[00:23] <bkerensa> Laney: https://code.launchpad.net/~bkerensa/ubuntu/raring/swauth/fix-for-1061020/+merge/133195
[00:23] <bkerensa> Laney: you asked me to forward to Debian but the package does not exist in Debian
[00:24] <xnox> Laney: somehow the packages list is ~8 hours out of date on the transition-tracker.
[05:38] <pitti> Good morning
[07:42] <mightyiam> thanks, TheMuso, i'll check
[07:46] <dholbach> good morning
[08:46] <mightyiam>  good morning indeed
[09:16]  * seb128 looks at dholbach and opt-in for some extra friday sponsoring out of his normal shift
[09:16] <seb128> !pilot in
[09:16] <seb128> @pilot in
[09:16]  * dholbach hugs seb128
[09:17]  * seb128 hugs dholbach back
[09:17] <dholbach> I'll sponsor a few bits later on, got to finish 2 other things first :)
[09:23] <mightyiam> my kernel in raring is "obsolete"
[09:23] <mightyiam> 3.5.0-18-generic
[09:24] <mightyiam> 29
[09:32] <cjwatson> mightyiam: Yes, I'm processing the 3.7.0-0 one through the archive at the moment.  No need to report it.
[09:33] <mightyiam> thanks, cjwatson
[09:42] <Laney> bkerensa: fair enough, comment in the MP to that effect then
[09:42] <Laney> xnox: uhh
[09:58] <xnox> 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] <xnox> =(
[09:58] <Laney> I'll look in a second
[09:58] <Laney> just collecting the pieces from that libgcrypt11 thingy
[09:59] <xnox> =)
[09:59] <xnox> thanks
[09:59] <Laney> stokachu: !!!
[10:16] <Laney> -rw-r--r-- 1 ubuntu-archive ubuntu_archive 1140090 Nov  8 14:09 Packages.bz2
[10:16] <Laney> xnox: suspicious eh
[10:17] <xnox> yeah....
[10:17] <Laney> hm
[10:17] <Laney> cjwatson: I suppose you didn't intend to turn that off :-)
[10:17] <mlankhorst> is the dpkg-diverts from libgtk-3-bin good enough as dumb example for dpkg-divert? :p
[10:18] <cjwatson> Laney: no - I'll lok
[10:18] <cjwatson> *look
[10:18] <Laney> ta
[10:18] <Laney> would JFDI but bzr
[10:18] <Laney> alternatively if I can just branch that and fix/push then I will
[10:18] <cjwatson> edit in place and commit
[10:18] <cjwatson> but
[10:18] <cjwatson> Laney: raring-proposed is up to date - I thought you'd stopped using raring in the transition tracker
[10:19] <Laney> it merges the two
[10:19] <Laney> because partial suite
[10:19] <cjwatson> oh, so you need to be triggered on a change to either, then?
[10:19] <Laney> well I suppose you could just sync release as well if proposed changes
[10:20] <Laney> you should only need to regenerate the tracker if proposed changes, right?
[10:21] <cjwatson> Laney: ok, should be fixed now
[10:22] <Laney> cheers
[10:25] <ScottK> 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] <seb128> ScottK, yes, https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1040259
[10:26] <seb128> ScottK, there is a new lib,api in quantal
[10:26] <ScottK> Sigh.
[10:27] <ScottK> Thanks.
[10:27] <seb128> yw
[10:27] <seb128> I didn't know KDE has a messaging indicator compatible with the old api
[10:27] <seb128> sorry about that, we should probably have added that to the list of things to port or at list consider it
[10:28] <seb128> hum
[10:28] <seb128> who synced glew?
[10:29] <seb128> 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] <Laney> https://lists.ubuntu.com/archives/raring-changes/2012-November/000950.html
[10:29] <seb128> Laney, "Sorry, changesfile not available."
[10:30] <Laney> the From line says who did it
[10:30] <seb128> oh, there is the signed-by
[10:30] <seb128> does alessio do IRC?
[10:30] <pitti> quadrispro
[10:30] <seb128> not there
[10:30] <seb128> grumpf
[10:31] <didrocks> cjwatson: is there a way hold manually proposed -> release pocket migration for this component?
[10:31] <pitti> hm, we don't yet have unity in autopkgtest; that ought to catch that?
[10:32] <didrocks> pitti: well, we can't run autopilot in autopkgtest as discussed in the UDS session
[10:32] <didrocks> pitti: because of need of bare metal
[10:32] <pitti> yeah
[10:34] <cjwatson> didrocks: I've blocked it for the time being
[10:34] <ScottK> 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] <didrocks> 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] <ScottK> seb128: I'm not actually sure all the bits it touches.
[10:36] <cjwatson> (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] <didrocks> sweet, that the conf is versionned :)
[10:36] <cjwatson> so please let me know if/when that can be unblocked
[10:37] <cjwatson> having that in bzr is probably overengineering but meh
[10:37] <seb128> didrocks, I emailed him and ubuntu-devel
[10:38] <didrocks> seb128: thanks!
[10:38] <didrocks> cjwatson: well, at least, we are sure to have a reason written in
[10:39] <cjwatson> yeah (I've just added a reference to this conversation)
[10:39] <cjwatson> I have no problem with anyone in ~ubuntu-release setting themselves up as a hinter
[10:40] <cjwatson> although I think any changes to lp:~ubuntu-release/britney/britney2-ubuntu still need to be deployed manually
[10:40] <Laney> you forced something in the other day - was that not through hints?
[10:40] <Laney> (I'm aware that the release team can do copies directly)
[10:42] <cjwatson> Laney: I forced eagle in using a hint
[10:43] <Laney> ah
[10:43] <Laney> I see it in history indeed
[10:43] <Laney> used to Debian ones where they use 'finished'
[10:43] <cjwatson> the release team can but shouldn't - better get britney to do it
[10:43] <cjwatson> yeah, their hints files aren't versioned, or weren't when I was last involved
[10:43] <cjwatson> given a VCS I see no point in leaving cruft in the file
[10:55] <pitti> 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] <pitti> mvo: I see that the "äää" appears on stdout (or err), and the fp.read() doesn't seem to get it
[11:00] <mvo> pitti: let me check
[11:04] <mvo> pitti: I wonder if mabye "less" is not installed in the test env
[11:04] <pitti> plausible, let me check
[11:04] <mvo> pitti: I update the test depends
[11:04]  * pitti runs run-adt-test -l
[11:07] <pitti> mvo: hm, I do have it installed here; that's a standard prepare-testbed VM
[11:08]  * pitti runs tests in there
[11:08] <mvo> pitti: I can do a upload with it added, maybe the server version is a bit different
[11:09] <pitti> oh, the tests runs a while
[11:10] <mvo> yeah
[11:13] <pitti> hm, no Python 3.2 any more in raring :(
[11:14] <xnox> pitti: nope. please rebuild your chroot as well, as there are packages that try to compile themself againsts "--installed"
[11:14] <xnox> python versions.
[11:14] <pitti> oh, I did, it's a fresh VM from yesterday
[11:15] <pitti> but we have packages which don't work yet with 3.3, so its removal seems a bit premature
[11:15] <xnox> pitti: which packages?
[11:15] <pitti> for comparing/debugging I can install it from quantal, though
[11:15]  * xnox thought we ported everything.....
[11:15] <pitti> like python-docutils; there are certainly more, though, it's just the one I'm currently looking at
[11:16] <xnox> I thought doko & mitya managed to get python-ductils workings....
[11:17] <pitti> the last build in raring was against 3.2
[11:17] <ogra_> xowow, thanks for the fstools, that was really fast
[11:17] <ogra_> xnox, ^^^
[11:18] <pitti> 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] <pitti> and that's happening from current upstream svn trunk as well, so upstream should be on it
[11:18] <xnox> ogra_: and it's in the ppa.
[11:18] <ogra_> xnox, well, its on archive.u.c and ports.u.c
[11:21] <xnox> ogra_: everywhere, where it matters =)
[11:21] <ogra_> yeah
[11:21]  * ogra_ is just missing the kernel now to start playing with the first images
[11:22] <cjwatson> why was the last linux-nexus7 upload in the queue rejected, do you know?
[11:22] <cjwatson> I saw a reject/reupload cycle but no explanation
[11:22] <ogra_> iirc there was an ftbfs with the tools package
[11:22] <ogra_> jani only discovered after upload
[11:22] <ogra_> janimo, ^^^
[11:23] <janimo> 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] <janimo> ogra_, so for the firmware are we settled on a separate package that puts up a notice when installed?
[11:25] <ogra_> janimo, apparently :/
[11:25] <ogra_> janimo, it needs to be preseedable though
[11:25] <janimo> is there a package I can look at that does something similar?
[11:25] <ogra_> so we can suppress the notice on image builds
[11:25] <janimo> preseedable?
[11:26] <ogra_> since there usb-creator will show it at image flash time
[11:26] <ogra_> the notice in the package just needs to be there for people installing the package separately
[11:28] <xnox> ogra_: hmmm....
[11:28] <xnox> ogra_: is the notice required, i thought we were meant to step that aside.
[11:30] <ogra_> xnox, apparently it is :(((
[11:30] <xnox> ogra_: so are you driving the legal workitem from the spec then?
[11:30] <ogra_> i'm not keen having it either
[11:31] <ogra_> legal is done
[11:31] <ogra_> victorp_, ^^^^
[11:31] <ogra_> we just need to display the same npotice that the shell script installer does nowadays
[11:31] <ogra_> (same thing for the package)
[11:32] <xnox> ogra_: ... and the notice will be a text file inside the tarball? (tar.gz: boot.img rootfs.img notice.txt README)
[11:32] <xnox> ;-)
[11:33] <ogra_> oh, sure, i could fish that out of the rootfs at build time
[11:34] <xnox> 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] <xnox> ogra_: and within tarball should be sufficient. Or maybe along side the tarball as well for apache to pick up as README
[11:34] <ogra_> i prefer inside if possible
[11:35]  * ogra_ doesnt like to touch make-web-indicies if avoidable :)
[11:35] <xnox> ack =)
[11:35] <pitti> mvo: I can reproduce the failure with less installed
[11:35] <ogra_> the first builds will be without firmware anyway i guess
[11:36] <seb128> could somebody mark https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/kde-l10n-sl/precise-updates/+merge/133394 as merged?
[11:36] <seb128> it was uploaded: https://launchpad.net/ubuntu/+source/kde-l10n-sl/4:4.8.5-0ubuntu0.1
[11:36] <pitti> mvo: "xvfb-run python3 tests/test_view.py" succeeds, though
[11:37] <didrocks> 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] <cjwatson> didrocks: Generally?  Neither.  What are you doing?
[11:38] <didrocks> cjwatson: I'm written the latest script for the copy from the PS release ppa to -proposed
[11:39] <didrocks> I have a list of package source name for a serie that are validated at this stage
[11:40] <cjwatson> 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] <cjwatson> But I don't really think that's a concern with copies into -proposed
[11:40] <cjwatson> Besides, both syncSource and syncSources are (lightly?) deprecated because they're synchronous and often time out
[11:40] <cjwatson> I would recommend using copyPackage instead
[11:41] <cjwatson> (you'll need to use the devel API version)
[11:41] <didrocks> cjwatson: copyPackage, not copyPackages? (like if one operation times out, maybe I'll push the validated stack partially)
[11:42] <didrocks> ah, it's async
[11:42] <cjwatson> You *could* use copyPackages, but I wouldn't as that suppresses announcement mails
[11:43] <cjwatson> Timeouts are very unlikely with copyPackage
[11:43] <cjwatson> And the proposed-to-release process should protect against most partial-copy situations
[11:43] <cjwatson> So I wouldn't worry about that
[11:44] <didrocks> cjwatson: makes sense, I'll follow your advice and test between ppas meanwhile. Thanks :)
[11:45] <didrocks> 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] <cjwatson> 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] <didrocks> cjwatson: agreed, just checking that I understand the parameter corectly.
[11:46] <cjwatson> You do
[11:46] <pitti> mvo: I confirmed it's not TMPDIR and similar; something more involved
[11:47] <didrocks> 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] <didrocks> 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] <didrocks> and there is no parameter compared to ppa.getPublishedBinaries() to catch them
[11:48] <didrocks> 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)
[11:51] <victorp> ogra_ hi
[11:52] <cjwatson> 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] <ogra_> victorp, hey, see backlog
[11:52] <pitti> mvo: aaah!
[11:52] <cjwatson> SPPH.getPublishedBinaries is not my favourite interface
[11:53] <pitti> mvo: reproduces with xvfb-run python3 tests/test_view.py |cat
[11:53] <pitti> mvo: happens because stdout is not a pipe
[11:53] <pitti> mvo: so presumably less fails to start up?
[11:53] <cjwatson> less is normally quite happy if stdout isn't a tty - it basically just acts like cat
[11:54] <didrocks> 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] <victorp> ogra_, read that, not sure what did you decide
[11:56] <ogra_> victorp, i just wanted you to confirm to xnox that legal work is done :)
[11:57] <ogra_> so its only some code thats missing now to chow the notice ...
[11:57] <ogra_> *show
[11:57] <victorp> 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] <ogra_> right
[11:57] <ogra_> thats enough
[11:57] <victorp> yeap
[12:06] <pitti> mvo: so I tried this, which works in a shell: PAGER="sh -c 'cat >/tmp/xx; true'" man man
[12:06] <pitti> mvo: but it doesn't work in that test, I get "Syntax error: Unterminated quoted string"
[12:08] <doko> xnox, are there any outstanding patches?
[12:14] <xnox> doko: not that I can find. but pitti reports that it's not working.
[12:14] <seb128> 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] <seb128> slangasek, ^
[12:14] <xnox> ogra_: victorp: ack.
[12:17] <doko> xnox, well, yes, disable these three odp tests ...
[12:17] <doko> or odt. I don't think packages build docs for this format
[12:18] <seb128> 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] <seb128> pitti, (sorry for the direct ping but I mentioned it earlier and noboby picked it)
[12:19] <cjwatson> 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] <cjwatson> 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] <cjwatson> apw: but that shouldn't block migration to release, so just for your next upload or whatever
[12:26] <seb128> can somebody mark https://code.launchpad.net/~matttbe/ubuntu/quantal/rhythmbox/1010619_795765/+merge/133343 as merged?
[12:26] <seb128> pitti, ^
[12:29] <apw> cjwatson, yeeks, i was pretty sure i git zapped the tree first ... :/  will look at it
[12:29] <ogra_> dpkg-gencontrol: error: the Depends field contains an arch-specific dependency but the package is architecture all+
[12:29] <ogra_> GRRR !
[12:31] <ogra_> silly stuff, its a binary dep why shouldnt an arch all package not have arch specific binary deps
[12:31] <cjwatson> 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] <ogra_> hmm, k
[12:34] <pitti> seb128: looking (just returned from lunch, sorry for delay)
[12:34] <seb128> pitti, no worry, nothing urgent, thanks!
[12:35] <pitti> seb128: fini
[12:36] <seb128> pitti, danke
[12:37] <diwic> 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] <seb128> diwic, don't have an impossible to review diff, have SRU compliant bugs for the changes you include?
[12:38] <diwic> seb128, hmm, I think I got that covered
[12:40] <diwic> It's okay to SRU four different bugs in one SRU, right?
[12:40] <Laney> yeah
[12:40] <Laney> if they all meet the criteria
[12:41] <diwic> 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] <seb128> diwic, yeah, as long as each bug is SRU compliant it's fine
[12:46]  * diwic uploads and hopes it all will go well
[12:49] <diwic> 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] <pitti> mvo: ok, committed a verified fix now, using tee instead of less
[12:51] <pitti> mvo: doing an upload now; I want more green on jenkins :)
[12:53] <seb128> 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] <seb128> diwic, it's not a blocker for the update but would be good to have
[12:54] <mvo> pitti: thanks!
[12:54] <mvo> pitti: I like tee more actually not less
[12:54]  * mvo makes a cup of tea
[12:55] <pitti> 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] <diwic> seb128, okay. I think the unity UI looks better :-)
[12:59]  * pitti chalks up the 6th fixed autopkgtest
[13:03] <pitti> mvo: I'll fix unattended-upgrades now (stderr and missing dependency), ok?
[13:03] <pitti> ah, cjwatson already committed the dep
[13:04] <mitya57> pitti: thanks for docutils & python-markdown uploads, two items less in my todo list! :)
[13:04] <pitti> mitya57: ah, I thought you already fixed markdown independently in svn?
[13:04] <pitti> 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] <mitya57> pitti: yes, but now it's not urgent for me to do a new upload
[13:05] <mitya57> upstream bug for docutils is http://sourceforge.net/tracker/?func=detail&atid=422030&aid=3582720&group_id=38414
[13:05] <mitya57> I'll maybe look at it if I have time
[13:06] <pitti> mitya57: ah, thanks; I had a quick try to fix the _ElementWrapper → Element thingy, but failed
[13:06] <pitti> yeah, and I have no clue about that one
[13:13] <cjwatson> utlemming: I notice hv-kvp-daemon-init is built on all architectures - is it actually useful on non-x86?
[13:19]  * mitya57 hopes that wifi will work better here
[13:19] <mitya57> did I miss anything? :)
[13:20] <pitti> mitya57: I said two things to you after your previous comment, then nothing related
[13:20] <mitya57> pitti: please repeat...
[13:20] <pitti> mitya57: ah, thanks; I had a quick try to fix the _ElementWrapper → Element thingy, but failed
[13:20] <pitti> yeah, and I have no clue about that one
[13:21] <pitti> mitya57: "that" -> the bug you referred to
[13:21] <mitya57> that was not after my last comment, seems like it was not sent actually
 pitti: "it still failed in jenkins though, will have a look later" — I don't see -0ubuntu3 jenkins job — where is it?
[13:22] <pitti> mitya57: still on the internal one, will publish soon
[13:22] <pitti> mitya57: actually it is: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-proposed-adt-python-docutils/lastFailedBuild/
[13:23] <pitti> yay, unattended-upgrades now works locally, /me uploads
[13:23] <mitya57> that one is with -0ubuntu1
[13:23]  * pitti aime le vert
[13:23] <mitya57> but ok, I'll wait until it's published
[13:24] <pitti> oh right, that was the FTBFSing one
[13:25] <Laney> 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] <pitti> mitya57: yay, it just succeeded!
[13:25] <Laney> oops, was meant to be in #-desktop
[13:25] <pitti> mitya57: (on the internal one for -proposed)
[13:25] <mitya57> well done pitti!
[13:26] <pitti> 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] <pitti> I feel better about the other 6 fixes, as these fix things properly
[13:27] <pitti> mitya57: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-proposed-adt-python-docutils/ :)
[13:28] <snikker|2> i'm tring to recompile ubuquity, but i've got this error: http://pastebin.com/H2ke9ne3 can oyu help me, please?
[13:29] <mitya57> I'll take a quick look at that right now
[13:29] <snikker|2> mitya57: ok, thanks
[13:30] <pitti> mvo: is someone working on the software-center failures?
[13:30] <mitya57> snikker|2: that was for pitti, not for you :((
[13:31] <xnox> snikker|2: please see #ubuntu-installer. please publish _full_ build log.
[13:31] <mitya57> snikker|2: maybe xnox knows
[13:31] <mitya57> oops, he's already here
[13:31] <mitya57> :)
[13:32] <seb128> is a build-depends "change libtiff4-dev to libtiff-dev" something worthing having a diff for on universe package?
[13:32] <seb128> do we try to drop libtiff4-dev from ubuntu? (I didn't follow much what was happening in quantal thereà
[13:32] <seb128> )
[13:32] <xnox> seb128: yes. it's a tiff4 -> tiff5 transition.
[13:32] <seb128> e.g http://launchpadlibrarian.net/117905009/love_0.8.0-1_0.8.0-1ubuntu1.diff.gz
[13:33] <seb128> xnox: we do it without debian on the whole archive?
[13:33] <cjwatson> Yes
[13:33] <seb128> ok
[13:33] <seb128> thanks
[13:33] <cjwatson> Please don't drop those changes, I spent ages on them
[13:33] <cjwatson> Besides, they should be forwardable
[13:33] <cjwatson> libtiff-dev is tiff4 in Debian right now; after wheezy releases it'll be flipped to tiff5
[13:33] <seb128> 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] <cjwatson> the latter
[13:34] <seb128> cjwatson, xnox: thanks
[13:34] <cjwatson> I ran a transition tracker for it
[13:35] <seb128> cjwatson, so "please use libtiff-dev" is valid for Debian reports as well? (double checking)
[13:35] <snikker|2> xnox: i'm lookng for the full log, because in the terminal i don't have the full log
[13:35] <cjwatson> seb128: Yes
[13:35] <seb128> cjwatson, excellent, will forward that one then, thanks
[13:35] <cjwatson> seb128: Though maintainers might well not apply it until later ...
[13:36] <seb128> well, I just want to send a bug to the bts
[13:36] <cjwatson> For anything that uses libtiff-dev in Debian, a binNMU will suffice to transition it to tiff5
[13:36] <seb128> that's fine if it sits there for a while
[13:36] <seb128> ok
[13:36] <seb128> that makes sense
[13:37] <cjwatson> 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] <cjwatson> it was *very* much easier to just do the lot
[13:38] <seb128> I see
[13:39] <seb128> 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] <mightyiam> ricotz: thanks for the libsecret patch
[14:30] <ricotz> Laney, thanks!
[14:40] <pitti> 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] <seb128> pitti, can you set https://code.launchpad.net/~hggdh2/ubuntu/precise/cobbler/lp-967815/+merge/132172 to "work in progress"?
[14:41] <pitti> mvo: is that apt's fault, or u-r-upgrader's itself?
[14:41] <pitti> seb128: done
[14:41] <seb128> pitti, danke
[14:41] <pitti> mvo: at least it succeeds on i386 now
[14:41] <pitti> mvo: might be py 3.3 hash randomization or so?
[14:42] <xnox> pitti: smells like PYTHONHASHSEED
[14:42] <xnox> oh =)
[14:42] <xnox> ;-)
[14:44] <mvo> pitti: need to look in detail, but it does smell like the randomization
[14:44] <pitti> mvo: I ran it two times with the same result
[14:45] <pitti> mvo: but shouldn't this be ordered explicitly anyway?
[14:49] <ScottK> 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] <mvo> 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] <seb128> ScottK, sorry about that, rejected the upload and redid it with the bug reference
[14:57] <ScottK> seb128: Thanks.  No problem.
[14:58] <mlankhorst> ugh this rename libdrm stuff scares me, hopefully it works and I'll never have to look at it again..
[15:15] <seb128> pitti, could you see https://code.launchpad.net/~betienne/ubuntu/quantal/gelemental/update/+merge/131998 to "Work in progress"?
[15:15] <snikker> xnox: sorry but i've got a problem with internet connection, btw the full log is here: http://pastebin.com/S3mTkpee
[15:17] <xnox> snikker: it doesn't say what machine you are building it on.
[15:17] <xnox> snikker: also 2.12.16 is the latest quantal installer. not 2.12.14.
[15:17] <xnox> snikker: are you building this on quantal?
[15:18] <snikker> yes i'm on quantal 64-bit
[15:18] <snikker> xnon: --^
[15:18] <snikker> xnox: --^
[15:18] <bdrung> cjwatson: what does oif stand for?
[15:19] <xnox> snikker: please try 2.12.16, not 2.12.14. We released images with 2.12.16
[15:19] <cjwatson> bdrung: I just work here
[15:20] <cjwatson> bdrung: I think it's Open Input Framework or some such
[15:20] <Laney> https://launchpad.net/oif
[15:20] <Laney> yeah
[15:22] <snikker> xnox: on launchpad page of ubiquity, i've got this error: "Failed to fetch package details"
[15:23] <snikker> xnox: now download page work
[15:24] <cjwatson> just try again or follow the link rather than the expander
[15:24] <mlankhorst> Laney: ok can I get all of -lts-quantal added to the xorg package list? :p
[15:24] <Laney> mlankhorst: mail devel-permissions with a complete list
[15:31] <seb128> could somebody set https://code.launchpad.net/~betienne/ubuntu/quantal/gelemental/update/+merge/131998 to "Work in progress"?
[15:31] <seb128> https://code.launchpad.net/~utlemming/popularity-contest/oneiric.lp707311/+merge/131878 to rejected as well
[15:43] <mlankhorst> Laney: ok is it enough that those packages were uploaded to a ppa in launchpad?
[15:43] <Laney> dunno
[15:46] <stokachu> Laney: did i break something? :D
[15:47] <Laney> stokachu: yeah :( https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1076906
[15:47] <hallyn> 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] <stokachu> damn
[15:48] <hallyn> 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] <hallyn> thanks
[15:48] <stokachu> Laney: this libgcrypt library is really becoming a headache
[15:49] <Laney> I hadn't heard of it before this morning :-)
[15:52] <stokachu> Laney: do you want to assign that to me?
[15:52] <stokachu> Ill nominate it for the raring series
[15:53] <Laney> the bug description there understates the impact BTW
[15:53] <Laney> it meant I couldn't log in
[15:53] <stokachu> ah ok
[15:53] <Laney> see the dupe
[15:53] <stokachu> ah
[15:53] <xnox> stokachu: hah. breaking gpg-agent, breaks me logging into my desktop environment.
[15:54]  * xnox disabled gpg-agent and carried on.....
[15:54] <stokachu> lol
[15:55] <cjwatson> time for a quick revert if you won't be able to fix it before the weekend?
[15:55] <stokachu> cjwatson: yes please
[15:55] <cjwatson> can you do that yourself or do you need help?
[15:56] <stokachu> cjwatson: am i just creating a new debdiff with the previous code path?
[15:56] <arges> tyhicks, hey when you have time, can you let me know what else is needed for bug 1052038? thanks
[15:56] <cjwatson> 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] <xnox> 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] <stokachu> gotcha ill do that now
[15:57] <cjwatson> 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] <xnox> stokachu: well, and debdiff it =)
[15:57] <cjwatson> Seems like a good time to start
[15:58] <stokachu> cjwatson: i also updated teh appmenu-gtk with what i hope is correct way to m-a it
[16:02] <stokachu> could i get a review/sponsor for bug 932860
[16:02] <stokachu> also an approval for raring nomination
[16:04] <xnox> Daviey: any good reason why python-gnupginterface is explicitely seeded in development/ubuntu-server?
[16:05] <Daviey> xnox: i wasn't aware it was!
[16:06] <Daviey> xnox: did you blame?
[16:06] <xnox> Daviey: nah, I didn't blame. In precise the upgrade-tarball / landscape-client were using them. But not any more.
[16:07] <xnox> Daviey: asking you as the ubuntu-server's seed point of contact.
[16:07] <xnox> Daviey: unless I am very confused how/where development seed is included.
[16:09] <Daviey> xnox: i don't think development was really defined.. If i am honest, foundations normally touches that
[16:09] <xnox> Daviey: blame says mdz 2006 "add development seed"
[16:10] <cjwatson> xnox: Feel free to ditch it if it's no longer appropriate
[16:10] <xnox> Daviey: ok, thanks. I'll go talk to somebody in foundations..... =)
[16:10] <Daviey> well that is the first commit, so doesn't help.. clealry broken out from something
[16:10] <xnox> cjwatson: ack.
[16:10] <cjwatson> stokachu: Of course this patch was in itself a regression fix :-/
[16:10] <Daviey> xnox: JFDI. :)
[16:11] <xnox> Daviey: it's just scary, why $ seeded-in-ubuntu -b python-gnupginterface
[16:11] <xnox> reports: ubuntu-server: daily
[16:12] <xnox> tumbleweed: ^^^^ can you help me understand above
[16:12] <xnox> ?
[16:12] <jpds> xnox: landscape-common ?
[16:12] <stokachu> cjwatson: yea to many dependencies on libgcrypt
[16:12] <cjwatson> seeded-in-ubuntu is badly named and concerns what's actually in images
[16:12] <stokachu> Laney: i uploaded a revert to that gpg bug if you want to take a look
[16:12] <xnox> jpds: not in raring anymore ;-)
[16:13] <cjwatson> the development seed isn't relevant to images
[16:13] <xnox> jpds: as in, in raring, landscape-common does not depend on python-gnupginterface.
[16:13] <tumbleweed> better name suggestions are always appreciated
[16:14] <cjwatson> xnox: well, germinate thinks that's why it's pulled in
[16:14] <Daviey> Anyway, it's unseeded now :-)
[16:14] <cjwatson> xnox: remember that seeded-in-ubuntu's output is based on the last successful image build
[16:14] <xnox> cjwatson: so germinate will catch up, on the next run =)
[16:15] <xnox> cjwatson: ah, so tomorrow it will be ok =)
[16:15] <cjwatson> xnox: And you only changed landscape-client today
[16:15] <snikker> xnox: smare error with ubiquity 2.12.16: http://pastebin.com/xLRJUbac
[16:15] <snikker> *same
[16:15] <Daviey> seeded-in-ubuntu IMO is just a guide.. i wouldn't trust it's output entirely.
[16:16] <cjwatson> I trust its output, but only for the specific thing it does
[16:16] <cjwatson> i.e. "what images is this on"
[16:16] <cjwatson> tumbleweed: something like grep-ubuntu-images?  But I don't know whether it's worth the effort of renaming.
[16:16] <tumbleweed> if there is a reasonable way to include germinate seeding, it could do that
[16:16] <Daviey> cjwatson: Last cycle it reported openvswitch was in kubuntu, which it didn't seem to be.
[16:17] <xnox> cjwatson: "smare error with ubiquity 2.12.16: http://pastebin.com/xLRJUbac " <--- any idea why the test now gests Eastern/Canada instead of Eastern/US on that users machine?
[16:17] <cjwatson> Daviey: that was because I didn't purge the Kubuntu images that we weren't building any more for some time
[16:17] <cjwatson> Daviey: But they were still the last on disk so it was reasonable
[16:17] <Daviey> cjwatson: I don't believe it was /ever/ in kubuntu
[16:17] <cjwatson> xnox: No
[16:18] <xnox> snikker: can you reproduce this in a pbuilder? have you modified tzdata / ubuntu packages?
[16:19] <xnox> snikker: the test does not fail on ubuntu dev machines, nor in ubuntu sbuild / pbuilder.
[16:19] <xnox> snikker: if you really, really want to build ubiquity disable that test. but I'm guessing you are mixing up embeded software somewhere.
[16:20] <xnox> cjwatson: Daviey: i'd like to drop all of the development seed. It only has a semi-random set of  python2 libraries that we want to all port to python3 and drop python2 equivalents from main.
[16:20] <cjwatson> Daviey: Hard to debug at this point.  If you see oddities such as that again I'd be happy to look when the evidence is still present.
[16:21] <cjwatson> xnox: If you do anything like that then please do a before/after comparison of germinate output to make sure that you aren't dropping things out of main that we want to keep supporting.
[16:21] <cjwatson> (In terms of source packages.)
[16:21] <snikker> xnox: i don't have modified nothing... i'll try in pbuild...how can u disable the test?
[16:23] <xnox> cjwatson: ack. that was my first though. cause something useful might be hanging on via that.
[16:23] <xnox> s/though/thought/
[16:23] <cjwatson> stokachu,slangasek: I've created https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog so that we can collect data about these kinds of discussions
[16:24] <Daviey> cjwatson: turns out, that example you already did.. http://irclogs.ubuntu.com/2012/10/02/%23ubuntu-release.html#t18:32 :)
[16:25] <stokachu> cjwatson: ok cool ill update the wiki with outcome
[16:27] <cjwatson> Daviey: you were apparently asking about package sets there, not about seeded-in-ubuntu output
[16:27] <cjwatson> Daviey: so are you sure you're remembering it correctly now? :-)
[16:30] <Daviey> cjwatson: Why let facts get in the way of a perfectly good rant? :)
[16:30] <cjwatson> heh
[16:31] <bdmurray> Is anybody uploading libgcrypt11 to raring?  If not I will.
[16:31] <Laney> I'm test building it now
[16:31] <Laney> you can take care of rejecting the SRUs
[16:31] <Laney> if not done already
[16:31] <bdmurray> Laney: I did that already
[16:32] <Laney> stokachu: you don't need to explicitly target proposed when uploading to the dev series
[16:32] <stokachu> Laney: ok ill note that down
[16:39] <seb128> could somebody set https://code.launchpad.net/~betienne/ubuntu/quantal/gelemental/update/+merge/131998 to "Work in progress"?
[16:39] <seb128>  https://code.launchpad.net/~utlemming/popularity-contest/oneiric.lp707311/+merge/131878 to rejected as well
[16:39] <seb128> stgraber, ^?
[16:39] <stgraber> sure
[16:39] <seb128> thanks
[16:46] <mpt> ev, why have the 12.04 and 12.10 lines stopped?
[16:46] <ev> stopped?
[16:47] <mpt> ev, yes, at October 26
[16:47] <mpt> whereas the 13.04 line goes on to November 8
[16:47] <xnox> ev: https://errors.ubuntu.com/ the graph not plotting 12.04 and 12.10
[16:47] <ev> oh, that's fixed in trunk
[16:47] <mpt> ok :-)
[16:47] <xnox> also, raring has mood swings =)
[16:48] <Laney> stokachu: ok, seems to work, uploading
[16:49] <cjwatson> so few users of 13.04 as yet that the granularity is rather coarse, I suspect ...
[16:49] <cjwatson> a lot of it seems to be failures to install ia32-libs-multiarch
[16:50] <mpt> By my calculations there are 40.5 machines running Raring
[16:50] <xnox> mpt: 1/8 of which are mine.
[16:50]  * Laney has 2 of them
[16:50] <mpt> It's probably the 0.5 of a machine that's causing all the trouble
[16:51] <stgraber> that seems a bit low considering I have 8 just here, but quite a few never reported a crash so I guess that may still be correct ;)
[16:51] <mpt> stgraber, yeah, I really mean 40 that have reported any errors so far
[16:52]  * xnox is still at 1/8th
[16:52]  * xnox goes to regenerate uuids....
[16:52] <Laney> stokachu: ok, done. I expanded your changelog a bit, fixed the target and inserted a bug reference
[16:53] <cjwatson> ia32-libs seems installable here, although I guess that's a relatively sensitive test
[16:54] <cjwatson> but proposed-migration *should* have rendered that much more robust in the development series
[16:54] <stokachu> Laney: ok thanks!
[16:54] <cjwatson> four of the six reports I saw were from the same user
[16:55] <cjwatson> *shrug*
[16:58] <bdmurray> seb128: I've accepted libreoffice now
[16:58] <seb128> bdmurray, thanks a lot
[16:58] <seb128> Sweetshark, ^
[17:07] <Sweetshark> bdmurray: thanks, awesome
[17:15] <xnox> barry: python3-chardet is packaged as a separate source package.
[17:15] <xnox> barry: so chardet is "ported"
[17:15] <xnox> barry: do I mark it green on the spreadsheet? remove it? or simply drop it from the tracker?
[17:15] <barry> xnox: yep, it's a separate upstream code base too
[17:16] <xnox> barry: is it compatible?
[17:16] <barry> xnox: in the 13.04 spreadsheet, i guess let's mark it green (doesn't matter too much i guess either way)
[17:16] <xnox> barry: how about I drop it from the tracker?
[17:16] <barry> xnox: i haven't done an exhaustive api comparison ;)
[17:16] <barry> xnox: +1
[17:17] <xnox> barry: =))) http://people.canonical.com/~ubuntu-archive/transitions/onlypy3oncd.html
[17:17] <xnox> barry: similarly python-oauth should not be on the tracker, as we have oauthlib.
[17:17] <barry> xnox: agreed.  i'm in the process of filing bugs on the relevant task:destktop packages to switch to oauthlib
[17:18] <xnox> barry: ack.
[17:18] <xnox> barry: is oauthlib in main yet? (Main-Inclusion-Report etc...)
[17:18] <barry> xnox: that's a good question
[17:19] <barry> xnox: yes, i think so.  fwiw, upstream just released 0.3.2 and that's now packaged in raring.  it fixes all the outstanding bugs we've had (and quilt patches we were carrying)
[17:20] <xnox> barry: cool =)
[17:49] <seb128> @pilot out
[18:02] <seb128> stgraber, can you mark https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422 as "work in progress" as well?
[18:05] <stgraber> seb128: done
[18:06] <seb128> thanks
[18:16] <slangasek> seb128: I'm not convinced that LibO should have a general exception to the SRU rule of "fix in dev first", but it doesn't need to be a hard rule, yeah
[18:16] <slangasek> hallyn: udevadm trigger + containers> right, presumably you've already solved the general class of problem of udevadm called in a container
[18:16] <slangasek> (or will soon :)
[18:18] <hallyn> slangasek: nope :)
[18:18] <hallyn> i meant :(
[18:18] <hallyn> that's device ns
[18:19] <hallyn> all we have now is a big stick
[18:19] <hallyn> ("no writes under /sys)
[18:59] <micahg> @pilot in
[19:00] <micahg> I forget, was it decided to enable proposed when test building?
[19:10] <marrusl> quick question... even for raring, the changelog for a patch should target raring-proposed yes?
[19:10] <ogra-cb> no need for that
[19:10] <dobey> marrusl: it doesn't matter if the changelog says raring or raring-proposed; it will go straight to -proposed anyway
[19:10] <ogra-cb> your behavior doesnt need to change at all
[19:11] <marrusl> gotcha.
[19:11] <marrusl> while I'm here... is there a doc/wiki that will help me divine whether to bump the #ubuntu# version by 1 or .1 ?  (it's a really trivial patch)
[19:12] <dobey> dch -i
[19:13]  * micahg wonders how ogra doe IRC over CB
[19:13] <marrusl> dobey, I should be in a raring chroot though, yes?  or does that not matter.
[19:13] <ogra-cb> micahg, using ubuntu ;)
[19:13] <ogra-cb> and xchat
[19:13] <micahg> dobey: that's not clear
[19:13] <dobey> marrusl: doesn't matter, you can change the entry to raring if it doesn't set it to it
[19:14] <marrusl> dobey, right.  ok just wondering if that affects the behavior of dch -i....  which now makes no sense to me. basically I'm hearing trust dch -i  :)
[19:14] <dobey> marrusl: using .1 is typically for special cases where the exact same version already exists on development version and stable version, and you need to update both; the stable version would get the .1
[19:14] <micahg> marrusl: SRUs general bump by .X, dev release is generally X, dch -i won't DTRT for the first SRU of something
[19:14] <marrusl> aaah.... that helps!
[19:14] <ogra-cb> security is also usually .X
[19:15] <marrusl> dobey, micahg, ogra-cb .....  much appreciated!
[19:15] <micahg> security update versioning is documented: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[19:15] <dobey> marrusl: simple solution; never trust software. but it's text file and dch -i just adds a new section. you can still tweak it appropriately in $EDITOR :)
[19:16] <marrusl> dobey, right yeah, for something this minor I can't think of a good reason to bother with a chroot even.  that's pretty much what I've done before.  minimal effor... pull-lp-source; vi  :)
[19:16] <marrusl> cool.
[19:27] <micahg> ogra-cb: stgraber: is https://launchpad.net/ubuntu/+source/classmate-initramfs still useful?
[19:28] <ogra-cb> micahg, no, should be burned
[19:28] <micahg> ogra-cb: thanks, will file for removal
[19:30] <micahg> can a TB person please mark this as WIP or rejected: https://code.launchpad.net/~vericalcroft/ubuntu/quantal/classmate-initramfs/added-misc-depends/+merge/125442
[19:43] <micahg> can I get a TB person to mark this as merged: https://code.launchpad.net/~obounaim/ubuntu/quantal/z3c.formui/added-homepage/+merge/125418
[19:56] <stgraber> micahg: done
[19:56] <stgraber> micahg: feel free to highlight me directly for those, I don't always notice "TB" :)
[19:57] <micahg> stgraber: ok, thanks
[20:14] <slangasek> seb128: isn't the conclusion here that we should make Logan a MOTU and then the sponsorship queue will be manageable again? :)
[20:14] <micahg> @pilot out
[20:15] <seb128> slangasek, yeah, I told Daniel that he should get him onboard ;-)
[20:15]  * slangasek grins
[20:34] <obounaim> micahg, what does TB stands for?
[20:35] <infinity> obounaim: Tech Board.
[20:36] <obounaim> ok thanks
[20:39] <ogra-cb> or thunderbirs if tou are in the #ubuntu-desktop channel ;)
[20:39] <ogra-cb> *you
[20:55] <zZommm> hello everyone, i have a packaging question, hope someone can help me here.
[20:56] <zZommm> i tried building libvirt-1.0.0 for quantal.
[20:56] <zZommm> threw out a few patches that were not needed, a few other changes and now it builds.
[20:56] <zZommm> but libvirt0 depends on libyajl1 instead of libyajl2. what could have gone wrong? libyajl1 is not even in quantal.
[20:58] <zZommm> shlibs:Depends is obviously right, because the library in the built package is linked to yajl1:
[20:58] <zZommm> $ ldd libvirt.so.0.1000.0  | grep yajl
[20:58] <zZommm>         libyajl.so.1 => not found
[21:02] <slangasek> zZommm: to have generated such a reference, you must have had libyajl.so.1 somewhere on your system when you built it.  Perhaps there's an embedded copy in the source tree?
[21:02] <zZommm> i'll check, but i doubt it.
[21:02] <zZommm> this is a fresh quantal install and i've used pbuilder to build the package.
[21:04] <zZommm> slangasek, no, nothing on the system with yajl and 1 in the name
[21:05] <zZommm> as i've said, fresh QQ install, pbuilder env created and this package built. Nothing else.
[21:05] <slangasek> zZommm: oh.  Does this show up when you instead run 'objdump -p libvirt.so.0.1000.0 | grep NEEDED.*yajl ?
[21:05] <slangasek> '
[21:08] <zZommm> slangasek, yes:   NEEDED               libyajl.so.1
[21:08] <slangasek> fun fun
[21:09] <slangasek> zZommm: well, it would be nontrivial to generate a library with that content without the library actually being present at build time
[21:09] <zZommm> yes it is :) the package build-depends on libyajl-dev, and that has only version 2.0.something available, it couldn't be anything else.
[21:09] <zZommm> ok
[21:09] <zZommm> i'll build again and keep the pbuilder chroot.
[21:09] <slangasek> right, let me check the *actual* contents of libyajl2
[21:10] <zZommm> this is a first one for me too, i've built (backported mostly) my fair share of packages and never encountered this.
[21:11] <slangasek> the libyajl2 package in the archive is correct (filename libyajl.so.2, soname matches)
[21:11] <slangasek> is the source package that you're building available somewher?
[21:11] <zZommm> no.
[21:11] <zZommm> but i can put it somewhere.
[21:11] <zZommm> just a sec.
[21:17] <zZommm> slangasek, http://9bit.biz/libvirt/
[21:18] <slangasek> zZommm: and you're sure this isn't a matter of building it in the wrong pbuilder chroot?
[21:18] <zZommm> 100%
[21:18] <zZommm> wait
[21:18] <zZommm> i'll check again
[21:18] <slangasek> because precise had libyajl1
[21:19] <zZommm> yes
[21:19] <zZommm> that was it
[21:19] <zZommm> pbuilder set up a wrong chroot
[21:19] <zZommm> stupid stupid stupid me for missing that
[21:19] <zZommm> thank you.
[21:20] <slangasek> aha, ok :)
[21:20] <zZommm> who would have thought
[21:20] <zZommm> that the debootstrap default on quantal is precise.
[21:21] <zZommm> according to the manpage pbuilder uses debootstrap default if nothing is specified
[21:24] <Sweetshark> anyone here able to nominate bug 1017125 for quantal pls? thx.
[21:28] <Sweetshark> disregard that. already happened
[21:32] <cjwatson> zZommm: I can't see such a statement in pbuilder's man page, and debootstrap doesn't *have* a default
[21:34] <zZommm> cjwatson, let me check again... i might have misread. Anyway, i ran pbuilder create without any other parameters and it created a precise chroot.
[21:35] <cjwatson> pbuilder has its own default
[21:35] <cjwatson> which is indeed still precise
[21:36] <zZommm> my mistake, yes. I was skimming over the manpage and somehow concluded that it used debootstrap defaults. which is strange, since debootstrap requires you to specify the distribution :)
[21:37] <cjwatson> exactly
[21:40] <zZommm> ok, package built and installed, seems to be working :)
[21:41] <zZommm> should i submit this somewhere? Debian already has libvirt-1.0.0 in experimantal, i just used the latest ubuntu packaging and applied it to the new version. I had to remove a few patches that are not needed anymore and make one or two other small changes.
[21:42] <infinity> zZommm: You might want to talk to smb and see what he's got going on for libvirt for raring.
[21:43] <infinity> zZommm: Or possibly hallyn.
[21:44] <slangasek> indeed, there was a UDS session about libvirt plans
[21:44] <zZommm> i'll check that out.
[21:44] <slangasek> http://summit.ubuntu.com/uds-r/meeting/21087/servercloud-r-libvirt/
[21:44] <zZommm> thanks
[21:44] <sarnold> .. I thought someone had a 1.0.0 ready to upload already?
[21:45] <infinity> That's not much for session notes.
[21:46] <zZommm> i created a package because 0.9.13 (in Q) has trouble with openvswitch networking.
[21:46] <slangasek> the blueprint has some notes, and also points at the people to harrass :)
[21:46] <infinity> (which happens to be the two people I mentioned, though in the inverse order)
[21:47] <infinity> zZommm: If you can identify what needs fixing and backport a patch to SRU 0.9.13, that might be nice.  We don't tend to push new versions to old releases, except in exceptional cases.
[21:48] <zZommm> i don't need you to put it in Q, i made this for me. But since the package should also work on R, I don't see a reason not to share it :)
[21:49] <zZommm> infinity, the problem on Q is that virt-manager does not really know what to do if you're using openvswitch. It just tries to use the classic linux bridge and fails.
[21:49] <slangasek> mdeslaur: that reminds me... did you have any further thoughts on the OVMF thing in virt-manager?  Given that we do have to change both the bios and the video bios
[21:51] <zZommm> libvirt 0.9.13 supports ovs, but only if you change the XML config of a VM by hand. Creating a new network type with ovs config doesn't really work (well). Or so I've been told by a libvirt developer earlier today.
[21:52] <zZommm> I can't access that blueprint, seems i'm not sexy enough :)
[21:58] <marrusl> zZommm, I think you just need to join the ~ubuntu-etherpad group in LP.  Anyway, that's the etherpad for the UDS discussion, here's the actual blueprint:
[21:58] <marrusl> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-libvirt
[22:00] <zZommm> thanks.
[22:01] <marrusl> np!
[22:03] <zZommm> i msgd him, but he's obviously not here, and I'm not on IRC 24/7. Should I send an email? would that be hallyn at canonical?
[22:03] <zZommm> oh i got it, i can get the email off launchpad. good.
[23:08] <mdeslaur> slangasek: I've poked at it a bit, but I can't think of a good way to do it that isn't a complete hack....the best idea I've come up with so far is to define a new arch, ie: "x86_64 UEFI" or something, and use a qemu-system-x86_64-uefi wrapper
[23:09] <slangasek> mdeslaur: hrm; why is that better than just setting the xml options?
[23:10] <mdeslaur> slangasek: because the xml files are handled by libvirt, and virt-manager is a level of abstraction away from that, and all the options are determined by libvirt "capabilities"
[23:10] <slangasek> ok
[23:11] <slangasek> so would libvirt need extended first?
[23:12] <mdeslaur> yes, and even libvirt doesn't really know things like filesystem paths, it's relying on qemu knowing all about that
[23:12] <mdeslaur> so in theory, you can specify the video bios as part of the xml definition of the video adapter, but that part isn't hooked up yet in the qemu libvirt backend
[23:13] <mdeslaur> it's a big abstracted mess
[23:13] <slangasek> can you?  I didn't find a libvirt option for specifying a video bios, only a card type
[23:14] <mdeslaur> devices, like network cards, have a "romfile" option
[23:15] <mdeslaur> qemu supports the same property for video devices
[23:15] <mdeslaur> slangasek: there's some info in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=811227
[23:16] <mdeslaur> slangasek: and also a link to how to combine the video rom into the main rom
[23:17] <mdeslaur> slangasek: but even if we do that, the gui would still be pretty awkward...ie: you'd have to manually specify an alternate bios for the video device, etc.
[23:17] <mdeslaur> which is why I was thinking of just creating a new arch (x86_64 EUFI)
[23:18] <mdeslaur> whoops, UEFI
[23:18] <slangasek> right... it's also not great to allow users to specify incompatible combinations of bios and video rom
[23:19] <mdeslaur> the ovmf package could ship the qemu-system-x86_64-uefi and qemu-system-i386-uefi scripts, which would just be a shell file that adds the appropriate option for the alternate directory
[23:20] <mdeslaur> and a trivial distro patch could be added to libvirt to gain knowledge of those two new archs
[23:20] <mdeslaur> it's also hackish, but that's where I'm at now
[23:22] <mdeslaur> (is i386 relevant for UEFI?)
[23:23] <sarnold> mdeslaur: _maybe_ initial apple intel machines?
[23:23] <mdeslaur> sarnold: I'm not sure that relevant for ovmf
[23:24] <mdeslaur> oh, seems vvmf does have some 32 bit stuff
[23:25] <cjwatson> mdeslaur: in principle, although not currently in practice for Ubuntu
[23:43] <mdeslaur> slangasek: do you have a package somewhere with the ovmf stuff in it?
[23:43] <slangasek> mdeslaur: not yet... jk took the action to provide that
[23:44] <slangasek> (I think he has a binary build floating about somewhere)
[23:53] <jelmer> One of my syncs into raring was just rejected "Rejected by archive administrator.". How do I tell why that is?
[23:53] <xnox> jelmer: DO NOT PANIC - we are removing armel
[23:54] <xnox> jelmer: check the publishing history, probably just the armel binary was "rejected"
[23:55] <jelmer> xnox: ah, ok - thanks