[07:05] <dholbach> good morning
[07:07] <mvo> hey dholbach
[07:07] <dholbach> hey mvo
[07:07] <dholbach> mvo: ALTER!!!!!
[07:07]  * dholbach hugs mvo
[07:07] <mvo> :)
[07:07]  * mvo hugs dholbach
[07:07] <dholbach> Up early?
[07:07] <mvo> yes
[07:08] <dholbach> same here :)
[07:10] <jml> are we the upstream of the acpi-support package?
[07:10] <jml> dholbach, hello!
[07:11] <dholbach> hiya jml
[07:11] <dholbach> jml: what about that UDW session? :-D
[07:12] <jml> dholbach, last week of January, right? I'll be in the UK that week.
[07:12] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
[07:12] <jml> dholbach, I was just about to ask :)
[07:12] <dholbach> jml: acpi-support is in debian too
[07:13] <jml> I'm trying to find the upstream vcs for it.
[07:13] <dholbach> let me see
[07:13] <jml> dholbach, I can do the Friday 1800 slot.
[07:13] <dholbach> wow, it's even in sync with debian in lucid
[07:14] <dholbach> jml: which topic? lplib? :)
[07:14] <jml> dholbach, I can do lplib. I could also do an "Ask Launchpad" session
[07:14] <jml> dholbach, whichever you think would be more interesting.
[07:14] <dholbach> jml: which one would you prefer?
[07:15] <jml> dholbach, I have no preference.
[07:15] <jml> wow, it's going to be exciting being able to actually attend some of these sessions :)
[07:16] <jml> dholbach, probably lplib is best.
[07:16] <jml> dholbach, keep it concrete & code-y
[07:16] <dholbach> hum, it could be that we're "upstream" for acpi-support
[07:17] <dholbach> it's a bit of a weird divergence
[07:17] <dholbach> slangasek might know more
[07:17] <dholbach> the debian/copyright of the debian source package says something like "It was downloaded from http://archive.ubuntu.com/....."
[07:18] <dholbach> jml: shall I pencil you in? session title? :)
[07:19]  * jml tries to think of a clever title that doesn't violate the CoC
[07:19] <dholbach> haha
[07:19]  * dholbach hugs jml
[07:20] <jml> I'm all out of clever. How about "Meet launchpadlib"?
[07:21] <StevenK> "launchpadlib and you: Making access to Launchpad easier" ?
[07:21] <dholbach> sounds good to me :)
[07:22] <jml> I'm just going to make lp:~ubuntu-core-dev/acpi-support/trunk the dev focus for acpi-support. slangasek can correct me if I'm wrong.
[07:22] <dholbach> jml: sounds good to me
[07:23] <dholbach> jml: thanks a bunch for helping out with UDW :)
[07:23] <jml> dholbach, my pleasure.
[07:23] <dholbach> we have a fantastic line-up this time
[07:23] <dholbach> I mean we always do :)
[07:24] <jml> dholbach, yeah. I'm looking forward to heckling at rockstar's talk :)
[07:24] <dholbach> haha
[07:25] <jml> Ng, hello.
[07:25] <jml> Ng, could I persuade you to set the development focus branch for https://code.edge.launchpad.net/evdev ?
[07:26] <dholbach> who can I interest in another UDW session? there's still 4 open slots!
[07:26] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
[07:31] <slangasek> jml: that should work
[07:31] <jml> slangasek, thanks.
[07:32]  * jml is doing a little mindless data gardening
[07:35] <wgrant> Can I convince somebody to sync something like jack-tools? 3.0 support works now, and I'd like to see that syncing actually works.
[07:36] <wgrant> (jack-tools has all the things that are likely to trip Soyuz up, and it has no real changes, so it seems like a good test)
[07:38] <slangasek> wgrant: I synced one already
[07:38] <slangasek> (abraca, now in dep-wait)
[07:38] <wgrant> slangasek: But it at least hit the buildds? Good.
[07:39] <slangasek> yep
[07:40] <slangasek> thanks for all your help to get v3 happening :)
[07:40] <wgrant> np
[07:40] <wgrant> Sorry it took so long.
[08:08] <junjun> hi
[08:09] <junjun> i get the source of 9.10 kernel, and found that Ubuntu patches the vanilla kernel. where can i find the information on the patch?
[08:09] <junjun> i want to know which change Ubuntu made to the vanilla kernel
[08:09] <junjun> the patch to 2.6.31 is pretty big.
[08:10] <junjun> except AppArmor, and ndiswrapper, what else Ubuntu change to the kernel?
[08:13] <dholbach> junjun: try asking in #ubuntu-kernel (and maybe wait a bit, the folks might still be asleep :-))
[08:13] <junjun> dholbach: thanks!
[08:14] <pitti> Good morning
[08:16] <pitti> slangasek: right, I think there should be an extra field in the workitems table eventually; but oh well, kees already fixed it for now
[08:21] <junjun> from Ubuntu 9.10, we patch kernel with Non-Exec stack patch. Is that exactly the patch named Exec-Shield from Redhat?
[08:21] <junjun> if not, what is the difference with Redhat's Exec-shield??
[08:24] <junjun> oh well, it seems Ubuntu uses the patch from Redhat (Fedora)
[08:25] <kees> junjun: "execshield" is the entire unbrella project that Redhat put all their hardening features under.
[08:25] <kees> junjun: Ubuntu's kernel carries the last remaining piece of that which is not already upstream, the partial nx-emulation for i386
[08:25] <junjun> kees: so you mean we only port the kernel patch to Ubuntu, but not the rest?
[08:25] <kees> junjun: everything else already in the kernel, userspace, etc.
[08:26] <kees> junjun: some details here: https://wiki.ubuntu.com/Security/Features
[08:26] <junjun> it is interesting to know, thanks
[08:26] <kees> sure, np
[08:26] <junjun> so far, it seems only kernel of Fedora (and Redhat, CentOS) and Ubuntu uses this patch.
[08:27] <kees> junjun: afaik, SUSE uses it as well, but I haven't personally verified it.
[08:27] <junjun> the rest like OpenSuse, Debian, .... dont. is that correct?
[08:27] <kees> Debian does not use it, correct.  I'm unsure about SUSE
[08:27] <junjun> kees: ok, i will check that
[08:28] <kees> junjun: as linked from https://wiki.ubuntu.com/Security/Features#Non-Exec%20Memory I have a simple regression test that can help validate a given kernel.
[08:29] <kees> junjun: the patch itself is here: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commitdiff;h=eb56f42a4bc9c671a19dcf8fd36eb3f341de7dfa
[08:30] <kees> it's based on the bits from http://www.codemonkey.org.uk/projects/execshield/
[08:32] <junjun> kees: very clear, thanks!
[08:33] <junjun> kees: why this patch doesnt work for 64bit kernel??
[08:33] <kees> junjun: the cs-limit approach doesn't make sense for 64bit, and nearly all 64bit system already implement non-exec in hardware, so the emulation is unneeded.
[08:34] <junjun> what do you mean by "cs-limit approach doesn't make sense"??
[08:35] <kees> the partial nx-emulation patch uses the cs segment limit to split userspace into two region (one executable, the other not).  as I understand it, there's no reason to do this for 64bit, since 64bit is PAE, which implements the NX bit in the page table, so no artificial separation is needed.
[08:41] <tseliot> pitti: shall I make nvidia depend on acpid and acpi-support or would the former suffice?
[08:41] <pitti> tseliot: just acpid, please
[08:41] <pitti> acpi-support is unrelated to what nvidia does, and is still on the "to die" list
[08:42] <tseliot> pitti: ok, the latter seemed too much as a dependency to me but I wanted to be sure
[08:45] <fabbione> zul: ping? is there a bacula 3.0.X backport for hardy anywhere?
[09:02] <tkamppeter> pitti, can you upload Poppler for me, debdiff on bug 293832? Thanks.
[09:24] <pitti> tkamppeter: hi! sure
[09:25] <pitti> tkamppeter: should the other tasks be "invalid"ated then?
[09:26] <Ng> jml: hey, is that still required?
[09:26] <tkamppeter> pitti, I think so.
[09:26] <pitti> tkamppeter: uploaded
[09:26] <Ng> jml: well, I suppose I can see that there's no focus set, so I suppose a better question would be what would you like it set to? ;)
[09:28] <tkamppeter> pitti, the non-Poppler tasks are invalidated now, thanks for uploading.
[09:28] <pitti> ogra: bryce_ wrote a basic test plan for touch screens to check that the udevification didn't break anything (https://wiki.ubuntu.com/X/Testing/Touchscreen); does that look reasonable to you, or is there something important that should be added there?
[09:50] <mdz> Ng: re: the mkinitramfs error, 17-12-2009 11:30:21 < slangasek!n=vorlon@minbar.dodds.net: mdz: yes, Keybuk said he was going to fix that today
[09:51] <Ng> ah, sorry
[10:24] <StevenK> pitti: What was the magical gvfs-mount option again?
[10:24] <pitti> StevenK: for doing what?
[10:25] <StevenK> pitti: A USB key I just inserted is not automounting
[10:28] <pitti> StevenK: so you want to mount it manually? gvfs-mount -d /dev/foo
[10:28] <StevenK> steven@liquified:~% gvfs-mount -d /dev/sdb
[10:28] <StevenK> No volume for device file /dev/sdb
[10:30] <pitti> so gvfs-mount -li doesn't have /dev/sdb then?
[10:30] <pitti> does devkit-disks --mount /dev/sdb work?
[10:31] <StevenK> pitti: No, gvfs-mount -li does not have sdb
[10:31] <StevenK> devkit-disks ... does work, though
[10:34] <pitti> StevenK: does gvfs-mount -oi say anything when you plug this in?
[10:35] <StevenK> pitti: Yes, and it actually mounted it this time.
[10:35]  * StevenK curses heisenbugs
[10:50] <pitti> free: can you please make bug 455217 public, so that it can be SRU-processed?
[10:51] <free> pitti: oops, sorry, just made it pubblic, thanks
[10:51] <pitti> free: and please make sure that all the fixed bugs have proper ubuntu package tasks
[10:52] <free> pitti: I think I'm not entitled to create tasks? or how do I?
[10:52] <free> pitti: I couldn't figure out how to do it last time
[10:52] <pitti> free: "Also affects distribution" -> ubuntu/landscape-client
[10:52] <free> pitti: okay, on all the bugs related to the SRU?
[10:52] <pitti> right
[10:53] <pitti> we need to track their fixes/status in all releases
[10:53] <pitti> I started adding them
[10:54] <free> okay
[10:55] <pitti> all added now, I think
[10:55] <pitti> free: would you mind reviewing the bugs and closing the lucid tasks which are already fixed?
[10:56] <free> pitti: sure
[10:56] <pitti> thanks
[11:06] <free> pitti: I guess I can use "Fix released" for lucid tasks right?
[11:06] <pitti> free: if they are fixed in lucid, yes
[11:06] <free> pitti: okay, so that's done
[11:07] <pitti> cheers
[11:07] <free> pitti: there a now bugs that have the Lucid task with fix-released, and bugs that have a new Ubuntu task (no release-specifc tasks yet)
[11:08] <free> pitti: so, I don't think I can open release-specifc tasks, can I?
[11:08] <pitti> free: you can nominate
[11:08] <free> pitti: what does that mean exactly?
[11:09] <pitti> free: the tasks won't be created yet, but they will shown as "proposed for jaunty-update", etc.
[11:09] <pitti> I'll accept them while reviewing
[11:09] <free> okay
[11:12] <free> pitti: I can't figure out how to nominate, I can't see any "nominate" or similar button in the bug page UI..
[11:12] <pitti> free: "Target to release"
[11:12] <pitti> (with the ubuntu task selected, not the upstream task)
[11:17] <free> pitti: and how do you select the Ubuntu task? clicking on it just brings me to the landscape-client source page in the ubuntu LP project
[11:18] <pitti> free: hm; just change the URL to /ubuntu/+source/landscape-client/... ?
[11:19] <pitti> or change anything else in the ubuntu task
[11:19] <pitti> like priority, assignee, etc.
[11:22] <free> pitti: okay, manually entering the url like you suggest works, but changing something the ubuntu task doesn't, I couldn't find any way to do it except manually entering the url
[11:26] <free> pitti: okay, the bugs without specific release tasks should be all nominated now (for intrepid to lucid)
[12:00] <pitti> free: can bug 455217 be fixed in lucid, too?
[12:01] <free> pitti: yes
[12:02] <free> pitti: just marked it as Fix released
[12:02] <pitti> great
[13:16] <zul> fabbione: no there isnt a backport
[13:16] <fabbione> zul: thanks, I have done myself
[13:16] <zul> fabbione: cool
[13:16] <fabbione> zul: you might want to take care of Lucid release notes for upgrading tho
[13:17] <fabbione> zul: you need to have a director > 3.0 to talk to fd > 3.0
[13:17] <fabbione> zul: dir 3.0 can talk to fd in any version but not the other way around
[13:17] <zul> fabbione: thanks for the heads up
[13:17] <fabbione> zul: so basically, if you want LTS to LTS upgrade plan, the director machine needs to be done first
[13:18] <zul> gotcha
[13:46] <zul> james_w: did the import failed for samba i dont see it in launchpad?
[13:47] <james_w> zul: it was stuck in the queue, I've set it to run next
[13:48] <zul> james_w: thanks
[14:06] <Keybuk> mdz, Ng: it was stuck in NEW :p
[14:27] <Chipzz> http://www.advogato.org/person/robertc/diary.html?start=129
[14:27] <Chipzz> this gets a major ++ from me
[14:27] <Chipzz> I would hope this mentality would propagate to more debian and ubuntu developers
[14:31] <joaopinto_> I really don't see the relation between upstreams doing their own packaging, and including the debian/* in the upstream source
[14:32] <joaopinto_> I agree with the first, not with the second
[14:32] <james_w> why?
[14:33] <joaopinto_> because debian/* use dependencies or rules some times tweeaked for specific distros/releases
[14:33] <joaopinto_> there is no advantage on having them including on the source, there is the advantage that other packagers will need to patch or rm the upstream debian/*
[14:34] <joaopinto_> ops, disadvantage
[14:35] <joaopinto_> upstreams doing the packaging is a social subject, including debian/* in the source is a technical one
[14:36] <james_w> upstream sometimes has code that doesn't work on Ubuntu, so there is a disadvantage that we sometimes need to patch it, so upstream shouldn't ship any code
[14:38] <joaopinto_> james_w, source code is generic, as far as possible, debian/rules are not, and you failed ot mention what at the advantages of having it include on the source :)
[14:38] <joaopinto_> ops, I meant debian/*
[14:38] <james_w> debian/* are generally, otherwise we wouldn't be able to derive from Debian without making vastly more changes than we do
[14:40] <Ng> joaopinto_: I like it when I unpack a tarball of some new software and I can just build a package out of it immediately. That's why I include a debian/ in my projects :)
[14:40] <ScottK> Is Google Talk audio supposed to be working with Empathy in Karmic?
[14:40] <ScottK> Ng: The problem is most upstreams that attempt to do this, don't know a lot about Debian packaging.
[14:41] <james_w> ScottK: I don't see that as a reason to tell every single upstream that does it off, as seems to be the culture currently
[14:41] <joaopinto_> james_w, you are refering to the general case of Debian versus Ubuntu, the debian/* world does not stop there, and still, your sentence is not accurate when you need to backport
[14:41] <Ng> ScottK: I would absolutely fit in that pot, which is why I merge back in the correctness from nxvl's packaging :)
[14:42] <joaopinto_> Ng, if you want your projects just to build, provide a .dsc file
[14:43] <joaopinto_> Ng, you will help those which "just want to build" per your rules, without interfering with others that want to build in another way
[14:43] <Ng> joaopinto_: I don't follow, how does a .dsc help?
[14:43] <james_w> for a .dsc file to make any sense you have to have a debian directory, no?
[14:43] <joaopinto_> Ng, dget file.dsc && debuild
[14:44] <joaopinto_> no, you just need the .dsc, diff, and orig
[14:44] <joaopinto_> and everone is happy with a single dget command, versus a wget source
[14:44] <StevenK> joaopinto_: Which you can't build without a debian directory in the source
[14:45] <joaopinto_> StevenK, you can, because I am refering to a .dsc which points to both the orig.tar.gz and the debian diff
[14:46] <StevenK> joaopinto_: And what do you think is in the debian diff? The debian directory.
[14:46] <joaopinto_> StevenK, right, but provided as it should as a diff, not included on the original source
[14:47] <james_w> joaopinto_: so you refuse to let us re-use and collaborate on that debian/ directory in the most natural way, as we do the rest of the code?
[14:47] <james_w> no thanks
[14:48] <joaopinto_> james_w, no, but I don't agree that the proper place for packaging collaboration is the source, you do collaboration for a group at the cost of other group
[14:48] <ScottK> Another issue is that improvements to Debian packaging need a new upstream release if that's the canonical source for them.
[14:48] <james_w> it's not a cost that means much
[14:49] <james_w> it doesn't have to be the canonical source, or diff.gz can make modifications
[14:49] <Ng> how much variation is there in the packaging of debian derivatives? talk of costs without numbers seems a bit pointless
[14:49] <joaopinto_> james_w, ah ok, so you assume that your need for collaboration is more important than others needs for a clean source :)
[14:49] <james_w> improvements to the code don't need a new upstream release, we are generally happy to patch and feed the changes back for the next release
[14:49] <joaopinto_> that's something personal, nothing to argue about :)
[14:52] <joaopinto_> james_w,  upstreams should be able to collaborate if the debian/* dir is kept in any VCS
[14:55] <Keybuk> huh?
[14:55] <Keybuk> upstream should never put the debian/ directory into their VCS
[14:55] <Keybuk> that's just wrong
[14:56] <joaopinto_> the only good reason I see on this change would be, "Hey you cand build .debs from the source", when there is no one able to set up a PPA or get it into the repositories
[14:56] <Keybuk> anyone can have a PPA
[14:56] <joaopinto_> but again, that is not collaboration :)
[14:56] <joaopinto_> Keybuk, we are debating that http://www.advogato.org/person/robertc/diary.html?start=129
[14:57] <Keybuk> there's no loop or step to getting one, just create a Launchpad account
[14:57] <Keybuk> I disagree strongly with Robert ;)
[14:57] <Keybuk> one of the biggest problems I ever have, as a distribution maintainer, is upstreams who put the packaging into their tarball
[14:57] <Keybuk> because it's always wrong
[14:57] <Keybuk> and it makes it very hard for us to modify it
[14:58] <jcastro> it should just be another branch imo
[14:58] <Keybuk> in certain ways, for example removing a debhelper config file, it becomes impossible to modify without repackaging the software entirely
[14:58] <jcastro> like how we're doing for UDD
[14:58] <joaopinto_> Keybuk, that was the pointing I was making
[14:58] <Keybuk> (because our source package format doesn't permit removing files in the diff.gz)
[14:58] <james_w> Keybuk: to be fair, Rob says we should fix that.
[14:59] <Keybuk> you also end up the situation where it looks like it's got a package
[14:59] <Keybuk> but the package is wrong
[14:59] <Keybuk> so people think they can grab the upstream tarball
[14:59] <Keybuk> build it
[14:59] <Keybuk> and then install it on their distribution
[14:59] <Keybuk> that could go *badly* wrong
[15:00] <Keybuk> look at the .spec file issues between SuSE and RedHat for an example ;)
[15:02] <LaserJock> hmm, so what happens if upstream has a debian/ but Debian, Ubuntu, <any old .deb-based distro> wants to package in different ways?
[15:03] <LaserJock> does the upstream need to pick which distro to support? or do they use something like control.in?
[15:04] <Keybuk> LaserJock: it gets more fun
[15:04] <Keybuk> upstream might disagree with the way distributions change their packages
[15:04] <Keybuk> and deliberately make it hard for distributions
[15:04] <Keybuk> (this happens)
[15:11] <Ng> Keybuk: why are you packaging things in isolation from the upstream? if their debian/ is wrong they must care enough to have one, so presumably want a correct one?
[15:12] <Keybuk> Ng: it means they want one they *think* is correct
[15:12] <Keybuk> that's so far removed from "a correct one" that they may as well be in different universes
[15:13] <Ng> Keybuk: I think they want one that produces a working package
[15:13] <Keybuk> see, that's the problem
[15:13] <Keybuk> let me give you an example
[15:13] <ScottK> Ng: Which is a small subset of what it takes to be correct.
[15:13] <Keybuk> I have an upstream, who we'll call Ted
[15:13] <Keybuk> he maintains a piece of software, which we'll call e2fsprogs
[15:13] <Keybuk> and he also happens to put the entire debian/ directory in his package
[15:14] <Ng> Ted sounds like he cares about his users!
[15:14] <Keybuk> tricks that Ted has done in the past include adding code to his debian/rules to disable features on Ubuntu
[15:14] <Keybuk> because he thought that Ubuntu was doing things wrong
[15:14] <Keybuk> turned out that was a bug in his kernel code he was hiding
[15:14] <Keybuk> the only reason he was getting bug reports from Ubuntu users is because we have lots of users
[15:15] <Ng> so to avoid fixing a kernel bug we just take the packaging away from him?
[15:15] <Keybuk> Ted has deliberately blocked library transitions
[15:15] <Keybuk> etc.
[15:15] <Keybuk> no
[15:15] <Keybuk> I'm saying that in the released upstream tarball is the wrong place for packaging
[15:15] <Keybuk> for a start, what's right for Debian might not be right for Ubuntu
[15:15] <Keybuk> even though the packaging files are the same)
[15:15] <Keybuk> I think the right way is what we do on Upstart
[15:15] <Keybuk> we have a tarball we release without packaging
[15:16] <Keybuk> then an upstream branch which is the tarball + packaging
[15:16] <Keybuk> and we collaborate on that
[15:16] <Ng> I'd concede plumbing stuff, but I like being able to grab a tarball or vcs checkout of some application and have it be ready to build
[15:16] <Keybuk> if distros need their own tweaks, they branch off it
[15:16] <james_w> so one person spoils it for the rest of us?
[15:16] <Keybuk> Ng: build for Ubuntu or build for Debian?
[15:16] <Keybuk> or build for SuSE or build for RedHat?
[15:16] <Keybuk> if you build something for Ubuntu, it might not work on Debian
[15:16] <Keybuk> and vice-vera
[15:16] <james_w> plus, the same arguments can apply for code, though admittedly less often
[15:17] <Keybuk> james_w: one of the major portions of packaging is patches to the code
[15:17] <Keybuk> that's kinda the point
[15:17] <Keybuk> here's a better question for you
[15:17] <Keybuk> why do we have packaging at all?
[15:17] <Keybuk> if the upstream tarball is perfect as-is
[15:17] <Keybuk> why do we *need* a debian directory in it?
[15:17] <Keybuk> why can't we automate the process of taking an autoconfery tarball and turning it into debs?
[15:17] <Keybuk> packaging is all about hacks to the code
[15:18] <Keybuk> packaging is changing the code to fit the distribution
[15:18] <Keybuk> or changing the default configuration of the code or result
[15:18] <Keybuk> changing install paths
[15:18] <Keybuk> removing files we don't want
[15:18] <Keybuk> adding ones that aren't incldued
[15:18] <Keybuk> etc.
[15:18] <Keybuk> if the upstream tarball is correct
[15:18] <Keybuk> (which it often is in a large majority of the cases)
[15:18] <Keybuk> you don't need packaging
[15:19] <Keybuk> this is probably the primary reason I don't like packaging-in-upstream
[15:19] <james_w> aside from the issue of autoconf/setup.py/Makefile.PL etc., yes
[15:19] <Keybuk> you end up with a qmail-esque bizarre situation where you have "the upstream code", and "the upstream approved patches to the code"
[15:19] <james_w> it strikes me you should write all this in a blog post and propose your preferred way instead
[15:20] <Keybuk> we discussed this in autotools a while back
[15:20] <Keybuk> the only bit you're really missing is knowing which files are libraries, which are headers, which are data, which are docs, etc.
[15:20] <Keybuk> a lot of that can be guessed by path
[15:20] <Keybuk> but you kinda want a manifest-like file that hints to a packaging system
[15:21] <Keybuk> you also want a standard format file for things like source descriptions, licencing, etc.
[15:24] <LaserJock> hmm, maybe you would want all that in a directory, maybe you could call it debian/ or something ;-)
[15:25] <Keybuk> LaserJock: the idea is that it'd be useful for everyone
[15:25] <Keybuk> and the debian formats are ... bizarre
[15:25] <Keybuk> like, why the hell would an upstream want to have a separate changelog?
[15:25] <Keybuk> their version number is already in configure.ac
[15:25] <Keybuk> unfortunately the discussion kinda veered towards "looks a lot like a .spec file" <g>
[15:25] <LaserJock> heh
[15:26] <LaserJock> the problem I see mostly though is upstreams either 1) don't want to package at all or 2) don't want to package for several different distros
[15:27] <ScottK> Or don't want to deal with distros at all and just have their users get packages from them
[15:27] <LaserJock> yes
[15:29] <ScottK> One of my upstreams (who uses Fedora) didn't see the point of getting his stuff into distros.
[15:29] <ScottK> I got one of his packages into Debian/Ubuntu and he mentioned he'd gotten a lot of new users show up right after I did that on his mailing list.
[15:29] <ScottK> Suddenly he got it and he packages his stuff for Fedora now.
[15:30] <ion> Had he been tuomov, he’d have hated you for getting new users.
[15:30] <Ng> popcon numbers can sometimes make a good impression :)
[15:31] <LaserJock> must upstreams I know just don't have time to learn .specs and debian/ etc.
[15:31] <LaserJock> *most
[15:32] <ScottK> This guy was distributing rpms already, he just hadn't seen the point in going to the trouble to get it in a distro.
[15:33] <LaserJock> and then there are upstreams that fork dependencies in PPAs and call it good ;-)
[15:34] <jam> barry: ping
[15:34] <jam> you sent a mail as "barry@canonical.com" that got blocked going to udd
[15:34] <jam> did you want me to add that address?
[15:35] <barry> jam: dang.  yes please!
[15:36] <jam> hmm.. it says the sender is "now" a member of the list already
[15:36] <jam> so apparently it should just work now
[15:36] <jam> I know I have a few accounts that get a bit confused sometimes
[15:36] <barry> weird, maybe it got held for other reasons
[15:36] <Keybuk> if upstreams did their job properly, we wouldn't _need_ distros ;-)
[15:36] <jam> I'm pretty sure it thought you weren't a member for a bit
[15:37] <jam> barry: ahh, I see why now
[15:37] <jam> Reason:  SpamAssassin identified this message as possible spam (score 3.8)
[15:38] <barry> ouch.  i should use fewer ! and $
[15:38] <jam> barry: though the message that got through was: X-Spam-Status: No, score=-2.2 required=4.5 tests=ALL_TRUSTED,AWL,BAYES_00, 	DATE_IN_PAST_03_06,MIME_BASE64_NO_NAME,MIME_BASE64_TEXT autolearn=ham  	version=3.1.7
[15:38] <jam> had you posted to udd before?
[15:39] <jam> As it looks like SQLGrey may have also been involved
[15:39] <barry> jam: yep, lots
[15:39] <jam> (I'm pretty sure you have)
[15:39] <jam> oh, and that sqlgrey stuff may be my local machine, not canonicals
[15:40] <jam> yeah, it probably is
[15:40] <LaserJock> was barry trying to sell us on the "effects" bzr can have on our personal life? ;-)
[15:40] <jam> apparently my mail host likes you
[15:40] <jam> but canonical's doesn't :)
[15:41] <jam> barry: so my guess is that SA doesn't like "date in past"
[15:41] <jam> since it seems to think that it was sent at 4am
[15:41] <jam> and then the fact that your mail client encodes everything as base64
[15:41]  * barry restarts ntpd
[15:41] <jam> even though it is just text
[15:41]  * persia reads backscroll and yet again wishes that `gzcat foo.diff.gz | patch` was capable of deleting files
[15:41] <Keybuk> persia: it is
[15:42] <Keybuk> Ian Jackson just disagreed with being able to do it, so had dpkg refuse to do so
[15:42] <barry> jam: i'm posting from a vm and when the host sleeps, my time gets out of whack.  unfortunately, that also seems to kill the ntpd service for some reason :(
[15:43] <Keybuk> persia: I think the reason dpkg refuses is quite logical
[15:43] <Keybuk> people might think that patching a file out of the tarball is an acceptable way to solve DFSG issues
[15:43] <Keybuk> when, of course, it isn't
[15:44] <persia> That's all!
[15:44] <Keybuk> because Debian would still have been distributing the file in the tarball
[15:44] <maco> arent you sposed to do that in the orig?
[15:44] <Keybuk> of course, nobody believed people would ever put debian directories in the tarball ;)
[15:45] <persia> I agree that it's not an acceptable way to make something DFSG-free (the tarball is shipped anyway), but it would mean that suddenly it wouldn't *matter* if upstream ships packaging (debhelpers -i helps to some degree, but only to some degree)
[15:45] <Keybuk> it still makes your life hard
[15:45] <Keybuk> you'd have to review every new upstream version carefully
[15:45] <persia> Can we revisit that, or is that reviving horses that are best forgotten?
[15:45] <Keybuk> "grr, upstream added a debian/wibble.foo file that I missed, and now my package fails to install"
[15:46] <Keybuk> if we were to revisit anything basic like that, we should probably just invent a new source package format
[15:46] <persia> Yeah, but one should be at least reviewing the file listing and dpkg --contents listings anyway, at an absolute minimum.
[15:46] <Keybuk> put it in an ubuntu/ directory
[15:46] <Keybuk> and then be done ;)
[15:46] <persia> Hrm.  tempting....   but maybe not.
[15:47] <Keybuk> if Colin ever gets hit by a bus, it'll be one of my first jobs ;)
[15:47] <Keybuk> Mark's been wanting to do that since day one, so I know I'll be allowed <g>
[15:48]  * pitti tosses http://cdimage.ubuntu.com/daily-live/20091218.1/ Keybukwards
[15:48] <Keybuk> pitti: way ahead of you ;) already rsync'd down and updating TFTP and NFS roots
[15:49] <Keybuk> will be interesting to see how this works
[15:49] <Keybuk> I got good numbers on ratchet
[15:49] <Keybuk> and I'm getting increasingly convinced that ratchet is slightly slower than max
[15:49] <pitti> good luck!
[15:51] <james_w> what's new in this image?
[15:51] <pitti> james_w: Keybuk's speedup work from today
[15:51] <pitti> (initramfs-tools, etc.)
[15:51] <Keybuk> well, last night
[15:51] <Keybuk> mostly initramfs-tools
[15:52] <james_w> the tsort stuff?
[15:52] <ion> How about devtmpfs?
[15:52] <Keybuk> no, that was in 18
[15:52] <Keybuk> I replaced all of the scripts/local loop with a tiny binary
[15:52] <Keybuk> that uses libudev to do what all that shell was trying to do *properly*
[15:52] <james_w> cool
[15:52] <Keybuk> ie. if the device doesn't exist, use netlink to wait for udev to finish with it
[15:52] <Keybuk> if the device exists, and is in udev's queue, also use netlink
[15:53] <Keybuk> if the device exists, and is not in udev's queue, done
[15:53] <Keybuk> also obviously outputs the filesystem type as udev knows it, so we don't have to separately probe fstype/blkid in the initramfs
[15:54] <Keybuk> one major advantage speed-wise is that it never calls "settle"
[15:54] <Keybuk> which means you can mount the root fs in the initramfs while loading of irrelevant modules is still happening
[15:54] <pitti> update-initramfs: Generating /boot/initrd.img-2.6.32-8-generic
[15:54] <pitti> .: 4: Can't open /scripts/functions
[15:54] <pitti> Keybuk: ^ known?
[15:55] <Keybuk> pitti: no, can you check through scripts/*/* and see which sources /scripts/functions *before* checking for "prereqs"
[15:56] <pitti> ./local-top/cryptroot
[15:56] <pitti> so, from cryptsetup
[15:56] <Keybuk> pitti: fix is obvious, don't source /scripts/functions until after the prereqs case
[15:56] <Keybuk> can you do that one while you're there?
[15:57]  * Keybuk has an allergy to cryptsetup
[15:57] <pitti> hm, I moved it down, now it says
[15:57] <pitti> [: 22: Private: unexpected operator
[15:57]  * pitti sighs
[15:57] <Keybuk> pitti: pastebin the script?
[15:58] <pitti> Keybuk: I'll try to squeeze it in (release meeting now)
[15:58] <Keybuk> oh, cryptsetup has a *weird* prereqs!
[15:58] <pitti> Keybuk: http://people.canonical.com/~pitti/tmp/cryptroot
[15:58] <Keybuk> yeah that for just won't work ;)
[15:59] <Keybuk> probably should be $(dirname $0) rather than /scripts/local-top
[16:01] <Keybuk> pitti: a change I made the other day is that the prereqs bit of each script is run at mkinitramfs time
[16:01] <Keybuk> rather than inside the initramfs
[16:02] <Keybuk> so the generated initramfs already knows what order to run things in
[16:02] <pitti> Keybuk: updated script (same URL), it doesn't complain now
[16:02] <pitti> but I don't claim I really understood what I was doing
[16:03] <Keybuk> basically was just expecting /scripts to exist
[16:03] <Keybuk> when that's /usr/share/initramfs-tools/scripts
[16:04] <Keybuk> (because I'm running it from mkinitramfs now)
[16:04] <pitti> Keybuk: so, I'm fine to do that upload if you want me
[16:04] <Keybuk> yup, go for it
[16:04] <Keybuk> I imagine we'll hit a few of those
[16:08] <pitti> uploaded
[16:09] <pitti> nice, bzr bd now DTRT even without a .bzr-builddeb/ config
[16:09] <james_w> inferring --merge?
[16:09] <pitti> right
[16:09] <pitti> the cryptsetup tree is full source, but it downloaded the orig.tar.gz, etc.
[16:09] <james_w> yeah, that's (yet another) thing you can thanks jelmer for
[16:10] <pitti> so far we just copied the very same config into all of our desktop trees
[16:10] <pitti> jelmer: *hug*
[16:10] <jelmer> pitti: :-) Glad to hear
[16:10] <jelmer> we have similar itchjes
[16:38] <Keybuk> james_w: I still have issues getting the first tarball into bzr ;)
[16:38] <Keybuk> I do sick and evil things like make a pretend upstream-last-release tag
[16:38] <Keybuk> or remove debian/changelog and import-dsc the source package I just generated
[16:39] <Keybuk> I noticed that it seems to upset the auto-importer though ;-(
[16:40] <james_w> hmm
[16:40] <james_w> I thought merge-upstream was supposed to work, but I can believe that I broke it
[16:40] <Keybuk> it won't work if there isn't a previous upstream tarball
[16:40] <Keybuk> it will only make deltas I assume
[16:41] <Keybuk> never the initial tarball
[16:41] <Keybuk> you can trick it into doing so though
[16:41] <james_w> yeah
[16:41] <james_w> we should fix that :-)
[16:47] <Keybuk> I have been heavily using the bzr stuff though
[16:47] <Keybuk> my workflow this cycle is "bzr branch lp:..." ... doesn't exist? file bug; out of date? file bug (and apt-get source)
[16:47] <Keybuk> otherwise just use the bzr
[16:52] <pitti> ttx: what I meant is that e. g. bug 497455  -> we won't promote until it actually appears on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[16:53] <ttx> pitti: right. It's a eucalyptus runtime dep, so I guess it will show up once the package in built
[16:53] <jelmer> pitti: btw, I noticed the MIR for tdb - some of the issues there should be fixed in the version of tdb in sid
[16:53] <jelmer> pitti: Are you the right person to talk to about the MIR, or somebody else?
[16:53] <jelmer> pitti: (I'm the Debian maintainer)
[16:53] <pitti> jelmer: I'm one right person, yes
[16:54] <kees> pitti: for the SIGXCPU+apport thing, I saw that you merged it, but I just wanted to make sure you felt that was a valid approach.
[16:54] <pitti> jelmer: which "issues" do you mean?
[16:55] <pitti> kees: it looks fine to me
[16:55] <kees> pitti: ok, cool.  No other signals like those two jumped out.
[16:56] <jelmer> pitti: tdb-dev has been renamed to libtdb-dev, manpages will be included in the next upstream version
[17:21] <ScottK> slangasek: It'd be nice (although lower priority than powerpc) if you could look at qt4-x11 on ia64 too.  I'm lost in a twisty turny maze of ifdefs.
[17:24]  * slangasek gibbers
[17:25] <ScottK> slangasek: The upstream feedback was: You have a config.h, remove it.  the issue is that #include "config.h" is including the wrong file
[17:25] <ScottK> Since it works on other archs.
[17:26] <ScottK> I think it's an ifdef issue
[17:57] <Keybuk> mdz: are any of the videod sessions ever going to appear on blip.tv ?
[18:09] <machina> hi, I'm trying to update this copyright from this http://pastebin.com/d5200e964 to this http://pastebin.com/d1fafa456 but I don't know if it's right for me to put a copyright under the debian maintainer's name?
[18:10] <machina> this is about updating an Ubuntu/debian package btw..
[18:49] <ebroder> I don't suppose I could ask somebody to do a sync run so the new version of the packge I was just about to work on would hit the repos? :)
[18:55] <ScottK> slangasek: I think I found my way through the twisty/turny maze for qt4-x11 ifdefs and ia64.  Found a "-   || defined(__ia64__) \" between the last version and the current one.
[18:55] <slangasek> ah, cool
[18:55] <slangasek> ebroder: what package?
[19:00] <ebroder> slangasek: open-vm-tools
[19:00] <slangasek> ah, needs a sync run on contrib; looking
[19:05] <slangasek> ebroder: syncing
[19:07] <ebroder> Yay! Thanks, slangasek
[19:09] <Lutin> those days, who do I have to ask to get a give-back on the buildds ?
[19:28] <ScottK> slangasek: If I give you a debdiff for qt4-x11, could you testbuild it on a ia64 porter box?  It's a huge package for me just to blind upload.
[19:28] <slangasek> sure
[19:28] <ScottK> OK.  I'll have it in a few.
[19:29] <ScottK> .dff.gz for that package takes an eternity to generate on my laptop.
[19:29] <ScottK> dff/diff
[19:48] <ScottK> Right, so the good news is the emergency drop protection shutdown on my laptop works.  The bad news is the diff.gz wasn't done yet.
[19:48] <ScottK> It was kind of cool to see the laptop blink off in mid-air when I dropped it.
[19:54] <slangasek> heh
[19:57] <ion> Why power down the entire laptop? Why not just park the HDD heads?
[20:00] <Lutin> could someone with a lucid chroot try to install libeina-svn-05 (no matter what arch.)
[20:02] <slangasek> Lutin: could; but is the problem you're trying to solve related to the fact that this package needs a binary promotion to main?
[20:03]  * ScottK guesses yes.
[20:03] <ScottK> ion: I didn't design the hardware.
[20:04] <ion> Nobody blamed you for the hardware design.
[20:04] <ScottK> It just seemed odd to ask me why it worked the way it does.
[20:04] <ion> I asked the channel.
[20:04] <ScottK> ok
[20:05] <ion> sincerely willing to learn the technical reason for shutting down everything.
[20:07] <slangasek> perhaps because the hardware doesn't trust the OS to park the heads and leave them parked
[20:08] <ion> The hardware could force the heads to be parked for a period and the OS to wait.
[20:11] <ScottK> slangasek: http://pastebin.com/f3e99eaa3
[20:11] <ScottK> slangasek: On the off chance that builds, please just throw it at the archive.
[20:12] <slangasek> how do I extract a usable patch from pastebin?
[20:14] <arthur_> slangasek: see the textarea in the bottom
[20:14] <slangasek> I see it; cut-n-pasting from it didn't please patch, that's why I was asking
[20:14] <arthur_> right after "To highlight particular lines, prefix each line with @@"
[20:14] <arthur_> ah
[20:14] <slangasek> patch: **** Only garbage was found in the patch input.
[20:15] <slangasek> oh, haha
[20:15] <slangasek> because it eats @@ at the beginning of a line
[20:15] <arthur_> nice spot
[20:15] <slangasek> ok, got it
[20:16] <ScottK> Oops
[20:17] <ScottK> When I click on download it comes up correct.
[20:17] <slangasek> oh, there's a download button, ok
[20:17] <slangasek> :)
[20:22] <Lutin> slangasek: that's it, thanks
[20:22] <slangasek> Lutin: ok, should be fixed in the next pulse then
[20:22] <Lutin> alright, thanks a lot
[20:39] <Lutin> slangasek: in fact JamieBennett just pointed out that it's been promoted some times ago
[20:39] <slangasek> Lutin: not so; the binary was in universe until around the time I commented
[20:39] <JamieBennett> Jonathan Riddell wrote on 2009-08-24:#6 Package moved to main
[20:40] <JamieBennett> from the bug comments
[20:41]  * ScottK suspects a library transition
[20:41] <slangasek> that refers to a source package
[20:44] <Lutin> ah, true. the source package introduces a new binary package which wouldn't have been promoted automatically ?
[20:49] <JamieBennett> slangasek: Is there an active archive admin around which could kick the binary into main for us then?
[20:51] <slangasek> JamieBennett: already did, see above
[20:52] <JamieBennett> OK, thanks
[20:52] <slangasek> Lutin: it's a routine archive admin activity to reconcile http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, so it /should/ be < 48h turnaround from accepting the package to making sure it's in main if it's supposed to be
[20:55] <Lutin> slangasek: ok, thanks for the explanation
[21:16] <wgrant> lamont: Are you planning to get the lp-buildd changes merged soonish?
[21:16] <lamont> bigjools was supposed to land them, I thought
[21:16] <wgrant> Ah, OK.
[21:16] <lamont> lp:~lamont/launchpad/lp-buildd/
[21:17] <lamont> is what I actually built
[21:17] <lamont> and actually has changes beyond 54
[21:17] <wgrant> Ah, I wondered what those extra three revs were for.
[21:18] <lamont> yeah, it was the lalalalalalala fix these too things that fell out of reviewing changes to the machines where I installed the package
[21:18] <lamont> some just landed after I'd cut 54, and/or were invasive enough that I want them to get more testing before I roll them.
[21:45] <HenriqueRocha> hi
[21:46] <lamont> slangasek: bug 498331
[21:46] <HenriqueRocha> i'm trying to install lucid alpha 1 but it doesn't install
[21:46] <slangasek> lamont: how precise :-)
[21:46] <lamont> slangasek: I decided to make sure it had a descriptive subject....
[21:47] <lamont> dear fellow buildd admins:  DO NOT give-back libgphoto2/armel.
[21:47] <hrocha> is it possible that it is not installing because i'm using the locale in portuguese?
[21:48] <slangasek> hrocha: #ubuntu+1 is the channel for lucid support; I'm not aware of any locale-specific issues in alpha-1
[21:48] <hrocha> ok, thanks
[23:31] <ebroder> Wait, what? Why can't I target bug #191776 for Hardy? The package has always been in multiverse - I should be able to
[23:42] <wgrant> ebroder: It doesn't exist in Hardy.
[23:42] <wgrant> It was removed just before release.
[23:42] <ebroder> Huh! How about that
[23:42] <wgrant> (and it was in universe then)
[23:43] <ebroder> Oh yeah - the bug was reported against Hardy a4
[23:45] <ebroder> It seems like it would be useful if I could deal with nominations for releases the package wasn't in at all. Oh well