Started logging meeting in #ubuntu-classroom

[15:28:40] <dholbach> Welcome everybody to the MOTU Q&A session - how are you all doing?

[15:28:56] <dholbach> I think we should start with a round of introductions

[15:29:40] <dholbach> I'm Daniel Holbach, MOTU for quite a while now - at the moment I'm working on improving MOTU and packaging documentation, if you have any questions at all - feel free to ping me and ask me Smile :-)

[15:29:55] <dholbach> who else do we have here today? Smile :)

[15:30:52] <rick_h> Rick, michigan lug leader, and hosting a packaging jam for the MI area...so here to learn some more

[15:31:04] <dholbach> rick_h: excellent - great to have you here

[15:31:33] <sommer> I'm Adam Sommer and I've recently started helping out with the Server team. Mostly testing and documentation.

[15:31:48] <dholbach> sommer: Rock On - I'm sure the server team's very happy with you

[15:32:01] <dholbach> ok - keep the introductions coming, it's great to know who's here and to get to know each other...

[15:32:15] <persia> I'm Emmet Hikory, MOTU for a while, and Contributor for some time before that. I tend to focus on .desktop files and stacktrace decoding.

[15:32:16] <dholbach> in the meantime let me start off with a few words about MOTU

[15:32:46] <dholbach> It's becoming easier and easier to become a MOTU - the process for that is on http://wiki.ubuntu.com/UbuntuDevelopers

[15:32:50] <huats> Christophe Sauthier, I've been doing many littles things (bug solving, packaging...), mainly thanks to norsetto and dholbach who help me a lot... and I am a MOTU Hopeful Smile :-) one day Smile :-)

[15:33:33] <dholbach> basically you contribute to Ubuntu through sponsors (I'll talk about that in a bit) and after your sponsors are happy with you, you can ask the MOTU Council to approve your request to join the team

[15:34:26] <dholbach> sponsoring means: you upload a package or a patch to either Launchpad or another webpage, somebody (who's an Ubuntu developer already) reviews it, builds a source package from it, signs it with their gpg key and uploads it

[15:34:38] <dholbach> and that's all there is to it Smile :-)

[15:34:46] <dholbach> does anybody have questions about that process?

[15:35:03] <dholbach> you can all read about it on http://wiki.ubuntu.com/SponsorshipProcess

[15:35:13] <dholbach> [LINK] http://wiki.ubuntu.com/SponsorshipProcess

[15:35:20] <dholbach> [LINK] http://wiki.ubuntu.com/UbuntuDevelopers

[15:36:30] <dholbach> ok great

[15:36:39] <dholbach> who of you is already involved with those processes and the MOTU team?

[15:37:34] <rick_h> yea, toss me in the "not yet" club

[15:38:05] <huats> I've been a more and more lately Smile :-)

[15:39:26] <gnomefreak> it says you need to package for 2 cycle releases and ive only done gutsy and im not sure if it fit the requirments

[15:39:59] <dholbach> gnomefreak: I think I removed that from the documentation as we had lots of contributors who contributed less long

[15:40:36] <dholbach> what I like about the process is that you just have to demonstrate that you're willing to learn and that you're a good team player and follow the processes

[15:40:51] <sourcercito> Hi, Basilio Kublik here, Ubuntu user for about 2 or 3 months, i'm currently helping by doing QA at LP, and looking for new ways to contribute, not in the precess yet, just came late to the introductions :-D

[15:41:00] <persia> gnomefreak: Don't let that scare you. Depending on interest, some people move more quickly (a couple months) and some more slowly (I took about 2 years). It's really about you becoming familiar with the processes, and feeling comfortable with your work.

[15:41:54] <Hobbsee> gnomefreak: it's basically "if you seem to know what you're doing, submit constantly correct debdiffs (or mostly, at least), follow processes and dont do stupid things, you're probably fine"

[15:41:58] <dholbach> it's important that you ask if you don't understand something, that people know they can trust you and that you're easy to work with

[15:43:27] <dholbach> we have a bunch of easy bugs that you can probably start working on quickly

[15:43:40] <dholbach> they are all linked from http://wiki.ubuntu.com/MOTU/Bugs and http://wiki.ubuntu.com/MOTU/TODO

[15:43:49] <dholbach> [LINK] http://wiki.ubuntu.com/MOTU/TODO

[15:43:51] <dholbach> [LINK] http://wiki.ubuntu.com/MOTU/Bugs

[15:44:10] <dholbach> some bugs are tagged as 'bitesize' meaning as much as "this might be easy to solve"

[15:44:23] <dholbach> some are tagged as 'packaging' meaning that the bug lies in the packaging

[15:44:51] <dholbach> we're already late to get fixes into gutsy, but this is a perfect time to get prepared for hardy by playing with bugs and tools a bit

[15:45:03] <dholbach> also I recommend http://wiki.ubuntu.com/MOTU/Recipes

[15:45:05] <Hobbsee> dholbach: oh, so this is *might* be easy to solve, rather than *guarenteed is* easy to solve?

[15:45:10] <dholbach> [LINK] http://wiki.ubuntu.com/MOTU/Recipes

[15:45:13] <dholbach> Hobbsee: yes, of course

[15:45:14] <Hobbsee> excellent, i can start tagging more bitesize bugs!

[15:45:22] <dholbach> but you can always ask on #ubuntu-motu

[15:45:33] <dholbach> or on ubuntu-motu@lists.ubuntu.com or ubuntu-motu-mentors@lists.ubuntu.com

[15:45:59] <dholbach> do we have any questions? Smile :-)

[15:46:48] <sommer> so say I attach a diff to a bug, the next step is to get it sponsored?

[15:46:54] <dholbach> sommer: exactly

[15:47:07] <rick_h> sure, I've started going through the packaging guide and whenever I tell someone "I've created a chroot and now dpkg-buildsource" I get back "oh, you should be using dpackage" or "it should just be 2 commands"

[15:47:08] <dholbach> if the package is in main/restricted, you subscribe a team called ubuntu-main-sponsors

[15:47:16] <dholbach> else you subscribe ubuntu-universe-sponsors

[15:47:26] <rick_h> am I going about this the wrong/non-standard method or should I be using some other "getting started" guide?

[15:47:28] * norsetto stress subscribe, not assign

[15:47:29] <Hobbsee> (dpkg-buildsource?)

[15:47:30] <persia> sommer: As an alternative, you can also look at the package, and try to fix more than one bug at once (although this isn't always as easy)

[15:47:36] <rick_h> Hobbsee: sorry, going from memory

[15:47:36] <dholbach> the bugs of those teams show up on http://daniel.holba.ch/sponsoring - and we're getting better and better at reviewing them quickly

[15:47:47] <Hobbsee> rick_h: a lot of it is aliases for each other. (and you wanted dpkg-buildpackage)

[15:47:50] <rick_h> whatever the first step in the packaging guide is after create the files

[15:48:06] <Hobbsee> rick_h: like, debuild is actually an alias of dpkg-buildpackage, afaik, and the options are the same.

[15:48:26] <dholbach> (debuild logs for you and makes use of fakeroot)

[15:48:29] <rick_h> ok, but the chroot setup is still the "proper" way and such?

[15:48:35] <dholbach> that depends

[15:48:47] <dholbach> for example develop for gutsy but still run feisty

[15:48:54] <dholbach> in that case it's favorable to have a chroot and use that

[15:49:00] <rick_h> ok

[15:49:07] <Hobbsee> rick_h: chroot, pbuilder, or sbuild, yes. but remember, a chroot will save any changes you make to it, whereas a pbuilder wont.

[15:49:10] <persia> I'd say there is no "proper" way to build packages. chroot, pbuilder, and sbuild all have advocates.

[15:49:19] <dholbach> so you can test that it builds and installs properly in the release target you want to get it uploaded to

[15:49:23] <Hobbsee> rick_h: (pbuilder just makes a chroot, then deletes it after building, or whatever you tell it to)

[15:49:25] <Hobbsee> rick_h: if that helps

[15:49:30] <rick_h> ok, but as someone new starting to read from page 1...what page 1 is my starting point?

[15:49:35] * persia notes that chroots only save changes if they aren't schroots

[15:49:46] <Hobbsee> persia: yeah, but i dont know about them Smile :)

[15:49:46] <sommer> persia: if I takle more than one bug for a package would I then attach the diff file to both bugs or just one?

[15:50:04] <dholbach> rick_h: we're in a transition period - I hope it's going to be just http://wiki.ubuntu.com/PackagingGuide and http://wiki.ubuntu.com/UbuntuDevelopment soon

[15:50:07] <Hobbsee> sommer: just one is fine, assuming you've got both listed in the changelog

[15:50:21] <sommer> gotcha thanks

[15:50:26] <rick_h> dholbach: ok, I'm going through the packaging guide so I'll just keep chugging for now

[15:50:36] <dholbach> sommer: what Hobbsee says, as long as you add a (LP: #123456) and (LP: #123457) in the changelog Smile :)

[15:50:37] <norsetto> sommer: and used the (LP: #xxxxx) tag

[15:50:39] <rick_h> I just got a bunch of "you're doing it the hard way" flak from people

[15:50:54] <persia> sommer: When I was a contributor, I usually picked the most critical bug, and put the debdiff there, with a note that it fixed the other bugs, and notes in those bugs that the fix was there. The other option (probably cleaner) is to make a new bug for your patch, and put a comment in the other bugs that the patch is in the new bug.

[15:50:57] <dholbach> rick_h: the packaging guide is not on the wiki yet, but I assume you get it from help.ubuntu.com for now

[15:51:02] <dholbach> rick_h: oh really?

[15:51:10] <Hobbsee> rick_h: it's not a bad idea doing it the hard way, then writing scripts after you understand it. *shrug*

[15:51:13] <rick_h> yea, I actually got the pdf version for now

[15:51:17] <Hobbsee> rick_h: helps you understand a bit better how it all fits in

[15:51:43] <dholbach> rick_h: http://wiki.ubuntu.com/MOTU/Recipes has a few howtos that concentrates on hands-on-use of tools, maybe that helps

[15:51:48] <rick_h> ok, well the hope is to learn and then I have a former MOTU to help with a jam for people in Nov

[15:51:52] <geser> persia: I manage a gutsy chroot which I use for preparing packages with schroot

[15:52:06] <rick_h> ok, thanks

[15:52:29] <Hobbsee> rick_h: with the "what should i build with" question, the only *wrong* answers are "on your own system, which you mess with all the time", or "in the wrong release"

[15:52:31] * persia also points at https://wiki.ubuntu.com/MOTU/Contributing for some ways to use tools when preparing patches for review

[15:52:32] <huats> rick_h: you can trust dholbach : the Recipes do help a lot at the beginning...

[15:52:40] <persia> geser: I also

[15:52:48] <Hobbsee> rick_h: and a lot of people do the former.

[15:53:41] <dholbach> rick_h: so anything you looked at packaging-wise already?

[15:53:57] <dholbach> gnomefreak: or you?

[15:54:29] <rick_h> dholbach: I'm just up to page 25 of the guide

[15:54:41] <rick_h> I created a debmirror last night to help with the chroot building

[15:54:47] <rick_h> locally that is

[15:54:50] <dholbach> nice

[15:55:04] <rick_h> so the plan is to get through the guide, then the jam I'm hosting is going to repackage gftp as a learning

[15:55:07] <rick_h> then go from there

[15:55:38] <rick_h> my goals are to be able to create packages of php/python apps (things i tend to run into that I wish had more up to date packages)

[15:55:54] <dholbach> rick_h: great - let me know once you get notes or plans for your jam session together

[15:56:05] <rick_h> sure thing

[15:56:07] <dholbach> I'm curious to know what you demo there Smile :-)

[15:56:12] <dholbach> gnomefreak: I believe you have done some packaging in the mozilla team?

[15:56:31] <rick_h> the flyer is: http://mitechie.com/uploads/package_jam.pdf

[15:56:44] <Hobbsee> gnomefreak: oh, shudder. i didnt realise you actually did mozilla packaging.

[15:56:59] <rick_h> Aaron Lake is in the area and volunteer to help get some materials together

[15:57:10] <rick_h> (I guess he was MOTU with breezy)

[15:57:15] * Hobbsee still occasionally has nightmares, remembering enigmail

[15:57:20] <Hobbsee> although that wasnt you

[15:57:54] <dholbach> rick_h: nice... tell Aaron to re-join the MOTU team! Smile :-)

[15:57:56] <gnomefreak> dholbach: yes

[15:58:08] <gnomefreak> dholbach: i am pretty much maintainer for iceape

[15:58:10] <rick_h> dholbach: he says he's been wanting to get involved some more so we're starting to prod him

[15:59:08] <dholbach> rick_h: way to go! Smile :-)

[15:59:21] <gnomefreak> Hobbsee: mozilla isnt fun but i learned more from mozilla than any other packaging like flash java and freinds

[15:59:26] <bintut> gtg.. good luck! =)

[16:00:04] <dholbach> ok... any packaging questions in here?

[16:00:57] <dholbach> huats: you had some last time - are you OK atm? Smile :)

[16:01:19] <huats> dholbach: Everythiing rock Smile :-)

[16:02:10] <dholbach> ok great Smile :)

[16:02:50] * tjagoda is a measy newbie who plans on going to rick-h's packaging jam

[16:03:08] <tjagoda> We Michiganders have aspirations of contribution, it would seem.

[16:03:35] <dholbach> that's great - you should write up your experiences from it or share your notes

[16:04:34] <dholbach> ok, one category of bugs we always fix before a release is unmetdeps bugs

[16:04:48] <dholbach> which means packages that are not installable because their depends can not be satisfied

[16:04:54] <rick_h> dholbach: one question on the packaging guide, my buildpackage command files due to missing gpg key

[16:04:56] <dholbach> one example is https://bugs.launchpad.net/ubuntu/+source/meta-gnome2/+bug/145543

[16:04:58] <tjagoda> Especially considering the fact that I'm a completely unexperiences user whose yet to learn c or c++.

[16:05:01] <rick_h> but there's nothing on setting that up int he manual

[16:05:29] <dholbach> rick_h: hang on, I'll find you the webpage

[16:05:29] <rick_h> at least up to the point of building the hello source

[16:05:29] <Hobbsee> tjagoda: i've used my c++ knowledge (or lack of it) exactly once in ubuntu.

[16:05:29] <dholbach> https://help.ubuntu.com/community/GnuPrivacyGuardHowto

[16:05:35] <tjagoda> heh

[16:05:50] <Hobbsee> tjagoda: so, i dont think hte "i cant program" excuse has any validity Smile :)

[16:05:52] <rick_h> thanks, now should I setup a dup for the chroot or just use the same one I would normally run with?

[16:06:10] <Hobbsee> tjagoda: of course, it's helpful if you do, but there are things you can learn on the fly - and they're not C++ and such

[16:06:18] <dholbach> I don't think there's a need to do duplicate it

[16:06:55] <dholbach> more important than being an ace when it comes to C++, is that you're motivated and good at detective work

[16:07:07] <dholbach> sometimes the upstream developers have a fix for the problem already

[16:07:14] <dholbach> or another distribution has it already

[16:07:44] <dholbach> as long as you're willing to learn, willing to talk to people there's no reason for "I'm not good at C++ yet" blocking your MOTU membership Smile :)

[16:07:56] <rick_h> package python apps Smile :-)

[16:07:59] <persia> Also, it's much more useful to be able to read code than to write it. If you can find the issue, and describe the problem clearly, upstream is often happy to generate the patch.

[16:08:00] <dholbach> hehe Smile :)

[16:08:09] <dholbach> exactly

[16:08:23] <dholbach> would anybody of you know how to fix https://bugs.launchpad.net/ubuntu/+source/meta-gnome2/+bug/145543 ?

[16:08:27] <dholbach> or at least what to make of it?

[16:09:18] <tjagoda> So I could get away with a small knowledge of Linux and no programming experience?

[16:09:38] <sommer> wouldn't you need to add a something in the control file about the deps?

[16:09:40] <persia> tjagoda: The first would probably go away after working on a few bugs, but the second is certainly no obstacle.

[16:09:56] <rick_h> dholbach: so is that a bug for beating on the doors of matainers for libtotem and epiphany?

[16:10:09] <dholbach> rick_h: no Smile :)

[16:10:13] <dholbach> sommer: sounds good

[16:10:18] <rick_h> oh, ok then

[16:10:18] <persia> sommer: Yes. Exactly.

[16:10:26] <dholbach> let's all download the source for meta-gnome2

[16:10:29] <dholbach> apt-get source meta-gnome2

[16:11:07] <Hunding> shouldn't you use "aptitude" rather than "apt-get"? Smile :)

[16:11:14] <dholbach> if you all look at the debian/control.in file (as sommer rightly pointed out)

[16:11:20] <dholbach> Hunding: your choice Smile :)

[16:11:22] <gnomefreak> problem is why would meta-gnome2 depend on -dbg packages? shouldnt they be recommend/suggestion?

[16:11:41] <dholbach> gnome-dbg is a meta package that you install if you should need it

[16:11:55] <dholbach> it's mostly intended for developers Smile :-)

[16:12:04] <persia> gnomefreak: The source is meta-gnome2, but the binary package listed in the first comment is gnome-dbg, for which debug packages are expected dependencies.

[16:12:24] <sommer> quick question, why is there a control and control.in file?

[16:12:26] <gnomefreak> ah grabbing source would have helped first Wink ;)

[16:12:58] <dholbach> sommer: that's a special case (debian gnome packages make use of debian/control.in) - the Uploaders: field is generated on the fly

[16:13:13] <dholbach> it has no practical use for ubuntu and is a special case

[16:13:15] <sommer> ah I see

[16:13:28] <dholbach> so if we look at the file we will see that it contains a couple of stanzas

[16:13:40] <dholbach> the first is about the source package, the others about the so-called binary packages

[16:13:59] <dholbach> binary packages is what you install, source package is what you edit, build and upload to the ubuntu build daemons

[16:14:33] <dholbach> also it contains information about which packages the binaries depend on, in the case of the source package what is needed to build the package

[16:14:42] <dholbach> does that make sense and is obvious to everybody?

[16:15:59] <dholbach> ok, I hope that no questions means 'OK' Smile :-)

[16:16:01] <sommer> so binary packages will only depend on other binary packages? and source packages depend on other source packages?

[16:16:20] <dholbach> sommer: build-depends in the case of source packages, but yeah essentially correct

[16:16:53] <sommer> cool I think I'm clear on deps now.

[16:16:54] <dholbach> let's look at the Package: gnome-dbg line (line 256)

[16:17:16] <dholbach> because that's what geser rightly found out about the bug already: that's where the problem is

[16:17:52] <dholbach> another thing that geser demonstrates in the bug: it's very important that you share all your knowledge - if you find out anything and don't see a solution to move on, just add it to the bug report

[16:18:11] <dholbach> it will somebody else's life easier

[16:18:24] <dholbach> so looking at gnome-dbg, it depends on a whole lot of other packages

[16:18:40] <dholbach> libtotem-plparser1-dbg and epiphany-browser-dbg included

[16:18:44] <dholbach> which are not part of gutsy

[16:18:46] <dholbach> what do we do?

[16:19:10] <dholbach> how can we check if we need to update them to a different package name or something?

[16:20:01] <sommer> sync from debian?

[16:20:30] <dholbach> we could do that, but we'd have to check the complete package of debian first and see if it fixes our problem

[16:20:54] <dholbach> how would we fix it just for ubuntu gutsy?

[16:21:37] <dholbach> I'd check which totem and epiphany-browser packages are effectively available in gutsy and see if we find a replacement for the current gnome-dbg deps

[16:21:58] <dholbach> daniel@lovegood:~$ apt-cache showsrc totem | head -n2

[16:21:58] <dholbach> Package: totem

[16:21:58] <dholbach> Binary: totem-mozilla, libtotem-plparser-dev, totem-xine, totem-gstreamer, libtotem-plparser7, totem

[16:21:58] <dholbach> daniel@lovegood:~$

[16:21:59] * persia notes that doing the investigation of the debian package would generally be preferable, if this weren't a time-limited Q&A session

[16:22:33] <dholbach> as we can see, Ubuntu Gutsy does not offer any -dbg packages any more

[16:22:41] <dholbach> so it looks safe to drop the dependency

[16:22:53] <dholbach> let's take a look at epiphany-browers

[16:23:03] <dholbach> daniel@lovegood:~$ apt-cache showsrc epiphany-browser | head -n2

[16:23:03] <dholbach> Package: epiphany-browser

[16:23:03] <dholbach> Binary: epiphany-browser, epiphany-browser-dev

[16:23:03] <dholbach> daniel@lovegood:~$

[16:23:19] <dholbach> same... so we can safely remove those two for now

[16:24:09] <dholbach> now we add a changelog entry to debian/changelog and try to build the package

[16:24:29] <dholbach> (you need to install devscripts if you haven't already, so we can use dch for that)

[16:25:04] <dholbach> then you run dch -i

[16:25:44] <dholbach> and add a changelog entry like " * debian/control.in: removed libtotem-plparser1-dbg and epiphany-browser-dbg dependencies, they are not in gutsy anymore." to it

[16:25:53] <dholbach> does that work for everybody?

[16:26:28] <sommer> I'm with ya

[16:26:38] <dholbach> to build it, we need a few tools and the build-dependencies for meta-gnome2

[16:26:47] <dholbach> sudo apt-get install build-essential fakeroot; sudo apt-get build-dep meta-gnome2 will hopefully suffice

[16:26:56] <blueyed> Add a LP: #xxx reference to the changelog, too.

[16:27:06] <dholbach> blueyed: excellent point!

[16:27:15] <dholbach> (LP: #145543) in this case

[16:27:29] <blueyed> So the bug gets automatically closed as fixed released.

[16:27:39] <dholbach> ... with the package upload.

[16:27:51] <dholbach> right-o - let me know once you're all there

[16:28:51] <dholbach> anybody having problems?

[16:29:40] <dholbach> ok let's hope we're all doing well Smile :-)

[16:29:45] <dholbach> now you run debuild

[16:29:58] <blueyed> not "debuild -S"?

[16:30:15] <dholbach> we'll try to build the package and see if that works Smile :)

[16:31:09] * persia notes that for those using sbuild or pbuilder, breaking this into two steps debuild -S and $my_build_tool $package_source.changes is also acceptable.

[16:32:39] * blueyed normally does "pdebuild" (uses pbuilder) for the build test and then debuild -S to create the .dsc/.changes file for use with debdiff.

[16:32:50] <dholbach> so in my case I have a gnome-dbg_2.18.3ubuntu2_all.deb which depends on: Depends: libatk1.0-dbg, libatspi-dbg, libgail-dbg, libglib2.0-0-dbg, gnome-applets-dbg, gnome-panel-dbg | libpanel-applet2-dbg, libgnomevfs2-0-dbg, libgtk2.0-0-dbg, libgnomeui-0-dbg, nautilus-dbg, libpango1.0-0-dbg, evolution-data-server-dbg, evolution-dbg, libgsf-gnome-1-114-dbg, gstreamer0.10-plugins-base-dbg, gstreamer0.10-plugins-good-dbg, gstreamer0.10-plugin

[16:32:50] <dholbach> s-ugly-dbg, libgstreamer0.10-0-dbg, libgtkhtml3.8-dbg, evince-dbg

[16:33:00] <dholbach> no totem, no epiphany

[16:33:15] <dholbach> I just tried to install it with gdebi, works nicely

[16:33:53] <dholbach> now you can run debuild -S (which will build a source package of the new version)

[16:34:57] <dholbach> if you now look at the output of debdiff meta-gnome2_2.18.3ubuntu1.dsc meta-gnome2_2.18.3ubuntu2.dsc

[16:35:06] * persia notes that some packages are buggy, and running debuild -S after having run debuild may be messy. If you have trouble with something like this, #ubuntu-motu is a great place to ask for help.

[16:35:09] <dholbach> you will see the source changes we made

[16:35:30] <dholbach> sommer: there you will notice that debian/control.in is generated from debian/control

[16:35:35] <dholbach> and has our changes too

[16:35:38] <blueyed> persia: so it's safer to use debuild -S and test the build using the .changes file?

[16:35:40] <dholbach> is everybody seeing that?

[16:36:23] <sommer> ah... cool

[16:36:36] <persia> blueyed: Yes and No. Yes, that you won't have issues with a bad clean rule. No, that you won't discover the bad clean rule (which should be fixed).

[16:37:38] <dholbach> so can somebody run:

[16:37:47] <blueyed> persia: you won't detect a bad clean rule with pbuilder, would you? Ah.. you've said "debuild". I see.. sorry for confusion.

[16:37:52] <dholbach> debdiff meta-gnome2_2.18.3ubuntu1.dsc meta-gnome2_2.18.3ubuntu2.dsc > meta-gnome2.debdiff

[16:38:04] <dholbach> and attach the meta-gnome2.debdiff file to the bug report? Smile :)

[16:38:07] <persia> blueyed: No. You wouldn't detect it.

[16:38:31] <blueyed> dholbach: is there a convention for naming the diff? I would have used meta-gnome2_2.18.3ubuntu2.dsc.diff

[16:38:48] <dholbach> blueyed: no there isn't really - lots of people do like you do

[16:38:56] <dholbach> some name it _.debdiff

[16:39:11] <dholbach> if it's attached to the bug with a comment "this makes it work", that's the most important point to it Smile :)

[16:39:17] <norsetto> blueyed: actually you can, by using a pbuilder hook (which is what I do)

[16:39:51] <persia> When sponsoring, I prefer package_version.dsc.diff or package_version.debdiff, as it makes is easier to keep track of different patches to different packages.

[16:40:21] <dholbach> who came up with a debdiff file? Smile :)

[16:40:28] <blueyed> norsetto: which does some comparison of before/after contents? That's interesting. Is it available somewhere?

[16:41:00] <norsetto> blueyed: no, I just use it to run debuild -S after the build, and then make the comparison

[16:41:03] <persia> dholbach: It was suggested to me for my first ever patch. I forget by whom.

[16:41:25] <norsetto> blueyed: I found it by looking at the source of revu-tools

[16:42:49] <blueyed> I would have a debdiff.. Smile :)

[16:42:59] <dholbach> sommer, rick_h: do you have a debdiff too? Smile :)

[16:43:48] <rick_h> sorry, boss chimed in and I had to run away to help him fix his mac problem

[16:43:52] <rick_h> I'm tring to play catchup

[16:44:26] <sommer> dholbach: sorry, someone had a question in RL... yep I've got a debdiff.

[16:44:51] <dholbach> sommer: if you can attach it to the bug report, we can take a look at it together

[16:45:45] <sommer> okay, one sec

[16:45:56] <blueyed> norsetto: can you maybe add it to the PBuilderHowto on the wiki?

[16:46:31] <norsetto> blueyed: sure I could, I suggested that that page is added to the packaging guide actually, it would even be better

[16:49:48] <rick_h> dholbach, back in the changelog entry do we increment the meta-gnome2 (1:2.18.3ubuntu1) ?

[16:49:51] <rick_h> or just leave it?

[16:50:12] <dholbach> rick_h: 1:2.18.3ubuntu2 would be correct

[16:50:30] <rick_h> ok, so we don't change it to a .4ubuntu assuming this gets updated

[16:50:30] <blueyed> rick_h: that's what the "-i" in "dch -i" makes.

[16:51:37] <sommer> dholbach: sorry I was called away again.

[16:52:01] <norsetto> blueyed: its very easy, you just add your hookdir to the pbuilder call, for instance --hookdir /usr/share/pbuilder/pbuilder-hooks/

[16:52:33] <norsetto> blueyed: and then you add in your hookdir the script B01debuildtest (or your modified one) from the revu-tools package

[16:53:21] <persia> rick_h: You would only want to change it to -4ubuntu1 if you were merging all the changes from Debian's -4.

[16:55:47] <rick_h> ok, I failed debuild due to the missing gpg key so I need to fix that

[16:56:01] <rick_h> is this transcription avail online so I can try to finish once I get that done/

[16:56:27] <norsetto> blueyed: all the script is doing is saving the .dsc and .diff.gz, running debuild -S, grepping the ^---.*orig*/ string in the diff and saving it, and restores the .dsc and .diff.gz

[16:57:12] <persia> rick_h: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-classroom-current.html is a bit behind (and it will get a date stamp at some point), but it should have the transcript in the next couple hours.

[16:57:44] <rick_h> thanks

[16:57:45] <dholbach> rick_h: that's fine, you don't need the key

[16:57:50] <norsetto> persia: dholbach has a local log, I usually use that and generate the log in in MOTU wiki

[16:57:56] <rick_h> oh, it told me it failed so I assumed I was stuck for now

[16:58:00] <dholbach> I think MootBot generates one too

[16:58:09] <dholbach> rick_h: you can run debuild on both .dsc files

[16:58:10] <blueyed> rick_h: when signing fails, the build is ok though. (you could use debuild -us -uc to skip signing)

[16:58:11] <persia> rick_h: You can also use debuild -us -uc to debuild without a key.

[16:58:11] <rick_h> yea, I knew it was recording somewhere, just not sure whree

[16:58:37] <persia> MootBot does, and makes it pretty, but I don't know where it stores the results.

[16:58:38] <rick_h> ok, thanks

[16:59:10] <rick_h> ok, that worked for the build then

[16:59:36] <blueyed> thanks, norsetto. I'll set it up here.

[16:59:53] <dholbach> anybody able to post the debdiff to the bug?

[17:00:32] <blueyed> rick_h in a minute.. Smile :)

[17:00:59] <dholbach> rock on

[17:03:41] <rick_h> heh, I'm looking but I think my debdiff is messed up

[17:03:59] <dholbach> can you upload it somewhere so we can take a look?

[17:04:12] <rick_h> http://paste.avwsystems.com/paste/47

[17:04:51] <dholbach> rick_h: is that all?

[17:04:59] <rick_h> oh, I see what happened

[17:05:04] <dholbach> rick_h: did you edit debian/control.in and ran dch -i before?

[17:05:08] <rick_h> heh, I initially did sudo apt-get source

[17:05:13] <rick_h> and then later removed and started over

[17:05:21] <rick_h> without sudo

[17:05:48] <Hobbsee> sudo wouldnt make a difference for that - it's only grabbing the source, and sticking it in your current directory, then unpacking it

[17:06:58] <rick_h> yea, I just had the files all owned by root so I started over real quick.

[17:07:23] <rick_h> I also missed the dch command and did the changelog manually. Much nicer with dch

[17:07:27] <dholbach> yeah

[17:07:39] <dholbach> Ok, let's close the session for today - we've been running for more than 1,5h already

[17:07:46] <blueyed> Should I upload then for now?

[17:07:49] <rick_h> ok, so running it debbuild again

[17:08:29] <dholbach> so please somebody attach the debdiff to the bug, I'm subscribed to it and will review it as soon as I read it in my mails Smile :-)

[17:08:41] <dholbach> thanks everybody for showing up to the session

[17:08:44] <blueyed> done

[17:08:47] <rick_h> thanks for the time

[17:08:57] <dholbach> please stop by on #ubuntu-motu, ubuntu-motu@lists.ubuntu.com or ubuntu-motu-mentors@lists.ubuntu.com

[17:08:57] <blueyed> Thank you.

[17:09:13] <dholbach> I'll announce the next session for next friday soon, so hope to see you there again

[17:09:23] <dholbach> hope to see you all as MOTUs soon Wink ;-)

[17:09:39] <sourcercito> rick_h, do you want to upload the debdiff yourself?, i could upload it, if you don't want that is

[17:09:57] <sourcercito> thanks dholbach it has been a great class :-D

[17:10:10] <dholbach> rock on Smile :-)

[17:10:19] <rick_h> just go ahead and upload please thanks

[17:10:28] <blueyed> I've just uploaded (after doing so to a wrong bug) Wink ;)

[17:10:34] <sourcercito> ok, noprob

[17:10:35] <dholbach> hehe

[17:10:39] <sourcercito> hehehe

[17:10:45] <sourcercito> blueyed, do you want to upload it?

[17:10:57] <dholbach> please mail me or let me know if you run into any problems

[17:11:01] <blueyed> sourcercito: done, twice Wink ;)

[17:11:05] <sourcercito> i'm not currently asking for motu sponsorship, so i wont benefit

[17:11:15] <sourcercito> :P

[17:11:27] <blueyed> Me neither. I wanted to do so in the hardy cycle.. Smile :)

[17:12:16] <sourcercito> blueyed, i guess, you forget to delete the last "," in the control.in

[17:12:17] <dholbach> sourcercito: soon Smile :)

[17:12:33] <sourcercito> dholbach, yes, i will do it Wink ;)

[17:13:01] <dholbach> great

[17:13:04] <dholbach> see you guys around!

[17:13:07] <dholbach> #endmeeting

Meeting ended.

Go back to MOTU/Q&A/Logs.

MOTU/Q&A/Logs/12-10-07 (last edited 2008-08-06 16:13:41 by localhost)