[00:51] <cjwatson> ockham_: I think I would have to see the source package to work it out
[00:51] <ockham_> cjwatson: it's in the debian games git repo
[00:51] <ockham_> i've pushed it recently
[00:52] <ockham_> git://git.debian.org/git/pkg-games/pysolfc.git
[01:00] <cjwatson> can you give me a URL for the upstream tarball?
[01:07] <cjwatson> ockham_: ^-
[01:07] <ockham_> cjwatson: http://sourceforge.net/projects/pysolfc/files/PySolFC/PySolFC-2.0/
[01:14] <SpamapS> hrm... sphinxsearch from debian unstable looks broken on arm.
[01:17] <SpamapS> ugh between multiarch and --as-needed fixes I'm becoming an autoconf expert. :-P
[01:17] <cjwatson> excellent
[01:17] <cjwatson> ockham_: (working on it)
[01:18] <ockham_> cjwatson: great, thx!
[01:18] <broder> SpamapS: you should never admit to that publicly
[01:21] <SpamapS> broder: it was a weak moment
[01:22] <cjwatson> ockham_: oh, I see - your debian/control stanza for pysol has Section in between the short description and the extended description, and this thoroughly confuses everything
[01:22] <cjwatson> ockham_: move that Section line up a line or two
[01:23] <ockham_> cjwatson: wow, i really didn't figure it was the order of those attributes...
[01:24] <cjwatson> it's not about ordering, it's that you have a multi-line Section field :-)
[01:25] <cjwatson> Section can come after Description (though that would be unconventional), but if you put it in the *middle* of Description, what you get is "Section: oldlibs\n Package to ease upgrading from ..."
[01:25] <cjwatson> and that is very much not good
[01:26] <ockham_> cjwatson: oh damnit. i just cut and pasted it, but i really had not noticed it had been *there*
[01:26] <ockham_> time to blush
[01:26] <ockham_> anyway, i'm trying to build it now
[01:26] <ockham_> sry to bother you with something so trivial...
[01:27] <SpamapS> oh the irony, http://sphinxsearch.com/bugs/my_view_page.php has no search field.
[01:28] <ockham_> cjwatson: build successful. yay!
[01:29] <cjwatson> cool
[01:34] <ockham_> cjwatson: uploading to mentors now. feel like reviewing (or even sponsoring) it?
[01:35]  * SpamapS submits his 20th bug report to debian related to the libmysqlclient transition
[01:35] <cjwatson> um, probably not sorry, it's a bit too late at night for me to try to exercise critical faculties, and I have a fairly busy week ahead with alpha-1 coming up
[01:38] <ockham_> cjwatson: ok, thx anyway. maybe another time
[01:38] <ockham_> ...
[01:46] <mneptok> SpamapS: use MariaDB ;)
[05:19] <broder> so if i want to attack the remaining ia32-libs problems, i should try to install ia32-libs-multiarch, pick a package that's not available, and go to town, right?
[05:21] <micahg> well, that package or its reverse dependencies if it has any
[05:22] <RAOF> broder: gstreamer is an excellent candidate :)
[05:23] <broder> ...that sounds like entrapment
[05:24] <broder> but i'll at least download the source and look at how bad it is
[05:24] <RAOF> Moderately bad.
[05:25] <RAOF> You inherit a library and a bunch of architecture-dependent plugins to that library.
[05:25] <RAOF> So you get to play transition time!
[05:25] <broder> yeah, that's what i would have figured
[05:26] <broder> why would i play transition time instead of check-a-list-of-paths time?
[05:26] <RAOF> Well… because you wanted to make gstreamer uninstallable for a while?
[05:27] <TheMuso> lol
[05:31] <broder> as much as that sounds like a fun game, i'll at least *start* by trying to check a list of paths
[05:40] <SpamapS> mneptok: I doubt maria will solve these problems, unless it magically convinces m4 scripts that files in /usr/lib/x86_64-gcc-linux are actually in /usr/lib
[05:42] <micahg> m4 scripts shouldn't hard code paths
[06:00] <pitti> Good morning
[06:02] <SpamapS> micahg: exactly. its ridiculous
[06:04] <SpamapS> micahg: to be fair, about half of the libmysqlclient using packages (50 or so of the 111) do it right by simply using AC_LINK_IFELSE
[06:17] <broder> RAOF: nope, i give up. too much work to start at 10 pm :)
[07:10] <tjaalton> how to find out why a package upload got rejected?
[07:10] <pitti> tjaalton: the email doesn't say? that's the usual way
[07:11] <tjaalton> pitti: no, can't see any comments there
[07:12] <pitti> was it a -proposed stable upload? rejections from the +queue page don't have comments
[07:12] <pitti> the reason for those should be noted in the corresponding SRU bug by the SRU team
[07:13] <pitti> or if it was a source NEW upload, you should get mail from teh archive admins
[07:13] <pitti> what kind of upload was that/
[07:13] <pitti> ?
[07:15] <tjaalton> it was n-m for oneiric-proposed, and i have a hunch why it got rejected
[07:16] <tjaalton> sponsored the upload, and it wasn't pushed to bzr
[07:16] <tjaalton> and the changelog entry didn't have LP: #xxxxxx
[07:19] <Sarvatt> tjaalton: oneiric-proposed would of been higher version than precise too
[07:20] <tjaalton> oh that too
[07:20] <tjaalton> hmm
[07:20] <tjaalton> meh :)
[07:21] <micahg> well, that's not a cause for a reject, unless it was versioned wrong
[07:21] <tjaalton> it got -Xubuntu5.1
[07:21] <micahg> so, that wouldn't be a reason for reject, just a reason not to move to -updates
[07:22] <micahg> but not closing the bug would be :)
[07:24] <RAOF> tjaalton: Right.  I rejected that, and sent an email to the dude in the changelog.  No LP reference :)
[07:25] <tjaalton> RAOF: ha! so I get to fix that too :)
[07:26] <RAOF> Hm.  Maybe I should have checked the changes file; I think that should have listed you as the uploader somewhere.
[07:27] <tjaalton> not the changes file
[07:28] <pitti> no, the uploader is only visible as the GPG signer of the .changes file
[07:28] <pitti> the +queue page doesn't show it anywhere
[07:28] <broder> gpg --verify -> "you don't have the key for foo" -> gpg --recv-keys foo
[07:29] <RAOF> I forget.  Can you get the signed changes file out of the queue?
[07:29] <tjaalton> how confusing.. n-m versions have bumped the "major" ubuntu version in -proposed
[07:30] <tjaalton> so -0ubuntu{4,5}
[07:30] <micahg> people aren't careful right after release which IMHO should be warned about more strongly
[07:32] <micahg> but IANA release or SRU team member
[07:32] <tjaalton> i've now done the same change as 0ubuntu6 for precise
[07:32] <micahg> s/release/archive/
[07:39] <tjaalton> RAOF: I've reuploaded it, precise too this time (0u6)
[08:01] <dholbach>  good morning
[09:00] <micahg> pitti: can you copy something quickly for me?  thunderbird 8.0+build1-0ubuntu0.11.10.1 from ubuntu-mozilla-security to oneiric-security?
[09:03] <pitti> darn, missed the publisher, copy-package takes really long :(
[09:03] <pitti> micahg: done now, but I figure it was a few seconds too late :(
[09:04] <micahg> ugh, ok, I thought it would be close, should be ok though, the newer extensions have a build-dep on the newer thunderbird, so update-manager won't offer them until thunderbird gets in
[09:04] <micahg> oops, I meant binary-dep :)
[09:04] <micahg> pitti: thanks
[09:07] <micahg> pitti: BTW, copy-packages being slow is why I have to keep asking you :)
[09:07] <pitti> micahg: ah, because lplib scripts time out, too?
[09:08] <micahg> yeah
[09:08] <pitti> we have that problem all the time with SRUs
[09:08] <micahg> it's a problem when there are too many binaries for me
[09:24] <pitti> apw, smb: can we have a current l-b-m and l-meta for 3.2.0-2?
[09:24] <pitti> so that alpha-1 will actually test -2, and we get rid of the remaining NBS?
[09:26] <smb> pitti, We will have a look. I thought ogasawara or apw did mention something there...
[09:26] <pitti> smb: danke!
[09:26] <smb> pitti, bitte! :)
[09:27] <apw> pitti, smb, sorry yes, will do that now
[09:28] <pitti> apw: great, thanks!
[09:28] <micahg> pitti: apparently we caught the publisher in time :)
[09:28] <pitti> micahg: ah, nice
[09:30] <smb> apw, Will you also push/create the initial precise-lbm tree on zinc?
[09:41] <infinity> apw: Oh hey.
[09:41] <infinity> apw: While you're fiddling with kernel packaging, can I get you to fix armhf for me? ;)
[09:41] <apw> infinity, whats wrong?
[09:42] <infinity> flock -w 60 /home/adconrad/linux-3.2.0/debian/.LOCK dh_gencontrol -plinux-image-3.2.0-2-omap
[09:42] <infinity> dpkg-gencontrol: error: current host architecture 'armhf' does not appear in package's architecture list (armel)
[09:42] <infinity> apw: You missed giving us a kernel on control.
[09:42] <infinity> s/on/in/
[09:42] <infinity> apw: Not that I care deeply about the kernel itself anyway, but I need the build to complete for linux-libc-dev to get spit out the other end. ;)
[09:43] <apw> infinity, ok will have a look see after meta
[09:43] <infinity> apw: Danke.
[09:43] <apw> hard to test as i have no chroot to test it in will you get it working (circlular dependancy erro)
[09:43] <infinity> apw: Do you have arm kit locally?  I can give you a chroot with all the kernel build-deps installed.
[09:46] <infinity> apw: I'm just tidying up some last-minute gotchas in the eglibc packaging, but we're basically ready to go except for linux-libc-dev.  I can (and likely will, if I have to) open using the hacked up linux-libc-dev I have here, but I'd rather use the Ubuntu saucy one.
[09:46] <apw> infinity, nope no kit either, we should have the chroot on the porter really
[09:47] <infinity> apw: It got all the way to the above, though, so I imagine it just needs s/armel/armel armhf/ across the various control shippets, and life's happy.
[09:47] <apw> i can probabally figure it out without one, as it should clean at least
[09:47] <apw> which generates control
[09:47] <apw> let me get pitti happy and i'll poke it
[09:47] <apw> infinity, could you zap me the whole build log into pastebin
[09:47] <infinity> apw: There will be chroots on scheat reasonably soon, I imagine, but I suspect people are wary of basing them on my 1st/2nd-stage bootstrap.
[09:47] <infinity> apw: If I had logged it, sure. :P
[09:47] <infinity> apw: (Yeah, I know...)
[09:49] <infinity> apw: My backscroll goes back to debian/rules binary-arch, which is probably all that's interesting.  Let me grab that.
[09:49] <apw> pitti, ok linux-meta in the pipe.  there is no lbm at this early stage, if you have NBS on linux-backports-modules-2.6.35, those die with oneiric and can be culled
[09:50] <apw> pitti, i probabally don't mean 2.6.35, which version are they
[09:50] <infinity> apw: http://paste.ubuntu.com/752311/
[09:51] <pitti> apw: I can remove linux-backports-modules-3.0.0 in its entirety if that's appropriate, yes
[09:51] <apw> pitti, yean 3.0 is oneiric's one so that is not needed in precise
[09:52] <apw> it will get replaced by a 3.2.0 in time
[09:52] <pitti> apw: ok, done
[09:52] <apw> pitti, thanks
[09:53] <pitti> apw: ah, tanks for the -meta upload, that should clear up http://people.canonical.com/~ubuntu-archive/nbs.html quite a bit
[10:00] <infinity> apw: Is that paste sufficient for your needs?
[10:01] <apw> infinity, /me looks
[10:05] <apw> infinity, yeah think that i've got it, if i pastebin you a patch can you test it for me
[10:06] <infinity> apw: Yep, turnaround's going to suck, you're conteding with 3 GCC builds and an eglibc build. ;)
[10:06] <infinity> apw: But I'll definitely test it here, so I have a proper linux-libc-dev in my 2nd-stage repository for tomorrow.
[10:07] <apw> infinity, will just double check it
[10:08] <apw> infinity, http://paste.ubuntu.com/752319/
[10:08] <apw> seems to put armhf everywhere armel is, so ... that should be right
[10:08] <infinity> apw: Big patch.
[10:09] <apw> infinity, heh indeed.  if you are only making linux-libc-dev could you not use the shortcut STAGE thing that linaro added
[10:10] <infinity> apw: I didn't know there was such a thing. :P
[10:10] <apw> infinity, i belive if you build with DEB_STAGE=stage1 you only get bootstrap packages
[10:10] <infinity> apw: Oh, shiny.
[10:10] <apw> (you also get a couple of useless ones which are empty)
[10:10] <infinity> apw: Maybe I should do that, then do a test of your patch for you.
[10:11] <apw> infinity, sounds appropriate
[10:11] <infinity> Though, I have to nap anyway.
[10:11] <infinity> Testing your patch should finish before I wake up.
[10:11] <infinity> I'll just do that.
[10:11] <apw> heh ok
[10:13] <apw> infinity, ok i've pushed that fix to our repos anyhow, its got to be better than whats there
[10:13] <infinity> apw: I suspect it'll do the trick.
[10:20] <apw> infinity, yeah pretty sure it will.  the DEB_STAGE stuff if your friend though, its definatly for this specific purpose
[11:27] <cjwatson> soren: are you planning to update user-mode-linux to 3.2.0?  looks like you did the last update
[11:57] <soren> cjwatson: It wasn't on my radar, but I certainly can.
[11:57] <cjwatson> thanks
[11:58] <soren> cjwatson: Hm... Where did you spot this?
[12:00] <soren> cjwatson: Oh, processing NBS?
[12:08] <om26er_> when does patch pilot start?
[12:09] <seb128> om26er_, whenever they feel like starting, there is no fixed time
[12:09] <nigelb> om26er_: depends on when today's pilot starts work.
[12:10] <om26er_> ok, i'll wait then.
[12:10] <infinity> om26er_: Is there something specific you were looking for piloty help with?
[12:11] <om26er_> infinity, just wanted to get two SRUs uploaded, it could wait a bit ;-)
[12:12] <infinity> Mmkay.  If you're cool with waiting, I'll go have breakfast instead of being helpful. ;)
[12:15] <zul> Riddell: can you have a look at quantum again please? thanks
[12:15] <cjwatson> soren: NBS, yes
[12:17] <om26er_> infinity, oops, totally missed the message, does the offer still stand? https://code.launchpad.net/~om26er/ubuntu/oneiric/indicator-sound/fix-864405/+merge/83589
[12:17] <om26er_> ;-)
[12:17] <om26er_> and also https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz-plugins-main/fix-sru-regressions-2/+merge/83590
[12:20] <seb128> om26er, the compiz one, there is a packaging vcs you should use this one
[12:20] <soren> I wonder if we should rename the kernel source binary package to linux-source-3.2 (rather than linux-source-3.2.0).
[12:21] <seb128> om26er, the packaging vcs has a fix commited for the grid keybinding issues which didn't get uploaded yet and should probably go in the same upload
[12:22] <om26er> seb128, https://code.launchpad.net/~compiz/compcomm-plugins-main/ubuntu ?
[12:22] <seb128> om26er, same issue with the indicator-sound sru, those issues should also be fixed in precise before sru-ed
[12:22] <seb128> om26er, yes
[12:23] <om26er> seb128, okay, I will get indicator-sound uplaoded to precise first and then SRU
[12:23] <om26er> seb128, about compiz plugins, does that also need to be uploaded to precise first?
[12:23] <seb128> yes, any SRU requires to be uploaded to the current serie first
[12:24] <om26er> there is a different fix for precise with test cases.. for bug 891886
[12:25] <seb128> om26er, ok, well the fix needs to be uploaded in precise first then you can get a SRU
[12:26] <om26er> seb128, so for precise the i pull the branch with test cases and get it uploaded, then for oneiric the simpler version of the branch?
[12:27] <seb128> om26er, correct, the goal is to ensure that the bugs are fixed in the current serie as well
[12:28] <seb128> om26er, you can probably ping kenvandine directly for the indicator sponsor and see if didrocks is interested in sponsoring the compiz one or if he prefers you to go through patch pilot sponsoring rather
[12:28] <seb128> didrocks, ^ not sure if you want to deal with the compiz uploads or are happy to let them through the sponsoring workflow
[12:29] <didrocks> seb128: this can go to the sponsoring workflow (if it's not upstream, we should ensure that smspillaz reviewed it and that there is a test due to the new req.)
[12:33] <om26er> sam reviewed fix for bug 891886 and approved it, the thing is he took the branch from the contributor and added test cases, what I am wondering is does it need to go with test cases to oneiric or would be fine without test cases,
[12:38] <didrocks> om26er: would be fine without the test case if the test case is running in precise
[12:39] <om26er> didrocks, okay thx
[12:41] <didrocks> yw :)
[13:43] <smoser> anyone else hitting bug 897230
[13:49] <tumbleweed> smoser: yes, you want bug 893826
[13:49] <smoser> tumbleweed, mark that as a dupe?
[13:50] <tumbleweed> your one is a dup
[13:55] <tjaalton> hum, nss was forked for ubuntu four years ago.. does anyone know why?
[13:56] <tjaalton> (no merges since Sun, 16 Dec 2007)
[13:57] <infinity> tjaalton: Probably because we forked all the mozilla.org components back then.
[13:58] <infinity> tjaalton: Though I can think of no particular argument to have nss or nspr forked.
[13:59] <tjaalton> infinity: ok.. just wondering if we or debian are going to get the systemwide nssdb stuff packaged anytime soon..
[14:00] <infinity> tjaalton: No idea.  But merging with Debian and then working with them might not be an awful plan.
[14:01] <tjaalton> infinity: yeah, I'll ask mike what he feels about it. there are some bugreports that seem related
[14:03] <stgraber> @pilot in
[14:13] <tjaalton> infinity: merges.ubuntu.com has a comment for nss: "do not merge"..
[14:15] <pitti> SpamapS: FYI, committing your qt4-x11 upload to its bzr (Vcs-Bzr)
[14:16] <infinity> tjaalton: Yes, I imagine nss and nspr are both blacklisted since they were forked, but it's worth re-examining that.
[14:17] <infinity> tjaalton: Perhaps talk to asac about the rationale at the time.
[14:17] <tjaalton> infinity: yeah, I will
[14:21] <pitti> infinity, cjwatson: I'm pondering what to do for bug 893826, do you have a minute to discuss this?
[14:21] <infinity> pitti: Sure.
[14:21] <infinity> pitti: My knee-jerk reaction is "stop doing that", but I suspect that's not an option? ;)
[14:22] <pitti> infinity, cjwatson: tl;dr: if a package uses dh --parallel, dh_builddeb also gets called with --parallel, which effectively ruins the predictable order that dh_builddeb gives us
[14:22] <ogra_> sounds like an evil upstream :P
[14:22] <pitti> so aside from "drop doc symlinking altogether" (which doesn't sound very appealing as it will increase our CDs by some 12 MB), the other option that I see is to never run dpkg-deb in parallel
[14:23] <infinity> How do you propose stopping people from doing so?
[14:23] <pitti> so we could eitehr modify debhelper to not respect the --parallel option for dh_builddeb only, or have pkgbinarymangler divert dh_builddeb to filter out the option
[14:23] <infinity> Doc symlinking still sort of scares me anyway.
[14:23] <pitti> the former is trivial, but introduces another permanent delta into debhelepr
[14:24] <pitti> infinity: agreed that it's scary in a way
[14:24] <infinity> Not just "in a way".
[14:24] <cjwatson> yeah, I'd prefer a diversion for that given that it's much more closely related to pkgbinarymangler than to debhelper really
[14:24] <infinity> It's downright scary.
[14:24] <infinity> The way dpkg deals with links versus targets is curiously fun.
[14:24] <pitti> infinity: only for directories
[14:24] <pitti> infinity: pkgbinarymangler doesn't symlink directories for that very reason
[14:24] <infinity> Ahh, and you only link individual files?
[14:24] <infinity> Fair enough.
[14:24] <pitti> infinity: quite a lot of packages did that manually in the past, before we had that
[14:24] <pitti> and it was a mess
[14:25] <pitti> infinity: yes
[14:25] <infinity> And I assume only between arch:any packages, etc, etc.
[14:25] <infinity> Anyhow.  Whatever.  I suspect it's here to stay.
[14:25] <pitti> infinity: yes
[14:25] <pitti> infinity: we don't link any -> all to avoid skew between i386 and other arch builds
[14:25] <infinity> But you're also going to not actually solve your problem by mangling dh --parallel.
[14:26] <infinity> There are other ways to run dpkg --build in parallel.
[14:26] <pitti> infinity: not dh --parallel, just dh_builddeb --parallel
[14:26] <pitti> infinity: right, but then the pacakge needs to explicitly do that
[14:26] <cjwatson> infinity: I suspect I can count the number of packages doing that on the fingers of one head, though
[14:26] <infinity> There are packages that explicitly do that. :P
[14:26] <cjwatson> Wow.  You strange finger-headed person.
[14:26] <pitti> but fixing these individually is a doable task
[14:27] <infinity> (not calling dpkg raw, but calling dh_builddeb without --parallel while still being, well, parallel)
[14:27] <pitti> I would like to avoid having to change qt4-x11 and friends to DTRT here and be aware of pkgbinarymangler, that sounds wrong
[14:27] <infinity> Given that --parallel happened after DEB_BUILD_OPTIONS=parallel, the latter has home-brew hacks all over.
[14:28] <infinity> But.  Maybe those cases don't matter as much.
[14:28] <infinity> Given that the first that springs to mind is the kernel.
[14:28] <infinity> Which won't hit the multiarch bug anyway. :P
[14:28] <pitti> yeah, multiarch isn't much of a problem there
[14:28] <infinity> (gcc is another, and it can)
[14:28] <cjwatson> the other scary alternative is to modify the diverted dpkg-deb to background itself and queue until they know which order to run in
[14:28] <infinity> But I don't think gcc runs binary-arch in paralle.
[14:28] <infinity> l
[14:28] <cjwatson> but I suspect that's too terrifying to live
[14:29] <pitti> cjwatson: that actually crossed my mind, but it seems very easy to get wrong
[14:29] <infinity> cjwatson: I think I just threw up a little.  But I kinda like it.
[14:29] <infinity> cjwatson: dpkg-deb triggers.
[14:29] <cjwatson> WCPGW
[14:29] <pitti> so I think pkgbinarymangler diverting dh_builddeb and filtering DH_OPTIONS/--parallel etc. still seems reasonably safe and confines changes to pkgbinarymangler itself
[14:29] <cjwatson> dpkg-deb queueing has a certain appeal but I think it's probably too fragile
[14:29] <pitti> still a bit "ugh" due to the diversion, that's why I wanted to consult you
[14:30] <cjwatson> least of three evils
[14:30] <cjwatson> it can't possibly be scarier than diverting dpkg-deb, which pkgbinarymangler already does
[14:30] <diwic> this is probably just me showing off that I don't know anything about packaging, but as I understand the problem is that some file or symlink ends up in different packages on different builds (due to some kind of race). Wouldn't you explicitly specify what files and symlinks belong to which package?
[14:30] <infinity> pitti: Can you confirm that said hack actually DTRT?
[14:31] <cjwatson> diwic: no, this is a special mangling operation that we do on the buildds outside of packaging
[14:31] <infinity> cjwatson: Of course, since we already divert dpkg-deb (you're welcome for that insanity), we can totally add triggers.
[14:31] <pitti> infinity: I'll start writing tests around that, etc. now, but it's what I finally figured out as the root cause
[14:31] <diwic> cjwatson, ok, thanks
[14:31] <infinity> pitti: I'm rather unfamiliar with how dh --parallel works, but it still just calls each helper once?
[14:31] <pitti> diwic: pkgstriptranslations walks the dependencies and symlinks an identical file in /usr/share/doc/<pkg>/ to the version in its Depends:
[14:32] <infinity> pitti: And then lets them fork?
[14:32] <cjwatson> diwic: e.g. so that we can do certain hacks without having to modify everything
[14:32] <pitti> diwic: but that fails if the order of processed packages differs on different arches
[14:32] <pitti> phone, brb
[14:34]  * infinity notes that dh(1) is remarkably unhelpful about what --parallel actually does.
[14:43] <diwic> so this is only a problem on source packages that build two binary packages that would be dependent on each other.
[14:43] <infinity> pitti: Okay, yeah, after looking at how --parallel works, diverting dh_builddeb to filter the option seems like the least objectionable idea.
[14:44] <infinity> diwic: Yeah.
[14:44] <diwic> in which case one can wonder why they are two separate packages in the first place, but I guess that's a completely different topic...
[14:45] <cjwatson> there are sometimes good reasons for circular deps
[14:45] <infinity> It's not always circular...
[14:45] <infinity> liba and a-bin both depend on a-common, for instance.
[14:45] <infinity> So docs from the first two can be links to the third.
[14:53] <cjwatson> hallyn: bug 897254 - I'd rather not accept qemu-kvm through binary NEW until that's fixed
[14:54] <cjwatson> in fact, I'm rejecting it from binary NEW (though that's unusual) to prevent it breaking upgrades for everyone who has it installed
[14:54] <hallyn> cjwatson: checking
[14:55] <pitti> re, sorry
[14:56] <pitti> infinity: yes, I looked in dh_builddeb
[14:56] <hallyn> cjwatson, ok, thanks
[14:56] <pitti> infinity: it spawns dpkg-deb processes until the limit, and then picks them up
[14:56] <hallyn> cjwatson: does rejecting as you're doing mean i can re-use the version # by chance?
[14:56] <pitti> infinity: so if the limit is 1, it's completely serial
[14:56] <cjwatson> hallyn: no, the source is already in the archive, so you'll need to bump
[14:56] <pitti> infinity: and the input list is ordered according to the order in control, I checked that
[14:56] <hallyn> cjwatson: ok, was pretty sure, just checking, thanks.
[14:57] <cjwatson> (unfortunately, one consequence of source-only uploads is that we don't get to catch this kind of thing until after builds have happened)
[14:57] <hallyn> darn you smoser  :)
[14:57] <pitti> diwic: it's not just circular depends
[14:57] <cjwatson> (this is why Debian's planned approach of source+throwaway-binary uploads is probably technically better even though it feels odd)
[14:57] <pitti> diwic: in this case, it's qt4-something depends: libqt-foo1, libqt-bar1
[14:58] <pitti> diwic: and depending on which order it processes the binaries, the qt4-something symlink goes into libqt-foo1 or libqt-bar1
[14:58] <pitti> infinity, cjwatson: thanks for the feedback, I'll go with that then
[14:59] <diwic> pitti, hmm, I think this is the case where I understand that than I thought I understood, the more is explained to me :-)
[14:59] <hallyn> cjwatson: stupid question, in the Replaces/Breaks, now do i use the version # that just failed?  or the one before it?
[14:59] <cjwatson> hallyn: sorry for the delay in reviewing this in the queue
[14:59] <cjwatson> hallyn: the versions I gave in the bug report should be correct - it's best to do << the first version that had it in the new location (whether that got built successfully or not)
[15:00] <diwic> pitti, where I understand that I understand less than I thought I understood
[15:00] <diwic> or something
[15:00] <pitti> heh
[15:00] <cjwatson> hallyn: that accounts for people who might have built it locally, say, although that's probably theoretical in this case, but still
[15:00] <hallyn> cjwatson: great, thanks
[15:04] <hallyn> cjwatson: and how bogus is it to add the other bug# into this commit msg?
[15:05] <cjwatson> hallyn: not especially but I think if it were me I'd just close it by hand with the text of the previous changelog entry
[15:05] <hallyn> ok, will do, thx
[15:06] <cjwatson> or I suppose you could add the bug# and then use debuild -S -v0.15.0+noroms-0ubuntu2
[15:06] <cjwatson> which would have the effect of closing the bug with the text of both changelog entries (check the .changes file before uploading to confirm this)
[15:06] <hallyn> i *think* i see what you mean, but i think i'll do it byhand right now :)
[15:25] <roadmr> Hey everyone! I need to report a couple upstream bugs on the kernel, but bugzilla.kernel.org is still down :-/ what's a good place to file bugs in the meanwhile? LKML? or the per-subsystem mailing lists? what are other people doing about this?
[15:31] <SpamapS> pitti: ty, I have been ignoring Vcs- tasks up until now. :-P
[15:31] <awsoonn> hi all, I'm trying to follow the packaging guide and pbuilder  isn't working for me: http://pastebin.com/0Rzk8PCt
[15:32] <awsoonn> something about an invalid release file... I'm sure I just missed something though.
[15:32] <cjwatson> awsoonn: where did archive.canonical.com come from?  that should be archive.ubuntu.com
[15:33] <awsoonn> cjwatson: from as far as I can tell, the default /etc/pbuilderrc file
[15:33] <awsoonn> I'll change it and see if that gets me anywhere. :)
[15:34] <tkamppeter> Which virtualization software are you using? I use qemu-kvm and virtual machine manager on Oneiric abd the Ctrl key does not work for the guests.
[15:34] <awsoonn> Jup, That did the trick. Thank you cjwatson
[15:35] <cjwatson> awsoonn: are you sure it was the default, rather than something in the guide you followed?  I'd be really very surprised if it were the default
[15:35] <cjwatson> archive.canonical.com only has the partner repository on it, not any of Ubuntu itself
[15:36] <infinity> cjwatson: /var/lib/dpkg/info/pbuilder.config tries to cleverly construct pbuilderrc based on your sources.list (mine lists my local mirror, and I know I've never configured pbuilder, cause I don't even use it).
[15:36] <cjwatson> oh ouch
[15:37] <cjwatson> so the problem is that awsoonn's system has archive.c.c first in sources.list (which isn't the default, but still)
[15:38]  * infinity nods.
[15:38] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/621169
[15:52] <rye> ping kenvandine, re: bug #874501 - right now we are blocked on completely unrelated bug. Can we omit it from current SRU and add this later on?
[15:53] <kenvandine> pitti, can you look at bug 874501
[15:55] <rye> kenvandine, the patch for multiple entries may come in later, if we find out some apps are breaking this way (which i highly doubdt, since usually apps drop/re-create entries)
[15:56] <kenvandine> rye, lets get another response from someone on the SRU team
[15:58] <pitti> kenvandine: right, I wasn't sure about the ordering behaviour change, that sounds like a potential regression which is utterly hard to detect
[15:58] <pitti> kenvandine: so perhaps we can backport that one patch
[15:58] <kenvandine> pitti, yeah... but i think it is more likely to fix some hard to reproduce bugs...
[15:58] <kenvandine> i can revert that one
[15:59] <pitti> I see how it is beneficial
[15:59] <pitti> but _if_ a user is in that situation of having multiple keys, and the older one happens to be the correct one, then it'll regress for him
[15:59] <kenvandine> i just think it is more likely to help than hurt
[15:59] <pitti> certainly
[15:59] <dobey> pitti: i think regression potential is low; it's certainly not reintroducing any old/broken behavior
[15:59] <pitti> but "fixes bugs for more people than it regresses for" is not an acceptable SRU criterion
[16:00] <kenvandine> pitti, ok, i'll revert that
[16:00] <pitti> kenvandine: the other bits looked fine indeed
[16:00] <pitti> thanks!
[16:00] <dobey> afaik, you would have to explicitly write broken code, for that case to even happen
[16:00] <kenvandine> pitti, thanks for weighing in :)
[16:01] <pitti> dobey: right; but the fix applies to those very applications
[16:01] <pitti> so if we would assume that there are none, we wouldn't need the fix in the first place :)
[16:01] <dobey> well the fix fixes other issues
[16:02] <dobey> assuming there are no applications broken in that way doesn't impact that
[16:02] <kenvandine> dobey, but nothing we have a bug reference for
[16:02] <dobey> kenvandine: does it not fix a bug filed upstream?
[16:02] <kenvandine> nope
[16:02] <kenvandine> nothing listed
[16:02] <pitti> anyway, I don't have a hard veto against this, it just seems utterly hard to verify and the fix isn't that important for an SRU
[16:03] <dobey> oh :-/
[16:03] <dobey> bad upstreams! :)
[16:03] <pitti> I'd rather get the other fix into -updates to unblock U1
[16:03] <kenvandine> yeah
[16:03]  * kenvandine will make it so
[16:04] <dobey> maybe it was a bug report only filed in stefw's head; "oh this is broken bad, i'll fix it" :)
[16:07] <pitti> ... which is great :)
[16:33] <lool> cjwatson: Hmm grub fails to install on an ext4 /boot here (configured to install on /dev/sda2 ext4 instead of MBR); is this a bug?
[16:33] <lool> (I know it's documented as fragile to start with)
[16:35] <cjwatson> lool: possibly a bug, depending on the nature of the failure
[16:35] <cjwatson> the fragility is normally in terms of staying installed rather than being installed in the firt place, though
[16:35] <lool> cjwatson: I didn't find the error in the debug messages going to syslog
[16:36] <lool> actually the error is that it can't read /grub/core.img correctly
[16:36] <lool> in French
[16:36] <lool> /usr/sbin/grub-setup : erreur : impossible de lire `/grub/core.img' correctement.
[16:36] <cjwatson> -vv
[16:37] <cjwatson> err, that was a bit terse
[16:37] <cjwatson> use grub-install --debug to find the grub-setup command it's running, then run that with the -vv option added
[16:37] <cjwatson> it may indicate a bug in grub's ext4 code
[16:38] <lool> cjwatson: http://paste.debian.net/147319/
[16:39] <lool> from LC_ALL=C /usr/sbin/grub-setup -vv --directory=/boot/grub --device-map=/boot/grub/device.map /dev/sda2
[16:40] <cjwatson> hm, that's not what I expected
[16:40] <cjwatson> add --force
[16:41] <lool> Yes
[16:41] <cjwatson> (you probably should have started with grub-install --debug --force)
[16:41] <cjwatson> which is what grub-pc.postinst uses
[16:42] <lool> hmm paste borken
[16:42] <lool> http://paste.ubuntu.com/752638/
[16:44] <lool> I will try unmounting and remounting /boot
[16:45] <lool> worked
[16:45] <lool> cjwatson: So it's fixed for me, but maybe I've lost interesting data on the bug
[16:46] <lool> I just did umount /boot; mount /boot (no error in both cases) and the bug went away  :-/
[16:47] <cjwatson> I wonder if it's a lack of fsync et al
[16:47] <cjwatson> hm, grub-mkimage fsyncs
[16:47] <cjwatson> does it have to fsync the directory as well or something?  I hate ext4
[16:48] <lool> can you just sync all buffers?
[16:48] <cjwatson> IIRC that doesn't guarantee what you'd like, and in any case can have horrible performance characteristics
[16:48] <cjwatson> rather not
[16:49] <cjwatson> I don't know what to do here :-/
[16:51] <lool> I will take a snapshot of the FS if it happens again; sorry  :-/
[16:59]  * tgall_foo looks for doko
[18:03] <zul> Riddell: ping
[18:13] <SpamapS> slangasek: any thoughts on myodbc ?
[18:13] <SpamapS> slangasek: seems like we have to package the new one in order to support mysql 5.5
[18:15] <om26er> stgraber, Hi! Can you please sponsor this https://code.launchpad.net/~om26er/ubuntu/precise/indicator-sound/fix-864405/+merge/83659
[18:17] <seb128> kenvandine, ^
[18:17] <seb128> om26er, you might want to just ping ken about indicator uploads
[18:18] <stgraber> om26er: I was actually going to @pilot out just about now :) Would be great if kev could have a look as I'm really not too familiar with these anyway
[18:19] <om26er> stgraber, alright i guess ken would do the sponsoring
[18:19] <om26er> seb128, surely will ask ken for future :-)
[18:21] <om26er> seb128, btw i have the branch for both precise and oneiric now (about indicator-sound)
[18:22] <om26er> also i pulled the compiz-plugins vcs added patches but didnt find a way to propose to it
[18:23] <seb128> om26er, what do you mean?
[18:23] <kenvandine> om26er, i'll do it
[18:23] <stgraber> kenvandine: thanks
[18:23] <stgraber> @pilot out
[18:23] <seb128> om26er, the destination vcs shouldn't make a difference
[18:23] <kenvandine> stgraber, np
[18:24] <om26er> seb128, i pulled lp:~compiz/compcomm-plugins-main/ubuntu added my patches
[18:24] <om26er> now where should i propose?
[18:24] <alexbligh1> Daviey, ping
[18:24] <seb128> om26er, where,how do you propose usually?
[18:25] <om26er> lp:ubuntu/pkgname
[18:25] <seb128> om26er, do you use the web ui, a bzr command usually?
[18:26] <seb128> it should work the same way...
[18:26] <om26er> webui
[18:26] <om26er> should i propose to lp:ubuntu/oneiric-proposed/compiz-plugins-main
[18:26] <om26er> ?
[18:27] <seb128> om26er, the webui should ask you what the target vcs, you can set lp:~compiz/compcomm-plugins-main/ubuntu no?
[18:27] <dobey> generally you propose to the branch you pulled from
[18:27] <om26er> seb128, proposing to lp:~compiz/compcomm-plugins-main/ubuntu give error
[18:27] <om26er> "there is 1 error"
[18:28] <seb128> hum, dunno then, that should work, maybe a question for #launchpad
[18:39] <l3on> Hi SpamapS .. around?
[18:39] <l3on> I'm working on mydboc ... that FTBFS in precise due to libmysqlclient changes...
[18:40] <l3on> It seems that last upstream release (5.1.9) has solved the problem (using x_free()), we can ask for update it in debian ?
[18:43] <Laney> l3on: slangasek is the maintainer of that package
[18:43] <SpamapS> l3on: I sent an email to slangasek suggesting exactly that
[18:44] <SpamapS> l3on: there was some other problem but I forget what it was.
[18:44] <l3on> so, what should we do? :)
[18:44] <SpamapS> l3on: Actually now I remember.. I couldn't get 5.1.9 building with autotools..
[18:45] <SpamapS> l3on: before I went too far down the rabbit hole I figured I'd ask slangasek
[18:45] <l3on> ah ok :)
[18:45] <SpamapS> l3on: its one of the last stubborn pieces of the libmysqlclient transition. :)
[18:46]  * slangasek mutters darkly
[18:46] <Daviey> alexbligh1: hey
[18:46] <slangasek> SpamapS: yeah, I'll try to pull the new upstream version in this week and give it a go
[18:47] <l3on> slangasek, , great! :)
[18:47] <SpamapS> slangasek: the failure in autotools (which is lost to 1000 other things in my backscrolls and logs) was pretty strange.. it struck me that mysql doesn't really care much about portable builds
[18:47] <slangasek> heh
[18:50] <SpamapS> dh_auto_configure picked up the CMakeLists and I had to explicitly tell it to use autoconf
[18:50] <SpamapS> but maybe I should have let it try to use cmake.. hm
[18:53] <alexbligh1> Daviey, hi - I got back from my meeting - eventually - we were going to have achat with smb
[18:53] <Daviey> alexbligh1: I suspect smb is offline now.. :(
[18:54] <dobey> which thing should i file a bug against for popping up the "Your version of Ubuntu is EOL" dialog when i do "sudo update-manager -d" on oneiric? update-manager?
[18:54] <micahg> dobey: already filed
[18:55] <dobey> ok
[18:55] <alexbligh1> Daviey, indeed. I added a couple of patches to LP #886521. I think the Oneiric and Natty one is right, but since Boris's comment, I think the problem with Lucid and Maverick might be something different.
[18:55] <dobey> and what about the "extras" repo not existing for precise?
[18:56] <alexbligh1> Daviey, smb is in DE (thus on CET), yes?
[18:57] <Daviey> alexbligh1: right..
[18:58] <Daviey> alexbligh1: The server team have their meeting at 16:00 (UK) time tomorow, smb has a section about the kernel there.  I'll peg in a discussion about this.
[18:58] <Daviey> (you are welcome to the meeting if you can attend)
[18:58] <alexbligh1> yep I might indeed be able to make that.
[19:00] <alexbligh1> I shall see if I can get the guys in Scotland to duplicate the Lucid/Maverick problem too. It's hard from down here as I need a physical machine to test it on (someone should get Xen running inside KVM :-) )
[19:00] <Daviey> alexbligh1, rocking, see you at 16:00 in #ubuntu-meeting
[19:03] <debfx> zul: the last openldap upload build-depends on heimdal-dev despite what the changelog says (and libldap-2.4-2 picked up a new dependency)
[19:03] <zul> debfx: k ill fix it
[19:09] <dobey> who owns the extras archive, and why does the updater depend on it?
[19:12] <stgraber> dobey: the ARB, not sure what you mean by depends, I guess it'd fail on a 404, yes, though it doesn't use any package from it (unless you installed something from extras obviously)
[19:12] <stgraber> dobey: what's the problem exactly?
[19:13] <dobey> stgraber: trying to upgrade from oneiric to precise with update-manager -d, and it fails because the extras archive seems to not exist for precise (404)
[19:13] <dobey> i don't think i have installed anything from it; i don't even know what is in that archive
[19:13] <stgraber> dobey: hmm, that's weird, I thought I fixed that one
[19:14] <stgraber> dobey: hmm, apparently it's extras.u.c is broken indeed, let me check if it's my fault or IS' :)
[19:14] <dobey> stgraber: thanks
[19:14] <stgraber> looks like it's IS', poking them now
[19:17] <SpamapS> weird, why are our i386 builds faster than amd64 builds?
[19:21] <bdrung> tumbleweed: re u-d-t. why do we have a loop "for sub in bug.subscriptions:" instead of an if expression?
[19:31] <kees> hallyn: if you're happy with segoon's patch for Yama, I'm going to go ahead and take it.
[19:36] <wyuka> any wubi devels around?
[19:37] <tgall_foo> doko ping
[19:38] <hallyn> kees: thanks, i hd asked him to resend and i was just going to ack it.  so pls feel free to add 'Acked-by: Serge Hallyn <serge.hallyn@ubuntu.com>"
[19:39] <kees> hallyn: okay, cool
[19:51] <tumbleweed> bdrung: because that's how you get at the subscription object?
[19:53] <bdrung> tumbleweed: isn't it possible to do a check like "ubuntu-sponsors in bug.subscriptions"?
[19:55] <tumbleweed> bdrung: bug.subscriptions gives you subscription objects, one of which may have the subscriber we want
[19:56] <bdrung> tumbleweed: is there no way to make this query shorter?
[19:56] <tumbleweed> bdrung: one can go straight to that subscription by writing the url for that bug_subscription (and catching 404)
[19:56] <tumbleweed> bdrung: that's what the first approach was doing, but I vetoed it because it was using a hard-coded base URL
[19:57] <bdrung> yes, and it sounds hacky
[20:30] <jdstrand> mterry: hey, did you get whatever you needed re ruby-flexmock (sorry I was off friday)
[20:31] <mterry> jdstrand, yeah, cjwatson sorted me out, thanks
[20:31] <jdstrand> great
[20:31] <jdstrand> :)
[20:39] <YokoZar> stgraber: Has there been discussion of extending Lintian to make a profile specifically for -extras?  (Eg, instead of the rule prohibiting /opt, we'd want the inverse)
[20:45] <stgraber> YokoZar: I think it was discussed yes, I don't think we have a detailed spec or work items for that though
[20:45] <stgraber> YokoZar: but that's definitely something that'd be useful for packages targeting the ARB process and for us reviewers
[20:45] <YokoZar> stgraber: yeah extending Lintian definitely counts as work,
[20:46] <YokoZar> stgraber: a profile however might be pretty quick to make and then you can just run lintian with a switch
[20:56] <YokoZar> http://www.google.com/trends?q=ubuntu+wireless%2C+ubuntu+wine%2C+ubuntu+sound%2C+ubuntu+flash&ctab=0&geo=all&date=all&sort=0  <-- Some graphs showing the relative googling for ubuntu + wireless, sound, flash, and wine
[20:57] <YokoZar> They've all declined, although by roughly the same proportion that Ubuntu searches themselves have declined.  Perhaps more interesting is that the relative ratio of flash queries has dropped significantly.  Perhaps we got it right this time :)
[21:06] <cjwatson> hallyn: hmm, I don't understand https://launchpadlibrarian.net/86106782/qemu-kvm_0.15.0%2Bnoroms-0ubuntu3_0.15.0%2Bnoroms-0ubuntu4.diff.gz - were there accidental changes in theree?
[21:06] <cjwatson> hallyn: it seems to have moved things back to qemu-kvm!
[21:07] <cjwatson> hallyn: so now qemu-utils is empty - I'm not sure I see the point
[21:16] <rdesfo> Hello, I'm having an issue with my ubuntu terminal.
[21:17] <rdesfo> When I log in regularly the "lower case a" is not recognized.  But I can su to another user or sign in as guest and it works fine
[21:17] <rdesfo> doesn't any one know if there is a config file I can remove to resolve this?
[21:45] <adam_g> RoAkSoAx: MP incoming

[21:46] <cjwatson> hallyn: if you want to move stuff back to qemu-utils, remember that you have to bump the Breaks/Replaces versions again ...
[21:48] <hallyn> to .4 bc upgrades won't have done it now, right?
[21:48] <cjwatson> because qemu-kvm 0.15.0+noroms-0ubuntu4 is in the archive on non-i386 architectures and delivers qemu-img and qemu-nbd
[21:49] <cjwatson> (i386 is in NEW, which is why I noticed this)
[21:49] <hallyn> understoos, thx
[21:49] <hallyn> understood, that is
[21:49] <cjwatson> I'm happy to review a source package pre-upload if you want another check
[21:50] <hallyn> sigh, thx, maybe i'd best.  it won't be for a few hourfs though.
[21:50] <RoAkSoAx> adam_g: MP?
[21:51] <cjwatson> I can just prepare it myself if you like, although I don't know what your VCS arrangements are
[21:52] <hallyn> it won't throw me off, (i just pull-lp-source every time) so that'd be great
[21:52] <cjwatson> OK, let me go hunt things down
[21:53] <RoAkSoAx> adam_g: your branch has conflicts apparently
[21:53] <cjwatson> hallyn: just to check, can I confirm that you only meant to put the extra Breaks/Replaces in that latest upload, and nothing else?
[21:54] <RoAkSoAx> adam_g:
[21:54] <RoAkSoAx> Diff: 4572 lines (+4162/-0) 66 files modified (has conflicts)
[21:54] <cjwatson> and yeah, pull-lp-source is love
[21:54] <hallyn> cjwatson: nothing else!  (sob)
[22:14] <Daviey> hallyn: Soft-freeze for a1 is now live... Makes sense to wait until end of week to remove etherboot?
[22:14] <Daviey> Doesn't seem to be something we need to acquire a freeze request for, right?
[22:17] <hallyn> Daviey: sure
[22:42] <SpamapS> arghhh
[22:42]  * SpamapS throws things as he finds a patched configure script without the patched configure.in in ulogd
[22:43]  * SpamapS calms down as he actually *does* find the patched configure.in
[22:43] <SpamapS> doh
[22:43]  * SpamapS will have to replace that window. ;)
[22:44] <rdesfo> does ubuntu have something like fedora's revisor application to customize distro?
[23:28] <SpamapS> hah.. wow..mass rebuilds do wonders for one's launchpad karma
[23:28]  * SpamapS notices it has doubled in the past 2 weeks
[23:35] <sontek> I'm trying to build marlin file manager and varka out of bzr, is this the proper place to come to discuss that? Or should I just mail their lists?
[23:35] <poolie> sontek, i think here is ok
[23:36] <sontek> When I make install varka I get: http://paste2.org/p/1801495
[23:37] <sontek> Its right that the file doesn't exist anywhere in the repo before or after building but not sure why it wants it
[23:38] <RAOF> Urgh.  cmake.
[23:38] <poolie> not obvious to me
[23:38] <RAOF> sontek: I'd guess you're missing a dependency, and cmake is helpfully not building the gir for you.
[23:38] <sontek> RAOF: yeah, both varka and marlin use cmake
[23:41] <sontek> RAOF: ahh, you are right, the building of it with 'make' says 'missing ... ' in between a bunch of successes :) I didn't have gobject-introspection
[23:41] <RAOF> File a bug with them; their build system is broken.
[23:42] <sontek> Yeah, I wish I knew more about their build system because thats what i'm having an issue with on marlin
[23:42] <sontek> its complaining I don't have 2 libraries, Varka, and some headers that come with gtk3-devel
[23:43] <sontek> I just installed Varka and have gtk3-devel
[23:43] <cjwatson> hallyn: sorted now
[23:45] <sontek> I even tried settings CFLAGS before running make to point it in the right direction
[23:47] <RAOF> I have no idea if cmake respects CFLAGS :)
[23:47] <RAOF> This has probably drifted off topic for #ubuntu-devel, and you'll likely get better information from their devel channels.
[23:51] <hallyn> cjwatson: thanks