1 [07:01] <dholbach> Good morning everybody!
   2 [07:01] <dholbach> who' all here for the packaging training session? :-)
   3 [07:01] <micahg> is this an open session?
   4 [07:01] <dholbach> yes
   5 [07:01] <micahg> ok
   6 [07:01]  * micahg is here for packaging
   7 [07:01]  * Rail is here too
   8 [07:02] <dholbach> who else? come on, don't be shy! :)
   9 [07:02] <juliend> o/
  10 [07:02]  * Koterpillar *
  11 [07:03] <dholbach> alright - I hope you all brought questions
  12 [07:03] <dholbach> do we have any questions about something to do with packaging or ubuntu development in general?
  13 [07:03]  * Koterpillar yes
  14 [07:03] <dholbach> Koterpillar: cool - go ahead!
  15 [07:04] <Koterpillar> How can I replace a package A with B so that ones dependent on A are satisfied?
  16 [07:04] <dholbach> Koterpillar: can you illustrate that case a bit?
  17 [07:06] <dholbach> just so we all know what we're talking about
  18 [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.
  19 [07:07] <Koterpillar> Currently, sreadahead conflicts with readahead.
  20 [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)
  21 [07:08] <dholbach> ubuntu-desktop is a special case because it is not modified by hand, but created from seed files
  22 [07:09] <dholbach> https://wiki.ubuntu.com/SeedManagement has more detail about that
  23 [07:09] <Koterpillar> Do I remove Conflicts: readahead?
  24 [07:09] <dholbach> no
  25 [07:10] <dholbach> "Conflicts:" says that both packages ship the same file which dpkg can't deal with
  26 [07:10] <dholbach> http://www.debian.org/doc/debian-policy/ch-relationships.html has more detail about what conflicts / replaces / provides / etc are for
  27 [07:10] <Rail> and http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.2
  28 [07:11] <dholbach> Koterpillar: I'm curious, what does sreadahead offer that readahead doesn't?
  29 [07:11] <dholbach> (I haven't looked into either of them)
  30 [07:11] <Koterpillar> I've seen a news about it doing better with SSD, wanted to try.
  31 [07:11] <dholbach> ok
  32 [07:12] <dholbach> do we have any other questions already?
  33 [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.
  34 [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)
  35 [07:12] <TheMuso> Well, it depends on whether the patch has been commited upstrea in the new version
  36 [07:13] <TheMuso> And any good maintainer will send patches upstream for inclusion.
  37 [07:13] <ethana2> dholbach: doctormo and I are working on the wizardpen driver..
  38 [07:13] <dholbach> TheMuso is absolutely right... the earlier you get stuff upstream, the less pain you have :)
  39 [07:13] <ethana2> trying to get it to Just Works status and included in main
  40 [07:13] <ethana2> by karmic
  41 [07:14] <FuturePilot> ah, I see
  42 [07:14] <dholbach> ethana2: just a sec
  43 [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
  44 [07:14] <ethana2> dholbach: k
  45 [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.
  46 [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
  47 [07:14] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines is really really helpful in that regard too
  48 [07:14] <TheMuso> That, and documenting that the patch was from upstream in the changelog is good.
  49 [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
  50 [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./
  51 [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
  52 [07:15] <TheMuso> And patch systems like dpatch alow a description of the patch to be added in the header of the patch.
  53 [07:16] <dholbach> TheMuso: don't all patch systems allow that?
  54 [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.
  55 [07:16] <TheMuso> Sure you can add it to headers of other patches and it will be ignored, which is ok as well.
  56 [07:16] <dholbach> "patch" itself can deal with    ## comment .....    above the    diff .....   line
  57 [07:17] <dholbach> ah ok
  58 [07:17] <dholbach> yes
  59 [07:17] <dholbach> :-)
  60 [07:17] <TheMuso> Yeah.
  61 [07:17] <dholbach> FuturePilot: problem solved? :)
  62 [07:17] <dholbach> https://wiki.ubuntu.com/Bugs/Upstream has more info for sending stuff upstream
  63 [07:17] <FuturePilot> dholbach: yeah I think I get it now. thanks
  64 [07:17] <dholbach> ROCK
  65 [07:18] <dholbach> ethana2: so... what is giving you guys trouble? :)
  66 [07:18] <ethana2> xautomation is a virtual package
  67 [07:18] <ethana2> ...I don't think it's a problem on x32... not sure
  68 [07:18] <ethana2> xautomation is evidently a dependency of wizardpen, which we're trying to package
  69 [07:19] <ethana2> on 64 bit ubuntu, it won't build because it can't get that package
  70 [07:19] <ethana2> I've checked my sources.list, it can get to source files
  71 [07:19] <dholbach> daniel@bert:~$ apt-cache show xautomation | grep ^F
  72 [07:19] <dholbach> Filename: pool/universe/x/xautomation/xautomation_1.03-1_amd64.deb
  73 [07:19] <dholbach> daniel@bert:~$
  74 [07:19] <dholbach> ?
  75 [07:19] <ethana2> hmm
  76 [07:19] <dholbach> it seems to exist on 64bit Ubuntu
  77 [07:19] <ethana2> I'll get a pastebin link to my build errors
  78 [07:19] <dholbach> sure
  79 [07:19] <ethana2> http://paste.ubuntu.com/205915/
  80 [07:20] <ethana2> and...  http://paste.ubuntu.com/205930/
  81 [07:20] <ethana2> ok the second one is the important one at this point
  82 [07:20] <dholbach> did you enable universe and multiverse for your pbuilder?
  83 [07:20] <ethana2> not specifically
  84 [07:21] <dholbach> do something like this
  85 [07:21] <dholbach> daniel@miyazaki:~$ cat .pbuilderrc
  86 [07:21] <dholbach> COMPONENTS="main universe multiverse restricted"
  87 [07:21] <dholbach> daniel@miyazaki:~$
  88 [07:21] <dholbach> and recreate the pbuilder
  89 [07:21] <ethana2> k
  90 [07:21] <dholbach> https://wiki.ubuntu.com/PbuilderHowto has more info
  91 [07:21] <dholbach> might be the problem that xautomation is in universe
  92 [07:21] <dholbach> looking at the first pastebin now
  93 [07:21] <ethana2> don't bother I think
  94 [07:22] <ethana2> ok, so I want a ~/.pbuilderrc file
  95 [07:22] <ethana2> containing
  96 [07:22] <TheMuso> The first one doesn't seem to be a problem, except for some lintian warnings.
  97 [07:22] <ethana2> COMPONENTS="main universe multiverse restricted"
  98 [07:22] <nellery> first one just looks like a keysigning error
  99 [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
 100 [07:22] <ethana2> TheMuso: maybe a gpg thing, but yeah
 101 [07:22] <dholbach> https://wiki.ubuntu.com/DebianMaintainerField has the reason for it
 102 [07:22]  * ethana2 saves .pbuilderrc file
 103 [07:23] <ethana2> ok, I'm just going to try to build this again, carry on
 104 [07:23] <dholbach> dh-clean-k-is-deprecated: just use dh_prep in debian/rules instead
 105 [07:23] <ethana2> oh, ok, I should do that now
 106 [07:23]  * ethana2 navigates to debian/rules
 107 [07:23] <dholbach> configure-generated-file-in-source config.log config.status: just remove them in the clean target in debian/rules
 108 [07:23] <dholbach> debian-files-list-in-source: this is weird :-)
 109 [07:24] <dholbach> other than that there doesn't seem to be anything wrong from as far as I can tell
 110 [07:24] <dholbach> do we have any other questions? :)
 111 [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?
 112 [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
 113 [07:25] <Rail> dholbach: already done, but no feedback from the author :(
 114 [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
 115 [07:27] <Rail> I have a very descriptive get-orig-source :)
 116 [07:27] <dholbach> that sounds like a good idea :)
 117 [07:28] <dholbach> any more questions? :)
 118 [07:28] <ethana2> ope, it failed again :(
 119 [07:28] <ethana2> ok, I made that file...
 120 [07:28] <ethana2> but it gives me the same error
 121 [07:28] <dholbach> I think you might need to recreate the pbuilder
 122 [07:29] <ethana2> ohhh
 123 [07:29] <dholbach> sudo pbuilder update --distribution karmic --override-config
 124 [07:29] <dholbach> or something
 125 [07:29] <ethana2> ok yeah I think I forgot that part
 126 [07:29] <ethana2> karmic?
 127 [07:29] <ethana2> I'm on Jaunty, does that matter?
 128 [07:29] <dholbach> jaunty might be fine for now
 129 [07:29] <ethana2> k
 130 [07:29] <ethana2> should I still use 'karmic' in that command?
 131 [07:30] <dholbach> but if you want to get it into karmic, it only makes sense if you test it on karmic first :)
 132 [07:30] <ethana2> ahh
 133 [07:30] <ethana2> hmm
 134 [07:30] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases explains how to do that in a sane way
 135 [07:30] <ethana2> I was going to wait for alpha 3 and then install karmic over my intrepid
 136 [07:30] <ethana2> I always dual boot two ubuntu's
 137 [07:31] <dholbach> ethana2: you can use a vm too
 138 [07:31] <ethana2> dholbach: yeah
 139 [07:31] <dholbach> the page explains various options
 140 [07:31] <dholbach> cool
 141 [07:31] <ethana2> well, I don't think I'm nearly to the point where it becomes a matter of testing
 142 [07:32] <ethana2> but I'll certainly test with karmic before I send it in to REVU
 143 [07:32] <ethana2> or anything of that nature
 144 [07:32] <dholbach> excellent
 145 [07:32] <dholbach> do we have any more problems some of you ran into?
 146 [07:34] <dholbach> what about the things we just discussed, did they raise any questions or eyebrows?
 147 [07:34]  * ajmitch has a whole truckload of patches to check through & tag :)
 148 [07:35] <Rail> Sometimes I want to override lintian warnings. Is there any policy or good practices on this subject?
 149 [07:35] <ethana2> Rail: a warning shouldn't need to be overridden
 150 [07:35] <ethana2> do you mean an error?
 151 [07:35] <dholbach> Rail: I usually just leave them there to remind me (or others) to fix them at some stage :)
 152 [07:36] <Rail> ethana2: no, just annoying warnings, like no-upstream-changelog
 153 [07:36] <ethana2> Rail: yeah, the only proper thing to do is fix their cause
 154 [07:36]  * ajmitch would only override where necessary
 155 [07:37] <ethana2> ok, pbuilder updated and stuff, attempting to build the package again
 156 [07:37] <dholbach> http://lintian.debian.org/manual/ch2.html#s2.4
 157 [07:37] <dholbach> if you really want to
 158 [07:37] <dholbach> I normally wouldn't bother :)
 159 [07:38] <ethana2> well, it went to make it
 160 [07:38] <ethana2> ..but failed
 161 [07:38] <dholbach> Rail: but I agree... no-upstream-changelog is really annoying :)
 162 [07:38] <ethana2> ..due to a bug in the code
 163 [07:38] <dholbach> especially considering how much space on the CDs we waste because of changelogs :-)
 164 [07:38] <ethana2> ohhhh, stricter gcc
 165 [07:39] <ethana2> blast, I have to find a way to fix the code here
 166 [07:39] <Rail> dholbach: thanks, going to read that manual :)
 167 [07:39] <dholbach> any more questions? :)
 168 [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?
 169 [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
 170 [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
 171 [07:41] <dholbach> it won't make changes to the code, and will try to "revert" the patch again
 172 [07:42] <dholbach> if you have complicated patches were upstream used some parts and neglected others, it's a bit more tricky
 173 [07:42] <dholbach> or if stuff was fixed in a different way
 174 [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
 175 [07:43] <ethana2> 'night, that was very helpful, rock on
 176 [07:43] <dholbach> maxpaguru: was that answer helpful?
 177 [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
 178 [07:44] <maxpaguru> dholbach:thanks, i need to know better. what to reeD or tutorials ?
 179 [07:45] <dholbach> maxpaguru: https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines https://wiki.ubuntu.com/Bugs/Upstream and generally https://wiki.ubuntu.com/MOTU/GettingStarted :-)
 180 [07:45] <maxpaguru> dholbach: ok!
 181 [07:45] <dholbach> :-)
 182 [07:46] <dholbach> any more questions?
 183 [07:47] <dholbach> ajmitch, TheMuso: it's weird that nobody says "review my package please", isn't it? :)
 184 [07:47] <Rail> hehe :)
 185 [07:47] <TheMuso> dholbach: Yeah.
 186 [07:47] <FuturePilot> sometimes when I'm watching a package build I see warnings about uselessly linked libraries or something. What is that?
 187 [07:48] <TheMuso> Sometimes, executables or libraries are linked against other libraries when they don't need to be.
 188 [07:48] <Rail> dholbach: everybody pushes to Debian NEW :P
 189 [07:48] <ajmitch> dholbach: I'll have to produce a few for you to review then :)
 190 [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 :)
 191 [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.
 192 [07:49] <dholbach> TheMuso: does linking with -Wl,as-needed (or however you specify it) help with that?
 193 [07:49] <FuturePilot> ah ok, so probably notify upstream?
 194 [07:49] <dholbach> FuturePilot: yes
 195 [07:49] <TheMuso> dholbach: I don't know.
 196 [07:50] <TheMuso> I've just fixed up the autofoo and sent a patch upstream.
 197 [07:50] <juliend> dholbach: hi, is there a tutorial somewhere about packaging perl projects from CPAN ?
 198 [07:50] <dholbach>        --as-needed
 199 [07:50] <dholbach>        --no-as-needed
 200 [07:50] <dholbach>            This option affects ELF DT_NEEDED tags for dynamic  libraries  men‐
 201 [07:50] <dholbach>            tioned on the command line after the --as-needed option.  Normally,
 202 [07:50] <dholbach>            the linker will add a DT_NEEDED tag for each dynamic  library  men‐
 203 [07:50] <dholbach>            tioned  on  the  command line, regardless of whether the library is
 204 [07:50] <dholbach>            actually needed.  --as-needed causes  DT_NEEDED  tags  to  only  be
 205 [07:50] <dholbach>            emitted for libraries that satisfy some symbol reference from regu‐
 206 [07:50] <dholbach>            lar objects which is undefined at the point that  the  library  was
 207 [07:50] <dholbach>            linked.  --no-as-needed restores the default behaviour.
 208 [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
 209 [07:51] <TheMuso> ah ok.
 210 [07:51] <dholbach> so it might be a suitable workaround in some cases
 211 [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!
 212 [07:51] <juliend> great :)
 213 [07:51] <dholbach> 23rd July, 00:00 UTC, gwolf and jawnsy, Packaging Perl Modules
 214 [07:52] <ajmitch> the problem is not seeing breakage until you hit specific areas of a program that need those missing functions
 215 [07:52] <dholbach> ajmitch: that too
 216 [07:52] <dholbach> juliend: for now I'd just tell you to review existing perl modules and how they are packaged
 217 [07:52] <dholbach> http://www.debian-administration.org/articles/78 might be helpful too
 218 [07:53] <juliend> perfect, thanks
 219 [07:53] <dholbach> nice
 220 [07:53] <dholbach> any more questions? :)
 221 [07:54] <dholbach> I'm immensely proud of all the great work you guys are doing!
 222 [07:54] <FuturePilot> :)
 223 [07:55] <maxpaguru> can you give us an example of package updating where some of the patches fail and how to handle the problem?
 224 [07:57] <dholbach> just a sec
 225 [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
 226 [07:58] <dholbach> robert_ancell had to "refresh" the patches because they didn't apply any more in their current form
 227 [07:58] <Rail> maxpaguru: maybe this log will help https://wiki.ubuntu.com/Packaging/Training/Logs/2009-04-16
 228 [07:59] <dholbach> ok, let's wrap up
 229 [07:59] <maxpaguru> dholbach:thank you very much!
 230 [07:59] <dholbach> thanks a lot everybody for attending and your clever questions!
 231 [08:00] <dholbach> logs will be up soon
 232 [08:00] <FuturePilot> dholbach: thanks again
 233 [08:00] <dholbach> see you in #ubuntu-motu and #ubuntu-devel :)
 234 [08:00] <dholbach> have a great day :-)


Packaging/Training/Logs/2009-07-02 (last edited 2009-07-02 12:05:27 by 99-21-107-94)