psusi | ugh.... and they left the quilt patches applied in the debian lvm2 bzr branch | 01:32 |
---|---|---|
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:34 |
psusi | yep... vc would depend on what vc, if any, a package is using | 01:35 |
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:47 |
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:50 |
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:51 |
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:52 |
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:53 |
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:54 |
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:55 |
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:56 |
ebroder | I'm not actually sure what I mean. But patches applied is definitely the resting state of the package | 01:57 |
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 | 01:59 |
psusi | why? | 02:00 |
psusi | I thought 3.0 just meant it used quilt patches, not that they are already applied in the source package? | 02:01 |
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:02 |
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:13 |
ebroder | s/(understand)ing/$1/ | 02:15 |
MattJ | echo "understanding" | sed 's/\(understand\)ing/\1/' | 02:23 |
* MattJ sneaks off to bed quickly | 02:23 | |
ebroder | MattJ: echo "understanding" | perl -pe 's/(understand)ing/$1/' | 02:24 |
ebroder | :-P | 02:24 |
MattJ | . | 02:24 |
MattJ | should have known | 02:25 |
=== asac_ is now known as asac | ||
=== nigelbabu is now known as nigelb | ||
bilalakhtar | Can non-core-devs be patch pilots? | 06:25 |
ebroder | Of course! Patch piloting is only partially about sponsorship | 06:25 |
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:32 |
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/ | 06:43 |
ebroder | SpamapS: wtf did you do to this mongodb package? | 07:08 |
SpamapS | ebroder: ?? I wish I knew | 07:11 |
SpamapS | ebroder: talking about the lucid backport to use the wrapper? | 07:11 |
ebroder | Yeah | 07:11 |
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:12 |
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:13 |
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:14 |
ebroder | Check out the build log from https://launchpad.net/~broder/+archive/ubuntu-tests/+build/2066064 - I added a bunch of debugging printouts | 07:15 |
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:16 |
SpamapS | ebroder: OH WEIRD.. why isn't it a symlink?! | 07:17 |
ebroder | SpamapS: That is a *fantastically* good question | 07:17 |
SpamapS | ebroder: also why does everything show up like 5 times in the debug build? | 07:18 |
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:19 |
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:20 |
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:21 |
SpamapS | brb.. trying to correct my keboard/touchpad weirdness | 07:23 |
* SpamapS really has to get the multitouch driver going.. the extra taps from the synaptics driver are driving me NUTS | 07:28 | |
SpamapS | ebroder: doh stat: cannot stat `/build/buildd/mongodb-1.2.2/debian/mongodb/usr/bin/mongo': No such file or directory | 07:40 |
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:41 |
ebroder | Oh, and screwed it up again. But still - usr/bin/mongo is a file coming out of that first dh_link | 07:43 |
SpamapS | ebroder: you should do 'file' on it too while you're hot. ;) | 07:48 |
ebroder | I'm pretty sure it's just a plain file with the contents "../lib/mongodb/xulwrapper" | 07:49 |
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:50 |
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:51 |
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:54 |
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. | 07:56 |
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:00 |
ebroder | Actually, I'm going to try something... | 08:01 |
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 | 08:46 |
SpamapS | ebroder: interesting | 09:21 |
SpamapS | ebroder: this still suggests a possible aufs bug.. rename then create symlink in place causes fail.. ? | 09:21 |
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:22 |
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:23 |
ebroder | SpamapS: Cool. Let me know and I'll sponsor it? | 09:29 |
SpamapS | ebroder: I pushed it already, should be updated in the MP | 09:35 |
ebroder | SpamapS: Ok, cool. Looks good to me. I'm going to add the set -e Stefano mentioned, and then I'll upload | 09:38 |
SpamapS | ebroder: right, cool! | 09:47 |
NCommander | cjwatson: ugh, will fix | 10:42 |
=== ogra_ is now known as ogra | ||
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:51 |
* NCommander got sucked into visiting home >.<; | 10:52 | |
NCommander | on my TODO list as w espeak | 10:52 |
ebroder | Awesome | 10:52 |
=== ogra_ac_ is now known as ogra_ac | ||
ari-tczew | could any admin reject clementine in natty NEW? I uploaded it by mistake. (dput ubuntu instead ppa) | 11:53 |
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? | 13:28 |
ubottu | Launchpad bug 658521 in linux (Ubuntu) "In Live session or installation HD not recognized" [Undecided,Confirmed] https://launchpad.net/bugs/658521 | 13:28 |
alex88 | no one? | 14:21 |
=== Richie_ is now known as WelshDragon | ||
BlackZ | !weekend | alex88 | 14:22 |
ubottu | 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:22 |
alex88 | oh..:) right..thank you BlackZ :) | 14:28 |
penguin42 | alex88: Oh you found a patch? | 14:29 |
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:32 |
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:33 |
alex88 | also i've set bug as confirmed.. after testing if it works what to do? | 14:34 |
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:36 |
penguin42 | alex88: In that bug it's probably right to be clearer about exactly who gave you the patch | 14:39 |
alex88 | penguin42, Tejun Heo <htejun@gmail.com> from linux-ide@vger.kernel.org | 14:40 |
penguin42 | yeh, just say that in the bug - it's always good to be able to trace patches | 14:41 |
alex88 | done | 14:41 |
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 | 14:55 |
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:06 |
crimsun | it would just follow normal commit procedure: Reported-and-tested-by: alex88 .. etc. | 15:07 |
nigelb | crimsun: Morning :-) | 15:16 |
crimsun | nigelb: hi | 15:17 |
nigelb | crimsun: Nice to see you around after long | 15:17 |
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:25 |
nigelb | cjwatson: that's probably bdmurray's territory | 15:27 |
* penguin42 is surprised that isn't one of the entries in '13 ways to say nothing in scientific visualisation' | 15:29 | |
=== MattJ100 is now known as MattJ | ||
bilalakhtar | doko: Can I work on the gcc-4.3 merge? | 17:01 |
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:06 |
bdrung | stgraber: pastebinit to paste.debian.net doesn't work any more. it outputs "http://paste.debian.net/" | 17:15 |
=== 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 | ||
RenatoSilva | how to undo apt-get build-dep? | 19:01 |
=== 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 | ||
ebroder | Of the releases that are still supported, Dapper and Hardy use usplash, Karmic uses xsplash, and everything newer uses plymouth, right? | 19:12 |
=== 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 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!