=== glebihan__ is now known as glebihan [00:23] Laney: https://code.launchpad.net/~bkerensa/ubuntu/raring/swauth/fix-for-1061020/+merge/133195 [00:23] Laney: you asked me to forward to Debian but the package does not exist in Debian [00:24] Laney: somehow the packages list is ~8 hours out of date on the transition-tracker. === emma is now known as em === cpg is now known as cpg|away === attente is now known as attente_zzz === cpg|away is now known as cpg [05:38] Good morning [07:42] thanks, TheMuso, i'll check [07:46] good morning === dpb_ is now known as Guest76575 === smb` is now known as smb === Tonio__ is now known as Tonio_aw === doko_ is now known as doko [08:46] good morning indeed [09:16] * seb128 looks at dholbach and opt-in for some extra friday sponsoring out of his normal shift [09:16] !pilot in [09:16] @pilot in === udevbot 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: seb128 [09:16] * dholbach hugs seb128 [09:17] * seb128 hugs dholbach back [09:17] I'll sponsor a few bits later on, got to finish 2 other things first :) [09:23] my kernel in raring is "obsolete" [09:23] 3.5.0-18-generic [09:24] 29 === henrix_ is now known as henrix [09:32] mightyiam: Yes, I'm processing the 3.7.0-0 one through the archive at the moment. No need to report it. [09:33] thanks, cjwatson [09:42] bkerensa: fair enough, comment in the MP to that effect then [09:42] xnox: uhh === mcclurmc_away is now known as mcclurmc [09:58] Laney: or maybe there is a mistake in my tracker. http://people.canonical.com/~ubuntu-archive/transitions/onlypy3oncd.html shows ndisgtk at 0.8.5-1 while if I generate the tracker locally it's at 0.8.5-1ubuntu1. [09:58] =( [09:58] I'll look in a second [09:58] just collecting the pieces from that libgcrypt11 thingy [09:59] =) [09:59] thanks [09:59] stokachu: !!! [10:16] -rw-r--r-- 1 ubuntu-archive ubuntu_archive 1140090 Nov 8 14:09 Packages.bz2 [10:16] xnox: suspicious eh [10:17] yeah.... [10:17] hm [10:17] cjwatson: I suppose you didn't intend to turn that off :-) [10:17] is the dpkg-diverts from libgtk-3-bin good enough as dumb example for dpkg-divert? :p [10:18] Laney: no - I'll lok [10:18] *look [10:18] ta [10:18] would JFDI but bzr [10:18] alternatively if I can just branch that and fix/push then I will [10:18] edit in place and commit [10:18] but [10:18] Laney: raring-proposed is up to date - I thought you'd stopped using raring in the transition tracker [10:19] it merges the two [10:19] because partial suite [10:19] oh, so you need to be triggered on a change to either, then? [10:19] well I suppose you could just sync release as well if proposed changes [10:20] you should only need to regenerate the tracker if proposed changes, right? [10:21] Laney: ok, should be fixed now [10:22] cheers [10:25] seb128: Where there API changes in 12.10 for messaging menu? I'm looking at Bug 1076362 and I'm really confused because it works for me fine with the Qt/KDE messaging indicator and literally nothing changed in Quassel between 12.04 and 12.10. [10:25] Launchpad bug 1076362 in quassel (Ubuntu) "Quassel messaging menu integration broken in Ubuntu 12.10" [Undecided,New] https://launchpad.net/bugs/1076362 [10:25] ScottK, yes, https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1040259 [10:25] Launchpad bug 1040259 in skype-wrapper "FFE: libmessaging-menu transitions for quantal" [High,In progress] [10:26] ScottK, there is a new lib,api in quantal [10:26] Sigh. [10:27] Thanks. [10:27] yw [10:27] I didn't know KDE has a messaging indicator compatible with the old api [10:27] sorry about that, we should probably have added that to the list of things to port or at list consider it [10:28] hum [10:28] who synced glew? [10:29] whoever did I hope there was a test rebuild of the unity stack with the new glew, we had glew updates breaking unity in the past [10:29] https://lists.ubuntu.com/archives/raring-changes/2012-November/000950.html [10:29] Laney, "Sorry, changesfile not available." [10:30] the From line says who did it [10:30] oh, there is the signed-by [10:30] does alessio do IRC? [10:30] quadrispro [10:30] not there [10:30] grumpf [10:31] cjwatson: is there a way hold manually proposed -> release pocket migration for this component? [10:31] hm, we don't yet have unity in autopkgtest; that ought to catch that? [10:32] pitti: well, we can't run autopilot in autopkgtest as discussed in the UDS session [10:32] pitti: because of need of bare metal [10:32] yeah [10:34] didrocks: I've blocked it for the time being [10:34] seb128: It's not just us as DBus menu is in upstream KDE, so it needs porting work upstream too and we're now too late for KDE 4.10. [10:35] cjwatson: thanks a lot. Let's try to sync with quadrispro when he's here (or sending an email if we can't catch him) [10:35] seb128: I'm not actually sure all the bits it touches. [10:36] (lp:~ubuntu-release/britney/hints-ubuntu - it just has a file for me at the moment, but the list of hinters is in britney.conf in lp:~ubuntu-release/britney/britney2-ubuntu) [10:36] sweet, that the conf is versionned :) [10:36] so please let me know if/when that can be unblocked [10:37] having that in bzr is probably overengineering but meh [10:37] didrocks, I emailed him and ubuntu-devel [10:38] seb128: thanks! [10:38] cjwatson: well, at least, we are sure to have a reason written in [10:39] yeah (I've just added a reference to this conversation) [10:39] I have no problem with anyone in ~ubuntu-release setting themselves up as a hinter [10:40] although I think any changes to lp:~ubuntu-release/britney/britney2-ubuntu still need to be deployed manually [10:40] you forced something in the other day - was that not through hints? [10:40] (I'm aware that the release team can do copies directly) [10:42] Laney: I forced eagle in using a hint [10:43] ah [10:43] I see it in history indeed [10:43] used to Debian ones where they use 'finished' [10:43] the release team can but shouldn't - better get britney to do it [10:43] yeah, their hints files aren't versioned, or weren't when I was last involved [10:43] given a VCS I see no point in leaving cruft in the file === henrix is now known as henrix_ [10:55] mvo: does https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-ubuntu-release-upgrader/lastFailedBuild/ARCH=i386,label=albali/artifact/results/dsc0t-nose-tests-stdout make any sense to you? [10:55] mvo: I see that the "äää" appears on stdout (or err), and the fp.read() doesn't seem to get it [11:00] pitti: let me check [11:04] pitti: I wonder if mabye "less" is not installed in the test env [11:04] plausible, let me check [11:04] pitti: I update the test depends [11:04] * pitti runs run-adt-test -l === _salem is now known as salem_ [11:07] mvo: hm, I do have it installed here; that's a standard prepare-testbed VM [11:08] * pitti runs tests in there [11:08] pitti: I can do a upload with it added, maybe the server version is a bit different [11:09] oh, the tests runs a while [11:10] yeah [11:13] hm, no Python 3.2 any more in raring :( [11:14] pitti: nope. please rebuild your chroot as well, as there are packages that try to compile themself againsts "--installed" [11:14] python versions. [11:14] oh, I did, it's a fresh VM from yesterday [11:15] but we have packages which don't work yet with 3.3, so its removal seems a bit premature [11:15] pitti: which packages? [11:15] for comparing/debugging I can install it from quantal, though [11:15] * xnox thought we ported everything..... [11:15] like python-docutils; there are certainly more, though, it's just the one I'm currently looking at [11:16] I thought doko & mitya managed to get python-ductils workings.... [11:17] the last build in raring was against 3.2 [11:17] xowow, thanks for the fstools, that was really fast [11:17] xnox, ^^^ [11:18] but oh well, I'll disable thre six failing test cases for now to fix the FTBFS; the other 1204 work, after all [11:18] * ogra_ wishes some archive admin would review the nexus kernel now so it can get out of NEW [11:18] and that's happening from current upstream svn trunk as well, so upstream should be on it [11:18] ogra_: and it's in the ppa. [11:18] xnox, well, its on archive.u.c and ports.u.c [11:21] ogra_: everywhere, where it matters =) [11:21] yeah [11:21] * ogra_ is just missing the kernel now to start playing with the first images [11:22] why was the last linux-nexus7 upload in the queue rejected, do you know? [11:22] I saw a reject/reupload cycle but no explanation [11:22] iirc there was an ftbfs with the tools package [11:22] jani only discovered after upload [11:22] janimo, ^^^ [11:23] cjwatson, FTBFS with raring gcc. I reuploaded with tools package build disabled as it was don efor linux-ac100 as suggested by infinity [11:25] ogra_, so for the firmware are we settled on a separate package that puts up a notice when installed? [11:25] janimo, apparently :/ [11:25] janimo, it needs to be preseedable though [11:25] is there a package I can look at that does something similar? [11:25] so we can suppress the notice on image builds [11:25] preseedable? [11:26] since there usb-creator will show it at image flash time [11:26] the notice in the package just needs to be there for people installing the package separately [11:28] ogra_: hmmm.... [11:28] ogra_: is the notice required, i thought we were meant to step that aside. [11:30] xnox, apparently it is :((( [11:30] ogra_: so are you driving the legal workitem from the spec then? [11:30] i'm not keen having it either [11:31] legal is done [11:31] victorp_, ^^^^ [11:31] we just need to display the same npotice that the shell script installer does nowadays [11:31] (same thing for the package) [11:32] ogra_: ... and the notice will be a text file inside the tarball? (tar.gz: boot.img rootfs.img notice.txt README) [11:32] ;-) [11:33] oh, sure, i could fish that out of the rootfs at build time [11:34] ogra_: that would be lovely, cause currently the website lists it on the hwe. So the notice needs to be accesible on cdimage as well. [11:34] ogra_: and within tarball should be sufficient. Or maybe along side the tarball as well for apache to pick up as README [11:34] i prefer inside if possible [11:35] * ogra_ doesnt like to touch make-web-indicies if avoidable :) [11:35] ack =) [11:35] mvo: I can reproduce the failure with less installed [11:35] the first builds will be without firmware anyway i guess [11:36] could somebody mark https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/kde-l10n-sl/precise-updates/+merge/133394 as merged? [11:36] it was uploaded: https://launchpad.net/ubuntu/+source/kde-l10n-sl/4:4.8.5-0ubuntu0.1 [11:36] mvo: "xvfb-run python3 tests/test_view.py" succeeds, though [11:37] cjwatson: should I still use syncSources() compared to syncSource()? I remember we discussed about it a year ago and you told me to use the first one [11:37] didrocks: Generally? Neither. What are you doing? [11:38] cjwatson: I'm written the latest script for the copy from the PS release ppa to -proposed [11:39] I have a list of package source name for a serie that are validated at this stage [11:40] I probably told you to use syncSources because it would either succeed or fail all at once rather than maybe copying some but not others [11:40] But I don't really think that's a concern with copies into -proposed [11:40] Besides, both syncSource and syncSources are (lightly?) deprecated because they're synchronous and often time out [11:40] I would recommend using copyPackage instead [11:41] (you'll need to use the devel API version) [11:41] cjwatson: copyPackage, not copyPackages? (like if one operation times out, maybe I'll push the validated stack partially) [11:42] ah, it's async [11:42] You *could* use copyPackages, but I wouldn't as that suppresses announcement mails [11:43] Timeouts are very unlikely with copyPackage [11:43] And the proposed-to-release process should protect against most partial-copy situations [11:43] So I wouldn't worry about that [11:44] cjwatson: makes sense, I'll follow your advice and test between ppas meanwhile. Thanks :) [11:45] as I'm seeing the "auto_approve" parameter, I think I can keep it to False, so that we don't bypass potential freezes [11:45] didrocks: You're acting with a developer hat on here rather than with an archive admin hat on, so you shouldn't use auto_approve [11:46] cjwatson: agreed, just checking that I understand the parameter corectly. [11:46] You do [11:46] mvo: I confirmed it's not TMPDIR and similar; something more involved [11:47] cjwatson: last thing (sorry to bother you), but I see that the relationship between source and binary packages is established here. However, if I try source.getPublishedBinaries(), I can get some tricky situation [11:47] cjwatson: like some binaries were published for amd64, but then the source becomes superseded, and the following call to source.getPublishedBinaries() won't give anything as it's only PUBLISHED or PENDING binary package state [11:48] and there is no parameter compared to ppa.getPublishedBinaries() to catch them [11:48] I wonder if I miss any obvious API to ensure I always get all the published binaries, even superseded (this is not for the copy, but for another step of the build process) === victorp_ is now known as victorp [11:51] ogra_ hi [11:52] didrocks: not sure there's a desperately good way at the moment; maybe figure out the binary names you care about and call Archive.getPublishedBinaries repeatedly (ugh) [11:52] victorp, hey, see backlog [11:52] mvo: aaah! [11:52] SPPH.getPublishedBinaries is not my favourite interface [11:53] mvo: reproduces with xvfb-run python3 tests/test_view.py |cat [11:53] mvo: happens because stdout is not a pipe [11:53] mvo: so presumably less fails to start up? [11:53] less is normally quite happy if stdout isn't a tty - it basically just acts like cat [11:54] cjwatson: yeah, I have a workaround to avoid making all those calls for Archive.getPublishedBinaries and infering the binary names… :/ But wanted to ensure I wasn't missing something obvious at least. Thanks again for your advice. [11:56] ogra_, read that, not sure what did you decide [11:56] victorp, i just wanted you to confirm to xnox that legal work is done :) [11:57] so its only some code thats missing now to chow the notice ... [11:57] *show [11:57] done as in, I have talked to our legal team and they are happy that if we display the notice we can distribute the fw blobs [11:57] right [11:57] thats enough [11:57] yeap [12:06] mvo: so I tried this, which works in a shell: PAGER="sh -c 'cat >/tmp/xx; true'" man man [12:06] mvo: but it doesn't work in that test, I get "Syntax error: Unterminated quoted string" [12:08] xnox, are there any outstanding patches? [12:14] doko: not that I can find. but pitti reports that it's not working. [12:14] bdmurray, https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1064962/comments/100 ... is that an hard requirement? we track libreoffice 3.7 for raring, not 3.6 but it's not ready for upload yet [12:14] slangasek, ^ [12:14] Launchpad bug 1064962 in indicator-appmenu (Ubuntu Quantal) "[SRU] Global menubar items do not work when opening a document directly from nautilus with no LibreOffice instance running" [High,Confirmed] [12:14] ogra_: victorp: ack. [12:17] xnox, well, yes, disable these three odp tests ... [12:17] or odt. I don't think packages build docs for this format [12:18] pitti, could you mark https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/kde-l10n-sl/precise-updates/+merge/133394 as merged? it's in https://launchpad.net/ubuntu/+source/kde-l10n-sl/4:4.8.5-0ubuntu0.1 [12:18] pitti, (sorry for the direct ping but I mentioned it earlier and noboby picked it) [12:19] apw: did you intentionally drop linux-headers-omap, linux-image-omap, and linux-omap from linux-meta for armel and armhf? There's no clear mention in the changelog, and the diff for linux-meta has lots of */DEBIAN/* junk in it too ... [12:20] apw: wait, never mind, I'm misreading and those binaries weren't actually dropped. The */DEBIAN/* junk in the diff indicates that your source package build tree is dirty though, I think [12:21] apw: but that shouldn't block migration to release, so just for your next upload or whatever [12:26] can somebody mark https://code.launchpad.net/~matttbe/ubuntu/quantal/rhythmbox/1010619_795765/+merge/133343 as merged? [12:26] pitti, ^ [12:29] cjwatson, yeeks, i was pretty sure i git zapped the tree first ... :/ will look at it [12:29] dpkg-gencontrol: error: the Depends field contains an arch-specific dependency but the package is architecture all+ [12:29] GRRR ! [12:31] silly stuff, its a binary dep why shouldnt an arch all package not have arch specific binary deps [12:31] Because arch-specific dependencies are valid in source package control files, but are processed at build time and are syntactically invalid in the binary package's control file [12:32] hmm, k [12:34] seb128: looking (just returned from lunch, sorry for delay) [12:34] pitti, no worry, nothing urgent, thanks! [12:35] seb128: fini [12:36] pitti, danke [12:37] I've got an SRU for PulseAudio coming up. Any religious sacrifice I can do to make it a smooth sailing experience instead of it getting stuck on the stormy patch review ocean? [12:38] diwic, don't have an impossible to review diff, have SRU compliant bugs for the changes you include? [12:38] seb128, hmm, I think I got that covered [12:40] It's okay to SRU four different bugs in one SRU, right? [12:40] yeah [12:40] if they all meet the criteria [12:41] in case of PulseAudio, we've agreed to be a little more flexible; which is the case for at least one of the bugs, to avoid having to do a backport stack thing like we do for X [12:41] diwic, yeah, as long as each bug is SRU compliant it's fine === MacSlow is now known as MacSlow|lunch [12:46] * diwic uploads and hopes it all will go well [12:49] seb128, btw, how is the transition to gnome 3.6 going and should I do my reduction of the sound-nua delta before or after you upload 3.6 to raring? [12:51] mvo: ok, committed a verified fix now, using tee instead of less [12:51] mvo: doing an upload now; I want more green on jenkins :) [12:53] diwic, 3.6 is being prepared in the vcs and and in https://launchpad.net/~ubuntu-desktop/+archive/ppa ... you are welcome to rebase the sound-nua ui bits, we just dropped that in favor of the upstream version so far [12:53] diwic, it's not a blocker for the update but would be good to have [12:54] pitti: thanks! [12:54] pitti: I like tee more actually not less [12:54] * mvo makes a cup of tea [12:55] mvo: yeah, I couldn't make it work with a "sh -c"; and dd doesn't work either as it stumbles over the appended "-" [12:56] seb128, okay. I think the unity UI looks better :-) [12:59] * pitti chalks up the 6th fixed autopkgtest [13:03] mvo: I'll fix unattended-upgrades now (stderr and missing dependency), ok? [13:03] ah, cjwatson already committed the dep [13:04] pitti: thanks for docutils & python-markdown uploads, two items less in my todo list! :) [13:04] mitya57: ah, I thought you already fixed markdown independently in svn? [13:04] mitya57: docutils now built, so test suite runs fine during package build; it still failed in jenkins though, will have a look later [13:05] pitti: yes, but now it's not urgent for me to do a new upload [13:05] upstream bug for docutils is http://sourceforge.net/tracker/?func=detail&atid=422030&aid=3582720&group_id=38414 [13:05] I'll maybe look at it if I have time [13:06] mitya57: ah, thanks; I had a quick try to fix the _ElementWrapper → Element thingy, but failed [13:06] yeah, and I have no clue about that one [13:13] utlemming: I notice hv-kvp-daemon-init is built on all architectures - is it actually useful on non-x86? === bdrung_ is now known as bdrung [13:19] * mitya57 hopes that wifi will work better here [13:19] did I miss anything? :) [13:20] mitya57: I said two things to you after your previous comment, then nothing related [13:20] pitti: please repeat... [13:20] mitya57: ah, thanks; I had a quick try to fix the _ElementWrapper → Element thingy, but failed [13:20] yeah, and I have no clue about that one [13:21] mitya57: "that" -> the bug you referred to [13:21] that was not after my last comment, seems like it was not sent actually [13:21] pitti: "it still failed in jenkins though, will have a look later" — I don't see -0ubuntu3 jenkins job — where is it? === attente_zzz is now known as attente [13:22] mitya57: still on the internal one, will publish soon [13:22] mitya57: actually it is: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-proposed-adt-python-docutils/lastFailedBuild/ [13:23] yay, unattended-upgrades now works locally, /me uploads === Ursinha is now known as Ursinha-afk [13:23] that one is with -0ubuntu1 [13:23] * pitti aime le vert [13:23] but ok, I'll wait until it's published [13:24] oh right, that was the FTBFSing one [13:25] ricotz: OK uploaded with some changes. Look at the diff to see what I changed - I suggest you do the same in Debian too [13:25] mitya57: yay, it just succeeded! [13:25] oops, was meant to be in #-desktop [13:25] mitya57: (on the internal one for -proposed) === cpg is now known as cpg|away [13:25] well done pitti! [13:26] mitya57: well, it's at the price of disabling tests, but I don't know enough about it, and the failures are at least visible upstream [13:26] I feel better about the other 6 fixes, as these fix things properly === Ursinha-afk is now known as Ursinha [13:27] mitya57: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-proposed-adt-python-docutils/ :) [13:28] i'm tring to recompile ubuquity, but i've got this error: http://pastebin.com/H2ke9ne3 can oyu help me, please? [13:29] I'll take a quick look at that right now [13:29] mitya57: ok, thanks [13:30] mvo: is someone working on the software-center failures? [13:30] snikker|2: that was for pitti, not for you :(( [13:31] snikker|2: please see #ubuntu-installer. please publish _full_ build log. [13:31] snikker|2: maybe xnox knows [13:31] oops, he's already here [13:31] :) [13:32] is a build-depends "change libtiff4-dev to libtiff-dev" something worthing having a diff for on universe package? [13:32] do we try to drop libtiff4-dev from ubuntu? (I didn't follow much what was happening in quantal thereà [13:32] ) [13:32] seb128: yes. it's a tiff4 -> tiff5 transition. [13:32] e.g http://launchpadlibrarian.net/117905009/love_0.8.0-1_0.8.0-1ubuntu1.diff.gz [13:33] xnox: we do it without debian on the whole archive? [13:33] Yes [13:33] ok [13:33] thanks [13:33] Please don't drop those changes, I spent ages on them [13:33] Besides, they should be forwardable [13:33] libtiff-dev is tiff4 in Debian right now; after wheezy releases it'll be flipped to tiff5 [13:33] cjwatson, I didn't plan to drop them don't worry, I was just asking because I was unsure if that was a "let's migrate the default install" or something we would take diff on the whole universe for [13:34] the latter [13:34] cjwatson, xnox: thanks [13:34] I ran a transition tracker for it [13:35] cjwatson, so "please use libtiff-dev" is valid for Debian reports as well? (double checking) [13:35] xnox: i'm lookng for the full log, because in the terminal i don't have the full log [13:35] seb128: Yes [13:35] cjwatson, excellent, will forward that one then, thanks [13:35] seb128: Though maintainers might well not apply it until later ... [13:36] well, I just want to send a bug to the bts [13:36] For anything that uses libtiff-dev in Debian, a binNMU will suffice to transition it to tiff5 [13:36] that's fine if it sits there for a while [13:36] ok [13:36] that makes sense [13:37] seb128: the reason I did the whole archive rather than just a subset is that it became very quickly clear that if we transitioned just a subset then we ran into build failure problems with libtiff4-dev and libtiff5-dev conflicting [13:37] it was *very* much easier to just do the lot [13:38] I see [13:39] that will go away once debian release as well and those are easy to cary until then so no worry [13:44] * cjwatson fixes MoM again, hopefully [13:54] ricotz: thanks for the libsecret patch === seb128_ is now known as seb128 [14:30] Laney, thanks! [14:40] mvo: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-proposed-adt-ubuntu-release-upgrader/lastFailedBuild/ failed on amd64 because it expects "main restricted universe multiverse" in apt sources, but something writes it as "... multiverse universe" [14:40] pitti, can you set https://code.launchpad.net/~hggdh2/ubuntu/precise/cobbler/lp-967815/+merge/132172 to "work in progress"? [14:41] mvo: is that apt's fault, or u-r-upgrader's itself? [14:41] seb128: done [14:41] pitti, danke [14:41] mvo: at least it succeeds on i386 now [14:41] mvo: might be py 3.3 hash randomization or so? [14:42] pitti: smells like PYTHONHASHSEED [14:42] oh =) [14:42] ;-) [14:44] pitti: need to look in detail, but it does smell like the randomization [14:44] mvo: I ran it two times with the same result [14:45] mvo: but shouldn't this be ordered explicitly anyway? [14:49] seb128: There's no bug in debian/changelog for the havp upload you just did. Would you please add it and reupload. It breaks SRU tracking if we don't have it. [14:49] pitti: let me check the failure in detail, it should be yes [14:51] * pitti misses the gdb magic for debugging python (printing Python objects) [14:52] ScottK, sorry about that, rejected the upload and redid it with the bug reference [14:57] seb128: Thanks. No problem. [14:58] ugh this rename libdrm stuff scares me, hopefully it works and I'll never have to look at it again.. === MacSlow|lunch is now known as MacSlow [15:15] pitti, could you see https://code.launchpad.net/~betienne/ubuntu/quantal/gelemental/update/+merge/131998 to "Work in progress"? [15:15] xnox: sorry but i've got a problem with internet connection, btw the full log is here: http://pastebin.com/S3mTkpee [15:17] snikker: it doesn't say what machine you are building it on. [15:17] snikker: also 2.12.16 is the latest quantal installer. not 2.12.14. [15:17] snikker: are you building this on quantal? [15:18] yes i'm on quantal 64-bit [15:18] xnon: --^ [15:18] xnox: --^ [15:18] cjwatson: what does oif stand for? [15:19] snikker: please try 2.12.16, not 2.12.14. We released images with 2.12.16 [15:19] bdrung: I just work here [15:20] bdrung: I think it's Open Input Framework or some such [15:20] https://launchpad.net/oif [15:20] yeah [15:22] xnox: on launchpad page of ubiquity, i've got this error: "Failed to fetch package details" [15:23] xnox: now download page work [15:24] just try again or follow the link rather than the expander [15:24] Laney: ok can I get all of -lts-quantal added to the xorg package list? :p [15:24] mlankhorst: mail devel-permissions with a complete list [15:31] could somebody set https://code.launchpad.net/~betienne/ubuntu/quantal/gelemental/update/+merge/131998 to "Work in progress"? [15:31] https://code.launchpad.net/~utlemming/popularity-contest/oneiric.lp707311/+merge/131878 to rejected as well [15:43] Laney: ok is it enough that those packages were uploaded to a ppa in launchpad? [15:43] dunno [15:46] Laney: did i break something? :D [15:47] stokachu: yeah :( https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1076906 [15:47] Launchpad bug 1076906 in libgcrypt11 (Ubuntu) "1.5.0-3ubuntu2 breaks gpg-agent" [Undecided,Confirmed] [15:47] slangasek: yuck, udevadm trigger action=change to fix the perms is as ugly as the initial udev and consolekit acls on the device :) but, of course, if that's the proper way, i'll change to that (when I get a good chance to test). [15:47] damn [15:48] slangasek: one downside would have been that containers can't do udevadm trigger, but then they shouldn't get /dev/kvm auto-created by udev either so shouldn't have this bug. [15:48] thanks [15:48] Laney: this libgcrypt library is really becoming a headache [15:49] I hadn't heard of it before this morning :-) [15:52] Laney: do you want to assign that to me? [15:52] Ill nominate it for the raring series [15:53] the bug description there understates the impact BTW [15:53] it meant I couldn't log in [15:53] ah ok [15:53] see the dupe [15:53] ah [15:53] stokachu: hah. breaking gpg-agent, breaks me logging into my desktop environment. [15:54] * xnox disabled gpg-agent and carried on..... [15:54] lol [15:55] time for a quick revert if you won't be able to fix it before the weekend? [15:55] cjwatson: yes please [15:55] can you do that yourself or do you need help? [15:56] cjwatson: am i just creating a new debdiff with the previous code path? [15:56] tyhicks, hey when you have time, can you let me know what else is needed for bug 1052038? thanks [15:56] Launchpad bug 1052038 in ecryptfs-utils (Ubuntu Precise) "ecryptfs_fnek_sig missing when login at the same time on cron session close" [Medium,In progress] https://launchpad.net/bugs/1052038 [15:56] Just reverse-apply the debiff from 1.5.0-3ubuntu1 -> 1.5.0-3ubuntu2 apart from debian/changelog, and add a new changelog entry documenting the reason for the reversion [15:57] stokachu: take old package, add the current changelog entry, add a higher version changelog entry saying "this reverts previous upload", generate package done =) [15:57] gotcha ill do that now [15:57] That reminds me, I was going to create a wiki page with a brief log of all the reversions we do during the development cycle [15:57] stokachu: well, and debdiff it =) [15:57] Seems like a good time to start [15:58] cjwatson: i also updated teh appmenu-gtk with what i hope is correct way to m-a it [16:02] could i get a review/sponsor for bug 932860 [16:02] Launchpad bug 932860 in appmenu-gtk (Ubuntu Quantal) "Broken (or missing) multiarch support" [High,In progress] https://launchpad.net/bugs/932860 [16:02] also an approval for raring nomination [16:04] Daviey: any good reason why python-gnupginterface is explicitely seeded in development/ubuntu-server? [16:05] xnox: i wasn't aware it was! [16:06] xnox: did you blame? [16:06] Daviey: nah, I didn't blame. In precise the upgrade-tarball / landscape-client were using them. But not any more. [16:07] Daviey: asking you as the ubuntu-server's seed point of contact. [16:07] Daviey: unless I am very confused how/where development seed is included. [16:09]