2009-06-04-1

Differences between revisions 1 and 2
Revision 1 as of 2009-06-04 07:54:53
Size: 87
Editor: i59F71954
Comment:
Revision 2 as of 2009-06-04 08:04:50
Size: 16124
Editor: i59F71954
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
... [06:56] <maxpaguru> salve here i am
[07:06] <RockyRoad> !seen mvo
[07:06] <ubot2> I have no seen command
[07:13] <@dholbach> <@dholbach> hello everybody
[07:13] <@dholbach> I just tried calling mvo, to no avail... I hope he's OK still
[07:13] <@dholbach> shall we make this an impromptu Q&A session about Ubuntu Development and Packaging instead?
[07:13] <@dholbach> who's here for the session?
[07:14] <@dholbach> don't be shy... raise your hands! :-))
[07:14] <juanje> me! :-)
[07:14] * micahg is here :)
[07:14] * juanje hugs dholbach ;-)
[07:15] <ara> o/
[07:15] * dholbach hugs y'all back :)
[07:16] <mbudde> o/
[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?
[07:16] <maxpaguru> °/
[07:17] * juanje thinking about....
[07:18] <micahg> I had a build fail on me
[07:18] <micahg> but I think it was because a patch was out of date
[07:18] <@dholbach> micahg: do you have a build log somewhere?
[07:18] <micahg> http://launchpadlibrarian.net/27434400/buildlog_ubuntu-jaunty-i386.acidbase_1.4.3.1-0ubuntu1~ppa1_FAILEDTOBUILD.txt.gz
[07:18] <@dholbach> let's see
[07:19] <@dholbach> yes
[07:19] <@dholbach> dpatch apply-all
[07:19] <@dholbach> applying patch 01_default_config to ./ ... ok.
[07:19] <@dholbach> applying patch 02_update_external_links to ./ ... failed.
[07:19] <micahg> I didn't check the patches before uploading
[07:19] <@dholbach> that's because a patch is out of date
[07:19] <micahg> ok
[07:19] <micahg> I'll look into it another time
[07:19] <@dholbach> does everybody know what dpatch is and how it works?
[07:20] <maxpaguru> not so much ;)
[07:20] <@dholbach> great :)
[07:20] <juanje> a bit
[07:21] <@dholbach> so dpatch is one of the patch systems we use for packaging
[07:21] <@dholbach> because we don't use distributed development with a clear history of changes for everything yet
[07:21] <@dholbach> it sometimes makes sense to separate out patches
[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
[07:22] <@dholbach> in that case you might come into a situation where you need to make changes their code or backport fixes
[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
[07:23] <@dholbach> that's why some package maintainers decide to put separate patches (one for every issue) into the debian/patches directory
[07:23] <@dholbach> acidbase, as micahg mentioned above, makes use of dpatch
[07:24] <@dholbach> 01_default_config seems to make some changes to the default configuration, and applies fine
[07:24] <@dholbach> 02_update_external_links unfortunately doesn't
[07:24] <@dholbach> the way that dpatch works is quite simple
[07:24] <@dholbach> you basically just run:
[07:24] <@dholbach> dpatch-edit-patch 03-new-patch-that-fixes-bug-1234567
[07:25] <@dholbach> and it will open a new shell environment, where you can make all kind of changes
[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
[07:25] <@dholbach> that includes the diff of what you just did
[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
[07:26] <@dholbach> does that make sense?
[07:26] <mbudde> Yes it does :)
[07:26] <@dholbach> https://wiki.ubuntu.com/PackagingGuide/PatchSystems#dpatch maybe makes it a bit clearer
[07:26] <RockyRoad> nice tool :)
[07:26] <@dholbach> (and has a quick example)
[07:26] <maxpaguru> yes indeed!
[07:27] <@dholbach> dpatch apply-all / dpatch unapply-all are useful commands too
[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
[07:27] <mbudde> Is there a preferred patch system (dpatch, quilt, ...) or does that depend on the package?
[07:28] <@dholbach> mbudde: I think it depends on what the package maintainer likes best
[07:28] <@dholbach> quilt seems to be the new black right now, but I really never grew to like it :)
[07:29] <micahg> wow
[07:29] <micahg> dpatch-edit-patch is cool
[07:29] <micahg> it does it all for you :)
[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 :-)
[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 :)
[07:30] <@dholbach> do we have any other questions?
[07:31] <mbudde> I have a problem with a package I'm updating.
[07:31] <micahg> is there a way to set a default key for signing with debuild?
[07:31] <@dholbach> micahg: yes, hang on
[07:31] <mbudde> http://launchpadlibrarian.net/27276693/buildlog_ubuntu-jaunty-i386.purple-plugin-pack_2.5.1-0ubuntu1~ppa3~jaunty_FULLYBUILT.txt.gz
[07:31] <@dholbach> something like this in your .bashrc should do the trick:
[07:31] <@dholbach> export DEBFULLNAME='Daniel Holbach'
[07:31] <@dholbach> export DEBEMAIL='daniel.holbach@ubuntu.com'
[07:32] <@dholbach> (and make sure that email address is a key id on your gpg key)
[07:32] <micahg> dholbach: I have 2 keys for the one address
[07:32] <micahg> don't ask...
[07:32] <mbudde> I get a whole lot of dpkg-shlibdeps warnings, is there any way to stop that?
[07:32] <mbudde> Or is it a problem at all?
[07:32] <@dholbach> micahg: I think you can specify the key id somewhere, but I'd need to look it up
[07:33] <micahg> ok
[07:33] <micahg> I know I can do it on the command line
[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
[07:34] <mbudde> Ok :)
[07:34] <@dholbach> mbudde: but those warnings are not critical at all
[07:35] <@dholbach> there might be something wrong with the linking (sorry, I'm no expert there)
[07:35] <@dholbach> do we have any more questions... maybe more general questions?
[07:36] <@dholbach> mbudde, micahg: good work - I'm happy you're working on some packaging stuff already
[07:37] <mbudde> It's fun! :)
[07:37] <@dholbach> is there anything you'd like me to talk about a bit?
[07:37] <mbudde> What about getting stuff back into debian?
[07:37] <maxpaguru> i'd like to know how to use bugs in LP
[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)
[07:39] <micahg> I just started :)
[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
[07:39] <@dholbach> maxpaguru: can you elaborate? what kind of bugs?
[07:40] <@dholbach> or is there anything in particular that you're wondering about?
[07:41] <maxpaguru> how to handle bugs in general , from where to begin , i'm a very newby;)
[07:41] <@dholbach> ok
[07:41] <@dholbach> so let's say you found a simple bug that you want to work on and fix it
[07:42] <@dholbach> you'd go and download the current source package by running apt-get source package-you-want-to-fix
[07:42] <@dholbach> then you'd make the simple change in the source tree
[07:42] <@dholbach> then you'd document it, by running dch -i
[07:42] <@dholbach> you'd add a new changelog entry, properly explain what you did to fix it
[07:43] <@dholbach> and add (LP: #1234567) to the changelog entry
[07:43] <@dholbach> with the bug number of the bug you're working on
[07:43] <@dholbach> (ah... before that you'd probably assign the bug to yourself and set the status to 'in progress')
[07:44] <micahg> indeed
[07:44] <@dholbach> then you'd run debuild -S to regenerate the source package
[07:44] <micahg> dholbach: why not make it a patch?
[07:44] <@dholbach> micahg: I'll get to that in a bit
[07:44] <micahg> ok
[07:44] <micahg> :)
[07:44] <@dholbach> then you'd test-build the package (you could use pbuilder for that: https://wiki.ubuntu.com/PbuilderHowto)
[07:44] <MaWaLe> sorry for interferring : where can i find the log of the classroom (i missed it :( )
[07:45] <@dholbach> MaWaLe: https://irclogs.ubuntu.com - it gets updated every now and then
[07:45] <MaWaLe> thx dholbach :)
[07:45] <@dholbach> also I'll put it up later at https://wiki.ubuntu.com/Packaging/Training/Logs
[07:45] <micahg> approx every hour
[07:45] <@dholbach> then you'd test the resulting package, make sure the bug is really fixed
[07:46] <maxpaguru> dholbach: Thanks where the tutorial links to that stuff . are there?
[07:46] <@dholbach> then you'd run
[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
[07:47] <@dholbach> this would generate the full patch (in package-you-want-to-fix.debdiff), that you could attach to the bug report
[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)
[07:47] <@dholbach> and somebody will take care of reviewing it and uploading it for you
[07:48] <@dholbach> the nice thing about "(LP: #1234567)" is that the bug will automatically gets closed, when the package is accepted
[07:48] <@dholbach> the docs for that are available at: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[07:48] <@dholbach> AndrewGe1: https://wiki.ubuntu.com/SponsorshipProcess
[07:49] <@dholbach> sorry AndrewGe1 - automatic tab completion
[07:49] <@dholbach> maxpaguru: did that make sense so far?
[07:49] <maxpaguru> dholbach: great it's much clearer!
[07:49] <@dholbach> awesome!
[07:50] <@dholbach> any more questions? :)
[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
[07:50] <juanje> but I don't know if this is the better way
[07:51] <@dholbach> juanje: if the package is in bzr already, the branch is probably the better option
[07:51] <juanje> dholbach: ok
[07:51] <maxpaguru> dholbach: I understand , it's clear i have to follow these steps one by one in detail. tnx so much
[07:52] <juanje> dholbach: and how the changelog should be changed in a debdiff?
[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
[07:52] <juanje> dholbach: yeah, make sense, thanks :-)
[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
[07:53] <maxpaguru> where to find bzr tutorial?
[07:53] <@dholbach> hang on
[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?
[07:54] <@dholbach> maxpaguru: http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
[07:54] <@dholbach> for general bzr use
[07:55] <@dholbach> and https://wiki.ubuntu.com/DistributedDevelopment/Documentation for use in the packaging / ubuntu development context
[07:55] <maxpaguru> ok ;)
[07:56] <@dholbach> juanje: I'm not quite sure I understand - can you give me an example?
[07:56] <juanje> maxpaguru: this could be useful as well: https://wiki.ubuntu.com/BzrMaintainerHowto
[07:56] <juanje> dholbach: yeah, sorry, I didn't explain myself well....
[07:57] <juanje> dholbach: what I mean is that when you fix some package
[07:57] <juanje> and it's not yours
[07:57] <juanje> do you have to "propose" a changelog?
[07:57] <maxpaguru> juanje: thanks I'll follow all those links!
[07:58] <juanje> or write the changelog as the final one
[07:58] <juanje> ?
[07:58] <@dholbach> we don't have the concept of "package maintainer" in Ubuntu
[07:58] <@dholbach> so we all maintain all packages as a team
[07:58] <juanje> ummmmm
[07:58] <juanje> ok
[07:58] <juanje> :-)
[07:58] <@dholbach> so it definitely helps if you add a changelog entry
[07:58] <juanje> dholbach: but, if you are not MOTU or so?
[07:59] <@dholbach> juanje: then you still add a changelog entry and put up the full debdiff (or branch) for review through sponsorship
[07:59] <juanje> ok
[07:59] <juanje> understood :-)
[07:59] <@dholbach> perfect
[07:59] <@dholbach> it's important that you put a lot of effort into documenting your changes
[07:59] <@dholbach> I usually write changelog entries like this:
[08:00] <maxpaguru> Bye everyone I'll see the log later :-)
[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)
[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
[08:02] <@dholbach> it's important we do that, because as I said above: we all maintain packages as a team
[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
[08:02] <@dholbach> so the next uploader of the package doesn't have to guess why you did a certain change
[08:02] <@dholbach> ... or you won't have to guess your intentions half a year later :)
[08:02] <juanje> dholbach: agree :-)
[08:02] <@dholbach> juanje: usually dch -i should do the right thing
[08:02] <juanje> it's very important :-)
[08:02] <juanje> ok
[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 :)
[08:03] <@dholbach> ...two bird with one stone...
[08:04] <juanje> ummmm
[08:04] <juanje> I swa something about debcommit, but I haven't try yet
[08:04] <@dholbach> juanje: you have a question?
[08:04] <@dholbach> it's good stuff :)
[08:04] <juanje> I think, I'll try :-)
[08:05] <@dholbach> rock on
[08:05] <@dholbach> ok... thanks everybody! if you have any more questions, please feel free to join #ubuntu-motu and ask questions there
[08:05] <@dholbach> we're happy to help you out!
[08:05] <juanje> dholbach: thanks for all!
[08:05] <juanje> :-)
[08:05] <@dholbach> mvo's session will be rescheduled - I'll let you all know about the session in a bit
[08:06] <@dholbach> thanks everyone and have a great day!
[08:06] <RockyRoad> thx dholbach :)
[08:06] <mbudde> dholbach, thank you!
[08:07] <@dholbach> my pleasure :)
[08:07] <maxpaguru> thanks to dholbach and everyone! :-)
[08:09] <ara> mvo session will be today at 15:00UTC
[08:09] <ara> more details on the planet today :)
[08:09] <juanje> mbudde: do you have some where the code from the package you got the fail?
[08:09] <juanje> ara: thanks :-)
[08:10] <juanje> mbudde: I have some ideas about the warnings I like to confirm. I you don't mind
[08:11] <mbudde> juanje, great! :) You can get the package from my PPA: https://launchpad.net/~mbudde/+archive/ppa
[08:12] <juanje> mbudde: thanks :-) I tell you latter ;-)
[08:13] <mbudde> juanje, if I'm not online please do send me an email
[08:15] <juanje> mbudde: sure ;-)
[08:15] <ricecom> too late.. :(
[08:50] <ricecom> bye

   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


CategoryPackaging

Packaging/Training/Logs/2009-06-04-1 (last edited 2009-06-04 08:04:50 by i59F71954)