=== tonyy is now known as tonyyarusso
=== tonyy is now known as tonyyarusso
=== cracksonj_ is now known as cracksonj
ace09hmm mo ones here07:04
dholbachMOTU Q&A session in 11 minutes12:48
dholbachWelcome to another MOTU Q&A session!13:00
dholbachLet's make a habit out of it and quickly introduce ourselves - who do we have here today?13:00
txwikinger2txwikinger2 is here13:00
* dholbach is Daniel Holbach, member of the MOTU team for quite a while, trying to make it as straight-forward as possible to join the team and help out.13:00
dholbachwho else is in for the Q&A session today? :)13:00
* txwikinger2 is a MOTU-contributor and what's to become a member of the MOTU-team13:01
* dholbach high-fives txwikinger2 - that's great :)13:01
dholbachwelcome void^13:01
* RainCT greets13:01
dholbachhey RainCT13:01
void^hello :)13:01
dholbachI suspect a few other lurkers in here, that's fine13:02
dholbachwho of you is interested in MOTU but still very new to all the processes, new to packaging, etc?13:02
frenchydholbach: That'd be me.13:03
dholbachwelcome frenchy13:03
frenchydholbach: Hi there!13:03
dholbachdo you have any questions off the top off your hat already?13:03
dholbachhow did you find your journey with the MOTU team so far? :)13:03
txwikinger2very interesting13:04
dholbachanything that bothers you, anything that's unclear right now?13:04
frenchyWhat's the best way to manage packages for 2 versions of a Distro?  i.e. Gutsy/Hardy.13:04
dholbachfor those of you just lurking and trying to figure out how cool MOTU is, I recommend https://wiki.ubuntu.com/MOTU/GettingStarted - it's a quick overview of interesting and important links13:05
dholbachwelcome dbkeen13:05
txwikinger2good question frenchy13:05
dholbachfrenchy: as in test-building them?13:05
frenchydholbach: I have found -motu to be a huge source of help for me.13:06
dholbachfrenchy: that's great to hear :)13:06
* txwikinger2 agrees with frenchy13:06
dholbachPPA is a good choice for "releasing" test packages for all kinds of releases13:06
dholbachfor building them locally, I'd either recommend having a chroot13:06
frenchyNot really, ummm ... mainly around the debian/changelog file13:06
dholbachhttp://wiki.ubuntu.com/DebootstrapChroot is a good introduction13:06
dholbachah ok13:07
frenchydholbach: Yeah, but translations are being plucked from your PPA ATM.  As I found out yesterday.13:07
dholbachthe bug to get that fixed is filed and I hope it gets done soon13:07
* RainCT is also a Contributor who wants to become a MOTU, and he maintains a few packages in Debian13:07
* dholbach high-fives RainCT - excellent13:07
dholbachso let's suppose you have updates of a package you want to get into both gutsy and hardy13:08
dholbachthe most obvious upload target is hardy as it is our current development release13:08
frenchydholbach: Yeah.13:08
dholbachgutsy is released already, so we can't do uploads there directly13:08
frenchydholbach: But I've got existing users.13:08
dholbachso for example you'd upload    gcalctool 2.21.0-0ubuntu1  to  hardy13:08
dholbachif it has important fixes that need to go to gutsy, you'd want to upload to gutsy-updates in the end13:09
dholbachin that case you'd follow the process described on http://wiki.ubuntu.com/StableReleaseUpdates13:09
dholbacha list of criteria like for the update is available there13:09
dholbachwe try to only update minimal patches to -updates to just fix a single really important issue13:10
dholbachso on the existing bug report you'd attach the minimal patch and get it uploaded to gutsy-proposed13:10
dholbachthat's what our eager testers install, so we'll get feedback on any regressions13:11
dholbachfor this upload you'd probably do something like     gcalctool 2.21.0-0ubuntu1~6.10prop1   gutsy-proposed13:11
dholbachthat way people can still upgrade to  2.21.0-0ubuntu1  once they upgrade to hardy13:12
dholbachdoes that make sense?13:12
dholbachgetting the versioning right is really important13:12
txwikinger26.10 or 7.10 ?13:12
dholbachum sorry, 7.10 in this example13:12
* dholbach lives in the past13:12
txwikinger2so what happens when you upgrade to hardy? will the hardy package upgrade the gutsy package?13:13
dholbachonce you've got enough good feedback on the proposed updates, you'll do an update to gutsy-updates (and use 2.21.0-0ubuntu1~7.10 as version number)13:13
dholbachtxwikinger2: yes13:13
dholbachdaniel@lovegood:~$ dpkg --compare-versions 1.2.3-1~prop1 lt 1.2.3-1; echo $?13:13
dholbachso that means   1.2.3-1~prop1 < 1.2.3-113:14
frenchydholbach: Sorry, I don't think that I've explained myself very clearly.  The most cumbersome part of my packaging is keeping 2 versions of the debian directory and swapping them in/out before the dpkg-buildpackage ... is there a better way?13:14
frenchydholbach: Although I'm very interested in what you were saying.13:14
dholbachwhich means the upgrade path from gutsy (+ -updates) to hardy is safe13:14
dholbachfrenchy: ah ok, I see13:14
dholbachwell in case you're the person that takes most case of the package, you could think about using bzr for the packaging13:15
dholbachin that case you could have a gutsy and a hardy branch of the packaging13:15
dholbachbzr-builddeb is a great tool to make package maintenance in bzr easy13:15
dholbachhttps://wiki.ubuntu.com/PackagingGuide/Recipes/UseBzrAndBzrBuildpackage unfortunately is a bit sparse13:16
frenchydholbach: Yeah I had that but it became very messy keeping 2 versions up-to-date.13:16
dholbachsomebody asked for a MOTU School session about it and I think that James Westby (the bzr-builddeb author) would be happy to give one - we should really get it on the schedule13:16
dholbachfrenchy: really? what were the problems you encountered?13:17
frenchydholbach: Well, I'm new to bzr.  I've been needing to update the Hardy one based on feedback from REVU but every time I did that I really needed to be also updating the Gutsy version.13:18
dholbachgenerally the "old release" branches shouldn't receive that many commits as the packages are released and we don't want to introduce too many changes in a stable release13:18
dholbachfrenchy: ok, so your case isn't really the "normal maintaining work-flow"13:19
frenchydholbach: Ok, so it's really just a teething issue.13:19
dholbachyou seem to do the changes on both releases13:19
dholbachin that case only the debian/changelog file should require merging13:19
dholbacha    ~/project/gutsy$ bzr merge ../hardy      should in most cases do what you want13:20
dholbachif you have your branches publically available and run into problems again, please let me know and we figure something out together13:20
frenchyYeah, I had o keep a separate changelog.  Seems a bit crazy.13:20
dholbacha separate changelog shouldn't be necessary, I guess13:21
dholbachdo we have any other questions? any other workflow or packaging bits that seem cumbersome, irksome or just wrong to you guys at the moment?13:21
txwikinger2the most cumbersome for me is to slowly understand the different parts of the process13:22
frenchySorry, but when you do that merge it'll clobber the gutsy changelog with the hardy one.  So then I should replace it.13:23
dholbachtxwikinger2: what are you referring to? do you have any examples?13:23
dholbachfrenchy: in most cases, I'd probably keep the hardy portions and add a "upload to gutsy" entry at the top with a correct version number13:23
txwikinger2well, like one package needed to get an sync from debian .. I thought I had to provide a debdiff for it.. such small things13:23
dholbachtxwikinger2: do you feel the documentation is not clear enough?13:24
dholbachor not obvious enough to look for it?13:24
txwikinger2I think you guys know a lot of this stuff inside out, but when you come new to it can be confusing13:24
txwikinger2I think there is a lot of good documentation13:24
RainCTtxwikinger2: (the debdiff would be for a merge)13:24
dholbachso what I try to establish is this wiki structure:13:25
dholbachUbuntuDevelopment/* for all process related information (sync, merges, release schedule, etc)13:25
dholbachPackagingGuide/* for all packaging details13:25
txwikinger2maybe sometimes it is either difficult to know where to look, or to have a overview kinda thing13:25
dholbachMOTU/* for all stuff that has to do with the MOTU team organisation13:25
txwikinger2It is not really major, since there is help from the MOTUs which helps the learning curve13:26
dholbachbut I feel there's a certain amount of knowledge you have to learn by osmosis, by hanging out with people, talking to them, reading mailing list posts and so on13:26
dholbachbecause only very few people read the whole wiki documentation before they start joining the MOTU team :)13:26
dholbachand I'm one of those that probably wouldn't do that :)13:26
dholbachif you ever feel documentation is missing or wrong, please let me know and I'll try to fix it13:27
txwikinger2yes, I will13:27
dholbachdo we have any other questions?13:27
dholbachif I remember correctly you all submitted patches and packages for sponsoring already?13:28
frenchyMe too13:28
dholbachhow did that work out for you?13:28
txwikinger2good. I was helped in a very friendly way, and learned a lot by very good comments13:29
frenchyWell, mine's a very specialised application and not many MOTUs will have the hardware to use it.  So the sponsoring has been hard to get.  But the packaging advice has been excellent.13:30
dholbachfrenchy: what applicaiton is it?13:31
frenchyCool, a chance for a plug ... Me TV, a DVB application for GNOME.13:31
frenchyMe TV, it's TV for me computer.13:32
dholbachahhh nice13:32
dholbachwell, if it's good to go from a packaging POV, it should go on, so people can test it and report bugs back :)13:32
frenchydholbach: "go on"?  REVU?13:33
dholbachI'll make sure to take a look at it later on13:33
dholbachsorry, I meant it should move on into the archive13:33
dholbachis there a particular packaging problem you all have run into recently and want to discuss?13:34
frenchydholbach: Thank you, I'd appreciate any packaging help you can give.  I think that I've got it pretty good shape.13:34
dholbachrock and roll :)13:34
dholbachis there anything you DIDN'T like up until now, anything you think that should be improve or change?13:35
dholbachsomebody should blog about this... nothing bad to say about MOTU! :-)13:36
frenchyI've got a ton of questions but I'm trying to be polite and let someone else have a go.13:36
dholbachfrenchy: fire away13:36
dholbachfrenchy: just ask your questions :)13:39
dholbachthey might be of interest to others13:39
frenchyIs a man page essential for a GUI application?  I've asked this question in -motu ... and the answer was "yes" ...  but never found out why?13:40
dholbachit's not essential - it's definitely nice to have13:40
dholbachespecially in cases where you have command line options that make a change13:40
dholbachsometimes you don't want to run a command, but how to invoke it properly before or have a place for good information about it13:41
frenchyCan the man page include information about how to set up the application.  I just don't see this very often.13:41
cjwatson_even a manual page that says that the program takes no options and explains itself in the GUI is better than nothing13:41
cjwatson_because that's not necessarily something you know up-front13:41
=== cjwatson_ is now known as cjwatson
cjwatsonthe man page can include anything you like :)13:41
frenchyCool, Ta.13:41
dholbachI agree that in cases like "a gnome applet" adding a manpage that explains that you should use the "add to panel" dialog can be a bit irksome :)13:42
cjwatsonas dholbach says, it's not critical, but it's something you should add for smooth integration13:42
cjwatson(the way Debian policy looks upon this is that you can upload a package without a man page, but you should file a bug about it to remind yourself or somebody else to do it in the future)13:43
dholbachanything else that came across your mind, when receiving review feedback or doing the packaging?13:43
frenchyWith translating ... with my understanding of it I get a "chicken before the egg" problem.  Can you please explain at what part of the process I'm meant to add the translations?13:44
dholbachfrenchy: I don' think I understand13:44
dholbachif you are upstream, you 1) make sure the code is translatable, 2) generate the .pot file, 3) spread it, 4) put .po files back into the source code?13:45
frenchyWell, I make the application, upstream tarball, load the translations up to LP.  But then when all the translations roll in months later I have to update the upstream with partially old translatiosn.13:46
frenchyAm I missing something?13:46
frenchyIs this the nature of the beast?13:47
dholbachthe way that GNOME deals with it is: do development, have a string freeze, let people do translations, release13:47
dholbachit might be good to notify your translators about "hey I'm going to do a release in a few days" or something13:47
frenchyOhhhh ... I've seen that in the release schedule and never knew what it was for ... thanks.13:47
dholbachit's good to have the .pot file in rosetta up-to-date too13:48
dholbachrock and roll :)13:48
frenchySome of them are slow though ... you know ... life gets in the way.13:48
dholbachRainCT, txwikinger2: everything's been smooth for you up until now?13:48
dholbachfrenchy: any more of yout "ton of questions"? :)13:49
* RainCT is trying to remember if he had any problem...13:49
frenchyI've heard some people complaining about CDBS and how it's not ideal ... I use CDBS.  Is it recommended that I use CDBS?13:51
dholbachthat's a good question :)13:51
* RainCT also uses CDBS and loves it :P13:51
dholbachI like using CDBS since it spares me the pain of copy-ing and past-ing huge sections from other packages13:51
dholbacha definite problem CDBS has: it's really hard to look behind the scenes and know what happens13:52
dholbachand the documentation is not ideal either13:52
frenchyYeah, that's what I heard.13:52
Amaranthso either it works fine or you spend a weekend crying trying to figure out what it's doing :P13:53
dholbachfor new contributors it's not easy to understand from something like13:53
dholbachinclude /usr/share/cdbs/1/rules/debhelper.mk13:53
dholbachinclude /usr/share/cdbs/1/rules/simple-patchsys.mk13:53
dholbachinclude /usr/share/cdbs/1/class/gnome.mk13:53
dholbachwhat the individual important build targets are13:53
frenchyOhh ... it works great for me.  I just didn't want other people laughing at me for using it.13:53
dholbachthere's a fine divide between "not having to care about details" and "not knowing what really happens" :)13:54
frenchyIn general, it's a good idea then?13:54
frenchyAs a developer I know all about that.13:54
dholbachI think it's definitely good to take a look at a lot of different packages and read the policy when you're unsure13:54
* RainCT remembers that CDBS's documentation is a problem.. Every page he looks says something different... :S (for example one says that install:: gets executed before dh_install, another document says that it does later..)13:54
dholbachCDBS shouldn't be a complete black box for you :)13:55
dholbachthere's one definite page at:13:55
frenchyWhat time does the class end?13:56
dholbachgot it from https://wiki.ubuntu.com/MOTU/Documentation13:56
dholbachin 4 minutes13:56
dholbachbut you can continue to ask questions in #ubuntu-motu13:56
dholbachor on ubuntu-motu-mentors@lists.ubuntu.com13:56
ian_brasildholbach: IMHO opinion this needs rewriting in the ubuntu style!!13:56
RainCTthanks, bookmarked13:56
dholbachok... any final comments? is this session useful to you?13:57
frenchyFor sure.  Very late though in Canberra.13:57
* ian_brasil catching up13:58
dholbachfrenchy: ohhhh ok :)13:58
dholbachI can imagine13:58
dholbachI really hope that somebody else will pick this up and run a session suitable for people in other timezones13:58
dholbachfor example 0:00 UTC would be nice, if somebody did that13:58
dholbachI'll ask around if somebody volunteers13:59
dholbachok great.... thanks for joining the session and thanks for your good questions14:00
dholbachsee you online soon again14:00
* dholbach rushes out for a dogwalk :)14:00
ian_brasildholbach: thx again for running thse sessions14:00
dholbachian_brasil: my pleasure :)14:01
ian_brasili have a quick question not really about packaging but about best practice14:02
dholbachfire away14:02
ian_brasili have patched hildon into some software14:02
ian_brasiland it modifies the glade file14:02
dholbachso you patched some software to make use of hildon, ok?14:02
ian_brasilupstream are nervous about incorporating the patch14:02
dholbachthat's a bit problematic then14:03
ian_brasilbecause merging the patch would mean to break it after14:03
ian_brasila short while without me even noticing.14:03
ian_brasilme = the maintainer14:04
dholbachI'd recommend talking to the upstream people and let them know that you tried it out and got good feedback from a lot of people14:04
dholbachmaybe that helps, generally upstream folks like having their software work in a lot of different places14:04
ian_brasilthe problem is that glade does not have hildon compatibility14:05
ian_brasilso every14:05
ian_brasilchange done against the original one has to be merged (or at least14:05
ian_brasilchecked for relevance) to the Hildon-specific one14:05
dholbachright, so if upstream merged your patch upstream you would have to check every new release again and again14:05
dholbachI think that's what's bound to happen14:06
ian_brasildholbach: right14:06
dholbachI think there's no good way around testing :)14:06
dholbachI'm sorry if I can't give you a better answer than that14:06
dholbachlool might also know some more about that14:07
dholbachhe's been in touch with upstreams and patching their stuff much more than I did14:07
ian_brasilno, i just wanted to know if i should try to push hard(er) for it to be accepted upstream14:07
txwikinger2sorry, I had a phone call14:07
ian_brasilif there was some precedent on this in ubuntu?14:08
dholbachian_brasil: I'd try to explain to them exactly what it does, that you have people who tested it and it brings no regressions and that they benefit from having their app run in various different places14:08
dholbachian_brasil: but I feel that's the best that you can do14:08
dholbachtry to ask the folks in #ubuntu-desktop14:09
dholbachthey've been in touch with GNOME folks a lot when it came to getting patches applied upstream14:09
dholbachand have a bunch of stories (good and bad) about it to tell14:09
ian_brasildholbach: ah ok, thanks for the advice14:09
dholbachthanks for the question ian_brasil14:09
dholbachnow I need to take my dog for a walk14:09
dholbachsee you guys later14:09
txwikinger2dholbach: Yes things are going smooth for me :)14:09
dholbachtxwikinger2: great :)14:10
loolian_brasil: You need upstream to maintain the hildon flavor or you need to maintain it, but someone needs to check hildon still work after changes14:10
loolian_brasil: There are many ways, like having one glade file for hildon and regular one, or patching the main one at build etc.14:11
ian_brasillool: hi, i maintain 2 glade files14:11
ian_brasillool: so in this case it is better that then i maintain it as upstream does not have much experience with hildon14:13
ian_brasilat least i can make sure it works ;)14:13
loolian_brasil: Basically someone needs to make sure changes work within hildon14:15
loolThe closest things are upstream, the easier14:15
loolSo if it's easy to maintain a small delta, that's best14:15
loolIf you need to maintain a separate file, you'll have to check whether they changed the way they use the glade file14:16
ian_brasillool: yes, i thought that.. hildon support in glade is definitely an itch for me a.t.m14:23
=== neversfelde_ is now known as neversfelde
=== cracksonj_ is now known as cracksonj
=== nixternal_ is now known as nixternal

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!