[00:39] <micahg> bdrung: it looks like since the binary package has the same name, everything should be fine
[00:39] <bdrung> micahg: and the source doesn't differ?
[00:40] <micahg> bdrung: what do you mean, it's from the same upstream AFAICT
[00:40] <bdrung> micahg: the debian/ directory. maybe some packaging difference that we need to carry?
[00:43] <micahg> bdrung: oh, hmm, ok, I can review it as well, from the changelog, it just a possible FTBFS on non-i386, which you already confirmed is not an issue
[00:49] <micahg> bdrung: yeah, I don't see anything special in the packaging, should I just comment on the bug
[02:11] <ScottL> is there a way to 'apt-get source ${package}' but get a particular release instead of changing the sources.list?
[02:13] <ScottL> for instance, i wanted to build qjackctl from maverick but for lucid and i was in a lucid install
[02:14] <micahg> ScottK: pull-lp-source
[02:14] <micahg> oops
[02:14] <micahg> ScottL: pull-lp-source
[02:14] <micahg> ScottK: sorry :(
[02:18] <ScottL> micahg, does that get the most current source, or can i specify the release?
[02:19]  * ScottL is downloading ubuntu-dev-tools on this machine to find out
[03:48] <micahg> ScottL: you can specify any release or pocket
[06:20] <RenatoSilva> what's the purpose of the 'linux' package and why should I use it?
[06:21] <micahg> RenatoSilva: linux is the source package for the Ubuntu kernel
[06:22] <ebroder> RenatoSilva: It's also a metapackage you can install to make sure (via a long chain of dependencies) that you always have the latest version of the Ubuntu kernel
[06:25] <RenatoSilva> source package as in containing source code?
[06:25] <RenatoSilva> ebroder: I can make sure I have the latest versions by updating the system, so I don't see the point of that package (it is not installed but I'm curious)
[06:26] <ebroder> RenatoSilva: You probably have a package called "linux-image-generic" or the like installed. It serves the same purpose as the "linux" package
[06:26] <Rhonda> RenatoSilva: The upgrade does only pull in the latest version if there is a dependency chain to it.
[06:26] <ebroder> You need one of these metapackages because, as the version number of our kernels change, sometimes the name of the package containing them do as well
[06:27] <RenatoSilva> ebroder: I have linux-image-generic, so why have  tow packages for the same thing?
[06:27] <Rhonda> It's not two for the same thing.
[06:27] <RenatoSilva> "It serves the same purpose as the "linux" package"
[06:27] <ebroder> It is in this case. linux depends on linux-image depends on linux-image-generic
[06:28] <Rhonda> RenatoSilva: No, it doesn't.
[06:28] <RenatoSilva> "The upgrade does only pull in the latest version if there is a dependency chain to it."
[06:28] <Rhonda> linux depends on linux-image, and linux-image is a virtual package provided by a few other packages, so it doesn't necessarily pull in linux-image-generic.
[06:28] <RenatoSilva> I don't understand this
[06:29] <Rhonda> Take a look at this page: http://packages.ubuntu.com/natty/linux-image
[06:29] <RenatoSilva> Should I use 'linux'?
[06:29] <Rhonda> What exactly don#t you understand in it?
[06:29] <Rhonda> That depends.
[06:30] <Rhonda> If you don't see a need for it and be happy with linux-image-generic, then have that.
[06:31] <Rhonda> With linux-image-generic, you always get the -generic flavor of the kernel.
[06:31] <Rhonda> With linux you can instead also have the -server or -virtual flavour.
[06:32] <Rhonda> Hmm, or not.
[06:33] <Rhonda> Because linux has a versioned depends on linux-image?
[06:33] <Rhonda> Confusing. %-)
[06:34] <Rhonda> I guess the "linux" package is there for people just looking for that and not being able to find linux-image or linux-image-generic instead.
[06:34] <Rhonda> So it's more a convenience reason, me thinks.
[06:35] <RenatoSilva> well, the version of the "actual" linux-image-generic is on the name, so updates pull new packages to install (through dependencies of 'linux-image-generic' I guess), but the old kernel keeps there, if I don't remove it the old kernel list in my grub menu increases indefinitely
[06:36] <Rhonda> It can't get removed automatically because you might still be running it.
[06:37] <RenatoSilva> there isn't any scheduling feature in apt for removing after reboot?
[06:37] <RenatoSilva> so I will always have to remove old kernels forever? ok
[06:39] <RenatoSilva> besides this, I'd appreciate to understand why 'linux', 'linux-image' and 'linux-image-generic' exist. I'm even more confused but thanks for trying. Thanks all for help.
[06:41] <Rhonda> I tried to come up with a possibility why it might exist.
[06:42] <RAOF> At one point it also pulled in linux-headers; does it still do that?
[06:44] <ebroder> None of linux, linux-image, or linux-image-generic pull in headers
[06:44] <ebroder> Or linux-generic
[06:50] <RenatoSilva> micahg: hi, do you remember the missing irc-more problem? I've attached another patch for making build fail for invalid plugins, not sure if they care though
[06:50] <micahg> RenatoSilva: I replied in teh bug about that
[06:58] <Rhonda> RAOF: Given that now changelogs are ripped out of the packages because of install size optimization I would be quite surprised by that. :)
[06:59] <RenatoSilva> micahg: oh I see. They have their own bug tracking, would you keep a fork if they don't care to fix it (not surprising)?
[07:00] <micahg> RenatoSilva: who, what/
[07:02] <ebroder> micahg: Did you say you were going to look at bug #592538?
[07:04] <micahg> ebroder: yeah, I was going to, but probably not tonight at this point, feel free to do it if you like
[07:04] <RenatoSilva> micahg: first patch is for debian package, second is for upstream, but purple-plugin-pack has its own bug tracking. I should have contributed that patch directly in their bug tracker but I'm lazy to create accounts everywhere, so I just saved it there and showed to them in IRC
[07:04] <ebroder> micahg: Ok, I'm looking for something to do, so I'll check it out
[07:05] <micahg> ebroder: if it's good, go ahead and close that other bug I mentioned in the changelog since the guy said it's fixed in that release
[07:05] <ebroder> micahg: Ok, thanks for the heads up
[07:06] <RenatoSilva> micahg: so it's pointless opening a bug in Launchpad, unless you guys patch it yourself and keep maintaining the patched version until convincing them to apply there in upstream
[07:06] <micahg> RenatoSilva: who's upstream?
[07:06] <RenatoSilva> micahg: the purple-plugin-pack developers?
[07:06] <micahg> RenatoSilva: didn't you talk to them already?
[07:07] <micahg> RenatoSilva: I just suggested opening a new Launchpad bug for it
[07:07] <RenatoSilva> micahg: I just linked to the LP bug in IRC, but no response
[07:07] <RenatoSilva> micahg: I'm just explaining that a new LP bug would be pointless
[07:08] <micahg> RenatoSilva: no, it's not, we can still patch it
[07:08] <micahg> RenatoSilva: we just prefer one bug per issue
[07:08] <RenatoSilva> micahg: so you patch it, and re-apply the patch every time a new upstream version is released?
[07:09] <micahg> RenatoSilva: no, the patch system will take care of that
[07:09] <RenatoSilva> micahg: sounds magic :)
[07:09] <micahg> or rather yes, but it's not a manual process :)
[07:11] <RenatoSilva> micahg: does that system detect if the patch was applied in upstream so it can stop re-patching?
[07:11] <micahg> RenatoSilva: yes
[07:11] <RenatoSilva> cool!
[07:13] <ebroder> micahg: I'm having a little trouble getting the debdiff to apply. Do you remember off hand if I need to pop the 3.0 (quilt) patches first?
[07:13] <ebroder> Never mind. Apparently that doesn't make anything better
[07:13] <micahg> ebroder: no, you don't need the diff, it should already be applied, it just needs to close
[07:14] <ebroder> micahg: No, I meant from the upgrade bug.
[07:14] <ebroder> But that's ok - I'll just play with it more
[07:14] <micahg> ebroder: oh :(
[07:14] <micahg> ebroder: in that case,yeah, I woudl think you need to pop the patches if it's source format 3
[07:15] <ebroder> micahg: Actually, I think that made things worse. I think I'll try just doing the upgrade myself and making sure I get his packaging changes :)
[07:15] <ebroder> ...wtf. How did we end up with patches to the upstream changelog in debian/patches/...
[07:16] <ebroder> I think this debdiff is just really confused
[07:19] <micahg> could be
[07:22] <ebroder> micahg: Oh, no - the debdiff was just built against Lucid's version. /me sighs
[07:23] <micahg> ebroder: yeah, I think the other bug's debdiff was the same
[07:27] <bilalakhtar> One thing to note: what-patch can be misleading at times
[07:28] <ebroder> No, this is definitely just a broken debdiff
[07:29] <RenatoSilva> micahg: bug 681680
[07:30] <micahg> RenatoSilva: ok, thanks
[07:59] <dholbach> good morning!
[08:18] <RenatoSilva> micahg: I just disagree with wishlist importance, it should be the same importance as the other bug (irc-more missing)
[08:19] <RenatoSilva> either of now, normal etc
[08:20] <RenatoSilva> imho --with-plugins="believed_to_exist" working is a bug not a feature
[08:21] <micahg> RenatoSilva: it's a new feature for the build system, hence wishlist
[08:22] <RenatoSilva> micahg: it's not for the debian build, but the plugin pack itself
[08:22] <micahg> RenatoSilva: doesn't matter
[08:22] <RenatoSilva> ok
[08:23] <micahg> RenatoSilva: feel free to file it upstream as well and link it in LP
[08:23] <RenatoSilva> ok
[08:27] <ebroder> tumbleweed += eleventy for bug #681693 :)
[08:54] <micahg> RenatoSilva: I was actually referring to the purple-pack-plugin trac tracker, not Debian, same maintainer sees bugs in both Debian and Ubuntu :)
[09:06] <RenatoSilva> micahg: I know, that comment in debian was before you said that
[09:06] <RenatoSilva> or regardless
[09:06] <micahg> RenatoSilva: k, np
[11:54] <ulysses> Hello, I have a debian/rules which doesn't work, what could be wrong? http://paste.ubuntu.com/536655/
[11:56] <ari-tczew> ulysses: what is the problem? show log
[11:57] <ulysses> ari-tczew: I don't have a log, a comment told meg on revu, that VER is empty, so it does nothing
[12:34] <Rhonda> ulysses: head -1 debian/changelog
[12:34] <Rhonda> ulysses: Is there actually a - in the version?
[12:35] <Rhonda> och
[12:36] <Rhonda> ulysses: That regexp seems to be quite broken, is this really what it's meant to do? It greps for exactly _one_ character before a - in the version string.
[12:36] <Rhonda> So it would match 2-3 but not 20-3 or 1.0.3-4
[12:38]  * Rhonda . o O ( there is no need for a log to catch that :P )
[13:31] <ulysses> Rhonda: the first line of changelog is : hupnp (0.0~svn77-0ubuntu1) natty; urgency=low
[13:31] <ulysses> Rhonda: sou you're right, the regexp is wrong:P I copied it from the wiki
[13:32] <Rhonda> which wiki?
[13:33] <ulysses> ubuntu wiki
[13:34] <ulysses> https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball
[13:40] <tumbleweed> ulysses: the regex is for 0+svn77-0ubuntu1 - modifiy it appropriately (or the version)
[13:41] <ulysses> I'm on it
[14:10] <Rhonda> ulysses: There is a different regex in there?
[14:10] <Rhonda> ulysses: [^-]+ != [^+]-
[14:11] <ulysses> I know
[14:11] <Rhonda> But that's your issue.
[14:11] <Rhonda> - isn't a quantifier. + in the wiki is.
[14:12] <Rhonda> I guess you want [^~]+
[14:13] <Rhonda> Oh. It seems to be really buggy in there.
[14:29] <tumbleweed> ulysses, Rhonda: oeer, my mistake, corrected
[14:47] <om26er> how can i prepare a branch for new upstream release of a package. i mean if i want to patch a package i pull it from bzr then make the changes and push. but how do i deal with a new release?
[14:53] <om26er> one guess i am thinking of is making a diff between the two releases and applying to the bzr branch locally and then push. anyone?
[16:54] <maxb> Can anyone recommend an example package that builds compiled extensions for multiple python versions, using dh7?
[17:01] <tumbleweed> maxb: almost all should
[17:02] <tumbleweed> maxb: example of mine: pystemmer
[17:02] <maxb> thanks
[17:50] <micahg> ScottL: is qjackctl meant to be a backport or an SRU?
[17:55] <ScottL> micahg, i could go either way, but i want you to know that the ubuntustudio team is planning on backporting fairly aggressively for lucid
[17:55] <ScottL> micahg, https://wiki.ubuntu.com/UbuntuStudio/Backports
[17:56] <micahg> ScottK: yeah, some of those might be able to be in -backports, but some will have to be in a PPA IMHO
[17:56] <micahg> ops
[17:56] <micahg> oops
[17:56] <micahg> ScottK: sorry again
[17:56] <micahg> ScottL: ^^^
[17:58] <micahg> ScottL: also, if it's going to be in -backports, it should be filed against the lucid-backports project, not Ubuntu
[18:05] <micahg> ScottL: is qjackctl broken in Lucid?
[18:22] <ScottL> micahg, no, it's not broken, but we would like to provide the improved functionality to ubuntu studio users
[18:23] <ScottL> micahg, which packages would you recommend to be in PPA and not backports?
[18:25] <micahg> ScottL: anything with a lot of rdepends
[18:45] <ScottL> micahg, i'm hoping that since we are only going from maverick to lucid we should experience too many dependency issues (except where they build directly against jack)
[18:50] <micahg> ScottL: I'm referring to when other packages depend on the ones that you want to backport
[19:01] <ScottL> micahg, oh, hmmmm.  good point, i'll have to think more on this then :P   thanks!
[19:09] <ScottK> Packages with rdepends on backports are OK, if you test all the rdepends.
[19:09] <ebroder> ScottK: I forget, do we need to worry about build-deps, or just binary deps?
[19:10] <ScottK> ebroder: Both, but runtime deps are more important.  For something that is a build-dep, but not a runtime dep a rebuild test is sufficient.
[19:24] <ScottL> micahg, how can i  file against the lucid-backports project if the bug is already filed on qjackctl (ubuntu)?
[19:24] <micahg> ScottL: also affects project
[19:24] <ScottL> micahg, hmmm, i was trying that...i'll have another go at it
[19:26] <ScottL> micahg, nevermind, got it...the term 'project' and qjackctl together were throwing me off a bit
[21:32] <ari-tczew> angelabad: if you're doing canna merge, please stop. BlackZ has requested a sync.
[21:32] <ari-tczew> I've updated comment on MoM.
[21:34] <angelabad> ari-tczew, ok, thanks!
[23:26] <ari-tczew> !backport | ari-tczew