[06:12] date -u === tcoread1 is now known as tcoread [07:01] Good morning everybody! [07:01] who' all here for the packaging training session? :-) [07:01] is this an open session? [07:01] yes [07:01] ok [07:01] * micahg is here for packaging [07:01] * Rail is here too [07:02] who else? come on, don't be shy! :) [07:02] o/ [07:02] * Koterpillar * [07:03] alright - I hope you all brought questions [07:03] do we have any questions about something to do with packaging or ubuntu development in general? [07:03] * Koterpillar yes [07:03] Koterpillar: cool - go ahead! [07:04] How can I replace a package A with B so that ones dependent on A are satisfied? [07:04] Koterpillar: can you illustrate that case a bit? [07:06] just so we all know what we're talking about [07:06] ubuntu-desktop depends on readahead, but there is sreadahead which i'd like to replace readahead with, but not remove ubuntu-desktop. [07:07] Currently, sreadahead conflicts with readahead. [07:08] there's two ways to achieve this, you could either change ubuntu-desktop (which is a special case) to depends on either readahead | sreadahead or you could change sreadahead to say Provides: readahead (if they indeed offer identical functionality) [07:08] ubuntu-desktop is a special case because it is not modified by hand, but created from seed files [07:09] https://wiki.ubuntu.com/SeedManagement has more detail about that [07:09] Do I remove Conflicts: readahead? [07:09] no [07:10] "Conflicts:" says that both packages ship the same file which dpkg can't deal with [07:10] http://www.debian.org/doc/debian-policy/ch-relationships.html has more detail about what conflicts / replaces / provides / etc are for [07:10] and http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.2 [07:11] Koterpillar: I'm curious, what does sreadahead offer that readahead doesn't? [07:11] (I haven't looked into either of them) [07:11] I've seen a news about it doing better with SSD, wanted to try. [07:11] ok [07:12] do we have any other questions already? [07:12] what do you do with the debian patches when a new version of the program is released? I know most of the time they won't patch anymore. [07:12] FuturePilot: you need to check if you need to update them or if they can be dropped (because they were included upstream already) [07:12] Well, it depends on whether the patch has been commited upstrea in the new version [07:13] And any good maintainer will send patches upstream for inclusion. [07:13] dholbach: doctormo and I are working on the wizardpen driver.. [07:13] TheMuso is absolutely right... the earlier you get stuff upstream, the less pain you have :) [07:13] trying to get it to Just Works status and included in main [07:13] by karmic [07:14] ah, I see [07:14] ethana2: just a sec [07:14] ....there's one dependency that's giving us trouble, and he's going to make a 64 bit ubuntu install to help us pin it down [07:14] dholbach: k [07:14] Mind you, there are sometimes patches for configuration settings that you want to keep, in which case you need to refresh the patch somehow. [07:14] sometimes you will see that people use names for their patches like 50_from_cvs_............., so it's obvious that they can be dropped with the new release [07:14] https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines is really really helpful in that regard too [07:14] That, and documenting that the patch was from upstream in the changelog is good. [07:15] so if somebody else comes across your package they know where the patch comes from and where the discussion about it is happening [07:15] If the patch is from a git repo for example, its also useful to keep the git commit message in the header of the patch./ [07:15] sometimes "refreshing a patch for a new upstream version" is easy enough, because you just need to apply it again and you'll have some offsets and some fuzz, but sometimes it's really unpleasant work [07:15] And patch systems like dpatch alow a description of the patch to be added in the header of the patch. [07:16] TheMuso: don't all patch systems allow that? [07:16] dholbach: Not in an official sense. Dpatch actually has commented lines where you add the author of the patch, and a description. [07:16] Sure you can add it to headers of other patches and it will be ignored, which is ok as well. [07:16] "patch" itself can deal with ## comment ..... above the diff ..... line [07:17] ah ok [07:17] yes [07:17] :-) [07:17] Yeah. [07:17] FuturePilot: problem solved? :) [07:17] https://wiki.ubuntu.com/Bugs/Upstream has more info for sending stuff upstream [07:17] dholbach: yeah I think I get it now. thanks [07:17] ROCK [07:18] ethana2: so... what is giving you guys trouble? :) [07:18] xautomation is a virtual package [07:18] ...I don't think it's a problem on x32... not sure [07:18] xautomation is evidently a dependency of wizardpen, which we're trying to package [07:19] on 64 bit ubuntu, it won't build because it can't get that package [07:19] I've checked my sources.list, it can get to source files [07:19] daniel@bert:~$ apt-cache show xautomation | grep ^F [07:19] Filename: pool/universe/x/xautomation/xautomation_1.03-1_amd64.deb [07:19] daniel@bert:~$ [07:19] ? [07:19] hmm [07:19] it seems to exist on 64bit Ubuntu [07:19] I'll get a pastebin link to my build errors [07:19] sure [07:19] http://paste.ubuntu.com/205915/ [07:20] and... http://paste.ubuntu.com/205930/ [07:20] ok the second one is the important one at this point [07:20] did you enable universe and multiverse for your pbuilder? [07:20] not specifically [07:21] do something like this [07:21] daniel@miyazaki:~$ cat .pbuilderrc [07:21] COMPONENTS="main universe multiverse restricted" [07:21] daniel@miyazaki:~$ [07:21] and recreate the pbuilder [07:21] k [07:21] https://wiki.ubuntu.com/PbuilderHowto has more info [07:21] might be the problem that xautomation is in universe [07:21] looking at the first pastebin now [07:21] don't bother I think [07:22] ok, so I want a ~/.pbuilderrc file [07:22] containing [07:22] The first one doesn't seem to be a problem, except for some lintian warnings. [07:22] COMPONENTS="main universe multiverse restricted" [07:22] first one just looks like a keysigning error [07:22] to avoid "Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address" you can run 'update-maintainer' from the ubuntu-dev-tools package [07:22] TheMuso: maybe a gpg thing, but yeah [07:22] https://wiki.ubuntu.com/DebianMaintainerField has the reason for it [07:22] * ethana2 saves .pbuilderrc file [07:23] ok, I'm just going to try to build this again, carry on [07:23] dh-clean-k-is-deprecated: just use dh_prep in debian/rules instead [07:23] oh, ok, I should do that now [07:23] * ethana2 navigates to debian/rules [07:23] configure-generated-file-in-source config.log config.status: just remove them in the clean target in debian/rules [07:23] debian-files-list-in-source: this is weird :-) [07:24] other than that there doesn't seem to be anything wrong from as far as I can tell [07:24] do we have any other questions? :) [07:24] The upstream tarball doesn't contain LICENSE file, but the author declared LGPL on the Homepage. Should I repack the tarball and put a copy of license file? [07:25] Rail: I'd ask the upstream developers to put a license file in there, then repacking for just this one release is fine [07:25] dholbach: already done, but no feedback from the author :( [07:26] ok, that's fine then - just make sure you mention it in debian/changelog very prominently so reviewers and archive admins know why the md5sums of the original tarball and yours don't match [07:27] I have a very descriptive get-orig-source :) [07:27] that sounds like a good idea :) [07:28] any more questions? :) [07:28] ope, it failed again :( [07:28] ok, I made that file... [07:28] but it gives me the same error [07:28] I think you might need to recreate the pbuilder [07:29] ohhh [07:29] sudo pbuilder update --distribution karmic --override-config [07:29] or something [07:29] ok yeah I think I forgot that part [07:29] karmic? [07:29] I'm on Jaunty, does that matter? [07:29] jaunty might be fine for now [07:29] k [07:29] should I still use 'karmic' in that command? [07:30] but if you want to get it into karmic, it only makes sense if you test it on karmic first :) [07:30] ahh [07:30] hmm [07:30] https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases explains how to do that in a sane way [07:30] I was going to wait for alpha 3 and then install karmic over my intrepid [07:30] I always dual boot two ubuntu's [07:31] ethana2: you can use a vm too [07:31] dholbach: yeah [07:31] the page explains various options [07:31] cool [07:31] well, I don't think I'm nearly to the point where it becomes a matter of testing [07:32] but I'll certainly test with karmic before I send it in to REVU [07:32] or anything of that nature [07:32] excellent [07:32] do we have any more problems some of you ran into? [07:34] what about the things we just discussed, did they raise any questions or eyebrows? [07:34] * ajmitch has a whole truckload of patches to check through & tag :) [07:35] Sometimes I want to override lintian warnings. Is there any policy or good practices on this subject? [07:35] Rail: a warning shouldn't need to be overridden [07:35] do you mean an error? [07:35] Rail: I usually just leave them there to remind me (or others) to fix them at some stage :) [07:36] ethana2: no, just annoying warnings, like no-upstream-changelog [07:36] Rail: yeah, the only proper thing to do is fix their cause [07:36] * ajmitch would only override where necessary [07:37] ok, pbuilder updated and stuff, attempting to build the package again [07:37] http://lintian.debian.org/manual/ch2.html#s2.4 [07:37] if you really want to [07:37] I normally wouldn't bother :) [07:38] well, it went to make it [07:38] ..but failed [07:38] Rail: but I agree... no-upstream-changelog is really annoying :) [07:38] ..due to a bug in the code [07:38] especially considering how much space on the CDs we waste because of changelogs :-) [07:38] ohhhh, stricter gcc [07:39] blast, I have to find a way to fix the code here [07:39] dholbach: thanks, going to read that manual :) [07:39] any more questions? :) [07:39] how to check in general if a patch that won't fix anymore need to be dropped or update? and then which steps? [07:40] so let's assume there's version 6.5 of something and we have a bunch of patches and we update to 7.0 and applying some of the patches fails [07:41] what you can do to easily test if a patch was applied upstream as-is, is run patch -p1 --dry-run -R < some-patch-file [07:41] it won't make changes to the code, and will try to "revert" the patch again [07:42] if you have complicated patches were upstream used some parts and neglected others, it's a bit more tricky [07:42] or if stuff was fixed in a different way [07:42] another tool I find useful is diffstat - you can run it on a patch file and quickly get an overview over what's changed in the patch [07:43] 'night, that was very helpful, rock on [07:43] maxpaguru: was that answer helpful? [07:43] porting patches forward over multiple versions gets tedious, which is why it'd a great idea to pass stuff to debian & to upstream [07:44] dholbach:thanks, i need to know better. what to reeD or tutorials ? [07:45] maxpaguru: https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines https://wiki.ubuntu.com/Bugs/Upstream and generally https://wiki.ubuntu.com/MOTU/GettingStarted :-) [07:45] dholbach: ok! [07:45] :-) [07:46] any more questions? [07:47] ajmitch, TheMuso: it's weird that nobody says "review my package please", isn't it? :) [07:47] hehe :) [07:47] dholbach: Yeah. [07:47] sometimes when I'm watching a package build I see warnings about uselessly linked libraries or something. What is that? [07:48] Sometimes, executables or libraries are linked against other libraries when they don't need to be. [07:48] dholbach: everybody pushes to Debian NEW :P [07:48] dholbach: I'll have to produce a few for you to review then :) [07:48] FuturePilot: that's something the upstream maintainers should dive into - it's if you specify stuff in Makefiles just to be safe :) [07:48] FuturePilot: It won't break anything if they do, but may introduce unnecessary dependencies to a package, so if they can be fixed up, its worth doing so. [07:49] TheMuso: does linking with -Wl,as-needed (or however you specify it) help with that? [07:49] ah ok, so probably notify upstream? [07:49] FuturePilot: yes [07:49] dholbach: I don't know. [07:50] I've just fixed up the autofoo and sent a patch upstream. [07:50] dholbach: hi, is there a tutorial somewhere about packaging perl projects from CPAN ? [07:50] --as-needed [07:50] --no-as-needed [07:50] This option affects ELF DT_NEEDED tags for dynamic libraries men‐ [07:50] tioned on the command line after the --as-needed option. Normally, [07:50] the linker will add a DT_NEEDED tag for each dynamic library men‐ [07:50] tioned on the command line, regardless of whether the library is [07:50] actually needed. --as-needed causes DT_NEEDED tags to only be [07:50] emitted for libraries that satisfy some symbol reference from regu‐ [07:50] lar objects which is undefined at the point that the library was [07:50] linked. --no-as-needed restores the default behaviour. [07:50] that's from the ld manpage... I've seen it in a couple of packages already, and I've seen it break a very few packages on some architectures [07:51] ah ok. [07:51] so it might be a suitable workaround in some cases [07:51] juliend: I'm delighted to tell you that we're going to have some perl wizards here in a few weeks that are going to talk about exactly that! [07:51] great :) [07:51] 23rd July, 00:00 UTC, gwolf and jawnsy, Packaging Perl Modules [07:52] the problem is not seeing breakage until you hit specific areas of a program that need those missing functions [07:52] ajmitch: that too [07:52] juliend: for now I'd just tell you to review existing perl modules and how they are packaged [07:52] http://www.debian-administration.org/articles/78 might be helpful too [07:53] perfect, thanks [07:53] nice [07:53] any more questions? :) [07:54] I'm immensely proud of all the great work you guys are doing! [07:54] :) [07:55] can you give us an example of package updating where some of the patches fail and how to handle the problem? [07:57] just a sec [07:58] sudo apt-get install devscripts; dget -xu https://launchpad.net/ubuntu/karmic/+source/yelp/2.27.1-0ubuntu2/+files/yelp_2.27.1-0ubuntu2.dsc; dget -xu https://launchpad.net/ubuntu/karmic/+source/yelp/2.27.2-0ubuntu1/+files/yelp_2.27.2-0ubuntu1.dsc [07:58] robert_ancell had to "refresh" the patches because they didn't apply any more in their current form [07:58] maxpaguru: maybe this log will help https://wiki.ubuntu.com/Packaging/Training/Logs/2009-04-16 [07:59] ok, let's wrap up [07:59] dholbach:thank you very much! [07:59] thanks a lot everybody for attending and your clever questions! [08:00] logs will be up soon [08:00] dholbach: thanks again [08:00] see you in #ubuntu-motu and #ubuntu-devel :) [08:00] have a great day :-) [08:01] Rail: thanks a lot! === yofel_ is now known as yofel === pleia2 changed the topic of #ubuntu-classroom to: Ubuntu Classroom || https://wiki.ubuntu.com/Classroom || https://lists.ubuntu.com/mailman/listinfo/ubuntu-classroom || Upcoming: Thu July 16 @ 18:00 UTC: Mono packaging: quick, easy, and awesome; July 23 @ 00:00 UTC: Packaging Perl Modules || Run 'date -u' in a terminal to find out the UTC time === worellana_ is now known as ramses-sv === alexbobp_ is now known as alexbobp === jarlen_ is now known as jarlen === Quintasan_ is now known as Quintasan [21:50] Hello there. Anybody helping with packaging questions yet? [21:50] (I'm currently working on a nearly-completed package that I hope to get into Ubuntu for Karmic if possible. =D ) === olujicz_ is now known as olujicz [21:57] ryanprior: #ubuntu-motu is the place to go [21:57] james_w: I thought that there was a packaging tutorial coming up soon? [21:57] there was one this morning [21:57] Ah, what time? [21:57] (last night for those on the West Coast US) [21:58] 6am UTC [21:59] That seems like a really silly time. >.> [21:59] ryanprior: The times alternate each week