[00:05] <jono> paultag, any chance you could add those feeds now?
[00:05] <jono> just ready for the global jam :-)
[00:07] <paultag> jono: I'll do it by EOD, but I'm a bit swamped atm
[00:07] <jono> paultag, thanks, pal!
[00:07] <paultag> sure thing
[00:15]  * jono wraps up the membership survey report
[00:15] <jcastro> HEY PAULTAG
[00:16] <paultag> jcastro: HEY GEORGE
[00:16] <jcastro> man the AMA ended up being pretty awesome
[00:17] <paultag> jcastro: :)
[00:17] <paultag> mhall119: How smart is the LD planet?
[00:18] <paultag> mhall119: I was just pulling up links in the background, and ubuntu-ca looks to have randal's feed in it - if I add randal's feed, it'll bork, yes?
[00:18] <mhall119> not very
[00:18] <mhall119> if by "bork" you mean "display duplicates", then maybe
[00:18] <paultag> mhall119: so it'd be sane to reject randal's for reason that it's included indirectly?
[00:20] <mhall119> I would think so, yeah
[00:20] <paultag> mhall119: ok, thanks
[00:20] <jcastro> "Any plans to make Unity more themeable? That's my biggest gripe with it right now, and I'm sure a lot of users feel the same."
[00:20] <mhall119> I mean, I could have it check for duplicate uid, but there's no gurantee that 2 distinct blogs won't use the same uid
[00:20] <jcastro> he should just set a wallpaper
[00:21] <paultag> jcastro: can I quote that ;)
[00:21] <jono> jcastro, hey
[00:21] <mhall119> I hear that gripe a lot, but really, I don't *see* unity 95% of the time, wasn't that the whole point of it?
[00:21] <paultag> mhall119: yeah. I'm not so sure that's something we should care about
[00:21] <jono> jcastro, want to hear something that will make you kill yourself?
[00:21] <jono> jcastro, http://www.noisecreep.com/2011/09/02/axel-rudi-pell-holy-diver-song/
[00:21] <jcastro> mhall119: well, if you like red corvettes let's say, and you set a red corvette wallpaper, your unity will look .... wait for it ..... red.
[00:21] <jcastro> jono: looking
[00:22] <mhall119> jcastro: what happens if you put a screenshot of Unity as your wallpaper?
[00:22] <jcastro> jono: one of those nu metal bands does a dio cover that makes me want to kill myself
[00:22] <jcastro> mhall119: don't do that. space/time continum, etc.
[00:22] <jcastro> jono: man dude, this is pretty awesome
[00:22] <jcastro> (being serious)
[00:22] <mhall119> yeah, I found that out about 2 hours from now
[00:23] <jcastro> jono: I envision when I get old, sitting in Vegas with some lounge singer singing this.
[00:23] <jcastro> wondering what happened to my life, etc.
[00:23] <jcastro> like that Nicholas Cage movie
[00:23] <jcastro> jono: guess what I heard on the radio today
[00:24] <jcastro> Mercyful Fate!
[00:24] <jcastro> it came on and I looked at Jill and was like "wait until you hear this guy's voice."
[00:24] <jcastro> then it hit her like a ton of bricks, lol
[00:24] <jcastro> hmm, I wonder if they have a best of CD.
[00:25] <jcastro> I can see myself getting that, but nothing more than just that.
[00:25] <jono> jcastro, we can't be friends anymore
[00:25] <jono> jcastro, it is not a patch on this monstrosity - http://www.youtube.com/watch?v=c15yM77xkP4
[00:26] <jcastro> ok this one's a bit too much
[00:26] <jono> a bit?
[00:26] <jono> I punched a hole in my monitor
[00:26] <jono> lo
[00:26] <jono> lol
[00:26] <jcastro> oh god
[00:26] <jcastro> is that a guitar?
[00:26] <jcastro> it sounds like they want to be NIN
[00:27] <jcastro> wow, this is horrible
[00:27] <jono> http://www.youtube.com/watch?v=qpl5mOAXNl4
[00:27] <jcastro> oh yes, found it
[00:27] <jcastro> mercyful fate does have a best of
[00:29] <jcastro> don't touch! never ever steal!
[00:29] <jcastro> unless, you're in for the kill!
[00:29] <jcastro> you've been caught, by the curse of the pharoah oh ....
[00:29] <jcastro> chugga chugga
[00:33] <mhall119> choo choo
[00:35] <jcastro> hmm, King Diamond also has a "Best of" Album.
[00:35] <jcastro> Come on, really dude. You have like 2 good songs, tops.
[00:37] <paultag> jono: mhall119: feeds done. I just did them over a snack. https://wiki.ubuntu.com/LoCoPortalFeeds#preview <- there's a report in the added column in what was done
[00:37] <paultag> All were approved except Randal's, since it's there via CA
[00:41] <jcastro> ugh, I hate impulse music buys, I already want to strangle this guy
[00:41] <jcastro> jono: you should have interveened
[00:41] <jcastro> hmm, at least the rest of the band knows how to jam
[00:44] <paultag> hunh, it works.
[00:44] <paultag> clever
[00:44] <jcastro> good, I hate that guy
[00:44] <paultag> >:)
[00:49] <paultag> $ ping dev.darkshed.net -c 1 | grep PING | awk '{print $3}'
[00:49] <paultag> (<IP_ADDRESS>)
[00:49] <paultag> $ ping fluxbox.org -c 1 | grep PING | awk '{print $3}'
[00:49] <paultag> (<IP_ADDRESS>)
[00:49] <paultag> muhahaha
[00:58] <mhall119> thanks paultag
[01:00] <paultag> mhall119: yep
[01:01] <paultag> back to fighting the never-ending battle for better softwar
[01:01] <paultag> e
[01:13] <akgraner> jono does Canonical have training aides for teaching Ubuntu.  I've been asked to teach a class of 9th graders Ubuntu.  I was hoping to find a curriculum that just needs to be updated.  If you don't know could you point me in the right direction? Please and thank you!
[01:15] <jono> akgraner, nope, nothing like that exists afaik
[01:15] <akgraner> I've already ordered the official Ubuntu book for all the students, but I know I'm going to need a more formal outline to present to the school...
[01:15] <jono> akgraner, maybe ask Ubuntu Youth
[01:15] <jono> would be awesome if you developed such a course
[01:16] <akgraner> well I'm going to have to :-)  so I'll share it with everyone and let people add to it  - if this goes well the whole school may migrate :-)
[01:16] <mhall119> akgraner: ask the Edubuntu team too, they might have something
[01:17] <akgraner> mhall119, that's true - I'll hunt dinda down too :-)
[01:17] <paultag> jono: akgraner: there was an ubuntu community learning project (UCLP) that had such materials IIRC
[01:17] <paultag> akgraner: might want to ask pleia2 or doctormo about it
[01:17] <paultag> this was before that team exploded
[01:19] <akgraner> Thanks y'all I'll explore all these options :-)  I only have 4 weeks to come up with this so I'll be hustling :-) b/c of course I said, "No problem,  can teach them!"
[01:19] <mhall119> akgraner: you can't just tell them to figure it out themselves?
[01:19] <akgraner> um not if I want a paycheck from them :-)
[01:20] <mhall119> oh, you're getting paid for this?
[01:20] <mhall119> nice
[01:20] <akgraner> yeppers :-)
[01:20] <akgraner> I don't turn down money...
[01:20] <mhall119> good career advice
[01:21] <akgraner> While I may give it away and share it  - I'll take it gladly :-)
[01:21] <mhall119> I can just imagine your brain: "You mean there will be a captive audience I can tell about the wonders of Ubuntu *and* I'll get paid to do it?!?!"
[01:21] <akgraner> oh heck yeah :-) that's exactly what I thought
[01:23] <akgraner> and none of this would have happened if I hadn't broken my knee - my physical therapist started asking me about Ubuntu.  Then I gave him the official book and a subscription to Ubuntu User.  He went to the PTA and School Officials and pitched the plan to try it with one grade and BAM the rest will hopefully be history...
[01:24] <akgraner> See it does pay to talk to everyone who will listen about Ubuntu :-)
[02:03] <cjohnston> jono, mhall119 paultag et al... I don't know about mhall119, but I would prefer that, since access was given to the LC, that the LC be responsible for adding/checking blogs, (or you jono since you also have access). If there is a problem with adding a blog feel free to ask for assistance.. other than that, I'd personally rather not be responsible for that part.
[02:06] <paultag> cjohnston: keep reading backlog
[02:08] <cjohnston> I know that mhall119 said that he wanted the loco council to make the decisions.. im mostly saying that I'd rather that the LC make decisions and add, which I don't see, but could have missed him mentioning about adding them as well
[02:09] <paultag> cjohnston: dude, I don't want to keep repeating conversations - I did it, I don't think anyone left with the impression that ya'll are managing it
[02:09] <paultag> cjohnston: I'm busy
[02:09] <paultag> cjohnston: we can chat later, there's no issue
[02:09] <cjohnston> ok
[02:25] <pleia2> akgraner: ubuntu learning is a bit defunct, but only because I don't have volunteers to help write course materials (doctormo has written 5 sysadmin classes that he was teaching up near boston for a while)
[02:25] <pleia2> we're still over in #ubuntu-learning though
[02:27] <akgraner> pleia2, I have 5 people now wanting to help - one person was a college level teacher for 20 years :-)  so I'll share the googledoc link with you and anyone who wants to help is welcome to :-)  I'll start on this on Monday as I need to finish a million other things between now and Sunday :-)
[02:27] <pleia2> akgraner: awesome, darkwingduck joined recently too so we'll see
[02:27] <akgraner> sweet!
[02:27] <pleia2> I'm at an airport now so we can touch base tuesday :)
[02:28] <akgraner> :-)  thank you!
[02:28]  * pleia2 finally using her fancy lounge pass!
[02:28] <akgraner> great!  have a great weekend! and don't worry about UWN we'll take care of it...no stress for you this weekend :-P
[02:28] <pleia2> thanks :)
[03:19] <akgraner> Ok who wants to teach me how to start a project in LP :-)  That should be a good Global Jam event  -teaching akgraner to use LP for more that filing bugs and joining teams...I think if I ask pgraner their may be a fight :-)  I'll see if I can figure it out on Sunday but if I get stuck I'm pinging y'all  - consider this your warning :-)
[03:19] <akgraner> s/their/there
[06:05] <czajkowski> morning
[13:41] <czajkowski> aloha
[13:50] <akgraner> czajkowski, morning/afternoon :-)
[13:51] <czajkowski> :)
[13:51] <czajkowski> hi
[13:59] <akgraner> time for me to head to our global jam - check back in with y'all soon :-)
[14:37] <jussi> 35C.... WHY??????? :(
[14:45] <akgraner> anyone else running oneiric can you check to see if checkbox/system testing will work for you - I can't get it to run for me using oneiric
[14:46] <czajkowski> akgraner: where do I run it
[14:46] <akgraner> pgraner's filing the bug since he can't get it to run either as I am still packing to take stuff to our global jam venue
[14:46] <czajkowski> having issues with getting U1 to run
[14:46] <czajkowski> cant launch gwibber
[14:46] <akgraner> czajkowski, go to the dash and type "system testing"
[14:47] <akgraner> you should see the icon show up click on it and see if it opens up for you
[14:47] <akgraner> Thank you!
[14:47] <akgraner> I am set to demo this in about an hour - and it looks like I will have to fall back to Natty
[14:48] <akgraner> here's the bug number if you can't get to work for you either -  840376
[14:49] <akgraner> yeah there's a lot of broken stuff in the beta I am finding  - I think I likes the alpha better :-/
[14:50] <akgraner> well I gotta run thanks czajkowski for trying it - I have an hour to drive to the venue...more later
[14:51] <czajkowski>  ant get it to run
[14:51] <czajkowski> *cant
[14:52] <czajkowski> alt f2  and typing it there causes machine to lock up
[14:52] <akgraner> czajkowski, thanks - yep it's borked - can you me to that bug number please...
[14:54] <czajkowski> which bug number ?
[14:54] <czajkowski> bug #840376
[14:54] <ubot2`> Launchpad bug 840376 in checkbox "System Testing (aka checkbox-gtk) fails to run" [Undecided,New] https://launchpad.net/bugs/840376
[15:50] <nigelb> AlanBell: ara blogged about something related to that.
[15:50] <nigelb> err
[15:50] <nigelb> akgraner: ^
[17:08] <paultag> akgraner: hey, you jamming?
[17:09] <paultag> akgraner: I need you to do something if you are
[17:09] <paultag> akgraner: and like nowish
[17:10] <paultag> :)
[17:11] <paultag> akgraner: if you're at the NC jam, can you stand up and ask for "John Riselvato". He worked on a few of my projects in the past, and I would love it if you could give him a (over the top) welcome
[17:11] <paultag> akgraner: get him to stand up and wave and all that other humiliating crud
[18:47]  * AlanBell looks forward to meeting openiduser560 at http://loco.ubuntu.com/events/ubuntu-uk/1257/detail/
[18:49] <czajkowski> akgraner: why ?
[19:38]  * popey waves to everyone
[23:56] <akgraner> paultag, sorry - I wasn't looking at IRC during the jam
[23:56] <akgraner> :-(
[23:58] <akgraner> It all worked out - I just showed everyone how to get to system testing (no one but me and Pete and one other person were running oneiric) and I showed them the  mock-ups and gave them the overview and asked them to join the UF LP team and maiing list and send in feedback
[23:59] <akgraner> then I just showed everyone what Beta 1 was looking like and highlighted the coolness of the software center :-)  it was fun..


[00:00] <half_mast> can anyone tell me how to take a screenshot of ubuntu touch
[00:01] <nhaines> half_mast: connect your device to your computer via USB and run 'phablet-screenshot'
[00:05] <half_mast> nhaines: Thank you that worked perfectly.
[00:06] <nhaines> half_mast: great!  :D
[00:08] <x_root> hello, is possible to use 3/4 fingers support in ubuntu 14.04?
[00:09] <x_root> i have a multi touch touchpad which used to work fine on windows with synaptic driver.. (but the synaptic functions to it was.. very useless... =/)
[00:09] <x_root> think if i could try it in ubuntu since is my main since 12.10
[01:08] <cwayne> jdstrand: still not working confined with 1.2.20 :/
[01:08] <cwayne> and getting this: syslog:Aug 16 01:07:19 ubuntu-phablet kernel: [  592.255080] (0)[9198:com.canonical.s]type=1400 audit(1408151239.937:198): apparmor="DENIED" operation="mkdir" profile="com.canonical.scopes.flickr_flickr_1.0.10" name="/home/phablet/.local/share/unity-scopes/leaf-net/com.canonical.scopes.flickr_flickr/" pid=9198 comm="com.canonical.s" requested_mask="c" denied_mask="c" fsuid=32011 ouid=32011
[01:16] <x_root> cwayne,
[01:16] <x_root> [21:08:26] <x_root> hello, is possible to use 3/4 fingers support in ubuntu 14.04?
[01:16] <x_root> [21:09:03] * jjohansen saiu (Ping timeout: 245 seconds)
[01:16] <x_root> [21:09:24] <x_root> i have a multi touch touchpad which used to work fine on windows with synaptic driver.. (but the synaptic functions to it was.. very useless... =/)
[01:16] <x_root> [21:09:45] <x_root> think if i could try it in ubuntu since is my main since 12.10
[01:16] <x_root> know something about it?
[01:20] <cwayne> nope
[01:50] <x_root> cwayne, just saw.. thanks anyway :)
[02:53] <josef_pauli> http://www.frys.com/product/8086774?site=sa:adpages%20page:P40_FRI%20date:081514 <-- Fry's wants me to buy a Lenovo A8 Tablet, Android 4.2
[02:53] <josef_pauli> ... if this were a popular target for ubuntu, I'd read a page or few of guidance
[02:53] <josef_pauli> ... if a few here think that this were an interesting intall, I'd get one, & try to let y'all help me
[02:54] <josef_pauli> s/intall/install/ <-- I blame mine aging netbook, and not my still-nimble fingers
[02:55] <josef_pauli> http://www.frys.com/product/8086774?site=sa:adpages%20page:P40_FRI%20date:081514 <-- Fry's wants me to buy a Lenovo A8 Tablet, Android 4.2
[02:55] <josef_pauli> ... if this were a popular target for ubuntu, I'd read a page or few of guidance
[02:55] <josef_pauli> ... if a few here think that this were an interesting intall, I'd get one, & try to let y'all help me
[02:55] <josef_pauli> o.k... I blame my clumsy fingers
[03:17] <jdstrand> cwayne: that is a known bug with the scopes. needs an update to the scopes api
[03:18] <jdstrand> cwayne: I can't find the bug, but pete-woods is working on it
[03:38] <lotuspsychje> http://www.omgubuntu.co.uk/2014/08/ubuntu-home-screen-scope-gesture
[03:38] <lotuspsychje> nice work guys!
[10:09] <aha_> Hello all. Q: Can I buy a phone with ubuntu-touch, or must I still wait for it?
[11:38] <cwayne> jdstrand: hm, i wonder if that's even causing the failure im seeing then.  i can get the nearby (no auth needed) department of the scope working, but as soon as i go to a department that needs auth, it fails
[15:43] <ostree> is this outdated https://wiki.ubuntu.com/Touch/Porting ?
[15:44] <ostree> and this https://wiki.ubuntu.com/Touch/AndroidDevel ?
[15:46] <ostree> ..inconsistent and misleading at least
[16:52] <cousteau> does Touch use the default Android keyboard?  are there efforts being made into making your own keyboard?  Because I have some ideas.
[17:05] <cwayne_> whatre the proper dimensions for a click apps icon?
[17:19] <dobey> cwayne_: 256x256 px
[17:19] <cwayne_> dobey, thanks
[17:19] <dobey> cwayne_: no transparency. fill the entire square with content
[17:21] <gambit2552> Hello is Ubuntu Touch available for the HTC Desire 601 yet?
[17:24] <ostree> gambit2552, https://wiki.ubuntu.com/Touch/Devices


[13:18] <Hobbsee> darn, clark fell over a copule of months ago, it looks like
[13:18]  * Hobbsee wonders how long ago they were set
[13:19] <jpatrick> *!*@gateway/tor/*!#ubuntu-ops -> opps, should be -proxy-users
[13:20] <jpatrick> yay!
[13:20] <Hobbsee> rotten chanserv.  it hates me.


[01:06] -queuebot:#ubuntu-release- New binary: haskell-http-link-header [amd64] (artful-proposed/universe) [1.0.3-2] (no packageset)
[01:06] -queuebot:#ubuntu-release- New binary: haskell-http-link-header [ppc64el] (artful-proposed/universe) [1.0.3-2] (no packageset)
[01:06] -queuebot:#ubuntu-release- New binary: haskell-http-link-header [i386] (artful-proposed/universe) [1.0.3-2] (no packageset)
[01:09] -queuebot:#ubuntu-release- New binary: haskell-http-link-header [arm64] (artful-proposed/universe) [1.0.3-2] (no packageset)
[03:29] -queuebot:#ubuntu-release- New: accepted haskell-http-link-header [arm64] (artful-proposed) [1.0.3-2]
[03:29] -queuebot:#ubuntu-release- New: accepted haskell-http-link-header [ppc64el] (artful-proposed) [1.0.3-2]
[03:29] -queuebot:#ubuntu-release- New: accepted haskell-http-link-header [i386] (artful-proposed) [1.0.3-2]
[03:29] -queuebot:#ubuntu-release- New: accepted haskell-cabal-install [s390x] (artful-proposed) [<IP_ADDRESS>-2]
[03:29] -queuebot:#ubuntu-release- New: accepted haskell-http-link-header [amd64] (artful-proposed) [1.0.3-2]
[03:45] <slangasek> jbicha: are you tracking the mapnik that you synced from experimental?  It has missing symbols relative to the previous version and regresses node-mapnik
[03:46] <slangasek> (and probably more; but node-mapnik has the autopkgtest that notices)
[04:07] -queuebot:#ubuntu-release- New binary: haskell-github [amd64] (artful-proposed/universe) [0.15.0-1build1] (no packageset)
[04:07] -queuebot:#ubuntu-release- New binary: haskell-github [ppc64el] (artful-proposed/universe) [0.15.0-1build1] (no packageset)
[04:07] -queuebot:#ubuntu-release- New binary: haskell-github [i386] (artful-proposed/universe) [0.15.0-1build1] (no packageset)
[04:32] -queuebot:#ubuntu-release- New: accepted haskell-github [amd64] (artful-proposed) [0.15.0-1build1]
[04:32] -queuebot:#ubuntu-release- New: accepted haskell-github [ppc64el] (artful-proposed) [0.15.0-1build1]
[04:32] -queuebot:#ubuntu-release- New: accepted haskell-github [i386] (artful-proposed) [0.15.0-1build1]
[08:03] <Laney> slangasek: I do it frequently
[08:03] <Laney> But not at the weekend ......
[08:03] <Laney> slangasek: Are you interested in helping out, or something? You seem to be keeping an eye on this.
[09:05] <LocutusOfBorg> hello, did anybody stop haskell autosync? btw slangasek great success :)
[09:08] -queuebot:#ubuntu-release- New binary: paste [amd64] (artful-proposed/main) [2.0.3+dfsg-4ubuntu1] (ubuntu-desktop, ubuntu-server)
[09:21] <LocutusOfBorg> btw why is ninja failing in that strange way? I would blame debhelper or similar...
[09:22] <LocutusOfBorg> src:ninja-build, seems that debhelper is missing some target
[09:23] <cjwatson> I see no evidence that haskell autosyncing is stopped
[09:26] <LocutusOfBorg> I had to manually sinc ghc some minutes ago
[09:33] <Laney> LocutusOfBorg: what happens if you rebuild in unstable now?
[09:33] <Laney> 10.5 is there
[09:35] <LocutusOfBorg> Laney, I finished 10 secoonds ago
[09:35] <LocutusOfBorg> damn, same issue
[09:35] <LocutusOfBorg> adding an empty override_dh_auto_install works, meh
[09:35] <LocutusOfBorg> I'm opening an RC bug in debian
[09:36] <LocutusOfBorg> or maybe I'll open it if you ask me, because it might be a debhelper bug
[09:38] <Laney> seems likely that it is
[09:38] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-82.105~14.04.1] (kernel)
[09:38] <LocutusOfBorg> I'll ask in debian devel irc
[09:39] <cjwatson> LocutusOfBorg: ghc> you're just impatient
[09:40] <cjwatson> LocutusOfBorg: by about an hour or so
[09:40] <LocutusOfBorg> ok, it was uploaded yesterday... anyway, even better
[09:44] <cjwatson> LocutusOfBorg: didn't get imported into LP last night because of losing a race by a couple of minutes, which delayed it by six hours
[09:44] <LocutusOfBorg> oh ok
[10:07] -queuebot:#ubuntu-release- Unapproved: at-spi2-atk (xenial-proposed/main) [2.18.1-2ubuntu1 => 2.24.1-0ubuntu1] (kubuntu, ubuntu-desktop)
[10:09] -queuebot:#ubuntu-release- Unapproved: rejected at-spi2-atk [source] (xenial-proposed) [2.24.1-0ubuntu1]
[10:15]  * cjwatson finally gets round to proposing a crontab merge to fix said race.  Only been meaning to do that for about six year
[10:15] <cjwatson> s
[10:32] <LocutusOfBorg> cjwatson, <3
[10:32] <LocutusOfBorg> lovely cron
[10:52] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-82.105~14.04.1]
[11:35] <jbicha> slangasek: yes I believe we just need a newer node-mapnik version, we can do that ourselves or wait a bit longer for Debian
[11:51] -queuebot:#ubuntu-release- Unapproved: libinput (xenial-proposed/main) [1.2.3-1ubuntu1 => 1.6.3-1ubuntu1~16.04.1] (kubuntu, ubuntu-desktop)
[12:12] -queuebot:#ubuntu-release- Unapproved: xorg-server (xenial-proposed/main) [2:1.18.4-0ubuntu0.2 => 2:1.18.4-0ubuntu0.3] (desktop-core, xorg)
[12:18] -queuebot:#ubuntu-release- Unapproved: xfonts-utils (xenial-proposed/main) [1:7.7+3ubuntu<IP_ADDRESS> => 1:7.7+3ubuntu<IP_ADDRESS>] (core)
[12:57] -queuebot:#ubuntu-release- Unapproved: mesa (xenial-proposed/main) [12.0.6-0ubuntu<IP_ADDRESS> => 17.0.7-0ubuntu<IP_ADDRESS>] (core, xorg)
[13:40] -queuebot:#ubuntu-release- New: accepted paste [amd64] (artful-proposed) [2.0.3+dfsg-4ubuntu1]
[14:21] -queuebot:#ubuntu-release- New binary: rustc [amd64] (artful-proposed/universe) [1.17.0+dfsg2-7] (no packageset)
[14:21] -queuebot:#ubuntu-release- New binary: rustc [s390x] (artful-proposed/universe) [1.17.0+dfsg2-7] (no packageset)
[14:27] -queuebot:#ubuntu-release- New binary: rustc [i386] (artful-proposed/universe) [1.17.0+dfsg2-7] (no packageset)
[14:36] -queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [0.1.0~bzr505-0ubuntu1~16.04.1]
[15:33] -queuebot:#ubuntu-release- Unapproved: intel-microcode (xenial-proposed/restricted) [3.20151106.1 => 3.20170511.1~ubuntu16.04.0] (ubuntu-desktop, ubuntu-server)
[15:34] -queuebot:#ubuntu-release- Unapproved: intel-microcode (yakkety-proposed/restricted) [3.20160714.1 => 3.20170511.1~ubuntu16.10.0] (ubuntu-desktop, ubuntu-server)
[15:34] -queuebot:#ubuntu-release- Unapproved: intel-microcode (zesty-proposed/restricted) [3.20161104.1 => 3.20170511.1~ubuntu17.04.0] (ubuntu-desktop, ubuntu-server)
[15:46] <rbasak> infinity: xnox: ^ who's reviewing these? Want me to do it? I don't see sil2100 here.
[15:50] -queuebot:#ubuntu-release- New binary: rustc [arm64] (artful-proposed/universe) [1.17.0+dfsg2-7] (no packageset)
[15:50] <xnox> rbasak, i review no, i applaud only =)
[15:53] <rbasak> xnox: huh?
[15:53] <xnox> rbasak, i'm just the uploader, and i have not pinged anybody to review it yet.
[15:54]  * xnox translates ranglish to english
[15:54] <rbasak> Ah
[15:54] <rbasak> OK. Well then I'll take it.
[15:58] <rbasak> xnox: not doing Trusty?
[16:00] <xnox> rbasak, nope.
[16:01] <xnox> rbasak, these new microcodes require early initramfs loading code; which is not in trusty. And I don't think intel-microcode is widely installed in trusty.
[16:02] <xnox> rbasak, in xenial we have started automated intel-microcode installation with ubuntu-drivers
[16:02] <rbasak> I see. Thanks.
[16:04] <rbasak> xnox: in the past the intel-microcode SRU updated the dat file only. With your backport it has the effect of changing more, such as debhelper compat level and the initramfs-tools hook. Do you have an opinion on one approach over the other?
[16:11] -queuebot:#ubuntu-release- New: accepted rustc [arm64] (artful-proposed) [1.17.0+dfsg2-7]
[16:11] -queuebot:#ubuntu-release- New: accepted rustc [amd64] (artful-proposed) [1.17.0+dfsg2-7]
[16:11] -queuebot:#ubuntu-release- New: accepted rustc [s390x] (artful-proposed) [1.17.0+dfsg2-7]
[16:11] -queuebot:#ubuntu-release- New: accepted rustc [i386] (artful-proposed) [1.17.0+dfsg2-7]
[16:11] <xnox> rbasak, i'd rather do wholesome backports. the changes are improve text output during initramfs generation. Pre-v4.4 handling of kernels is not as relevant on xenial, unless people boot trusty kernel (still)
[16:12] <rbasak> xnox: that's not general SRU policy though :-/
[16:14] <slangasek> Laney: well, I was working on transitions over the weekend, and the number of stuck tests that I was running across was significant enough that I batch retried, and 800 seemed a bit high.  Do you have some idea of the failure rate here, that would inform whether it's worth putting effort into the cause vs. just batch retrying on the regular?
[16:15] <xnox> rbasak, this is hwe backport of binary blobs for restricted.
[16:15] <rbasak> xnox: it is; however the packaging is not a binary blob.
[16:15] <slangasek> Laney: but also, if you need someone else to hit the mass-retry button, I can certainly do that ;)
[16:15] <Laney> slangasek: do you know what the problem was?
[16:15] <xnox> rbasak, e.g. are nvidia packages backported piecewise, or just straight backports of the new upstream releases (and the new packaging)?
[16:15] <slangasek> no clue
[16:15] <Laney> it's not regular, at least not on that scale
[16:15] <Laney> but there could be a systemic problem that hits at one time
[16:15] <rbasak> xnox: I don't know. Is it?
[16:15] <Laney> something like: the initial dist-upgrade fails
[16:16] <xnox> rbasak, there is more room for error by modifying this; since one has to be careful and exclude packaging of the broken microcodes.
[16:16] <rbasak> I can see that a wholesale packaging update might be necessary depending on the nature of the upstream blob update (eg. if old packaging cannot cope with it).
[16:16] <ypwong> infinity, can you help us to review the xenial sru for fwupdate?
[16:17] <slangasek> Laney: well, there had also been several big packages going through the system (nodejs, perl, ...), so it's possible 800 was in line with the overall error rate?  But I don't know how to even measure that error rate
[16:17] <rbasak> In this case, isn't the packaging more closely tied to the Free bits, rather than the non-Free bits? The blob itself remains a blob all the way through to the hardware, no?
[16:18] <xnox> zesty diff is smaller, since zesty base is newer thus that one looks a lot more like just the blob update
[16:21] <rbasak> That statement sounds likely to be true, but I don't follow what point you're making there. I was reviewing the Xenial diff to start with.
[16:21] <xnox> that's backwards no? =)
[16:21] <xnox> yakkety all diffs are needed.
[16:21] <Laney> slangasek: We have the information needed (exit code of autopkgtest) in a database, so it could be exposed on http://autopkgtest.ubuntu.com/statistics
[16:21] <Laney> 800 at once is definitely more than I'd expect
[16:21] <Laney> I suspect a package was failing to install or similar
[16:21] <rbasak> I find it easier to start with the most invasive set of decisions. Then reviewing the smaller diffs is easy :)
[16:22] <Laney> I pushed a change earlier that should result in more runs being recorded as failures (with version 'unknown') rather than being left in running state
[16:22] <slangasek> Laney: you have an error code for these test requests that end up stuck in 'running'?  They don't seem to ever show up on the per-package pages
[16:23] <Laney> It's because they fail too early for autopkgtest-web to know the current version, so it skips them
[16:23] <slangasek> ah
[16:23] <Laney> that's what my fix remedies
[16:23] <xnox> rbasak, the initramfs hook updates are good / wanted in xenial; update from debhelper compat 7->9 is imho also good as we do want microcode package to build exactly the same way on all releases. And ideally we do want to update it on continious basis.
[16:23] <Laney> well, it fakes up a version of 'unknown'
[16:23] <xnox> not taking compat changes, creates more work and divergence
[16:23] <slangasek> yeah, that seems like a good improvement :)
[16:24] <Laney> so you should at least easily be able to browse them rather than having to surf swift via its API
[16:24]  * xnox ponders if intel-microcode really should be a snap
[16:24] <slangasek> makes the state more discoverable
[16:24] <rbasak> xnox: perhaps so, but in that case should we not have those changes go through the usual SRU process with their own bugs, justifications, regression tests, etc?
[16:25] <rbasak> xnox: and for the future "exactly the same way" / "update it on continious basis", I agree this might be what we want in general, but I think that should probably form an SRU exception that we want to formulate, review, approve, etc.
[16:26] <xnox> rbasak, perhaps, but all of them are "backport the latest micocode package to stable releases" which is what the bug report in question is.
[16:26] <xnox> rbasak, the bug here is not "cherrypick high-severety microcode updates only for Skylake"
[16:26] <rbasak> OTOH this particular update we should probably just get through, and for that, I think minimising it to the blob update makes more sense, unless there's a particular reason why that can't be done or there's a specific reason it carries higher risk.
[16:27] <xnox> my request here is for a wholesome backport to latest, not a targeted fix for just this one skylake HT bug.
[16:27] <cjwatson> *wholesale
[16:27] <rbasak> xnox: OK, but if you want to drive the more general bug, it'll end up in the slow lane.
[16:27] <xnox> cjwatson, yes, checked dictionary.
[16:28] <xnox> rbasak, it definately should be in the slow lane, with extra long phasing. I am expecting it will be in proposed for a month of so.
[16:28] <xnox> rbasak, as we need to collect multiple possitive results on multiple CPU SKUs / Families.
[16:29] <rbasak> I agree with extra long phasing and a long time in proposed. I was expecting though to be able to fast track a blob update (only) into proposed so users had somewhere official from which to get it (for opt-in updates).
[16:29] <xnox> there are a lot of updates to a lot of microcodes, and any one of them can regress anything (to the point of graphics not working, or systems not booting)
[16:30] <xnox> rbasak, that would diverge packages and create sru-only delta which i do not want to support, nor maintain, nor debug going forward.
[16:30] <xnox> (delta vs debian)
[16:31] <xnox> imho it is a mistake that we do not routinely update microcode packages, the way we e.g. update the hwe-kernels.
[16:31] <rbasak> It's been done before. I'm not ruling out your longer term plans at all here. If those are successful, then any difficult maintainability point becomes moot.
[16:32] <xnox> rbasak, given lack of dependencies it would be nice to copy down the .deb verbantim. but we will not do that.
[16:33] <xnox> rbasak, please review yakkety/zesty, i think you will have less objections about those.
[16:33] <xnox> rbasak, and i prefer for later releases be fix released, before even accepting xenial package.
[16:34] <xnox> unless you object to s/7/9 in those too
[16:40] <rbasak> AFAICT, either I need to accept the packaging changes on the basis that they are approved under current SRU policy (perhaps with approving whatever I need to that is within my remit), and so I can accept X/Y/Z subject to review this way, or I don't. I don't think it makes sense to accept Y/Z and not X on a policy basis. And if I did, but we later decided to do something different, that'd be even
[16:40] <rbasak> more of a pain to manage in the future.
[16:40] <rbasak> So I think ~ubuntu-sru needs to resolve what to do here first, if you want to include packaging changes in this update.
[16:41] <rbasak> OTOH I'd accept a blob-only update into all three releases as I don't think there's any SRU policy question there, but you've said and given reasons as to why you don't want that.
[16:41] <xnox> rbasak, right, my thinking behind this upload was that this is backport-published-to-updates-via-proposed-testing
[16:42] <rbasak> That's a summary of my thinking right now. I'd like opinions from other ~ubuntu-sru if any are around please.
[16:42] <xnox> i did not prepare these as classic SRUs.
[16:42] <xnox> and backports minimise delta / changes, to only those neccessory to get something building on older release; no changes are required here, as debian too backports this package as far back as is reasonable.
[16:44] <rbasak> The regression risk there though is for example that the delivery mechanism changes to something that older kernels cannot support.
[16:45] <rbasak> OTOH, it seems unlikely to me that just updating the blobs would pose any difficulty for a system on which the delivery mechanism already works (and if it doesn't, that's a matter for a more specific SRU following the usual process).
[16:45] <xnox> the risk of buggy microcodes / microcodes with regressions is much higher. The last delivery change was in the v3.13 kernels, and has not changed since.
[16:45] <rbasak> "the risk of buggy microcodes / microcodes with regressions is much higher" - how so?
[16:46] <xnox> (the requirement around built-in / non-builtin module is imho insignificant)
[16:46] <rbasak> "The last delivery change was in the v3.13 kernels" - only because you specifically know that. What might you not know about that is in the same class of problems?
[16:46] <xnox> rbasak, re:buggy microcode the infamous lock ellision update
[16:46] <xnox> that needed newer glibc on the host too, to prevent it from using the now disabled lock ellision, resulting in crashes.
[16:47] <xnox> e.g. one needed newer userspace glibc and the new microcode.
[16:47] <xnox> that was non-obvious during the microcode update.
[16:47] <xnox> because of lack of disclosures from intel
[16:47] <rbasak> xnox: and how would backporting the latest packaging have avoided that, if that packaging didn't have the versioned dependency because we didn't know about it?
[16:48] <xnox> it doesn't, due to lack of information. Therefore bisecting and cherrypicking individual microcode updates and/or cherrypicking changes does not reduce risk at all. The only way we can reduce risk is extensive in-the-field testing on multiple of microcode families and watch for regression bug reports.
[16:49] <xnox> because we need positive tests that things are not broken horibbly on N latest cpu families. E.g. at least as far back as e.g. ivy bridge today.
[16:49] <rbasak> xnox: fine, but it makes no difference to your example whether we backport the packaging or backport only the blogs.
[16:49] <rbasak> *blobs.
[16:50] <xnox> validation matrix explodes. I do not think we will be able to get comprehensive coverage for every cpu family, on every release series. therefore we will have to trust the validation from multiple releases.
[16:51] <rbasak> I still fail to see how it would be different in your example whether we backport blobs or backport the packaging. The packaging made no difference to that situation.
[16:51] <xnox> which is an argument for not doing these updates, and keep systems knowgly vulnerable.
[16:51] <xnox> rbasak, if the packaging makes no difference, why should i be creating N versions of packaging, instead of maintaining one version of packaging?!
[16:51] <xnox> =)
[16:51] <xnox> and then debugging the case where the packaging did make a difference.
[16:52] <rbasak> Because minimal changes to stable releases minimised regression risk, as the packaging includes interactions with other components (such as the kernel) where there is a non-zero risk of regression that can be mitigated by not changing it.
[16:52] <rbasak> *minimises
[17:03] <xnox> my understanding is that e.g. snapd, firefox, linux-hwe, cloud-archive  use a backport model of complete updates to latest upstream and packaging changes with minimal delta w.r.t. the version being backported. Rather than minimal delta w.r.t. each of the targetted releases.
[17:05] <xnox> i understand not taking 99% of changes where the actual bugfix is a one-lines; i do not understand rejecting 1% of packaging changes, when 99% are all needed.
[17:05] <rbasak> Yes, and each of those have a documented exception and individual policy. We don't currently have one of those for intel-microcode.
[17:06] <xnox> where can i look at that?
[17:06] <rbasak> And each of those has had the pros and cons considered on a case by case basis.
[17:06] <rbasak> https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
[17:06] <xnox> ack thanks
[17:06] <rbasak> Firefox isn't there. Technically it doesn't have an SRU exception AFAIK. It goes in via the security pocket, and the security team have their own polices.
[17:07] <rbasak> Though in practice an SRU would probably be fine because we do it all the time anyway (because security).
[17:12] <rbasak> I've written up what I think is the current situation in the bug. I'm EOD for now - I think from our discussion you're not in a hurry?
[17:19] <slangasek> Depends: libsbml perl (not considered)
[17:19] <slangasek> hmph
[19:14] <slangasek> cjwatson: do you have any idea why auto-sync says dictem_1.0.4.orig.tar.gz content has changed, given that it arrived in Ubuntu via auto-sync?
[19:45] <slangasek> libfile-sharedir-projectdistdir-perl/1.000008-1
[19:45] <slangasek> which are worse, perl package names or perl package version numbers?
[19:58] <infinity> slangasek: Because it did.
[19:59] <slangasek> infinity: so Debian's orig.tar.gz changed?
[19:59] <infinity> slangasek: dak is slack about maintaining the constraint if things are no longer on disk. :(
[19:59] <slangasek> ah, so this was a package removal/readd?
[20:00] <infinity> slangasek: Debian's original orig only existed briefly.  It went (accidentally, probably) native in 1.0.4-2, then back to non-native in -4
[20:00] <infinity> slangasek: But we have a record of -1, and LP won't let you do that:
[20:00] <infinity> slangasek: https://launchpad.net/ubuntu/+source/dictem/1.0.4-1
[20:00] <infinity> slangasek: So, the only solution here would be to fake the sync using the orig from the -1 upload.
[20:00] <slangasek> right
[20:01] <infinity> slangasek: Not that it matters, given that -3 and -4 were no-ops, really.  Just the maintainer asserting his non-demise.
[20:03] <infinity> (Well, they should be no-ops, according to the changelog.... Of course, the new orig might have made them excitingly different!)
[21:57] -queuebot:#ubuntu-release- Unapproved: apport (zesty-proposed/main) [2.20.4-0ubuntu4.2 => 2.20.4-0ubuntu4.3] (core)
[21:58] -queuebot:#ubuntu-release- Unapproved: apport (yakkety-proposed/main) [2.20.3-0ubuntu8.4 => 2.20.3-0ubuntu8.5] (core)
[22:00] -queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.7 => 2.20.1-0ubuntu2.8] (core)
[22:30] <slangasek> Laney, infinity: I'm interested in your thoughts on https://bugs.launchpad.net/britney/+bug/1700668
[22:30] <ubot5`> Ubuntu bug 1700668 in britney "make it easier to reset baseline for autopkgtests that regress in release" [Undecided,New]
[23:06] -queuebot:#ubuntu-release- New sync: ocamlbuild (artful-proposed/primary) [0.10.1-1]
[23:16] <xnox> ^ would unblock ocaml transition going further
[23:18] <slangasek> not an autosync? :)
[23:19] -queuebot:#ubuntu-release- New: accepted ocamlbuild [sync] (artful-proposed) [0.10.1-1]
[23:19] <xnox> slangasek, from experimental
[23:19] <slangasek> ah
[23:21] -queuebot:#ubuntu-release- New binary: ocamlbuild [amd64] (artful-proposed/none) [0.10.1-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: ocamlbuild [ppc64el] (artful-proposed/none) [0.10.1-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: ocamlbuild [arm64] (artful-proposed/none) [0.10.1-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: ocamlbuild [s390x] (artful-proposed/none) [0.10.1-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: ocamlbuild [i386] (artful-proposed/none) [0.10.1-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: ocamlbuild [armhf] (artful-proposed/none) [0.10.1-1] (no packageset)
[23:32] <xnox> slangasek, seems to me that all the bugs of failed to install/upgrade are filed against random package that happens to be the unlucky one to call insserv or run of disk space, etc.
[23:32] <xnox> https://bugs.launchpad.net/ubuntu/+source/systemd/+bugs?field.searchtext=install%2Fupgrade&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[23:32] <xnox> trianging these is not fun.
[23:33] <slangasek> xnox: experiencing the upgrade failures is also not fun; can we get rid of insserv yet?
[23:33] <xnox> slangasek, my understanding is that we have and debian did too. but not in xenial?!
[23:33] -queuebot:#ubuntu-release- New: accepted ocamlbuild [amd64] (artful-proposed) [0.10.1-1]
[23:33] -queuebot:#ubuntu-release- New: accepted ocamlbuild [armhf] (artful-proposed) [0.10.1-1]
[23:33] -queuebot:#ubuntu-release- New: accepted ocamlbuild [ppc64el] (artful-proposed) [0.10.1-1]
[23:34] -queuebot:#ubuntu-release- New: accepted ocamlbuild [arm64] (artful-proposed) [0.10.1-1]
[23:34] -queuebot:#ubuntu-release- New: accepted ocamlbuild [s390x] (artful-proposed) [0.10.1-1]
[23:34] -queuebot:#ubuntu-release- New: accepted ocamlbuild [i386] (artful-proposed) [0.10.1-1]
[23:34] <slangasek> right, it is gone, but still causes upgrade failures in xenial
[23:35] <xnox> hm, my system seems to be broken
[23:35] <slangasek> since insserv in xenial isn't integrated with systemd the way it was with upstart, I think the right fix is to SRU insserv to make it non-fatal
[23:35] <xnox> I'm getting segfaults
[23:35] <xnox> [661832.017428] schroot[30225]: segfault at 500000002 ip 00007fc0023262b8 sp 00007ffde3b7f060 error 4 in pam_cgfs.so[7fc002323000+6000]
[23:35] <xnox> [657710.517534] pcscd[12977]: segfault at 10 ip 00007f7792767d44 sp 00007f778abc8e20 error 4 in libpthread-2.23.so (deleted)[7f779275e000+18000]
[23:35] <xnox> that can't be good.
[23:35] <xnox> slangasek, does systemd in xenial need any of the insserv orderings? and e.g. do we still use insserv orderings for e.g. shutdown?
[23:36]  * xnox thought we didn't
[23:38] <slangasek> xnox: that's what I'm saying, I don't believe it's meaningfully integrated with systemd at all
[23:39] <slangasek> should be verified, but AIUI it's mostly pointless
[23:39] <xnox> ack. let me add a trello card about that
[23:39] <slangasek> (and so shouldn't be allowed to cause upgrade errors)


[13:38] <benji> bac: I'm wandering around in testing infrastructure, but we should probably formulate a plan for today soonish
[13:38] <bac> benji: my plan is to make the changes per review and get my branch landed
[13:38] <benji> that sounds good; want to sync up after that?
[13:38] <bac> then i will be an official Go programmer, a juju core contributor, and an all around badass
[13:39] <hatch> morning
[13:41] <bac> yes, benji, that'll be good
[13:48] <hazmat> bac, they teach the secret handshake then ;-)
[13:49] <bac> excellent.
[13:50] <benji> bac is so awesome he doesn't call the wrong number, you answer the wrong phone
[13:53] <goodspud> Bwa ha ha ha
[13:53] <goodspud> Is that taken from a "Clint Eastwood" joke?
[13:54] <benji> goodspud: Chuck Norris
[13:54] <goodspud> benji, er yeah... that's who I meant :)
[13:54] <gary_poster> :-)
[13:54] <goodspud> Clint, Chuck... all the same really (don't hit me Chuck)
[13:55] <benji> Clint Eastwood doens't hit people, he makes Chuck Norris do it for him.
[13:56] <goodspud> Bwa ha ha ha
[14:14] <teknico> bac, care to add a code review link to your card?
[14:15] <bac> teknico: ok.
[14:15] <teknico> bac, beat you to the punch :-)
[14:15] <bac> dang
[14:16] <teknico> oh, you got reviews already, ok
[14:16] <bac> teknico: are you doing juju-core reviews or just curious
[14:16] <bac> i have an abundance of reviews!  :)
[14:16] <teknico> bac, just curious, I don't feel up to the task yet
[14:23] <gary_poster> bac you available for a call with me and frankban to share your glorious go juju api command knowledge, now that you have a branch in review?
[14:24] <bac> gary_poster: sure.  benji may want to join if he has time.
[14:24] <bac> let me re-tea and i'll join you there?
[14:24] <gary_poster> thanks bac, pm'd location
[14:24] <gary_poster> you too benji
[14:24] <benji> for you I'll clear my schedule
[14:27] <teknico> gary_poster, ok, where's the party?
[14:40] <hatch> I've noticed that some code uses camelcased and some uses understores fooBar vs foo_bar - is there a prefered method? I typically write camelcased
[14:40] <hazmat> hatch, camelcased
[14:41] <hazmat> hatch, we transitioned mid dev
[14:42] <hatch> sounds good to me - old habits are hard to break ;)
[14:43] <gary_poster> Makyo, hey.  I have more feedback for your branch--small but nice.  Trying to add it now..
[14:50] <gary_poster> comment added
[14:59] <Makyo> gary_poster, Thanks for the feedback.  I'm not sure I understand.  Do I need to call _navigate rather than navigate or fire('navigate')?  Where do I set the options?  Tests for those lines?
[15:00] <gary_poster> Makyo, about to have call, but you would need your logout to eventually call the app navigate method with that new option
[15:01] <gary_poster> Makyo, talk to you after this call or after daily?
[15:01] <Makyo> gary_poster, Sure.
[15:01] <gary_poster> thanks
[15:09] <Makyo> Will try to coffee in the meantime, so I'm not running so slow
[15:17] <Makyo> gary_poster, nvm, I get it now, was misreading Router.combine.  Will get a test in for that.
[15:27] <gary_poster> cool thanks Makyo
[15:28] <gary_poster> jujugui call in 2
[15:32] <teknico> sorry, hangout crashed and is not starting anymore, trying again
[15:35] <bac> gary_poster: branch back in review after making changes.
[15:35] <bac> gary_poster: proceeding with the next branch, dependent on the first
[15:35] <gary_poster> cool
[15:54] <hatch> bcsaller_: have time for a chat?
[15:55] <bcsaller_> hatch: sure
[15:55] <hatch> in the boardroom
[16:38] <hatch> if I run --fixes multiple times on a commit will that link to multiple tickets or will it blow up? :)
[16:39] <gary_poster> heh, dunno hatch.  you can do it in lp though
[16:39] <gary_poster> "link to bug"
[16:41] <hatch> sounds good :)
[16:41] <bcsaller_> I think the arg parser is last write wins
[16:42] <Makyo> Have yet to use --fixes, been using -bug=xxxxxx in lbox.  That just do the same thing?
[16:43] <gary_poster> different under the hood in a way you don't care about Makyo.  --fixes annotates branch in a way that LP snarfs up, and I suspect lbox uses LP API to directly communicate the connection
[16:43] <gary_poster> so inetrchangeable effectively
[16:59] <gary_poster> hatch are you already factoring out the namespace code into a separate module?  If have some changes--mostly but not exclusively docs--for that code as well.  It would be easier if we did not stomp on one another.
[16:59] <gary_poster> s/If have/I have/
[17:00] <hatch> gary_poster: I haven't touched the namespace stuff yet - I'm working on creating the subapp structure right now
[17:00] <gary_poster> Great hatch.  Lemme know when you get there and we can either coordinate or maybe I will already have my changes in.
[17:01] <hatch> right now my changes to app.js are going to be minimal - I'm trying to keep them all in the extension - so update away!
[17:02] <gary_poster> cool thanks
[17:23] <bac> hatch: let's talk soon about code reviews.  whenever convenient for you.
[17:23] <hatch> can we do it after lunch? I really want to get this subapp stuff working
[17:25] <gary_poster> Small simple cleanup branch for review.  bcsaller needs to look at it, and then anyone else (hi, jujugui!).  https://codereview.appspot.com/7372044/
[17:26] <bac> hatch: ok
[17:26] <bac> ping me
[17:27] <bac> gary_poster: i'll look at it.  there is no card, right?
[17:27] <gary_poster> right bac.  was a review follow-on for bcsaller's branch of some changes I wanted but didn't make it
[17:32] <bcsaller_> *cough* sorry about that
[17:33] <frankban> bac: is it required to ping someone to get a juju-core review?
[17:34] <bac> frankban: i didn't and i got four!
[17:34] <frankban> bac: cool!
[17:34] <bac> may not hurt to ping fwreade, though
[17:35] <frankban> bac: I have no rush, approaching EOD
[17:35] <gary_poster> bcsaller, :-) np.  I read your reveiew, thanks.  In the current structure how does one register a namespaced route?  I assumed that you would register something for the path ":your_namespace_here:/your/path" or for something similar.  Is that it?
[17:35] <gary_poster>  /:your_namespace_here:/your/path I guess
[17:35] <bcsaller> gary_poster: that will work, but I think specifying it as an attr of the route definition will be better and will work the subapp stuff cleanly
[17:36] <bcsaller> The change to match is a few minutes of work, I can propose it after you land your changes
[17:36] <gary_poster> bcsaller, sounds good, thanks.
[17:36] <bac> gary_poster: done
[17:37] <gary_poster> Cool, thank you bac.
[18:35] <gary_poster> Makyo, approved with some small changes
[18:35] <gary_poster> hatch/bac, please take a look at https://codereview.appspot.com/7395043/ very soon so Makyo can land
[18:38] <hatch> alright
[18:38] <bac> hi benji
[18:38] <benji> hey bac
[18:38] <bac> i've got a branch that implements the server and client functions for the ws/rpc get command
[18:39] <bac> benji: would you like to try poking at it with your ws client and see if it behaves?
[18:39] <bac> benji: or show me how to?
[18:39] <bac> i.e., gimme your client
[18:40] <benji> bac: sure, shall we relocate to the hangout to discuss?
[18:40] <bac> i'm sure others are on the edges of their seats...
[18:40] <bac> but, ok
[18:40] <gary_poster> I don't even have a seat!
[18:41] <benji> bac: here is the code: http://paste.ubuntu.com/1700814/
[18:42] <bac> benji: invited you
[18:44] <hatch> the code looks good - I'll do a functionality check now
[18:56] <hatch> I really hate how harddrives advertise 3TB but are really only 2.73TB ... 270GB is a lot of missing space ;)
[19:04] <bac> benji: bzr push lp:~bac/juju-core/add-get-2
[19:04] <benji> thanks bac
[19:15] <bcsaller> gary_poster, hatch: when you have time can you check that the rules for ns route matching make sense to you in https://codereview.appspot.com/7396050/
[19:19] <hatch> I must be missing something
[19:19] <hatch> because it looks like it just returns true all the time :)
[19:21] <hatch> that was a poorly formed joke
[19:21] <hatch> and poorly executed
[19:24] <hatch> bcsaller: just to verify when you said
[19:24] <hatch> So /:inspector/service/mysql/ would match while
[19:24] <hatch> you meant :inspector: right?
[19:24] <bcsaller> yeah
[19:25] <bcsaller> unfortunate typo
[19:26] <hatch> revieweddd
[19:27] <bac> benji: which websocket package does your script use?  the one from pip doesn't have 'create_connection'
[19:27] <benji> bac: hmm, let me look
[19:28] <bac> gary_poster: are we chatting in 1 min?
[19:30] <gary_poster> bac, no.  I hoped we would be, but house person is here.  will ping?
[19:30] <gary_poster> should be within 15 min
[19:31] <bac> ok
[19:31] <benji> bac: "websocket-client"
[19:48] <gary_poster> bac, ready now.  joining.  you ready?
[19:57] <bac> gary_poster: joining now
[20:15] <gary_poster> bac https://codereview.appspot.com/7390043/
[20:21] <bac> hi benji, i'm getting {"RequestId":1,"Error":"no such request \"ServiceGet\" on Client","Response":{}}
[20:22] <bac> benji: is there some other registration step i might be forgetting?
[20:22] <benji> bac: I didn't have to do anything for mine, let me look at your code a second
[20:24] <benji> bac: the code looks good to me; did you use --upload-tools when you bootstrapped?
[20:24] <gary_poster> bcsaller, that namespace-restricted route matching looks good to me.  When you prepare for landing, please do include some documentation
[20:24] <gary_poster> even just comments in the routes section
[20:24] <bcsaller> gary_poster: thanks, on it
[20:24] <bac> benji: yes
[20:25] <bac> benji: i just tried 'Status' and it works
[20:25] <benji> hmm, well, that's something
[20:28] <benji> bac: it might be your return signature, you should be returning a struct, not a pointer to a struct (I am far from certain that this is it, but that is the only candidate I have for what the problem might be)
[20:29] <bac> hmm
[20:29] <bac> ok
[20:32] <bac> benji: that is why rog was returning Status{}
[20:32] <bac> he had to return a struct so he couldn't return nil
[20:33] <benji> that would explain it (although, I wonder why not just make the standard return signature a pointer to a struct, then returning nil is fine)
[20:34] <bac> benji: well there is that
[20:34] <bac> go is weird in that the caller looks the same whether it is a struct or pointer returned
[20:36] <benji> yeah, that's something that I'm not sure if I like or not; not having to do the "." vs. "->" dance like in C++ is nice, but it might be confusing having the DWIM
[20:41] <bac> benji: that was it!  fixed the return signature and it works.  thanks!
[20:41] <benji> cool
[20:54] <bac> benji: are you okay running with my add-get-2 branch?
[20:55] <benji> bac: I'm ok enough to try :)  please write down my goal(s) in an email to me and I'll tackle them
[20:56] <bac> benji: ok, the main thing is to figure out api_test and add relevant test for the new command
[20:59] <bac> benji: writing email now
[20:59] <benji> thanks
[20:59] <benji> tests I think I can handle
[21:00] <bac> benji: did my msgs just show up in #juju-dev?
[21:00] <benji> bac: I'm not in juju-dev at the moment
[21:00] <bac> my client is reporting Your message couldn't be sent to the channel
[21:00] <bac> ok
[21:00] <benji> I guess I should add that to my auto-join (it's just so noisy over there)
[21:15] <hatch> O K lunching
[21:15] <hatch> bbiab
[21:29] <BradCrittenden> gary_poster: should we be added to ~gophers?  if not we cannot submit to juju-core
[21:29] <gary_poster> BradCrittenden, yes we should.  I will ping mramm about it unless you tell me you are doing so
[21:29] <BradCrittenden> gary_poster: he is currently on #juju-dev.
[21:30] <bcsaller> hmm, lbox submit is failing for me, trying to figure out why, sorry about any noise its generating
[21:33] <bac> bcsaller: how is it failing?
[21:33] <bac> i got a read-only transport failure, which i attributed to not having write permission to lp:juju-core
[21:33] <bcsaller> bac: http://paste.ubuntu.com/1701833/
[21:34] <bcsaller> bac: sh ./.lbox.check works fine though
[21:34] <bac> bcsaller: ok, unrelated
[21:35] <bac> no clue as to what is happening with yours
[21:35] <bcsaller> bac: thanks for looking :)
[21:48] <bac> gary_poster: well, thanks for trying.  :)
[21:49] <gary_poster> bac :-(
[22:03] <hatch> ok!!!
[22:03] <hatch> sooo
[22:04] <hatch> how do I go about merging trunk into my branch?
[22:04] <hatch> well the proper way of doing so
[22:05] <hatch> I need to make sure I have all of the most recent routing code
[22:06] <Makyo> hatch, If you're in your branch, you can do bzr merge ../../trunk or wherever your copy of trunk is
[22:06] <Makyo> hatch, Make sure trunk is up to date by doing `bzr pull` in there, first.
[22:06] <hatch> ahh ok that's simple enough thx
[22:07] <Makyo> bcsaller, new version of jshint changed the command name, just running into that now.
[22:12] <Makyo> guihelp, Newest version of jshint dies spectacularly on some of our files - namely JSON, but a few JS files it was fine with before.  Can bcsaller or I set the version in our current branch to an older one for the time being?
[22:12] <gary_poster> Makyo, +1
[22:12] <hatch> go for it
[22:12] <hatch> although what's it barfing on?
[22:12] <hatch> just curious
[22:15] <Makyo> hatch, **.json, a few redefinitions across files (YUI, etc.), one instance of 'char' as a var name.  I'd like to get both bcsaller and I's branches landed (or proposed) today, so I'm proposing we drop the version for now, make a card to investigate moving to current when we've got time.
[22:15] <hatch> oh yeah for sure - drop it down
[22:16] <hatch> jshint isn't one that you wouldn think would all of a sudden start breaking heh
[22:16] <Makyo> They just hit 1.0.0, so I'm assuming something big happened :_
[22:16] <Makyo> :)
[22:17] <Makyo> bcsaller, when you get back, in package.json, set jshint's version to "0.9.1" rather than ">=0.9.1"
[22:19] <hatch> haha
[22:19] <hatch> aww man this routes stuff is kicking my a$$
[22:35] <hatch> bcsaller: is the _dispatch method in app.js a monkeypatch for the YUI one in Router?
[22:35] <hatch> I now finally have all of the route parsing business done (and only 2 lines lol)
[22:35] <hatch> but now it's barfing on dispatch
[22:39] <hatch> bcsaller: maybe we can pair tomorrow to solve this?
[22:52] <gary_poster> bcsaller, I made a review of your Landscape aggregation branch.  Please rustle up another one.
[22:55] <bcsaller> hatch: yes, its overridden
[22:55] <hatch> yeah I attempted to make my way through it but I think it's best if we work together on this integration part
[22:55] <hatch> would that be alright?
[22:56] <bcsaller> sure
[22:56] <hatch> great - I figure we should be able to get it done in <1h tomorrow
[22:58] <gary_poster> Makyo, appcache info: thanks! LGTM with trivials
[22:58] <gary_poster> (and actually fly-bys)
[23:03] <hatch> if one reviewer has comments and the next has nothing to add but agrees with reviewer 1
[23:03] <hatch> what should they put? land as is? or....
[23:03] <hatch> land with other changes?
[23:08] <hatch> I chose "Land with Gary's trivials" :)
[23:14] <hatch> has anyone ever evaluated using https://github.com/airportyh/testem ?   If you look at it and think it is worth incorporating into our tools you could do so and propose it some Friday or other.
[23:30] <hatch> sure I can look into it


[18:37] <ibeardslee> morning
[18:47] <snail> morning
[19:06] <ajmitch> morning
[20:33] <thumper> morning


[05:58] <mborzecki> morning
[06:09] <mborzecki> mvo: hey
[06:10] <mvo> hey mborzecki
[06:23] <mup> PR snapd#7608 closed: o/snapstate, etc: SnapState.Channel -> TrackingChannel, and a setter <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7608>
[06:30] <mborzecki> school run, back in 30
[06:32] <zyga> hey
[06:32] <zyga> working on regression test for bug from Friday
[06:33] <mvo> hey zyga !
[06:33] <mvo> zyga: did you identify the bug ? is it a difficult one?
[06:34] <mvo> zyga: also thanks for 7662 and friends
[06:34] <mvo> zyga: I cherry pick this now
[06:44] <mup> PR snapd#7674 opened: interfaces: de-duplicate emitted update-ns profiles (2.42) <Created by mvo5> <https://github.com/snapcore/snapd/pull/7674>
[07:02] <mborzecki> re
[07:04] <zyga> mvo: re, sorry, some morning school interrupts
[07:04] <zyga> mvo: not sure  yet
[07:04] <zyga> mvo: give me one hour
[07:06] <mvo> zyga: sure
[07:06] <mvo> zyga: thanks for looking into this
[07:31] <zyga> mvo: not super hard
[07:31] <zyga> mvo: not kernel or anything like that
[07:31]  * mvo hugs zyga
[07:31] <zyga> mvo: just overlooked and underused feature
[07:48] <zyga> mvo: workaround is tiny
[07:48] <zyga> mvo: proper fix requires a little bit more logic
[07:48] <zyga> mvo: I'll send workaround patches in one hour
[07:49] <zyga> mvo: should we have a 2.42.1 milestone on launchpad
[07:50] <mvo> zyga: feel free to add it
[07:50] <zyga> ok
[08:01] <pstolowski> morning
[08:03] <mborzecki> pstolowski: hey
[08:19] <mup> PR snapd#7666 closed: tests: don't depend on GNU time <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7666>
[08:21] <mup> PR snapd#7668 closed: tests: tweak wording in mount-ns test <Simple 😃> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7668>
[08:30] <mup> PR snapd#7675 opened: osutil: preseed mode helper <Prebaking> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7675>
[08:33] <mup> PR snapd#7676 opened: many: cherry pick test updates for 2.42 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7676>
[08:38] <mup> PR snapd#7677 opened: interfaces/content: workaround for renamed target <Created by zyga> <https://github.com/snapcore/snapd/pull/7677>
[08:39] <pedronis> pstolowski: hi, to discuss 7675, can you make a list of the packages that would need to query PreseedMode ?
[08:40] <pstolowski> pedronis: sure, will do
[08:41] <zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/7677
[08:41] <mup> PR #7677: interfaces/content: workaround for renamed target <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7677>
[08:41] <zyga> mborzecki: it's a priority customer request
[08:43] <zyga> mvo: the test passed a single run, force pushed with commit typo and running across all machines
[08:47] <zyga> mborzecki: could you send a patch that disables xdelta for amazon?
[08:47] <zyga> mborzecki: for the resend in spread
[08:49] <pstolowski> pedronis: updated (added to the description)
[08:51] <mborzecki> zyga: the lzo with xdelta thing pops up on amazon?
[08:52] <zyga> mborzecki: yes, when invoked locally
[08:52] <zyga> https://www.irccloud.com/pastebin/MKaHiW7M/
[08:54] <pstolowski> pedronis: if the concern is about having a global flag like this vs passing it around, my suggestion is to have it available though the helper first like proposed (in whatever package we find suits best), then replace it with something final after all the bits are in place
[08:56] <pedronis> pstolowski: where exactly is it used in apparmor ?
[08:57] <pedronis> in loadProfiles ?
[08:57] <pstolowski> pedronis: yes - to have --skip-kernel-load
[09:14] <mup> PR snapd#7678 opened: spread: disable secondary compression for deltas <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7678>
[09:14] <mborzecki> zyga: ^^
[09:14] <zyga> 1-2-1
[09:14] <zyga> thx
[09:16] <pedronis> pstolowski: can we have a quick HO in ~15 ?
[09:16] <pstolowski> pedronis: yes
[09:31] <pedronis> pstolowski: going to the standup
[09:31] <pstolowski> pedronis: ok, coming
[09:39]  * Chipaca can't stand up yet
[09:43] <Chipaca> mvo: any feedback on #7669 vs #7670?
[09:43] <mup> PR #7669: snap, cmd/snap: support (but warn) deprecated multi-slash channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/7669>
[09:43] <mup> PR #7670: cmd/snap: support (but warn) using deprecated multi-slash channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/7670>
[09:45] <mup> PR snapd#7635 closed: tests/lib/gendevmodel: helper tool for generating developer model assertions <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7635>
[09:51] <pedronis> Chipaca: I haven't looked at them yet? what's the difference between, the summary says they are the same
[09:52] <pedronis> Chipaca: do we have code for daemon yet?
[09:53] <Chipaca> pedronis: the second one uses channel.Full instead of .Parse, I think it results in simpler code (the explanation is onthe second one, at the end of the description)
[09:54] <Chipaca> i'll have the daemon up before the standup today
[09:54] <pedronis> ok, thx
[09:54] <Chipaca> i think it's the last bit left
[09:54] <pedronis> Chipaca: plus reintroducing the code about risk switching
[09:54] <pedronis> that we had to revert
[09:54] <pedronis> it will probably need a rewrite though
[09:55] <Chipaca> pedronis: i wouldn't count that as part of this, but, yes that is also missing
[09:55] <Chipaca> pedronis: and then defaults
[09:55] <pedronis> yes
[09:55] <Chipaca> pedronis: some of this work will need tweaking for defaults, fwiw
[09:55] <pedronis> yes
[09:55] <Chipaca> as here we always do Full, and on install with defaults we need to not do so
[09:56] <Chipaca> i was tempted to do that from the start but thought better leave it simple for now
[09:56] <pedronis> Chipaca: no, the Full is probably fine, the question is more where the value comes from
[09:56] <Chipaca> anyway, got a meeting coming up, need to set up
[10:01] <mvo> Chipaca: was in a meeting
[10:04] <mup> PR snapd#7679 opened: many: changes to testing in preparation of Core 20 seed consuming code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7679>
[10:09] <mup> PR snapcraft#2771 opened: python plugin: skip download and wheel for local sources <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2771>
[10:24] <zyga> mvo: https://github.com/snapcore/snapd/pull/7677 is ready for review
[10:24] <mup> PR #7677: interfaces/content: workaround for renamed target <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7677>
[10:25] <zyga> mborzecki, pstolowski ^ priority customer bug
[10:25] <zyga> trivial code change + tests + rationale
[10:31] <pstolowski> zyga: looking
[10:32] <zyga> thank you guys
[10:39] <zyga> mvo: https://github.com/snapcore/snapd/pull/7677 is green
[10:39] <mup> PR #7677: interfaces/content: workaround for renamed target <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7677>
[10:39] <pedronis> reviews for #7672 and #7679 would great, they are mostly reorg in preparation of actual Core 20 seed loading code
[10:39] <mup> PR #7672: seed: share auxInfo20 and makeSystemSnap via internal <Created by pedronis> <https://github.com/snapcore/snapd/pull/7672>
[10:39] <mup> PR #7679: many: changes to testing in preparation of Core 20 seed consuming code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7679>
[10:47] <mvo> Chipaca: 7622 is ready for a review (after you finished the other things of course :)
[10:47] <Chipaca> mvo: thanks
[10:56]  * dot-tobias hi everybody
[11:19] <zyga> mvo: do you want to get a security review for https://github.com/snapcore/snapd/pull/7677
[11:19] <mup> PR #7677: interfaces/content: workaround for renamed target <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7677>
[11:19] <zyga> otherwise it's green and we could build a new edge core/snapd snap next
[11:25] <zyga> brb
[11:28] <mvo> zyga: sounds like we can merge and ask security for a retrospective one
[11:28] <mvo> zyga: it will just be on edge
[11:33] <mvo> mborzecki: 7302 has a conflict now
[11:35] <zyga> mvo: ok, mering
[11:36] <mup> PR snapd#7677 closed: interfaces/content: workaround for renamed target <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7677>
[11:36] <zyga> mvo: can you please remind me how to correctly trigger edge build, do I need to just do the snap build request or do I need to ensure the intermediate git is synchronized somehow?
[11:41] <mvo> zyga: for the snapd it will all happen automaitcally
[11:41] <mvo> zyga: for old school core its spread-cron that needs to merge a git tree first
[11:42] <mvo> zyga: https://travis-ci.org/snapcore/spread-cron/branches
[11:42] <zyga> mvo: so just "sit tight"?
[11:42] <mvo> zyga: and "snapd-vendor-sync" there
[11:42] <mvo> zyga: yeah or manually triggering this one
[11:50] <mup> PR snapd#7680 opened: daemon: parse and reject invalid channels in snap ops <Created by chipaca> <https://github.com/snapcore/snapd/pull/7680>
[12:08] <zyga> there's another thing called snap https://ai.google/research/pubs/pub48630/
[12:08] <zyga> at some point everything will just be called foo, I guess
[12:15] <cmatsuoka> hello everyone
[12:15] <cmatsuoka> did we have a timezone shift at some point in the past two weeks?
[12:16] <cmatsuoka> I see all events in my calendar shifted one hour, and my time zone is correct
[12:18] <pstolowski> cmatsuoka: hey Claudio, welcome back!
[12:20] <pstolowski> cmatsuoka: yes, we switched from summer time yesterday
[12:21] <cmatsuoka> ah ok, I just wanted to make sure everything is consistent and I won't miss any meeting
[12:25] <zyga> mvo: refresh-app-awareness just got more complicated
[12:25] <zyga> cmatsuoka: hey :)
[12:26] <zyga> I need to sync with stgraber
[12:34] <mup> PR snapd#7678 closed: spread: disable secondary compression for deltas <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7678>
[12:41] <zyga> mvo: I have some ideas on how to fix this
[12:41] <zyga> mvo: would love to sync
[12:41] <zyga> mvo: feels like a week or two of work though
[12:41] <zyga> mvo: but would solve some issues in general without bothering us in the future
[12:43] <zyga> mvo, mborzecki: I updated the last comment on https://github.com/snapcore/snapd/pull/7547 with some details
[12:43] <mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
[12:44] <pedronis> zyga: isn't how we do the tracking vs the other bits of awareness orthogonal anyway?
[12:45] <zyga> pedronis: some are intersecting, the agent is something we need the cgroup for
[12:45] <zyga> pedronis: we can re-design without the agent being present
[12:45] <zyga> pedronis: and continue work on the UX without that
[12:46] <zyga> pedronis: the cgroup gives us tracking without breaking systemd and a possibility to install the agent
[12:46] <pedronis> you mean the release the agent?
[12:46] <zyga> yes
[12:46] <zyga> I need to stop and think for a moment
[12:46] <zyga> on how to proceed
[12:47] <zyga> I need to make more tea anyway
[12:47] <zyga> perhaps we can work on part of the UX without the agent now and progress towards _a_ solution that would not affect LXD or be affected by LXD
[12:47] <zyga> and then integrate this so that the UX works only better
[12:47] <zyga> and the backend changes silently behind the scenes once everything is aligned
[12:48]  * zyga -> tea
[12:56] <ijohnson> Wait so now the SU is in 1 hr
[12:56] <ijohnson> Right?
[12:57] <cmatsuoka> ijohnson: yes, it seems so
[12:57] <ijohnson> Hmmm
[12:57] <cmatsuoka> ijohnson: end of dst in europe
[12:58] <ijohnson> cmatsuoka: do you follow daylight savings time? The US switches next week so next week it seems to go back to 8 am local for me
[12:58] <ijohnson> But this week it's at 9 am local
[12:58] <ijohnson> I saw a few weeks ago on my calendar the time went to 9 AM and was kinda excited at the prospect of having 9 am meetings all winter
[12:59] <cmatsuoka> ijohnson: for me it was 10AM local time, now it's 11AM
[12:59] <ijohnson> Yeah it was 8 am on Friday now it's 9 am local for me
[13:01]  * ijohnson is quite confused that the timezone switch between US and EU don't at least happen at the same time
[13:02] <cachio> mvo, is the standup delayed 1 hour?
[13:03] <cachio> I didn't receive the update
[13:03] <cachio> it used to be automatic
[13:05] <cmatsuoka> cachio: the standup should be 11AM in our timezone
[13:06] <cachio> cwayne, yes
[13:07] <cachio> cmatsuoka, yes}
[13:08] <cwayne> :)
[13:10] <Chipaca> cachio: the time didn't change, but the timezone did :)
[13:10] <Chipaca> it's all the german farmers fault
[13:11] <cachio> hhhehe
[13:12] <cwayne> Chipaca: thats who i blame all my problems on tbh
[13:12] <cwayne> bad run? german farmers did it.
[13:15] <pedronis> I commented a bit on some of the channels PRs, 7670 seems good to me, assuming we don't want a special error msg in 7680
[13:15] <pedronis> Chipaca: ^
[13:48] <Chipaca> pedronis: ack
[13:51] <Chipaca> cwayne: i haven't run in the last month because of my knee
[13:51] <mup> PR snapcraft#2772 opened: remote-build: improve resiliency for https connection issues <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2772>
[13:51] <Chipaca> cwayne: also the germans' fault
[13:52] <cwayne> Chipaca: thats rough, mine's been wonky as hell lately too
[13:53] <cwayne> damn germans
[13:54] <Chipaca> cwayne: wonky knees, doo doo doo
[13:55]  * cwayne has baby shark stuck in my head now
[14:51] <mup> PR snapcraft#2773 opened: build providers: inject snapd snap for latest feature availability <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2773>
[14:54] <mup> PR snapcraft#2774 opened: remote-build: architecture handling <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2774>
[14:59] <Chipaca> sergiusens: <3 2773
[14:59] <sergiusens> Chipaca: your review would be appreciated :-)
[15:10] <mup> PR snapcraft#2775 opened: remote-build: add clean flag <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2775>
[15:37] <mup> PR snapcraft#2776 opened: repo: convey proper error message when refreshing to invalid channel <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2776>
[15:40]  * cachio lunch
[16:09]  * zyga finished talking to mborzecki and EODs
[16:09] <zyga> mvo: sorry, the UX doc needs to wait, I'm exhausted by the complexity today
[16:09]  * mborzecki too
[16:22] <pedronis> cachio: we are getting (again?) errors like:   systemctl restart systemd-journald.service
[16:22] <pedronis> Job for systemd-journald.service failed.
[16:22] <pedronis> See "systemctl status systemd-journald.service" and "journalctl -xe" for details.
[16:23] <pedronis> cachio: https://api.travis-ci.org/v3/job/603911307/log.txt
[16:27] <Chipaca> pedronis: if we are, i can try my proposed fix this evening
[16:34] <Chipaca> pedronis: nearly finished reviewing 7679, but going to go out and do some exercise for a bit, will bbl
[16:37]  * Chipaca pokes a few other things before going
[16:48] <mup> PR snapd#7672 closed: seed: share auxInfo20 and makeSystemSnap via internal <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7672>
[16:59] <cachio> pedronis, I'll take a look
[17:28] <cachio> degville, hey
[17:28] <cachio> I just updated the testing blogpost
[17:28] <cachio> with the feedback
[17:28] <degville> cachio: hello! want me to take a look?
[17:28] <cachio> when you have a time could yo uplease take a look
[17:28] <cachio> a quick one please
[17:28] <degville> cachio: yes, of course - no problem.
[17:28] <cachio> degville,thanks!!!!
[17:55] <mup> PR snapcraft#2773 closed: build providers: inject snapd snap for latest feature availability <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2773>
[17:55] <mup> PR snapcraft#2774 closed: remote-build: architecture handling <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2774>
[19:22] <degville> cachio: I've just read through your post again - made a few comments on the changes, but really only minor suggestions!
[19:23] <cachio> degville, thanks a lot, I'll address them
[19:23] <degville> cachio: np!
[19:32] <kyrofa> Thanks guys for putting this room together to help us all with host networking (https://ai.google/research/pubs/pub48630/)
[19:33] <kyrofa> Google likes snap things. https://github.com/google/snappy
[19:33] <Pharaoh_Atem> libsnappy predates snapd, iirc
[19:34] <kyrofa> Oh I'm well aware :P
[19:51] <ijohnson> jdstrand_: hey is there any reason not to include usr/bin/paste in the base policy? that program is in both core and core18 and doesn't seem to pose any obvious security problems to me and it would simplify some shell scripting I'm doing :-)
[19:55] <jdstrand> ijohnson: hey, no, I'll add it to my list. I plan to do a misc policy updates PR for 2.43 and will add this
[19:55] <ijohnson> thanks jdstrand
[20:10] <mup> PR snapcraft#2776 closed: repo: convey proper error message when refreshing to invalid channel <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2776>
[20:13] <mup> PR snapcraft#2677 closed: erorrs: preserve quotes when printing SnapcraftPluginCommandError <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2677>
[20:34] <mup> PR snapcraft#2777 opened: cli: pass channels None when not doing a push --release <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2777>
[20:38] <mup> PR snapd#7622 closed: snap: make `snap known --remote` use snapd if available <Needs Samuele review> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7622>
[20:38] <Chipaca> whoops
[20:38] <Chipaca> pedronis: i just noticed yours was not one of the +1's on 7662 :-(
[20:40] <mup> PR snapd#7681 opened: tests: add info that could be used to determine why journalctl is failing to restart <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7681>
[20:40] <Chipaca> pedronis: any issues you had with it can be addressed in 7624 though so that's probably ok
[20:41] <pedronis> Chipaca: I marked myself long ago, mostly because of xerrors
[20:41] <pedronis> but then there was a prereq one already landed
[20:41] <Chipaca> pedronis: ah ok :) that's sorted with #7667
[20:41] <mup> PR #7667: spread: enable bboozzoo/snapd-devel-deps COPR repo for getting golang-x-xerrors <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7667>
[20:41] <pedronis> Chipaca: my other question is how long it takes to fail?
[20:41] <pedronis> s/fail/fallback/
[20:43] <Chipaca> pedronis: next to nothing
[20:43] <Chipaca> pedronis: there's no retrying, is what i mean
[20:43] <pedronis> ok
[20:43] <Chipaca> when it's 'the socket isn't there' at least :)
[20:44] <pedronis> ah
[20:44] <Chipaca> i guess you could have a hung snapd that makes things slower
[20:44] <pedronis> anyway that's the main case
[20:44] <pedronis> the next one doesn't seem to pay attention to auth though?
[20:45] <Chipaca> 7624?
[20:45] <pedronis> yes
[20:45] <Chipaca> I'm waiting for the master merge before looking at that one
[20:45]  * Chipaca lazy
[20:45] <pedronis> ok
[20:45] <Chipaca> pedronis: but auth is a quick fail so should be handled ok
[20:45] <pedronis> anyway I marked it as I need to look at it
[20:45] <Chipaca> i'll be looking out for it in any case
[20:45] <pedronis> yea, my point is I don't think the code is looking for it
[20:45] <pedronis> atm
[20:46] <Chipaca> hmmm
[20:46] <Chipaca> i think i reviewed something along those lines in this context
[20:46] <Chipaca> a previous pr about download
[20:46] <Chipaca> i'll have a dig
[20:47] <Chipaca> pedronis: i'll take the dog for a walk before the temperature drops more, then i'll have a look
[20:47] <Chipaca> i think it might already be handled but not sure, don't remember exactly
[20:47] <Chipaca> anyway, ttfn
[20:50] <pedronis> same here
[20:50] <pedronis> ttfn
[21:07] <mup> PR snapcraft#2772 closed: remote-build: improve resiliency for https connection issues <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2772>
[22:40] <mup> PR snapcraft#2777 closed: cli: pass channels None when not doing a push --release <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2777>
[23:56] <mup> PR snapcraft#2768 closed: remote-build: autorecovery <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2768>