[01:32] <psusi> ugh.... and they left the quilt patches applied in the debian lvm2 bzr branch
[01:34] <lamalex> Hey devs, I know there's a command to get the packing for a package out of source control, but i can't remember and google is failing
[01:34] <lamalex> anyone know off hand?
[01:34] <psusi> apt-get source
[01:34] <lamalex> psusi, that's not from version control
[01:34] <lamalex> that's from the archive
[01:35] <psusi> yep... vc would depend on what vc, if any, a package is using
[01:47] <ebroder> psusi: That's the way that UDD works with 3.0 (quilt) packages, because it imports the unpacked source tree, and unpacking a 3.0 (quilt) package applies the patches
[01:50] <psusi> ebroder, eh?  if the bzr repo contains the quilt patch, surly it should not already be applied?
[01:50] <psusi> the whole point is to keep it separate from the upstream source
[01:51] <ebroder> psusi: When you do dpkg-source -x on a 3.0 quilt package, it applies the patches
[01:51] <ebroder> And UDD imports basically dpkg-source -x; bzr add
[01:51] <psusi> right... but when you do a bzr branch, they should not be applied already
[01:52] <ebroder> I don't think that's obviously true
[01:52] <psusi> seems like it to me... when you bzr builddeb, it makes sure the source is clean and all patches are removed, then builds a source package, doesn't it?
[01:53] <psusi> so when you check it out of the repository, it should already be clean and have no patches applied
[01:53] <ebroder> I don't think the ordering is quite that obvious with 3.0 packages
[01:53] <psusi> huh?  ordering is what the series file is for?
[01:53] <psusi> but when you make a source package, no patches are applied
[01:54] <ebroder> No, I'm saying that you don't remove the patches, *then* build the source package. Removing the patches is *part* of the build-the-source-package process
[01:54] <psusi> well, yea... I suppose...
[01:54] <psusi> it makes sure to remove them in case you forgot
[01:54] <psusi> but I would think that the natural state of the bzr repository should be to not have them applied
[01:54] <psusi> i.e. be clean
[01:54] <ebroder> I think one of the files in debian/source/ specifies what the natural state should be
[01:55] <ebroder> But I think the default is that the resting state is with patches applied
[01:55] <psusi> hrm.... that's goofy, since it complicates the merge process since you have to remember to remove them first
[01:56] <ebroder> Or alternatively, the next time you build the package, it'll create a new patch, and you roll that into other patches as appropriate
[01:56] <psusi> huh?
[01:57] <ebroder> I'm not actually sure what I mean. But patches applied is definitely the resting state of the package
[01:59] <psusi> this is driving me nuts because when I bzr merge the debian version into ours, they have patches already applied and we don't
[01:59] <ebroder> Well why don't we have the patches applied? If our package is 3.0, too, it should have patches applied
[01:59] <psusi> so how am I supposed to review the quilt patches when they are already applied?  I have to remove them first, then review/merge/refresh the patches
[02:00] <psusi> why?
[02:01] <psusi> I thought 3.0 just meant it used quilt patches, not that they are already applied in the source package?
[02:02] <psusi> the whole point of the source package format as I understand it is that no modifications are done to the upstream files, but rather they are kept aside in the debian/ directory to facilitate replacing the upstream files with a new release
[02:13] <ebroder> I mean, modifications are going to be done to the upstream files at some point, so arguing about when is to some extent mincing words. But as I understanding it, unpacking a 3.0 (quilt) package by definition of the format involves applying the quilt patches
[02:15] <ebroder> s/(understand)ing/$1/
[02:23] <MattJ> echo "understanding" | sed 's/\(understand\)ing/\1/'
[02:23]  * MattJ sneaks off to bed quickly
[02:24] <ebroder> MattJ: echo "understanding" | perl -pe 's/(understand)ing/$1/'
[02:24] <ebroder> :-P
[02:24] <MattJ> .
[02:25] <MattJ> should have known
[06:25] <bilalakhtar> Can non-core-devs be patch pilots?
[06:25] <ebroder> Of course! Patch piloting is only partially about sponsorship
[06:32] <ebroder> One of the most important things you can do as a patch pilot is make sure that patches are in good shape for the people who can do sponsoring
[06:43] <bilalakhtar> It was cool to see pitti come around and sponsor a UDD patch that I published 5 months ago during the maverick cycle. pitti also updated it to fit the natty package, cool! I had almost ignored the patch completely
[06:43] <bilalakhtar> s/UDD\ patch/UDD\ merge/
[07:08] <ebroder> SpamapS: wtf did you do to this mongodb package?
[07:11] <SpamapS> ebroder: ?? I wish I knew
[07:11] <SpamapS> ebroder: talking about the lucid backport to use the wrapper?
[07:11] <ebroder> Yeah
[07:12] <SpamapS> (which is, BTW, the dumbest thing ever... I really hate that we don't just dump libmozjs.so in /usr/lib :-P
[07:12] <SpamapS> )
[07:13] <ebroder> It's annoying me that it's the only package for universe in the sponsors queue, and now it's annoying me that I have *no* clue what the heck is going on, so we'll see if I can manage to channel my annoyance productively
[07:13] <SpamapS> ebroder: it works on my sbuild and pbuilder, and a clean ec2 lucid instance
[07:13] <ebroder> Yeah, same for me
[07:13] <ebroder> (Well, I didn't try EC2, but I'll take your word for it
[07:13] <SpamapS> I asked in #launchpad but got no response
[07:14] <ebroder> I'm starting to suspect that something about the usr/bin/mongo symlink is broken as soon as it's created
[07:14] <ebroder> Hopefully I'll be able to tell from https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066069
[07:14] <SpamapS> thats just the first one
[07:14] <ebroder> No, the others all look fine - that one isn't actually a symlink by the time dh_link is done with it
[07:14] <SpamapS> I was thinking maybe the buildd's might not have the right version of tar
[07:15] <ebroder> Check out the build log from https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066064 - I added a bunch of debugging printouts
[07:16] <SpamapS> ebroder: btw, this patch pilot thing is *amazing* .. have seen more in depth reviews and sponsorship in 5 days than in 6 months of Ubuntu work prior
[07:16] <SpamapS> ebroder: so thanks. :)
[07:17] <SpamapS> ebroder: OH WEIRD.. why isn't it a symlink?!
[07:17] <ebroder> SpamapS: That is a *fantastically* good question
[07:18] <SpamapS> ebroder: also why does everything show up like 5 times in the debug build?
[07:19] <ebroder> You mean the rm -f ...; ln -sf ... lines? dh_link goes through and "fixes" every symlink every time it runs
[07:19] <ebroder> So it creates /usr/bin/mongo. Then it creates /usr/bin/mongod and fixes /usr/bin/mongo. Then it creates ...
[07:19] <ebroder> (Except that something is screwed up with /usr/bin/mongo)
[07:20] <SpamapS> ebroder: weird!
[07:20] <SpamapS> ebroder: so might be better to create a manual .links file.. I just wanted to make sure I got everything.
[07:21] <SpamapS> ugh
[07:21] <SpamapS> something is wonky about my keyboard/mouse
[07:21] <ebroder> Maybe. Although it wouldn't really be bad enough to care about if it was actually working, and I'm not convinced that changing how you create the symlinks will fix the issue
[07:23] <SpamapS> brb.. trying to correct my keboard/touchpad weirdness
[07:28]  * SpamapS really has to get the multitouch driver going.. the extra taps from the synaptics driver are driving me NUTS
[07:40] <SpamapS> ebroder: doh stat: cannot stat `/build/buildd/mongodb-1.2.2/debian/mongodb/usr/bin/mongo': No such file or directory
[07:41] <SpamapS> ebroder: thats after the files have been moved to /usr/lib/mongodb
[07:41] <ebroder> SpamapS: Yeah, uploaded a new build and fixed that
[07:41] <ebroder> (https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066075)
[07:43] <ebroder> Oh, and screwed it up again. But still - usr/bin/mongo is a file coming out of that first dh_link
[07:48] <SpamapS> ebroder: you should do 'file' on it too while you're hot. ;)
[07:49] <ebroder> I'm pretty sure it's just a plain file with the contents "../lib/mongodb/xulwrapper"
[07:50] <ebroder> I mean, a symlink is just a file with weird flags whose contents are the target of the link, even if it's not really exposed that way
[07:50] <SpamapS> that would be *the suck*
[07:51] <ebroder> The file is the right size for it to be that
[07:51] <SpamapS> I suppose it could be an aufs bug.. do the buildd's use aufs like sbuild on our boxes?
[07:51] <SpamapS> argh, this is so weird.. alt-tab just stops working for no reason
[07:54] <ebroder> aufs bug would be interesting, but it would be *so* weird to be consistently reproducable for this build and only this symlink but not for anything else
[07:56] <SpamapS> ebroder: agreed. It might be worth it to build a package that just does dh_link calls and then exits as a test case.
[08:00] <ebroder> SpamapS: If it was a aufs thing, I would think that installing plain files into /usr/bin then moving them out, then creating symlinks might trigger it
[08:01] <ebroder> Actually, I'm going to try something...
[08:46] <ebroder> SpamapS: Alright, I got something for you: http://pastebin.com/EXS4a65j
[08:46] <ebroder> Test build worked: https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066096
[09:21] <SpamapS> ebroder: interesting
[09:21] <SpamapS> ebroder: this still suggests a possible aufs bug.. rename then create symlink in place causes fail.. ?
[09:22] <ebroder> SpamapS: I, uh, remembered seeing a comment about a bug like that somewhere in initramfs-tools, so figured I'd give it a go
[09:23] <SpamapS> ebroder: cool.. thanks for lending a keen and capable pair of eyes to it!
[09:23] <SpamapS> ebroder: applying your patch and re-pushing
[09:29] <ebroder> SpamapS: Cool. Let me know and I'll sponsor it?
[09:35] <SpamapS> ebroder: I pushed it already, should be updated in the MP
[09:38] <ebroder> SpamapS: Ok, cool. Looks good to me. I'm going to add the set -e Stefano mentioned, and then I'll upload
[09:47] <SpamapS> ebroder: right, cool!
[10:42] <NCommander> cjwatson: ugh, will fix
[10:51] <ebroder> NCommander: Is mame good to go? It's the last {uni,multi}verse package in the queue :)
[10:51] <NCommander> ebroder: I got sidetracked on that
[10:52]  * NCommander got sucked into visiting home >.<;
[10:52] <NCommander> on my TODO list as w espeak
[10:52] <ebroder> Awesome
[11:53] <ari-tczew> could any admin reject clementine in natty NEW? I uploaded it by mistake. (dput ubuntu instead ppa)
[13:28] <alex88> Hi, i've got a kernel patch to fix bug 658521. How do i test to see if it works? I'm rebuilding ubuntu kernel and going to test it. Is that the right way?
[14:21] <alex88> no one?
[14:22] <BlackZ> !weekend | alex88
[14:28] <alex88> oh..:) right..thank you BlackZ :)
[14:29] <penguin42> alex88: Oh you found a patch?
[14:32] <alex88> penguin42, sata kernel developer given to me
[14:32] <alex88> i've added to the bug report
[14:32] <penguin42> alex88: I tend to follow https://help.ubuntu.com/community/Kernel/Compile   , and yes building the kernel should be a good way to try - won't help on install though
[14:32] <alex88> now compiling patched kernel
[14:32] <alex88> penguin42, can't do on that..the board_ahci_yes_fbs isn't declared on older kernel.. i'm building lastest development version
[14:33] <penguin42> ah right
[14:33] <alex88> btw, it should build headers and image deb so i can test on usb installed ubuntu if it see the hdd
[14:34] <alex88> also i've set bug as confirmed.. after testing if it works what to do?
[14:36] <penguin42> alex88: Not too sure; you could try asking on #ubuntu-kernel, the bug should gain a patch tag automatically I think; can you set 'nominate for natty' - I can't see the botton at the moment
[14:36] <alex88> np :)
[14:39] <penguin42> alex88: In that bug it's probably right to be clearer about exactly who gave you the patch
[14:40] <alex88> penguin42, Tejun Heo <htejun@gmail.com> from linux-ide@vger.kernel.org
[14:41] <penguin42> yeh, just say that in the bug - it's always good to be able to trace patches
[14:41] <alex88> done
[14:55] <crimsun> alex88: as a note, that patch needs to land in Linus's tree and linux-2.6.36.y.git (stable) for the SRU
[15:06] <penguin42> in which case the thing to do is to test it and confirm it works; Tejun's message says it's a blind patch without testing - so if it works and you can give it a good test let Tejun know, and maybe he can push it or do a bit more investigation
[15:07] <crimsun> it would just follow normal commit procedure: Reported-and-tested-by: alex88   .. etc.
[15:16] <nigelb> crimsun: Morning :-)
[15:17] <crimsun> nigelb: hi
[15:17] <nigelb> crimsun: Nice to see you around after long
[15:25] <cjwatson> who runs http://reports.qa.ubuntu.com/reports/sponsoring-stats/?  it would be awfully nice if the graphs' y-axis started at 0
[15:25] <cjwatson> non-0-based graphs are more usually used for statistical distortions to make a point :-)
[15:27] <nigelb> cjwatson: that's probably bdmurray's territory
[15:29]  * penguin42 is surprised that isn't one of the entries in '13 ways to say nothing in scientific visualisation'
[17:01] <bilalakhtar> doko: Can I work on the gcc-4.3 merge?
[17:06] <bilalakhtar> doko: ignore it, you have been uploading since a long time, leave it
[17:06] <bilalakhtar> I mean, ignore my previous message on taking the merge
[17:15] <bdrung> stgraber: pastebinit to paste.debian.net doesn't work any more. it outputs "http://paste.debian.net/"
[19:01] <RenatoSilva> how to undo apt-get build-dep?
[19:12] <ebroder> Of the releases that are still supported, Dapper and Hardy use usplash, Karmic uses xsplash, and everything newer uses plymouth, right?