[00:01] Laney: the page say: (last edited 06.08.2008 11:00:40 by localhost) [00:01] is that when you mark the minor changes box? [00:01] Laney, the same guide is located here: https://wiki.ubuntu.com/PackagingGuide/Complete [00:02] Elbrus: No, the page is a bunch of includes and I edited one of those, that's probably why [00:02] down in the Updating a package recipe [00:02] ah. [00:02] Laney, so idk, if you have to change both of them [00:03] pangloss: Not that one, but there are other calls too [00:04] o ok [00:05] jdong: RE your pa_tls_set() error, which version were you using? [00:10] How do I tell pbuilder to use the ubuntu name scheme for building packages? If it's even that way. [00:11] er...ubuntu naming scheme for building packages? [00:11] gouki: what do you mean? [00:11] Hobbsee, yes. [00:11] I mean .. [00:11] which is? [00:12] gouki: The package will get built with the correct name if the version in debian/changelog is correct [00:13] When I launch pbuilder create *.dsc, it creates the package with the following name: hydra_5.4-1_i386.deb [00:13] as nhandler says, the version number is controlled by debian/changelog [00:13] as is the distribution that the upload is targetting [00:13] gouki: What version do you have in debian/changelog? [00:14] you will need to rebuild the source package to regenerate the .dsc file that pbuilder looks at [00:14] 5.4-1, nhandler [00:14] ajmitch, but I was under the impression that the name contained 'ubuntu'. [00:15] gouki: The version should be 5.4-1ubuntu1 [00:15] nhandler, and that is changed on the changelog? [00:15] pbuilder doesn't change versions at all [00:16] ajmitch, I see. I didn't thought about changing it on changelog :S [00:16] gouki: If you use 'dch -i' it will take care of creating a new changelog entry for you with the correct version [00:16] nhandler, ok! I'll try that. [00:16] Thank you all! [00:16] You are welcome gouki [00:17] Ohh, got it. [00:17] nhandler: well, it's almost always correct. Sometimes it isn't. [00:17] Very true Hobbsee [00:17] The changelog was created when I ran dh_make. Should I delete the entry it created and just leave the one made by dch? [00:18] gouki: Is this a new package that isn't in the repositories yet? [00:18] nhandler, yes, it is. [00:19] gouki: What is the upstream version of the package? [00:19] right, changelogs made by dh_make target debian unstable, so you'll want 5.4-0ubuntu1 [00:19] 5.4, nhandler [00:19] gouki: Ok, so the version in your changelog should be '5.4-0ubuntu1' [00:19] ajmitch, OK! Got it. Thank you. [00:19] gouki: You should also target 'jaunty' instead of unstable [00:19] nhandler, but that is done manually, correct? [00:20] no [00:20] you need to write that in your changelog. [00:21] Hobbsee, OK. [00:21] Think I got it! :) [00:23] But as for the debian-related entry on debian/changelog, I should delete it? [00:23] yes [00:23] OK. Thank you all very much! [00:24] hey folks :) [00:25] Hi porthose [00:36] Is there a way to test the package and force it to install the 'Recommends:' packages? [00:37] gouki: Recommended packages are installed by default in intrepid [00:38] I'm running Hardy. I can create a pbuild environment for Jaunty and test it there, nhandler? [00:38] Not yet gouki. The Jaunty repositories haven't opened yet [00:38] jaunty is there, so you can create a pbuilder of it [00:39] james_w: I thought the repositories weren't complete yet [00:39] it's just the floodgates haven't opened yet [00:39] nhandler: intrepid has been copied [00:39] james_w: I thought they were still in the process of copying it over [00:40] nhandler: all done I believe [00:40] the current task is getting the Jaunty toolchain in place [00:40] james_w: Great. Any idea when it will be unfrozen? [00:40] when ^ is complete [00:41] JauntyReleaseSchedule says the 6th [00:41] It'll open when it's ready. [00:41] No reason you can't upload now though. Stuff will just sit in queue. [00:42] I know lintian was throwing warnings about jaunty in debian/changelog. Has this been updated? [00:42] No. [00:43] Patches welcome no doubt. [00:43] ScottK: Would that be lintian that would need to be patched? [00:44] nhandler: Yes. [00:44] nhandler: A patch for debchange in devscripts to default to jaunty wouldn't be bad either. [00:44] nhandler: debchroot will need updating too. [00:45] Thanks ScottK [01:02] nhandler, want help making those patches :-)? [01:04] The lintian one is easy enough even I could do it. [01:04] lintian has already been patched [01:04] Ah. [01:04] * NCommander needs to install dapper on a PowerPC box [01:04] most of them could be done within 5 minutes [01:04] It's in lintian's git tree [01:04] OK. [01:06] NCommander: Thanks, but I think I can handle it [01:06] yay for uploads to jaunty [01:06] Speaking of uploads [01:08] * ajmitch wonders if universe merges have been completed yet [01:08] ajmitch: You're a funny one today. [01:08] * NCommander reads MOTU council's archives [01:09] TheMuso: I'm sure that there can't be that many to work on [01:09] or at least most of the changes will have been pushed to debian, right? [01:09] Nah, only 400. [01:10] 400 isn't too bad [01:10] ScottK, I just discovered there was a backports mailing list [01:11] * TheMuso prepares jaunty chroots./ [01:12] * ajmitch preps his merge list & pbuilder [01:12] One can still bootstrap, since only toolchain packages have been updated so far. [01:14] TheMuso, no, the entire archive have been imported for jaunty [01:15] NCommander: entire debian archive, or do you just mean that intrepid has been copied? [01:15] Intrepid has been copied, you can debootstrap jaunty AFAIK [01:15] isn't that exactly what TheMuso just said? [01:15] NCommander: thats what I was saying. [01:16] * NCommander drinks more caffiene [01:18] wgrant: ok, I count 353 for jaunty at the moment, no doubt I'm missing some [01:18] (universe) [01:19] mdt sees 405 for universe, but that will include build1 [01:19] right [01:19] Can MoM be made to merge with experimental, since debian is frozen? [01:19] that's not necessarily safe [01:19] TheMuso, there are a lot of things in experimental we don't want [01:19] More to the point, is MoM set up that way? [01:19] ah right. [01:20] * NCommander notes that we're going to be hurting if Debian doesn't release soon [01:20] * ajmitch is only doing a comparison of debian unstable & jaunty universe to get those 353 [01:20] NCommander: no, I don't think we'll hurt [01:20] NCommander: There is? [01:20] http://qa.ubuntuwire.com/multidistrotools/universe.html is what I'm going by. [01:21] so what are the merge rules this time round? [01:21] ScottK, plenty of people upload SVN snapshots to experimental, I dunno if I want those over a stable release [01:21] NCommander: Agreed. [01:21] ajmitch, the main issue is that very few pakacagers are updating packages to sid to perserve the sid->lenny upgrade path [01:21] One always ought to know why something is in Experimental. [01:21] * NCommander thinks debian-changes has slowed to a trickle ATM [01:22] wgrant: you're right, it's the buildX revisions that's throwing off my count [01:23] since I'm only looking at versions which contain 'ubuntu' [01:23] It'd be nice if Lintian knew to treat those as Ubuntu builds too [01:23] Ah. [01:23] ScottK: So it doesn't turn them into build1ubuntu1? [01:23] mor that lintian doesn't complain about an unknown NMU or bad version [01:23] wgrant: That'd be dch, but as ajmitch says [01:24] Oh, damn, yes. [01:24] * NCommander *really* wished LP just supported normal binNMUing [01:24] Or binary rebuilds in Ubuntu terminology [01:24] * ajmitch wouldn't mind starting merging, apart from the whole contacting people part [01:26] ajmitch: You're welcome to all mine [01:26] NCommander: If you only accept source uploads, you can't have it both ways [01:27] StevenK, have a binary rebuild button on Launchpad, which causes sbuild to be called with the --binNMU switch [01:27] You assume Launchpad can actually call sbuild [01:27] It can retry failed builds. Retrying unfailed ones shouldn't be so much harder. [01:28] ScottK, that works by marking the record NEEDS BUILD from FAILED [01:28] Which means whatever magic process checks for builds sees it and retries it, hence why the build logs get clobbered [01:28] NCommander: OK. so mark it NEEDS BUILDS from DONE or whatever. [01:29] You can't [01:29] The version needs to change [01:29] Right [01:29] Picky, picky, picky. [01:29] Be it the source version or the binary version. [01:29] dpkg will recongize a version with a +b1 binary as being the same base version [01:29] Personally, I like buildX [01:29] ScottK: I'll have to get in before sebner, I guess [01:29] StevenK, when a binNMU is done, there is a specific catch in dak and dpkg to allow an out of sync binary and source [01:30] * NCommander notes that a binNMU is done internally by recreating the source package, and building that [01:30] So I have no wish to see this changed [01:31] I guess I don't have very many merges waiting. [01:31] I think I mostly sponsored stuff this last cycle. [01:31] Do we have anything that will give a list of packages not in Debian with new upstream versions? [01:31] I've spotted 3, 2 of which are mail [01:32] ScottK: Yes, gimme a sec. [01:33] http://qa.ubuntuwire.com/uehs/ shows them and Debian QA-maintained packages. [01:33] ScottK: of the 1 other package that's to be merged by you, it's a transitional package [01:33] wgrant: THanks. [01:33] ajmitch: As I said, not much. [01:34] I guess I won't have much to do then [01:34] what is the env var that will cause dpkg-buildpackage to tell gcc build with debug symbols? [01:34] probably something like FOO=-g [01:36] * NCommander looks forward to jaunty general archive open === _stink__ is now known as _stink_ [01:46] Using the debian/menu file I can create a shortcut, correct? [01:47] gouki: I believe the debian/menu file is mainly for debian. You want to install a .desktop file. [01:48] nhandler, do you know about documentation for that? [01:49] gouki: http://standards.freedesktop.org/desktop-entry-spec/latest/ [01:49] nhandler, thank you. [01:49] gouki: You should also read https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles#.desktop%20Files [01:51] nhandler, that last one is very interesting. Thank you. [01:52] You're welcome ;) [02:14] script does "apt-get source $PACKAGE" which creates a dir based on package+version- how can I figure out what the dir is so the script can cd into it? [02:49] anyone have a second to answer a question? [02:50] etiquette here is to ask the question and see if anyone answers it :) [02:51] hah [02:51] are there any tutorials on how to use dput to upload source packages to your ppa? [02:52] !ppa [02:52] With Launchpad's Personal Package Archives (PPA), you can build and publish binary Ubuntu packages for multiple architectures simply by uploading an Ubuntu source package to Launchpad. See https://help.launchpad.net/PPAQuickStart. [02:52] thanks ajmitch [02:53] pangloss: In general, PPA questions are best asked in #launchpad. [02:54] ScottK: Sorry, I figured this would be a good place to ask since its a motu related thing [02:56] pangloss: If it's a PPA, it's not. [04:06] Matthew Garrett is not the developer of Ultamatix, is he? http://nancib.wordpress.com/2008/11/02/pengs-links-for-sunday-2-november [04:07] no, he certainly isn't [04:08] he wouldn't have such scathing opinions of it if that were the case [04:08] If he were, it might actually do sane stuff, too [04:08] one would expect some sanity from him [04:08] his rants are always rather amusing [04:08] Hm [04:09] Matthew didn't write Automatix either [04:09] He would have been soundly beaten if he did [04:09] Ultamatix is the same crap from automatix. [04:09] The advertised "rewrite to make it safer" didn't happen [04:11] It's just so full of fail [04:12] motu [04:12] I was ALMOST sure he didn't do it, but I could be missing something because of my English. [04:13] youre recipes are broken >.< [04:13] gouki: you uploaded the package? [04:14] * ajmitch is getting nervous with the water dripping from the ceiling === nxvl_ is now known as nxvl [04:14] nxvl_, no I did not. Did think you'd be back. [04:14] Let me work on that. [04:16] This guide is broken https://wiki.ubuntu.com/PackagingGuide/Complete#Recipe:%20Updating%20An%20Ubuntu%20Package [04:16] bad motu.. [04:16] go sit in the corner! [04:16] What is broked pangloss ? [04:17] nhandler, first of all, step 4 skips a step [04:17] it does not show you how to install the old source package [04:17] secondly [04:17] pangloss: You don't install the old source package [04:17] extract is a better term? [04:17] Yeah [04:18] And I thought someone said they updated this recipe earlier today [04:18] because you need the brasero-0.5.2 directory [04:18] well it does not look very updated [04:18] and additionally [04:18] the package does not build when you;re finished [04:18] so [04:18] What messages are produced when you go to build? [04:19] 1 sec [04:19] here is what I can see, but I will send you the whole file too [04:19] nhandler: http://paste.ubuntu.com/66592/ [04:20] pangloss: They modified the dget command to be dget -xu. That should create the required folder [04:20] And how were you building that package pangloss ? [04:20] well I tried it two ways [04:21] first with pbuilder on my computer via 'sudo pbuilder build [04:21] ' [04:22] What version of Ubuntu is your pbuilder chroot? [04:22] and the second via launchpads servers incase my pbuilder was broken [04:22] its intrepid [04:22] I ran this [04:23] 'sudo pbuilder create --distribution intrepid \ --othermirror "deb http://archive.ubuntu.com/ubuntu intrepid main restricted universe multiverse"' [04:24] nhandler here is the whole FAILEDTOBUILD log http://paste.ubuntu.com/66593/ [04:25] I followed the recipe to a tee [04:26] pangloss: Give me a second to try and follow the recipe [04:27] pangloss: Are you running your own repo mirror? [04:28] nhandler: I have my own PPA [04:28] https://launchpad.net/~james-burkle/+archive [04:28] Is this the build log from the ppa? [04:28] yes [04:28] Ok [04:29] 3 e-mails, 3 fails [04:29] thanks for your time nhandler [04:30] pangloss: I actually have to head of to bed now. I'll finish going through the recipe tomorrow. Sorry. [04:31] ok, thanks [04:33] * Elbrus is also heading to bed [04:43] I uploaded my first package to REVU. I was wondering if someone could point out the stupid things I've done? :) [04:48] who took out the pbuilder completions? [05:01] gouki: give use a link [05:02] porthose, I've been looking at it, but still hasn't showed up. [05:03] NCommander: you can only upload to REVU now if you are a UUC or higher correct? [05:04] porthose: That's a proposal. It's not implemented yet. [05:05] So my dput.cf with anonymous works but it just has a delay? [05:05] gouki, 5-20 minutes [05:05] * NCommander can't remember what the crontab is currently set to [05:05] OK, NCommander. Thank you. [05:05] ScottK, can you upload a merge for me? [05:09] NCommander: I could, but it won't go anywhere. [05:09] Can it wait (it's a bit late) [05:09] Yeah [05:09] * NCommander is just attacking his list of merges [05:10] NCommander: Who plus 1'ed your MOTU app so far? [05:11] dholbach and [05:11] uhhhh [05:11] * NCommander blanks on the second name [05:11] nixternal? [05:11] THere we go [05:11] (yes) [05:12] wooo, midori merged [05:12] one down, four to go [05:13] Well hopefully soren, geser, or persia will give you an upcheck soon and you can upload yourself. [05:19] My first Jaunty upload is sitting in unapproved. [05:31] ScottK, did you do any checking in adept w.r.t. to version pinning? [05:32] NCommander: Not any successful checking. [05:33] * NCommander guesses adept might not have pinning support [05:33] * ScottK doens't normally use it, so doesn't know if it's unsupported or he didn't figure it out. [05:33] I'm guessing not as Adept 3 (for KDE4) was a total rewrite. === tjaalton_ is now known as tjaalton [05:35] ScottK, https://blueprints.edge.launchpad.net/intrepid-backports/+spec/backport-pinning-support [05:36] and it sucks [05:37] just wanted it out there [05:37] Hmmm ... Don't think the package went through :S [05:37] gouki, have you actually added any GPG keys to your Launchpad account (and then signed into REVU?) [05:37] NCommander: personally I prefer the debian backports.org system for this [05:37] hey guys, I've got a debdiff on here that seems to be helping a decent amount of people, I'm wondering what the next steps I should take are [05:37] but the chances of getting LP folks to implement that is zilch [05:37] https://bugs.edge.launchpad.net/ubuntu/+source/libgnomecanvas/+bug/272316 [05:37] Launchpad bug 272316 in libgnomecanvas "[regression, intrepid] redraw problems, patches from fedora" [Low,Confirmed] [05:38] My GPG is on LP, but I uploaded as anonymous. Do I need to sign in? [05:38] jdong, that's what we're trying to implement [05:38] I know that Intrepid's just released, and I have no problems waiting on it for a while, but just want to to know if there's anything I can do to help push it along [05:38] jdong, it needs both work on the GUI to be more user friendly (synaptic has pinning support, but I actually had to use the manual to find it), and it needs modification to Soyuz to pin the repo below 100 [05:38] jdong: We can ask. [05:39] ScottK, alternatively, we can drop a hack into APT (or ship a conffile) that pins the repo lower [05:39] Not a pretty solution, but better than no pinning [05:39] NCommander: Get the gui figured out first ... [05:39] NCommander: I'd rather have separate sections like the Debian implementation [05:39] ScottK, as I said, synaptic has support, I just need to figure out how to make it more "clean" [05:39] separate sections? [05:39] jdong, - ^ [05:40] * NCommander is just familar w/ pinning on the backports.org repo [05:40] NCommander: yeah, like Debian backports.org puts each application in its own section [05:40] WHen did that happen [05:40] NCommander: i.e. deb http://backports.org/... all [05:40] specifies every backport [05:40] or you can specify ... gimp firefox bzr [05:40] Uhhh O_O; [05:40] unless they removed that abilitiy within the past 2 years [05:40] oh, you mean having to manually install each package, right? [05:41] (apt-get -t etch-backports intsall *package* [05:41] That sounds more like a hack. [05:41] wgrant: It's better than having to enable all of backports to get one package. [05:41] wgrant: do you think pinning is solid enough for selective backport picking? [05:41] wgrant, no, he's referring to the pinning used by default on the backports repositry [05:41] Well, the apt-get has the -t branch, which sets the pin on a repo to 990 [05:42] NCommander: which doesn't work with source, but still that's another point [05:42] By default apt will ignore anything with a low enough pin prioity (under 200) [05:42] I'm not sure if pinning will work well here, but there must be a better solution [05:42] Yasumoto: If you believe the patch addresses the when of a SRU - https://wiki.ubuntu.com/StableReleaseUpdates - you can follow that process [05:42] My solution is we pin the backport repo to 100 so backports will not automatically clobber main packages [05:42] I'd like something like add/remove programs for browsing backports [05:42] And then in synaptic, have a Backport Available section [05:42] NCommander: but then a user can have a weird mix of backports and non-backports that we don't support [05:43] NCommander: I'm SURE our dependencies aren't specified well enough for this to be robuts [05:43] robust* [05:43] We already don't support backports, and suggest pinning in our directions [05:43] well we suggest it as a hack. [05:43] jdong, when you have a -t option set, the dependencies are pulled from the backport repo [05:43] NCommander: and how confident are you that all dependencies are represented properly? :) [05:43] That's a bug and deserves an upload to fix ;-) [05:43] Ohhh. [05:44] * ScottK stops typing since NCommander took the words out of his mouth. [05:44] NCommander: hi! can you look in the revu queue why is hydra not being showed? [05:44] NCommander: lol I recall my days of mixing testing and sid this way and NASTY things happened. [05:44] jdong, most people only enable backports for a single package or two [05:44] NCommander: [citation needed] [05:44] jdong: Key difference is that we're building against the target release and so it should be OK. [05:45] By having them only install that package and any necessary dependencies should pulled only [05:45] ScottK: alright, if you feel it's okay I have no bojections to it [05:45] jdong, thats how backports.org works [05:45] stefanlsd: alright, sweet. thanks :) [05:45] ok, so if a-backport depends on b-backport, and user selects a-backport, but later b-backport has an update available, what happens? [05:45] gouki: you need to subscribe you to revu-uploaders [05:45] gouki: https://edge.launchpad.net/~revu-uploaders [05:45] does this middle dependency get pulled in? [05:46] nxvl, er, thats a little out of date :-) [05:46] nxvl, we haven't allowed that in ages [05:46] jdong, err, huh? [05:46] jdong, if at the time of installation a backport requires an updated dependency (that is package a depends on package b which is > than whats in hardy, then that package will get pulled in) [05:47] NCommander: ok, user installs dvdrip backport which pulls in new x264 backport. Two weeks later a critical security bug appears in x264 and we update it. [05:47] NCommander: what? revu-uploaders? [05:47] NCommander: does this automatically get pulled in with the pinning config? [05:47] nxvl, yeah, that's been unused for months now [05:47] I don't think so [05:47] jdong, no [05:47] I don't think you can pin a specific repo [05:47] NCommander: well, that's broken IMO. [05:47] I just don't pin [05:47] jdong, our current methodology is also broken. ONe bad backport and we can break a load of users not using an existing package [05:48] coppro, you can, you can pin specific packages and repos [05:48] gouki: then you don't [05:48] NCommander: Not implemented in Adept, but upstream is open to implementing for Jaunty if we can get a design done. [05:48] :P [05:48] NCommander: agreed. but I'm not happy with pinning as a proposed solution. [05:48] nxvl, haven't. [05:48] oh so you can pin a package from updating from a specific repo? [05:48] NCommander: so, can you check why is that package not being listed please [05:48] gouki, are your GPG keys on Launchpad properly set? [05:48] (what was the package?) [05:48] * coppro eagerly awaits the oo.o3 backport [05:48] NCommander: and please rewrite blueprints in a non-implementation-specific manner. [05:49] Argh [05:49] NCommander, yes, they are. [05:49] gouki, have you actually logged into REVU since last updating your keys? [05:49] pinning is not necessarily the *ONLY* way to accomplish what we want, and in fact rigth now I disagree with implementation by pinning. [05:49] I DO want the behavior of selective backports [05:49] jdong: OK. Then let's agree on that. [05:49] let's keep the spec at that until we figure out a sane implementation [05:49] * NCommander edits the spec [05:49] NCommander, yes. [05:49] you could give each backport its own repo [/badidea[ [05:50] jdong: I do think pinning would be an improvement over the current situation, but certainly if we can do better ... [05:50] coppro: not any worseofanidea than pinning [05:50] coppro: the problem is shared dependencies [05:50] actually... what *if* each backport was in a separate repo? [05:50] Well, maybe we can get a security-backports repo then [05:50] can't you do it like PPAs do and allow dependency on specific other ones only? [05:50] jdong: Then we would murder you! [05:50] Or just make sure security annoucements are released [05:50] wgrant: lol is it that unreasonable an idea other than launchpad dev overhead to implement? [05:51] coppro: exactly [05:51] that's what I'm thinking. What if it was like each backport was in an independent "PPA" [05:51] and the GUI for selecting backports simply enables each one of these. [05:51] then it would be awesome [05:52] * NCommander gets an idea [05:52] uh oh [05:52] Then you need to add six or seven PPAs if you backport something large [05:52] there would need to be some magic on the implementation side to get this workflow easier for archive admins [05:52] We can use APT pins [05:52] and the difference is? [05:52] But we need to expand the scope [05:52] we could also modify apt [05:52] Every time you install a package, we need to pin that package to 200, so it will get installed and ugpraded automatically [05:53] StevenK: well why is that a horrible thing if a UI represents the dependency properly? [05:53] jdong: Because it means Software Sources turns into a cesspoll [05:53] When a security fault is found, we modify the package to explicately depend on the new version in backports. As long as the installed package is pinned, apt-get dist-upgrade will pull the updated dependency [05:53] ^- jdong [05:53] cesspool [05:54] That means APT need a way to programmability change pins [05:54] NCommander: can't we still run into situations where one bad backport breaks more backports? [05:54] here's a worse idea than making every backport a PPA [05:54] jdong, no [05:54] jdong, ok, if we have a depends on a (>= 0.2) [05:54] modify apt to allow an archive not to be selected for default updates, and then make it so that it will update if it is a package from that repo or depended on by one in it [05:55] And APT sees 0.2, and 0.22, but the repo 0.22 is pinned below 200 [05:55] It will install 0.2 over 0.22 [05:56] If we ever find a security fault in a backported version, we simply change the dependencies in the rdepends that we've backported to pull in the newer dependencies explicately [05:56] well I still don't personally like the idea of one big monolithic backports pool [05:56] I think using pinning is a HACK to make something MONOLITHIC appear MODULAR. [05:56] I can't see the soyuz developers changing that anytime soon though [05:56] * coppro likes his idea, even though it's mostly ridiculous [05:56]