[07:34] <doko_> pitti, jibel: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-python3.4/7/ARCH=amd64,label=adt/  could you have a look?
[08:00] <doko> infinity, could you have a look at https://launchpad.net/ubuntu/+source/ruby-patron/0.4.18-2 ? did you have to kill these two before as well?
[08:05] <infinity> doko: That doesn't ring any bells, and the previous version built everywhere. :/
[08:06] <infinity> doko: But, kill now, investigate later.  I need to go to bed.
[08:07] <infinity> doko: This is the first time it's built on ruby2.0, so I assume we've just found a bug.
[08:08] <jibel> doko, pitti restarted it and the testsuite is running
[08:13] <Mirv> the new qtdeclarative-opensource-src binary packages in utopic should be promoted to main like the old packages they replaced, since it's preventing some builds for rsalveti
[08:15] <Mirv> after that rsalveti would probably appreciate kicking rebuilds of https://launchpad.net/ubuntu/+source/qtpim-opensource-src/5.0~git20140203~e0c5eebe-0ubuntu3 and https://launchpad.net/ubuntu/+source/qtlocation-opensource-src/5.2.1-1ubuntu3
[08:15] <Laney> as a core-dev he's able to do that himself
[08:21] <Mirv> oh, ok (the rebuild part)
[08:24] <Laney> yup
[08:24] <Mirv> the list of new packages that are renames of the old ones that were made transitional: qml-model-qtqml-models2 qml-module-qt-labs-folderlistmodel qml-module-qt-labs-settings qml-module-qtquick-dialogs qml-module-qtquick-localstorage qml-module-qtquick-particles2 qml-module-qtquick-privatewidgets qml-module-qtquick-window2 qml-module-qtquick-xmllistmodel qml-module-qtquick2 qml-module-qttest
[08:26] <doko> dpkg-source: warning: -sn is not a valid option for Dpkg::Source::Package::V3::Quilt
[08:26] <doko> gpgv: Signature made Mon Apr 28 13:12:05 2014 UTC using RSA key ID 311D765A
[08:26] <doko> gpgv: Can't check signature: public key not found
[08:26] <doko> dpkg-source: warning: failed to verify signature on ./rtkit_0.11-1.dsc
[08:26] <doko> dpkg-source: info: extracting rtkit in rtkit-0.11
[08:26] <doko> dpkg-source: info: unpacking rtkit_0.11.orig.tar.xz
[08:26] <doko> dpkg-source: info: unpacking rtkit_0.11-1.debian.tar.gz
[08:26] <doko> dpkg-source: info: applying 01-no_ptrace_cap.patch
[08:26] <doko> patching file rtkit-daemon.c
[08:26] <doko> Hunk #1 FAILED at 1766.
[08:26] <doko> 1 out of 1 hunk FAILED
[08:26] <doko> dpkg-source: info: fuzz is not allowed when applying patches
[08:26] <doko> dpkg-source: info: if patch '01-no_ptrace_cap.patch' is correctly applied by quilt, use 'quilt refresh' to update it
[08:26] <doko> dpkg-source: info: restoring quilt backup files for 01-no_ptrace_cap.patch
[08:26] <doko> dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B .pc/01-no_ptrace_cap.patch/ --reject-file=- < rtkit-0.11/debian/patches/01-no_ptrace_cap.patch gave error exit status 1
[08:26] <doko> FAILED [dpkg-source died]
[08:26] <doko> how can this happen when the debian upload did patch that correctly?
[08:30] <Laney> that package has an ubuntu.series file
[08:33] <doko> ahh
[08:34] <doko> omg, whole lot of ruby modules wants to migrate to main
[09:08] <doko> banned
[09:26] <ogra_> infinity, so i talked to the heise author and he can obviously still reproduce the screensaver issue with his iso ... can that be ?
[09:27] <seb128> ogra_, what issue?
[09:27] <ogra_> seb128, hodling enter for 30sec
[09:27] <ogra_> seb128, http://www.heise.de/newsticker/meldung/Sperrbildschirm-bei-Ubuntu-14-04-einfach-zu-umgehen-2178733.html
[09:28] <seb128> did he download the iso before it was flagged official and got a wrong one?
[09:28] <ogra_> i'll ask him to check the md5 ... just want to be sure its supposed to be really gone
[09:28] <ogra_> (my system is obviously already up to date and i didnt use the iso anyway over here)
[09:29] <michagogo|cloud> ogra_: ask him to update his system?
[09:29] <michagogo|cloud> sudo apt-get update && sudo apt-get dist-upgrade
[09:29] <seb128> ogra_, we didn't have any unity update since release (there is one SRU in proposed)
[09:29] <ogra_> michagogo|cloud, thats not the point, his article claimed the release iso has the issue
[09:29] <seb128> ogra_, you can also ask for the unity package version (dpkg -l | grep unity)
[09:29] <ogra_> will do
[09:29] <seb128> ogra_, we didn't have any unity update since release
[09:30] <seb128> so that doesn't make sense
[09:30] <ogra_> seb128, and the iso surely shouldnt have the issue, right ?
[09:30] <seb128> if it's fixed in the current version, it was fixed in release
[09:30] <ogra_> ok
[09:30] <seb128> no it shouldn't
[09:30] <seb128> and we tested the fix/verified it when it landed
[09:30] <seb128> there could be other issues though
[09:32] <ogra_> right
[09:49] <ogra_> seb128, seems he has the right iso and also unity 7.2.0+14.04.20140416-0ubuntu1 ... he uses nvidia drivers though
[09:51] <pitti> doko: run #8 finished, and failed due to su -c ... nobody; that's another fallout from last release's change that these accounts have a disabled shell
[09:51] <seb128> ogra_, can you ask what he does exactly and what happens?
[09:51] <pitti> doko: the usual fix is to call "su -s /bin/sh -c ..."
[09:51] <ogra_> will do
[09:52] <seb128> ogra_, ok, so I tested with the version which had the bug and with the fixed version
[09:52] <seb128> ogra_, sitting on enter for 45 seconds
[09:53] <ogra_> and you cant repro i guess
[09:53] <ogra_> (with the fixed)
[09:53] <seb128> ogra_, with the old version it would display "wrong password" and then the spinner would stop spinning and nothing would happen, then when you release the keypress unity would segfault
[09:53] <seb128> ogra_, with the new one, the spinner keeps spinning and it does a "wrong password" every few seconds
[09:53] <seb128> like if you kept trying to enter wrong passwords
[09:53] <seb128> no segfault
[10:04] <ogra_> seb128, hmm, with the iso he seems to see compiz crash and gets "respawn to fast" messages it seems
[10:04] <seb128> ogra_, can he submit the crash report/get a bt from apport?
[10:04] <ogra_> (which might not be the same segfault)
[10:05] <ogra_> i will ask
[10:05] <ogra_> not sure he is that technical :)
[10:26] <doko> pitti, you mean fallout caused by autopkgtest?
[10:27] <pitti> doko: no, by whichever package sets up the default user base (user-setup?), it caused massive pain
[10:28] <cjwatson> pitti: base-passwd
[10:28] <cjwatson> Sorry for the pain but I think it was overdue
[10:29] <pitti> no, not user-setpu
[10:29] <pitti> ah, base-passwd
[10:29] <pitti> I think we fixed most fallout by now, but it seems python3.4's test still needs to be fixed
[11:09] <cjwatson> doko: s/trusty/utopic/?
[11:09] <doko> shit ... yeah
[11:17] <ogra_> cjwatson, oh, after you fixed the "touch i386 accidentially gets promoted all the time" issue on cdimage i assume i have to run mark-current for i386 too when manually promoting, right ?
[11:17] <cjwatson> I believe so, yes
[11:17] <ogra_> thanks
[11:17] <ogra_> just wanted to make sure
[11:48] <xnox> doko: just install devscripts from utopic... it's fixed now.
[14:18] <doko> pitti, jibel: please could you give back the rails-3.2 autopkg test. should have now all dependencies available for ruby2.1
[14:18] <cjwatson> wg 25
[14:18] <cjwatson> sigh
[14:23] <rbasak> ^^ I didn't realise this was new. Should this have happened, or should it just be on ddebs instead?
[14:23] <rbasak> I also appear to have forgotten to run update-maintainer :-/
[14:25] <Laney> rbasak: If it's a -dbg package then it's the same as any other new binary as far as the archive is concerned
[14:25] <cjwatson> It's new, but it's also not a problem
[14:26] <Laney> ddebs.u.c should get a -dbgsym which is empty and Depends on the -dbg
[14:26] <rbasak> Right, but is -dbg the "right" way to do things?
[14:26] <cjwatson> *shrug*
[14:26] <rbasak> OK, I won't worry about it then :)
[14:26] <cjwatson> It's not worth diverging from Debian to remove it
[14:26] <rbasak> Thanks!
[14:26] <Laney> It's the only way Debian has, and we don't bother removing them
[14:30] <pitti> doko: will do later; there's the d-jenkins migration to LP teams happening, so it's shutdown
[14:30] <pitti> doko: thanks!
[15:44] <sil2100> Hi SRU team! In the UNAPPROVED queue there seems to be and qtorganizer5-eds SRU waiting since last week - is there anything wrong with it, should we take some action?
[16:06] <bdmurray> sil2100: for trusty? the queue is quite large so I'd be surprised if anyone has looked at it yet
[16:06] <bdmurray> slangasek: is upgrading from P w/ -lts- packages to Q supported?
[16:10] <sil2100> bdmurray: ok, thanks :)
[16:10] <sil2100> Just been worried it got forgotten or (even worse) it had some problems that we didn't notice
[16:42] <slangasek> bdmurray: upgrading to Q now, or in the past given that it's now EOL?  anyway, I'm pretty sure we said we wouldn't support upgrades from P w/ lts-raring- to Q, but I don't remember if we said we would support P/ w lts-quantal- to Q
[16:46] <bdmurray> slangasek: Q isn't EOL quite yet, infinity was talking about sending an announcement then waiting 4 weeks
[16:46] <bdmurray> slangasek: but okay, not supported
[16:48] <slangasek> has the announcement been sent?  It's supposed to be EOL now; has the security team agreed to supporting it an extra month?
[16:53] <mdeslaur> kill it kill it kill it
[17:25] <infinity> mdeslaur: I'll send the announce today (honest) and give it three weeks (which is what I gave raring), which will allow the last SRU kernel to land.
[17:25] <mdeslaur> infinity: ok, sounds good
[18:01] <slangasek> infinity, cjwatson, pitti: ddebs.u.c seems to be empty for trusty-proposed; is this a known issue?
[18:01] <slangasek> no ddebs for -updates seems problematic for errors retraceability
[18:02] <infinity> slangasek: s/proposed/updates/ you mean?
[18:02] <slangasek> infinity: yes, that
[18:02] <infinity> slangasek: And not known by me until just now...
[18:03] <infinity> Given how pitti does refcounting, some of them might be long gone by now, too. :/
[18:03] <slangasek> fwiw I only noticed because I had dpkg-dbgsym installed locally, and update-manager was throwing me to the 'partial upgrade' screen
[18:07] <infinity> slangasek: Oh, feh.  It's right there in the crontab.
[18:09] <slangasek> next year, in the ho^W^W soyuz
[18:09] <infinity> slangasek: Should fix itself in a few minutes, though no idea how many will have been irrecoverably lost. :(
[18:09] <infinity> Probably a week or more of SRUs.
[18:10] <slangasek> well, no worse crying over spilled ddebs
[18:10] <infinity> I guess the upshot is that most of what was SRUed in the first week or two are packages we tend to SRU a lot. :P
[18:10] <slangasek> just one more reason to get ddebs into soyuz
[18:10] <slangasek> s/worse/use/ (?)
[18:11] <infinity> Total brain/finger disconnect?
[18:52] <infinity> slangasek: Alright, ddebs should exist for -updates.
[18:52] <slangasek> huzzah
[18:52] <infinity> slangasek: No idea how many were lost, but dpkg is there, at least. :P
[18:54] <infinity> Let's see if I can save a few more.
[19:30] <apw> infinity, i thinik when the kernel started to go missing, he upped the retension a lot, to like 30 days or soemthing
[19:31] <apw> (for ddebs which are unclaimed)
[20:27] <robru> cjwatson, hiya, we have another unity8 release that needs to be version bumped to get through -proposed. thanks!
[20:38] <infinity> robru: On it.
[20:39] <robru> infinity, thanks!
[20:53] <xnox> are daily _trusty_ images going to be build? useful to use those during sru verification
[21:08] <infinity> xnox: They will be, yes.
[22:00] <cjwatson> pitti: Do autopkgtest jobs need a kick after the Jenkins migration?
[22:01] <cjwatson> I notice that software-properties (at least) hasn't run
[22:01] <cjwatson> Maybe that's what jibel just mentioned on some internal lists ...
[23:41] <robru> infinity, cjwatson : I'm a little confused about unity8, excuses says the jenkins is running, but jenkins seems to indicate that the tests passed? is there some kind of hiccup there?
[23:42] <infinity> robru: The jenkins instance was heavily mangled today, I suspect there's some fallout that jibel might need to look at.
[23:43] <robru> infinity, ok, thanks