[01:27] <SteveA> sabdfl: ?
[01:28] <sabdfl> hi! have a good dinner?
[01:29] <sabdfl> what's the idiom Interface(arg, none) all about?
[01:30] <sabdfl> stevea: ping?
[02:01] <sabdfl> hey stevea
[02:01] <SteveA> hi
[02:02] <sabdfl> what's the idiom return IPerson(xxx, None) about?
[02:02] <sabdfl> i think i have an authentication problem at the moment
[02:02] <sabdfl> she runs (!) but then falls over
[02:03] <SteveA> sorry -- flaky networking for a while
 hi! have a good dinner?
 what's the idiom Interface(arg, none) all about?
 dinner was pretty good
 japanese thai from chinatown
 one of the rosetta team screwed up the IPerson adapter
 I'm fixing it
 the idiom is IFoo(obj) or IFoo(obj, default_value)
 you get the default value if the object is not adaptable to IFoo
 kiko, celso, daniel and andrew say hi
 they're still getting the ad-hoc wireless hacking up
 yay! fuxed big!
[02:03] <sabdfl> how was yr dinner?
[02:03] <sabdfl> festive?
[02:03] <SteveA> yes, I'm checking in a fix
[02:03] <SteveA> one of the rosetta team screwed up the IPerson adapter
[02:04] <SteveA> dinner was good
[02:04] <SteveA> japanese / thai place
[02:04] <sabdfl> out of curiousity where was the fix?
[02:04] <SteveA> not so expensive
[02:05] <SteveA> dmark.py
[02:05] <sabdfl> what needed fixing?
[02:05] <sabdfl> i've been staring at it for half an hour, but didn't know where to enable auth or what the codepath was for the IPerson(principal, None) code
[02:05] <sabdfl> hey celso
[02:09] <SteveA> I had to add some imports, and change a little code in personFromPrincipal
[02:09] <SteveA> wtf is sys.path.append('../..') doing in there?
[02:09] <SteveA> that's seriously evil
[02:12] <daf> where was that?
[02:13] <sabdfl> SteveA: that was me, getting "import imark" or "import dmark" to work this afternoon
[02:13] <sabdfl> it worked, but you can happily remove it now
[02:13] <SteveA> the rosetta team really must get out of the habit of checking in code without testing it
[02:13] <SteveA> and I'm not just talking about unit testing -- just running the darn server and looking at a page
[02:14] <sabdfl> is the auth / iperson fix checked in now?
[02:14] <SteveA> I found the bug by using the postmortem debugger
[02:14] <sabdfl> we have some overlapping work by lalo and i
[02:14] <sabdfl> dlalo and dmark have a lot of common classes :-/
[02:17] <sabdfl> should i remove the common classes from dmark and let lalo work on them in dlalo?
[02:17] <sabdfl> or remove them from dlalo?
[02:17] <sabdfl> hey kiko
[02:18] <kiko> hey sabdfl
[02:18] <kiko> SteveA is lagged as always
[02:19] <sabdfl> do they have a decent wifi setup in the hotel?
[02:19] <kiko> well
[02:19] <sabdfl> or are you guys surfing courtesy of public dns?
[02:19] <kiko> not in the fifth floor, no
[02:19] <kiko> but they have ethernet cables in the rooms
[02:19] <kiko> we're surfing ad-hoc off debonzi's laptop
[02:19] <kiko> who in turn is connected through the hotel ethernet
[02:19] <sabdfl> ok
[02:20] <kiko> on the ground floor it's pretty good
[02:20] <kiko> so
[02:20] <kiko> I managed to land everything to get lp running
[02:20] <sabdfl> stevea: if there is a trivial fix to that launchpad issue, please just jabber it to me, it's not coming through arch
[02:20] <sabdfl> thanks kiko
[02:20] <kiko> however there's an auth fix that's needed
[02:20] <sabdfl> did the breakage come after that?
[02:20] <sabdfl> yes, that's what i'm staring at
[02:21] <kiko> apparently something that landed this morning in the pre-"freeze" checkins
[02:21] <sabdfl> is there a fix?
[02:21] <kiko> yes, SteveA has it in-hand but the network is on crack
[02:21] <kiko> let me try something
[02:21] <sabdfl> if it's quite, jabber it to me and i'll commit it
[02:21] <sabdfl> quick
[02:22] <kiko> let's see if he can get back on
[02:22] <kiko> jesus this room is full of raving madmen
[02:22] <sabdfl> welcome to canonical :-)
[02:22] <SteveA> hi
[02:23] <kiko> so SteveA is removing locks
[02:25] <SteveA> my archive mirror on chinstrap is locked
[02:25] <sabdfl> nice
[02:27] <sabdfl> geez, how is that even possible, if a chinstrap archive is just a mirror?
[02:28] <kiko> now that's a good question. I think the issue is that SteveA had a failed rocketfuel submission to PQM and well, the mirror locked because it failed "mid-stream".
[02:28] <SteveA> --- orig/lib/canonical/launchpad/dmark.py
[02:29] <sabdfl> blush. why did it have to be dmark?
[02:29] <SteveA> +++ mod/lib/canonical/launchpad/dmark.py
[02:29] <SteveA> @@ -3,6 +3,8 @@
[02:29] <SteveA>
[02:29] <SteveA>  # Zope interfaces
[02:29] <SteveA>  from zope.interface import implements
[02:29] <SteveA> +from zope.component import ComponentLookupError
[02:29] <SteveA> +from zope.app.security.interfaces import IUnauthenticatedPrincipal
[02:29] <SteveA>
[02:29] <SteveA>  # SQL imports
[02:29] <SteveA>  from sqlobject import DateTimeCol, ForeignKey, IntCol, StringCol, BoolCol
[02:29] <SteveA> @@ -1354,12 +1356,12 @@
[02:29] <SteveA>  def personFromPrincipal(principal):
[02:29] <SteveA>      """Adapt canonical.lp.placelessauth.interfaces.ILaunchpadPrincipal
[02:29] <SteveA>          to IPerson
[02:29] <SteveA> -
[02:29] <SteveA>      """
[02:29] <SteveA> -    # Adapter shouldn't return None
[02:29] <SteveA> -    #if IUnauthenticatedPrincipal.providedBy(principal):
[02:29] <SteveA> -    #    return None
[02:29] <SteveA> -
[02:29] <SteveA> +    if IUnauthenticatedPrincipal.providedBy(principal):
[02:29] <SteveA> +        # When Zope3 interfaces allow returning None for "cannot adapt"
[02:30] <SteveA> +        # we can return None here.
[02:30] <SteveA> +        ##return None
[02:30] <SteveA> +        raise ComponentLookupError
[02:30] <SteveA>      return Person.get(principal.id)
[02:30] <SteveA>
[02:30] <SteveA> my arch mirror is fucked in a way I don't immediately know how to repair
[02:31] <kiko> sabdfl, can you manage that patch?
[02:31] <kiko> we're in a precarious situation here
[02:31] <sabdfl> in progress...
[02:32] <kiko> in fact
[02:35] <sabdfl> ok, get a whole new traceback now. progress :-)
[02:35] <sabdfl> want me to commit this, then get working on the new one?
[02:38] <sabdfl> want me to commit that?
[02:38] <kiko> sabdfl, can you manage that commit?
[02:38] <SteveA_> yes please
[02:38] <SteveA_> I tried to jabber it to you too
[02:38] <sabdfl> coming up
[02:41] <sabdfl> it's at pqm now
[02:41] <kiko> w00t
[02:43] <kiko> lalo,
[02:45] <sabdfl> ok, phew, looks like we have a launchpad again :-)
[02:45] <sabdfl> thanks guys
[02:45] <kiko> lunchpad!
[02:46] <sabdfl> kiko see you for lunchpad action tomorrow
[02:46] <sabdfl> steve, celso, daniel, enjoy the weekend!
[02:46] <kiko> sabdfl, will do
[02:51] <sabdfl> night guys
[02:51] <lifeless> night
[02:53] <kiko> http://www.onlamp.com/pub/a/python/2004/09/23/plone_features.html?page=2
[02:53] <kiko> bradb wrote that one
[02:56] <dilys> Bug 2068 resolved: Wishlist: view PQM's pending queue
[02:56] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2068
[03:07] <kiko> BradB|London dude?
[03:08] <BradB|London> dude
[03:08] <BradB|London> just committed the sqlobject patch
[03:14] <kiko> you rock man
[03:14] <kiko> sabdfl managed to land some lp fixes
[03:14] <kiko> so lp is live
[03:14] <BradB> cool
[03:15] <kiko> but apparently your patch aint live
[03:15] <kiko> or so it seems
[03:16] <BradB> eh, that can't be good
[03:27] <BradB> it was patch-457
[03:28] <BradB> ...but I'm still waiting for the star-merge that started 10 minutes ago...
[03:29] <BradB> wow, that finished quickly; now i "just" have to do another commit
[03:33] <cprov_> found a bug there
[03:33] <cprov_> fixed
[03:34] <BradB> i'm still in the middle of grabbing the latest changes
[03:35] <BradB> 17 minutes to cvs -q up. Sweet.
[03:37] <BradB> We need paste.canonical.com or some such.
[03:37] <BradB> After merging, the app doesn't start for me.
[03:38] <BradB> zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/Users/bradb/launchpad/lp/site.zcml", line 5.2-5.33
[03:38] <BradB> ConfigurationError: ('Invalid value for', 'factory', "Couldn't import canonical.lp.tales, No module named icelso in canonical.lp.tales.RequestAPI")
[03:55] <cprov_> heh
[03:55] <cprov_> fixed nicely now
[03:59] <kiko> BradB, merging dude
[04:00] <spiv> Gah.
[04:00] <spiv> tla on chinstrap is spinning on mark's merge.
[04:00] <spiv> Maybe he forgot to mirror or something.
[04:00] <spiv> elmo, lifeless: please work your magic on PQM.
[04:03] <lifeless> done
[04:05] <kiko> wait
[04:05] <kiko> lifeless, done what?
[04:05] <spiv> kiko: PQM needed a poke.
[04:05] <lifeless> spivs request
[04:05] <spiv> kiko: Mark had an empty merge.
[04:05] <SteveA> lifeless: I asked tla to mirror my archive.  The process was interrupted.    How do I break this?
[04:06] <lifeless> tla lock-revision -b
[04:06] <SteveA> I tried that
[04:06] <lifeless> whats the command you used?
[04:06] <SteveA> hmm, worked this time
[04:06] <SteveA> must have been flaky network problems
[04:07] <SteveA> ta
[04:07] <spiv> SteveA: crappy error messages to go with crappy connectivity? :)
[04:09] <kiko> dude
[04:09] <kiko> are you on cable, or ad-hoc, SteveA?
[04:10] <spiv> He's on the KKGeorge ap I think.
[04:10] <spiv> lifeless: Thanks, btw.
[04:10] <lifeless> SteveA: whats the beef with the symlinks ?
[04:11] <lifeless> Other than many projects not punning their checkouts as packages.
[03:53] <sabdfl> ping?
[04:10] <kiko_fud> pong?
[04:11] <kiko_fud> hey brad
[04:11] <kiko_fud> where are you?
[04:11] <kiko_fud> oh, dumb question
[04:11] <BradB> yo dude, hotel
[04:11] <BradB> what's everyone doing today?
[04:11] <kiko_fud> dude lets hit the road, steve's waiting for us
[04:12] <BradB> heh, ok
[04:12] <kiko_afk> I'm downstairs in 5 mins
[04:12] <BradB> where are you/we going?
[04:13] <BradB> i.e. should i bring my laptop?
[04:13] <kiko_afk> we're going downtown, and no
[04:13] <BradB> ok, cool, see ya in a bit
[05:33] <sabdfl> daf, lalo: ping?
[07:52] <sabdfl> carlos: ping
[07:53] <carlos> sabdfl: pong
[07:53] <sabdfl> can you update the languages file as follows, please?
[07:53] <carlos> sure
[07:53] <sabdfl> change "English from United States" to be "English (United States)"
[07:53] <sabdfl> look ok?
[07:53] <carlos> for all languages?
[07:54] <sabdfl> yes, lang (country)
[07:54] <carlos> ok
[07:54] <sabdfl> thanks
[07:54] <sabdfl> hows the alpha going?
[07:54] <carlos> I'm going to the cinema now, I will change it tonight or tomorrow morning
[07:54] <sabdfl> have you seen my huge merge now?
[07:54] <sabdfl> ok
[07:54] <carlos> sabdfl: we are not getting as much feedback as I thought...
[07:54] <sabdfl> how many people are using it?
[07:54] <carlos> sabdfl: no, I'm scared about it :-P
[07:55] <carlos> hmm, let me check..
[07:55] <sabdfl> the merge is just starting to clear up a lot of duplication in the code
[07:55] <carlos> about 13 alpha testers
[07:56] <sabdfl> ok
[07:56] <sabdfl> let's keep it small like that for a few weeks while we clean up... there's lots of cleaning up to do
[07:56] <carlos> sabdfl: I know, and I like it, but I have some local changes that are broken now and I need to work on them to prevent any regression, that's the problem, but It's not more than one hour or so
[07:57] <sabdfl> ok, enjoy the movie, what are you going to see?
[07:57] <carlos> that's why I'm scared about the changes :-P
[07:57] <carlos> "El bosque"
[07:57] <sabdfl> hhrm.... stuff has moved ALL OVER the place
[07:57] <sabdfl> and is going to move again Monday
[07:57] <sabdfl> like RosettaPOTemplate -> POTemplate
[07:59] <carlos> I know
[07:59] <carlos> but If I catch up with the current changes
[07:59] <carlos> my additions will be moved also on Monday, right?
[07:59] <carlos> or should I wait?
[08:02] <carlos> I found it!! (I was looking for the english name of the movie :-P)
[08:02] <carlos> "The Village"
[08:02] <carlos> Sometimes they change the name completely
[08:03] <carlos> time to leave
[08:03] <carlos> later
[09:22] <kiko_afk> hey
[09:22] <kiko_afk> braderoo
[09:22] <BradB> yo
[09:24] <BradB> what time are we taking off
[09:24] <BradB> ?
[09:24] <kiko_afk> dunno, 15mins?
[09:25] <kiko_afk> I wont even bother changing nicks if so
[09:25] <kiko_afk> sabdfl, how's the Great Refactoring going?
[09:25] <BradB> Woohoo, glad Mark's advocating a sane way to name columns. StudlyCapsAreTooOftenMisused
[09:25] <kiko_afk> I'm against studly anything
[09:26] <BradB> even studly methods?
[09:26] <kiko_afk> just studly ClassNames.
[09:26] <kiko_afk> yeah, I don't know, maybe comes from a gtk+ thing
[09:26] <kiko_afk> instance and method names are lowercase
[09:26] <kiko_afk> class names are uppercase
[09:26] <kiko_afk> and never do unqualified imports of lowercase things.
[09:27] <BradB> Yeah, in this case I meant mixedCase actually, not StudlyCaps.
[09:27] <BradB> kiko_afk: so we'll meet in the lobby at 8:45?
[09:28] <kiko_afk> sounds good
[09:28] <kiko_afk> ring 517 and 519
[09:28] <kiko_afk> and tell them
[09:31] <BradB> ok, rang them
[09:32] <kiko_afk> gf' probably out with bf#2
[09:33] <kiko_afk> or hmm do I get to be #2 now <wink>
[09:34] <BradB> serious dude?
[09:34] <kiko_afk> nah
[09:34] <kiko_afk> said yesterday she was going to the movies to see the village
[09:35] <kiko_afk> like carlos up there
[09:35] <BradB> the village!
[09:35] <kiko_afk> I just remembered the whole thing because the name in portuguese is different and she said the name offhandedly
[09:37] <kiko_afk> stub's so cool
[09:44] <kiko_afk> time to dash
[11:25] <sabdfl> stub: ping


[19:50] <DalekSec> zequence: You were talking about perhaps not really making note of the 14.10 release, you could also do as mythbuntu does and fully go LTS releases only.
[20:26] <zequence> DalekSec: We had a discussion about that on the mail list, and decided to keep releasing the ISOs.
[20:26] <zequence> The only difference is that we recommend people to install the LTS.
[21:40] <DalekSec> OK, nice.
[21:55] <zequence> Release announcements away. Hope I didn't mess anything up, as I usually do.
[21:59] <DalekSec> Want to do the honors in #ubuntustudio, or shall I?
[22:05] <zequence> DalekSec: You mean change the welcome message?
[22:05] <DalekSec> The topic, yep.
[22:06] <zequence> DalekSec: Sure. I might have the rights, but not sure. Also, I've never done it, so be my guest :)
[22:07] <DalekSec> zequence: "14.04.1 and 14.10 Now Released"
[22:37] <zequence> DalekSec: Cool. Thanks!
[22:37] <DalekSec> Of course.


[00:02] <mup> Bug #1992704 changed: KVM hosts can be removed even with locked KVMs composed <MAAS:New> <https://launchpad.net/bugs/1992704>
[00:05] <mup> Bug #1992704 opened: KVM hosts can be removed even with locked KVMs composed <MAAS:New> <https://launchpad.net/bugs/1992704>
[00:08] <mup> Bug #1992704 changed: KVM hosts can be removed even with locked KVMs composed <MAAS:New> <https://launchpad.net/bugs/1992704>
[00:14] <mup> Bug #1992704 opened: KVM hosts can be removed even with locked KVMs composed <MAAS:New> <https://launchpad.net/bugs/1992704>
[00:17] <mup> Bug #1992704 changed: KVM hosts can be removed even with locked KVMs composed <MAAS:New> <https://launchpad.net/bugs/1992704>
[00:20] <mup> Bug #1992704 opened: KVM hosts can be removed even with locked KVMs composed <MAAS:New> <https://launchpad.net/bugs/1992704>
[07:06] <mup> Bug #1992314 changed: MAAS Turns Off Machines w/ Power Type Manual After PXE Boot <MAAS:Invalid> <https://launchpad.net/bugs/1992314>
[08:21] <mup> Bug #1829155 changed: Source routing configuration is not conditional <cpe-onsite> <MAAS:Invalid> <https://launchpad.net/bugs/1829155>
[08:51] <mup> Bug #1877669 changed: maas shell/dbshell missing from Snap <MAAS:Won't Fix by ack> <https://launchpad.net/bugs/1877669>
[08:57] <mup> Bug #1878895 changed: boot-resources start-import should re-start importing when changing boot-source configuration <sts> <MAAS:Won't Fix> <https://launchpad.net/bugs/1878895>
[09:07] <mup> Bug #1880448 changed: The UI should warn or prevent users from deploying if there is an issue with a rack controller <sts> <ui> <MAAS:Won't Fix> <maas-ui:New> <https://launchpad.net/bugs/1880448>
[13:05] <mup> Bug #1992791 opened: Info icons appear/disappear based on checked options in subnet page <ui> <MAAS:New> <https://launchpad.net/bugs/1992791>


[01:20] <Fudge> man still getting this from live build
[01:20] <Fudge> [2019-07-19 11:13:18] lb_binary_syslinux
[01:20] <Fudge> P: Begin installing syslinux...
[01:20] <Fudge> E: Unable to locate package syslinux-themes-ubuntu-oneiric
[01:23] <sarnold> where did *that* come from? oneiric reached end of life in 2013 https://wiki.ubuntu.com/Releases
[01:26] <Fudge> everytime i try to build an image I get that, building for disco amd64
[01:27] <Fudge> built the package form livecdroot-fs git
[01:32] <Fudge> I am just building this inside a directory, not a chroot or vm, maybe that is my error
[01:35] <jamesh> Fudge: which git repo?
[01:36] <jamesh> (i.e. is it possible you've picked some abandoned repo?)
[01:44] <duflu> Or have some old package installed
[02:36] <Fudge> https://paste.ubuntu.com/p/VjRfJzD8n9/
[02:40] <Fudge> jamesh:  yeah maybe im not, i thought lb was part of livecdroot-fs but i havent installed live-build from git, it's from archives
[03:17] <Fudge> does that actually help
[04:50] <Fudge> ill try with binary-images as iso and not iso-hybrid
[05:07] <Fudge> jamesh:  where is the live-build git repo ?
[06:00] <didrocks> good morning
[06:13] <duflu> Morning didrocks
[06:18] <didrocks> hey duflu
[07:14] <marcustomlinson> morning duflu and didrocks
[07:14] <duflu> Hi marcustomlinson
[07:16] <didrocks> hey marcustomlinson
[07:29] <oSoMoN> good morning desktoppers
[07:29] <Wimpress> o/
[07:31] <didrocks> salut oSoMoN, hey Wimpress
[07:32] <oSoMoN> hey didrocks, Wimpress
[07:35] <marcustomlinson> hey oSoMoN and Wimpress
[07:38] <duflu> Hi oSoMoN and Wimpress
[07:54] <Fudge> morning guys
[07:55] <marcustomlinson> morning Fudge
[07:55] <didrocks> hey Fudge
[07:56] <Fudge> sorry I was saying morning to you guys loL. It's still evening here.
[07:57] <Fudge> my bad
[07:58] <Trevinho> morning!
[08:00] <Fudge> Hi Trevinho
[08:00] <Trevinho> Fudge: hey
[08:03] <Fudge> so bit of an update for anyone who i've chatted with. I for quite some time have been trying to learn live build and thought i'd checked out the right git repository but first was debian, then i packaged livecd-rootfs but realised i was still using live-build from repos. So I am trying to find where live-build is maintained so I can build from master. Hopefully resolve some of the problems i'm
[08:03] <Fudge> having.
[08:03] <Laney> hi there
[08:04] <didrocks> hey Trevinho, Laney
[08:07] <willcooke> oopsm, forgot to open IRC
[08:07] <willcooke> morning all
[08:07] <didrocks> hey willcooke
[08:07] <Laney> hi didrocks willcooke
[08:08] <marcustomlinson> morning Trevinho Laney and willcooke
[08:08] <Fudge> Hi Laney  did you have a restful sleep
[08:13] <duflu> Morning Trevinho, Laney, willcooke
[08:16] <seb128> happy friday desktopers!
[08:18] <Laney> hey marcustomlinson Fudge duflu seb128!
[08:18] <Laney> Fudge: yeah pretty good thanks
[08:18] <seb128> hey Laney, how are you?
[08:18] <Laney> not bad!
[08:19] <marcustomlinson> morning seb128
[08:19] <Laney> got to get ready to leave in a bit
[08:19] <Laney> you?
[08:20] <seb128> Fudge, that's bug #1739790, the fix is trivial see comment #3 but seems foundations doesn't want to support those kinds of build so aren't interested to upload a fix, I will probalby end up doing that
[08:22] <seb128> Laney, I'm ok, my summerflu is getting better, but now my gf got it and she is with the little one on fridays so I acted backups for some hours, it feels like it's going to be a busy day
[08:22] <seb128> also we leave for Spain tomorrow for 2 weeks but didn't start packing yet :-/
[08:23] <Laney> oh I forgot you were off!
[08:23] <Laney> :S
[08:23] <Laney> hope you both get well enough to enjoy that
[08:25] <seb128> thx
[08:27] <seb128> I hope you have a good flight
[08:27] <seb128> is that a direct one? how long?
[08:28] <didrocks> hey seb128
[08:28] <Trevinho> seb128: oh... Hey! sorry to hear you had flu
[08:28] <seb128> lut didrocks, en forme ?
[08:28] <didrocks> ça va, et toi ?
[08:28] <seb128> hey Trevinho! yeah, in summer, wth :/
[08:29] <seb128> didrocks, ça va un peu mieux :)
[08:30] <Laney> 2 flights, 11:55 + 6 hour wait + 01:00
[08:31] <oSoMoN> that's a long journey
[08:32] <Laney> yeah :(
[08:32] <oSoMoN> (I know du_flu would disagree)
[08:34] <seb128> :-/
[08:34] <seb128> 6 hours wait for the 1hour also sucks :/
[08:34] <Laney> hope there's a place to shower / sleep
[08:44] <Fudge> seb128:  thanks I noticed the same bug , but must have missed comment 3 with a fix. I will look again
[08:45] <Fudge> seb128:  awesome that is great thank you for pointing that out for me.
[08:46] <seb128> np
[08:46] <oSoMoN> Trevinho, I manage to reliably crash gnome-shell by creating a symlink to a folder on my desktop, and then using the context menu to send it to the trash. Can't reproduce in a clean disco/eoan VM though. Does that ring a bell?
[08:47] <seb128> oSoMoN, hum, I saw something like that yesterday...bug #1832124
[08:48] <oSoMoN> seb128, ah, thanks, I'll attach my crash file to the report
[08:48] <seb128> thx!
[08:48] <seb128> journal log gnome-shell extracts would be useful as well
[08:48] <oSoMoN> sure
[08:49] <seb128> also send it using ubuntu-bug, easier to review things from the error tracker than from a dump attached to a comment
[08:50] <Fudge> is there anyone running accessibility team currently?
[08:50] <seb128> I don't think so
[08:54] <Fudge> seb128:  I'm using Version: 3.0~a57-1ubuntu38
[08:54] <Fudge> but don't see the code for LB_SYSLINUX_THEME in the function/defaults.she file
[08:56] <seb128> Fudge, live-build-3.0~a57/functions/defaults.sh:1220:			LB_SYSLINUX_THEME="${LB_SYSLINUX_THEME:-ubuntu-oneiric}"
[08:56] <seb128> grepping on that same version here
[09:23] <Fudge> seb128:  sorry but I can't find it with grep or search
[09:25] <seb128> Fudge, can you pastebin the log from those commands
[09:25] <seb128> $  dget https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/live-build/3.0~a57-1ubuntu38/live-build_3.0~a57-1ubuntu38.dsc
[09:25] <Fudge> root@rob:/usr/share/live/build/functions# cat defaults.sh  |grep -i theme
[09:25] <seb128> $ dpkg-source -x live-build_3.0~a57-1ubuntu38.dsc
[09:25] <Fudge> root@rob:/usr/share/live/build/functions#
[09:26] <seb128> $ grep -n oneiric live-build-3.0~a57/* -r
[09:26] <seb128> (or without the '/*' that's not needed)
[09:26] <seb128> ah, you are speaking installed system
[09:27] <Fudge> yes
[09:27] <seb128> $ grep oneiric * -r
[09:27] <seb128> usr/share/live/build/functions/defaults.sh:			LB_SYSLINUX_THEME="${LB_SYSLINUX_THEME:-ubuntu-oneiric}"
[09:28] <seb128> in https://launchpad.net/ubuntu/+source/live-build/3.0~a57-1ubuntu38/+build/16902755/+files/live-build_3.0~a57-1ubuntu38_all.deb
[09:29] <seb128> Fudge, md5sum /usr/share/live/build/functions/defaults.sh ?
[09:30] <Fudge> ok now i see it
[09:30] <Fudge> dpkg: warning: downgrading live-build from 1:20190315 to 3.0~a57-1ubuntu38
[09:30] <seb128> what did you change?
[09:30] <Fudge> i installed the package you linked me to
[09:30] <seb128> ah, unsure where you got the previous version you had?
[09:31] <Fudge> ive been looking for the git repo, but I thought live-build was in the armine archive
[09:32] <Fudge> ermine oops
[09:35] <Fudge> seb128:  running now, let you know how it goes. Thank you for the help
[09:36] <Fudge> hope you feel better soon and have a great trip, binge some Netflix
[09:36] <seb128> thanks! :)
[09:37] <seb128> let us know how the build goes
[09:41] <Fudge> do I just drop the -oneiric off the package name?
[09:43] <Fudge> this is the build if you scroll to the end https://paste.ubuntu.com/p/6s9jVpmQqW/
[09:44] <Fudge> oh you said xenial on your post
[09:45] <Fudge> i didnt repalce oneiriric with xenial, just removed -oneiric
[09:45] <Fudge> will retry
[09:49] <Trevinho> oSoMoN: mh, no bell... Can you check journalctl /usr/bin/gnome-shell -b0 if there are reports related to js dumpstack?
[09:51] <Trevinho> it should mention the crash signal
[09:51] <seb128> Fudge, the non versioned should depends on -xenial so be equivalent
[09:52] <seb128> so I guess more fixes are needed :-/
[09:53] <Fudge> seb128:  takes me a while to pick things up, i'm not a devloper. But i've been cracking on with this when time has availed itself for a long time.
[09:54] <oSoMoN> Trevinho, https://paste.ubuntu.com/p/CktKzBvSR7/
[09:54] <oSoMoN> gotta go on a quick errand, bbiab
[09:56] <Fudge> seb128:  well I have an iso so i'd call that success 538M    binary.hybrid.iso
[09:57] <seb128> Fudge, there is one problem still with the theme though
[09:57] <Fudge> oh?
[10:00] <seb128> Fudge, ah, you need to use -xenial indeed
[10:00] <seb128> well your log has 'cp: cannot stat '/usr/share/syslinux/themes/ubuntu/isolinux-live': No such file or directory'
[10:00] <seb128> so the syslinux theme copy failed
[10:00] <seb128> which means your menu/theme might not look right
[10:00] <Fudge> this is for blind ppl ;)
[10:01] <seb128> but it should be only cosmectic
[10:01] <seb128> k
[10:01] <seb128> so you don't care much I guess :)
[10:01] <Fudge> this is the build I just finished though https://paste.ubuntu.com/p/TPmhgH5ymF/
[10:02] <Fudge> this is the easy part sadly, I still have to learn how to incorporate our seeds and how to merge them with upstream ubuntu
[10:02] <Fudge> themuso gave me small tid bits here and there but managed it himself, so I hadn'nt really learned from him.
[10:03] <seb128> I don't know if commented things somewhere sorry
[10:03] <Fudge> all good
[10:04] <seb128> bah, where are the ppc64el builders?
[10:05] <Fudge> :D
[10:06] <seb128> changing location, brb
[10:28] <Fudge> seb128:  wb, so you're on a holiday soon?
[10:32] <seb128> Fudge, yes, tonight :)
[10:49] <Fudge> where from and to seb128
[10:51] <seb128> Europe to Europe, easy one :p
[10:51] <seb128> going to Spain for 2 weeks
[10:55] <Fudge> what attracts you there?
[11:01] <Fudge> seb128:  Tasmania is a great place to tour
[14:05] <oSoMoN> didrocks, seb128: no luck on this chromium snap CSD theming bug: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1800260/comments/7
[14:05] <seb128> oSoMoN, :-(
[14:10] <seb128> oSoMoN, I don't know what you tried yet but random $whatIwouldtry is to strace -e open | grep css it and start deleting files listed there to see what difference they make
[14:10] <oSoMoN> seb128, I listed everything I tried in comments on the bug report, for future reference
[14:11] <oSoMoN> I'll try that
[14:12] <seb128> oSoMoN,
[14:12] <seb128> > it locates and opens the expected css file (~/snap/chromium/current/.local/share/themes/Yaru/gtk-3.20/gtk.css)
[14:12] <seb128> would be interesting to replace that one by the one from another theme which is quite different
[14:12] <seb128> to see if that leads to a different result
[14:13] <oSoMoN> yes, and this CSS file is actually bind-mounted from gtk-common-themes, so can't easily delete it
[14:13] <seb128> ah
[14:13] <seb128> I guess you could cp -r that directory
[14:13] <seb128> disconnect the theme
[14:14] <seb128> and copy manually the content to ~/snap
[14:14] <oSoMoN> in comment #6 I modified the CSS to change the headerbar colors, and the unfocused one was picked up correctly, but not the focused one
[14:14] <seb128> that's really puzzling :/
[14:14] <oSoMoN> in other news, LP librarian being down is pretty annoying
[14:15] <seb128> indeed
[14:18] <seb128> oSoMoN, did you try under xfce just to see if the shell in use makes a difference?
[14:18] <oSoMoN> I didn't, let me do that now
[14:21] <didrocks> oSoMoN: argh :/ I'm quite out of idea with this now…
[14:22] <didrocks> oSoMoN: you didn't check the gtk3 vs gtk3.20 thingy, though, no?
[14:22] <didrocks> just to check if removing one doesn't kick some internal behavior for chromium
[14:23] <didrocks> ah, it yeah, basically what seb128 says was the last element we discussed about as a workaroud, to ensure the right files are really used
[14:24] <oSoMoN> didrocks, nope, but I double-checked the strace and only the gtk3.20 css is read
[14:24] <didrocks> (but indeed, not easily to do)
[14:24] <didrocks> weird weird weird…
[14:24] <seb128> disconnecting the theming and copying the content manually shouldn't be too difficult?
[14:24] <oSoMoN> yeah, I can do that
[14:24] <oSoMoN> testing a xubuntu session now
[14:29] <oSoMoN> oh, interesting, in an XFCE/Xubuntu session with Yaru, the chromium snap is correctly themed
[14:32] <didrocks> c r a z y
[14:32] <didrocks> wondering if they don't have a XDG_CURRENT_SESSION or whatsover hardcoded value…
[14:33] <seb128> oSoMoN, interesting...
[14:34] <oSoMoN> and librarian is back \o/
[14:34] <seb128> didrocks, but the deb is the same source code and doesn't have the same issue in the same session
[14:34] <seb128> crazyness
[14:34] <oSoMoN> seb128, not just the deb, also the snap unconfined
[14:35] <didrocks> seb128: right, the deb would be impacted… or it's the session + try to find some files at a particular place
[14:35] <seb128> Trevinho, do you know if there any magic in gnome-shell for decorations that could impact confined snaps?
[14:35] <oSoMoN> (presumably because it's using the system-wide theme, instead of the one from gtk-common-themes)
[14:35] <seb128> Trevinho, or more specifically the chromium one
[14:36] <didrocks> oSoMoN: have you tried locally the snap as a classic one? (with the rest of the libs local?)
[14:36] <didrocks> like, giving it access to system-wide theme
[14:37] <Trevinho> seb128: mhmh, don't think so... it's just server-side decorated when using native borders.
[14:37] <Trevinho> otherwise not sure if they check something outside X to do any magic...
[14:38] <oSoMoN> didrocks, I unpacked the snap in a folder and ran it from there, unconfined, and it got the right color
[14:38] <Trevinho> ah... mhmh so.. reading the gsettings maybe? but looks weird it can't
[14:38] <didrocks> oSoMoN: with all other libs referencing local snap version? (but the theme?)
[14:39] <seb128> Trevinho, what gsettings? it seems to parse the css
[14:39] <seb128> Trevinho, see comments on bug #1800260
[14:39] <oSoMoN> didrocks, no, it was fully unconfined, so using system-wide libs only
[14:40] <didrocks> seb128: hum, maybe a mix of the 2, with some LD_LIBRARY_PATH magic, would worth a try?
[14:40] <Trevinho> ooh OK, then out of context.
[14:46] <seb128> Trevinho, read the bug please in case you have an idea, Olivier is banging his head on that one for some weeks and could use help
[14:46] <Trevinho> oSoMoN: I remember that using GTK_DEBUG=interactive I was able to get some infos... but actually the best way to debug style issues three was to use a ld-preload that was debugging style calls...
[14:46] <seb128> didrocks, oSoMoN, well the snap works confined with yaru from gtk-common-theme on xubuntu if I understood correctly the comment a bit earlier?
[14:46] <Trevinho> let me see if I can find my snippet
[14:46] <seb128> that would rule out any confinement/gsettings issue
[14:46] <oSoMoN> seb128, yes, that's correct
[14:47] <oSoMoN> Trevinho, yeah I also tried GTK_DEBUG=interactive a while back
[14:47] <didrocks> seb128: the idea was: files confined with other env variables (like XDG_* differing), but that may be unlikely
[14:48] <seb128> yeah, I guess it's not impossible, still weird :/
[14:48] <didrocks> oSoMoN: maybe try overriding some env variable before launching the snap in the mate session to see if there is an imapct?
[14:48] <didrocks> impact*
[14:51] <Trevinho> Mhmh I can't find the specific. but something based on this acting on the style context printing the widget path maybe
[14:51] <Trevinho> https://cloud.trevi.me/index.php/s/7kb52AspQDcr4Hs
[14:57] <oSoMoN> interestingly, I'm observing that the headerbar color for other themes isn't always correct. I thought only yaru was affected, but it seems adwaita is, too. ambiance isn't
[15:03] <seb128> oSoMoN, it would make sense for it to not being theme specific...
[15:04] <oSoMoN> yeah, at least it opens up more doors, as I was kind of going in circles focusing on yaru only
[15:12] <oSoMoN> oh, and it's not just chromium, actually… the gnome-calculator snap with adwaita doesn't get the right background color for the headerbar when focused
[15:14] <Trevinho> mhmhmh... IIRC they check an atom set on the window to verify the focused state... but don't know if things changed now to use a mode for Wayland too; need to check gtk
[15:15] <Trevinho> oSoMoN: are the other widgets using the active / backdrop state too? or just the headerbar
[15:15] <seb128> oSoMoN, win, you are off the hook now! :)
[15:15] <oSoMoN> heh, just in time for beer o'clock :)
[15:16] <oSoMoN> Trevinho, there are other widgets using active/backdrop, but afaict only the headerbar is getting the wrong color, and only in the active state, backdrop is fine
[15:18] <oSoMoN> I'll take a couple of screenshots and stitch them together to demonstrate the issue with gnome-calculator
[15:24] <seb128> oSoMoN, but it's fine on xubuntu?
[15:24] <seb128> start looking like a gnome-shell bug...
[15:25] <oSoMoN> nope
[15:25] <oSoMoN> not fine on xubuntu, for adwaita
[15:26] <oSoMoN> I wonder if the version of adwaita that's shipped in gtk-common-themes changed significantly between bionic and disco (assuming we're shipping the bionic version, not a recent upstream one)
[15:27] <oSoMoN> hrm no, the version in gtk-common-themes is built from https://gitlab.gnome.org/GNOME/adwaita-icon-theme.git
[15:28] <oSoMoN> ah no, that's only the icon theme
[15:28] <seb128> :-/
[15:28] <oSoMoN> I need a break, my brains are melting
[15:30] <oSoMoN> adwaita comes from https://gitlab.gnome.org/GNOME/gnome-themes-extra, apparently
[15:30] <oSoMoN> so not the version in bionic
[15:30] <Laney> hi fron london
[15:30] <oSoMoN> hey Laney
[15:30] <Trevinho> oSoMoN: ah, I just read the paste you sent me this morning (it went to a dead tab :P), anyways it seems something that the incoming SRU/update should cover
[15:31] <oSoMoN> Trevinho, some good news at last :)
[15:31] <Trevinho> oSoMoN: adwaita is inside gtk itself
[15:31] <Trevinho> no=
[15:31] <Trevinho> ?
[15:31] <Trevinho> hi Londolaney
[15:32] <Laney> I should get a laptop with better battery
[15:32] <Laney> 1h47 train ride, it was dead by the end of it
[15:32] <Laney> ://////\\\\\\/////\\\\\
[15:32] <oSoMoN> Trevinho, but gtk-common-themes embeds a copy of adwaita
[15:32] <Trevinho> Laney: so it happens, I changed mine few weeks ago since from a day to another died, and now I can support 5-6hrs again :P
[15:33] <Laney> Trevinho: new laptop or new battery?
[15:36] <Trevinho> battery
[15:36] <Trevinho> don't tell my employer, but I can do more than three years with a recent laptop :P
[15:36] <Laney> nod
[15:36] <Laney> heh
[15:37] <Laney> tbh I knew it wasn't the best at the time, but the hidpi screen tempted me anyway ...
[15:39] <seb128> sucks that battery go down like that over the years
[15:39] <seb128> can you find some shop that would get the xps appart and replace the battery?
[15:41] <jibel> there are usually good videos that explain how to disassemble most laptops
[15:41] <Laney> I could probably do it
[15:42] <Laney> where it says "Capacity: 48.2%" in g-p-m, ...
[15:42] <jibel> and it's yours do you'll take care unlike random shops or support services
[15:42] <Laney> is that the one to be looking at?
[15:42] <jibel> s/do/so
[15:43] <didrocks> anyway, time for week-end, good holidays seb128, have a nice trip Laney!
[15:43] <Laney> bye didrocks!
[15:46] <seb128> Laney, I think so
[15:46] <Laney> that sounds quite bad then /o\
[15:46] <Laney> I could be having a whole 3 hours!!!!!
[15:56] <seb128> that doesn't sound great either :-/ That quite convince me to not go for a hidpi screen, I've enough to chase power plugs in train or to have to go back from $place because I didn't take the charger and the laptop gets flat in a few hours
[15:57] <Laney> yeah, not such how much better current models are
[15:57] <Laney> you pay a penalty for it
[16:07]  * Laney is relocating, biab
[16:26] <oSoMoN> I'm calling it a day, have a great week-end everyone, bonnes vacances seb128
[16:35] <seb128> going to do the same here, need to start packing
[16:35] <seb128> have a nice w.e desktopers, good luck for next week, I'm probably going to be around at time but not on a regular basis/schedule
[16:36] <willcooke> see you seb128
[16:36] <willcooke> have a good holiday
[16:36] <seb128> thanks!
[16:38] <marcustomlinson> yeah have a good holiday seb128
[17:17] <willcooke> night all, happy weekend


[22:55] <HyP3r> Hello. I guess it is a more systemd-resolvd question... but how can I define a "backup-dns" server?
[22:56] <HyP3r> Actually I have just a array of some dns servers and it seems like systemd-resolvd just uses a random host


[00:44] <thumper> dog walk, then addressing review comments...
[00:44]  * thumper afk for a bit
[01:21] <redir> manana juju-dev
[01:41] <wallyworld> menn0: a small one, fixes 2 blockers, when you have a moment http://reviews.vapour.ws/r/5276/
[01:43] <menn0> wallyworld: looking
[01:45] <menn0> wallyworld: ship it
[01:45] <wallyworld> menn0: ta
[01:45] <anastasiamac> menn0: axw beat u to it too :D
[02:02] <menn0> wallyworld: I think I've figure out what's going on with https://bugs.launchpad.net/juju-core/+bug/1604514
[02:02] <mup> Bug #1604514: Race in github.com/joyent/gosdc/localservices/cloudapi <blocker> <ci> <joyent-provider> <race-condition> <regression> <juju-core:In Progress by menno.smits> <https://launchpad.net/bugs/1604514>
[02:02] <menn0> it's certainly not a new issue
[02:02] <menn0> and I really don't think it should be a blocker
[02:02] <wallyworld> yeah, i'd be surprised if it were
[02:03] <menn0> I think the problem is that the joyent provider destroys machines in parallel
[02:03] <wallyworld> it's not a regression
[02:03] <wallyworld> i'm surprised it was marked as such
[02:03] <menn0> but the joyent API test double isn't safe to access concurrently
[02:03] <wallyworld> sounds plausible
[02:04] <menn0> the correct place to fix it is in the test double but that's not our code
[02:04] <wallyworld> yep, i think we can unmark as a blocker and figure out what to do from there
[02:05] <wallyworld> we may need to pull in that external code, as a i doubt we will get it to be fixed
[02:05] <menn0> wallyworld: ok, i'll update the ticket so it's no longer blocking
[02:06] <menn0> wallyworld: and then I'll poke it some more to see if I can figure out a fix
[02:06] <menn0> wallyworld: I can /occasionally/ reproduce the race if I use dave's stress script
[02:07] <wallyworld> maybe there's a work around in the non test code, but would be better to fix upstream i guess
[02:13] <stokachu> menn0: im still seeing https://bugs.launchpad.net/juju-core/+bug/1604644
[02:13] <mup> Bug #1604644: juju2beta12: E11000 duplicate key error collection: juju.txns.stash <blocker> <conjure> <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1604644>
[02:13] <stokachu> just fyi
[02:13] <menn0> stokachu: that's the issue xtian was looking at
[02:14] <stokachu> menn0: this one was https://bugs.launchpad.net/bugs/1593828
[02:14] <mup> Bug #1593828: cannot assign unit E11000 duplicate key error collection: juju.txns.stash <ci> <conjure> <deploy> <intermittent-failure> <oil> <oil-2.0> <juju-core:Fix Released by 2-xtian> <https://launchpad.net/bugs/1593828>
[02:14] <stokachu> and it was marked fixed
[02:15] <menn0> stokachu: they're the same issue (dup)
[02:16] <menn0> stokachu: which version of Juju are you using? I think it was only fixed very recently (not sure exactly when though)
[02:16] <stokachu> menn0: correct, i opened a new issue as the previous version was marked fixed release
[02:17] <stokachu> Bug #1604644: juju2beta12: E11000 duplicate key error collection: juju.txns.stash
[02:17] <mup> Bug #1604644: juju2beta12: E11000 duplicate key error collection: juju.txns.stash <blocker> <conjure> <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1604644>
[02:17] <stokachu> juju beta 12
[02:17]  * menn0 checks when the fix went in
[02:18] <stokachu> beta12 lol
[02:19] <thumper> menn0: perhaps the patch approach didn't work?
[02:20] <mup> Bug #1589471 changed: Mongo cannot resume transaction <canonical-bootstack> <juju-core:Invalid> <https://launchpad.net/bugs/1589471>
[02:20] <menn0> stokachu, thumper: nope the fix didn't make beta12
[02:20] <mup> Bug #1604641 opened: restore-backup fails when attempting to 'replay oplog' again <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1604641>
[02:20] <mup> Bug #1604644 opened: juju2beta12: E11000 duplicate key error collection: juju.txns.stash <blocker> <conjure> <mongodb> <juju-core:Triaged> <https://launchpad.net/bugs/1604644>
[02:20] <stokachu> lmao
[02:20] <stokachu> it got mark fixed release
[02:20] <menn0> the fix is here: 99cb2d1c148f5ed1d246bf4fe44064363226e12e (Jul 15)
[02:20] <menn0> it's not in beta12
[02:21] <stokachu> menn0: can you update that bug with your findings
[02:21] <stokachu> 1604644
[02:21] <menn0> stokachu: will do. shall I also mark it as a dup of the other one?
[02:22] <stokachu> menn0: the other bug is already mark fixed released
[02:22] <thumper> menn0: I thought the patch was applied to the top of our mgo branch
[02:22] <stokachu> i think we should leave that one alone and work off this new one
[02:22] <thumper> menn0: check with mgz and sinzui
[02:22] <thumper> and balloons I suppose
[02:22] <stokachu> sinzui: ^ they are saying it didnt make it in
[02:22] <stokachu> make it in beta12
[02:22] <menn0> thumper: no, it looks like we copied in a fixed version of mgo's upsert code into juju
[02:24] <menn0> ah crap... chrome crash
[02:26] <menn0> thumper: oh never mind, you're right we patch over mgo in the build
[02:26] <menn0> thumper: at any rate, that change isn't in beta12
[02:26] <thumper> Which was the release we just did? It should be in that
[02:27] <thumper> if stokachu is building from source, he won't have it
[02:27] <stokachu> this is from the ppa
[02:27] <thumper> hmm...
[02:27] <thumper> that should have the fix
[02:27] <menn0> thumper: the latest tag in git is "juju-2.0-beta12"
[02:27] <menn0> the fix is 99cb2d1c148f5ed1d246bf4fe44064363226e12e
[02:27] <menn0> when I check out the tag, the fix isn't there
[02:28] <menn0> when I check out master, it is
[02:28] <thumper> ugh
[02:28] <stokachu> im guessing a one-off was done for this issue
[02:28] <stokachu> ?
[02:29] <menn0> perhaps there was some miscommunication about when the release was ok to cut
[02:29] <lazyPower> booo, that was in the release notes too
[02:29] <lazyPower> mgo package update that retries upserts that fail with ‘duplicate key error’ lp1593828
[02:29] <lazyPower> speaking of o/ hey core team :
[02:29] <lazyPower> :)
[02:31] <stokachu> so we're sure that fix isn't in beta 12 from the ppa?
[02:32] <stokachu> because it's also uploaded to the archive :)
[02:32] <menn0> stokachu: pretty sure. the release tag is there in git, and the fix isn't part of that release.
[02:33] <stokachu> menn0: ok, if you don't mind updating that bug so i can follow up with balloons/mgz in the morning
[02:33] <menn0> awesome :(
[02:33] <menn0> stokachu: will do. i'll poke xtian too so he's in the loop
[02:33] <stokachu> menn0: ok cool thanks a bunch
[02:33] <sinzui> menn0: thumper: The patch was added to the juju tree, and the scrpt that makes the tar file applies it. that is the hack that mgz put together
[02:33] <thumper> sinzui: looks like something didn't take though
[02:34] <thumper> o/ lazyPower
[02:34] <axw> wallyworld: I'm planning to add this to the cloud package: http://paste.ubuntu.com/20129296/. one of those will be present in a new environs.OpenParams struct. sound sane?
[02:34] <menn0> sinzui: it looks like the rev didn't make the cut of the release.
[02:34] <axw> sound/look
[02:34] <sinzui> Yeah, that is a bad way to deliver a fix
[02:34] <wallyworld> axw: loking
[02:34] <menn0> sinzui: what to do now?
[02:35] <axw> wallyworld: open to suggestions for a better name also
[02:35] <sinzui> menn0: I have no idea. I think godeps should define the repo and rev. Other wise we continue to maintain the patch in the tree and apply it each time the tar file is made
[02:36] <menn0> sinzui: the immediate problem is that beta12 didn't include the fix at all. the revision with the fix was committed *after* beta12 was cut.
[02:37] <menn0> sinzui: the mgo patch doesn't exist in beta12
[02:37] <stokachu> we should amend the release notes and set the fix for beta13
[02:37] <wallyworld> axw: i don't think that struct belongs in cloud - it's an analgamation of things used for an environ should really belongs in there
[02:37] <wallyworld> and then it could be called CloudSpec
[02:37] <wallyworld> or something
[02:37] <sinzui> menn0: I cannot help at this point. The release was started we aboorted and tried again.
[02:38] <stokachu> so can the mgo fix be pulled into godeps now?
[02:38] <stokachu> what was the reason for applying the fix during the tarball build
[02:39] <thumper> anastasiamac: while you are doing virt-type fixes, core/description/constraints_test.go:25, the virt type needs to be added to the allArgs func
[02:39] <axw> wallyworld: yeah ok, that's what I had to start with. issue is how to then make State implement EnvironConfigGetter. I think I'll have to define a type outside of the state package that adapts it to that interface
[02:40] <wallyworld> stokachu: the reason was we don't control upstream and we could not get the fix landed for us to use
[02:40] <wallyworld> so we were forced to adopt a solution where the change was patched in a s part og the build
[02:40] <stokachu> wallyworld: so the fixed was pulled in before the PR was accepted?
[02:40] <thumper> stokachu: more complicated than that...
[02:40] <stokachu> ah ok
[02:41] <stokachu> just trying to understand
[02:41] <thumper> related to golang, imports and the mgo release process
[02:41] <wallyworld> stokachu: no, the upstream PR was unaccepted but it was landed in an unstable v2 branch which we could not use directly
[02:41] <wallyworld> it's all a mess
[02:41] <thumper> s/unaccepted/accepted/
[02:41] <stokachu> ok, but the status in master is it is now part of the tree?
[02:41] <wallyworld> no :-(
[02:41] <thumper> kinda
[02:41] <wallyworld> not that i am aware of
[02:41] <thumper> but poorly
[02:42] <thumper> wallyworld: it is in a patch...
[02:42] <thumper> in the tree
[02:42] <thumper> ick
[02:42] <stokachu> how do you guys do it, this makes my head hurt
[02:42] <wallyworld> sure, but unless you apply the patch manually....
[02:42] <thumper> yes
[02:42] <wallyworld> mine too
[02:42] <thumper> stokachu: many years of built up resistence
[02:42] <lazyPower> stokachu - i'm going to say copious amounts of beer and callous to schenanigans
[02:42]  * thumper goes to put the kettle on
[02:42] <stokachu> thumper: lol, you guys will lead the zombie resistance
[02:43] <stokachu> lazyPower: :D
[02:43] <thumper> I for one await the zomie appocalypse
[02:43] <menn0> stokachu: this is partially due to the way Go handles imports
[02:43] <lazyPower> I never trusted go imports
[02:43] <stokachu> ok so not as simple as placing the git rev in the Godeps stuff
[02:43] <menn0> stokachu: b/c mgo is imported all over the place across multiple repos, if we want to fork it, we would have to change *everything*
[02:44] <menn0> stokachu: no, b/c the fix got accepted into mgo's unstable branch, but isn't yet in the stable branch
[02:44] <stokachu> ah i see
[02:44] <stokachu> gotcha, i didnt realize it was never in the stable branch
[02:44] <menn0> stokachu: we *could* use the unstable branch, but that pulls in a bunch of other stuff we don't really want
[02:44] <stokachu> understood
[02:46] <lazyPower> doesn't that mean its going to wind up landing in stable and pull in that bunch of other stuff eventually?
[02:46]  * lazyPower is showing his ineptitude at golang
[02:52] <natefinch> the whole "unstable" thing in the import path just seems like a bad idea.  Either make it a new version or don't.  If you want to mark it as unstable, do so in the readme.
[02:57]  * thumper notes that we are still using charm.v6-unstable
[02:57] <natefinch> yep
[02:57] <natefinch> dumb idea
[02:58] <natefinch> instead of having to go change all the imports once when we move to a new version, we have to do it twice.  Assuming we ever actually bother to rename it from unstable.
[04:08] <menn0> wallyworld: fix for the joyent race: http://reviews.vapour.ws/r/5277/
[04:08] <wallyworld> looking
[04:09] <wallyworld> menn0: lgtm
[04:10] <menn0> wallyworld: thansk
[04:10] <menn0> thanks even
[04:11] <menn0> wallyworld: backport to 1.25 as well/
[04:11] <menn0> ?
[04:11] <wallyworld> menn0: um, it's such a simple fix, why not
[04:11] <menn0> wallyworld: ok
[04:11] <wallyworld> might get a bless more often than twice a year
[04:22] <thumper> menn0: re dump-model review, and See Also, I copied it from elsewhere...
[04:23] <thumper> I did think it was strange
[04:25]  * thumper looks for a good example
[04:38] <thumper> menn0: updated http://reviews.vapour.ws/r/5265/
[04:38] <thumper> added a few drive by fixes for "See also:" formatting, made consistent with juju switch
[04:38] <thumper> menn0: made the apiserver side a bulk call, client api still single
[04:38] <thumper> added client side formatting
[04:44] <menn0> thumper: looking. I wasn't really suggesting that you had to do the bulk API work given the rest of the facade but great that you did anyway :)
[04:45] <menn0> thumper: "See also" is already quite inconsistent between commands
[04:45] <menn0> sigh
[04:45] <thumper> I thought that switch was most likely to be right
[04:45] <thumper> I looked at quite a few
[04:45] <menn0> thumper: oh hang on... you fixed them all!
[04:45] <thumper> and picked the resulting style
[04:45] <menn0> thumper: nice
[04:46] <thumper> well, in that package
[04:49] <menn0> thumper: ship it!
[04:50] <thumper> menn0: ta
[05:53] <babbageclunk> menn0: D'oh.
[08:00] <frobware> dooferlad: ping
[08:01] <dooferlad> frobware: hi
[08:01] <frobware> dooferlad: any change we can meet now?
[08:02] <frobware> chance
[08:02] <dooferlad> frobware: need 5 mins
[08:02] <frobware> dooferlad: I have a plumber arriving in ~30 mins which is likely to clash with our 1:1
[08:02] <frobware> dooferlad: ok
[08:03] <babbageclunk> menn0: ping?
[08:04] <menn0> babbageclunk: howdy... i'm in the tech board call atm. talk after?
[08:04] <babbageclunk> menn0: cool cool
[09:13] <menn0> babbageclunk: hey, done now
[09:14] <babbageclunk> menn0: Sorry, in standup.
[09:14] <wallyworld> fwereade: in prep for some work, i have needed to move model config get/set/unset off client facade to their own new facade, so essentially a copy of stuff and a bit of boiler plate for backwards compat until gui is updated. would love a review at your leisure so i can land when CI is unclocked http://reviews.vapour.ws/r/5279/
[09:15] <wallyworld> i also removed jujuconnsuite tests \o/
[09:17] <menn0> babbageclunk: np, I'll hang around for a bit.
[09:23] <fwereade> wallyworld, ack, thanks
[09:24] <fwereade> wallyworld, I presume: s/have needed to/gladly took the opportunity to/ ;p
[09:34] <wallyworld> fwereade: that too, but also a need
[09:34] <wallyworld> :)
[09:44] <babbageclunk> menn0: Sorry, rambling discussion about godeps and vendoring. Nearly done.
[09:45] <menn0> babbageclunk: sounds like a repeat of the tech board meeting :)
[09:45] <babbageclunk> menn0: quite
[09:45] <babbageclunk> menn0: ok, done
[09:46] <babbageclunk> menn0: did you manage to reproduce stokachu's problem?
[09:46] <babbageclunk> menn0: sorry, I mean, has anyone had a chance to reproduce it?
[09:47] <menn0> babbageclunk: nope. I gave stokachu a rebuild of 2.0-beta12 which definite had the patch applied.
[09:47] <babbageclunk> menn0: And does he see it with that?
[09:47] <menn0> babbageclunk: he was going to try it out and see if the problem happened with that as he's able to make it happen fairly reliably.
[09:48] <menn0> babbageclunk: I don't know. He never got back to me. I think it was quite late for him at the time.
[09:48] <menn0> babbageclunk: he was going to report back on the ticket but hasn't yet.
[09:48] <babbageclunk> menn0: Ok, cool - I had a go with a checkout of the right commit and the patch applied, but no luck yet - not sure which bundle to use.
[09:48] <menn0> babbageclunk:
[09:48] <menn0> babbageclunk: my goal was to establish whether or not the patch made it into the release or not
[09:49] <menn0> (and whether or not it worked)
[09:49] <menn0> babbageclunk: I imagine we'll hear back from stokachu when he starts work again
[09:49] <babbageclunk> menn0: Also not sure whether my laptop has enough oomph to cause the contention needed.
[09:50] <menn0> babbageclunk: it seems like there was some process failure when the official beta12 was produced so I'm not ruling out that the patch didn't actually make it into the release
[09:50] <babbageclunk> menn0: Yeah, it was a bit crazy.
[09:52] <menn0> babbageclunk: stokachu said he could make the problem happen quite often with just using add-model and destroy-model
[09:52] <menn0> I'm not sure how hard he was really pushing things
[09:53] <babbageclunk> menn0: Ok, I'll try that a few more times. The hadoop-spark-zeppelin bundle really squishes my machine. It's pretty cool.
[09:53] <menn0> babbageclunk: I guess you could try making the problem happen with a juju that's built without the patch
[09:54] <menn0> and when you have a reliable way of triggering the problem
[09:54] <menn0> rebuild with the patch and see if it goes away
[09:54] <babbageclunk> menn0: Well, I'm more concerned that the 5-retry thing just made it a bit less likely, but not really better.
[09:54] <menn0> or, you could hold off and do something else until we hear more from the QA peeps and stokachu
[09:55] <babbageclunk> menn0: I'll give it a couple more kicks and then get in touch with the US peeps.
[09:55] <menn0> you would think 5 would be enough...
[09:55] <babbageclunk> I would and did!
[09:55] <menn0> maybe a random short sleep between each loop would help?
[09:55] <menn0> ethernet style
[09:56] <babbageclunk> Yeah, could help - want to be sure it's happening first though.
[09:56] <menn0> for sure... need more info
[09:57] <babbageclunk> amusing - the test that was originally causing the problem in tests has been deleted.
[09:57] <babbageclunk> I mean, in our suite.
[09:58] <menn0> babbageclunk: for unrelated reasons?
[09:58] <babbageclunk> yeah, because address picking has been removed.
[10:01] <menn0> ha funny... still needs to be fixed of course
[10:01] <menn0> babbageclunk: I've got to go. I've got a literal mountain of washing to contend with.
[10:03] <babbageclunk> menn0: ok, thanks. Happy climbing!
[11:40] <mup> Bug #1604785 opened: repeatedly getting rsyslogd-2078 on node#0 /var/log/syslog <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1604785>
[11:40] <mup> Bug #1604787 opened: juju agents trying to log to <IP_ADDRESS>:6514 (virbr0 IP) <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1604787>
[11:51] <frankban> cherylj: hey morning, could you please merge trivial http://reviews.vapour.ws/r/5280/ ?
[11:55] <cherylj> frankban: sure
[11:55] <frankban> cherylj: ty!
[12:10] <mup> Bug #1598272 changed: LogStreamIntSuite.TestFullRequest sometimes fails <ci> <intermittent-failure> <test-failure> <juju-core:Fix Released by fwereade> <https://launchpad.net/bugs/1598272>
[12:20] <stokachu> babbageclunk: retrying to reproduce this morning, was late last night for me
[12:22] <perrito666> morning all
[12:44] <frankban> cherylj: how do I check what failed at /var/lib/jenkins/workspace/github-merge-juju/artifacts/trusty-err.log ?
[12:44] <frankban> cherylj: sorry, at http://juju-ci.vapour.ws:8080/job/github-merge-juju/8475/console
[12:45] <cherylj> frankban: I've pinged mgz to take a look.  I think it's a merge job failure
[12:45] <frankban> cherylj: ty
[12:46] <mup> Bug # changed: 1603596, 1604176, 1604408, 1604561, 1604644
[13:31] <perrito666> wallyworld: go to sleep?
[13:31] <wallyworld> ok, about that time
[13:31] <mup> Bug #1604817 opened: Race in github.com/juju/juju/featuretests <blocker> <ci> <intermittent-failure> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1604817>
[13:33] <natefinch> wallyworld: if you he 2 minutes, I'd love it if you could just read and maybe quickly respond to a couple review comments I have: http://reviews.vapour.ws/r/5238/
[13:34] <natefinch> s/he/have
[13:34] <wallyworld> ok
[13:36] <wallyworld> natefinch: done
[13:36] <natefinch> wallyworld: thanks
[13:37] <natefinch> hey, we're down to just two blocking tests in master, awesome
[13:37] <natefinch> (sorta)
[13:48] <babbageclunk> fwereade: ping?
[13:48] <frankban> cherylj: should I try merge again?
[13:49] <fwereade> babbageclunk, pong
[13:50] <fwereade> babbageclunk, what can I do for you?
[13:50] <babbageclunk> fwereade: I'm trying to understand the relationship between container and machine provisioners.
[13:50] <babbageclunk> fwereade: Sorry, environ provisioners
[13:51] <babbageclunk> fwereade: (looking at bug 1585878)
[13:51] <mup> Bug #1585878: Removing a container does not remove the underlying MAAS device representing the container unless the host is also removed. <2.0> <hours> <maas-provider> <network> <reliability> <juju-core:Triaged by 2-xtian> <https://launchpad.net/bugs/1585878>
[13:52] <fwereade> babbageclunk, at the heart of a provisioner there is a simple idea: watch the machines and StartInstance/StopInstance in response
[13:52] <fwereade> babbageclunk, I think that's called ProvisionerTask?
[13:53] <babbageclunk> fwereade: yup, and it's the same between the environ and container provisioners.
[13:53] <babbageclunk> fwereade: but with different brokers, I think.
[13:53] <fwereade> babbageclunk, yeah, exactly
[13:54] <babbageclunk> fwereade: So it looks like the environ provisioner explicitly excludes containers from the things it watches
[13:54] <fwereade> babbageclunk, ultimately we *should* be able to just start each of them with a broker, an api facade, and knowledge of what set of machines they should watch
[13:54] <fwereade> babbageclunk, yeah, that should be encapsulated in what it watches
[13:55] <fwereade> babbageclunk, I expect they actually make different watch calls or something, though? :(
[13:55] <babbageclunk> fwereade: Ok - in the maas case I need to tell maas the container's gone away after getting rid of it.
[13:55] <cherylj> frankban: yes, looks like one PR went through, so something's working...
[13:55] <cherylj> frankban: so I'd retry
[13:56] <frankban> cherylj: retrying
[13:56] <fwereade> babbageclunk, ha, ok, let me think
[13:56] <babbageclunk> fwereade: Until I started saying this, I thought that the container broker didn't talk to the environ, but now I think that's wrong - it needs to tell it when it starts, right?
[13:57] <fwereade> babbageclunk, I am confident that a container provisioner should *not* talk to the environ directly, because that would entail distributing environ creds to every machine
[13:58] <babbageclunk> fwereade: Ok, that makes sense. So in order to clean up the maas record of the container, the environ provisioner would also need to watch containers, right?
[13:59] <babbageclunk> I should trace the start path so I can see where maas gets told about the container.
[14:00] <fwereade> babbageclunk, I would be most inclined to have a separate instance-cleanup worker on the controllers, fed by provisioners leaving messages (directly or indirectly) on instance destruction
[14:00] <babbageclunk> fwereade: leaving messages how? Files?
[14:00] <fwereade> babbageclunk, db docs?
[14:00] <babbageclunk> fwereade: oh, duh
[14:00] <fwereade> babbageclunk, ;p
[14:01] <fwereade> babbageclunk, there is a general problem with having all-the-necessary-stuff set up before a provisioner sees a machine to try to deploy
[14:02] <babbageclunk> fwereade: ok, so the container provisioner creates a record indicating that it killed a container, and a controller-based worker watches those and does the environ-level cleanup.
[14:02] <fwereade> babbageclunk, trying to set up networks etc in the provisioner is wilful SRP violation -- but I think we do have a PrepareContainerNetworking (or something) call that the provisioner task makes
[14:03] <babbageclunk> fwereade: ok
[14:03] <fwereade> babbageclunk, yeah, I would be grateful if we would cast it in terms that applied to machines and containers both, and didn't distinguish between them except in the worker that actually handles them
[14:03] <babbageclunk> fwereade: so that's in the environ provisioner - it talks to the provider.
[14:04] <fwereade> babbageclunk, I don't think any provisioner should be responsible for doing this work, I think it should be a separate instance-cleanup worker
[14:04] <babbageclunk> fwereade: (oops, that was in response the prev)
[14:04] <fwereade> babbageclunk, yuck :)
[14:05] <babbageclunk> fwereade: Ok - so the provisioner task would just say "this instance needs cleaning"...
[14:05] <babbageclunk> fwereade: and then the new worker would see all of them and just do stuff for the containers for now.
[14:05] <fwereade> babbageclunk, so, really, *that* should be happening in an instance-preparer worker, which creates tokens watched by the appropriate provisioner, which can then only try to start instances that have all their deps ready
[14:06] <fwereade> babbageclunk, yeah, I think so
[14:06] <fwereade> (I refer, above, to the instance-prep work currently done by the provisioner, not to what you just said, which I agree with)
[14:06] <babbageclunk> fwereade: right, I was just going to check that.
[14:07] <babbageclunk> fwereade: sounds good, thanks!
[14:07] <fwereade> babbageclunk, note that there's an environ-tracker manifold available on environ manager machines already, it gets you a shared environ that's updated in the background, you don't need to dirty your worker up with those concerns
[14:08] <babbageclunk> fwereade: ok, I'll make sure to base my worker on that.
[14:10] <fwereade> babbageclunk, and it is called "environ-tracker", set up in agent/model.Manifolds
[14:10] <fwereade> babbageclunk, just use it as a dependency and focus the worker around the watch/response loop
[14:11] <fwereade> babbageclunk, you should then be able to just assume the environ's always up to date, and if you do race with a credential change or something it's nbd, just an error, fail out and let the mechanism bring you up to try again soon
[14:12] <babbageclunk> fwereade: ok
[14:12] <fwereade> babbageclunk, ...or, hmm. be careful about those errors, actually
[14:12] <fwereade> babbageclunk, we want those to be observable, I think
[14:13] <babbageclunk> fwereade: observable?
[14:13] <fwereade> babbageclunk, and we probably shouldn't mark the machine that used them dead until they've succeeded
[14:13] <fwereade> babbageclunk, report the error in status, I think, nothing should be competing for it by the time this is running
[14:14] <babbageclunk> fwereade: oh, gotch
[14:14] <babbageclunk> a
[14:14] <fwereade> babbageclunk, so, /sigh, this implies moving responsibility for set-machine-dead off the provisioner and onto the instance-cleaner
[14:14] <fwereade> babbageclunk, which is clearly architecturally sane, but a bit of a hassle
[14:15] <fwereade> babbageclunk, otherwise we'll be leaking resources and not having any entity against which to report the errors
[14:15] <fwereade> babbageclunk, sorry again: not set-machine-dead, but remove-machine
[14:15] <fwereade> babbageclunk, the machine agent sets itself dead to signal to the rest of the system that its resources should be cleaned up
[14:16] <babbageclunk> fwereade: ok
[14:16] <frankban> cherylj: looked at the tests and I've found that the failure is real for my branch. I have a fix already, but how do I check the tests that actually failed from the CI logs?
[14:16] <fwereade> babbageclunk, but we shouldn't *remove* it until both the instance (by the provisioner) and other associated resources (by instance-cleaner, maybe more in future) have been cleaned up
[14:17] <babbageclunk> fwereade: Yeah, that makes sense.
[14:17] <cherylj> frankban: go to your merge job:  http://juju-ci.vapour.ws:8080/job/github-merge-juju/8475/
[14:17] <cherylj> frankban: and click trusty-err.log
[14:17] <fwereade> babbageclunk, ...and ofc *that* now implies that we *will* potentially have workers competing for status writes
[14:17] <cherylj> frankban: argh, looks like it failed to run again
[14:17] <cherylj> balloons, sinzui - can you take a look:  http://juju-ci.vapour.ws:8080/job/github-merge-juju/8475/artifact/artifacts/trusty-err.log
[14:18] <fwereade> babbageclunk, so... it's not trivial, I'm afraid, but I can't think of any other things that'll interfere
[14:18] <frankban> cherylj: I am running 8477 now
[14:18] <frankban> cherylj: let's see if it will fail to run again, it should fail with 2 tests failures in theory
[14:19] <fwereade> babbageclunk, do you know what dimitern has been doing lately? I think he had semi-detailed plans for addressing the corresponding setup concerns but I'm not sure he started implementing them
[14:19] <cherylj> frankban: ah, well, when it completes you can view that trusty-err.log file for the test output
[14:19] <babbageclunk> fwereade: sorry, no - he's been away for the last week and a bit, not sure what he's working on at the moment.
[14:19] <frankban> cherylj: yes thank you, good to know
[14:19] <fwereade> babbageclunk, no worries
[14:20] <fwereade> babbageclunk, do sync up with him when he returns
[14:20] <babbageclunk> fwereade: hang on, why multiple workers competing to write status?
[14:20] <fwereade> babbageclunk, if the provisioner StopInstance fails that should report; if the instance-cleaner Whatever fails, that should also report
[14:21] <fwereade> babbageclunk, it might also be useful to look at what storageprovisioner has done
[14:21] <fwereade> babbageclunk, with the internal queue for delaying operations if they can't be done yet
[14:22] <babbageclunk> fwereade: Oh I see, so if both of them fail then an error in the provisioner might be hidden by one in the cleanup worker.
[14:22] <fwereade> babbageclunk, yeah, exactly
[14:23] <babbageclunk> fwereade: ok, that's heaps to go on with - I'll probably need more pointers once I'm a bit further along.
[14:23] <babbageclunk> fwereade: Thanks!
[14:23] <fwereade> babbageclunk, (nothing would be *lost*, because status-history, but it would be good to do better)
[14:23] <fwereade> babbageclunk, np
[14:23] <fwereade> babbageclunk, always a pleasure
[14:25] <mup> Bug #1604644 opened: juju2beta12: E11000 duplicate key error collection: juju.txns.stash <conjure> <mongodb> <juju-core:New> <https://launchpad.net/bugs/1604644>
[14:43] <sinzui> sorry cherylj: got pulled inot a meeting. Go is writing errors to stdout You can see the failure in http://juju-ci.vapour.ws:8080/job/github-merge-juju/8475/artifact/artifacts/trusty-out.log
[14:43] <sinzui> cherylj: I think we can create unified log so that the order of events and where to look are in a single place
[15:02] <rick_h_> katco: ping for standup
[15:02] <katco> rick_h_: oops omw
[16:16] <mup> Bug #1604883 opened: add us-west1 to gce regions in clouds via update-clouds <juju-core:New> <https://launchpad.net/bugs/1604883>
[16:25] <mup> Bug #1604883 changed: add us-west1 to gce regions in clouds via update-clouds <juju-core:New> <https://launchpad.net/bugs/1604883>
[16:34] <mup> Bug #1604883 opened: add us-west1 to gce regions in clouds via update-clouds <juju-core:New> <https://launchpad.net/bugs/1604883>
[16:41] <perrito666> anyone has spare time to review this http://reviews.vapour.ws/r/5282/diff/# ? its not a very short one, its part of a set of changes to support ControllerUser permissions, I am happy to discuss what this particular patch does if anyone goes for the rev
[16:45] <natefinch> rick_h_: I have a ship it for the interactive bootstrap stuff... should I push it through or wait for master to be unblocked?
[16:45] <rick_h_> natefinch: wait for master please atm
[16:46] <rick_h_> natefinch: just mark it as blocked on the card on master
[16:51] <natefinch> rick_h_: will do
[16:52] <rick_h_> natefinch: got a sec?
[16:52] <natefinch> rick_h_: yep
[16:52] <rick_h_> natefinch: https://hangouts.google.com/hangouts/_/canonical.com/rick?authuser=1
[16:58]  * rick_h_ goes for lunchables then
[17:37] <natefinch> god I love small unit tests
[17:38] <natefinch> I love that it tells me "you have an error in this 20 lines of code"
[18:49] <rick_h_> jcastro: marcoceppi arosales heads up docs switch is done and the jujucharms.com site is all 2.0 all the time https://jujucharms.com/docs
[18:49] <marcoceppi> rick_h_: yesssss
[18:50] <mup> Bug #1604915 opened: juju status message: "resolver loop error" <oil> <oil-2.0> <juju-core:New> <https://launchpad.net/bugs/1604915>
[18:50] <rick_h_> marcoceppi: will send an email shortly, want to check on status of b12 in xenial update to go along with it
[19:05] <mup> Bug #1604919 opened: juju-status stuck in pending on win2012hvr2 deployment <oil> <oil-2.0> <juju-core:New> <https://launchpad.net/bugs/1604919>
[19:06] <natefinch> rick_h_: output for interactive commands on stdout or stderr?
[19:07] <rick_h_> natefinch: so jam had some thoughts and added notes to the interactive spec on that
[19:07] <natefinch> rick_h_: ok, I was wondering who added that.  it was incomplete so I was hoping for clarification
[19:07]  * rick_h_ loads doc to double check
[19:08] <rick_h_> natefinch: ah, yea looks like he didn't finish typing
[19:08] <natefinch> rick_h_: I know the answer for non-interactive commands, but not sure if it should be different for interactive
[19:08] <natefinch> rick_h_: given that there's no real scriptable output
[19:09] <natefinch> (I mean, you can script anything, but it's not made with that in mind)
[19:09] <rick_h_> natefinch: can you ping him to clarify the rest, but the start is there as far as for interactive I think that's the idea that the questions/etc should go to stderr, but if we confirm things "successfully added X" it's stdout
[19:09] <natefinch> rick_h_: ok, yeah, I'll talk to him about it.
[19:09] <rick_h_> natefinch: ty
[19:15] <natefinch> oh man... writing this package to handle the formatting of user interactions was the best idea I ever had.
[19:16] <natefinch> ok, maybe not the best idea ever. But... it's certainly saving my ass.
[19:22] <rick_h_> natefinch: <3
[19:23] <alexisb> natefinch, so that begs the questions, what was your best idea ever
[19:24] <natefinch> alexisb: that's like the best set up for a joke I've ever had....
[19:25] <natefinch> alexisb: marrying my wife, obviously.  Only slightly behind would be the idea to switch from Mechanical Engineering to Computer Science in school.  Dodged a bullet there.
[19:26] <natefinch> I have a couple mech-e friends... they basically design screws all day long
[19:26] <alexisb> natefinch, yep
[19:27] <alexisb> I got to my first statics class, followed by drafting and went "o hell no!"
[19:28] <alexisb> I also had some time at Racor systems (Parker affiliate) and watched there engineers at a ProE screen all day
[19:28] <alexisb> no thank you
[19:28] <natefinch> yuuup
[19:29] <natefinch> I realized fairly early that I found physics fascinating in the abstract, but the reality of actually figuring shit out was mind-bogglingly boring.
[19:29] <alexisb> at racor, the acturally factory was AWESOME, which is where I started wtih control systems
[19:30] <perrito666> wanna do some boring mech things, try calculating elevators for a living
[19:30] <perrito666> most revealing class I ever had
[19:30] <natefinch> friend of mine makes maglev elevators for things like aircraft carriers.... still pretty boring work in the small
[19:31] <natefinch> he'd probably say the same for my job, though ;)
[19:31] <natefinch> "So... you twiddled with carriage returns all day?"
[19:32] <perrito666> lol "so, found that missing statement?"
[19:32] <mup> Bug #1604931 opened: juju2beta12: unable to destroy controller properly on localhost <conjure> <juju-core:New> <https://launchpad.net/bugs/1604931>
[19:32] <perrito666> but I was talking about builting elevators, I actually had to spend a semester calculating those
[19:38]  * rick_h_ runs to get the boy from school
[19:53] <arosales> rick_h_: great to hear thanks for the fyi
[20:30] <natefinch> are we supposed to be able to add-cloud for providers like ec2?
[20:31] <natefinch> it doesn't look like we're stopping people from doing that
[20:35] <mup> Bug #1604955 opened: TestUpdateStatusTicker can fail with timeout <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1604955>
[20:44] <mup> Bug #1604959 opened: Failed restore juju.txns.stash 'collection already exists' <backup-restore> <ci> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1604959>
[20:48] <natefinch> rick_h_: It's a little weird that clicking on "stable" in jujucharms brings you to the 2.0 docs, which say at the top, in red "Juju 2.0 is currently in beta which is updated frequently. We don’t recommend using it for production deployments."
[20:58] <natefinch> the problem with MAAS API URL is that it looks like I'm shouting, but really it's just TLA proliferation
[21:11] <mup> Bug #1604961 opened: TestWaitSSHRefreshAddresses can fail on windows <ci> <intermittent-failure> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1604961>
[21:11] <mup> Bug #1604965 opened: machine stays in pending state even though node has been marked failed deployment in MAAS <oil> <oil-2.0> <juju-core:New> <https://launchpad.net/bugs/1604965>
[21:17] <redir> you sure are
[21:19] <redir> ignore ^^
[21:25] <menn0> perrito666: ping
[21:26] <perrito666> menn0: ping
[21:27] <perrito666> sorry pong
[21:27] <perrito666> menn0: did I break something?
[21:28] <menn0> perrito666: no, I just wanted to apologise for not getting to your ACLs PR yesterday... the day got swallowed up by critical bugs
[21:28] <menn0> perrito666: I was about to review now and see that it's been discarded?
[21:29] <perrito666> menn0: oh, no worries, you would not have been able to review it yesterday anyway, it had a dependency on an unmerged branch and the diff was uncomprehensible, I droped it, merged the pending branch and re-proposed
[21:30] <perrito666> RB is really misleading, I thought that adding the dependency on the depends on field would fix the diff but did nothing at all and then it would not allow me to upload my own diff
[21:30] <perrito666> I think we should change RB for something a bit more useful, like snapchat
[21:30] <menn0> perrito666: LOL :)
[21:31] <menn0> perrito666: I've been wondering about Gerrit or Phabricator, they seem like the best alternatives
[21:31] <perrito666> I checked one of those during the sprint, and I liked it, I cant rememmber which one though, Phabricator I think
[21:32] <perrito666> menn0: also, the only person that knew something about our RB is no longer in this team which makes an interesting SPOF
[21:32] <menn0> perrito666: I don't think the ops side of RB is particularly hard
[21:32] <menn0> perrito666: and I *think* the details are written down /somewhere/
[21:33] <perrito666> menn0: I fear that the certain somewhere is an email :s
[21:33] <perrito666> anyway, eric usually knew the dark secrets like how to actually make a branch depend on
[21:33] <menn0> perrito666: phab is nice. I've used it a bit at one job. it support enforcing a fairly strict (but customized) development process..
[21:34] <menn0> perrito666: you do this: rbt post --disable-ssl-verification -r <review_number> --parent <parent_branch>
[21:34] <menn0> perrito666: and then check how it looks on the RB website and hit Publish
[21:35] <katco> menn0: perrito666: i've been interested in how this works out for teams: https://github.com/google/git-appraise
[21:35] <perrito666> menn0: ah, I need some non magic interaction :)
[21:35] <perrito666> menn0: if you ask me (and even if you dont) if it cant be done on the website, its broken
[21:36] <menn0> perrito666: I think you can upload arbitrary diffs to RB... but I've never done it
[21:36] <menn0> katco: looks interesting! I hadn't heard of git-appraise before
[21:36]  * menn0 reads more
[21:37] <katco> menn0: i enjoy the decentralized nature. no ops needed
[21:37] <katco> menn0: or at least i think i *would*. i've never used this
[21:37] <perrito666> menn0: well I actually tried, It seems to assume rb has something it doesnt, we might have broken that particular workflow with our magic bot
[21:39] <perrito666> katco: that looks amazing but seems to not work very nicely with github workflow (which we sort of use)
[21:39] <menn0> katco: storing the reviews in git is a nice idea. the way you add comments is a little unfriendly though. I guess the expectation is that someone will create a UI/tool for that.
[21:40] <katco> perrito666: just saw this: https://github.com/google/git-pull-request-mirror
[21:40] <katco> menn0: and just found this: https://github.com/google/git-appraise-web
[21:41] <redir> who's the resident data race expert?
[21:41] <perrito666> katco: mm, really interesting, do you know actual users of this, I am interested in seeing how it behaves in heavily conflictive envs
[21:41] <perrito666> redir: we all are good adding data races :p
[21:42] <redir> perrito666: OK who's the resident data race tortoise?
[21:42] <perrito666> redir: well, you are not in luck, its dave cheney :p
[21:42] <menn0> katco: that improves the situation somewhat! :)
[21:42] <perrito666> redir: just throw the problem to the field and well see how can we attack it
[21:43] <katco> perrito666: i do not. this looks fairly active? https://git-appraise-web.appspot.com/static/reviews.html#?repo=23824c029398
[21:43] <perrito666> man, was that english broken or what? ;p I am loosing my linguistic skills
[21:43] <redir> I think it is pretty straightforward
[21:46] <perrito666> katco: very interesting, I really like the idea of storage of these things In the repo
[21:46] <perrito666> but ill say something very shallow
[21:46] <redir> https://github.com/go-mgo/mgo/blob/v2/socket.go#L329 needs to be locked so it doesn't race with https://github.com/go-mgo/mgo/blob/v2/stats.go#L59
[21:46] <redir>  I think
[21:46] <perrito666> the UI is ugly as f***
[21:46] <redir> trouble reproducing
[21:46] <katco> perrito666: it is certainly spartan
[21:47] <katco> perrito666: personally, i would be writing an emacs plugin for this if someone hasn't already
[21:48] <katco> redir: why are stats being reset before kill has been returned? i think there's a logic bomb there
[21:49] <perrito666> I dont know what kind of spartans you know, the ones from the movie certainly look better than that UI :p
[21:49] <katco> perrito666: sorry, i intended this usage: "adj.	Simple, frugal, or austere: a Spartan diet; a spartan lifestyle."
[21:51] <perrito666> katco: I know, I intended to : " troll (/ˈtroʊl/, /ˈtrɒl/) is a person who sows discord on the Internet by starting arguments or upsetting people,"
[21:51] <katco> lol
[21:52] <perrito666> redir: while killing, imho you should be locking everything indeed, but I have not checked past these two links to know if I am speaking the thruth about this particular issue
[21:53] <perrito666> katco: I do dislike the ui though, I prefer something like github without the insane one mail per comment thing
[21:55] <katco> redir: also i don't think that's the race. socketsAlive locks the mutex before doing anything: https://github.com/go-mgo/mgo/blob/v2/stats.go#L135
[21:56] <redir> mkay thanks
[21:56] <redir> perrito666: katco ^
[21:59] <perrito666> moving to a silent neigbourhood is glorious for work
[22:05] <mup> Bug #1604988 opened: Inconsistent licence in github.com/juju/utils/series <jujuqa> <packaging> <juju-core:Triaged> <juju-core 1.25:Triaged> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1604988>
[22:43] <menn0> katco: you're convincing me that we should experiement with vendoring some more :)
[22:43] <katco> menn0: eep...
[22:43] <katco> menn0: as long as how go does vendoring is well understood, i'm happy. i am scared of diverging too much without forethought
[22:44] <menn0> katco: sure... it's not something we should do lightly. and if do it, it should use Go's standard mechanism.
[22:44] <perrito666> menn0: re our previous talk http://reviews.vapour.ws/r/5282/diff/#
[22:45] <katco> menn0: yeah, agreed
[22:48] <menn0> perrito666: ok. I can take a look.
[22:49] <menn0> perrito666: my initial comment is that I wish this was 2 PRs: one for state and one for apiserver (but I will cope)
[22:50] <perrito666> menn0: I am sorry I promise I tried to make it smaller
[22:51] <perrito666> menn0: its smaller than it looks though, small changes in many files
[22:52] <katco> menn0: i think i messed up the tech board permissions. i was trying to get a link and it looked publicly accessible, so i disabled that. now i can't view it
[22:53] <menn0> katco: I'll take a look
[22:53] <katco> menn0: sorry about that
[22:53] <menn0> katco: you completely removed canonical access :) not sure how to put it back yet
[22:54] <mup> Bug #1605008 opened: juju2beta12 and maas2rc2:  juju status shows 'failed deployment' for node that was 'deployed' in maas <oil> <oil-2.0> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1605008>
[22:54] <katco> menn0: wait what! all i did was turn off link sharing :(
[22:54] <menn0> katco: figured it out. what was it before? anyone at canonical can edit or view?
[22:55] <menn0> or comment?
[22:55] <katco> menn0: could comment i think, but it looked like external people with link could view as well
[22:56] <menn0> katco: ok, it's fixed. anyone from canonical can comment again.
[22:56] <katco> menn0: ta, sorry
[22:57] <axw> wallyworld: did I miss anything on the call? slept through my alarm supposedly, pretty sure it didn't go off though
[22:57] <axw> need to ditch this dodgy phone
[22:58] <perrito666> axw: or get a clock
[22:58] <wallyworld> axw: not a great deal, just release recap, tech board summary
[22:58] <axw> perrito666: could do that too, I'd rather have it near my head so I don't wake up my wife
[22:58] <axw> suppose I could move the clock...
[22:58] <perrito666> axw: get a deaf people clock
[22:58] <axw> wallyworld: ok, ta
[22:58] <perrito666> (not trolling, these are a thing)
[22:59] <axw> perrito666: ah, have not seen one
[22:59] <perrito666> they have a thing that you put in your pillow and it vibrates
[22:59] <perrito666> much like your phone, but less points of failure
[22:59] <axw> I guess I could just use my fitbit then. if I can find it, and my charger...
[23:00] <mup> Bug #1605008 changed: juju2beta12 and maas2rc2:  juju status shows 'failed deployment' for node that was 'deployed' in maas <oil> <oil-2.0> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1605008>
[23:00] <axw> anyway
[23:00]  * axw stops debugging alarm replacement issues
[23:06] <mup> Bug #1605008 opened: juju2beta12 and maas2rc2:  juju status shows 'failed deployment' for node that was 'deployed' in maas <oil> <oil-2.0> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1605008>
[23:18] <alexisb> axw, thumper ping
[23:18] <axw> coming, sorry
[23:18] <thumper> coming
[23:49] <redir> axw: thanks for the protip in the review. helpful
[23:49] <axw> redir: np
[23:57] <thumper> menn0: so you are working with redir on the race?


[00:56] <Hobbsee> kiko: i didn't know you were into hosting ubuntu bots
[02:20] <kiko> Hobbsee, the things we do..
[02:23] <Hobbsee> kiko: heh, true.  so if there's more hosting, we should send them to you?
[02:24] <kiko> Hobbsee, if it's not going to chew up all my bandwidth, sure
[02:24] <Hobbsee> right
[02:24] <kiko> more seriously, It Depends
[02:24] <Hobbsee> yeah, true.  on what though?
[02:25] <kiko-zzz> what it's for and what it requires
[02:25] <kiko-zzz> ask me more tomorrow when I'm actually awake
[02:25] <kiko-zzz> zzz
[02:25] <Hobbsee> right
[02:25] <kiko-zzz> ;)
[08:14] <mdke> jtv: would you be able to take care of my request on -users to approve the templates and po files for ubuntu/hardy/gnome-user-docs?
[08:14] <mdke> danilo_: ^?
[08:17] <danilo_> mdke: approved
[08:17] <mdke> danilo_: yay thanks.
[08:17] <mdke> danilos: will the po files be imported too?
[08:17] <mdke> (it's the ones from version 2.22.0+svn20080310ubuntu2 I need)
[08:17] <danilos> mdke: they should be automatically approved in the next hour or so (when the auto-approval script hits them)
[08:18] <mdke> brilliant, thanks
[08:19] <danilos> mdke: if it doesn't happen in the next few hours, it's probably because of gnome-doc-utils "de/de.po" paths, so just ping me and we'll work it out
[08:26] <mdke> danilos: ok, I will check and get in touch by email...
[09:06] <ubotu> New bug: #203260 in launchpad-bazaar "Ability to hide 'Code' tab, or replace with alternate information" [Medium,Confirmed] https://launchpad.net/bugs/203260
[09:06] <ubotu> New bug: #203478 in blueprint "Meeting attendees shouldn't be sorted by Launchpad ID" [Undecided,New] https://launchpad.net/bugs/203478
[10:19] <metric> Anyone know what launchpad's source code is based on?  Plone?
[10:19] <Fujitsu> metric: It's Zope 3.
[10:19] <metric> cool. thanks
[11:06] <ubotu> New bug: #195514 in apport "apport doesn't say what extra information it includes in the report" [Wishlist,Confirmed] https://launchpad.net/bugs/195514
[12:32] <ubotu> New bug: #203520 in launchpad "Got translation import finished email, but translation is not imported" [Undecided,New] https://launchpad.net/bugs/203520
[13:36] <ubotu> New bug: #203546 in malone/1.2 "Forward Bugs Upstream to an Email Address: Obfuscate email addresses" [Undecided,New] https://launchpad.net/bugs/203546
[14:20] <ubotu> New bug: #203555 in malone/1.2 "Implement getting status of bugs from Bugzilla instances having the Launchpad plugin installed" [Undecided,New] https://launchpad.net/bugs/203555
[14:20] <ubotu> New bug: #203558 in malone/1.2 "Add 'remote_id' to BugMessage" [Undecided,New] https://launchpad.net/bugs/203558
[14:22] <ubotu> New bug: #203553 in malone "Allow multiple ExternalBugTrackers for a single bug tracker type" [Undecided,New] https://launchpad.net/bugs/203553
[14:26] <ubotu> New bug: #203559 in malone/1.2 "Only update modified bugs for Bugzilla trackers having the Launchpad plugin installed" [Undecided,New] https://launchpad.net/bugs/203559
[14:26] <ubotu> New bug: #203560 in malone/1.2 "Get the current time of bugzilla instances having the Launchpad plugin installed" [Undecided,New] https://launchpad.net/bugs/203560
[14:26] <ubotu> New bug: #203562 in launchpad "Project announcement headlines should be links" [Undecided,New] https://launchpad.net/bugs/203562
[14:30] <d_rol> Hello. I am interested in a project whose maintainer's address is no more valid. Could someone here help me ?
[14:31] <ubotu> New bug: #203564 in malone/1.2 "Implement getting status of bugs from Trac instances having the Launchpad plugin installed" [Undecided,New] https://launchpad.net/bugs/203564
[14:36] <ubotu> New bug: #203566 in malone/1.2 "Only update modified bugs for Trac instances having the Launchpad plugin installed" [Undecided,New] https://launchpad.net/bugs/203566
[14:36] <ubotu> New bug: #203567 in malone/1.2 "Get the current time of Trac instances having the Launchpad plugin installed" [Undecided,New] https://launchpad.net/bugs/203567
[15:00] <ubotu> New bug: #203575 in malone/1.2 "Forward Bugs Upstream to an Email Address: Handle email addresses correctly when changing bug tracker details" [High,In progress] https://launchpad.net/bugs/203575
[15:21] <ubotu> New bug: #203585 in malone "add "No Tag Applied" to the tag list on bugs" [Undecided,New] https://launchpad.net/bugs/203585
[16:20] <ubotu> New bug: #202447 in hwtest "Translation template unavailable, even though hwtest is in main" [Undecided,Confirmed] https://launchpad.net/bugs/202447
[17:03]  * gmb -> dinner; bbl
[18:25] <ubotu> New bug: #203651 in malone/1.2 "Forward Bugs Upstream to an Email Address: Allow status and importance to be changed on bugtasks" [Undecided,New] https://launchpad.net/bugs/203651
[18:30] <jsk> evening all
[18:31] <ubotu> New bug: #203652 in malone/1.2 "Forward Bugs Upstream to an Email Address: UI niceties" [Undecided,New] https://launchpad.net/bugs/203652
[18:39] <jsk> launchpad seems nice and fast these days.
[18:40] <jsk> :)
[18:56] <fliegenderfrosch> very basic question: i've just started to use a vcs. i've uploaded a branch of my software-project to launchpad. can i now just change the files, use "bzr commit" and update the branch on launchpad with "bzr push"?
[18:57] <kiko> yes
[18:59] <fliegenderfrosch> kiko, thx
[18:59] <kiko> it's that easy!
[19:19] <TeTeT> is there a way to get a list of all bugs for a certain project? No matter which state they are in
[19:21] <LaserJock> TeTeT: you can use an advanced search
[19:21] <kiko> TeTeT, what LaserJock said -- just click
[19:24] <TeTeT> any way to do it by a script?
[19:25] <LaserJock> TeTeT: once you have the URL you can just wget/curl the URL
[19:48] <TeTeT> kiko: the bughelper app contains a bugnumbers script that can get all bugs in a project, very nice
[19:53] <kiko> TeTeT, yeah, though if you tell me what you're trying to do there may be a better way
[19:54] <TeTeT> kiko: I need to transfer some stats from our engineering projects tracked in LP to our CRM
[19:55] <kiko> TeTeT, what sort of stats?
[19:56] <TeTeT> kiko: open bugs, closed bugs for now
[19:57] <kiko> TeTeT, counts or analytical?
[19:57] <TeTeT> kiko: only counts, keep it simple
[20:01] <kiko> TeTeT, well, for now using bughelper might be your safest bet
[20:11] <kiko> hey Seveas
[20:11] <Seveas> heu kiko
[20:11] <kiko> what's the story?
[20:11] <Seveas> story?
[20:11] <kiko> you know the song
[20:11] <kiko> Seveas, it seems my destiny leads me to discuss IRC bots with you this fine tuesday.
[20:20] <kiko> bac, ping?
[20:20] <bac> kiko: hi
[20:21] <kiko> bac, question for you.
[20:21] <kiko> bac, load http://feeds.edge.launchpad.net/~ubuntu-bugs/latest-bugs.atom
[20:21] <bac> shoot
[20:21] <kiko> bac, and tell me what you see.
[20:22] <Fujitsu> I have but one gripe with that feed (which I've been using for ages)... the milestone icons for distro tasks.
[20:22] <bac> kiko: i see 25 bugs...none of which appear to be for ubuntu-bugs
[20:24] <kiko> bac, not just that. they are ordered in some paradoxical way :)
[20:24] <bac> in my feed reader they are ordered how i tell it to order them
[20:25] <bac> kiko:  ordering is up to the reader
[20:26] <Fujitsu> That's the correct list of bugs, isn't it?
[20:26] <Fujitsu> Just the wrong end of it.
[20:26] <bac> kiko: ah, but your complaining about the set of 25 returned.  now there's a good point
[20:26] <kiko> bac, well, I mean to say that the feed is displaying what appears to be the N first bugs. right :)
[20:26] <bac> yes, for some back-assward definition of 'latest'
[20:27] <bac> :(
[20:28] <kiko> bac, heh, should be an easy fix :)
[20:28] <bac> kiko:  yeah, i'll see what i can do about that
[21:13] <No`> hi all
[21:26] <d_rol> Hello, is there a launchpad admin in the room ?
[21:26] <No`> I've applied to join the LP-beta-tester team on 2008-03-12, and I see that my membership is still pending (along with dozens of others)
[21:27] <No`> the issue is that I do need this membership to use the launchpad mailing-list feature
[21:28] <No`> anyone would like to help?
[21:28] <mpt> Gooooooooooooooooood morning Launchpadders!
[21:28] <d_rol> er. good evening actually :)
[21:30] <No`> good "universal standard time" everyone
[23:21] <ubotu> New bug: #203753 in launchpad "it does not allow me to run the updates. It blocks the database and tells me there is another program running this" [Undecided,New] https://launchpad.net/bugs/203753