| === tonyy is now known as tonyyarusso | ||
| === tonyy is now known as tonyyarusso | ||
| === cracksonj_ is now known as cracksonj | ||
| ace09 | hmm mo ones here | 07:04 |
|---|---|---|
| ace09 | hello? | 07:07 |
| dholbach | MOTU Q&A session in 11 minutes | 12:48 |
| dholbach | Welcome to another MOTU Q&A session! | 13:00 |
| dholbach | Let's make a habit out of it and quickly introduce ourselves - who do we have here today? | 13:00 |
| txwikinger2 | txwikinger2 is here | 13: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 | |
| dholbach | who 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-team | 13:01 | |
| * dholbach high-fives txwikinger2 - that's great :) | 13:01 | |
| txwikinger2 | s/what's/wants/ | 13:01 |
| dholbach | welcome void^ | 13:01 |
| * RainCT greets | 13:01 | |
| dholbach | hey RainCT | 13:01 |
| void^ | hello :) | 13:01 |
| dholbach | I suspect a few other lurkers in here, that's fine | 13:02 |
| dholbach | who of you is interested in MOTU but still very new to all the processes, new to packaging, etc? | 13:02 |
| frenchy | dholbach: That'd be me. | 13:03 |
| dholbach | welcome frenchy | 13:03 |
| frenchy | dholbach: Hi there! | 13:03 |
| dholbach | do you have any questions off the top off your hat already? | 13:03 |
| dholbach | how did you find your journey with the MOTU team so far? :) | 13:03 |
| txwikinger2 | very interesting | 13:04 |
| dholbach | anything that bothers you, anything that's unclear right now? | 13:04 |
| frenchy | What's the best way to manage packages for 2 versions of a Distro? i.e. Gutsy/Hardy. | 13:04 |
| dholbach | for 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 links | 13:05 |
| dholbach | welcome dbkeen | 13:05 |
| txwikinger2 | good question frenchy | 13:05 |
| dholbach | frenchy: as in test-building them? | 13:05 |
| frenchy | dholbach: I have found -motu to be a huge source of help for me. | 13:06 |
| dholbach | frenchy: that's great to hear :) | 13:06 |
| * txwikinger2 agrees with frenchy | 13:06 | |
| dholbach | PPA is a good choice for "releasing" test packages for all kinds of releases | 13:06 |
| dholbach | for building them locally, I'd either recommend having a chroot | 13:06 |
| frenchy | Not really, ummm ... mainly around the debian/changelog file | 13:06 |
| dholbach | http://wiki.ubuntu.com/DebootstrapChroot is a good introduction | 13:06 |
| dholbach | ah ok | 13:07 |
| frenchy | dholbach: Yeah, but translations are being plucked from your PPA ATM. As I found out yesterday. | 13:07 |
| dholbach | the bug to get that fixed is filed and I hope it gets done soon | 13:07 |
| * RainCT is also a Contributor who wants to become a MOTU, and he maintains a few packages in Debian | 13:07 | |
| * dholbach high-fives RainCT - excellent | 13:07 | |
| dholbach | so let's suppose you have updates of a package you want to get into both gutsy and hardy | 13:08 |
| dholbach | the most obvious upload target is hardy as it is our current development release | 13:08 |
| frenchy | dholbach: Yeah. | 13:08 |
| dholbach | gutsy is released already, so we can't do uploads there directly | 13:08 |
| frenchy | dholbach: But I've got existing users. | 13:08 |
| dholbach | so for example you'd upload gcalctool 2.21.0-0ubuntu1 to hardy | 13:08 |
| dholbach | if it has important fixes that need to go to gutsy, you'd want to upload to gutsy-updates in the end | 13:09 |
| dholbach | in that case you'd follow the process described on http://wiki.ubuntu.com/StableReleaseUpdates | 13:09 |
| dholbach | a list of criteria like for the update is available there | 13:09 |
| dholbach | we try to only update minimal patches to -updates to just fix a single really important issue | 13:10 |
| dholbach | so on the existing bug report you'd attach the minimal patch and get it uploaded to gutsy-proposed | 13:10 |
| dholbach | that's what our eager testers install, so we'll get feedback on any regressions | 13:11 |
| dholbach | for this upload you'd probably do something like gcalctool 2.21.0-0ubuntu1~6.10prop1 gutsy-proposed | 13:11 |
| dholbach | that way people can still upgrade to 2.21.0-0ubuntu1 once they upgrade to hardy | 13:12 |
| dholbach | does that make sense? | 13:12 |
| dholbach | getting the versioning right is really important | 13:12 |
| txwikinger2 | 6.10 or 7.10 ? | 13:12 |
| dholbach | um sorry, 7.10 in this example | 13:12 |
| * dholbach lives in the past | 13:12 | |
| txwikinger2 | :) | 13:12 |
| txwikinger2 | so what happens when you upgrade to hardy? will the hardy package upgrade the gutsy package? | 13:13 |
| dholbach | once 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 |
| dholbach | txwikinger2: yes | 13:13 |
| dholbach | daniel@lovegood:~$ dpkg --compare-versions 1.2.3-1~prop1 lt 1.2.3-1; echo $? | 13:13 |
| dholbach | 0 | 13:13 |
| dholbach | daniel@lovegood:~$ | 13:13 |
| dholbach | so that means 1.2.3-1~prop1 < 1.2.3-1 | 13:14 |
| frenchy | dholbach: 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 |
| frenchy | dholbach: Although I'm very interested in what you were saying. | 13:14 |
| dholbach | which means the upgrade path from gutsy (+ -updates) to hardy is safe | 13:14 |
| dholbach | frenchy: ah ok, I see | 13:14 |
| dholbach | well in case you're the person that takes most case of the package, you could think about using bzr for the packaging | 13:15 |
| dholbach | in that case you could have a gutsy and a hardy branch of the packaging | 13:15 |
| dholbach | bzr-builddeb is a great tool to make package maintenance in bzr easy | 13:15 |
| dholbach | https://wiki.ubuntu.com/PackagingGuide/Recipes/UseBzrAndBzrBuildpackage unfortunately is a bit sparse | 13:16 |
| frenchy | dholbach: Yeah I had that but it became very messy keeping 2 versions up-to-date. | 13:16 |
| dholbach | somebody 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 schedule | 13:16 |
| dholbach | frenchy: really? what were the problems you encountered? | 13:17 |
| frenchy | dholbach: 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 |
| dholbach | generally 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 release | 13:18 |
| dholbach | frenchy: ok, so your case isn't really the "normal maintaining work-flow" | 13:19 |
| frenchy | dholbach: Ok, so it's really just a teething issue. | 13:19 |
| frenchy | Yup. | 13:19 |
| dholbach | you seem to do the changes on both releases | 13:19 |
| dholbach | in that case only the debian/changelog file should require merging | 13:19 |
| dholbach | a ~/project/gutsy$ bzr merge ../hardy should in most cases do what you want | 13:20 |
| dholbach | if you have your branches publically available and run into problems again, please let me know and we figure something out together | 13:20 |
| dholbach | OK? | 13:20 |
| frenchy | Yeah, I had o keep a separate changelog. Seems a bit crazy. | 13:20 |
| dholbach | a separate changelog shouldn't be necessary, I guess | 13:21 |
| dholbach | do 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 |
| txwikinger2 | the most cumbersome for me is to slowly understand the different parts of the process | 13:22 |
| frenchy | Sorry, but when you do that merge it'll clobber the gutsy changelog with the hardy one. So then I should replace it. | 13:23 |
| dholbach | txwikinger2: what are you referring to? do you have any examples? | 13:23 |
| dholbach | frenchy: in most cases, I'd probably keep the hardy portions and add a "upload to gutsy" entry at the top with a correct version number | 13:23 |
| txwikinger2 | well, like one package needed to get an sync from debian .. I thought I had to provide a debdiff for it.. such small things | 13:23 |
| dholbach | txwikinger2: do you feel the documentation is not clear enough? | 13:24 |
| dholbach | or not obvious enough to look for it? | 13:24 |
| txwikinger2 | I think you guys know a lot of this stuff inside out, but when you come new to it can be confusing | 13:24 |
| txwikinger2 | I think there is a lot of good documentation | 13:24 |
| RainCT | txwikinger2: (the debdiff would be for a merge) | 13:24 |
| dholbach | ok | 13:24 |
| dholbach | so what I try to establish is this wiki structure: | 13:25 |
| dholbach | UbuntuDevelopment/* for all process related information (sync, merges, release schedule, etc) | 13:25 |
| dholbach | PackagingGuide/* for all packaging details | 13:25 |
| txwikinger2 | maybe sometimes it is either difficult to know where to look, or to have a overview kinda thing | 13:25 |
| dholbach | MOTU/* for all stuff that has to do with the MOTU team organisation | 13:25 |
| txwikinger2 | It is not really major, since there is help from the MOTUs which helps the learning curve | 13:26 |
| dholbach | but 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 on | 13:26 |
| dholbach | because only very few people read the whole wiki documentation before they start joining the MOTU team :) | 13:26 |
| dholbach | and I'm one of those that probably wouldn't do that :) | 13:26 |
| dholbach | if you ever feel documentation is missing or wrong, please let me know and I'll try to fix it | 13:27 |
| txwikinger2 | yes, I will | 13:27 |
| dholbach | do we have any other questions? | 13:27 |
| dholbach | if I remember correctly you all submitted patches and packages for sponsoring already? | 13:28 |
| txwikinger2 | yes | 13:28 |
| frenchy | Me too | 13:28 |
| dholbach | how did that work out for you? | 13:28 |
| txwikinger2 | good. I was helped in a very friendly way, and learned a lot by very good comments | 13:29 |
| dholbach | great | 13:29 |
| frenchy | Well, 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 |
| dholbach | frenchy: what applicaiton is it? | 13:31 |
| frenchy | Cool, a chance for a plug ... Me TV, a DVB application for GNOME. | 13:31 |
| frenchy | Me TV, it's TV for me computer. | 13:32 |
| dholbach | ahhh nice | 13:32 |
| dholbach | well, 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 |
| frenchy | dholbach: "go on"? REVU? | 13:33 |
| dholbach | I'll make sure to take a look at it later on | 13:33 |
| dholbach | sorry, I meant it should move on into the archive | 13:33 |
| dholbach | is there a particular packaging problem you all have run into recently and want to discuss? | 13:34 |
| frenchy | dholbach: Thank you, I'd appreciate any packaging help you can give. I think that I've got it pretty good shape. | 13:34 |
| dholbach | rock and roll :) | 13:34 |
| dholbach | is there anything you DIDN'T like up until now, anything you think that should be improve or change? | 13:35 |
| dholbach | somebody should blog about this... nothing bad to say about MOTU! :-) | 13:36 |
| frenchy | I've got a ton of questions but I'm trying to be polite and let someone else have a go. | 13:36 |
| RainCT | heh | 13:36 |
| dholbach | frenchy: fire away | 13:36 |
| dholbach | frenchy: just ask your questions :) | 13:39 |
| dholbach | they might be of interest to others | 13:39 |
| frenchy | Is 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 |
| dholbach | it's not essential - it's definitely nice to have | 13:40 |
| dholbach | especially in cases where you have command line options that make a change | 13:40 |
| dholbach | sometimes you don't want to run a command, but how to invoke it properly before or have a place for good information about it | 13:41 |
| frenchy | Can 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 nothing | 13:41 |
| frenchy | ? | 13:41 |
| cjwatson_ | because that's not necessarily something you know up-front | 13:41 |
| === cjwatson_ is now known as cjwatson | ||
| cjwatson | the man page can include anything you like :) | 13:41 |
| frenchy | Cool, Ta. | 13:41 |
| dholbach | I 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 |
| cjwatson | as dholbach says, it's not critical, but it's something you should add for smooth integration | 13: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 |
| dholbach | anything else that came across your mind, when receiving review feedback or doing the packaging? | 13:43 |
| frenchy | With 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 |
| dholbach | frenchy: I don' think I understand | 13:44 |
| dholbach | if 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 |
| frenchy | Well, 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 |
| frenchy | Am I missing something? | 13:46 |
| frenchy | Is this the nature of the beast? | 13:47 |
| dholbach | the way that GNOME deals with it is: do development, have a string freeze, let people do translations, release | 13:47 |
| dholbach | it might be good to notify your translators about "hey I'm going to do a release in a few days" or something | 13:47 |
| frenchy | Ohhhh ... I've seen that in the release schedule and never knew what it was for ... thanks. | 13:47 |
| dholbach | it's good to have the .pot file in rosetta up-to-date too | 13:48 |
| dholbach | rock and roll :) | 13:48 |
| frenchy | Some of them are slow though ... you know ... life gets in the way. | 13:48 |
| dholbach | RainCT, txwikinger2: everything's been smooth for you up until now? | 13:48 |
| dholbach | frenchy: any more of yout "ton of questions"? :) | 13:49 |
| * RainCT is trying to remember if he had any problem... | 13:49 | |
| frenchy | I | 13:50 |
| frenchy | I'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 |
| dholbach | that's a good question :) | 13:51 |
| * RainCT also uses CDBS and loves it :P | 13:51 | |
| dholbach | I like using CDBS since it spares me the pain of copy-ing and past-ing huge sections from other packages | 13:51 |
| dholbach | a definite problem CDBS has: it's really hard to look behind the scenes and know what happens | 13:52 |
| dholbach | and the documentation is not ideal either | 13:52 |
| frenchy | Yeah, that's what I heard. | 13:52 |
| Amaranth | so either it works fine or you spend a weekend crying trying to figure out what it's doing :P | 13:53 |
| dholbach | for new contributors it's not easy to understand from something like | 13:53 |
| dholbach | include /usr/share/cdbs/1/rules/debhelper.mk | 13:53 |
| dholbach | include /usr/share/cdbs/1/rules/simple-patchsys.mk | 13:53 |
| dholbach | include /usr/share/cdbs/1/class/gnome.mk | 13:53 |
| dholbach | what the individual important build targets are | 13:53 |
| frenchy | Ohh ... it works great for me. I just didn't want other people laughing at me for using it. | 13:53 |
| dholbach | there's a fine divide between "not having to care about details" and "not knowing what really happens" :) | 13:54 |
| frenchy | In general, it's a good idea then? | 13:54 |
| frenchy | As a developer I know all about that. | 13:54 |
| dholbach | I think it's definitely good to take a look at a lot of different packages and read the policy when you're unsure | 13: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 | |
| dholbach | CDBS shouldn't be a complete black box for you :) | 13:55 |
| dholbach | there's one definite page at: | 13:55 |
| dholbach | https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml | 13:55 |
| frenchy | What time does the class end? | 13:56 |
| dholbach | got it from https://wiki.ubuntu.com/MOTU/Documentation | 13:56 |
| dholbach | in 4 minutes | 13:56 |
| dholbach | but you can continue to ask questions in #ubuntu-motu | 13:56 |
| dholbach | or on ubuntu-motu-mentors@lists.ubuntu.com | 13:56 |
| ian_brasil | dholbach: IMHO opinion this needs rewriting in the ubuntu style!! | 13:56 |
| RainCT | thanks, bookmarked | 13:56 |
| dholbach | ok... any final comments? is this session useful to you? | 13:57 |
| frenchy | For sure. Very late though in Canberra. | 13:57 |
| * ian_brasil catching up | 13:58 | |
| dholbach | frenchy: ohhhh ok :) | 13:58 |
| dholbach | I can imagine | 13:58 |
| dholbach | I really hope that somebody else will pick this up and run a session suitable for people in other timezones | 13:58 |
| dholbach | for example 0:00 UTC would be nice, if somebody did that | 13:58 |
| frenchy | Thanks. | 13:59 |
| dholbach | I'll ask around if somebody volunteers | 13:59 |
| dholbach | ok great.... thanks for joining the session and thanks for your good questions | 14:00 |
| dholbach | see you online soon again | 14:00 |
| * dholbach rushes out for a dogwalk :) | 14:00 | |
| ian_brasil | dholbach: thx again for running thse sessions | 14:00 |
| dholbach | ian_brasil: my pleasure :) | 14:01 |
| ian_brasil | i have a quick question not really about packaging but about best practice | 14:02 |
| dholbach | fire away | 14:02 |
| ian_brasil | i have patched hildon into some software | 14:02 |
| ian_brasil | and it modifies the glade file | 14:02 |
| dholbach | so you patched some software to make use of hildon, ok? | 14:02 |
| ian_brasil | upstream are nervous about incorporating the patch | 14:02 |
| dholbach | that's a bit problematic then | 14:03 |
| ian_brasil | because merging the patch would mean to break it after | 14:03 |
| ian_brasil | a short while without me even noticing. | 14:03 |
| ian_brasil | me = the maintainer | 14:04 |
| dholbach | I'd recommend talking to the upstream people and let them know that you tried it out and got good feedback from a lot of people | 14:04 |
| dholbach | maybe that helps, generally upstream folks like having their software work in a lot of different places | 14:04 |
| ian_brasil | the problem is that glade does not have hildon compatibility | 14:05 |
| ian_brasil | so every | 14:05 |
| ian_brasil | change done against the original one has to be merged (or at least | 14:05 |
| ian_brasil | checked for relevance) to the Hildon-specific one | 14:05 |
| dholbach | right, so if upstream merged your patch upstream you would have to check every new release again and again | 14:05 |
| dholbach | I think that's what's bound to happen | 14:06 |
| ian_brasil | dholbach: right | 14:06 |
| dholbach | I think there's no good way around testing :) | 14:06 |
| dholbach | I'm sorry if I can't give you a better answer than that | 14:06 |
| dholbach | lool might also know some more about that | 14:07 |
| dholbach | he's been in touch with upstreams and patching their stuff much more than I did | 14:07 |
| ian_brasil | no, i just wanted to know if i should try to push hard(er) for it to be accepted upstream | 14:07 |
| txwikinger2 | sorry, I had a phone call | 14:07 |
| ian_brasil | if there was some precedent on this in ubuntu? | 14:08 |
| dholbach | ian_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 places | 14:08 |
| dholbach | ian_brasil: but I feel that's the best that you can do | 14:08 |
| dholbach | try to ask the folks in #ubuntu-desktop | 14:09 |
| dholbach | they've been in touch with GNOME folks a lot when it came to getting patches applied upstream | 14:09 |
| dholbach | and have a bunch of stories (good and bad) about it to tell | 14:09 |
| ian_brasil | dholbach: ah ok, thanks for the advice | 14:09 |
| dholbach | thanks for the question ian_brasil | 14:09 |
| dholbach | now I need to take my dog for a walk | 14:09 |
| dholbach | see you guys later | 14:09 |
| txwikinger2 | dholbach: Yes things are going smooth for me :) | 14:09 |
| dholbach | txwikinger2: great :) | 14:10 |
| lool | Heya | 14:10 |
| lool | ian_brasil: You need upstream to maintain the hildon flavor or you need to maintain it, but someone needs to check hildon still work after changes | 14:10 |
| lool | ian_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_brasil | lool: hi, i maintain 2 glade files | 14:11 |
| ian_brasil | lool: so in this case it is better that then i maintain it as upstream does not have much experience with hildon | 14:13 |
| ian_brasil | at least i can make sure it works ;) | 14:13 |
| lool | ian_brasil: Basically someone needs to make sure changes work within hildon | 14:15 |
| lool | The closest things are upstream, the easier | 14:15 |
| lool | So if it's easy to maintain a small delta, that's best | 14:15 |
| lool | If you need to maintain a separate file, you'll have to check whether they changed the way they use the glade file | 14:16 |
| ian_brasil | lool: yes, i thought that.. hildon support in glade is definitely an itch for me a.t.m | 14: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!