[07:34] 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? === doko_ is now known as doko [08:00] 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] doko: That doesn't ring any bells, and the previous version built everywhere. :/ [08:06] doko: But, kill now, investigate later. I need to go to bed. [08:07] doko: This is the first time it's built on ruby2.0, so I assume we've just found a bug. [08:08] doko, pitti restarted it and the testsuite is running [08:13] 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] 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] as a core-dev he's able to do that himself [08:21] oh, ok (the rebuild part) [08:24] yup [08:24] 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] dpkg-source: warning: -sn is not a valid option for Dpkg::Source::Package::V3::Quilt [08:26] gpgv: Signature made Mon Apr 28 13:12:05 2014 UTC using RSA key ID 311D765A [08:26] gpgv: Can't check signature: public key not found [08:26] dpkg-source: warning: failed to verify signature on ./rtkit_0.11-1.dsc [08:26] dpkg-source: info: extracting rtkit in rtkit-0.11 [08:26] dpkg-source: info: unpacking rtkit_0.11.orig.tar.xz [08:26] dpkg-source: info: unpacking rtkit_0.11-1.debian.tar.gz [08:26] dpkg-source: info: applying 01-no_ptrace_cap.patch [08:26] patching file rtkit-daemon.c [08:26] Hunk #1 FAILED at 1766. [08:26] 1 out of 1 hunk FAILED [08:26] dpkg-source: info: fuzz is not allowed when applying patches [08:26] dpkg-source: info: if patch '01-no_ptrace_cap.patch' is correctly applied by quilt, use 'quilt refresh' to update it [08:26] dpkg-source: info: restoring quilt backup files for 01-no_ptrace_cap.patch [08:26] 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] FAILED [dpkg-source died] [08:26] how can this happen when the debian upload did patch that correctly? [08:30] that package has an ubuntu.series file [08:33] ahh [08:34] omg, whole lot of ruby modules wants to migrate to main [09:08] banned [09:26] 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] ogra_, what issue? [09:27] seb128, hodling enter for 30sec [09:27] seb128, http://www.heise.de/newsticker/meldung/Sperrbildschirm-bei-Ubuntu-14-04-einfach-zu-umgehen-2178733.html [09:28] did he download the iso before it was flagged official and got a wrong one? [09:28] i'll ask him to check the md5 ... just want to be sure its supposed to be really gone [09:28] (my system is obviously already up to date and i didnt use the iso anyway over here) [09:29] ogra_: ask him to update his system? [09:29] sudo apt-get update && sudo apt-get dist-upgrade [09:29] ogra_, we didn't have any unity update since release (there is one SRU in proposed) [09:29] michagogo|cloud, thats not the point, his article claimed the release iso has the issue [09:29] ogra_, you can also ask for the unity package version (dpkg -l | grep unity) [09:29] will do [09:29] ogra_, we didn't have any unity update since release [09:30] so that doesn't make sense [09:30] seb128, and the iso surely shouldnt have the issue, right ? [09:30] if it's fixed in the current version, it was fixed in release [09:30] ok [09:30] no it shouldn't [09:30] and we tested the fix/verified it when it landed [09:30] there could be other issues though [09:32] right [09:49] seb128, seems he has the right iso and also unity 7.2.0+14.04.20140416-0ubuntu1 ... he uses nvidia drivers though [09:51] 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] ogra_, can you ask what he does exactly and what happens? [09:51] doko: the usual fix is to call "su -s /bin/sh -c ..." [09:51] will do [09:52] ogra_, ok, so I tested with the version which had the bug and with the fixed version [09:52] ogra_, sitting on enter for 45 seconds [09:53] and you cant repro i guess [09:53] (with the fixed) [09:53] 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] ogra_, with the new one, the spinner keeps spinning and it does a "wrong password" every few seconds [09:53] like if you kept trying to enter wrong passwords [09:53] no segfault [10:04] seb128, hmm, with the iso he seems to see compiz crash and gets "respawn to fast" messages it seems [10:04] ogra_, can he submit the crash report/get a bt from apport? [10:04] (which might not be the same segfault) [10:05] i will ask [10:05] not sure he is that technical :) [10:26] pitti, you mean fallout caused by autopkgtest? [10:27] doko: no, by whichever package sets up the default user base (user-setup?), it caused massive pain [10:28] pitti: base-passwd [10:28] Sorry for the pain but I think it was overdue [10:29] no, not user-setpu [10:29] ah, base-passwd [10:29] I think we fixed most fallout by now, but it seems python3.4's test still needs to be fixed [11:09] doko: s/trusty/utopic/? [11:09] shit ... yeah [11:17] 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] I believe so, yes [11:17] thanks [11:17] just wanted to make sure [11:48] doko: just install devscripts from utopic... it's fixed now. === pete-woods1 is now known as pete-woods-lunch [14:18] pitti, jibel: please could you give back the rails-3.2 autopkg test. should have now all dependencies available for ruby2.1 [14:18] wg 25 [14:18] sigh [14:23] ^^ I didn't realise this was new. Should this have happened, or should it just be on ddebs instead? [14:23] I also appear to have forgotten to run update-maintainer :-/ [14:25] 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] It's new, but it's also not a problem [14:26] ddebs.u.c should get a -dbgsym which is empty and Depends on the -dbg [14:26] Right, but is -dbg the "right" way to do things? [14:26] *shrug* [14:26] OK, I won't worry about it then :) [14:26] It's not worth diverging from Debian to remove it [14:26] Thanks! [14:26] It's the only way Debian has, and we don't bother removing them [14:30] doko: will do later; there's the d-jenkins migration to LP teams happening, so it's shutdown [14:30] doko: thanks! === pete-woods-lunch is now known as pete-woods [15:44] 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] sil2100: for trusty? the queue is quite large so I'd be surprised if anyone has looked at it yet [16:06] slangasek: is upgrading from P w/ -lts- packages to Q supported? [16:10] bdmurray: ok, thanks :) [16:10] Just been worried it got forgotten or (even worse) it had some problems that we didn't notice [16:42] 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] slangasek: Q isn't EOL quite yet, infinity was talking about sending an announcement then waiting 4 weeks [16:46] slangasek: but okay, not supported [16:48] 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] kill it kill it kill it === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [17:25] 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] infinity: ok, sounds good [18:01] infinity, cjwatson, pitti: ddebs.u.c seems to be empty for trusty-proposed; is this a known issue? [18:01] no ddebs for -updates seems problematic for errors retraceability [18:02] slangasek: s/proposed/updates/ you mean? [18:02] infinity: yes, that [18:02] slangasek: And not known by me until just now... [18:03] Given how pitti does refcounting, some of them might be long gone by now, too. :/ [18:03] fwiw I only noticed because I had dpkg-dbgsym installed locally, and update-manager was throwing me to the 'partial upgrade' screen [18:07] slangasek: Oh, feh. It's right there in the crontab. [18:09] next year, in the ho^W^W soyuz [18:09] slangasek: Should fix itself in a few minutes, though no idea how many will have been irrecoverably lost. :( [18:09] Probably a week or more of SRUs. [18:10] well, no worse crying over spilled ddebs [18:10] 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] just one more reason to get ddebs into soyuz [18:10] s/worse/use/ (?) [18:11] Total brain/finger disconnect? [18:52] slangasek: Alright, ddebs should exist for -updates. [18:52] huzzah [18:52] slangasek: No idea how many were lost, but dpkg is there, at least. :P [18:54] Let's see if I can save a few more. [19:30] infinity, i thinik when the kernel started to go missing, he upped the retension a lot, to like 30 days or soemthing [19:31] (for ddebs which are unclaimed) [20:27] cjwatson, hiya, we have another unity8 release that needs to be version bumped to get through -proposed. thanks! [20:38] robru: On it. [20:39] infinity, thanks! [20:53] are daily _trusty_ images going to be build? useful to use those during sru verification === jhodapp is now known as jhodapp|afk [21:08] xnox: They will be, yes. [22:00] pitti: Do autopkgtest jobs need a kick after the Jenkins migration? [22:01] I notice that software-properties (at least) hasn't run [22:01] Maybe that's what jibel just mentioned on some internal lists ... [23:41] 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] robru: The jenkins instance was heavily mangled today, I suspect there's some fallout that jibel might need to look at. [23:43] infinity, ok, thanks