2009-07-02
Next Session: TBD |
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)