[00:39] bdrung: it looks like since the binary package has the same name, everything should be fine [00:39] micahg: and the source doesn't differ? [00:40] bdrung: what do you mean, it's from the same upstream AFAICT [00:40] micahg: the debian/ directory. maybe some packaging difference that we need to carry? [00:43] 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 === freeflyi1g is now known as freeflying [00:49] bdrung: yeah, I don't see anything special in the packaging, should I just comment on the bug [02:11] is there a way to 'apt-get source ${package}' but get a particular release instead of changing the sources.list? [02:13] for instance, i wanted to build qjackctl from maverick but for lucid and i was in a lucid install [02:14] ScottK: pull-lp-source [02:14] oops [02:14] ScottL: pull-lp-source [02:14] ScottK: sorry :( [02:18] 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] ScottL: you can specify any release or pocket [06:20] what's the purpose of the 'linux' package and why should I use it? [06:21] RenatoSilva: linux is the source package for the Ubuntu kernel [06:22] 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] source package as in containing source code? [06:25] 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] 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] RenatoSilva: The upgrade does only pull in the latest version if there is a dependency chain to it. [06:26] 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] ebroder: I have linux-image-generic, so why have tow packages for the same thing? [06:27] It's not two for the same thing. [06:27] "It serves the same purpose as the "linux" package" [06:27] It is in this case. linux depends on linux-image depends on linux-image-generic [06:28] RenatoSilva: No, it doesn't. [06:28] "The upgrade does only pull in the latest version if there is a dependency chain to it." [06:28] 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] I don't understand this [06:29] Take a look at this page: http://packages.ubuntu.com/natty/linux-image [06:29] Should I use 'linux'? [06:29] What exactly don#t you understand in it? [06:29] That depends. [06:30] If you don't see a need for it and be happy with linux-image-generic, then have that. [06:31] With linux-image-generic, you always get the -generic flavor of the kernel. [06:31] With linux you can instead also have the -server or -virtual flavour. [06:32] Hmm, or not. [06:33] Because linux has a versioned depends on linux-image? [06:33] Confusing. %-) [06:34] 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] So it's more a convenience reason, me thinks. [06:35] 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] It can't get removed automatically because you might still be running it. [06:37] there isn't any scheduling feature in apt for removing after reboot? [06:37] so I will always have to remove old kernels forever? ok [06:39] 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] I tried to come up with a possibility why it might exist. [06:42] At one point it also pulled in linux-headers; does it still do that? [06:44] None of linux, linux-image, or linux-image-generic pull in headers [06:44] Or linux-generic [06:50] 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] RenatoSilva: I replied in teh bug about that [06:58] 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] 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] RenatoSilva: who, what/ [07:02] micahg: Did you say you were going to look at bug #592538? [07:02] Launchpad bug 592538 in rhythmbox-radio-browser (Ubuntu) "Please update the package to 2.1.1" [Undecided,Confirmed] https://launchpad.net/bugs/592538 [07:04] ebroder: yeah, I was going to, but probably not tonight at this point, feel free to do it if you like [07:04] 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] micahg: Ok, I'm looking for something to do, so I'll check it out [07:05] 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] micahg: Ok, thanks for the heads up [07:06] 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] RenatoSilva: who's upstream? [07:06] micahg: the purple-plugin-pack developers? [07:06] RenatoSilva: didn't you talk to them already? [07:07] RenatoSilva: I just suggested opening a new Launchpad bug for it [07:07] micahg: I just linked to the LP bug in IRC, but no response [07:07] micahg: I'm just explaining that a new LP bug would be pointless [07:08] RenatoSilva: no, it's not, we can still patch it [07:08] RenatoSilva: we just prefer one bug per issue [07:08] micahg: so you patch it, and re-apply the patch every time a new upstream version is released? [07:09] RenatoSilva: no, the patch system will take care of that [07:09] micahg: sounds magic :) [07:09] or rather yes, but it's not a manual process :) [07:11] micahg: does that system detect if the patch was applied in upstream so it can stop re-patching? [07:11] RenatoSilva: yes [07:11] cool! [07:13] 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] Never mind. Apparently that doesn't make anything better [07:13] ebroder: no, you don't need the diff, it should already be applied, it just needs to close [07:14] micahg: No, I meant from the upgrade bug. [07:14] But that's ok - I'll just play with it more [07:14] ebroder: oh :( [07:14] ebroder: in that case,yeah, I woudl think you need to pop the patches if it's source format 3 [07:15] 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] ...wtf. How did we end up with patches to the upstream changelog in debian/patches/... [07:16] I think this debdiff is just really confused [07:19] could be [07:22] micahg: Oh, no - the debdiff was just built against Lucid's version. /me sighs [07:23] ebroder: yeah, I think the other bug's debdiff was the same [07:27] One thing to note: what-patch can be misleading at times [07:28] No, this is definitely just a broken debdiff [07:29] micahg: bug 681680 [07:29] Launchpad bug 681680 in purple-plugin-pack (Ubuntu) "Build should fail on invalid plugins" [Undecided,New] https://launchpad.net/bugs/681680 [07:30] RenatoSilva: ok, thanks === hannesw_ is now known as hannesw [07:59] good morning! [08:18] micahg: I just disagree with wishlist importance, it should be the same importance as the other bug (irc-more missing) [08:19] either of now, normal etc [08:20] imho --with-plugins="believed_to_exist" working is a bug not a feature [08:21] RenatoSilva: it's a new feature for the build system, hence wishlist [08:22] micahg: it's not for the debian build, but the plugin pack itself [08:22] RenatoSilva: doesn't matter [08:22] ok [08:23] RenatoSilva: feel free to file it upstream as well and link it in LP [08:23] ok === hrw|gone is now known as hrw [08:27] tumbleweed += eleventy for bug #681693 :) [08:27] Launchpad bug 681693 in ubuntu-dev-tools (Ubuntu) "[wishlist] u-d-t config file" [Wishlist,New] https://launchpad.net/bugs/681693 [08:54] 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] micahg: I know, that comment in debian was before you said that [09:06] or regardless [09:06] RenatoSilva: k, np === hanska is now known as dapol === dapol is now known as dapal [11:54] Hello, I have a debian/rules which doesn't work, what could be wrong? http://paste.ubuntu.com/536655/ [11:56] ulysses: what is the problem? show log [11:57] ari-tczew: I don't have a log, a comment told meg on revu, that VER is empty, so it does nothing [12:34] ulysses: head -1 debian/changelog [12:34] ulysses: Is there actually a - in the version? [12:35] och [12:36] 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] 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 ) === yofel_ is now known as yofel [13:31] Rhonda: the first line of changelog is : hupnp (0.0~svn77-0ubuntu1) natty; urgency=low [13:31] Rhonda: sou you're right, the regexp is wrong:P I copied it from the wiki [13:32] which wiki? [13:33] ubuntu wiki [13:34] https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball [13:40] ulysses: the regex is for 0+svn77-0ubuntu1 - modifiy it appropriately (or the version) [13:41] I'm on it [14:10] ulysses: There is a different regex in there? [14:10] ulysses: [^-]+ != [^+]- [14:11] I know [14:11] But that's your issue. [14:11] - isn't a quantifier. + in the wiki is. [14:12] I guess you want [^~]+ [14:13] Oh. It seems to be really buggy in there. === udienz is now known as udienz-makan === udienz-makan is now known as udienz [14:29] ulysses, Rhonda: oeer, my mistake, corrected [14:47] 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] 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? === Lutin is now known as Guest27846 [16:54] Can anyone recommend an example package that builds compiled extensions for multiple python versions, using dh7? === hrw is now known as hrw|gone [17:01] maxb: almost all should [17:02] maxb: example of mine: pystemmer [17:02] thanks === Guest27846 is now known as Lutin [17:50] ScottL: is qjackctl meant to be a backport or an SRU? [17:55] 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] micahg, https://wiki.ubuntu.com/UbuntuStudio/Backports [17:56] ScottK: yeah, some of those might be able to be in -backports, but some will have to be in a PPA IMHO [17:56] ops [17:56] oops [17:56] ScottK: sorry again [17:56] ScottL: ^^^ [17:58] ScottL: also, if it's going to be in -backports, it should be filed against the lucid-backports project, not Ubuntu [18:05] ScottL: is qjackctl broken in Lucid? === RoAk is now known as andreserl [18:22] micahg, no, it's not broken, but we would like to provide the improved functionality to ubuntu studio users [18:23] micahg, which packages would you recommend to be in PPA and not backports? [18:25] ScottL: anything with a lot of rdepends [18:45] 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] ScottL: I'm referring to when other packages depend on the ones that you want to backport [19:01] micahg, oh, hmmmm. good point, i'll have to think more on this then :P thanks! [19:09] Packages with rdepends on backports are OK, if you test all the rdepends. [19:09] ScottK: I forget, do we need to worry about build-deps, or just binary deps? [19:10] 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] micahg, how can i file against the lucid-backports project if the bug is already filed on qjackctl (ubuntu)? [19:24] ScottL: also affects project [19:24] micahg, hmmm, i was trying that...i'll have another go at it [19:26] micahg, nevermind, got it...the term 'project' and qjackctl together were throwing me off a bit [21:32] angelabad: if you're doing canna merge, please stop. BlackZ has requested a sync. [21:32] I've updated comment on MoM. [21:34] ari-tczew, ok, thanks! [23:26] !backport | ari-tczew [23:26] ari-tczew, please see my private message