[06:12] <tcoread> date -u
[07:01] <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:02] <dholbach> who else? come on, don't be shy! :)
[07:02] <juliend> o/
[07:02]  * Koterpillar *
[07:03] <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:04] <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:06] <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:07] <Koterpillar> Currently, sreadahead conflicts with readahead.
[07:08] <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:09] <dholbach> https://wiki.ubuntu.com/SeedManagement has more detail about that
[07:09] <Koterpillar> Do I remove Conflicts: readahead?
[07:09] <dholbach> no
[07:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <Rail> I have a very descriptive get-orig-source :)
[07:27] <dholbach> that sounds like a good idea :)
[07:28] <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:29] <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:30] <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:31] <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:32] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <maxpaguru> dholbach:thanks, i need to know better. what to reeD or tutorials ?
[07:45] <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:46] <dholbach> any more questions?
[07:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <juliend> perfect, thanks
[07:53] <dholbach> nice
[07:53] <dholbach> any more questions? :)
[07:54] <dholbach> I'm immensely proud of all the great work you guys are doing!
[07:54] <FuturePilot> :)
[07:55] <maxpaguru> can you give us an example of package updating where some of the patches fail and how to handle the problem?
[07:57] <dholbach> just a sec
[07:58] <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:59] <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!
[08:00] <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:01] <maxpaguru> Rail: thanks a lot!
[21:50] <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:57] <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:58] <james_w> 6am UTC
[21:59] <ryanprior> That seems like a really silly time. >.>
[21:59] <nhandler> ryanprior: The times alternate each week