2009-06-04-1
Next Session: TBD |
1 [06:56] <maxpaguru> salve here i am
2 [07:06] <RockyRoad> !seen mvo
3 [07:06] <ubot2> I have no seen command
4 [07:13] <@dholbach> <@dholbach> hello everybody
5 [07:13] <@dholbach> I just tried calling mvo, to no avail... I hope he's OK still
6 [07:13] <@dholbach> shall we make this an impromptu Q&A session about Ubuntu Development and Packaging instead?
7 [07:13] <@dholbach> who's here for the session?
8 [07:14] <@dholbach> don't be shy... raise your hands! :-))
9 [07:14] <juanje> me! :-)
10 [07:14] * micahg is here :)
11 [07:14] * juanje hugs dholbach ;-)
12 [07:15] <ara> o/
13 [07:15] * dholbach hugs y'all back :)
14 [07:16] <mbudde> o/
15 [07:16] <@dholbach> do you have any questions about ubuntu development, about packaging, maybe even a specific problem that you're dealing with at the moment... some general thoughts about how ubuntu development works? anything we could help out with?
16 [07:16] <maxpaguru> °/
17 [07:17] * juanje thinking about....
18 [07:18] <micahg> I had a build fail on me
19 [07:18] <micahg> but I think it was because a patch was out of date
20 [07:18] <@dholbach> micahg: do you have a build log somewhere?
21 [07:18] <micahg> http://launchpadlibrarian.net/27434400/buildlog_ubuntu-jaunty-i386.acidbase_1.4.3.1-0ubuntu1~ppa1_FAILEDTOBUILD.txt.gz
22 [07:18] <@dholbach> let's see
23 [07:19] <@dholbach> yes
24 [07:19] <@dholbach> dpatch apply-all
25 [07:19] <@dholbach> applying patch 01_default_config to ./ ... ok.
26 [07:19] <@dholbach> applying patch 02_update_external_links to ./ ... failed.
27 [07:19] <micahg> I didn't check the patches before uploading
28 [07:19] <@dholbach> that's because a patch is out of date
29 [07:19] <micahg> ok
30 [07:19] <micahg> I'll look into it another time
31 [07:19] <@dholbach> does everybody know what dpatch is and how it works?
32 [07:20] <maxpaguru> not so much ;)
33 [07:20] <@dholbach> great :)
34 [07:20] <juanje> a bit
35 [07:21] <@dholbach> so dpatch is one of the patch systems we use for packaging
36 [07:21] <@dholbach> because we don't use distributed development with a clear history of changes for everything yet
37 [07:21] <@dholbach> it sometimes makes sense to separate out patches
38 [07:21] <@dholbach> so let's say you're packaging a huge piece of upstream software and the software authors do one release every year
39 [07:22] <@dholbach> in that case you might come into a situation where you need to make changes their code or backport fixes
40 [07:23] <@dholbach> it can get very hard to stay on top of what's happening and who changed what if you just apply all changes directly on the source
41 [07:23] <@dholbach> that's why some package maintainers decide to put separate patches (one for every issue) into the debian/patches directory
42 [07:23] <@dholbach> acidbase, as micahg mentioned above, makes use of dpatch
43 [07:24] <@dholbach> 01_default_config seems to make some changes to the default configuration, and applies fine
44 [07:24] <@dholbach> 02_update_external_links unfortunately doesn't
45 [07:24] <@dholbach> the way that dpatch works is quite simple
46 [07:24] <@dholbach> you basically just run:
47 [07:24] <@dholbach> dpatch-edit-patch 03-new-patch-that-fixes-bug-1234567
48 [07:25] <@dholbach> and it will open a new shell environment, where you can make all kind of changes
49 [07:25] <@dholbach> when you hit Ctrl-D to close the shell, it will create a new file called debian/patches/03-new-patch-that-fixes-bug-1234567.patch
50 [07:25] <@dholbach> that includes the diff of what you just did
51 [07:25] <@dholbach> then you add 03-new-patch-that-fixes-bug-1234567 to debian/patches/00list (for internal housekeeping) and it will automatically get applied during the build
52 [07:26] <@dholbach> does that make sense?
53 [07:26] <mbudde> Yes it does :)
54 [07:26] <@dholbach> https://wiki.ubuntu.com/PackagingGuide/PatchSystems#dpatch maybe makes it a bit clearer
55 [07:26] <RockyRoad> nice tool :)
56 [07:26] <@dholbach> (and has a quick example)
57 [07:26] <maxpaguru> yes indeed!
58 [07:27] <@dholbach> dpatch apply-all / dpatch unapply-all are useful commands too
59 [07:27] <@dholbach> I hope one day we can get rid of all patch systems when we have full source imports in bzr though and keep track of all the history in there
60 [07:27] <mbudde> Is there a preferred patch system (dpatch, quilt, ...) or does that depend on the package?
61 [07:28] <@dholbach> mbudde: I think it depends on what the package maintainer likes best
62 [07:28] <@dholbach> quilt seems to be the new black right now, but I really never grew to like it :)
63 [07:29] <micahg> wow
64 [07:29] <micahg> dpatch-edit-patch is cool
65 [07:29] <micahg> it does it all for you :)
66 [07:29] <@dholbach> as nice as patch systems are for housekeeping (backport fix to version A, delete patch file, when version A+1 gets out), a bzr merge <upstream branch> is much more obvious :-)
67 [07:30] <@dholbach> I guess we should have James Westby here as a speaker again, he's the man when it comes to distributed development :)
68 [07:30] <@dholbach> do we have any other questions?
69 [07:31] <mbudde> I have a problem with a package I'm updating.
70 [07:31] <micahg> is there a way to set a default key for signing with debuild?
71 [07:31] <@dholbach> micahg: yes, hang on
72 [07:31] <mbudde> http://launchpadlibrarian.net/27276693/buildlog_ubuntu-jaunty-i386.purple-plugin-pack_2.5.1-0ubuntu1~ppa3~jaunty_FULLYBUILT.txt.gz
73 [07:31] <@dholbach> something like this in your .bashrc should do the trick:
74 [07:31] <@dholbach> export DEBFULLNAME='Daniel Holbach'
75 [07:31] <@dholbach> export DEBEMAIL='daniel.holbach@ubuntu.com'
76 [07:32] <@dholbach> (and make sure that email address is a key id on your gpg key)
77 [07:32] <micahg> dholbach: I have 2 keys for the one address
78 [07:32] <micahg> don't ask...
79 [07:32] <mbudde> I get a whole lot of dpkg-shlibdeps warnings, is there any way to stop that?
80 [07:32] <mbudde> Or is it a problem at all?
81 [07:32] <@dholbach> micahg: I think you can specify the key id somewhere, but I'd need to look it up
82 [07:33] <micahg> ok
83 [07:33] <micahg> I know I can do it on the command line
84 [07:34] <@dholbach> mbudde: that looks more like an upstream problem to me - it might make sense to have a chat with the upstream authors about it
85 [07:34] <mbudde> Ok :)
86 [07:34] <@dholbach> mbudde: but those warnings are not critical at all
87 [07:35] <@dholbach> there might be something wrong with the linking (sorry, I'm no expert there)
88 [07:35] <@dholbach> do we have any more questions... maybe more general questions?
89 [07:36] <@dholbach> mbudde, micahg: good work - I'm happy you're working on some packaging stuff already
90 [07:37] <mbudde> It's fun! :)
91 [07:37] <@dholbach> is there anything you'd like me to talk about a bit?
92 [07:37] <mbudde> What about getting stuff back into debian?
93 [07:37] <maxpaguru> i'd like to know how to use bugs in LP
94 [07:38] <@dholbach> mbudde: check out https://wiki.ubuntu.com/Debian/Bugs (there's the 'submittodebian' tool in ubuntu-dev-tools which makes forwarding patches really easy)
95 [07:39] <micahg> I just started :)
96 [07:39] <@dholbach> mbudde: now is a really good time to forward stuff to debian: we're merging lots and lots of packages right now and if you see a delta that could as well go to debian, forward it
97 [07:39] <@dholbach> maxpaguru: can you elaborate? what kind of bugs?
98 [07:40] <@dholbach> or is there anything in particular that you're wondering about?
99 [07:41] <maxpaguru> how to handle bugs in general , from where to begin , i'm a very newby;)
100 [07:41] <@dholbach> ok
101 [07:41] <@dholbach> so let's say you found a simple bug that you want to work on and fix it
102 [07:42] <@dholbach> you'd go and download the current source package by running apt-get source package-you-want-to-fix
103 [07:42] <@dholbach> then you'd make the simple change in the source tree
104 [07:42] <@dholbach> then you'd document it, by running dch -i
105 [07:42] <@dholbach> you'd add a new changelog entry, properly explain what you did to fix it
106 [07:43] <@dholbach> and add (LP: #1234567) to the changelog entry
107 [07:43] <@dholbach> with the bug number of the bug you're working on
108 [07:43] <@dholbach> (ah... before that you'd probably assign the bug to yourself and set the status to 'in progress')
109 [07:44] <micahg> indeed
110 [07:44] <@dholbach> then you'd run debuild -S to regenerate the source package
111 [07:44] <micahg> dholbach: why not make it a patch?
112 [07:44] <@dholbach> micahg: I'll get to that in a bit
113 [07:44] <micahg> ok
114 [07:44] <micahg> :)
115 [07:44] <@dholbach> then you'd test-build the package (you could use pbuilder for that: https://wiki.ubuntu.com/PbuilderHowto)
116 [07:44] <MaWaLe> sorry for interferring : where can i find the log of the classroom (i missed it :( )
117 [07:45] <@dholbach> MaWaLe: https://irclogs.ubuntu.com - it gets updated every now and then
118 [07:45] <MaWaLe> thx dholbach :)
119 [07:45] <@dholbach> also I'll put it up later at https://wiki.ubuntu.com/Packaging/Training/Logs
120 [07:45] <micahg> approx every hour
121 [07:45] <@dholbach> then you'd test the resulting package, make sure the bug is really fixed
122 [07:46] <maxpaguru> dholbach: Thanks where the tutorial links to that stuff . are there?
123 [07:46] <@dholbach> then you'd run
124 [07:46] <@dholbach> debdiff package-you-want-to-fix_old-version.dsc package-you-want-to-fix_new-version.dsc > package-you-want-to-fix.debdiff
125 [07:47] <@dholbach> this would generate the full patch (in package-you-want-to-fix.debdiff), that you could attach to the bug report
126 [07:47] <@dholbach> then you'd subscribe ubuntu-main-sponsors (if the package is in main/restricted) or ubuntu-universe-sponsors (if it's in universe/multiverse)
127 [07:47] <@dholbach> and somebody will take care of reviewing it and uploading it for you
128 [07:48] <@dholbach> the nice thing about "(LP: #1234567)" is that the bug will automatically gets closed, when the package is accepted
129 [07:48] <@dholbach> the docs for that are available at: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
130 [07:48] <@dholbach> AndrewGe1: https://wiki.ubuntu.com/SponsorshipProcess
131 [07:49] <@dholbach> sorry AndrewGe1 - automatic tab completion
132 [07:49] <@dholbach> maxpaguru: did that make sense so far?
133 [07:49] <maxpaguru> dholbach: great it's much clearer!
134 [07:49] <@dholbach> awesome!
135 [07:50] <@dholbach> any more questions? :)
136 [07:50] <juanje> dholbach: so, the better way to fix a bug is with a debdiff? I missed the UDS' session about patches, debdiff, branches and I was wondering which one would be the better way. I usualy try to attach a bzr branch with the fixes so the maintainer can merge the changes
137 [07:50] <juanje> but I don't know if this is the better way
138 [07:51] <@dholbach> juanje: if the package is in bzr already, the branch is probably the better option
139 [07:51] <juanje> dholbach: ok
140 [07:51] <maxpaguru> dholbach: I understand , it's clear i have to follow these steps one by one in detail. tnx so much
141 [07:52] <juanje> dholbach: and how the changelog should be changed in a debdiff?
142 [07:52] <@dholbach> juanje: in that case, you could do something like: bzr push --fixes lp:1234567 lp:~juanje/package-you-want-to-fix/my-fix
143 [07:52] <juanje> dholbach: yeah, make sense, thanks :-)
144 [07:52] <@dholbach> juanje: if you ran dch -i before, you added an entry in the changelog, which will turn up in the debdiff file
145 [07:53] <maxpaguru> where to find bzr tutorial?
146 [07:53] <@dholbach> hang on
147 [07:53] <juanje> dholbach: yes, but I mean if you write it like you were writting your onw package or as other people (the maintainer) will change it after?
148 [07:54] <@dholbach> maxpaguru: http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
149 [07:54] <@dholbach> for general bzr use
150 [07:55] <@dholbach> and https://wiki.ubuntu.com/DistributedDevelopment/Documentation for use in the packaging / ubuntu development context
151 [07:55] <maxpaguru> ok ;)
152 [07:56] <@dholbach> juanje: I'm not quite sure I understand - can you give me an example?
153 [07:56] <juanje> maxpaguru: this could be useful as well: https://wiki.ubuntu.com/BzrMaintainerHowto
154 [07:56] <juanje> dholbach: yeah, sorry, I didn't explain myself well....
155 [07:57] <juanje> dholbach: what I mean is that when you fix some package
156 [07:57] <juanje> and it's not yours
157 [07:57] <juanje> do you have to "propose" a changelog?
158 [07:57] <maxpaguru> juanje: thanks I'll follow all those links!
159 [07:58] <juanje> or write the changelog as the final one
160 [07:58] <juanje> ?
161 [07:58] <@dholbach> we don't have the concept of "package maintainer" in Ubuntu
162 [07:58] <@dholbach> so we all maintain all packages as a team
163 [07:58] <juanje> ummmmm
164 [07:58] <juanje> ok
165 [07:58] <juanje> :-)
166 [07:58] <@dholbach> so it definitely helps if you add a changelog entry
167 [07:58] <juanje> dholbach: but, if you are not MOTU or so?
168 [07:59] <@dholbach> juanje: then you still add a changelog entry and put up the full debdiff (or branch) for review through sponsorship
169 [07:59] <juanje> ok
170 [07:59] <juanje> understood :-)
171 [07:59] <@dholbach> perfect
172 [07:59] <@dholbach> it's important that you put a lot of effort into documenting your changes
173 [07:59] <@dholbach> I usually write changelog entries like this:
174 [08:00] <maxpaguru> Bye everyone I'll see the log later :-)
175 [08:01] <@dholbach> * src/something.c, src/something.h: remove all occurrences of "frobnicator", changes taken from upstream SVN commit 1542, fixes the build again (LP: #638153)
176 [08:01] <@dholbach> that way people will see: which files you changed, what you changed, why you changed it and that the upstream developers did the same thing, plus you close the current Ubuntu bug
177 [08:02] <@dholbach> it's important we do that, because as I said above: we all maintain packages as a team
178 [08:02] <juanje> dholbach: I usually write the changes on the bzr log and when I make changelog entry in it, but I had some doubts about if then the maintainer had to rewrite it (also maybe changing the version or so). Actually my doubts were more about the version you put to the changelog entry
179 [08:02] <@dholbach> so the next uploader of the package doesn't have to guess why you did a certain change
180 [08:02] <@dholbach> ... or you won't have to guess your intentions half a year later :)
181 [08:02] <juanje> dholbach: agree :-)
182 [08:02] <@dholbach> juanje: usually dch -i should do the right thing
183 [08:02] <juanje> it's very important :-)
184 [08:02] <juanje> ok
185 [08:03] <@dholbach> juanje: if you add a new changelog entry and run debcommit afterwards, it will use that changelog entry for the bzr commit message :)
186 [08:03] <@dholbach> ...two bird with one stone...
187 [08:04] <juanje> ummmm
188 [08:04] <juanje> I swa something about debcommit, but I haven't try yet
189 [08:04] <@dholbach> juanje: you have a question?
190 [08:04] <@dholbach> it's good stuff :)
191 [08:04] <juanje> I think, I'll try :-)
192 [08:05] <@dholbach> rock on
193 [08:05] <@dholbach> ok... thanks everybody! if you have any more questions, please feel free to join #ubuntu-motu and ask questions there
194 [08:05] <@dholbach> we're happy to help you out!
195 [08:05] <juanje> dholbach: thanks for all!
196 [08:05] <juanje> :-)
197 [08:05] <@dholbach> mvo's session will be rescheduled - I'll let you all know about the session in a bit
198 [08:06] <@dholbach> thanks everyone and have a great day!
199 [08:06] <RockyRoad> thx dholbach :)
200 [08:06] <mbudde> dholbach, thank you!
201 [08:07] <@dholbach> my pleasure :)
202 [08:07] <maxpaguru> thanks to dholbach and everyone! :-)
203 [08:09] <ara> mvo session will be today at 15:00UTC
204 [08:09] <ara> more details on the planet today :)
205 [08:09] <juanje> mbudde: do you have some where the code from the package you got the fail?
206 [08:09] <juanje> ara: thanks :-)
207 [08:10] <juanje> mbudde: I have some ideas about the warnings I like to confirm. I you don't mind
208 [08:11] <mbudde> juanje, great! :) You can get the package from my PPA: https://launchpad.net/~mbudde/+archive/ppa
209 [08:12] <juanje> mbudde: thanks :-) I tell you latter ;-)
210 [08:13] <mbudde> juanje, if I'm not online please do send me an email
211 [08:15] <juanje> mbudde: sure ;-)
212 [08:15] <ricecom> too late.. :(
213 [08:50] <ricecom> bye
Packaging/Training/Logs/2009-06-04-1 (last edited 2009-06-04 08:04:50 by i59F71954)