[00:37]  * xnox likes Voyager 12.10 - we should totally start calling ubuntu release after the battleships from star trek
[00:50] <mlankhorst> Defiant 13.04!
[00:51] <slangasek> jelmer: hmmmm, do you have plymouth running?
[00:52] <jelmer> slangasek: I had it installed, but I don't think it was running yet
[00:53] <slangasek> jelmer: hmmmm, better questions; do you expect any cryptsetup prompts for non-root filesystems, and if so did you see them?
[00:55] <jelmer> slangasek: yep, I do expect a cryptsetup prompt and I did get one; that was all in 80x25 text mode though. Nothing fancy-looking like I had in Ubuntu.
[00:55] <jelmer> Shouldn't that be the case with plymouth?
[00:56] <slangasek> you got a cryptsetup prompt for a filesystem *other* than the root filesystem?
[00:56] <xnox> jelmer: plymouth in debian default to the "text" plugin, instead of fancy graphics, solar patters and promt boxes.
[00:56] <slangasek> (two different prompting methods, initramfs vs. not)
[00:56] <jelmer> slangasek: Sorry, I have a cryptsetup prompt for lvm
[00:56] <slangasek> jelmer: is your root fs on the vg in question?
[00:56] <jelmer> That LVM contains all my partitions, including the one with /
[00:56] <slangasek> righto
[00:56] <jelmer> Sorry for being unclear.
[00:57] <slangasek> jelmer: workaround: mv /etc/init/cryptdisks-early.conf{,.bak}
[00:57] <jelmer> slangasek: thanks, I'll give that a try and followup
[00:57] <slangasek> I think I reported this bug to dupondje once before
[00:57] <slangasek> possibly only on IRC
[00:58] <slangasek> the problem is that /etc/init.d/cryptdisks-early and /etc/init/cryptdisks-early.conf have the same name but are not the same thing
[01:11] <smoser> hallyn, i have not used hugeadm
[01:56] <achiang> jtaylor: hi, are you on valgrind-devel?
[02:19] <hallyn> smoser: ok, thanks.  i may blog to get opinions on the best way to do waht we want...
[02:56] <infinity> Sweetshark: You around?
[02:57] <infinity> Sweetshark: Can I get you to incorporate the patch from the other libreoffice SRU in the precise queue and reupload (well, once you test that it applies...)
[03:13] <infinity> tjaalton: Your xorg-server SRU to quantal leaves something to be desired. :P
[03:14] <infinity> tjaalton: Could I get you to just re-do -0ubuntu6.1 without the offending patch, instead of the 6.2 that reverts it?
[03:14] <infinity> tjaalton: I'm going to reject all three(!) uploads for now, you can find them in the rejected queue, if you need the source.
[04:42] <pitti> Good morning
[05:31] <tjaalton> infinity: ah, i thought it had to be called 6.2
[05:32] <pitti> cjwatson, ev: thanks for ubiquity's excellent tests/run! I like that it installs all missing build deps, downloads all the embedded source packages etc. by itself
[05:32] <pitti> (it failed its autopkgtests with new pygobject, I'll propose a branch)
[06:07] <pitti> cjwatson, xnox: ubiquity fix sent to https://code.launchpad.net/~pitti/ubiquity/pygobject-fixes/+merge/136327
[06:07] <pitti> I get two test failures (independent from pygobject and the branch), I mentioned those in the MP
[06:10] <infinity> tjaalton: That would be true if the previous one had ever been accepted.
[06:12] <pitti> infinity: darn, eglibc autopkgtest failed again, with a test failure
[06:14] <tjaalton> infinity: right.. I've uploaded 6.1 now, with a fixed changelog
[06:15] <pitti> apparently tst-eintr1 and tst-mqueue5 failed and are not exfail
[06:15] <pitti> migth be VM related?
[06:16] <infinity> pitti: May well be, since they work on the buildds.
[06:16] <infinity> pitti: A lot of those tests are pretty touchy about kernel/hardware/etc.
[06:17] <pitti> at least that's how I interpret https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-eglibc/4/ARCH=amd64,label=albali/console
[06:17] <pitti> (NB that's only the tail of the log; the full log is 57 MB)
[06:18] <infinity> pitti: No, the progressions don't cause a failure.
[06:18] <infinity> The regressions, however, are:
[06:18] <infinity> tst-cancel4.out, Error 1
[06:18] <infinity> tst-cancel5.out, Error 1
[06:18] <infinity> tst-cancelx4.out, Error 1
[06:18] <infinity> tst-cancelx5.out, Error 1
[06:19] <infinity> tst-cpuclock2.out, Error 1
[06:19] <infinity> tst-cputimer1.out, Error 1
[06:19] <infinity> tst-key1.out, Error 1
[06:19] <infinity> tst-key4.out, Error 1
[06:19] <infinity> And almost certainly due to the VM. :/
[06:19] <infinity> Or maybe the raring kernel sucks.
[06:19] <infinity> I just rebooted into it today, I'll have to test.
[06:20] <pitti> *** timer thr2 invoked too soon: 2.903523202 instead of expected 2.903549566
[06:20] <pitti> that's darn close, though
[06:21] <infinity> cpuclock and cputimer are ones I could xfail without feeling too bad about it.  The others, though, I'd like to test on bare metal here and see what's up.
[06:22] <infinity> If I can't reproduce on a raring kernel, I'm at a bit of a loss, mind you.
[06:22] <pitti> infinity: yeah, these might be due to testing in a VM then?
[06:23] <pitti> some jitter in timing tests is rather unavoidable there
[06:23] <infinity> Might be.  We'll have to see.
[06:23] <pitti> I thought that PPA builds would work pretty much the same way?
[06:23] <infinity> Note that even a Panda can grind those tests out fine, though. :P
[06:23] <pitti> do we have eglibc PPA builds?
[06:23] <infinity> The only PPA builds I do are devirt.
[06:24] <pitti> ah, ok
[06:31] <infinity> pitti: Well, let me try that local build now/overnight and see how it ends.
[07:50] <infinity> pitti: Hrm.  So, on a raring kernel on bare metal, I see the cputimer1 regression, but none of the other ones.
[07:50] <infinity> pitti: And adjusting expected failures to suit a VM builder seems wrong.
[07:52] <pitti> infinity: I guess we cannot conditionally exfail them?
[07:52] <pitti> infinity: how much less useful would the rebuild test be if we skip the tests?
[07:52] <pitti> i. e. is it mostly the "it builds" part that you are interested in, or also the tests?
[07:52] <infinity> It would still be useful to know that it builds.
[07:53] <infinity> Knowing if a new toolchain causes a mess of regressions in the testsuite would be nice, but that's also fairly rare and indicative of a pretty large screw up that we'll notice all over.
[07:53] <pitti> it seems it's pretty much the only time when we test the tool chain tests on the actual kernel that it'll be run on
[07:54] <infinity> We could conditionally fail them by shipping a different set of expected results with the test, and having the test copy them in before rebuilding, I guess.
[07:54] <infinity> But maintaining the two sets would be annoying.
[07:54] <pitti> yeah
[07:54] <pitti> I rather thought about exfailing those 5 if DEB_BUILD_PROFILE==autopkgtest or so
[07:55] <pitti> but if it's a text file as opposed to something programmatic, that wouldn't work
[07:59] <infinity> pitti: I can not fail the build on testsuite regressions on that BUILD_PROFILE, at least, so we can complete the build and then look at logs.
[08:00] <infinity> pitti: And perhaps have the test itself re-parse the testsuite output at the end and still exit non-0 on regressions?  It would pretty much always fail, but we'd at least get to complete the package build.
[08:00] <infinity> pitti: Always failed, though, sounds like the sort of red that would just be ignored after a while. :/
[08:01] <pitti> yeah, that wouldn't be very useful
[08:01] <infinity> pitti: Can you waste some cycles and retrigger the test a few times to at least see if the regressions are consistent?
[08:02] <pitti> sure
[08:02] <infinity> pitti: If they are, we can do something like the above, and mangle the testsuite checker to ignore those particular failures or something.
[08:02] <pitti> infinity: we have two runs now (one for -proposed, one for release)
[08:02]  * pitti restarts the -proposed one
[08:03] <pitti> and two arches each
[08:03] <pitti> comparing
[08:03] <dupondje> xnox: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1073649
[08:03] <dupondje> having this every 2 boots :(
[08:03] <dupondje> really *** :P
[08:03] <dholbach> good morning
[08:03] <infinity> Does autopkgtest have any facility for parsing a standard ouput format for pass/fail sets, or does it just assume each test is a single unit?
[08:05] <infinity> pitti: ^
[08:05] <pitti> infinity: http://paste.ubuntu.com/1391100/
[08:06] <pitti> infinity: autopkgtest doesn't do parsing of individual tests results, no
[08:06] <infinity> Okay, that's a reasonably consistent set of regressions.
[08:06] <pitti> just "exit code 0 and stderr == ''", and otherwise attaches the logs
[08:06] <infinity> Basically just the cancel* and key* tests, and sometimes cpuclock/timer.
[08:07] <infinity> Might need to do some digging to see why/how those first two sets are failing.
[08:07] <infinity> The clock/timer stuff, I'm not really concerned about.
[08:07] <pitti> backtrace5 might be i386 only
[08:08] <pitti> the clock/timer ones sound like jitter/race condition
[08:08] <infinity> backtrace5 is already XFAIl anyway.
[08:08] <pitti> infinity: oh, it doesn't say (ignored)?
[08:08] <infinity> If you look at the logs, right under the list you copy/pasted is the list of regressions.
[08:08] <pitti> infinity: anyway, the server that runs autopkgtest sometimes runs 8 VMs in parallel; that will often cause some jitter
[08:08] <infinity> (ignored) is the upstream testsuite ignoring, the next bit is us comparing against our own XFAIL list.
[08:09] <pitti> ah, and then the logs for each failed test
[08:09]  * infinity nods.
[08:12] <infinity> And, actually, I already have cpuclock2 ignored in a few profiles anyway, just not amd64.
[08:12] <infinity> So, I'd be comfy just adding that to every profile.
[08:13] <infinity> But, yeah.  The cancel and key ones are disconcerting.
[08:13] <pitti> infinity: would it be practical to grep -v these tests out of the log in that BUILD_PROFILE before you throw it to the log parser?
[08:13] <infinity> And not reproducible on bare metal.
[08:13] <infinity> pitti: Yeah, something like that could work.  Knowing why those tests fail first would be a requirement, though.
[08:13] <pitti> infinity: so if I were to throw current eglibc into a PPA, we should see the same errors/
[08:13] <pitti> ?
[08:14] <infinity> pitti: Maybe?  Except that the PPAs are hardy dom0 and domU, what's the autopkgtest rig?
[08:14] <pitti> uh
[08:14] <infinity> Obviously a raring domU, at any rate.
[08:15] <pitti> infinity: pretty standard kvm with standard client kernel, i. e. raring for the raring tests
[08:15] <pitti> no xen
[08:15] <infinity> Oh, it's KVM?
[08:15] <infinity> Ew.
[08:15] <infinity> Then no, I bet you won't see this in a PPA. :P
[08:15] <infinity> I can test on my Xen host, but I'm guessing it won't fail the same way at all.
[08:17] <pitti> infinity: so if these are KVM related, and as we primarily want to do a rebuild test, filtering those out seems appropriate to me at least for now
[08:17] <pitti> of course, if they represent an actual problem, our cloud instances would be affected by that
[08:17] <infinity> They're probably KVM-related, yeah.  I'll need to dig a little bit to see for sure.
[08:17] <pitti> but so far these don't seem to be an actual problem
[08:17] <pitti> we are using raring VMs all over the place
[08:17] <infinity> To be fair, most glibc test regressions don't show up as actual real-world problems for any but the most demanding users who like to DoS themselves.
[08:17] <pitti> s/actual problem/obvious problem/
[08:18] <infinity> (Except when something is hideously broken, but the tests that fail when something's hideously broken tend to always pass otherwise)
[08:18] <infinity> But, yeah, to be sure, I want to hunt down WTF those tests are testing.
[08:18] <infinity> They may well be exposing a KVM bug we want to fix.
[09:28] <xnox> @pilot in
[09:28]  * dholbach hugs xnox :)
[09:29] <xnox> dholbach: I am suspecting you have a script running..... ;-) did the topic change?!
[09:29] <dholbach> no
[09:29] <dholbach> and no
[09:29] <xnox> dholbach: ack and ?!
[09:30] <xnox> bug 1
[09:30] <dholbach> tm_T: do you have an idea why the bot did not pick up "@pilot in"?
[09:31] <Tm_T> dholbach: ubottu is gone atm
[09:32] <Tm_T> dholbach: the situation is under investigation
[09:32] <dholbach> thanks a bunch tm_T
[09:32] <Tm_T> np
[09:32] <dholbach> xnox, ^ ubottu is taking some well-deserved holidays :)
[09:33] <xnox> dholbach: we should invest in a marvin model.
[09:34] <dholbach> xnox, reading "here I am, brain the size of a planet..." in my mornings might depress me too much :)
[09:35] <hrw> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676533 - can we merge that in ubuntu while waiting for debian to do that as well?
[09:38] <xnox> hrw: sure, if it applies cleanly.
[09:39] <xnox> tyhicks: see ^ hrw
[09:42] <hrw> it does
[09:44] <xnox> hrw: I am patch piloting right now, and will upload this sometime today. Will that do?
[09:46] <Tm_T> grah, sorry
[09:47] <Tm_T> there ya go
[09:47] <nigelb> Heh, careful there ;-)
[09:49] <Tm_T> nigelb: I'm old and slow, now I need to be careful too?! (;
[09:50] <hrw> xnox: would be lovely
[09:52] <xnox> hrw: run import-bug-from-debian against it, assigned to myself and subscribed you for notifications =)
[09:52] <nigelb> Tm_T: ;)
[09:58] <hrw> xnox: thanks
[10:02] <OdyX> tkamppeter_, pitti: I've pushed two commits to address CVE-2012-5519 in cups to the git repository master branch. It'd be great if you could take a look and eventually upload to raring. I'm very much afraid that this wouldn't qualify to anything near testing/stable/quantal as it implies a configuration files change, etc.
[10:03] <pitti> OdyX: no, indeed; migrating an user-customized conffile over to that new one is going to be hard enough (does that work even?); doing it as a security update is going to be next to impossible
[10:04] <pitti> OdyX: I think for a security update we just want a small patch that temporarily drops privileges to lp or lpadmin when reading files
[10:04] <OdyX> pitti: yes. But that will end up in upstream's 1.6.2 and trunk eventually, so a configuration prompt (over files previously modified through a web interface) doesn't look near to anything easy.
[10:05] <OdyX> pitti: I'm beginning to think some of these could not be turned to be not configurable at all…
[10:05] <pitti> TBH I don't quite see the point of this chane
[10:05] <pitti> change
[10:06] <OdyX> pitti: as I understand upstream: some stuff stays web-configurable, the rest is only config-file configurable.
[10:06] <pitti> yes, but upstream pretty much established the situation that every user will have a modified config file
[10:07] <pitti> so you can't just split it and call that a security fix, because it will not help at all with actually applying that update :(
[10:07] <Sweetsha1k> infinity: you mean I should merge in the patch for bug 585910?
[10:07] <pitti> I guess cupsd will fail if it sees settings which should now be in cups-files.conf, or ignore those
[10:07] <pitti> either breaks existing systems
[10:07] <OdyX> well, it's an upstream massive change that, by magic, happens to fix that.
[10:08] <pitti> for new installs, yes
[10:09] <OdyX> pitti: what do you propose ?
[10:09] <pitti> the apparmor profile should actually take care of the worst stuff
[10:09] <pitti> OdyX: as I said; I think cupsd should temporarily drop privileges when accessing log files
[10:10] <OdyX> pitti: I'm afraid I don't have the skills to implement that.
[10:11] <OdyX> pitti: I'll comment on the Debian bug with pointers to the patch and its implication, if you can chime in that'd be great.
[10:11] <pitti> ok
[10:11] <xnox> slangasek: do we have a user tag for upstart jobs support in debian?
[10:11]  * xnox just came across http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687016
[10:12] <Sweetshark> infinity: for precise that makes sense, but not for quantal. The fix is claimed to be in 3.6.4 and that one will be tagged as a micro release this week: http://wiki.documentfoundation.org/ReleasePlan/3.6#3.6.4_release -- given the time things hangs in the queue, the last thing I want to do is make upload a pre-3.6.4 version for quantal now in addition, just for one fix ...
[11:27]  * xnox did dput instead of sbuild *sigh*
[11:28]  * xnox needs to wrap dput such that it aborts if there is no matching binary .build file.
[11:28] <Laney> use UNRELEASED?
[11:29] <xnox> Laney: I don't like that. I should be building the package that will be uploaded.
[11:29] <ogra_> ++
[11:29] <xnox> & testing.
[11:30] <xnox> also I once saw a package that was parsing the release line in the changelog instead of using dpkg-vendor....
[11:30] <xnox> meh, the package builds fine and works fine, so no damage done.
[11:31] <Laney> by not using it you risk uploading a package you haven't built or tested at all ...
[11:31] <xnox> true.
[11:32] <xnox> pitti: I guess you want ubiquity to be uploaded such that pygobject can be unblocked?
[11:32] <pitti> xnox: it's not super-urgent, but would be nice in the next days
[11:32] <pitti> xnox: but I guess these two test failures need addressing first, or do they not happen for you?
[11:33] <xnox> pitti: already fixed =) together with pep8/pyflakes warnings from your changes
[11:33] <xnox> pitti: how do I setup jenkins to run tests on every commit for lp:ubiquity?
[11:34] <pitti> ubiquity/frontend/gtk_ui.py:471: redefinition of unused 'GLib' from line 52
[11:34] <pitti> ah, sorry about that
[11:34] <pitti> xnox: thanks for pointing out, will run these next time
[11:34] <xnox> pitti: and are there other packages left to fix with new pygobject?
[11:34] <pitti> xnox: I fixed dbusmock, the rest succeeded
[11:34] <xnox> pitti: also pep8 in raring complains about "over-identation"
[11:34] <xnox> pitti: I'll upload then.
[11:35] <pitti> xnox: indeed, the s/GObject/GLib/ of course didn't adjust the continuation lines
[11:36] <pitti> xnox: as for jenkins, I'm not sure; I think you should talk to didrocks or jibel, who set up the equivalent of that for unity
[11:36] <xnox> pitti: thanks a lot for your fixes. As you can see we don't follow gtk developments that close ;-) we are just started to transition things here and there for width-for-height widgets.
[11:36] <xnox> pitti: ack.
[11:37] <pitti> xnox: no worries; I broke it, I fix it :)
[11:37] <pitti> xnox: oh, aptdaemon was another victim, but I fixed that yesterday
[11:37] <pitti> it's great to be able to hold this back in -proposed and run all the autopkgtest stuff against that without breaking the distro
[11:42] <xnox> pitti: rock star ;-)
[11:43] <OdyX> pitti: there, sent more info to the bug.
[12:33] <hrw> someone know how to tell modem-manager to not touch serial ports at all?
[12:44] <seb128> slangasek, bdmurray, infinity, ScottK, SpamapS: is there any way somebody could SRU review http://launchpadlibrarian.net/123208124/gnome-settings-daemon_3.4.2-0ubuntu0.6_source.changes this week? it's a annoying issue in the LTS and it would be good to get the fix in and some other g-s-d fixes are lining up for after this one so it would be good to get that one in to create room for the next one
[12:54] <mlankhorst> mvo: poke, I posted a question on #debian-apt a few days ago, enver got an answer :P
[12:54] <mlankhorst> s/env/nev/
[12:57] <xnox> pitti: in raring, in sbuild/schroot "from gi.repository import Gtk" fails
[12:58] <pitti> xnox: any error message?
[12:58] <xnox> http://paste.ubuntu.com/1391594/
[12:58] <pitti> xnox: needs xvfb-run?
[12:59] <pitti> this is nothing new, Gtk and the old pygtk have always needed a $DISPLAY
[13:00] <xnox> pitti: well something changed in ubiquity dependencies then. Previously I just ran sbuild on ubiquity and the test-suite would run and succeed, now it didn't for me.
[13:00] <xnox> or something change in the minimal install / chroot.
[13:01] <pitti> ./tests/run:    os.execvp('xvfb-run', argv)
[13:01] <pitti> it seems to try at least
[13:01] <xnox> hmm...
[13:02] <xnox> ok, running python3 under xvfb-run does import Gtk just fine.
[13:02]  * xnox goes looking into ubiquity test-suite
[13:02] <pitti> xvfb-run python3 -c 'from gi.repository import Gtk'
[13:02] <pitti> does that work?
[13:02] <xnox> yeap.
[13:02] <pitti> (in schroot)
[13:02] <xnox> yes.
[13:31] <mdeslaur> pitti: FYI, I plan on simply disabling being able to modify cupsd.conf via the web interface...there a _way_ too many options in there that are dangerous
[13:31] <pitti> mdeslaur: but doesn't use it the same auth mechanism as "lpadmin"?
[13:31] <pitti> mdeslaur: you can hardly disallow lpadmin and the command line tools
[13:32] <pitti> mdeslaur: I had actually assumed that the AA profile would prevent the worst of it, like reading /etc/shadow
[13:32] <pitti> hm, but I guess cupsd needs that
[13:32] <mdeslaur> pitti: well, /etc/shadow is allowed by the apparmor profile, unfortunately :)
[13:32] <mdeslaur> pitti: what do you mean disallow lpadmin?
[13:32] <pitti> mdeslaur: I thought the point was that lpadmin group users could change the conffile, and by that read files as root
[13:33] <pitti> mdeslaur: i. e. everyone who can read the auth cookie in /var/run/cups/certs/
[13:33] <mdeslaur> pitti: yes, but only via the web interface, as by default cupsd.conf is owned by root
[13:33] <mdeslaur> pitti: they can change a whole bunch of configuration options in that file, including the default directories, etc.
[13:33] <pitti> ah, you can't set arbitrary options through lpadmin
[13:34] <pitti> ok, seems fine
[13:35] <mdeslaur> no, it's only a web interface issue...and I can't think of a really good reason why editing cupsd.conf is absolutely necessary there
[13:35] <mdeslaur> the upstream change is _way_ too intrusive as a security update, as you said earlier
[13:35] <didrocks> cjwatson: hey, not sure if that's a problem in more regular time where we don't have multiple uploads of libreoffice/webkit/gcc at the same time and more powerpc builders, but the ppa https://launchpad.net/~ubuntu-unity/+archive/daily-build has the "release" priority score (so 1500) and all the rest landing in distro has the "-proposed" one (3000). The net result is that
[13:35] <doko> infinity, https://launchpadlibrarian.net/124204285/buildlog_ubuntu-raring-armhf.gcc-4.7_4.7.2-12ubuntu1_FAILEDTOBUILD.txt.gz
[13:35] <didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4014568 is waiting for 11h and counting (a lot more as gcc will be built next…)
[13:35] <pitti> mdeslaur: yeah; we don't even have a way of migrating the config files
[13:36] <mdeslaur> pitti: yeah, that's going to be a pain for new versions :(
[13:36] <cjwatson> didrocks: It probably isn't a problem normally; I've scored it up for now
[13:37] <didrocks> cjwatson: thanks
[13:37] <OdyX> mdeslaur: disabling web-edit is probably the safest course of action for security upgrades indeed.
[13:37] <OdyX> jonas had a patch for that on the debian bug.
[13:38] <mdeslaur> OdyX: yeah, that's what I plan on doing...ie: http://paste.ubuntu.com/1391676/
[13:38] <OdyX> btw, if the next cups ubuntu upload could be based on the git repository, it'd be great to get changes in there tested.
[13:38] <mdeslaur> OdyX: ah, I am going to hide the option completely
[13:39] <OdyX> mdeslaur: looks intrusive but I don't have a better option. Could you comment with that patch on the bug, cc'ing debian security team ?
[13:39] <mdeslaur> OdyX: sure, let me test it properly first though
[13:40] <OdyX> mdeslaur: cool, thanks.
[13:48] <SpamapS> hrm, did something change in Debian experimental where there's a new way to build non-native packages without a .orig tarball? PHP5 has just a .tar.gz with the whole source in it.
[13:49] <SpamapS> which really confuses the package importer
[13:49] <OdyX> SpamapS: php5/experimental looks like it's a broken upload
[13:50] <OdyX> SpamapS: it's native where it shouldn't (at all)
[13:50] <Laney> Format: 1.0
[13:50] <OdyX> even then: see the .changes file: php5_5.4.8-1.tar.gz
[13:51]  * OdyX reports a bug.
[13:52] <SpamapS> OdyX: thanks
[13:52] <SpamapS> thought for a second I was losing my mind
[13:53] <SpamapS> Its worth noting that 5.4.9 is out, so perhaps the right thing is just to build 5.4.9's upload properly
[13:55] <OdyX> SpamapS: making the maintainer aware can help that :)
[14:00] <seb128> doko, infinity: hey, could one of you look at the patch on https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/1079768 (from the sponsoring queue)?
[14:01] <seb128> no bot?
[14:01] <seb128> bug title is " FTBFS with glibc-2.16 (due to outdated gnulib) "
[14:04] <seb128> pitti, can you mark https://code.launchpad.net/~kampka/ubuntu/quantal/fwknop/upstart-support/+merge/124683 merged (it got uploaded to raring but was targetting the wrong serie)
[14:04] <pitti> seb128: done
[14:04] <seb128> pitti, danke, same for https://code.launchpad.net/~wb-munzinger/ubuntu/precise/havp/fix-init-script/+merge/125949 ?
[14:05] <pitti> done
[14:05] <seb128> pitti, danke ;-)
[14:05] <pitti> de rien
[14:05] <seb128> pitti, reject https://code.launchpad.net/~bkerensa/ubuntu/quantal/kubuntu-docs/fix-for-1049278/+merge/125965 ?
[14:05] <seb128> pitti, sorry to bother you with those, hate launchpad acls...
[14:05]  * seb128 is cleaning a bit the sponsoring queue
[14:05] <pitti> seb128: pas de problem, just ask
[14:05] <pitti> seb128: it's great to clean the queue
[14:05] <arges> cjwatson, hello. looking at bug 1075181 regarding uefi secureboot for 12.04.2. Are there images available already to test and verify some of these packages?
[14:06] <seb128> pitti, ;-)
[14:09] <seb128> pitti, https://code.launchpad.net/~nicolozilio/ubuntu/precise/software-center/fix-for-842706/+merge/127102 ... work in progress or rejected (cf mvo comment which says it's targetting the wrong vcs and has some "to fix")
[14:10] <pitti> seb128: you can do WIP yourself
[14:10] <seb128> pitti, not on a stable serie no
[14:10] <seb128> pitti, I don't even have edit mode for the status on that one
[14:11] <seb128> like the small yellow pen icon
[14:11] <seb128> it's not displayed next to the status...
[14:11] <pitti> seb128: lequel, WIP où rej?
[14:11] <seb128> pitti, reject I guess
[14:11] <seb128> since that's the wrong vcs
[14:11] <pitti> done
[14:11] <seb128> danke
[14:29] <tkamppeter> pitti, OdyX, I have looked into the GIT repo of CUPS and I see that on Oct 30 OdyX has removed my pstops-based-workflow-only-for-printing-ps-on-a-ps-printer.patch as it breaks tests. Is there no way to modify the tests?
[14:30] <OdyX> tkamppeter: I didn't find. If you enable that patch, the tests fail and I couldn't understand why.
[14:31] <OdyX> tkamppeter: see also https://www.cups.org/str.php?L4220 and https://launchpad.net/~odyx/+archive/printing/+packages results
[14:32] <OdyX> tkamppeter: also, I'm testing the introduction of ucf to handle /etc/cups/cupsd.conf with the extensive upstream patch
[14:43] <seb128> mdeslaur, do we need to keep security-sponsors subscribed to https://bugs.launchpad.net/ubuntu/+source/request-tracker3.8/+bug/1004834 ?
[14:43] <mdeslaur> seb128: no, thanks I removed it
[14:43] <seb128> mdeslaur, it's on the sponsoring queue but it doesn't seem there is a lot to be acted on
[14:43] <seb128> mdeslaur, thanks
[14:44] <mdeslaur> seb128: no...in fact, I'll release them now
[14:44] <seb128> cool
[14:45] <mdeslaur> seb128: thanks
[14:53] <diwic> pitti, is the SRU queue still weeks long? I uploaded an SRU for PulseAudio (on 12.04) a while ago but nothing has happened since.
[14:53] <pitti> yes, https://launchpad.net/ubuntu/quantal/+queue?queue_state=1 is quite long
[14:53] <pitti> https://launchpad.net/ubuntu/precise/+queue?queue_state=1 too
[14:55] <diwic> ok
[14:56] <diwic> pulseaudio is not in that list though, so maybe something else went wrong?
[14:57] <diwic> pitti, and it can't have gone through to proposed without me noticing, because then it would have shown up in https://launchpad.net/ubuntu/+source/pulseaudio I believe
[14:58] <pitti> diwic: usually the SRU reviewers should leave a comment in the bug if they reject a package
[14:58] <pitti> diwic: which release did you upload it to?
[14:58] <diwic> 12.04
[14:58] <pitti> diwic: on the +queue page you can look at the rejected queue and check if it's there
[14:59] <diwic> nope, not there either
[15:03] <pitti> hm, then it seems it wasn't actually uploaded?
[15:04] <ogra-cb> or accidentially uploaded to a PPA
[15:05] <diwic> pitti, maybe I did something else wrong...I'll check in a while
[15:07] <barry> didrocks, mvo do either of you have time for a quick review of https://code.launchpad.net/~barry/piston-mini-client/lp1077083/+merge/135449 ?
[15:07] <barry> didrocks, mvo or should i jfdi? :)
[15:08] <didrocks> barry: TBH, you are the most knowledgeable on that than I can ever do, wait on mvo's answer or maybe Anthony's? :)
[15:08] <seb128> pitti, https://code.launchpad.net/~felix-lawrence/ubuntu/quantal/ubuntu-mono/fix-for-748861/+merge/129859 <- can you set to "merged"?
[15:08] <pitti> done
[15:09] <seb128> danke
[15:09] <dholbach> Is anyone interested in the ubuntu development hangout (on air) at 16 UTC and talk about the projects you're working on?
[15:09] <dholbach> (in 50m)
[15:10] <ogra-cb> mvo, could it be that your app-install-data-ubuntu upload from today reverts cjwatson's bugfix from yesterday ? i see strange image build failures re-occuring that were caused by it
[15:10] <seb128> ogra-cb, mvo: let me have a look
[15:10] <barry> didrocks: cool.  if the diff doesn't look insane and achuni or mvo don't respond i may just go for it :)  (i still want to upload tox first so i can enable the tests)
[15:11] <barry> didrocks: then i'll enable the py3 version of the library
[15:11] <mvo> ogra-cb: it was spout, it should be ok
[15:11] <didrocks> sweet \o/
[15:11] <ogra-cb> mvo, hmm
[15:11] <seb128> mvo, ?
[15:12] <mvo> barry: I tear my hairs out over a crash in python with glib and threading right now, once I finished that I can check the diff out
[15:12] <mvo> ogra-cb: do you have a log of the error?
[15:12] <seb128> ogra-cb, mvo: the fix is not reverted according to the debdiff: http://launchpadlibrarian.net/124162411/app-install-data-ubuntu_0.12.10.7_13.04.diff.gz
[15:12] <barry> mvo: :(  ping me if i can help
[15:13] <mvo> seb128: sorry, the context is that "spout:spout.desktop" was incorrect but it should be good, just verified in my branch
[15:13] <ogra-cb> mvo, http://paste.ubuntu.com/1391846/
[15:14] <seb128> ogra-cb, mvo: the issue is /usr/share/app-install/desktop/gmpc:gmpc.desktop
[15:14] <seb128> "Name=Gnome Music Player Client
[15:14] <seb128> de música del GNOME
[15:15] <seb128> "
[15:15] <ogra-cb> mvo, this is teh same error all image builds had yesterday .... i did two image builds today, the first one worked fine, the log is from the second one (after app-install-data-ubuntu was promioted i guess)
[15:15] <seb128> ogra-cb, mvo: that's invalid
[15:15] <ogra-cb> aha
[15:15] <ogra-cb> new issue, same symptoms then
[15:15] <ogra-cb> fun
[15:15] <seb128> we really need an autopkgtest on app-install-data-ubuntu
[15:15] <seb128> which checks the included .desktops validity through the pyxdg parser on build
[15:16] <ogra-cb> ++
[15:16] <mvo> barry: maybe, I think I simply need to not use threading there at all, it breaks in different way with glib and python :/ I can either have it crash with "Fatal Python error: PyThreadState_Get: no current thread
[15:16] <mvo> " when deallocing some random pkg or it appears to be simply super slow. anyway, that is not helpful I keep digging until I either have a testcase or something useful
[15:16] <mvo> seb128: aha, fun :/
[15:16] <seb128> mvo, I can fix that .desktop and reupload if you want (there is also a trivial merge request for it on the sponsoring queue to add misc:Depends)
[15:17] <mvo> seb128: I can create a verification step during the extraction that deletes the ones that are broken
[15:17] <mvo> seb128: the depends thing is merged, thanks :)
[15:17] <seb128> mvo, oh, great, danke
[15:17] <seb128> mvo, verification step sounds like manual work, we should just have an autopkgtest for it ;-)
[15:18] <seb128> mvo, want to do the upload if you have a checkout ready?
[15:18] <mvo> seb128: as part of the automatic update :) not manal, no
[15:18] <mvo> seb128: sure, I can do that
[15:18] <seb128> mvo, thanks
[15:18] <mvo> seb128: a good excuse to stop looking at this thread bug that makes me really unhappy
[15:18] <seb128> mvo, gmpc.desktop Name's being on 2 lines is the only issue
[15:19] <seb128> mvo, ogra-cb: I checked, once that fixed xapian is happy again
[15:19]  * ogra-cb hugs seb128 
[15:19] <ogra-cb> thanks !!
[15:19]  * seb128 hugs ogra-cb back
[15:22] <sconklin> @pilot-in
[15:23] <sconklin> @pilot in
[15:24] <didrocks> sconklin: issue to enter the cockpit? :)
[15:24] <seb128> sconklin, I think the bot is on holidays on something
[15:24] <seb128> dholbach, ^
[15:25] <sconklin> whetever. I don't need a bot in order to get my work done anyway
[15:25] <dholbach> sconklin, didrocks, seb128: yes, tm_T said that ubottu is gone and it's under investigation
[15:25] <bdrung> sabdfl: https://overbenny.wordpress.com/2012/11/27/code-name-for-ubuntu-18-04-lts/
[15:25] <vibhav> does "debuild -S -sa" also need the build-depends to be installed?
[15:25] <jpds> vibhav: Yes.
[15:26] <vibhav> jpds: any way to skip that?
[15:26] <jpds> vibhav: Well, you might need things like cdbs installed.
[15:26] <Laney> I don't think it does, but it does run the clean target
[15:26] <seb128> yeah, you don't need build-depends to build the source
[15:26] <Laney> so whatever you need to execute that, unless you skip it (with -nc)
[15:26] <ogra-cb> heh
[15:27] <Laney> which risks having a dirty source package, so check the diff
[15:27] <ogra-cb> for like 70% of the packages
[15:27] <vibhav> Laney: yes, that was the argument I was talking about
[15:27] <ogra-cb> the other 30 do evil stuff in the clean target
[15:27] <Laney> yep
[15:28] <Laney> for example control.in → control mangling might happen then
[15:28] <Laney> so, beware
[15:28] <xnox> vibhav: currently there is no way to encode which build-depends are needed for clean target only vs a full build. So if you decide to skip any of them, you may get failures to create source package or force missgenerated source package.
[15:29] <vibhav> Well, lets hope that none of that happens
[15:30] <ogra-cb> i would consider it a bug if the build doesnt fail then though
[15:30] <xnox> pitti: it may have been transient, as now they all pass. Weird.
[15:30] <xnox> (ubiquity test-suite failing in sbuild)
[15:31] <mvo> seb128: test as part of the extraction added
[15:31] <seb128> mvo, you rock ;-)
[15:32] <ogra-cb> wow
[15:32]  * ogra-cb bows in front of mvo
[15:34] <seb128> ogra-cb, mvo: note that http://anonscm.debian.org/gitweb/?p=collab-maint/apt-xapian-index.git;a=commitdiff;h=cefa7e5eed2ed0336aaf1fc183cc10faf119b5eb as well
[15:34] <seb128> ogra-cb, mvo: that's a fix in the debian git for apt-xapian-index to continue rather than bailing out on parsing errors
[15:34] <mvo> meat
[15:34] <mvo> eh
[15:34] <mvo> neat
[15:35] <Laney> mmm meat
[15:35] <mvo> (what a lousy vegetarian I am!)
[15:35] <seb128> mvo, note also that we are one version behind debian for apt-xapian-index... if you feel like merging at some point ;-)
[15:35] <ogra-cb> yummy
[15:35] <seb128> lol
[15:36] <OdyX> tkamppeter, pitti : I have now pushed a move to ucf including making the upgrade smoother. The preinst probably has to be amended for the Ubuntu versions but I think the rough idea is there, wdyt ?
[15:41] <vibhav> hmm, its seems to build now
[15:42] <vibhav> Laney: How does -nc result in unclean source packages?
[15:43] <Laney> think about what could happen if you don't clean your tree
[15:45] <GunnarHj> cjwatson: Are you there?
[15:51] <cjwatson> arges: http://cdimage.ubuntu.com/precise/daily-live/ - but I don't think it has a signed kernel in place yet
[15:52] <arges> cjwatson, ok I'll ask apw when those will land
[15:53] <cjwatson> arges: The signed kernel is in precise-proposed but it needs a couple of packaging fixes which apw knows about
[15:53] <cjwatson> GunnarHj: slightly
[15:53] <mvo> pitti: is there a knonw segfaul threading fix in python-gi from 3.4.0 to 3.4.2? I get a segfault here for the reviews helper in quanal but it works fine in raring. If you don't know right away, no worries, I can start digging
[15:53] <mvo> pitti: I would like to backport that fix (if there is one :)
[15:53] <arges> thanks
[15:54] <GunnarHj> cjwatson: Wanted to mentioned that I failed to install from the desktop ISO (i386) this morning. It hanged at the point when it asks you to select a picture, and didn't complete the installation. Tried twice.
[15:55] <GunnarHj> cjwatson: daily build
[15:56] <apw> cjwatson, i believe you needed the meta packages made (should be out in -proposed) and Provides: linux-image which i want to slip in once this -propsoed kernel makes it out
[15:56] <apw> cjwatson, was there anything else i've forgotten
[15:57] <cjwatson> xnox,stgraber: ^- could you look at GunnarHj's problem?  I'm about to be on a call
[15:57] <cjwatson> apw: Right, those two
[15:57] <cjwatson> apw: The metapackage should've been sufficient to make this work - when did that lalnd?
[15:58] <cjwatson> hmm, Friday
[15:58] <apw> cjwatson, i thought they hit -proposed like friday
[15:58] <cjwatson> something else wrong then
[15:58]  * apw checks
[15:58] <stgraber> GunnarHj: can you try removing /usr/lib/ubiquity/plugins/ubi-webcam.py, see if that helps?
[15:59] <xnox> GunnarHj: stgraber: there is also a command line option to disable webcam. I believe Laney was working on porting ubiquity to the new gst api?!
[15:59] <GunnarHj> stgraber: Sure, can do that. But not right now; will try your suggestion later.
[16:00] <xnox> GunnarHj: --no-webcam as commandline flag (launch ubiquity from terminal from live session)
[16:00] <cjwatson> apw: Ah, wrong seeds, my bad
[16:00] <stgraber> xnox: yeah, Laney was doing some work on that, I don't think any of it landed yet, so my guess is that whatever commit I pulled out of gstreamer in precise to fix the hang was re-introduced
[16:00] <Laney> yes but that's not relevant to this problem
[16:00] <apw> cjwatson, yay (sort of :)
[16:00] <xnox> GunnarHj: or UBIQUITY_NO_WEBCAM=1 as bootarg.
[16:00] <apw> cjwatson, the Provides: just makes the CD too big right?
[16:01] <xnox> GunnarHj: did you select the picture & managed to click next and then it hang? or before?
[16:01]  * xnox wonders if it's the webcam hagging or something after that step.
[16:01] <cjwatson> apw: Yeah
[16:01] <GunnarHj> xnox, stgraber: Do you (xnox) with the latter mean an env. var? It hanged before.
[16:01] <cjwatson> apw: Or at least was the most immediate cause of that - I tend to find out about such problems in series
[16:02] <cjwatson> arges: OK, think I've fixed that, tomorrow's build *should* have the signed kernel
[16:02] <arges> cjwatson, great!
[16:02] <apw> cjwatson, ok hopefully i can get that change in fairly soon, we are nearly ready to release whats there
[16:07] <mvo> barry: just reviewed the branch if you don't mind I will merge and upload?
[16:07] <barry> mvo: that would be fantastic.  once that lands i will work on enabling the py3 version of the package
[16:09] <slangasek> xnox: user tag> no
[16:11] <xnox> GunnarHj: environment variable, command line flag or moving ubi-webcam.py out of the way should skip the webcam page. Then we will at least know if the installer is borked in the webcam page or somewhere else.
[16:11] <GunnarHj> xnox: Ok, I'll try it later and let you know.
[16:11] <pitti> mvo: we have a lot of fixes in 3.4.x, but not a specifically threading one (http://git.gnome.org/browse/pygobject/log/?h=pygobject-3-4)
[16:12] <pitti> mvo: can you reproduce this easily? then bisecting might be easiest
[16:12] <pitti> mvo: sure that it's in pygi, and not in glib?
[16:12] <xnox> slangasek: do we need one, or shall we it more gradually?
[16:12] <xnox> slangasek: maybe we can use dholbach's army of contributors here =) to find and forward upstart jobs to debian.
[16:13] <mvo> pitti: could be glib too, but its crashin in "#0  subtype_dealloc.25740 (self=
[16:13] <mvo> " ... #13 pygi_callable_info_invoke (info=0x16e3850, py_args=<optimized out>, kwargs=
[16:14] <pitti> mvo: need to leave for today; if you can reproduce it, please open a LP bug and subscribe me, then I'll have a look tomorrow morning
[16:14] <mvo> pitti: thanks
[16:14] <mvo> pitti: will do
[16:16] <slangasek> xnox: at this point, it should be part of standard Debian merge & upstreaming responsibilitie
[16:16] <slangasek> s
[16:16] <xnox> ack.
[16:17] <xnox> slangasek: but the boot process is the same as in ubuntu or different? e.g. does mountall & udev handle it, or do we have a divergence there for now.
[16:17] <slangasek> xnox: it's mountall+udev+ifupdown the same as in Ubuntu
[16:17] <xnox> cool.
[16:17] <slangasek> Debian *also* has startpar, which is an interesting wrinkle
[16:18] <slangasek> it has consequences for how you name your upstart jobs vs. init scripts, to make sure startpar doesn't try to do double duty
[16:19] <xnox> *shrug* ok.
[16:19] <slangasek> and to make sure you don't deadlock your boot because startpar is waiting for an upstart event that won't happen
[16:20] <slangasek> for instance, we're close to being able to sync cryptsetup in Debian+Ubuntu now; but I probably need to get startpar working in raring first before we can be completely synced
[16:22] <xnox> slangasek: intersting. but currently cryptsetup in ubuntu uses both upstart and initscripts (boot and shutdown respectively)
[16:23] <xnox> and I don't quite see how that can be currently resolved. Unless it already has been in Debian.
[16:24] <xnox> @pilot out
[16:25] <seb128> xnox, sorry you don't get to bail out of piloting today, not bot to allow that ;-)
[16:25]  * xnox please somebody remove me from the topic, as the bot is currently away from keyboard.
[16:25] <mvo> barry: lp:~software-store-developers/piston-mini-client/packaging has my updated version with py2 and py3 if you could do a quick double check that would be cool. I think its good but I am a bit worried about the amount of boilerplate I had to add to debian/rules :/
[16:25] <seb128> xnox, that's dholbach's secret plan to deal with the sponsoring queue backlog
[16:25] <xnox> seb128: well it's not like it's the first time somebody was left "piloting" for days =)))))
[16:25] <Laney> xnox:  you can do it yourself
[16:26] <xnox> ogra-cb: thanks.
[16:26] <xnox> Laney: as far as I know, I am a mere mortal w.r.t. channel access rights. Note the bot is absent.
[16:26] <barry> mvo: cool, i'll take a look after lunch
[16:26] <mvo> barry: great, thanks
[16:26] <Laney> the topic isn't locked
[16:27] <xnox> Laney: cool. Thanks for letting me troll^W know
[16:27] <xnox> ;-)
[16:27] <Laney> (see how the channel mode doesn't have +t)
[16:28]  * xnox is confused with my irc client
[16:29] <barry> xnox: C-c C-t :)
[16:30] <xnox> barry: i used to use erc, but not anymore. It used to become sluggish for me after a few days of idling & no messaging menu integration, unless that has changed.
[16:33] <mitya57> hey arges, I want to ask you about https://launchpad.net/ubuntu/+source/sphinx/1.1.3+dfsg-4ubuntu2
[16:34] <mitya57> (1) is that still actual or can it be dropped? (2) why doesn't that ftbfs happen in debian?
[16:35] <arges> mitya57, hi
[16:35] <mitya57> o/
[16:38] <arges> mitya57, i'm not sure why it doesn't happen in debian. i just saw the ftbfs in ubuntu and fixed it. it was a really weird issue where the xvfb-run will not work the first time it is run, and works fine the next time it is run
[16:38] <xnox> arges: !!!! thank you.
[16:39]  * xnox had all sorts of weird stuff going on with xvfb-run & ubiquity test suite
[16:42] <tkamppeter> OdyX, according to the log the CUPS tests fail due to job control files not being purged (FAIL: 8 job control files were not purged.). I am wondering why changes in the filter chain prevent CUPS from purging job control files. Seems to be a bug in CUPS.
[16:43] <mitya57> arges, so it's a heisenbug, will keep the change :)
[16:43] <mitya57> thanks
[16:43] <OdyX> tkamppeter: that's another problem, see the upstream bugreport.
[16:43] <arges> mitya57, yea I think that's the best way to describe it. np
[16:44] <OdyX> tkamppeter: for both I suspect a problem with libcupsfilters
[16:55] <mvo> pitti: hm, hm, 3.4.2 does not build on quantal, oh well (needs newer gobject-introspection-1.0)
[17:16] <seb128> stgraber, hey, can you mark https://code.launchpad.net/~sonia/ubuntu/quantal/vim-scripts/fix-for-31204/+merge/126966 as merged?
[17:16] <seb128> xnox uploaded to raring but the merge request is against quantal
[17:17] <mvo> pitti: found the crash, https://bugzilla.gnome.org/show_bug.cgi?id=688067 - will prepare a SRU tomorrow
[17:17] <xnox> seb128: darn, thought I included all the correct links with "actions todo" in the report.
[17:17] <xnox> seb128: thanks for spotting.
[17:17] <seb128> xnox, yw ;-)
[17:22] <arges> hallyn, hello. looking at libvirt bug 1055658, i noticed the fix is in -proposed and it is verified, when will it land in -updates? thanks
[17:24] <seb128> who is the right person to talk to about qemu-linaro and getting qemu-kvm-spice built on i386?
[17:24] <seb128> hallyn, slangasek, ...:  ^ ? ;-)
[17:35] <stgraber> seb128: done
[17:38] <seb128> stgraber, thanks
[17:40] <seb128> stgraber, can you set https://code.launchpad.net/~sometimesfood/ubuntu/precise/libvdpau/libvdpau.fix-967091/+merge/130999 as merged?
[17:41] <stgraber> sure, done
[17:42] <vibhav> Arges:yes, once the fix is verified, your package will land in - updates
[17:43] <seb128> stgraber, thanks
[17:44] <cjwatson> arges: It's waiting for bug 1027987 also to be verified
[17:44] <seb128> doko, did you ever forward http://launchpadlibrarian.net/78456781/gcc-h8300-hms_1%3A3.4.6-6_1%3A3.4.6-6ubuntu1.diff.gz to debian? I don't find it in the BTS
[17:49] <micahg> vibhav: there's a 7 day bake time as well for most packages still
[17:50] <vibhav> michag: bake time for verified packages, right?
[17:50] <micahg> vibhav: no, total
[17:51] <vibhav> Ah
[17:51] <vibhav> arges: ^^^^
[17:52] <arges> vibhav, cjohnston thanks
[17:52] <arges> cjwatson i mean
[17:54] <slangasek> seb128: hallyn :)
[17:54] <seb128> slangasek, thanks ;-)
[18:00] <seb128> ScottK, barry: is https://code.launchpad.net/~mitya57/ubuntu/raring/python-defaults/resync/+merge/131193 still on your review list? it's in the sponsoring queue for a while...
[18:03] <seb128> stgraber, can you set https://code.launchpad.net/~bjaanes/ubuntu/quantal/lybniz/invalid-function-fix/+merge/131254 to "work in progress" (or "rejected"), it needs fixes and it's targetting the wrong seie
[18:04] <stgraber> seb128: done
[18:04] <seb128> stgraber, thanks
[18:57] <jtaylor> are packages with adt tests automatically added to jenkins.qa?
[18:59] <Tm_T> bug #1
[18:59] <Tm_T> temporary solution ^
[19:00] <cjwatson> huh?
[19:01] <hallyn> seb128: AIUI spice server can't build on 32-bit, right?
[19:03] <hallyn> arges: if you can verify that other bug, that'd be awesome.  I couldn't reproduce the origianl bug in a VM, haven't had a chance to try on real hardwrae
[19:03] <hallyn> (the other bug being 1027987)
[19:33] <arges> hallyn, ok i'll give it a shot if i have some time
[19:34] <barry> seb128: sorry, i will look at that again
[19:34] <barry> xnox: erc in emacs24 seems pretty responsive so far
[19:48] <seb128> barry, hey, no worry, thanks
[19:49] <seb128> hallyn, the gnome-boxes maintainer (who works for redhat) told me before quantal that recent spice is supposed to work on i386
[19:49] <seb128> hallyn, other distros (including debian) seem to manage that fine, not sure what is special about our linaro version
[19:56] <seb128> hallyn, http://git.qemu.org/?p=qemu.git;a=commit;h=a13ccc991a852cf12f2c05f537c40ce239ae464f
[19:56] <seb128> "This fixes running "-vga qxl -spice" with 32 bit compiled qemu-system-i386."
[19:56] <seb128> hallyn, that's pointed from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640139 which states "0.10 version of spice-server actually fixed 32bit issues too."
[19:59] <hallyn> seb128: excellent.
[20:00] <seb128> hallyn, confirmed on http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg04953.html it seems
[20:01] <seb128> hallyn, so, how do we move forward on enabling spice on 32bits in raring? ;-)
[20:01] <seb128> hallyn, I can help testing if needed (in fact I would like to be able to try gnome-boxes which depends on it which is why I'm asking about it)
[20:08] <hallyn> seb128: not sure, i'll take a look at the packaging after i finish lunch and testing this  libvirt bit.
[20:08] <hallyn> assume its one change in debian/control
[20:10] <seb128> hallyn, thanks, let me know how it goes or if I can help on something
[20:16] <GunnarHj> xnox, stgraber, cjwatson: I made a couple of attempts to enter a live session in order to start ubiquity from there without the webcam, but I never made it into the live session. One time the desktop just froze, and two times I ended up on the greeter (without knowing any username/password combination). So the current ISOs seem not to be very healthy. Gave up. :(
[20:22] <darkxst> Sarvatt, are you able to merge this? https://code.launchpad.net/~darkxst/ppa-purge/multiarch-lp892886
[20:50] <stokachu> xnonx, apw: would either of you have time to sru bug 932860
[20:55] <stokachu> also need to have bug 1077095 sru'd
[21:47] <hallyn> seb128: fwiw i've pushed a test pkg to ppa:serge-hallyn/virt (qemu-linaro), but it may be sitting waiting to build for awhile...  but it *should* build 32-bit.  hopefully the upstream fix really was a fix :)
[21:48] <israeldahl_> Hi, I need some assistance in uploading  a new version of a program that is already in USC.  How can I do this without Debian having a new upstream package (there maintainer is non-existant)
[21:49] <seb128> hallyn, thanks
[21:52] <israeldahl_> Does anyone know if this is even possible?
[21:57] <israeldahl_> Really?  Doesn't someone know?
[21:59] <seb128> israeldahl_, you can do the update, add it to launchpad for review and subscribe ubuntu-sponsors
[22:01] <israeldahl_> Sorry... how do I do it?   I have the source, I made a personal bzr branch.  Is there a specific webpage with this info?
[22:06] <israeldahl_> Ok, a different question then, how do I make the software-center recognize a program in a certain category?  Is it the menu file or the desktop file?
[22:08] <israeldahl_> Is anyone out there?
[22:09] <seb128> israeldahl_, http://developer.ubuntu.com/packaging/html/udd-sponsorship.html
[22:10] <seb128> israeldahl_, the desktop categories are used for classification
[22:10] <israeldahl_> is that for the software center as well seb128?
[22:13] <israeldahl_> Ok, I have branched the program and the desktop file is in the source.... why then does the software-center not see it?  Does it not install correctly?
[22:14] <seb128> israeldahl_, not sure how s-c deal with that
[22:14] <seb128> try asking on #software-center
[22:14] <israeldahl_> nobody seems to know this.  is there a forum somewhere that someone might know something like this?
[22:15] <israeldahl_> I tried the ubuntu-app-devel earlier
[22:23] <israeldahl_> Anyone know how software center  decides how to categorize programs?
[22:27] <israeldahl_> Is there a key word to get attention?  Anybody have any idea how Software Center knows how to place a program into the correct catergory i.e. ardour --> sound & video
[22:28] <hallyn> hm, ppa build fails with "Python not found. Use --python=/path/to/python"
[22:28] <hallyn> that's probably not good
[22:30] <SpamapS> israeldahl_: this is not a support channel. #ubuntu would be better. That said, the packager chooses a "Section" for each package. That particular one is in the 'sound' section.
[22:31] <infinity> bdrung: I'd question the sponsorship of all those libreoffice uploads for #585910
[22:31] <bdrung> infinity: why?
[22:32] <infinity> bdrung: Given the ridiculous size of libreoffice updates, it might have been better to work with Sweetshark to get those incorporated in larger updates.
[22:32] <israeldahl_> Ok, fair enough.  I am working to get the latest version of lmms 0.4.13 into the repos, and need to make sure the bugs are all out.  this seemed to be the place to ask questions
[22:32] <bdrung> infinity: the SRUs are still unapproved.
[22:33] <bdrung> Sweetshark: ^
[22:33] <infinity> bdrung: A bit late now for raring, but I think I'll reject the SRU ones and ask you nicely (this is me asking nicely) to work with him on getting the fix in a larger SRU.
[22:33] <bdrung> infinity: can you state that in the bug report, please?
[22:34] <bdrung> infinity: the big size of libreoffice is not an issue for raring.
[22:34] <arges> hallyn, tried to reproduce bug 1027987 on bare metal. I defined a volume group for libvirt, then restarted libvirt-bin and did no noticed any delay with the older package. am I missing some steps?
[22:34] <infinity> bdrung: No, for raring, it's just buildd time.
[22:34] <hallyn> arges: no, i have a feeling an underlying bug in kernel or udev got fixed in the meantime
[22:35] <hallyn> so then the question is, do we drop that part of the debdiff, or do we simply say it isn't regressing anything and keep it in?
[22:37] <arges> hallyn, in the debian bug they used virt-manager.. not sure if that makes a difference
[22:38] <infinity> bdrung: Bug updated, SRUs rejected.
[22:38] <hallyn> arges: yes!  that rings a bell!
[22:38] <infinity> bdrung: As you were happy enough to sponsor it in the first place, can I count on you to chase up Bjoern to make sure it doesn't get missed?
[22:39] <bdrung> infinity: i'll try
[22:39] <infinity> arges: Thanks for verifying those eglibc fixes, BTW.  You rock.
[22:40] <arges> infinity, np thanks for getting that patch done
[22:41] <xnox> bug 1
[22:47] <bdrung> Sweetshark: what are your SRU plans for precise and quantal? will you make sure that the fix for bug #585910 (in upstream release 3.6.4) will be in the next SRUs?
[22:48] <bdrung> infinity: vlc 2.0.4 is stuck in the SRU queue for precise. can you have a look at it?
[22:50] <stgraber> micahg: regarding the lxc backport, someone told me that it should be fine as long as the package I depend on from backport didn't exist in the release pocket, which is the case here
[22:50] <infinity> bdrung: I can in a bit.  I'm arguing with glibc right now.
[22:51] <ScottK> xnox: It depends on how you define the market. That one may actually be fixed now.
[22:51] <bdrung> infinity: maybe this upload needs to go -security too (see Debian bug 692130)
[22:52] <infinity> mdeslaur: ^
[22:53] <infinity> bdrung: As a general rule, if you want it in security, you should talk to the security team and have it done through their PPA.
[22:53] <infinity> bdrung: Assuming the upload only has the security fix.
[22:54] <bdrung> infinity: it's a new upstream release with bug fixes including a security fix.
[22:54] <infinity> bdrung: Oh, yeah.  That's more problematic.
[22:54] <mdeslaur> does it have a microrelease exception?
[22:54] <xnox> ScottK: our regular bot was away from keyboard on vacation, I was checking if the replacement showed up for work or not ;-)
[22:55] <mdeslaur> bdrung: is there a bug open for that upload?
[22:55] <bdrung> vlc has a preliminary microrelease exception
[22:56] <bdrung> mdeslaur: yes, but no open security bug
[22:56] <bdrung> lp 970447 for example
[22:58] <mdeslaur> bdrung: since it contains a security fix, we need to do it through the security pocket.
[22:58] <mdeslaur> bdrung: is there a tracking bug for the SRU?
[22:59] <bdrung> mdeslaur: lp 970447 (the bug with the highest priority)
[22:59] <infinity> bdrung / mdeslaur: If I reject this from precise-proposed, will you two sort out what needs to be done to get it in security instead?
[22:59] <infinity> (Which will, at least, require amending the changelog to include the security bug) :P
[23:00] <mdeslaur> infinity: yes
[23:01] <infinity> Danke.
[23:01] <mdeslaur> bdrung: could you put it somewhere I can grab? is it in a ppa or somewhere?
[23:02] <bdrung> mdeslaur: i attached the debdiff to the bug. the changelog entry needs an adjustment.
[23:02] <bdrung> mdeslaur: do you prefer a debdiff for the debian/ part or a .debian.tar.gz file or a full source package?
[23:02] <infinity> bdrung: Just so you don't think we're screwing you around with unnecesary faff here, rest assured there's rhyme and reason in this. :)
[23:03] <infinity> bdrung: Notably that we builds in -proposed build against -updates, while -security is meant to be self-contained, so I can't copy the SRU to security without a massive rdep audit.
[23:03] <bdrung> infinity: no problem. when i uploaded vlc to -proposed, i wasn't aware a security issue
[23:03] <infinity> bdrung: Much simpler to just work with the security team, since their PPA has -updates turned off.
[23:03] <mdeslaur> bdrung: I'm not quite sure what that debdiff is against
[23:03] <infinity> mdeslaur: I can just give you his package from the queue.
[23:03] <mdeslaur> bdrung: is it based on the quantal package?
[23:04] <mdeslaur> infinity: please
[23:04] <mdeslaur> gotta run...
[23:04] <infinity> mdeslaur: It'll be in chinstrap:~adconrad/vlc/ shortly.
[23:04] <bdrung> mdeslaur: grab the precise-security package, grab the 2.0.4 source, copy the debian/ directory and apply the patch
[23:05] <mdeslaur> bdrung: I'll create a tracking bug, and I'll upload it tomorrow morning to build in the security PPA
[23:05] <mdeslaur> bdrung: thanks
[23:05] <mdeslaur> infinity: thanks
[23:05] <bdrung> mdeslaur: or easier: grab it from the vlc debian git repo (precise branch)
[23:06] <cjwatson> sigh - well, I guess I predicted ending up as TIL for half the archive when I did that armel rebuild
[23:06] <infinity> bdrung: I've just given him your source package from -proposed, that should suffice.
[23:06]  * cjwatson works his way through a ton of merges
[23:06] <infinity> mdeslaur: It's there now.
[23:11] <bdrung> mdeslaur: the faster way to receive the source: git clone git://git.debian.org/git/pkg-multimedia/vlc.git -b precise