[01:32] ugh.... and they left the quilt patches applied in the debian lvm2 bzr branch [01:34] 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] anyone know off hand? [01:34] apt-get source [01:34] psusi, that's not from version control [01:34] that's from the archive [01:35] yep... vc would depend on what vc, if any, a package is using [01:47] 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] ebroder, eh? if the bzr repo contains the quilt patch, surly it should not already be applied? [01:50] the whole point is to keep it separate from the upstream source [01:51] psusi: When you do dpkg-source -x on a 3.0 quilt package, it applies the patches [01:51] And UDD imports basically dpkg-source -x; bzr add [01:51] right... but when you do a bzr branch, they should not be applied already [01:52] I don't think that's obviously true [01:52] 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] so when you check it out of the repository, it should already be clean and have no patches applied [01:53] I don't think the ordering is quite that obvious with 3.0 packages [01:53] huh? ordering is what the series file is for? [01:53] but when you make a source package, no patches are applied [01:54] 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] well, yea... I suppose... [01:54] it makes sure to remove them in case you forgot [01:54] but I would think that the natural state of the bzr repository should be to not have them applied [01:54] i.e. be clean [01:54] I think one of the files in debian/source/ specifies what the natural state should be [01:55] But I think the default is that the resting state is with patches applied [01:55] hrm.... that's goofy, since it complicates the merge process since you have to remember to remove them first [01:56] 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] huh? [01:57] I'm not actually sure what I mean. But patches applied is definitely the resting state of the package [01:59] 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] Well why don't we have the patches applied? If our package is 3.0, too, it should have patches applied [01:59] 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] why? [02:01] I thought 3.0 just meant it used quilt patches, not that they are already applied in the source package? [02:02] 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] 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] s/(understand)ing/$1/ [02:23] echo "understanding" | sed 's/$understand$ing/\1/' [02:23] * MattJ sneaks off to bed quickly [02:24] MattJ: echo "understanding" | perl -pe 's/(understand)ing/$1/' [02:24] :-P [02:24] . [02:25] should have known === asac_ is now known as asac === nigelbabu is now known as nigelb [06:25] Can non-core-devs be patch pilots? [06:25] Of course! Patch piloting is only partially about sponsorship [06:32] 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] 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] s/UDD\ patch/UDD\ merge/ [07:08] SpamapS: wtf did you do to this mongodb package? [07:11] ebroder: ?? I wish I knew [07:11] ebroder: talking about the lucid backport to use the wrapper? [07:11] Yeah [07:12] (which is, BTW, the dumbest thing ever... I really hate that we don't just dump libmozjs.so in /usr/lib :-P [07:12] ) [07:13] 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] ebroder: it works on my sbuild and pbuilder, and a clean ec2 lucid instance [07:13] Yeah, same for me [07:13] (Well, I didn't try EC2, but I'll take your word for it [07:13] I asked in #launchpad but got no response [07:14] I'm starting to suspect that something about the usr/bin/mongo symlink is broken as soon as it's created [07:14] Hopefully I'll be able to tell from https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066069 [07:14] thats just the first one [07:14] No, the others all look fine - that one isn't actually a symlink by the time dh_link is done with it [07:14] I was thinking maybe the buildd's might not have the right version of tar [07:15] Check out the build log from https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066064 - I added a bunch of debugging printouts [07:16] 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] ebroder: so thanks. :) [07:17] ebroder: OH WEIRD.. why isn't it a symlink?! [07:17] SpamapS: That is a *fantastically* good question [07:18] ebroder: also why does everything show up like 5 times in the debug build? [07:19] You mean the rm -f ...; ln -sf ... lines? dh_link goes through and "fixes" every symlink every time it runs [07:19] So it creates /usr/bin/mongo. Then it creates /usr/bin/mongod and fixes /usr/bin/mongo. Then it creates ... [07:19] (Except that something is screwed up with /usr/bin/mongo) [07:20] ebroder: weird! [07:20] ebroder: so might be better to create a manual .links file.. I just wanted to make sure I got everything. [07:21] ugh [07:21] something is wonky about my keyboard/mouse [07:21] 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] 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] ebroder: doh stat: cannot stat `/build/buildd/mongodb-1.2.2/debian/mongodb/usr/bin/mongo': No such file or directory [07:41] ebroder: thats after the files have been moved to /usr/lib/mongodb [07:41] SpamapS: Yeah, uploaded a new build and fixed that [07:41] (https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066075) [07:43] Oh, and screwed it up again. But still - usr/bin/mongo is a file coming out of that first dh_link [07:48] ebroder: you should do 'file' on it too while you're hot. ;) [07:49] I'm pretty sure it's just a plain file with the contents "../lib/mongodb/xulwrapper" [07:50] 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] that would be *the suck* [07:51] The file is the right size for it to be that [07:51] I suppose it could be an aufs bug.. do the buildd's use aufs like sbuild on our boxes? [07:51] argh, this is so weird.. alt-tab just stops working for no reason [07:54] 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] 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] 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] Actually, I'm going to try something... [08:46] SpamapS: Alright, I got something for you: http://pastebin.com/EXS4a65j [08:46] Test build worked: https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066096 [09:21] ebroder: interesting [09:21] ebroder: this still suggests a possible aufs bug.. rename then create symlink in place causes fail.. ? [09:22] 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] ebroder: cool.. thanks for lending a keen and capable pair of eyes to it! [09:23] ebroder: applying your patch and re-pushing [09:29] SpamapS: Cool. Let me know and I'll sponsor it? [09:35] ebroder: I pushed it already, should be updated in the MP [09:38] SpamapS: Ok, cool. Looks good to me. I'm going to add the set -e Stefano mentioned, and then I'll upload [09:47] ebroder: right, cool! [10:42] cjwatson: ugh, will fix === ogra_ is now known as ogra [10:51] NCommander: Is mame good to go? It's the last {uni,multi}verse package in the queue :) [10:51] ebroder: I got sidetracked on that [10:52] * NCommander got sucked into visiting home >.<; [10:52] on my TODO list as w espeak [10:52] Awesome === ogra_ac_ is now known as ogra_ac [11:53] could any admin reject clementine in natty NEW? I uploaded it by mistake. (dput ubuntu instead ppa) [13:28] 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? [13:28] Launchpad bug 658521 in linux (Ubuntu) "In Live session or installation HD not recognized" [Undecided,Confirmed] https://launchpad.net/bugs/658521 [14:21] no one? === Richie_ is now known as WelshDragon [14:22] !weekend | alex88 [14:22] alex88: It's a weekend. Often on weekends the paid developers and a lot of the community may not be around to answer your question. Please be patient, wait longer than you normally would or try again during the working week. [14:28] oh..:) right..thank you BlackZ :) [14:29] alex88: Oh you found a patch? [14:32] penguin42, sata kernel developer given to me [14:32] i've added to the bug report [14:32] 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] now compiling patched kernel [14:32] 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] ah right [14:33] btw, it should build headers and image deb so i can test on usb installed ubuntu if it see the hdd [14:34] also i've set bug as confirmed.. after testing if it works what to do? [14:36] 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] np :) [14:39] alex88: In that bug it's probably right to be clearer about exactly who gave you the patch [14:40] penguin42, Tejun Heo from linux-ide@vger.kernel.org [14:41] yeh, just say that in the bug - it's always good to be able to trace patches [14:41] done [14:55] 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] 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] it would just follow normal commit procedure: Reported-and-tested-by: alex88 .. etc. [15:16] crimsun: Morning :-) [15:17] nigelb: hi [15:17] crimsun: Nice to see you around after long [15:25] 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] non-0-based graphs are more usually used for statistical distortions to make a point :-) [15:27] 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' === MattJ100 is now known as MattJ [17:01] doko: Can I work on the gcc-4.3 merge? [17:06] doko: ignore it, you have been uploading since a long time, leave it [17:06] I mean, ignore my previous message on taking the merge [17:15] stgraber: pastebinit to paste.debian.net doesn't work any more. it outputs "http://paste.debian.net/" === Richie_ is now known as WelshDragon === gord_ is now known as gord === zanoi- is now known as zanoi === jdong is now known as 30BAAH8IN === jdong_ is now known as jdong === nigelb is now known as Guest81825 === temugen is now known as Guest4535 === hanska is now known as dapal === emma_ is now known as emma === emma is now known as em === elmo_ is now known as elmo === sikon is now known as lucidfox === 30BAAH8IN is now known as jdong [19:01] how to undo apt-get build-dep? === Tm_K is now known as Tm_T === Richie__ is now known as WelshDragon === jtechidna is now known as JontheEchidna === AlanChicken is now known as AlanBell [19:12] Of the releases that are still supported, Dapper and Hardy use usplash, Karmic uses xsplash, and everything newer uses plymouth, right? === lan3y is now known as Laney === mnepton is now known as mneptok === superm1` is now known as superm1 === temugen_ is now known as temugen === temugen is now known as Guest35743 === emma is now known as em === lifeless_ is now known as lifeless === Zic_ is now known as Zic === Lutin_ is now known as Lutin === ev_ is now known as ev === dapal is now known as a5e02a === a5e02a is now known as dapal === wgrant_ is now known as wgrant === Nafallo_ is now known as Nafallo === hanska is now known as dapal === Richie is now known as WelshDragon