=== kickinz1 is now known as kickinz1|afk
=== kickinz1|afk is now known as kickinz1
=== kickinz1 is now known as kickinz1|afk
[00:54] <darkxst> aeoril, libvte has a soname bump each release
[00:55] <darkxst> that would make it tricky to bisect or swap versions etc!
[00:58] <darkxst> aeoril, maybe https://bugzilla.gnome.org/show_bug.cgi?id=708213
[00:58] <ubottu> Gnome bug 708213 in VteTerminal "zsh - lots of blank space upon resizing VTE based terminals" [Normal,Resolved: fixed]
=== salem_ is now known as _salem
=== Bluefoxicy_ is now known as Bluefoxicy
[03:52] <aeoril> darkxst thanks!  Looked over that bug - seems like the timing is approximately correct - 9/2013 for the bug work, 11/2013 for the release in trusty, as far as I can tell
[03:53] <aeoril> darkxst wait, I take that back - would the bug fix have made it into trusty within that small of a window?
[03:53] <aeoril> (not really sure about the trusty release date)
[03:55] <infinity> hallyn: LP: #1419855
[03:55] <ubottu> Launchpad bug 1419855 in qemu (Ubuntu) "must manually load kvm_hv or kvm_pr before using kvm on ppc64" [Undecided,New] https://launchpad.net/bugs/1419855
[03:55] <infinity> hallyn: Due to a typo in debian/rules, the qemu-kvm init job is never actually installed on ppc64el.
[03:56] <infinity> hallyn: I suspect we might also want to loosen it to install on powerpc and ppc64 as well (ie: anywhere where qemu-system-ppc is native)
[03:56] <aeoril> I am looking for the patched code in launchpad for trusty release - but not really sure exactly if I am looking at the correct libvte for trusty darkxst
[04:09] <hallyn> infinity: ok.  cgmanager needs my attention tonight, but wrote it down for tomorrow
[04:10] <hallyn> man, on v0.36 already
[04:10] <hallyn> was hoping it would be dead by now
[04:17] <infinity> hallyn: We still need to SRU back the qemu-kvm bits at some point too, and whatever else we slacked on.
[04:18] <infinity> hallyn: Perhaps a discussion better had when we're in the same timezone.
[04:18] <hallyn> what tz are you in?
[04:21] <hallyn> the sru of othe rqemu-kvm bits is on my list.
[04:27] <infinity> hallyn: I'm in Hong Kong right now.
[04:28] <infinity> hallyn: FWIW, qemu-slof is now in main on trusty too, though I'm not sure how much difference that makes until we either decide to backport utopic's qemu wholesale (ick) or get IBM to identify and backport all the necessary patches for LE host support.
[04:45] <darkxst> aeoril, I didn't think that fix would have been in trusty, but maybe it was
[04:46] <aeoril> darkxst I have been looking - it seems the version for the fix was 34.8, while the version in trusty is 34.9 ...
[04:47] <aeoril> darkxst I cannot use pull-lp-source to get the library source code though - is there another way?
[04:47] <hallyn> hong kong.  it's a globe-trotting month for you
[04:48] <darkxst> aeoril, pull-lp-source needs the source package name
[04:48] <darkxst> there is also apt-get source
[04:48] <darkxst> that works with binary names
[04:48] <aeoril> darkxst ok, I'll try that
[04:49] <darkxst> aeoril, vte3 is the source package name from memory
[04:50] <aeoril> darkxst I just did "sudo apt-get source libvte-2.90-9" and it seemed to work ...
[04:50] <aeoril> but yah, vte3 is what I have been seeing ...
[04:55] <aeoril> darkxst this worked, I will use it:  sudo pull-lp-source vte3 trusty
[05:17] <infinity> aeoril: Err, there's no reason to run that as root (ie: don't use sudo).
[05:18] <aeoril> infinity ok, thanks
=== work_alkisg is now known as alkisg
[06:20] <darkxst> pitti, indeed disabling cgmanager and lxcfs stops by drives getting unmounted
[06:21] <aeoril> darkxst what do you think of this? https://bugzilla.gnome.org/show_bug.cgi?id=543919
[06:21] <ubottu> Gnome bug 543919 in VteTerminal "window size changes don't always propagate" [Normal,Resolved: invalid]
[06:22] <darkxst> aeoril, it looks like it predates gtk3?
[06:23] <aeoril> darkxst yes, but they never fixed it and it was just marked as invalid for gtk3 with a mention that if it was seen in gtk3 to reopen
[06:23] <aeoril> I am assuming just because they never saw it - that does not mean it still wasn't lurking around maybe ...
[06:25] <darkxst> aeoril, your out by 1-2 lines? that doesnt seem even remotely similar
[06:25] <aeoril> darkxst I must have misread it
[06:27] <darkxst> aeoril, I'd probably be digging into the code and use git to find all commits that affect size/resizing
[06:28] <darkxst> aeoril, maybe check that a resize event occurs when launch with --geometry
[06:28] <aeoril> darkxst ok
[06:29] <darkxst> aeoril, and maybe talk to Cpe if he knows what fixed it?
[06:29] <aeoril> darkxst is git diff?
[06:29] <aeoril> use git diff?
[06:30] <darkxst> git log -p <file>
[06:30] <darkxst> or git log -G/S <var/func name>
[06:30] <darkxst> are handy
[06:31] <darkxst> aeoril, that should have been chpe, youll have to head to the gnome channels on GIMPnet to find him though
[06:32] <aeoril> darkxst so git log -p vte.c?
[06:32] <aeoril> darkxst yes, his name is all over vte
[06:32] <darkxst> aeoril, that will show you a log of all commits affecting vte.c (probably way to much to process
[06:33] <aeoril> I'll grep around for --geometry and other stuff
[06:34] <darkxst> thats just a command line switch
[06:34] <darkxst> find the functions that actually handle geometry
[06:34] <darkxst> and then look for changes in those functions
[06:37] <darkxst> aeoril, you picked a pretty hard bug, and I certainly don't have time to investigate properly
[06:38] <aeoril> darkxst it picked me - I would need your help to fix it.  If you need to bow out, I probably should too.
[06:39] <darkxst> aeoril, I can keep sending you random guesses, thats all I've been doing anyway
[06:39] <aeoril> darkxst no, you have been much more valuable than that for me, actually
[06:40] <aeoril> darkxst given your last suggestions, I have a lot to go on for now actually if I were to stick with it
[06:40] <darkxst> but perhaps a simple packaging bug, something like bug 1406200 could break up things a little! you have spent like all week on this bug
[06:40] <ubottu> bug 1406200 in syncevolution (Ubuntu) "Add support for GOA in Syncevolution to make it work with Ubuntu-Gnome (Vivid)" [Undecided,New] https://launchpad.net/bugs/1406200
[06:41] <aeoril> darkxst I have not devoted much time to this bug until today.  I have also learned a heck of a lot, which is invaluable.  But, i have taken up a lot of IRC time for you guys as well
[06:42] <aeoril> darkxst really, I started from scratch this morning and did it right.  Basically, other than the initial learning stuff I did I have spent 1 day on this bug properly
[06:43]  * darkxst never spends more than a couple of hours on a bug unless it involves writing lots of code
[06:44] <aeoril> darkxst also, it is much more fun looking at code and seeing what it does, which is where I am at now
[06:44] <aeoril> darkxst are you that fast?  Or you just lose interest and go onto another one?
[06:45] <pitti> Good morning
[06:45] <darkxst> aeoril, If i can't find the problem in that time, I'll just forward upstream
[06:45] <pitti> darkxst: thanks for confirming
[06:45] <aeoril> darkxst ok, I see
[06:46] <aeoril> darkxst I tend to bite into things and stick with them beyond normal death
[06:46] <aeoril> (as you can probably already tell)
[06:47] <darkxst> pitti, morning an np, getting sick of rebooting but still haven't fixed gdm/gtk bug either ;(
[06:47] <darkxst> aeoril, seems a little unproductive, always utilize upstream
[06:48] <aeoril> darkxst so, at this point, you would go ahead and file a but on vte on gnome bugzilla and have done with it?
[06:48] <aeoril> s/but/bug/
[06:50] <aeoril> darkxst the problem is fixed in vivid though - I thought the whole point of this exercise was finding where the fix was to hopefully backport into trusty and utopic?  Upstream wouldn't be appropriate for that, would it?
[06:51] <aeoril> darkxst talking to chpe would seem like the sanest thing to do at this point ...
[06:52] <aeoril> (if possible)
=== alkisg is now known as work_alkisg
[06:54] <darkxst> aeoril, if you file a bug they will just probably close
[06:54] <darkxst> it
[06:54] <darkxst> but sure you can ask if they know about what fixed it
[06:56] <aeoril> darkxst Unfortunately, I don't see a forum other than bugzilla on wiki.gnome.org ...
[06:58] <darkxst> aeoril, #gnome-hackers on GIMPnet is probably your best bet
[06:59] <aeoril> darkxst ok.  I'll go on there tomorrow and see if I get any help.  Otherwise, I'll think about looking around at geometry code and using git
[07:01] <aeoril> darkxst to get the vte git repo, I would do "git clone git://git.gnome.org/vte" ???
[07:02] <darkxst> aeoril, pretty sure you can answer that question yourself!
[07:02] <aeoril> darkxst yes, you are right.  I am tired.
[07:02] <darkxst> aeoril, message me again when you are stuck!
[07:02] <aeoril> afk.  Good night.
=== kickinz1|afk is now known as kickinz1
=== zyga_ is now known as zygag
=== zygag is now known as zyga
[07:56] <geser> Are there any known issues with permanently switching to systemd? My 15.04 VM won't start (kernel panic) unless I specify init=/lib/systemd/systemd
[07:58] <darkxst> geser, maybe, pitti has been doing a good job of fixing them as I find them though
[08:01] <darkxst> geser, but that said I'm now reconsidering swithing ubuntu-gnome to systemd (assuming ubuntu don't switch), it mostly works great,
[08:14] <pitti> darkxst: argh WTH <censored> <censored>, I got it!
[08:15] <pitti> darkxst: i. e. I finally understand what's going on with the mounts
[08:15] <pitti> geser: you mean it panics with upstart and works with systemd? that's certainly not expected -- do you have some output/a bug?
[08:16] <seb128> pitti, what's going on then?
[08:16] <pitti> /etc/mtab, the nail in my coffin
[08:16] <pitti> so systemd boots, parses /etc/mtab (which it expects to be a link to /proc/mounts)
[08:16] <pitti> sees all the gazillion mounts from the previous boots and creates .mount units for them
[08:17] <pitti> then unmounts the fstab ones as their devices aren't even there yet (that's the "cleanup mounts after yanking out a device")
[08:18] <pitti> and then it turns /etc/mtab into a /proc/mounts symlink as intended, which suddenly makes all the mounts disappear
[08:18] <pitti> so, it should parse /proc/mounts instead of /etc/mtab
[08:19] <pitti> and for  cleanup we should also turn /etc/mtab into a symlink on upgrades; it's been many many years since it needed to be a file, and it keeps causing confusing
[08:19] <pitti> confusion
[08:22] <seb128> pitti, good work figuring it out!
[08:25] <pitti> so, we do turn /etc/mtab into a /proc/mounts symlink, but something during shutdown or initramfs turns it back to a file
[08:25] <darkxst> pitti, that sounds well convoluted
[08:25] <darkxst> (the problem, not the fix)
[08:26] <pitti> darkxst: yeah, perfect example of an emergent bug which you don't really see at each individual step..
[08:26] <pitti> so, what is so insistant on making /etc/mtab a file..
[08:27] <pitti> /etc/init/lxcfs.conf!
[08:27] <pitti> and /lib/systemd/system/lxcfs.service
[08:27] <pitti> ExecStopPost=/bin/sed -i "/^lxcfs \/var\/lib\/lxcfs fuse.lxcfs/d" /etc/mtab
[08:27] <pitti> nonono!
[08:28] <pitti> that also explains why these problems started about two weeks ago when we got lxcfs
[08:28] <pitti> so it all fits together now
[08:28] <geser> pitti: no, I switched that it starts with systemd by default (apt install systemd-sysv --purge (to purge the conflicting upstart package)) but it does so only when I specify init= in grub
[08:29] <darkxst> pitti, pretty sure it was in some way linked to glib/gtk on ubuntu-desktop ppa though
[08:29] <pitti> darkxst: I don't have that PPA
[08:29] <darkxst> I first hit it when I installed that,
[08:29] <pitti> darkxst: but, it's a race condition; anything which changes the timing during boot could trigger it
[08:29] <darkxst> it went away when I purged it
[08:30] <darkxst> pitti, fun old races
[08:30] <pitti> that's why disabling lxcfs helped
[08:33] <darkxst> pitti, makes sense
[08:41] <pitti> geser: sorry, I thought I replied already
[08:42] <pitti> geser: do you have some logs/a screenshot of the panic? can you please file a bug, that sounds quite serious
=== spineau is now known as spineau_afk
[08:48] <geser> pitti: I can try to take a screenshot from within VMware. The kernel panics with "Attempted to kill init" about 2 sec after booting.
[08:48] <pitti> geser: ah, can you please boot with "debug" on the command line, too?
[08:50] <infinity> pitti: Can you verify LP: #1404509 for trusty when you have a chance?
[08:51] <ubottu> Launchpad bug 1404509 in systemd (Ubuntu Trusty) "[precise, trusty] udev does not automatically load modules with kernel >= 3.11" [Undecided,Fix committed] https://launchpad.net/bugs/1404509
[08:51] <pitti> infinity: hm, HWE promised to verify that; I don't have an affected machine
[08:51] <pitti> infinity: I'll reply to them again with a prodding
[08:52] <infinity> pitti: Ta.
[08:52] <aeoril> darkxst I actually never did stop - I have been familiarizing myself with the vte code all night - pretty cool stuff
[08:53] <infinity> pitti: I didn't find a test case (nor divine one from the comments) for trusty, since you said trusty already worked for the 'cpu' subsystem, but 'might fail' for 'others'.  Makes it all a bit nonspecific to test. :P
[08:54] <darkxst> aeoril, ok, like I said message me again when you are stuck!
[08:55] <aeoril> darkxst ok, sorry - won't keep bothering you
[08:56] <pitti> infinity: yeah, that was a request from Dell for ipmi systems; I asked them again to test (our HWE engineers also have that hw)
[08:56] <infinity> pitti: Spiffy.
[08:56] <pitti> infinity: i. e. the real test case that we're interested in is "does that laptop work now"
[08:57] <infinity> pitti: "No, the battery went flat, sorry."
=== spineau_afk is now known as spineau
[09:07] <geser> pitti: filed as bug #1421117 with the debug output from the serial console
[09:07] <ubottu> bug 1421117 in systemd (Ubuntu) "Ubuntu 15.04 VM doesn't boot after switching permanently to systemd" [Undecided,New] https://launchpad.net/bugs/1421117
=== work_alkisg is now known as alkisg
[09:18] <alkisg> mvo: good morning, the SRU was approved and it's now in precise-proposed, we did verification-done for one of the bugs, do you need help for the other 3 ones?
[09:56] <mlankhorst> pitti: gmsh 'regression' with mesa upload again :/
[09:57] <pitti> mlankhorst: argh; nudged
[10:00] <mlankhorst> ty
[10:00] <pitti> geser: replied to the bug
[10:17] <mvo> alkisg: I would certainly not mind help ! can also give it a go later today
=== spineau is now known as spineau_afk
[10:19] <geser> pitti: added the info you requested to the bug. It looks like /sbin/init being an absolute symlink is the issue.
[10:28] <pitti> /sbin/init -> /lib/systemd/systemd
[10:28] <pitti> geser: that's what it is here
[10:31] <geser> here too (booted system), in the initramfs it's /root/sbin/init -> /lib/systemd/systemd but there is no /lib/systemd/systemd there, only /root/lib/systemd/systemd
[10:31] <flexiondotorg_> Will the HWE stuff be installed/shipped by default in 14.04.2 or will it still be a post-install apt-get for users?
=== vrruiz_ is now known as rvr
[10:42] <dholbach> didrocks, wow, looks like there's a lot going on in the ubuntu-make project :)
[10:45] <didrocks> dholbach: heh, yeah, and nice community contributions! :)
[10:45] <dholbach> :)
[10:46] <didrocks> dholbach: the next update would have 5-6 new supports, coming from the community :)
[10:46] <didrocks> (a new contributor)
[10:46] <didrocks> it's awesome!
[10:46] <dholbach> wow, that's amazing
[10:46] <didrocks> those people rocks! :)
[10:51] <pitti> geser: hm, that all looks fine and expected; so I'm a bit stumped what to ask next..
[10:57] <geser> pitti: so what's the difference to boot with "init=/lib/systemd/systemd" which works?
[10:59] <pitti> geser: that's the thing, I don't have the slightest idea :/
[10:59] <pitti> geser: the default is /sbin/init, but if that points to /lib/systemd/systemd it should be the same
[11:03] <pitti> geser: I guess init=/bin/systemd doesn't work either?
[11:03] <pitti> geser: if it does, that would be a major surprise
=== alkisg is now known as work_alkisg
[11:18] <geser> pitti: correct, init=/bin/systemd doesn't work either (with a different error: target filesystem doesn't have requested /bin/systemd)
[11:18] <pitti> interesting (and a lie, too)
=== spineau_afk is now known as spineau
[11:24] <geser> pitti: but with /sbin/systemd -> ../lib/systemd/systemd (created for testing) and init=/sbin/systemd it works again
[11:25] <pitti> geser: fun; that sounds like an initramfs-tools bug then
[11:37] <ricotz> pitti, hi, is "/sbin/init -> /lib/systemd/systemd" already default? since here is points to upstart
[11:38] <geser> ricotz: it's only default when you install systemd-sysv
[11:40] <ricotz> geser, ok, i guess i hold off that to keep ubuntu-minimal, ureadahead
=== _salem is now known as salem_
=== MacSlow is now known as MacSlow|lunch
[13:28] <rbasak> Is it sufficient to supply jquery in debian/missing-sources/, when minified JS is being shipped upstream?
[13:29] <rbasak> Or is it necessary to provide the mechanism to derive the minified JS also?
[13:29] <rbasak> (the minified JS isn't actually used; the packaging uses libjs-jquery instead)
[14:10] <pitti> rbasak: there's the option to repack the upstream source without the code copy; but if you want to use the original tarball, debian/missing-sources/ sounds ok to me
[14:16] <rbasak> pitti: OK - thanks
[14:28] <hallyn> pitti: hey - sorry to bother you, but would you mind taking a look at http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.36-1.dsc an dperhaps sponsorin ginto sid?
[14:35] <flexiondotorg_> Will the HWE stuff be installed/shipped by default in 14.04.2 or will it still be a post-install apt-get for users?
=== josepht_ is now known as josepht
[14:39] <smoser> hey.
[14:40] <smoser> do i need an MIR to move python3-serial to main ?
[14:40] <smoser> https://launchpad.net/ubuntu/+source/cloud-init/0.7.7~bzr1055-0ubuntu1/+build/6969483
[14:40] <smoser> it blocks cloud-init, but is from same source package as python-serial which is in main.
=== pgraner-afk is now known as pgraner
[15:00] <pitti> hallyn: re (sorry, meeting); can do
[15:01] <pitti> hallyn: wrt your recent comment on bug 1419623, that's what I did
[15:01] <ubottu> bug 1419623 in systemd (Ubuntu) "systemd unmounts mounted filesystems when lxcfs is installed" [High,In progress] https://launchpad.net/bugs/1419623
[15:01] <hallyn> pitti: thanks.  If you feel up to actual checking of the upstream patches too that'd be great :)  I'm feeling squeamish, but at the same time these fixes need to ge tout
[15:02] <hallyn> pitti: oh!  i thought you said you'd sent a patch to systemd
[15:02] <pitti> hallyn: well, both
[15:02] <pitti> hallyn: systemd should be more robust in that situation, but we still don't want to turn a symlink into a file
[15:02] <hallyn> cool, thanks
[15:02] <hallyn> yeah
[15:02] <mbruzek> Good morning #ubuntu-devel
=== MacSlow|lunch is now known as MacSlow
[15:02] <pitti> hallyn: we discussed the systemd patch on teh upstream ML this morning; it's unfortuantely a bit tricky as util-linux 2.25's libmount has a bug
[15:03] <pitti> hallyn: but I'll keep a slightly hackish patch in our tree for now
[15:03] <mbruzek> Someone from Nagios contacted me and he wants to update the packages for Ubuntu.  He does not know how to do that so was asking me for information on how to get started.
[15:03] <pitti> hallyn: checking of the upstream patches> for what?
[15:03] <hallyn> pitti: sanity?
[15:04] <hallyn> it switches cgmanager so it now pivots into an empty root
[15:04] <hallyn> it *should* be safe, but i'm not sure whether my imagination is just failing me as to ways in which it culd fail
[15:04] <jpds> mbruzek: In which release? 14.04 LTS?
[15:05] <mbruzek> jpds He did not specify release, but I would guess yes the LTS release
[15:05] <jpds> mbruzek: That's not really possible.
[15:06] <jpds> !sru | mbruzek
[15:06] <ubottu> mbruzek: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[15:06] <pitti> hallyn: ah, so mostly https://github.com/lxc/cgmanager/commit/a08d1c038c84 ?
[15:06] <mbruzek> I will give him this information and see what I can do, I believe the reason he wants to update is because nagios core is verison 4.x now and we still have 3.x in the packages
[15:07] <pitti> hallyn: do you have that packaging in git, or can I clean up the changelog? (Closes: #760281) (Closes: #767468) → (Closes: #760281, #767468)
[15:07] <jpds> mbruzek: that's updatable in the development release.
[15:07] <mbruzek> jpds: if that is not possible, perhaps he can start the process for the next LTS
[15:07] <jpds> mbruzek: Exactly.
[15:07] <mbruzek> I just want to point him to the right resources so he can get moving
[15:08] <hallyn> pitti: not in git, cleanup apprecaited
[15:09] <hallyn> uh, i think not in git.  what does the pkging say? :)  /me chekcs
[15:10] <hallyn> pitti: so yeah, basically that commit and the one before and the one after it.  (the rest should be no big deal)
[15:10] <cjwatson> smoser: no, that doesn't need an MIR.  moved
[15:14] <pitti> hallyn: ah, so umounts etc. from the real systems were busted because cgmanager only made them slave in its NS, not private?
[15:15] <hallyn> no,
[15:15] <smoser> cjwatson, thanks.
[15:16] <hallyn> pitti: it was bc it cgmanager only made them slave in its NS, not in the host ns
[15:16] <hallyn> so it owrked fine under systemd, bc there the host is MS_SHARED
[15:16] <hallyn> but in sysvinit/upstart it's private on the host so mounts don't get fwded in the first place.
[15:16] <hallyn> it's not cgmanager's place to change that on the host
[15:17] <hallyn> really it points to a problem with mounts propagation, but i didn't want to fight that fight for this bug
[15:17] <pitti> hallyn: so, the patch looks sensible enough to me, and it seems some people tested it in the debian bugs too
[15:18] <pitti> hallyn: note that as far as the unblock request goes, testing has 0.33 only; I figure you want 0.36 in testing as these two bugs are quite important?
[15:19] <hallyn> pitti: yes, please.  I have a separate patch (though i have to rework it) for jessie
[15:19] <hallyn> wait,
[15:20] <pitti> hallyn: do you want to fix that? http://paste.ubuntu.com/10189427/
[15:20] <hallyn> no, i mean i'd *like* 0.36 in testing but figured that wasn't possible, so am working in a debian bug on a debdiff for 0.33-3
[15:20] <pitti> hallyn: (I suggest calling shlibdeps with -c4 to make the build fail on changed symbols)
[15:22] <hallyn> pitti: feh!  those appeared in 0.33
[15:22] <pitti> hallyn: ok, responded to https://mentors.debian.net/package/cgmanager
[15:23]  * hallyn looks for an example of shlibdeps
[15:26] <hallyn> pitti: so I dont' suppose I can use 0.33 in the new symbols file?  Or does it only matter tha tit was available as of 0.33-1 package?
[15:28] <pitti> hallyn: you should use that (i. e. the version where the symbol appeared, not when you added it to the .symbols file)
[15:29] <hallyn> thx
[15:39] <hallyn> pitti: is there a DEB_SHLIBS_ARGS type variable I can set to pass -c4, or do i have to use a override_dh_shlibdeps section?
[15:40] <pitti> hallyn: I think you have to override_dh_makeshlibs, and call dh_makeshlibs -- -c4
[15:40] <pitti> I'm not aware of something easier :/
[15:42] <cjwatson> overrides are more discoverable than variables anyway
[15:42] <hallyn> cjwatson: yeah i'm just afraid i'll drop something in the override
[15:43] <cjwatson> how so?
[15:43] <hallyn> so ican be sure that dh_makeshlibs normally doesn't pass any variables?
[15:43] <hallyn> as in, it would normally pass '-foo' and i dont' pass it in my override
[15:43] <cjwatson> the unoverridden case of override_dh_foo is always simply dh_foo
[15:43] <cjwatson> this is never a thing you need to worry about
[15:43] <hallyn> ok, that's good :)
[15:43] <hallyn> thx
=== kickinz1 is now known as kickinz1|afk
[15:54] <hallyn> hm.  dpkg-shlibdeps: unknown option `-c4'
[15:54] <hallyn> pitti: ^
[15:54] <pitti> hallyn: yeah, dh_makeshlibs :)
[15:54] <cjwatson> makeshlibs not shlibdeps
[15:56] <hallyn> oh, thx.
[16:01] <zul> pitti:  is there a way were you can login to qemu for autopkgtest after a test fails?
[16:02] <pitti> zul: yes; run it with -s (aka --shell-on-fail), it will then give you the ssh command (or minicom, netcat etc. if your machine doesn't have a running ssh server)
[16:03] <zul> pitti:  cool thanks
[16:10] <hallyn> pitti: updated package pushed to mentors
[16:12] <pitti> hallyn: hm, I don't see it yet on https://mentors.debian.net/package/cgmanager
[16:12] <hallyn> pitti: just did it 3 mins ago, sometimes it takes a bit...
[16:17] <hallyn> pitti: it's there now
[16:18]  * hallyn biab
[16:24] <Odd_Bloke> smoser: Where can I get the most recent packaging for cloud-init in precise(-updates)?
[16:24] <Odd_Bloke> smoser: lp:ubuntu/precise-updates/cloud-init looks out-of-date.
[16:27] <rbasak> Odd_Bloke: do you know about pull-lp-source? "pull-lp-source cloud-init precise".
[16:27] <rbasak> What's in the archive is the definitive "most recent", except for maybe work in progress in branch somewhere, but I'm not sure that exists for cloud-init.
[16:29] <Odd_Bloke> rbasak: I did once, and now I do again. :p  Thanks. :)
[16:30] <smoser> Odd_Bloke, looking
[16:30] <smoser> bzr importer and cloud-init do not get along.
[16:30] <smoser> its a regular PITA
[16:32] <rbasak> There seem to be a number of server packages that the bzr importer fails with. For this reason I gave up on UDD a long time ago - I have to use the non-UDD workflow anyway, and UDD never seemed to gain me much.
[16:33] <rbasak> I think it's an issue for new starters actually. More to learn, more edge cases to deal with. We should throw UDD away.
[16:33] <rbasak> (and this includes me when I started)
[16:39] <cjwatson> rbasak: Once we have git support, hopefully we will
[16:39] <pitti> hallyn: in symbols you want s/0.36-1/0.33/, but I'll fix that
[16:40] <cjwatson> (Since dgit is inherently much more reliable and does largely the same thing)
[16:40] <rbasak> cjwatson: UDD with git would work really well IMHO. Though I think the importer should leave quilt patches unapplied. Then the importer can be written to never fail.
[16:41] <rbasak> dgit did look good when I read about it. I didn't actually try to use it though.
[16:41] <cjwatson> Ian was doing something with that in dgit recently, I forget exactly where he ended up
[16:41] <cjwatson> It was certainly never-fail
[16:43] <cjwatson> Er, I think
[16:43] <cjwatson> It may well still need work, but it's much more tractable work in git
[16:44] <smoser> Odd_Bloke,
[16:44] <smoser> precise: lp:ubuntu/precise-proposed/cloud-init
[16:44] <smoser> trusty: lp:ubuntu/trusty/cloud-init
[16:44] <smoser> utopic: lp:ubuntu/utopic/cloud-init
[16:44] <smoser> vivid: lp:ubuntu/vivid/cloud-init
[16:44] <Odd_Bloke> smoser: Aha, -proposed. Thanks!
[16:51] <hallyn> pitti: how did i do that!  i distinctly remember typing in 0.33
[16:54] <pitti> hallyn: uploaded
[16:54] <hallyn> pitti: thx!
=== liam_ is now known as Guest13534
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
[18:08] <tumbleweed> jtaylor: have you seen the pyzmq autopkgtest failure?
[18:19] <grimble_> Hi, my name is Bartek. I submitted my first bug (1410383) and provided patch. Do I have to do something more to receive feedback or just queue is full and need to wait for my turn?
[18:22] <cyphermox> grimble_: for a puppet SRU, correct?
[18:22] <grimble_> yes
[18:23] <cyphermox> grimble_: so looking quickly it seems correct, but I don't usually touch puppet
[18:23] <cyphermox> that said, since it's for a bug fix in a stable release, you might want to follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[18:24] <cyphermox> to update the bug associated with that merge to make it easier to review the bug later and test the fix.
[18:26] <grimble_> ok, thanks for link, I'll look into it and come back if I would have questions :)
[18:27] <cyphermox> don't hesitate :)
=== rickspencer3_ is now known as rickspencer3
[18:47] <jtaylor> tumbleweed: no, whats up with that all logs say tests worked ...
[18:47] <jtaylor> debian works weird
[18:53] <hallyn> infinity: mwhudson: hey, you guys came up with the original kvm.powerpc script (/usr/bin/kvm for powerpc)?
[18:53] <tumbleweed> jtaylor: https://jenkins.qa.ubuntu.com/job/vivid-adt-pyzmq/23/ARCH=amd64,label=adt/console - there's an import error
[18:54] <tumbleweed> but that can't be explained by the 14.4.0 -> 14.4.1 diff
[18:54] <jtaylor> hm
[18:54] <jtaylor> that test shouldn't be uploaded yet
[18:54] <jtaylor> someone nmu'd
[18:54] <jtaylor> or I forgot what I did
[18:54] <jtaylor> ah nmu
[18:54] <tumbleweed> yeah, that was an ubuntu-specific upload
[18:54] <jtaylor> yeyI know of that failure
[18:55] <jtaylor> the reason its not uploaded yet
[18:55] <jtaylor> its minor but didn't have the time to see whats going wrong yet
[18:55] <tumbleweed> I can't see the cause from the diff :(
[18:55] <jtaylor> the failign test is new
[18:55] <jtaylor> just 3 lines
[18:56] <tumbleweed> jtaylor: https://launchpadlibrarian.net/195372601/pyzmq_14.4.0-1build1_14.4.1-0ubuntu1.diff.gz
[18:56] <jtaylor> search for test_ssh
[18:56] <jtaylor> so its not a regression
[18:57] <tumbleweed> oh, I see
[18:57] <tumbleweed> there
[18:57] <tumbleweed> I'll force that test failure then
[18:57] <tumbleweed> no, disable that test
[18:58] <jtaylor> its probably somehow related to the apckaging
[18:58] <jtaylor> building from source normally does not cause the test to fail
[18:59] <tumbleweed> yes, it's probably a bad PYTHONPATH
[19:04] <bdmurray> zul: there is no bug for tracking the python-keystoneclient upload for a trusty SRU?
[19:04] <zul> bdmurray:  the 1.0.0 upload?
[19:05] <bdmurray> zul: right
[19:05] <zul> bdmurray:  that was a mistake please reject it
[19:06] <bdmurray> done
[19:14] <mwhudson> hallyn: yes, with help from BenC iirc
[19:16] <hallyn> mwhudson: smoser found that that fails for libvirt bc apparmor forbids the use of awk/uname.  So smoser switched it to using
[19:16] <hallyn> just shell, but the question is whehter and how to do the uname -m check.
[19:16] <mwhudson> ah
[19:16] <hallyn> 'uname -m' will i assume report ppc personality on ppc64 host,
[19:17] <hallyn> but ppc personality on ppc64host can run qemu-system-ppc64 just fine
[19:17] <mwhudson> i don't know very much about any of this :)
[19:17] <hallyn> so just wondering how best to emulate that
[19:17] <mwhudson> i just wanted to be able to install qemu-kvm on aarch64 and have something useful happen
[19:17] <mwhudson> BenC might know i guess
[19:18] <BenC> hallyn: How would “uname -m” report ppc on a ppc64?
[19:18] <hallyn> mwhudson: BenC: in particular we're wondering whther http://paste.ubuntu.com/10191769/ is ok (minus adding extra ' in last case)
[19:18] <hallyn> BenC: i assumed the same way that it reports i386 if i run 'i386' on x864 host
[19:19] <BenC> svy@yoda1:~$ uname -m
[19:19] <BenC> ppc64
[19:19] <BenC> root@ctsendian:~ # uname -m
[19:19] <BenC> ppc
[19:19] <hallyn> is ctsendian a ppc personality on ppc64?
[19:19] <BenC> bcollins@swarted:~$ uname -m
[19:20] <BenC> x86_64
[19:20] <BenC> ctsendian is a 32-bit ppc system
[19:20] <BenC> (e500mc)
[19:20] <BenC> hallyn: Ah, you mean like if I run “linux32 uname -m”?
[19:20] <hallyn> right
[19:20] <BenC> svy@yoda1:~$ linux32 uname -m
[19:20] <BenC> ppc
[19:21] <BenC> Right, that works
[19:21] <BenC> Let me test the script
[19:23] <BenC> hallyn: Add e5500* and I think it will work well
[19:23] <BenC> hallyn: Does that work for PowerMac as well?
[19:23] <BenC> i.e. does it match POWER*
[19:23] <BenC> like G5 (which is 64-bit)
[19:25] <BenC> hallyn: Here’s one you can test on: https://github.com/jolicloud/base-installer/blob/master/kernel/tests/powerpc/g5.cpuinfo
=== roadmr is now known as roadmr_afk
[19:29] <hallyn> BenC: cool, thanks!
[19:29] <infinity> hallyn: Wait, what does apparmor prevent?
[19:30] <hallyn> infinity: when libvirt starts a qemu instance, that is not allowed to run /bin/awk or /bin/uname
[19:30] <BenC> infinity: libvirt does not have exceptions to execute awk and uname
[19:30] <hallyn> (yes, we could add those, but we also could not)
[19:30] <infinity> hallyn: I feel like that's a bug. :P
[19:31] <infinity> hallyn: But sure, doing it in pure shell can accomplish the same thing.
[19:31] <BenC> hallyn: I would add comments in the script saying why it needs to stay purely shell, else a year from now someone will “fix it” by using snazzy awk and uname calls
[19:32] <infinity> hallyn: The new one seems incorrect, however.
[19:32] <infinity> hallyn: Since it won't catch all ppc64 cases.
[19:33] <BenC> Yeah, and I think POWER4 is not 64-bit?
[19:33] <infinity> BenC: It is.
[19:34] <infinity> I mean, it's mostly a moot point, since older ppc64 CPUs can't run kvm anyway, but newer ones that won't be branded POWER* will be able to.
[19:34] <hallyn> would it be easier to enumerate the 32-bit cases?
[19:35] <infinity> hallyn: Maybe, as only a select few 32-bit CPUs are KVM-capable, but it's still simpler to use the logic we did before. :/
[19:35] <hallyn> infinity: but then i was stil wondering whether the 'uname -m' check was actually wrong
[19:35] <hallyn> ok, we can go half-way,
[19:35] <hallyn> add an apparmor exception for uname but not awk
[19:36] <hallyn> if the uname check was correct
[19:36] <infinity> Maybe.  Or find uname in proc somewhere.  It might be hiding in there somewhere. :P
[19:36] <BenC> hallyn: I assume if you call kvm with in a ppc personality, you’ve put in effort to want to run a 32-bit VM
[19:37] <hallyn> i dunno, seems to me you car eabout what the gues thas, and qemu-system-ppc64 will dtrt wrt that
[19:37] <BenC> infinity: “uname -m” is runtime dependent on the personality
[19:38] <infinity> BenC: Yeah, I'm aware.
[19:38] <BenC> hallyn: I can’t even imagine calling kvm while under a ppc32 personality without knowing it’s happening and without knowing you want to do that for a reason
[19:38] <infinity> BenC: But personalities are also a bit of a lie. :P
[19:38] <hallyn> BenC: i suffer from a well-known lack of imagination :)
[19:38] <BenC> hallyn: Can you give me a real use case for when that even makes sense?
[19:39] <BenC> infinity: Eat your cake and go back to work
[19:39] <infinity> Anyhow, I'd agree that following uname is probably sane.
[19:39] <infinity> BenC: I refuse to work at 3:39am.
[19:39]  * hallyn jealous
[19:39] <BenC> infinity: Have you returned to AU?
[19:40] <infinity> hallyn: Anyhow, I think the default fallback for 32/64 is sane, as we can't know (and don't want to know) what future CPUs might call themselves.
[19:40] <infinity> hallyn: And uname seems the only halway sane way to do that bit.
[19:40] <infinity> BenC: HKG.
[19:40]  * BenC agrees
[19:40] <hallyn> ok, thanks guys - so i'll stick with the current use of uname -m, and at most will reproduce the awk logic with shell
[19:40] <BenC> infinity: Ah
[19:41] <flexiondotorg_> cyphermox, Hi
[19:41] <flexiondotorg_> cyphermox, Are you able to upload some of the packages we reviewed?
[19:42] <cyphermox> did you get a second review?
[19:42] <flexiondotorg_> Not yet. I'll chase tomorrow then.
[19:43] <cyphermox> or ask here if anybody has time to review them :)
[19:43] <flexiondotorg_> Any sponsor here who could review some packages for upload into the official archive?
[19:44] <flexiondotorg_> mhall119, Do you know anyone in not-Europe timezone that could help? With the above?
[19:45] <hallyn> BenC: so you were saying e5500* should run qemu-system-ppcemb right?
[19:46] <infinity> hallyn: Well, currently that matches   e500*|e6500*)
[19:46] <infinity> Did Ben's opinion change since we wrote that? :P
[19:46] <hallyn> infinity: that's what i'm wondering
[19:51] <hallyn> so looking at https://github.com/hallyn/qemu/blob/ubuntu-dev/debian/kvm.powerpc
=== liam_ is now known as Guest73606
[19:54] <hallyn> hm, no
[19:54] <hallyn> previous push failed :)
[19:59] <hallyn> smoser: https://github.com/hallyn/qemu/blob/ubuntu-dev/debian/kvm.powerpc is working for me on test files
[20:00] <infinity> hallyn: You don't really need the POWER*) case if you have the ppc64*) case.
[20:01] <hallyn> infinity: yeah but i figure it avoids an extra exec for uname
[20:01] <hallyn> s
[20:01] <hallyn> (gr, cursorwarp)
[20:01] <infinity> hallyn: Yeah, skips a fork, but meh.
[20:03] <infinity> hallyn: I'd also use consistent formatting for the first two cases compared to the second two for readability, but that's a minor complaint.
[20:03] <infinity> (Ideally multiline for all)
[20:04] <hallyn> infinity: well, skip a fork, and inconsistent wrt personality i guess, so i'll remove it
[20:04]  * infinity goes to bed instead of bikeshedding.
[20:04] <hallyn> infinity: thx - gnight
[20:06] <smoser> hallyn, ok. so its ok to run uname ?
[20:06] <smoser> i just completely randomly picked 'POWER'
[20:06] <hallyn> smoser: will be in about 3 minutes
[20:06] <smoser> i dont know if POWER would be right for qemu-system-ppc or not
[20:06] <hallyn> (dputing new libvirt now)
[20:06] <smoser> (ie, line 18)
[20:07] <hallyn> smoser: yeah i'm getting rid of that now
[20:08] <hallyn> smoser: so maybe https://github.com/hallyn/qemu/blob/ubuntu-dev/debian/kvm.powerpc ?
[20:12] <hallyn> hm, but that's not working
[20:12] <hallyn> oh, heh.  nm
[20:34] <mhall119> flexiondotorg_: what issue?
=== roadmr_afk is now known as roadmr
[20:57] <flexiondotorg_> mhall119, cyphermox has reviewed some packages for Ubuntu MATE and suggested I get a second review prior to upload to the official archive.
[20:57] <flexiondotorg_> mhall119, dholbach has been sponsoring but has been busy recently and not it is late here in Europe.
=== salem_ is now known as _salem
[20:57] <flexiondotorg_> mhall119, I was wondering if a sponsor from a timezone still in office hours could help?
=== kickinz1|afk is now known as kickinz1
[21:07] <mhall119> flexiondotorg_: I'm sure one could, I don't know who though
[21:07] <mhall119> I assume any ubuntu developer can do this?
[21:07] <mhall119> this is really where dholbach is an expert, not me
[21:08] <cyphermox> mhall119: correct, any MOTU can
[21:09] <cyphermox> flexiondotorg_: if you have bugs open for the uploads they could be added to the sponsoring queue so that would make things more easy to track
[21:09] <flexiondotorg_> cyphermox, Understood.
[21:09] <flexiondotorg_> cyphermox, I'll file bugs for ubuntu-mate-settings and ubuntu-mate-artwork tomorrow.
[21:10] <flexiondotorg_> cyphermox, In fact, those have been review by dholbach previously and yourself.
[21:10] <flexiondotorg_> So, those should be good to go.
[21:10] <flexiondotorg_> Right?
[21:11] <cyphermox> if they have been reviewed by two motus yes that's sufficient, so I can upload those
[21:11] <cyphermox> you'll still need at least the metapackage uploaded before you can do much though
[21:12] <flexiondotorg_> cyphermox, Agreed. Can that be uploaded before everything else is in the official archive?
[21:12] <cyphermox> flexiondotorg_: well, yes, but it won't be installable until the other parts are uploaded
[21:12] <cyphermox> so it would stay in proposed I'd say
[21:13] <flexiondotorg_> cyphermox, Understood.
[21:14] <flexiondotorg_> I've got some packages we are actually uploading to Debian because they are general MATE utilities and not specific to Ubuntu MATE.
[21:15] <flexiondotorg_> So, I think we only need the ubuntu-mate-settings, ubuntu-mate-artwork and ubuntu-mate-meta packages, since the other stuff should come via Debian.
[21:16] <cyphermox> sure
[21:16] <cyphermox> and yuyo
[21:17] <flexiondotorg_> cyphermox, Yes, yuyo too.
[21:17] <cyphermox> is there much else that hasn't yet made it in to debian?
[21:17] <cyphermox> because soon you'll end up caught in freezes
[21:17] <flexiondotorg_> cyphermox, We are trying to add MATE Menu, MATE Tweak and Caja-Actions to Debian.
[21:18] <flexiondotorg_> cyphermox, I realise the freeze happens on 19th.
[21:18] <flexiondotorg_> Hoping they can make it before then if not I can either drop them (disappointing) or apply for exception.
[21:19] <flexiondotorg_> cyphermox, I'm just double checking ubuntu-mate-settings and ubuntu-mate-artwork
[21:46] <flexiondotorg_> cyphermox, OK ubuntu-mate-settings and ubuntu-mate-artwork are good to go from my point of view.
[21:46] <flexiondotorg_> cyphermox, Any last thoughts from you?
[22:11] <hallyn> hi - for a build-dependency which only exists on some of the arches on which the package being built exists, is there a good way to say in debian/control "only build-dep on libnuma-dev on these architectures" ?
[22:11] <hallyn> i think i'm being silly
[22:12] <hallyn> pls to ignore
[22:28] <cyphermox> flexiondotorg_: no, I'll look at them after dinner
[22:28] <flexiondotorg_> cyphermox, Many thanks!
=== tkamppeter_ is now known as tkamppeter