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