[00:37] * xnox likes Voyager 12.10 - we should totally start calling ubuntu release after the battleships from star trek [00:50] Defiant 13.04! [00:51] jelmer: hmmmm, do you have plymouth running? [00:52] slangasek: I had it installed, but I don't think it was running yet [00:53] jelmer: hmmmm, better questions; do you expect any cryptsetup prompts for non-root filesystems, and if so did you see them? [00:55] 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] Shouldn't that be the case with plymouth? [00:56] you got a cryptsetup prompt for a filesystem *other* than the root filesystem? [00:56] jelmer: plymouth in debian default to the "text" plugin, instead of fancy graphics, solar patters and promt boxes. [00:56] (two different prompting methods, initramfs vs. not) [00:56] slangasek: Sorry, I have a cryptsetup prompt for lvm [00:56] jelmer: is your root fs on the vg in question? [00:56] That LVM contains all my partitions, including the one with / [00:56] righto [00:56] Sorry for being unclear. [00:57] jelmer: workaround: mv /etc/init/cryptdisks-early.conf{,.bak} [00:57] slangasek: thanks, I'll give that a try and followup [00:57] I think I reported this bug to dupondje once before [00:57] possibly only on IRC [00:58] 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] hallyn, i have not used hugeadm [01:56] jtaylor: hi, are you on valgrind-devel? [02:19] smoser: ok, thanks. i may blog to get opinions on the best way to do waht we want... === fisted_ is now known as fisted === chilicuil_away is now known as chilicuil === robru is now known as robru|packing [02:56] Sweetshark: You around? [02:57] 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] tjaalton: Your xorg-server SRU to quantal leaves something to be desired. :P [03:14] 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] tjaalton: I'm going to reject all three(!) uploads for now, you can find them in the rejected queue, if you need the source. === cpg is now known as cpg|away [04:42] Good morning [05:31] infinity: ah, i thought it had to be called 6.2 [05:32] 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] (it failed its autopkgtests with new pygobject, I'll propose a branch) === rsalveti_ is now known as rsalveti === Ursinha_ is now known as Ursinha === Quintasan_ is now known as Quintasan [06:07] cjwatson, xnox: ubiquity fix sent to https://code.launchpad.net/~pitti/ubiquity/pygobject-fixes/+merge/136327 [06:07] I get two test failures (independent from pygobject and the branch), I mentioned those in the MP [06:10] tjaalton: That would be true if the previous one had ever been accepted. === cpg|away is now known as cpg [06:12] infinity: darn, eglibc autopkgtest failed again, with a test failure [06:14] infinity: right.. I've uploaded 6.1 now, with a fixed changelog [06:15] apparently tst-eintr1 and tst-mqueue5 failed and are not exfail [06:15] migth be VM related? [06:16] pitti: May well be, since they work on the buildds. [06:16] pitti: A lot of those tests are pretty touchy about kernel/hardware/etc. [06:17] 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] (NB that's only the tail of the log; the full log is 57 MB) [06:18] pitti: No, the progressions don't cause a failure. [06:18] The regressions, however, are: [06:18] tst-cancel4.out, Error 1 [06:18] tst-cancel5.out, Error 1 [06:18] tst-cancelx4.out, Error 1 [06:18] tst-cancelx5.out, Error 1 [06:19] tst-cpuclock2.out, Error 1 [06:19] tst-cputimer1.out, Error 1 [06:19] tst-key1.out, Error 1 [06:19] tst-key4.out, Error 1 [06:19] And almost certainly due to the VM. :/ [06:19] Or maybe the raring kernel sucks. [06:19] I just rebooted into it today, I'll have to test. [06:20] *** timer thr2 invoked too soon: 2.903523202 instead of expected 2.903549566 [06:20] that's darn close, though [06:21] 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] If I can't reproduce on a raring kernel, I'm at a bit of a loss, mind you. [06:22] infinity: yeah, these might be due to testing in a VM then? [06:23] some jitter in timing tests is rather unavoidable there [06:23] Might be. We'll have to see. [06:23] I thought that PPA builds would work pretty much the same way? [06:23] Note that even a Panda can grind those tests out fine, though. :P [06:23] do we have eglibc PPA builds? [06:23] The only PPA builds I do are devirt. [06:24] ah, ok [06:31] pitti: Well, let me try that local build now/overnight and see how it ends. === chilicuil is now known as chilicuil_away === doko_ is now known as doko [07:50] pitti: Hrm. So, on a raring kernel on bare metal, I see the cputimer1 regression, but none of the other ones. [07:50] pitti: And adjusting expected failures to suit a VM builder seems wrong. [07:52] infinity: I guess we cannot conditionally exfail them? [07:52] infinity: how much less useful would the rebuild test be if we skip the tests? [07:52] i. e. is it mostly the "it builds" part that you are interested in, or also the tests? [07:52] It would still be useful to know that it builds. [07:53] 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] 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] 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] But maintaining the two sets would be annoying. [07:54] yeah [07:54] I rather thought about exfailing those 5 if DEB_BUILD_PROFILE==autopkgtest or so [07:55] but if it's a text file as opposed to something programmatic, that wouldn't work [07:59] 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] 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] pitti: Always failed, though, sounds like the sort of red that would just be ignored after a while. :/ [08:01] yeah, that wouldn't be very useful [08:01] pitti: Can you waste some cycles and retrigger the test a few times to at least see if the regressions are consistent? [08:02] sure [08:02] 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] infinity: we have two runs now (one for -proposed, one for release) [08:02] * pitti restarts the -proposed one [08:03] and two arches each [08:03] comparing [08:03] xnox: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1073649 [08:03] having this every 2 boots :( [08:03] really *** :P [08:03] good morning [08:03] 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] pitti: ^ [08:05] infinity: http://paste.ubuntu.com/1391100/ [08:06] infinity: autopkgtest doesn't do parsing of individual tests results, no [08:06] Okay, that's a reasonably consistent set of regressions. [08:06] just "exit code 0 and stderr == ''", and otherwise attaches the logs [08:06] Basically just the cancel* and key* tests, and sometimes cpuclock/timer. [08:07] Might need to do some digging to see why/how those first two sets are failing. [08:07] The clock/timer stuff, I'm not really concerned about. [08:07] backtrace5 might be i386 only [08:08] the clock/timer ones sound like jitter/race condition [08:08] backtrace5 is already XFAIl anyway. [08:08] infinity: oh, it doesn't say (ignored)? [08:08] If you look at the logs, right under the list you copy/pasted is the list of regressions. [08:08] infinity: anyway, the server that runs autopkgtest sometimes runs 8 VMs in parallel; that will often cause some jitter [08:08] (ignored) is the upstream testsuite ignoring, the next bit is us comparing against our own XFAIL list. [08:09] ah, and then the logs for each failed test [08:09] * infinity nods. [08:12] And, actually, I already have cpuclock2 ignored in a few profiles anyway, just not amd64. [08:12] So, I'd be comfy just adding that to every profile. [08:13] But, yeah. The cancel and key ones are disconcerting. [08:13] 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] And not reproducible on bare metal. [08:13] pitti: Yeah, something like that could work. Knowing why those tests fail first would be a requirement, though. [08:13] infinity: so if I were to throw current eglibc into a PPA, we should see the same errors/ [08:13] ? [08:14] pitti: Maybe? Except that the PPAs are hardy dom0 and domU, what's the autopkgtest rig? [08:14] uh [08:14] Obviously a raring domU, at any rate. [08:15] infinity: pretty standard kvm with standard client kernel, i. e. raring for the raring tests [08:15] no xen [08:15] Oh, it's KVM? [08:15] Ew. [08:15] Then no, I bet you won't see this in a PPA. :P [08:15] I can test on my Xen host, but I'm guessing it won't fail the same way at all. [08:17] 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] of course, if they represent an actual problem, our cloud instances would be affected by that [08:17] They're probably KVM-related, yeah. I'll need to dig a little bit to see for sure. [08:17] but so far these don't seem to be an actual problem [08:17] we are using raring VMs all over the place [08:17] 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] s/actual problem/obvious problem/ [08:18] (Except when something is hideously broken, but the tests that fail when something's hideously broken tend to always pass otherwise) [08:18] But, yeah, to be sure, I want to hunt down WTF those tests are testing. [08:18] They may well be exposing a KVM bug we want to fix. === bitshuffler_ is now known as bitshuffler === bitshuffler_ is now known as bitshuffler [09:28] @pilot in [09:28] * dholbach hugs xnox :) [09:29] dholbach: I am suspecting you have a script running..... ;-) did the topic change?! [09:29] no [09:29] and no [09:29] dholbach: ack and ?! [09:30] bug 1 [09:30] tm_T: do you have an idea why the bot did not pick up "@pilot in"? [09:31] dholbach: ubottu is gone atm [09:32] dholbach: the situation is under investigation [09:32] thanks a bunch tm_T [09:32] np [09:32] xnox, ^ ubottu is taking some well-deserved holidays :) [09:33] dholbach: we should invest in a marvin model. [09:34] xnox, reading "here I am, brain the size of a planet..." in my mornings might depress me too much :) [09:35] 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] hrw: sure, if it applies cleanly. [09:39] tyhicks: see ^ hrw [09:42] it does [09:44] hrw: I am patch piloting right now, and will upload this sometime today. Will that do? === Tm_T changed the topic of #ubuntu-devel to: pilot [09:46] grah, sorry === Tm_T changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox [09:47] there ya go [09:47] Heh, careful there ;-) [09:49] nigelb: I'm old and slow, now I need to be careful too?! (; [09:50] xnox: would be lovely [09:52] hrw: run import-bug-from-debian against it, assigned to myself and subscribed you for notifications =) [09:52] Tm_T: ;) [09:58] xnox: thanks [10:02] 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] 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] 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] 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] pitti: I'm beginning to think some of these could not be turned to be not configurable at all… [10:05] TBH I don't quite see the point of this chane [10:05] change [10:06] pitti: as I understand upstream: some stuff stays web-configurable, the rest is only config-file configurable. [10:06] yes, but upstream pretty much established the situation that every user will have a modified config file [10:07] 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] infinity: you mean I should merge in the patch for bug 585910? [10:07] I guess cupsd will fail if it sees settings which should now be in cups-files.conf, or ignore those [10:07] either breaks existing systems [10:07] well, it's an upstream massive change that, by magic, happens to fix that. [10:08] for new installs, yes === Sweetsha1k is now known as Sweetshark [10:09] pitti: what do you propose ? [10:09] the apparmor profile should actually take care of the worst stuff [10:09] OdyX: as I said; I think cupsd should temporarily drop privileges when accessing log files [10:10] pitti: I'm afraid I don't have the skills to implement that. [10:11] 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] ok [10:11] 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] 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 ... === mcclurmc_away is now known as mcclurmc === _jmp__ is now known as _jmp_ === _salem is now known as salem_ [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] use UNRELEASED? [11:29] Laney: I don't like that. I should be building the package that will be uploaded. [11:29] ++ [11:29] & testing. [11:30] also I once saw a package that was parsing the release line in the changelog instead of using dpkg-vendor.... [11:30] meh, the package builds fine and works fine, so no damage done. [11:31] by not using it you risk uploading a package you haven't built or tested at all ... [11:31] true. [11:32] pitti: I guess you want ubiquity to be uploaded such that pygobject can be unblocked? [11:32] xnox: it's not super-urgent, but would be nice in the next days [11:32] xnox: but I guess these two test failures need addressing first, or do they not happen for you? [11:33] pitti: already fixed =) together with pep8/pyflakes warnings from your changes [11:33] pitti: how do I setup jenkins to run tests on every commit for lp:ubiquity? [11:34] ubiquity/frontend/gtk_ui.py:471: redefinition of unused 'GLib' from line 52 [11:34] ah, sorry about that [11:34] xnox: thanks for pointing out, will run these next time [11:34] pitti: and are there other packages left to fix with new pygobject? [11:34] xnox: I fixed dbusmock, the rest succeeded [11:34] pitti: also pep8 in raring complains about "over-identation" [11:34] pitti: I'll upload then. [11:35] xnox: indeed, the s/GObject/GLib/ of course didn't adjust the continuation lines [11:36] 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] 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] pitti: ack. [11:37] xnox: no worries; I broke it, I fix it :) [11:37] xnox: oh, aptdaemon was another victim, but I fixed that yesterday [11:37] 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] pitti: rock star ;-) [11:43] pitti: there, sent more info to the bug. === Johnswing is now known as Jswing === mitya57_ is now known as mitya57 === cpg is now known as cpg|away [12:33] someone know how to tell modem-manager to not touch serial ports at all? [12:44] 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 === Pendulum_ is now known as Pendulum [12:54] mvo: poke, I posted a question on #debian-apt a few days ago, enver got an answer :P [12:54] s/env/nev/ [12:57] pitti: in raring, in sbuild/schroot "from gi.repository import Gtk" fails [12:58] xnox: any error message? [12:58] http://paste.ubuntu.com/1391594/ [12:58] xnox: needs xvfb-run? [12:59] this is nothing new, Gtk and the old pygtk have always needed a $DISPLAY [13:00] 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] or something change in the minimal install / chroot. [13:01] ./tests/run: os.execvp('xvfb-run', argv) [13:01] it seems to try at least [13:01] hmm... [13:02] ok, running python3 under xvfb-run does import Gtk just fine. [13:02] * xnox goes looking into ubiquity test-suite [13:02] xvfb-run python3 -c 'from gi.repository import Gtk' [13:02] does that work? [13:02] yeap. [13:02] (in schroot) [13:02] yes. === tkamppeter_ is now known as tkamppeter === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ [13:31] 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] mdeslaur: but doesn't use it the same auth mechanism as "lpadmin"? [13:31] mdeslaur: you can hardly disallow lpadmin and the command line tools [13:32] mdeslaur: I had actually assumed that the AA profile would prevent the worst of it, like reading /etc/shadow [13:32] hm, but I guess cupsd needs that [13:32] pitti: well, /etc/shadow is allowed by the apparmor profile, unfortunately :) [13:32] pitti: what do you mean disallow lpadmin? [13:32] mdeslaur: I thought the point was that lpadmin group users could change the conffile, and by that read files as root [13:33] mdeslaur: i. e. everyone who can read the auth cookie in /var/run/cups/certs/ [13:33] pitti: yes, but only via the web interface, as by default cupsd.conf is owned by root [13:33] pitti: they can change a whole bunch of configuration options in that file, including the default directories, etc. [13:33] ah, you can't set arbitrary options through lpadmin [13:34] ok, seems fine [13:35] 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] the upstream change is _way_ too intrusive as a security update, as you said earlier [13:35] 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] infinity, https://launchpadlibrarian.net/124204285/buildlog_ubuntu-raring-armhf.gcc-4.7_4.7.2-12ubuntu1_FAILEDTOBUILD.txt.gz [13:35] 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] mdeslaur: yeah; we don't even have a way of migrating the config files [13:36] pitti: yeah, that's going to be a pain for new versions :( [13:36] didrocks: It probably isn't a problem normally; I've scored it up for now [13:37] cjwatson: thanks [13:37] mdeslaur: disabling web-edit is probably the safest course of action for security upgrades indeed. [13:37] jonas had a patch for that on the debian bug. [13:38] OdyX: yeah, that's what I plan on doing...ie: http://paste.ubuntu.com/1391676/ [13:38] 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] OdyX: ah, I am going to hide the option completely [13:39] 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] OdyX: sure, let me test it properly first though === mitya57 is now known as mitya57_ [13:40] mdeslaur: cool, thanks. [13:48] 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] which really confuses the package importer [13:49] SpamapS: php5/experimental looks like it's a broken upload [13:50] SpamapS: it's native where it shouldn't (at all) [13:50] Format: 1.0 [13:50] even then: see the .changes file: php5_5.4.8-1.tar.gz [13:51] * OdyX reports a bug. [13:52] OdyX: thanks [13:52] thought for a second I was losing my mind [13:53] 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] SpamapS: making the maintainer aware can help that :) [14:00] 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] no bot? [14:01] bug title is " FTBFS with glibc-2.16 (due to outdated gnulib) " [14:04] 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] seb128: done [14:04] pitti, danke, same for https://code.launchpad.net/~wb-munzinger/ubuntu/precise/havp/fix-init-script/+merge/125949 ? [14:05] done [14:05] pitti, danke ;-) [14:05] de rien [14:05] pitti, reject https://code.launchpad.net/~bkerensa/ubuntu/quantal/kubuntu-docs/fix-for-1049278/+merge/125965 ? [14:05] pitti, sorry to bother you with those, hate launchpad acls... [14:05] * seb128 is cleaning a bit the sponsoring queue [14:05] seb128: pas de problem, just ask [14:05] seb128: it's great to clean the queue [14:05] 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] pitti, ;-) [14:09] 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] seb128: you can do WIP yourself [14:10] pitti, not on a stable serie no [14:10] pitti, I don't even have edit mode for the status on that one [14:11] like the small yellow pen icon [14:11] it's not displayed next to the status... [14:11] seb128: lequel, WIP où rej? [14:11] pitti, reject I guess [14:11] since that's the wrong vcs [14:11] done [14:11] danke [14:29] 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] tkamppeter: I didn't find. If you enable that patch, the tests fail and I couldn't understand why. [14:31] tkamppeter: see also https://www.cups.org/str.php?L4220 and https://launchpad.net/~odyx/+archive/printing/+packages results [14:32] tkamppeter: also, I'm testing the introduction of ucf to handle /etc/cups/cupsd.conf with the extensive upstream patch [14:43] mdeslaur, do we need to keep security-sponsors subscribed to https://bugs.launchpad.net/ubuntu/+source/request-tracker3.8/+bug/1004834 ? [14:43] seb128: no, thanks I removed it [14:43] mdeslaur, it's on the sponsoring queue but it doesn't seem there is a lot to be acted on [14:43] mdeslaur, thanks [14:44] seb128: no...in fact, I'll release them now [14:44] cool [14:45] seb128: thanks === fisted_ is now known as fisted [14:53] 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] yes, https://launchpad.net/ubuntu/quantal/+queue?queue_state=1 is quite long [14:53] https://launchpad.net/ubuntu/precise/+queue?queue_state=1 too === Todd__ is now known as Todd [14:55] ok [14:56] pulseaudio is not in that list though, so maybe something else went wrong? [14:57] 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] diwic: usually the SRU reviewers should leave a comment in the bug if they reject a package [14:58] diwic: which release did you upload it to? [14:58] 12.04 [14:58] diwic: on the +queue page you can look at the rejected queue and check if it's there [14:59] nope, not there either [15:03] hm, then it seems it wasn't actually uploaded? [15:04] or accidentially uploaded to a PPA [15:05] pitti, maybe I did something else wrong...I'll check in a while [15:07] 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] didrocks, mvo or should i jfdi? :) [15:08] 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] pitti, https://code.launchpad.net/~felix-lawrence/ubuntu/quantal/ubuntu-mono/fix-for-748861/+merge/129859 <- can you set to "merged"? [15:08] done [15:09] danke [15:09] Is anyone interested in the ubuntu development hangout (on air) at 16 UTC and talk about the projects you're working on? [15:09] (in 50m) [15:10] 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] ogra-cb, mvo: let me have a look [15:10] 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] didrocks: then i'll enable the py3 version of the library [15:11] ogra-cb: it was spout, it should be ok [15:11] sweet \o/ [15:11] mvo, hmm [15:11] mvo, ? [15:12] 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] ogra-cb: do you have a log of the error? [15:12] 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] mvo: :( ping me if i can help [15:13] seb128: sorry, the context is that "spout:spout.desktop" was incorrect but it should be good, just verified in my branch [15:13] mvo, http://paste.ubuntu.com/1391846/ [15:14] ogra-cb, mvo: the issue is /usr/share/app-install/desktop/gmpc:gmpc.desktop [15:14] "Name=Gnome Music Player Client [15:14] de música del GNOME [15:15] " [15:15] 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] ogra-cb, mvo: that's invalid [15:15] aha [15:15] new issue, same symptoms then [15:15] fun [15:15] we really need an autopkgtest on app-install-data-ubuntu [15:15] which checks the included .desktops validity through the pyxdg parser on build [15:16] ++ [15:16] 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] " 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] seb128: aha, fun :/ [15:16] 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] seb128: I can create a verification step during the extraction that deletes the ones that are broken [15:17] seb128: the depends thing is merged, thanks :) [15:17] mvo, oh, great, danke [15:17] mvo, verification step sounds like manual work, we should just have an autopkgtest for it ;-) [15:18] mvo, want to do the upload if you have a checkout ready? [15:18] seb128: as part of the automatic update :) not manal, no [15:18] seb128: sure, I can do that [15:18] mvo, thanks [15:18] seb128: a good excuse to stop looking at this thread bug that makes me really unhappy [15:18] mvo, gmpc.desktop Name's being on 2 lines is the only issue [15:19] mvo, ogra-cb: I checked, once that fixed xapian is happy again [15:19] * ogra-cb hugs seb128 [15:19] thanks !! [15:19] * seb128 hugs ogra-cb back [15:22] @pilot-in [15:23] @pilot in [15:24] sconklin: issue to enter the cockpit? :) [15:24] sconklin, I think the bot is on holidays on something [15:24] dholbach, ^ [15:25] whetever. I don't need a bot in order to get my work done anyway [15:25] sconklin, didrocks, seb128: yes, tm_T said that ubottu is gone and it's under investigation [15:25] sabdfl: https://overbenny.wordpress.com/2012/11/27/code-name-for-ubuntu-18-04-lts/ [15:25] does "debuild -S -sa" also need the build-depends to be installed? [15:25] vibhav: Yes. [15:26] jpds: any way to skip that? [15:26] vibhav: Well, you might need things like cdbs installed. [15:26] I don't think it does, but it does run the clean target [15:26] yeah, you don't need build-depends to build the source [15:26] so whatever you need to execute that, unless you skip it (with -nc) [15:26] heh [15:27] which risks having a dirty source package, so check the diff [15:27] for like 70% of the packages [15:27] Laney: yes, that was the argument I was talking about [15:27] the other 30 do evil stuff in the clean target [15:27] yep [15:28]