[07:33] <didrocks> mmrazik: hey, in case you didn't see my comment: https://code.launchpad.net/~ps-jenkins/window-mocker/latestsnapshot/+merge/147433
[07:46] <mmrazik> didrocks: didn't see it. In the last week or so I've seen several branches not being marked as merged by launchpad
[07:47] <mmrazik> didrocks: its launchpad who is changing the state, right? Not the bot...
[07:47] <mmrazik> seen it 4-5 times or so last week
[07:47] <didrocks> mmrazik: oh, right, it's LP, Friday evening mind's screwup :)
[07:47] <mmrazik> didrocks: but it is weird that the diff was generated empty
[07:47] <didrocks> mmrazik: so a trigger in LP didn't work I guess
[07:47] <didrocks> mmrazik: the diff is generated everytime trunk changes
[07:47] <mmrazik> didrocks: that was my assumption, yes
[07:47] <mmrazik> didrocks: I don't think that is true
[07:48] <mmrazik> or at least I've never seen a diff to change once it is generated
[07:48] <mmrazik> only if the candidate branch changes
[07:48] <didrocks> mmrazik: same, I don't have the real rule, but I've definitively see new conflicts generated sometimes
[07:48] <didrocks> without the candidate branch changes
[07:48] <mmrazik> magic...
[07:48] <didrocks> it's a little bit of black magic for me
[07:48] <didrocks> yep :)
[07:48] <mmrazik> :)
[07:56] <didrocks> Mirv: hey, did you see that seb added some more infos on your Qt branches?
[07:57] <didrocks> Mirv: and some were rejected, can you please before we do our hangout ensuring that all licenses reflect the files in the project?
[07:59] <Mirv> didrocks: hi. actually I haven't noticed that.
[08:00] <Mirv> didrocks: licenses need to be re-checked module by module, but at least regarding the added license files all modules have code that fall under those
[08:01] <didrocks> Mirv: apparently not from what seb is telling, I didn't check TBH
[08:01] <Mirv> didrocks: where is that info?
[08:02] <Mirv> oh, a new column in the doc..
[08:02] <Mirv> too far on the right
[08:02] <didrocks> Mirv: yep, "New review comments"
[08:02] <Mirv> ok then
[08:02] <didrocks> Mirv: do you mind having a look for all project before we resume the hangout?
[08:02] <didrocks> just ping me once you are ready :)
[08:03] <Mirv> didrocks: ok
[08:03] <didrocks> thanks!
[08:09] <jibel> any idea why on a default install, compiz would load the font 'Nanum Gothic' (along with more standard ones)? This alone consumes 400kB of memory.
[08:11] <didrocks> jibel: I saw you g+ post, I think it's Nux, let me check
[08:12] <jibel> I couldn't figure why with fontconfig in debug mode
[08:12] <didrocks> hum, didn't find it straight away, looking quickly over nux/compiz/unity code, but I'm sure Nux is doing some stuff with fonts (or at least, did in the past)
[08:12] <didrocks> so I wouldn't be surprised if this is the root cause
[08:16] <jibel> yeah but it is really not trivial to find because there are lot of criteria involved in font matching
[08:17] <didrocks> indeed
[08:43] <Mirv> didrocks: ok we could have something now
[08:43] <didrocks> Mirv: great, coming :)
[10:59] <popey> JohnLea: when you initiate spread in raring, the windows which get zoomed out all get resized down by a small factor, and then resized back up again when you come out of spread. Is this intentional? It causes redraws of the applications being spread, unncessarily so IMO.
[10:59] <JohnLea> popey: let me test, and I will get back to you
[10:59] <JohnLea> thanks for the heads up
[11:02] <popey> JohnLea: see http://popey.com/~alan/max.png and http://popey.com/~alan/spread.png for an example. the VirtualBox application window gets resized ~28px smaller causing a full desktop redraw in the vm.
[11:03] <JohnLea> popey; yes, that sounds to me like a bug, the spread should be scaling (not resizing) the windows.
[11:04] <popey> ok, I'll file it
[11:04] <JohnLea> popey; thanks!  I'd also recommend asking smspillaz about it
[11:04] <popey> roger
[11:04] <JohnLea> popey; ping me the bug # when done, thx!
[11:05] <popey> roger roger
[11:05] <andyrock> popey, JohnLea The spred does scale the windows
[11:06] <JohnLea> andyrock; so that is desired behaviour?
[11:06] <andyrock> JohnLea, no I think the problem here is the decoration
[11:10] <andyrock> JohnLea, but the right guy to talk about it is Trevinho here
[11:10] <JohnLea> popey; ^
[11:10] <JohnLea> andyrock; thx
[11:11] <andyrock> btw let me check the code
[11:13] <popey> andyrock: JohnLea bug 1121941
[11:13] <andyrock> popey, it happens just for maximized windows, right?
[11:14] <popey> good question
[11:14]  * popey tries
[11:14] <andyrock> popey, thx
[11:15] <popey> andyrock: yes, maximised windows only
[11:15]  * popey edits title of bug
[11:16] <andyrock> popey, http://paste.ubuntu.com/1636066/
[11:16] <andyrock> line 9-10
[11:16] <andyrock> i think these lines trigger the issue
[11:17] <andyrock> but IIRC we draw a fake decoration for maximized windows in the spread
[11:18] <andyrock> so it should not be needed
[11:18] <andyrock> but let's wait Trevinho
[11:20] <andyrock> this could explain also bug https://bugs.launchpad.net/compiz/+bug/1039942
[11:20] <smspillaz> andyrock: if WindowManager::Decorate sets MWM_DECOR in _MWM_HINTS then compiz will re-decorate and resize the window
[11:20] <smspillaz> I don't think its related to 1039942 though
[11:38] <andyrock> popey, ok I've a branch that fixes the issue
[11:39] <andyrock> i just need to do some more tests with special app/window (chrom*, etc)
[11:44] <sil2100> :)
[11:49] <sil2100> didrocks: hi! A thing related to the search-testing as part of libcolumbus... maybe for now we could merge the AP test code even now? I would just comment out the app lens fuzzy tests, as those are failing without columbus
[11:49] <didrocks> sil2100: sounds good to me then :)
[11:49] <sil2100> didrocks: this way we would have some time to test the search code a bit
[11:49] <sil2100> In a real testing environment
[11:50] <didrocks> sil2100: yep, please do not hesitate :-)
[11:50] <sil2100> didrocks: ok :)
[12:14] <sil2100> didrocks: hm, do you know if the Window Mocker name will be translated into many languages?
[12:15] <didrocks> sil2100: we shouldn't up until we need it for other tests
[12:15] <didrocks> that's IMHO :)
[12:15] <didrocks> at worse, we can have 2 desktop files
[12:15] <didrocks> one translated and launching the app
[12:15] <didrocks> and another one untranslated and shipping with LANG=C
[12:21] <sil2100> For me it would be better if we didn't for now as well
[12:33] <Trevinho> popey, JohnLea, andyrock: it happens because we have to re-decorate a maximized window in order to be able to draw on it its decoration...
[12:34] <Trevinho> popey: this was needed for the scale, however due to some changes I did recently for the alt+tab spread, I think we can avoid this... But I need to look further at it
[12:41] <smspillaz> heh, I remember when I did the same thing about two years ago now and ran into the same problem :p
[12:41] <smspillaz> the solution of course being just drawing the decoration pixmap, but we have the ability to do that now
[14:39] <mterry> didrocks, you said in your email that UTAH is fixed?  We made some progress?
[14:40] <didrocks> mterry: hey, the local.rc fix is supposed to land soon
[14:40] <didrocks> mterry: but anyway, with the power outage, we can't really know yet :)
[14:42] <mterry> didrocks, local.rc?  I may have missed a conversation
[14:43] <didrocks> mterry: they were two known issues for provisionning an image, one is bug #1118581
[14:43] <didrocks> mterry: the other (the Friday evening one) was a file conflict in the default packages
[14:43] <didrocks> aborting the install
[14:43] <mterry> right
[14:44] <didrocks> both are fixed
[14:44] <didrocks> now, we need to wait for the QA lab to be up again
[14:44] <didrocks> well, the magners machine rather
[14:44] <didrocks> (the rest is up)
[14:44] <mterry> Yup.  OK
[14:44] <mterry> didrocks, have a good weekend?
[14:45] <didrocks> mterry: was nice, quite some snow here as well, so didn't do anything too exciting ;-) yourself?
[14:47] <mterry> didrocks, just stayed inside through most of our snowstorm.  Thankfully I don't have a car, so was quite happy watching everyone else digging out their cars
[14:49] <didrocks> mterry: yeah, it's the time as well I enjoy to only rent a car when I'm needing it :)
[15:16] <mterry> didrocks, what do you use to make snapshot packages of the various unity upstreams?
[15:16] <didrocks> mterry: do you talk about the upstream tarball?
[15:17] <mterry> didrocks, yeah
[15:19] <didrocks> mterry: so, I'm using the split mode of bazar to do that. This is down in a cowbuilder chroot, where I sign the source package (after installing the build-deps)
[15:20] <didrocks> mterry: look at the chroot-tools/ directory, containing the .pbuilderrc and buildsource-chroot tool
[15:22] <mterry> thanks
[16:09] <didrocks> mterry: oh, I would have 2 MIRs for you to look at if possible
[16:10] <didrocks> mterry: qt5chooser, I'll ask Mirv_ to give the rationale soon (it's needed for coinstalling Qt4 & 5 on the same machine for a dev env, but he knows more than I)
[16:11] <didrocks> mterry: for libcolumbus, I think we can prepare things a little bit before, wdyt? cyphermox, do you mind prepping a MIR for it? (Satoris is upstream)
[16:13] <mterry> didrocks, k
[16:13] <didrocks> thanks mterry :)
[16:13] <mterry> didrocks, cyphermox : poke me with bugs when you have them
[16:13]  * didrocks goes back to Qt5 and headaches
[16:15] <cyphermox> ok!
[16:17] <didrocks> thanks cyphermox ;)
[16:23]  * davmor2 hands didrocks some paracetamol there now it's just qt5
[16:23] <didrocks> davmor2: thanks, would be a big help :)
[16:35] <Mirv> mterry: qtchooser is the upstream recommended and Debian adopted tool to co-install dev executables of Qt4 and Qt5, so needed now for libqt4-dev and developing with Qt5. it replaces the manually patching to add suffixes and alternatives system used earlier.
[16:37] <mterry> Mirv, sure
[16:42] <mterry> Mirv, is there a bug for its MIR yet?
[16:43] <mterry> Mirv, didrocks said qt5chooser.   But you say qtchooser.  Which package name is it?  I notice that qtchooser is already in main
[16:43] <didrocks> mterry: sorry, was qtchooser
[16:44] <mterry> didrocks, it's in main now it looks like.  Is this an after-the-fact mir?
[16:47] <didrocks> mterry: yeah, sorry, didn't give you context :)
[16:47] <didrocks> mterry: it's based on the upload of qt4-x11 we did Friday
[16:48] <didrocks> and yeah, after-the-fact MIR
[16:48] <cyphermox> didrocks: mterry: who will upload li
[16:48] <cyphermox> *libcolumbus
[16:48] <cyphermox> like, ETA for the upload?
[16:49] <mterry> didrocks, but no bug yet?  Can you or Mirv file a bug and I'll start looking
[16:49] <mterry> cyphermox, don't know
[16:49] <didrocks> cyphermox: this week? with daily release
[16:49] <cyphermox> ok
[16:49] <didrocks> mterry: that's why I ask Mirv to give you the info, to get a bug :)
[16:50] <didrocks> cyphermox: it's needed prior the new hud
[16:50] <didrocks> so tomorrow if jenkins is back :)
[16:50] <cyphermox> hud is what b-deps on it right?
[16:50] <didrocks> cyphermox: yeah, or is already, look at the MP :)
[16:51] <didrocks> sorry, still on Qt5 and really really needs paracetamol I guess…
[16:51] <mterry> Mirv, can you please file a MIR bug with the info you gave me  on IRC?  https://wiki.ubuntu.com/MainInclusionProcess
[17:06] <cyphermox> mterry: are doing any other MIRs currently?
[17:06] <cyphermox> libcolumbus also needs libsparsehash-dev; I'll write the mir now unless you're already working on it
[17:07] <mterry> cyphermox, I'm not working on it.  Please write it up
[17:07] <mterry> I'll review once written
[17:07] <cyphermox> ack
[17:10] <davmor2> hey guys why does quantal look like this http://ubuntuone.com/6eZ84ok0EYTNWcGWOVzoCG and raring look like this http://ubuntuone.com/52xxNl1j5swOuyDo7SNWUa
[17:13] <bregma> davmor2, can you be more specific about which difference you're referring to, and what you're expecting?
[17:14] <davmor2> bregma: I'm expecting them to look the same they are the same track the only difference is the distro series
[17:15] <davmor2> the size of the dash is irrelevant
[17:16] <mterry> davmor2, looks like the only difference is the cover art?
[17:16] <mterry> davmor2, the banding on top and bottom is expected
[17:16] <davmor2> mterry: album name
[17:16] <mterry> I guess one has left arrow and other has right arrow.  I don't know if that is expected
[17:16] <bregma> davmor2, I see you have the dash configured in full-screen mode in your raring example, and the album cover art is missing, and the raring example is using the new raring assets instead of the quantal assets, but it would be good to know more clearly what you're expecting
[17:17] <mterry> davmor2, album name looks the same to me.  "Running Up That Hill" in both
[17:18] <davmor2> mterry: oh yes sorry I was seeing the title on the image my fault
[17:19] <bregma> question is, why is the album art missing?
[17:21] <davmor2> bregma: that's the big question
[17:21] <davmor2> I'm just checking through by all accounts there is no album art displayed for any track
[17:22] <bregma> all I can suggest is that the dash and scopes are going through some significant development at the moment, and that there may be an impledence mismatch somewhere i the stack that will get irond out in time
[17:23] <davmor2> bregma: and the full screen is a default this is a vanilla install for testing
[17:24] <bregma> I just searched for that album with today's raring build and got the cover art in the preview
[17:25] <davidcalle> davmor2, bregma: regarding album art. With Rhythmbox as the default, we depend on it for album art, it needs to be closed at least once to list the album art it has feched in its db, then the lens can pick it up.
[17:25] <davidcalle> s/list/add
[17:28] <davmor2> davidcalle: Nope also oddly if RB is closed and I click on a track it isn't played it just opens the player
[17:29] <davidcalle> davmor2, interesting :/
[18:07] <cyphermox> mterry: https://bugs.launchpad.net/ubuntu/+source/sparsehash/+bug/1122265
[18:08] <cyphermox> mterry: https://bugs.launchpad.net/ubuntu/+bug/1122269
[18:09] <cyphermox> libcolumbus isn't in the archive yet so I can't match it to the package yet
[18:09] <mterry> k
[18:17] <sil2100> \o/
[18:29] <smspillaz> sil2100: can I modify the "unity" shellscript to not kill compiz when it runs "--replace"
[18:29] <smspillaz> shellscript/python file/whatever
[18:30] <smspillaz> its a hack that just causes problems, and the reason for it existing isn't there anymore.
[18:46] <sil2100> smspillaz: oh, so it's not needed anymore?
[18:46] <sil2100> smspillaz: in this case, I think we can just remove it
[18:47] <sil2100> Trevinho: hi! Are you around?
[18:49] <sil2100> See you later everyone
[19:04] <mterry> fginther, without the staging PPA, if I want to try to reproduce crashes that jenkins is seeing or whatever, how do I use the same packages as Jenkins?
[19:05] <fginther> mterry, jenkins uses an http archive for the packages it builds.
[19:05] <mterry> fginther, an archive that I could point to, I assume?
[19:05] <fginther> mterry, it's possible to use that instead as long as the test system has VPN access (I've done this)
[19:06] <mterry> fginther, OK, cool.  Then I don't mind staging going away
[19:06] <fginther> mterry, the packages are not archived anywhere, so if you needed a specific package that was not the latest, you would be out of luck (which I think is the way the PPA works as well)
[19:06] <mterry> true
[19:11] <mterry> oh hey, jenkins is back up
[19:12] <mterry> cyphermox, do you know if you think the indicator stack will build cleanly now/
[19:12] <mterry> ?
[19:13] <mterry> hmm, the autopilot ati/intel/nvidia machines are still offline though
[19:22] <cyphermox> mterry: I think so
[19:22] <cyphermox> but yeah, depends on the machines being up ;)


[00:41] <jrmy> ok so my alsa driver is up to date
[00:41] <jrmy> how do i get it to use my onboard?
[00:41] <jrmy> there apparently are 3 devices
[00:41] <jrmy> there are*
[00:48] <jedijf> jrmy: aplay -l   will list your devices (in terminal)
[00:48] <jedijf> alsamixer is always a good place to start with sound...no MM's and pcm up
[00:49] <jrmy> well i have one.. but its not working when i try playing a music file
[00:49] <jrmy> so i guess i'll get alsamixer
[00:49] <jrmy> sudo apt-get alsamixer?
[00:49] <jedijf> try alsamixer in the terminal
[00:52] <jrmy> odd even after switching to the sound card i still cant hear the mp3
[00:54] <jrmy> i just updated my alsa driver too
[00:54] <jrmy> maybe the jack is broken?
[00:55] <jrmy> there is another sound card i can test
[00:56] <jrmy> but i dont see why i cant hear an mp3
[01:00] <jrmy> not the wrong jack.. clearly labeled
[01:00] <jrmy> any ideas?
[01:00] <jrmy> just tried watching a youtube video and no sound either
[01:02] <jedijf> did you try alsamixer and make sure it's not muted(MM) and pcm is up?
[01:04] <jrmy> ah.. stuff was muted
[01:04] <jrmy> lol
[01:04] <jrmy> i remember that error that it said once
[01:05] <jrmy> sweet
[01:06] <jrmy> how would i tell if it sets it to m.. i suppose i could just save the session and it will reboot without mutes
[01:06] <jrmy> lol.. finally
[01:07] <jrmy> heh, you know what.. this is why i liek linux.. its fun to me to have to fix problems
[01:07] <jrmy> windows is boring most of the time.. problems make things more interesting
[01:07] <jrmy> and when the problems are solved it feels great :D
[01:10] <jrmy> i wonder if its illegal to have other operating systems on a ps3
[01:11] <jrmy> i remember reading the terms of agreements and it didnt specifically say if you couldnt
[01:11] <jrmy> well as far as i could understand it.. anyways probably innapropriate for this channel
[01:11] <jrmy> thanks for the help
[01:21] <jedijf> jrmy: no prob...play...learn..break stuff
[01:23] <jrmy> :]
[02:10] <JonathanD> knightzero: hey.
[02:23] <InHisName> jrmy is all helped up and gone.
[02:45] <InHisName> jedijf: that worked just GREAT!
[10:59] <JonathanD> Morning PA
[11:14] <rmg51> morning JonathanD
[11:20] <InHisName> morning JonathanD
[11:20] <JonathanD> Morning guys
[11:21]  * JonathanD is looking for more speakers for fosscon...
[14:19] <knightze1o> Good morning, all.
[14:21] <JonathanD> hi.
[14:21] <JonathanD> bye
[15:30] <knightzero> exit
[15:30] <andrew> exit
[15:30] <andrew> hrm, didn't work
[15:30] <andrew> I'm still here
[15:43] <JonathanD> howdy knightzero
[15:47] <knightzero> Morning JonathanD
[16:07] <InHisName> Howdy all - knightzero, andrew, JonathanD    what great experiments can we do today to help me procrastinate my studies ?
[16:24] <andrew> you can play with the chrome experiments
[16:30] <knightzero> I've been dabbling in distributed computing - providing a nice load for my air conditioner in my home office.  Might be worth tinkering with.
[16:31] <JonathanD> this is why my heavy gear is in the basement :P
[16:33] <knightzero> I've been thinking of getting a rack for my attic - I'll still have to cool it, but at least the bellowing air conditioner won't be a foot from my head when I'm at my desk.
[16:33] <JonathanD> http://jdsnetwork.com/images/100_2770.JPG is my basement.
[16:34] <JonathanD> someone threw out a rack here, I tried to find someone to take it but no one could get it :/
[16:37] <knightzero> I wish I'd known - I'll put a homeless rack to good use any day.
[16:38] <JonathanD> I'm using a stereo cabinet :P
[16:45] <InHisName> JonathanD: you have SUN equipt.  r u running Solaris ?
[16:45] <JonathanD> InHisName: someone else has that now
[16:45] <JonathanD> I gave it to someone at lilug.
[16:46] <InHisName> what does lilug stand for ?
[16:46] <JonathanD> long island linux users group
[16:46] <InHisName> u live on LI ?
[16:46] <JonathanD> No. I live in Bridgeport, PA.
[16:47] <JonathanD> But I go to/host events all over the place.
[16:47] <JonathanD> Our camping trip gets a fair few from NY
[16:47] <InHisName> Closer to me,  actually probably half way between.
[16:48] <InHisName> what are the big 4 things in foreground ?  IBM servers ?
[16:48] <JonathanD> Yes.
[16:48] <JonathanD> My vmware environment.
[16:48] <InHisName> how many cores total among the 4 boxes ?
[16:48] <JonathanD> They're pretty old ;)
[16:49] <InHisName> XEONs?
[16:49] <JonathanD> Only 8 cores, at 1.6Ghz, as I recall.
[16:49] <JonathanD> PIII class xeons.
[16:49] <JonathanD> 4GB ram in each box.
[16:49] <JonathanD> Running ESXi
[16:50] <InHisName> OH,  I just bought a 1 U server made in '05  dual XEONs dual core  2.8Ghz  8 mem sockets.  Bought 16gigs but only recognizes half of it.  Beeps and fails if I fill all the slots.
[16:51] <InHisName> 39lbs  1Ux19"x26"
[16:51] <JonathanD> I love my IBMs
[16:51] <JonathanD> you see the table they're on?
[16:51] <InHisName> interesting now that I look at it.
[16:51] <JonathanD> The table collapsed.
[16:52] <JonathanD> They all kept working, although I had to pry PS2 pins out of some of the keyboard/mouse sockets
[16:52] <InHisName> before or after the picture ?
[16:52] <JonathanD> before.
[16:52] <JonathanD> I didn't even know it happened til I went down to get something.
[16:53] <JonathanD> They were still running and active :)
[16:53] <InHisName> YOu were RDP into them and never much looked at the hardware ?
[16:53] <JonathanD> depends on what I'm doing.
[16:53] <JonathanD> I usually just access it all from my laptop
[16:53] <InHisName> virtualBox is so cool
[16:53] <InHisName> I like it better than vmware
[16:53] <JonathanD> I'm down there if I need to use the workbench but otherwise not so much anymore.
[16:53] <JonathanD> InHisName: I like ESXi as it's tiny.
[16:54] <JonathanD> theres no full distro to keep updated.
[16:54] <InHisName> that s a virt system too?
[16:54] <JonathanD> Yeah. it's an OS of sorts, though.
[16:54] <JonathanD> You install it on the hardware, the VMs sit on top of it.
[16:54] <JonathanD> There is no "host OS"
[16:54] <InHisName> Loads on bare metal, then?
[16:54] <JonathanD> The machine boots into vmware.
[16:55] <JonathanD> You pretty much then do everything remotely.
[16:55] <InHisName> ESXi is a vmware product ?
[16:55] <JonathanD> Yes
[16:55] <JonathanD> and ESXi is free.
[16:55] <JonathanD> The full on ESX is not free.
[16:55] <JonathanD> There are some servers with an ESXi on flash built in.
[16:55] <InHisName> vbox headless works like that but needs a host OS same as normal one.
[16:56] <JonathanD> http://www.vmware.com/products/vsphere-hypervisor/overview.html
[16:56] <PennBot> Title: Free VMware vSphere Hypervisor: Bare Metal Hypervisor (Based on VMware ESXi) (at www.vmware.com)
[16:58] <InHisName> The vmware I used made LOTS of extra files in one dir fortunately but still seems like a lot of support waste.  vbox hardly uses much more than the VDI file itself.   That one does sound intriguing
[16:58] <JonathanD> I quite like it.
[16:58] <JonathanD> I have mine setup with an NFS store for the VMs.
[16:58] <JonathanD> Any of those 4 boxes can start any VM.
[16:59] <JonathanD> I have some scripts in place that will move VMs all to one box, if I'm not going to use them for a while, so they can keep running without the power draw of all 4 boxes.
[16:59] <InHisName> Have you compared it to MS hypervisor ?
[16:59] <InHisName> Does only one have clear better features ?
[17:00] <JonathanD> well, ESXi has always had solid linux support, where MS it's sort of an afterthought.
[17:00] <JonathanD> Aside from that, I've not spent a ton of time on it.
[17:00] <JonathanD> vmware has been at this a long time, and I've been a vmware user for near a decade now.
[17:00] <InHisName> Measured the KW from the 4 boxes in idle mode ?
[17:01] <InHisName> i c
[17:01] <JonathanD> they pull about 12 amps.
[17:01] <JonathanD> well, the whole circuit does.
[17:01] <JonathanD> Theres switches and stuff on it though, too.
[17:01] <JonathanD> and 12 was "at boot"
[17:01] <InHisName> That's quite a bill if run 24x7
[17:01] <JonathanD> with the drives spinning up and such.
[17:01] <JonathanD> Theres usually only one running.
[17:02] <JonathanD> I think idle, with VMs runnig but not active, was bout 4.
[17:02] <JonathanD> I try to use them less during the summer, so I can just run on the one :p
[17:02] <InHisName> do you have a manager that starts up hardware and shuts down based on demand of use ?
[17:02] <JonathanD> not directly.
[17:02] <JonathanD> Just a "collapse" and "restore" thing.
[17:03] <JonathanD> collapse takes all the VMs on 3 of the machines, suspends them, then resumes them on the remaining one.
[17:03] <InHisName> Now that would be real cool.  Then could back down to one or even less if you do nothing.
[17:03] <JonathanD> then shuts them down.
[17:03] <JonathanD> restore does the opposite.
[17:04] <JonathanD> except I never bothered to setup WOL so I have to turn them on first.
[17:04] <JonathanD> lunchtime
[17:04] <InHisName> eat hearty!
[17:43] <InHisName> anyone who can advise fixing any erorrs in setting up bind would be helpful  http://pastebin.ca/2048322
[17:43] <PennBot> Title: pastebin - Untitled - post number 2048322 (at pastebin.ca)
[18:35] <jedijf> @seen mutantturkey
[18:35] <PennBot> jedijf: mutantturkey was last seen in #ubuntu-us-pa 4 days, 16 hours, 48 minutes, and 56 seconds ago: <MutantTurkey> bark bark
[19:25] <waltman> Vusi Mahlasela was just talking about Ubuntu on The World Cafe!
[19:26] <waltman> not the distro, the concept
[19:26] <MutantTurkey1> world cafe live?
[19:26] <waltman> "Ubuntu" sounds much cooler when spoken by a South African
[19:26] <MutantTurkey1> haha
[19:26] <waltman> no, that's the music venue. the radio show's just called "the world cafe"
[19:27] <waltman> do I need to explain what "radio" is to you kids?
[19:30] <MutantTurkey1> yes i know
[19:30] <MutantTurkey1> but the show is from the venue right?
[19:31] <waltman> Close. The show's from WXPN, which is attached to WCL.
[19:31] <MutantTurkey1> ah okay
[19:32] <MutantTurkey1> some good bands play there
[19:38] <JonathanD> whoa, compiz works on the T41 :D
[19:38] <JonathanD> It hasn't worked for agggggggges.
[19:38] <teddy-dbear> http://www.xpn.org/
[19:39] <PennBot> Title: WXPN 88.5 FM :: Public Radio from the University of Pennsylvania home (at www.xpn.org)
[19:41] <JonathanD> although I can't get the rain to work :p


[00:05] <ibeardslee> the upcoming ubuntu release is the first in I don't think I have gone rushing off installing it on a PC or laptop at the beta stage
[00:07] <ibeardslee> .. oh .. it has been released
[00:27] <mwhudson> oh yeah
[00:27] <mwhudson> i guess i should upgrade?
[00:32] <ibeardslee> I'm considering leaving my work PC as the LTS, as that is what we 'support' internally
[00:33] <ibeardslee> anyone capable of upgrading or installing a non-Ubuntu LTS version of Linux is 'capable' of looking after it themselves
[00:34] <ibeardslee> .. reminds me I should puppetise the 'Notify for the long-term support versions'
[01:19] <kcj[work]> Morning.


[10:48] <Laney> sil2100: starting this review by rebasing your branch
[10:48] <Laney> conflicts /o\
[12:00] <Laney> alright, done I think, was a bit hairy at times
[12:00] <Laney> sil2100: I'm going to force push that to your branch - would you mind rearranging the commits, merging temporary ones and so on so they tell a logical story please? After lunch I will give a review on the code itself :-)
[12:03] <Laney> (hopefully I didn't break it 😬)
[13:28] <xnox> teward:  my question about restarting, is mostly about "after we fix network-online.target during firstboot; what do we do during the remainder of the machine runtime" since networking does come and go.
[13:29] <xnox> vorlon:  it was not trolling, but actual concert / upstream position statement. Just because one fixes the ordering during firstboot, it doesn't help with the lifecycle.
[13:33] <teward> xnox: I think then thats a larger issue that goes beyond SystemD.  Because then we have to define every possible case for what a 'network reload' is and that will get very complex quickly.  Most good utils I find needing that level of sensitivity already have their own tests in place, and anything requiring DNS is not going to be able to follow the usual tests (rtelink tracking etc) to ID if its up or not - at that point it becomes a
[13:33] <teward> software issue for those pieces of software moreso than a systemd issue in my opinion
[13:33] <teward> at that point its a can of worms and a rabbit hole so...
[13:35] <sil2100> Conflicts again?!
[13:36] <sil2100> Laney: ok, let me get to that in a moment once I'm done with this NEW review
[13:38] <sil2100> Laney: some time ago I merged trunk to avoid conflicts, but from that time there prorbably was some changes pushed - sorry about that
[13:39] <xnox> teward:  the systemd upstream stance is that a service should stay up; itself know what it needs; and retry/backoff.
[13:39] <xnox> teward:  for example, on ubuntu, in standard configuration dns resolution is available After=systemd-resolved.service And if dns name fails to resolve, it should just poll and retry.
[13:40] <xnox> teward:  i'm not advocating that we need or should support restarting services, that are not smart enough to retry things themselves.
[13:40] <teward> ack.
[13:41] <teward> thats a given in most services heh
[13:43] <xnox> teward:  is the unit service in question does mounts or exports?
[13:44] <xnox> teward:  cause i would have thought that anything that does network mounts (aka nfs client) should be part of the remote-fs.target which already should be after network.target
[13:44] <teward> xnox: ERR:NotTheInitialFilerOfQuestion
[13:44] <xnox> teward:  ack.
[13:45] <teward> xnox: i just weighed my opinions in here and was unsure of the scope of the discussion hence my showing up
[13:45] <teward> ;)
[13:45] <xnox> teward:  cause i wanted to say, surely we can convert all of those things into systemd generator of the .mount units which systemd seems to handle fine for nfs ;-)
[13:45] <xnox> ack
[13:46] <teward> xnox: no disagreement, but it goes back to "customized configs after install" which goes back to rbasak's opinion
[13:47] <teward> nothing I have uses at boot nfs mounts heh.  Except VMware which... is not Ubuntu xD
[14:06] <Laney> sil2100: no worries, the main branched moved quite rapidly in the last few weeks once we deployed
[15:47] <vorlon> xnox: this was all about the nfs server, not nfs mounts; the root bug in the thread was about /etc/exports using DNS names and not being guaranteed to be able to resolve those until after network-online.target, thus making an unreliable boo
[15:48] <vorlon> t


[05:39] <RickJames_B> anyone try to use a hdpvr with the newest mythbuntu
[05:39] <RickJames_B> 1212 hdpvr
[05:52] <RickJames_B> i cant seem to get it to show video on frontend it errors out. I did get it to work for a few min then it stopped and now no video
[05:52] <RickJames_B> my hd home runs work fine
[09:36] <qwebirc49202> Issue with 0.27.3+fixes.20140924.629f711-0ubuntu0mythbuntu2 going to 100%, top indicates the thread at 100% is SSDP


[01:25] <Son_Goku> yay...
[01:25] <Son_Goku> somebody broke the packaging for snapd in Fedora in snapd git
[01:25] <Son_Goku> I think I'm going to have to resync from Dist-Git asap
[01:25] <Son_Goku> it's also broken for 2.29
[05:54] <mborzecki> morning
[06:29] <mborzecki> mvo: morning
[07:00] <kalikiana> moin moin
[07:23] <mborzecki> guys, what's with the nested functions in libsnap-confine-private?
[07:24] <mvo> hey mborzecki
[07:24] <mborzecki> mvo: hey
[07:25] <mvo> mborzecki: good morning! what in particular? this is mostly the baby of zyga, however review/cleanup is always good
[07:25] <mvo> mborzecki: it might have gotten less reviews than the average other code we have
[07:25] <mborzecki> yeah, i was a bit tired with arch fixes so i went on and tried checking the lower level C bits with sparse and now build it with clang
[07:25] <mvo> mborzecki: well, thats not true, it got a different kind of reviews, very security focused mostly
[07:26] <mvo> mborzecki: cool, what are your findings so far?
[07:26] <mborzecki> a bunch of signed/usigned comparisons
[07:26] <mvo> mborzecki: we ran it through coverity a while ago
[07:26] <mvo> mborzecki: aha, neat, lets fix those
[07:26] <mborzecki> sprinkled some statics here and there, added voids in function arguments where possible
[07:27] <mborzecki> clang chokes on nested functions though, I don't think it's actually supported outside of gcc
[07:29] <mborzecki> btw. that's actually weird that coverity did not pick up signed/unsigned stuff, i remember it to be very picky
[07:32] <mvo> mborzecki: indeed, not sure what happend, maybe it was too long ago, I would have to check my mail history. having some static analyizing that happens regularly as part of each build ideally would be way better
[07:34] <mborzecki> yeah, i'll tune CFLAGS there to something more useful, it's -Wall -Werror right now, there should albo be -Wextra at least
[07:34] <mvo> mborzecki: +1
[07:34] <mvo> mborzecki: great to have a fresh new set of eyes looking at this
[08:18] <mup> PR snapd#4150 opened: ifacestate: make interfaces.Repository available via state cache <Created by mvo5> <https://github.com/snapcore/snapd/pull/4150>
[08:42] <zyga-ubuntu> o/
[08:42] <zyga-ubuntu> good morning
[08:44] <mvo> hey zyga-ubuntu
[08:45] <zyga-ubuntu> hey, sorry for starting late today
[08:45] <zyga-ubuntu> how are things?
[08:49] <mborzecki> zyga-ubuntu: hey
[08:49] <zyga-ubuntu> hey :)
[08:54] <mvo> zyga-ubuntu: things are mostly good, a test failure for 2.29.2 on pi3 which is annyoing but mostly test breakage not real issues it seems
[08:55] <mvo> zyga-ubuntu: i.e. arm seems to return EPERM for cgroup access denials and x86 EACCESS
[08:55] <zyga-ubuntu> oh
[08:55] <zyga-ubuntu> that's intereting
[08:56] <zyga-ubuntu> just last week I recall jdstrand and tyhicks discuss EPERM vs EACCSS on various syscalls
[08:56] <zyga-ubuntu> it seems that it varies from one syscall to another
[08:56] <mvo> and annoying because it means 2.29.2 is not in candidate yet :/
[08:56] <zyga-ubuntu> and thus, perhaps, varies from arch to arch
[08:56] <mvo> yeah, the pattern isnot consistent
[09:05] <sergiusens> mvo are you guys paying attention to the adt results?
[09:06] <mvo> sergiusens: generally speaking yes, things were very slow with the opening of bionic so we may have missed some data because of this in the most recent few days. why?
[09:06] <mvo> sergiusens: all releases go through the regular autopkgtest distro testing so yes, we are generally autopkgtest clean
[09:07] <sergiusens> mvo oh, because of the slowness, was wondering if you where interested in our approach of launching them on demand (after a review) so resources don't starve
[09:08] <sergiusens> there are many tests for the same branch of a snapd PR enqueued, which I guess comes after minor review fixes and such
[09:08] <zyga-ubuntu> I think adt could use the concept of travis automatic job cancellation
[09:09] <zyga-ubuntu> so only one such instance exists for the same branch (the latest one)
[09:09] <mvo> sergiusens: we are definitely interessted, cachio was working on this, but because of other work this is a bit slow going crrently
[09:09] <sergiusens> zyga-ubuntu yeah, it is nice to think of ideals others can do, and there is a bug for that; I am talking about things we can do ;-)
[09:09] <zyga-ubuntu> sergiusens: no disagreement there
[09:09] <mvo> sergiusens: yeah, we definitely want to stop starving the distro
[09:10] <mvo> sergiusens: and there is work, its just slow right now because of other duties
[09:10] <mvo> sergiusens: I will connect you with cachio, sounds like you guys have figured it out already
[09:10] <mvo> sergiusens: or is it trivial? if so I can have a look in a bit myself
[09:11] <sergiusens> mvo zyga-ubuntu we have a telegram and irc bot if interested. We've been using this approach for a while now
[09:11] <sergiusens> mvo for hooking up; elopio and cachio could hook up and discuss
[09:11] <zyga-ubuntu> sergiusens: I saw you use this multiple times and I was indeed intrigued
[09:12] <zyga-ubuntu> sergiusens: it seems like a better way to use our resources, last-phase test after review and travis say it's oK
[09:12] <sergiusens> most of it is based out of this https://github.com/snapcore/snapcraft/blob/master/tools/retry_autopkgtest.sh
[09:12] <sergiusens> zyga-ubuntu that is what we do; we also run a nightly with travis' cron for sanity checks
[09:13] <sergiusens> I don't know if you suffer this, but we get dns/proxy errors all the time on non-x86 so running on every PR just became noise
[09:13] <zyga-ubuntu> no, we don't suffer those
[09:14] <sergiusens> yeah, I guess we hammer the system a bit more given we build stuff for like 3 hours min for every run :-P
[09:17] <mvo> sergiusens: cool, thanks. do you know where the result of the runs are stored? or is retry-github-test synchronous ?
[09:18] <sergiusens> mvo it adds the entry to the PR (just as if it were triggered by the webhook)
[09:18] <mvo> sergiusens: sweet
[09:21] <sergiusens> mvo if you want more automation that having to trigger, you cold run something like that script as the last step of your travis run (keeping the secret as an encrypted var on travis)
[09:23] <mvo> sergiusens: btw, are you up early or traveling (if I may ask :)
[09:40] <mup> PR snapd#4151 opened: tests: fix security-device-cgroup* tests on devices with framebuffer <Created by mvo5> <https://github.com/snapcore/snapd/pull/4151>
[09:41] <zyga-ubuntu> wow, nice!
[09:41] <zyga-ubuntu> approved, thank you mvo!
[09:42] <sergiusens> mvo I woke up at 4am; just early ;-)
[09:45]  * mvo hugs sergiusens
[09:46] <sergiusens> there's just so much to do and so little time
[09:52] <mborzecki> where can I get spread images?
[09:52] <zyga-ubuntu> mborzecki: you can build them youself or get them from spread.zygoon.pl
[09:52] <zyga-ubuntu> spread images are just images with well known user/password
[09:52] <zyga-ubuntu> nothing maic
[09:52] <zyga-ubuntu> *magic
[09:53] <zyga-ubuntu> if you have a way please contribute a build command for arch linux
[09:53] <zyga-ubuntu> I can refresh my images periodically (just was too lazy to set it up before)
[09:53] <mborzecki> ok
[09:53] <mborzecki> my first time using spread :) i'll probably have a lot of questions, so bear with me
[09:54] <zyga-ubuntu> gladly :)
[09:55] <mup> PR snapd#4152 opened: snapd: fix snap cookie bugs <Created by stolowski> <https://github.com/snapcore/snapd/pull/4152>
[09:59]  * zyga-ubuntu reads 4152
[10:03] <mup> PR snapd#4153 opened: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup lowe level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
[10:04] <mup> Issue snapcraft#1658 opened: Map of supported bases to containers <design-required> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1658>
[10:04] <mup> Issue snapcraft#1659 opened: Schema support for supported bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1659>
[10:04] <mup> Issue snapcraft#1660 opened: Container passthrough for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1660>
[10:07] <zyga-ubuntu> mborzecki: are you trying to build snap-confine with clang?
[10:07] <mborzecki> yeh, it builds now
[10:07] <mup> Issue snapcraft#1661 opened: Walk the prime directory for elf files (in lifecycle) <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1661>
[10:07] <mup> Issue snapcraft#1662 opened: patchelf with ld-linux <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1662>
[10:07] <mup> Issue snapcraft#1663 opened: patchelf with common rpath (not runpath) <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1663>
[10:08] <zyga-ubuntu> mborzecki: is clang becoming a default in arch?
[10:08] <mborzecki> not that I know of
[10:08] <zyga-ubuntu> so why?
[10:11] <mup> Issue # opened: snapcraft#1664, snapcraft#1665, snapcraft#1666, snapcraft#1667, snapcraft#1668
[10:11] <mborzecki> to start with, clang is usually better with finding errors, but the best outcome is to usually build the code with both gcc and clang
[10:12] <mborzecki> and then you have initiatives like debian clang, that try to rebuild the whole archive using clang
[10:12] <zyga-ubuntu> I think that unless we can test build this with clang it will quickly bitrot
[10:12] <zyga-ubuntu> I don't mind the initiative just hoping it can stay something we really support (or not) but explicitly
[10:13] <mborzecki> well, i left a note about this in the PR, 'We should aim to integrate at least clang builds into the CI pipeline.'
[10:13] <mborzecki> and basically that's why i asked about spread images
[10:14] <mup> Issue snapcraft#1669 opened: patchelf with ld-linux from the future <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1669>
[10:14] <mup> Issue snapcraft#1670 opened: Change file migrations such that files move from stage to prime rather than coming from the part each time <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1670>
[10:14] <mup> Issue snapcraft#1671 opened: Rename prepare/build/install to pre-build/build/post-build, and deprecate prepare/build/install <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1671>
[10:14] <mborzecki> if this does not make sense, feel free to point that out and I'll stop with the PR that's already opened
[10:17] <mup> Issue # opened: snapcraft#1672, snapcraft#1673, snapcraft#1674, snapcraft#1675, snapcraft#1676, snapcraft#1677
[10:20] <mup> Issue snapcraft#1678 opened: Support for set-summary <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1678>
[10:20] <mup> Issue snapcraft#1679 opened: Support for set-name <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1679>
[10:20] <mup> Issue snapcraft#1680 opened: Documentation overhaul for pre/post and setters <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1680>
[10:20] <zyga-ubuntu> mborzecki: I think it's fine, just trying to understand your motivation better
[10:20] <pstolowski> pedronis, hey! i've proposed the PR for cookies problem. re your questions from Friday about why cookie is not removed in UnlinkCurrentSnap for example - it's deliberate. we're interested in having a single cookie for given snap regardless of revisions or whether the snap is enabled or disabled. we create the cookie when we install the snap for the first time, and we remove the cookie when the last revision is discarded
[10:21] <pedronis> pstolowski: ok, I'll look at it with that in mind
[10:21] <pstolowski> thanks
[10:22] <Chipaca> i thought we weren't adding more patches until we got epochs working?
[10:22] <zyga-ubuntu> Chipaca: I think this patch is "special"
[10:22] <zyga-ubuntu> Chipaca: it's not really a patch
[10:22] <zyga-ubuntu> we could even do it in one of the managers at startup
[10:23] <Chipaca> it still breaks reverts
[10:23] <Chipaca> so the reason we're not doing patches is still there
[10:23] <zyga-ubuntu> just by virtue of incrementing the patch level?
[10:23] <Chipaca> yes
[10:23] <zyga-ubuntu> ah
[10:23] <zyga-ubuntu> then yes, it cannot be a patch
[10:26] <pedronis> as not a patch it will need a flag, that we can remove when we have patches I suppose
[10:31] <pedronis> mvo: I cannot make the standup, but we need to talk with Gustavo about moving  snapctl start/stop/... etc from 2.29 to 2.30 in the roadmap topic
[10:32] <mup> Issue snapcraft#1681 opened: Make architectures grammar-powered <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1681>
[10:33] <mvo> pedronis: sure, I will raise that
[10:35] <mup> Issue # opened: snapcraft#1682, snapcraft#1683, snapcraft#1684, snapcraft#1685
[10:35] <mvo> pedronis: 4150 is something I would appreciate your review, should be (hopefully) easy as its closely copied^Wmodelled after how the assertdb is handled
[10:36] <ackk> Chipaca, hi, I added some comments/replies on https://github.com/snapcore/snapd/pull/3916
[10:36] <mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
[10:43] <Chipaca> ackk: yep, it's in my queue
[10:44] <pedronis> mvo: I'll look at it today
[10:45] <ackk> Chipaca, thanks. I addressed some of the comments, fwiw
[10:46] <mvo> pedronis: thank you
[10:46] <mborzecki> zyga-ubuntu: do you think splitting tests/unit/c-unit-tests into c-unit-tests-gcc & c-unit-tests-clang will be enough?
[10:59] <zyga-ubuntu> mborzecki: yes
[10:59] <zyga-ubuntu> mborzecki: that's fine and it will clearly show what's what
[10:59]  * pedronis lunch+dentist appt
[10:59] <mborzecki> testing this locally now
[11:00] <mborzecki> also made me go through how spread testing is setup, looks like adding arch will not be that complicated
[11:01] <zyga-ubuntu> most of the complexity is concentrated in "prepare.sh" where we build snapd and prepare the system for testing
[11:04] <mborzecki> while i'm waiting for spread to finish, did anyone get a chance to look at https://github.com/snapcore/snapd/pull/4135#issuecomment-342002622 ?
[11:04] <mup> PR #4135: cmd/{snap-seccomp,snap-confine-ns},osutil,interfaces/account_control: workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135>
[11:05] <mborzecki> i'm leaning towards removing tests/main/static and i'm not sure this would be acceptable, but the packaging (fedora, suse) do not build snapd statically, so I don't know what exactly this tests is supposed to check
[11:06] <Chipaca> mborzecki: if it's the CGO_ENABLED check, it was because we'd had problems with cgo stuff sneaking in through depends that was impacting memory consumption at one point
[11:06] <zyga-ubuntu> mborzecki: commented on your questions
[11:07] <Chipaca> and that was an easy way to block it
[11:11] <mborzecki> ok, so one alternative way to fix this is to drop CGO_ENABLED=0 and set -extldflags, we can keep the test this way
[11:15] <Chipaca> mborzecki: how would that alert us of new cgo bits we didn't know about?
[11:15] <Chipaca> (that's basically what we need)
[11:17] <mborzecki> i won't, but it doesn't build now either, it did build before because no cgo built pieces were called yet
[11:21] <Chipaca> mborzecki: well, that's the whole purpose of the test, if it's not working why have it?
[11:24] <mborzecki> i could probably rework the group stuff to not call the c library, but instead parse /etc/groups directly, but this is half solution only, and probably 100% correct on musl systems only as glibc is happy to use nss instead
[11:29] <zyga-ubuntu> pstolowski: reviewed
[11:35] <niemeyer> Hello hello!
[11:35] <niemeyer> mborzecki: Welcome!
[11:35] <mborzecki> niemeyer: hey
[11:37] <mvo> hey niemeyer - welcome back
[11:37] <niemeyer> mvo: Thank you
[11:37] <niemeyer> Glad to be back
[11:40] <zyga-ubuntu> hey
[11:40] <mborzecki> zyga-ubuntu: pushed clang test as well
[11:41] <pstolowski> thanks zyga-ubuntu
[11:41] <pstolowski> hey niemeyer !
[11:41] <Chipaca> mborzecki: what if we just have panic'ing stubs for the no-cgo build? just for this check?
[11:41] <niemeyer> Heyos!
[11:43] <mborzecki> Chipaca: yeah, this might work
[11:43] <zyga-ubuntu> mborzecki: I just sent my review, let me read the new parts
[11:44] <kalikiana> hrm, failing to see the forest for the trees, time for a break
[11:45] <zyga-ubuntu> mborzecki: added two more comments
[11:46] <zyga-ubuntu> mvo: what shall I do with https://github.com/snapcore/snapd/pull/4146 ?
[11:46] <mup> PR #4146:  interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4146>
[11:47] <mup> Issue snapcraft#1686 opened: Support strings in grammar <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1686>
[11:50] <mup> Issue snapcraft#1687 opened: Make source grammar-powered <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1687>
[11:50] <mup> Issue snapcraft#1688 opened: Documentation for advanced grammar for sources <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1688>
[11:50] <mup> Issue snapcraft#1689 opened: Implement "on" and "from" selectors (statements) in project_loader <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1689>
[11:52] <mvo> zyga-ubuntu: lets leave it for now if we need a .3 I think we can consider it
[11:52] <mvo> zyga-ubuntu: I did not had the mental capacity last friday to include it
[11:53] <mup> Issue snapcraft#1690 opened: Design quilt support <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1690>
[11:53] <mup> Issue snapcraft#1691 opened: Implement quilt design <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1691>
[11:53] <mup> Issue snapcraft#1692 opened: snapcraft quilt tutorial <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1692>
[11:54] <mvo> zyga-ubuntu: what would happen if we build snap-cofnine with g++ (i.e. using c++ rules for the C part)? would it explode in size?
[11:54] <zyga-ubuntu> mvo: not sure, why would you want that?
[11:56] <mvo> zyga-ubuntu: to avoid having to write "foo(void)" when I mean "foo()"
[11:56] <mup> Issue snapcraft#1693 opened: Develop metadata handler system <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1693>
[11:56] <mup> Issue snapcraft#1694 opened: Develop appstream handler <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1694>
[11:56] <zyga-ubuntu> mvo: I don't think that's a very strong reason honestly
[11:56] <zyga-ubuntu> mvo: it's not C vs C++, just particular -W flag
[11:57] <zyga-ubuntu> perhaps we need to default to C99 or more recent
[11:58] <mvo> zyga-ubuntu: I checked and it seems C99 is also considering f() as unknown vs f() as empty (which is what we want)
[11:59] <zyga-ubuntu> f() as unknown?
[11:59] <mvo> zyga-ubuntu: well, maybe not, it just annoys me that backward compatiblity to 1877 requires us to write a clunky f(void) when e.g. c++ gets this right
[11:59] <mvo> zyga-ubuntu: yes, it means "don't assume anything about arguments"
[11:59] <mup> Issue snapcraft#1695 opened: Refactor meta into package <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1695>
[11:59] <mup> Issue snapcraft#1696 opened: Add schema checking for snap.yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1696>
[11:59] <mup> Issue snapcraft#1697 opened: Documentation for sources of information extraction <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1697>
[11:59] <mvo> zyga-ubuntu: f() means that
[11:59] <mvo> zyga-ubuntu: and apparently its for compatibility with older C programs (i.e. before K&R C). which makes me even more sad
[12:02] <mup> Issue # opened: snapcraft#1698, snapcraft#1699, snapcraft#1700, snapcraft#1701, snapcraft#1702, snapcraft#1703
[12:05] <mup> Issue snapcraft#1704 opened: Add unit tests for error classes <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1704>
[12:05] <mup> Issue snapcraft#1705 opened: Remove the current tests that assert exact error messages and only assert on the error class <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1705>
[12:29] <cachio> mvo, hey
[12:30] <niemeyer> mvo: Hey, did you start on monthly refresh scheduling already?
[12:31] <mvo> niemeyer: I have not started on this yet, I have started on the refresh-control things we talked about before (via snapd-control)
[12:31] <mvo> hey cachio
[12:32] <cachio> mvo, waiting for the confirmation of the cert team
[12:32]  * zyga-ubuntu ->coffee
[12:32] <niemeyer> mvo: Cool, I'm talking to mborzecki and will suggest he pick up that plus timer services shortly after it, if you're okay with that
[12:32] <cachio> mvo, other thing, did you take a look to the gsettings app?
[12:32] <cachio> snap
[12:32] <mvo> cachio: still not, sorry :/
[12:32] <mvo> cachio: is there an open PR for this?
[12:32] <mvo> niemeyer: sure, thats fine
[12:33] <cachio> mvo, no yet, waiting for the snap in the store
[12:33] <mvo> cachio: aha, ok. is it blocking on me uploading it?
[12:33] <cachio> mvo, I sent the branch, do you need it?
[12:33] <cachio> mvo, yes
[12:33] <mvo> cachio: if you could mail me the PR again, that would be great
[12:34] <cachio> mvo, there is a branch
[12:34] <cachio> mvo, should I create a PR?
[12:34] <cachio> mvo, it is gonna fail
[12:34] <mvo> cachio: branch is enough, just pass me the link and I have a look
[12:34] <mvo> cachio: but after lunch, gtg now :)
[12:34] <cachio> mvo, sure, thanks
[12:39]  * Chipaca dances
[12:39]  * Chipaca stops for lunch
[12:40] <mup> PR snapd#4154 opened: overlord/snapstate: support completion for command aliases <Created by chipaca> <https://github.com/snapcore/snapd/pull/4154>
[12:49] <Son_Goku> mvo, you guys somehow broke snapd packaging for Fedora
[12:49] <Son_Goku> it doesn't compile anymore
[12:52] <Son_Goku> gobuild: invalid option -- '-'
[12:52] <Son_Goku> error: Unknown option - in gobuild(o:)
[12:52] <Son_Goku> error: line 370: %gobuild -o bin/snap-update-ns  --ldflags '-extldflags "-static"' $GOFLAGS %{import_path}/cmd/snap-update-ns
[12:56] <zyga-ubuntu> Son_Goku: there's some tricky quoting there
[12:56] <Son_Goku> I already fixed this in my spec in Dist-Git
[12:56] <zyga-ubuntu> ah wait
[12:56] <zyga-ubuntu> no
[12:56] <zyga-ubuntu> s/bin/cmd/
[12:56] <Son_Goku> yeah you just can't do what you did
[12:56] <zyga-ubuntu> this is fixed in mater
[12:56] <Son_Goku> nope, master is broken too
[12:56] <Son_Goku> I tried
[12:56] <zyga-ubuntu> ??
[12:56] <zyga-ubuntu> what cannot you do?
[12:57] <Son_Goku> %gobuild does not let you pass --ldflags
[12:57] <zyga-ubuntu> the problem there is "bin => cmd"
[12:57] <Son_Goku> -o is the *output file*
[12:57] <zyga-ubuntu> ah
[12:57] <zyga-ubuntu> sorry, I must confused this with similar opensuse issue
[12:57] <Son_Goku> yeah, openSUSE issue is different
[12:57] <Son_Goku> their %gobuild macro works differently
[12:57] <Son_Goku> much more complicated
[12:58] <zyga-ubuntu> Son_Goku: hmm, but we do build s-u-n statically
[12:58]  * zyga-ubuntu wonders
[12:59] <mup> Issue snapcraft#1706 opened: Summary of errors at the end of build <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1706>
[13:02] <mup> Issue snapcraft#1707 opened: New UX for travis CI enablement <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1707>
[13:02] <mup> Issue snapcraft#1708 opened: Implement new design for travis CI UX <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1708>
[13:04] <mborzecki> it's -ldflags not --
[13:05] <mborzecki> Son_Goku: ^^
[13:06] <Son_Goku> ah
[13:15] <jdstrand> mvo: thank you for doing 4151
[13:18] <zyga-ubuntu> jdstrand: hello
[13:18] <jdstrand> hey zyga-ubuntu :)
[13:20] <jdstrand> mvo: I wonder if we should load a framebuffer module if /dev/fb0 doesn't exist instead of mocking it
[13:22] <ogra_> jdstrand, that might be tricky ... some of the framebuffer modules clash with kms
[13:22] <ogra_> (if we ever get armhf added to the tests)
[13:22] <jdstrand> I'm surprised that none of the VMs have an actual device. my Ubuntu Core 16 vm has one
[13:23] <jdstrand> I guess cause I chose qxl as the driver
[13:23] <ogra_> x86 should be okay with that though
[13:24] <jdstrand> ogra_: interesting
[13:24] <jdstrand> mvo: maybe instead of loading it, perhaps we should configure (at least some of) the VMs to have a framebuffer (eg, qxl or similar)
[13:25] <jdstrand> mvo: and then it would autoload. I was obviously thinking that the vms would have a framebuffer (all of mine do locally), but if nothing in the test infrastructure does, it means the test is rather pointless
[13:32] <mvo> Son_Goku: what is the build error?
[13:33] <Son_Goku> mvo: invalid invocation to the macro
[13:33] <mvo> Son_Goku: aha, nevermind
[13:33] <Son_Goku> I'm merging my changes into the git master spec now
[13:33] <Son_Goku> so I'll have a PR in a few minutes
[13:34] <mvo> jdstrand: in the standup right now, but you make import points
[13:34] <mvo> Son_Goku: \o/
[13:37] <jdstrand> mvo: if you could ping me to discuss whenever is convenient, that would be great
[13:41] <Son_Goku> mvo: also, why did snap-confine.1 become snap-confine.5?
[13:42] <mvo> Son_Goku: uh, that is a question for zyga-ubuntu
[13:42] <Son_Goku> or rather the other way around
[13:42] <Son_Goku> it went from 5 to 1
[13:43] <Son_Goku> ah, Debian bug
[13:43] <Son_Goku> meh
[13:52] <zyga-ubuntu> re
[13:53] <zyga-ubuntu> Son_Goku: thank you :-)
[13:53] <zyga-ubuntu> Son_Goku: there was a bug about the man page number from debian
[13:53] <zyga-ubuntu> Son_Goku: I changed that so the bug could be fixed
[13:53] <Son_Goku> yeah, I saw after git blame
[13:53] <Son_Goku> I'm surprised no one complained yet about snap being in the wrong section
[13:53] <zyga-ubuntu> ah, great, sorry for laggy response, I was on HO
[13:53] <Son_Goku> so... I have the beginnings of EL7 support now
[13:53] <zyga-ubuntu> Son_Goku: something I can look into this week,
[13:54] <zyga-ubuntu> oh, exciting
[13:54] <zyga-ubuntu> any issues so far?
[13:54] <Son_Goku> it was a pain to get it to compile :/
[13:54] <Son_Goku> https://copr.fedorainfracloud.org/coprs/ngompa/snapcore-el7/
[13:55] <Son_Goku> I think I'm going to have to do more enhancements to the SELinux policy again
[13:55] <Son_Goku> since it's completely untested, I don't think I should create the distro target symlink just yet
[13:56] <Son_Goku> also, unlike the fedora build, the centos build is vendorized
[13:56] <Son_Goku> so a litany of weirdness showed up during the build
[13:56] <mborzecki> zyga-ubuntu: do you think we should run c-unit-test-{gcc,clang} with -Werror so that it fails when on warnings?
[13:56] <zyga-ubuntu> ok
[13:57] <zyga-ubuntu> mborzecki: yes, that's sensible
[13:57] <Son_Goku> zyga-ubuntu: this is why I really need those multi-tarball releases as I asked mvo last year
[13:59] <mvo> Son_Goku: I was planning to do for the 2.29, do you need one for 2.28.5?
[13:59] <mup> PR snapd#4155 opened: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4155>
[13:59] <Son_Goku> mvo: nah, I don't care for 2.28
[14:00] <Son_Goku> I'm okay with jank preview crappiness for my copr build for 2.28
[14:00] <Son_Goku> but once I am more comfortable with the snapd build on CentOS, I don't want that anymore
[14:00] <Son_Goku> mvo, zyga-ubuntu: PR proposed
[14:01] <Son_Goku> this will need to be merged back into 2.29 as well
[14:04] <mvo> Son_Goku: thanks!
[14:08] <mvo> Son_Goku: https://github.com/snapcore/snapd/releases/tag/2.28.5 now has the "no-vendor" tarball that contains no vendor/ dir - so now we have one tar with vendor and one without. do you need more?
[14:08] <Son_Goku> mvo: basically, I just want a no-vendor tarball and a tarball containing *only* the snapd-<version>/vendor/ tree
[14:09] <Son_Goku> that way I can include both tarballs in dist-git unconditionally
[14:09] <mvo> Son_Goku: aha, only vendor - sure, let me add this too
[14:09] <Son_Goku> and only use the latter when I'm doing CentOS builds
[14:09] <Son_Goku> because I'm *really* not going to be having zyga-ubuntu do a bunch of go library packages for EL7
[14:09] <Son_Goku> it's not worth it when go is rebased every year
[14:10] <Son_Goku> mvo: this multi-tarball configuration will also help you deal with the delta between debian and ubuntu
[14:10] <Son_Goku> since debian purges the vendor/ tree
[14:13] <mvo> Son_Goku: ok, please check if https://github.com/snapcore/snapd/releases/tag/2.28.5 looks reasonable
[14:14] <Son_Goku> mvo: LGTM
[14:15] <mvo> Son_Goku: great, thats my updated script now, so things should hpefully be better from now on
[14:15] <Son_Goku> :D
[14:15] <Son_Goku> zyga-ubuntu: feel free to give this a go: https://copr.fedorainfracloud.org/coprs/ngompa/snapcore-el7/
[14:15] <Son_Goku> let me know how well it works (or doesn't work!)
[14:19] <zyga-ubuntu> I'll install centos
[14:20] <mborzecki> i'm out for today, leaving to pick up my kids, maybe I'll push another patch for #4153
[14:20] <mup> PR #4153: cmd/{snap-confine,libsnap-confine-private,snap-shutdown}: cleanup low-level C bits <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4153>
[14:21] <zyga-ubuntu> see you mborzecki
[14:25] <kalikiana> meh. was hunting what I thought was a syntax error. until I realized confinement was what prevented parsing from working at all.
[14:26] <pedronis> mvo: #4150 looks reasonable but I don't understand the need of the changes in overlord.New
[14:26] <mup> PR #4150: ifacestate: make interfaces.Repository available via state cache <Created by mvo5> <https://github.com/snapcore/snapd/pull/4150>
[14:28] <mvo> pedronis: yeah, I revert that one
[14:28] <mvo> pedronis: thank you!
[14:32] <pedronis> mvo: do you plan do add helpers?  (a bit like assertstate has) to ifacerepo? or just use the repo directly ?
[14:33] <pedronis> I suppose it also depends how far is the repo interface to what you actually need
[14:34] <mvo> pedronis: no helpers planned so far, the repo is rich enough for my use case
[14:34] <mvo> pedronis: but my use case is really simple
[14:34] <mvo> :)
[14:35] <zyga-ubuntu> the time of day when I change my vim color scheme :/
[14:35] <pedronis> mvo: it's fine,   assertstate has helpers, but there's also code that gets DB and does just Find, it depends
[14:35] <zyga-ubuntu> aha sunset
[14:35] <pedronis> mvo: I'm mostly asked because of the name of the package
[14:38] <mvo> pedronis: aha, ok
[14:39] <mvo> pedronis: I'm fine using something more generic, no strong opinion but for now that package is all I need
[14:54] <mup> Issue snapcraft#1709 opened: Extract macaroon retrieval into more generic place <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1709>
[14:54] <mup> Issue snapcraft#1710 opened: Research circle-ci <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1710>
[14:55] <pedronis> pstolowski: added a couple of high-level comments to the cookie PR
[14:55] <pstolowski> pedronis, thanks
[14:57] <mup> Issue snapcraft#1711 opened: Develop enable-ci circle-ci <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1711>
[14:57] <mup> Issue snapcraft#1712 opened: Tutorial for circle-ci <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1712>
[15:00] <mup> Issue snapcraft#1713 opened: catkin plugin: support for building all packages in a given workspace <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1713>
[15:00] <mup> Issue snapcraft#1714 opened: catkin plugin: recursively merge rosinstall files <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1714>
[15:00] <mup> Issue snapcraft#1715 opened: catkin plugin: detect and gracefully handle rosinstall clashes <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1715>
[15:02] <elopio> sergiusens: meeting?
[15:12] <Chipaca> hmm, looks like i need to take a bunch of days off
[15:12] <Chipaca> pedronis: mvo: niemeyer: any preference as to when i do this?
[15:14] <Chipaca> taking the last two weeks of the year off i still have 11 days
[15:16] <mvo> Chipaca: nothing in particular, but I have the same issue, I will probably take some days off in early Dec
[15:17] <Chipaca> i mean, i could take all of december off
[15:17] <Chipaca> but that's probably bad :-)
[15:28] <pedronis> I will take the last two weeks of december off
[15:28] <Chipaca> pedronis: as well as the shutdown, or including that?
[15:28] <pedronis> including shutdown
[15:29] <pedronis> I mean off from Dec 18
[15:29] <Chipaca> pedronis: right, even doing that i have 11 left
[15:29] <pedronis> you should have taken holidays before :)
[15:29] <Chipaca> yes.
[15:29] <pedronis> Chipaca: anyway you can keep some for the next year as well,  not sure that's a fix though
[15:30] <Chipaca> pedronis: i might do something like taking mondays off, and keep what's left for next year
[15:30] <Chipaca> or lose 'em, i mean i just took a week off less than a month ago
[15:30] <Chipaca> oh, no, i took two days off
[15:30] <Chipaca> it _felt_ like a week :-)
[15:30] <pedronis> heh
[15:30] <Chipaca> see that's the problem :-)
[15:32] <zyga-ubuntu> Chipaca: take all holidays on January
[15:32] <zyga-ubuntu> problem solved
[15:32] <zyga-ubuntu> I need to pick up my daughter as my wife is stuck in traffic, ttyl
[15:44] <elopio> sergiusens: the only explanation I see for the timeout is that the plugins suite is taking 100 minutes on autopkgtest. This suite takes 40 minutes in travis, and has worked on autopkgtests until last week, so my guess is that the system is overloaded making everything twice as slow.
[15:45] <sergiusens> elopio ok, that could explain it
[15:45] <sergiusens> cjwatson any idea how adt hosts are setup ^ ?
[15:45] <elopio> we can split the tests in autopkg like we do on travis. But that will be slower because for every test the deb is prepared, but it will give us a bigger margin on the timeout for when the system is overloaded. I'm not sure how often this will be.
[15:46] <sergiusens> elopio but these timeouts, are they present on amd64?
[15:46] <elopio> I'm looking at arm64. Let me check the amd64
[15:47] <niemeyer> Chipaca: You can roll one of the weeks on to next year, if you want
[15:48] <sergiusens> Chipaca taking days off without traveling away from $HOME always makes it feel like it is longer that it should be for me
[15:51] <elopio> sergiusens: the result we have available for amd64 shows that suite finishing in 3091s
[15:54] <sergiusens> so less than an hour
[15:58] <zyga-ubuntu> re
[16:00] <elopio> yes. I think splitting makes sense, at least until all our hello world builds take less than 1 minute. It will at least let us worry about real errors and not time outs.
[16:03] <cjwatson> sergiusens: none, ask Laney
[16:04] <cjwatson> sergiusens: (autopkgtest isn't LP, even though we share cloud regions)
[16:04] <sergiusens> cjwatson yeah, thanks; just got a hold of him on my random question about queuing on #ubuntu-release
[16:04] <sergiusens> apparently a cloud region died and things got bad
[16:05] <sergiusens> and the snapd queue which we already discussed on how to make it easier going
[16:15] <kalikiana> elopio: do test snapcraft.yaml files versus modifying them on the fly impact this? I was looking into build packages/ snaps tests which are all fixed, but you were suggesting we prefer creating them on the fly
[16:15] <kalikiana> kinda wondering if one or the other is faster
[16:19] <elopio> kalikiana: I don't think so. We can create a file in a lot less than a second.
[16:37] <jdstrand> roadmr: hi! re goby> I think I forget to rerun the review-- I didn't add the comment for granting classic to the snap, so I think I may have granted then got pulled away
[16:37] <roadmr> jdstrand: right, it's what I speculated in the bug
[16:38] <jdstrand> roadmr: I didn't see the bug. is there anything else I should do?
[16:39] <roadmr> jdstrand: I don't think so, the bug was about things being "stuck" but I explained the sequence of events which seems sensible. Let me find it for you
[16:39] <roadmr> jdstrand: https://bugs.launchpad.net/snapstore/+bug/1729826
[16:39] <mup> Bug #1729826: "Waiting for previous upload" when none in review queue <Snap Store:New> <https://launchpad.net/bugs/1729826>
[16:40] <elopio> sergiusens: do you know why our ppa is not building for armhf and arm64?
[16:43] <jdstrand> roadmr: thanks
[16:45] <mup> PR snapd#4156 opened: overlord/devicestate: switch to the new endpoints for registration <Created by pedronis> <https://github.com/snapcore/snapd/pull/4156>
[17:16] <sergiusens> elopio our ppa? snapcraft is architecture all
[17:19] <elopio> sergiusens: ahhh, of course, that is why it builds only once.
[17:21] <elopio> so, we won't have the unittests running in different architectures every day, but that's probably fine.
[17:42] <sergiusens> elopio what is this about building a deb everyday?
[17:42]  * sergiusens steps away for a bit
[17:44] <elopio> sergiusens: just trying to get rid of the make_beta_pr. It runs nightly, just as the PPA. So instead of making a branch, it would be better to run the autopkgtests on the PPA every night.
[18:07] <mup> PR snapcraft#1716 opened: tests: split the integration autopkgtests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1716>
[18:35]  * Chipaca EODs
[18:57] <cachio> zyga-ubuntu, do you see he network-status interface when you list the interfaces?
[18:58] <jdstrand> cachio: I don't have context, but note that network-status is not an implicit slot. you need a slot implementation
[18:59] <cachio> jdstrand, ah, ok
[19:00] <cachio> jdstrand, tx, thats make sense now
[19:00] <jdstrand> cool
[19:01] <cachio> jdstrand, any idea why is it implemented in that way?
[19:02] <jdstrand> cachio: because the core snap and the classic system doesn't ship connectivity-api by default
[19:02] <jdstrand> implicit slots are for things that are expeccted to always be provided by the host OS
[19:04] <cachio> jdstrand, but the network-control is pretty similar and it is implicit
[19:05] <jdstrand> cachio: network-control allows using various tools that are avaialble inn the core snap or the classic distro
[19:05] <jdstrand> cachio: network-status allows using a dbus api provided by the connectivity-api deb from Touch
[19:05] <cachio> jdstrand, ah, ok
[19:06] <cachio> jdstrand, thanks for the explanation
[19:06] <jdstrand> cachio: ie, the core snap provides the things that are made avaialble via the interface. that is what makes it implicit. if it does not, then a slot implementation must provide it
[19:06] <zyga-ubuntu> cachio: looking
[19:06] <jdstrand> zyga-ubuntu: you don't have to
[19:07] <zyga-ubuntu> cachio: ah, I see jdstrand already answered
[19:07] <jdstrand> zyga-ubuntu: I answered the question
[19:07] <zyga-ubuntu> thank you :)
[19:07] <jdstrand> np
[19:07] <cachio> thanks guys
[19:07] <zyga-ubuntu> thank you for working on tests :)
[19:07] <zyga-ubuntu> jdstrand: FYI, tmpfs is in final stages of polish, expect a swarm of small PRs that make everything work nicely, spread and unit tests
[19:08] <jdstrand> ok
[19:08] <zyga-ubuntu> jdstrand: I'm adding support for files and symlinks which will also be handy for layouts (implementing this gives us all the designed building block of layouts now)
[19:08] <jdstrand> zyga-ubuntu: note I'm still in the throes of investigating various issues
[19:08] <zyga-ubuntu> throes?
[19:08] <jdstrand> sorry
[19:09] <jdstrand> I'm very busy lately investigatin the fallout of the udev tagging PR
[19:09] <zyga-ubuntu> ah, I see
[19:09] <zyga-ubuntu> thank you for doing that
[19:09] <zyga-ubuntu> let me know if I can help
[19:09] <jdstrand> getting through things, but still getting different reports
[19:09] <zyga-ubuntu> I pushed a PR related to udev tagging of hooks
[19:10] <jdstrand> I also have some spread tests I'm working on to fill some testing gaps I noticed
[19:10] <zyga-ubuntu> anything worrying from the reports you are getting?
[19:10] <jdstrand> nothing that seems terribly widespread
[19:11] <jdstrand> but things that are affecting people
[19:11] <jdstrand> (corner rcase type things I think is what's left)
[19:12]  * zyga-ubuntu nods
[19:13] <kyrofa> elopio, whatever happened to re-using the cache in integration tests?
[19:17] <elopio> kyrofa: we didn't notice any improvements on travis. I started measuring the tests, and decided first to remove the duplicates which reduced 10 minutes.
[19:17] <elopio> after 2.35 we can reopen it and measure again
[19:17] <kyrofa> elopio, ah yes, okay. I'm adding another ROS test, FYI
[19:20] <elopio> kyrofa: ok. And any reason for putting it in the integration suite instead of the snapcraft-de-noche like we did with the lunar one?
[19:21] <kyrofa> elopio, those run too late, man. And they're so easy to forget about
[19:22] <kyrofa> All these ROS tests pull the same thing.  Lets try sharing the cache again :)
[19:24] <kyrofa> Lunar is a little different. That test ensures support, but that's all it needs to do. We have various other kinetic tests that all do the same, but slightly different things
[19:24] <kyrofa> Caching would make one test take a while, and all others take two minutes
[19:25] <kyrofa> Although if we're _already_ running into disk space issues that may be a problem
[19:25] <elopio> maybe we can remove the slow tag. But while we have that, remember that the ros tests will run once a day, just as late as snapcraft-de-noche.
[19:25] <kyrofa> elopio, not all of them are marked slow, just the snapd ones
[19:26] <kyrofa> elopio, also, triggering autopkgtest runs is easy, triggering de-noche tests... ?
[19:26] <kyrofa> (note that I'm not adding another snapd test, just a good old integration test)
[19:26] <elopio> we will have to see if it's because of tmpfs. But if it's not, we need a solution, so ask for more space on the runnners.
[19:26] <kyrofa> Indeed
[19:28] <elopio> kyrofa: a good old *slow* integration test :) I have no problem with this, if the test is needed, and we need to run it on each PR, we have to deal with the delay. I'm just making the questions, because the past two weeks have been sad because of slow tests.
[19:29] <kyrofa> elopio, hahaha
[19:29] <kyrofa> elopio, of course, you're doing your job ;)
[19:29] <kyrofa> elopio, but yeah, I need to make sure this behavior doesn't regress
[19:31] <elopio> it seems that our plugins will always be slow, so our suite will always be slow. Lets parallelize through splits and explore other options like the cache.
[19:31] <kyrofa> elopio, how is Travis looking today? Think it could handle a little experimentation?
[19:32] <kyrofa> I want to propose my ROS PR, and also propose that same PR with your caching rebased on top, and compare the two
[19:33] <elopio> kyrofa: the integration_tests/plugins suite is already big, so we might be forced to do it, not just for fun.
[19:33] <kyrofa> elopio, yeah that probably needs to be done
[19:35] <kyrofa> elopio, though note that this test is actually going into integration_tests/ itself. Are you trying to migrate those elsewhere?
[19:35] <elopio> kyrofa: why on integration_tests if it's for a plugin? souldn't it go in itnegration_tests/plugins?
[19:35] <kyrofa> elopio, also, you're trying to toast the snaps_tests, right?
[19:35] <kyrofa> elopio, because it was already there, I was just adding to it
[19:36] <elopio> kyrofa: yeah, no more snaps_tests please.
[19:36] <kyrofa> elopio, this PR will actually _remove_ one then, ;)
[19:37] <elopio> kyrofa: that sounds wrong, but lucky wrong because the integration_tests suite has a little more room than the plugins one.
[19:37] <elopio> kyrofa: you can experiment locally with the shared cache, just adding a timer like https://stackoverflow.com/a/9502897/2665322
[19:37] <kyrofa> elopio, oh yes of course, good call
[19:38] <kyrofa> elopio, well, if I move these both into plugins I guarantee it'll run over. Shall we split first
[19:38] <kyrofa> ?
[19:39] <elopio> kyrofa: yes, I think we first refactor to have everything in snapcraft/tests/integration
[19:39] <kyrofa> elopio, agreed
[19:39] <elopio> then we can split snapcraft/test/integration/plugins/ros and snapcraft/tests/integration/plugins/others
[19:39] <kyrofa> elopio, I'll rebase to build on that branch
[19:39] <kyrofa> elopio, haha, great idea
[19:40] <kyrofa> Okay, got it
[19:40] <kyrofa> I'll do that, then experiment with caching with that single suite
[19:41] <elopio> not great, but well, we don't have many options. My experiment running cleanbuilds in parallels was a lot slower than one thread of normal builds :(
[19:42] <kyrofa> Yeah, not surprising :(
[19:51] <kyrofa> Oh wait, I can't build on that test refactor, this needs to land for this release
[19:51] <kyrofa> I'll just propose in the integration_tests suite for now
[19:53] <zyga-ubuntu> pedronis: around?
[19:53] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/4141 what happened here?
[19:53] <mup> PR #4141: snap-update-ns: add missing unit test for desired/current profile handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/4141>
[19:58] <pedronis> zyga-ubuntu: no, clue  I didn't push to that branch, I don't even have it around
[19:59] <pedronis> also the commit are marked as mvo too
[19:59] <zyga-ubuntu> pedronis: ah, mvo must have rebased something oddly
[19:59] <zyga-ubuntu> no worries, I'll check it out tomorrow
[20:00]  * zyga-ubuntu -> EOD
[20:25] <mup> PR snapcraft#1717 opened: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717>
[21:02] <sergiusens> pedronis cachio I've been looking at your PRs that have been merged and noticed that almost none waited for adt to finish running; given the queue for adt is being starving due to so many snapd requests on the upstream queue, mind disabling the adt hooks you guys have (temporarily at least).
[21:03] <sergiusens> I did tell mvo earlier today about our process and mentioned elopio mind be able to help cachio
[21:05] <kyrofa> snappy-m-o, autopkgtest 1717 zesty:amd64
[21:05] <snappy-m-o> kyrofa: I've just triggered your test.
[21:07] <kyrofa> sergiusens, the shebang fix in post-build won't work. Not even post-pull will work, as we need to make sure shebangs are fixed for stage-packages that are used as part of pulling
[21:07] <mup> PR snapcraft#1653 closed: internal: don't reuse variable in OsRelease <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1653>
[21:08] <sergiusens> kyrofa oh right; pre-build then?
[21:08] <kyrofa> sergiusens, it needs to happen in the repo
[21:09] <sergiusens> kyrofa as part of unpacking? Like all other things?
[21:09] <kyrofa> sergiusens, yeah, which is where it is right now
[21:09] <kyrofa> sergiusens, but then we also need it post-build
[21:09] <kyrofa> And pre-build
[21:09] <kyrofa> Heh
[21:09] <sergiusens> kyrofa I still think that `unpack` should eventually be something triggered by pre-pull and pre-build
[21:10] <sergiusens> kyrofa as in the directive to do something should be something a user could override
[21:10] <sergiusens> that is the gist of it
[21:10] <kyrofa> So: repo for stage-packages that might be used for pulling. pre-build for source that needs to be fixed before building, and pre-stage for fixups in order to be useful in staging (and the snap in general)
[21:10] <kyrofa> Yeah you're probably right there
[21:11] <sergiusens> kyrofa doing it in unpack right now is fine as we do a bunch of other things that should be overrideable there
[21:11] <kyrofa> sergiusens, it really comes down to this: we currently don't have pre/post. But we currently are doing the shebang fix in unpack as well as pip, python plugin, and catkin plugin
[21:12] <kyrofa> sergiusens, in the interest of not needing to play whackamole with this shebang bug, I'd like to make those all go through the same codepath
[21:12] <kyrofa> Where should that be with the view of having pre/post?
[21:13] <mup> PR snapd#4157 opened: add spread test for connecting all interfaces (excepting gadget slots) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4157>
[21:17] <kyrofa> I can just throw in in internal/common for now, then we can refactor it when we use pre/post
[21:17] <kyrofa> That's better than file_utils because that's public
[21:18] <sergiusens> kyrofa internal.mangling ?
[21:18] <kyrofa> Hey, not bad
[21:18] <sergiusens> it is settled then
[21:19] <kyrofa> Done
[21:25] <mwhudson> heh i now have the 4th oldest snapcraft and the oldest snapd pr
[21:25] <mwhudson> the snapd one still being open is definitely my fault though
[21:25] <mup> PR snapcraft#1718 opened: lxd: let lxd choose the architecture <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1718>
[21:28] <sergiusens> mwhudson it is marked 2.36, as soon as adt is freed up and we can release 2.35 we will focus on those
[21:28] <mwhudson> sergiusens: it also has conflicts i haven't resolved so i'm not too bitter :)
[21:28] <mwhudson> sergiusens: and it would make sense to do #1718 first in any case
[21:28] <mup> PR #1718: daemon,overlord: add subcommand handling to snapctl <Reviewed> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1718>
[21:29] <mwhudson> mup: bad bot
[21:29] <mup> mwhudson: Roses are red, violets are blue, and I don't understand what you just said.
[21:29] <kyrofa> mwhudson, looks like that PR _definitely_ happened first
[21:29] <mwhudson> snapcraft#1718
[21:29] <mup> PR snapcraft#1718: lxd: let lxd choose the architecture <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1718>
[21:29] <mwhudson> eh
[21:29] <mwhudson> *heh
[21:29] <mwhudson> (can't type today)
[21:34] <sergiusens> ah, kalikiana or kyrofa mind looking at that ^? I am going to be signing off soonish, it has been a very long Monday in front of my computer.
[21:34] <kyrofa> Sweet, I'll check it out
[21:35] <mwhudson> i haven't managed to run the tests yet so we should let travis do it's thing i guess...
[21:35] <kyrofa> Alright, I'll take a look in a few then
[22:45] <elopio> Alright, trying something  new here. Weechat relay+SSL to sync with the android app
[22:46] <elopio> IRC fun never ends.
[23:04] <kyrofa> elopio, haha, welcome back!
[23:14] <cachio> cwayne, hey, can't access to the bug that is in the email
[23:14] <cachio> https://bugs.launchpad.net/plano/+bug/1727783
[23:28] <sergiusens> elopio, snap install thelounge
[23:29] <elopio> sergiusens: I tried that, hated it.
[23:31] <elopio> And anyway, it's almost as complicated as this one. I would also need letsencrypt for the lounge.
[23:32] <sergiusens> Yup
[23:34]  * elopio goes to exercise. I'll be back in 1 hour.
[23:38]  * sergiusens goes into airplane mode
[23:39]  * mwhudson finds FakeLxd
[23:41] <mup> PR snapcraft#1719 opened: many: account for python shebang ars in rewrite <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1719>


[10:56] <lcapriotti> hi, I'm trying to exec a text-based installer when system has completed booting: http://www.friendpaste.com/1DWFdkL9xtCR9mBXF5XQZL
[10:56] <lcapriotti> but the text installer cannot accept inputs
[10:57] <lcapriotti> the login prompt is shown instead, superimposed with installer text output
[10:57] <mgoetze> well, you should tell your login job not to start until the installer is done, of course
[10:58] <mgoetze> and then you'll want something like "exec < /dev/console" in your script
[10:59] <lcapriotti> what is I don't want/can't modify the tty1 upstart job?
[10:59] <lcapriotti> would something like exec su -c "myInstaller" -l work?
[11:03] <ion> exec openvt command
[11:04] <lcapriotti> pls speculate
[11:19] <lcapriotti> ion: exec openvt -s command worked, tks a lot!
[15:39] <kindjal> Is there a target date for upstart 0.10 (even roughly)?  I'm interested in the "automatic" and "manual" feature being discussed for the 0.10 release.
[15:41] <sadmac2> kindjal: its kind of in "when its done" mode, but I think we'd like to have it in the next 6 months
[15:41] <sadmac2> well, we'd like to have it today, and release dates are meant to be broken, but...
[15:42] <kindjal> Understood.  "it's done when it's done" is very understandable... I was just curious as to where it stood.  Thanks.
[15:43] <kindjal> If I require a "chkconfig" like functionality for upstart, am I thus sort of stuck with a "link job files into /etc/init" until then?
[15:47] <kindjal> By "chkconfig" I guess I really mean just "enable/disable" a job
[15:52] <sadmac2> kindjal: yes. though that's what chkconfig is anyway :)
[15:52] <kindjal> Yes... but upstart could eliminate the concept of "runlevel" which is sort of chkconfig's focus.


[03:53] !dmwaters:*! Good day all, it appears that rather large netsplit was caused by the disappearence of  our european hub. I'm looking into the situation now. Thank you for your patience, and thank you for using freenode!