=== bigon is now known as bigon` [11:24] Hi all [12:48] MOTU Q&A session in 11 minutes [13:00] Welcome everybody to another MOTU Q&A session - let's start with our usualy round of introductions [13:00] I'm Daniel Holbach, working in the MOTU team for quite some time now and try to help to make it as enjoyable and straight-forward to become a MOTU as possible. :) [13:00] who else do we have here? [13:00] * persia is Emmet Hikory. A MOTU for a bit now. Ask me about stacktraces and make :) [13:01] persia: stacktraces and make? [13:01] norsetto: Yep. Those are the areas I'm most happy to answer questions about right now (I will also answer others :) ) [13:02] is that everybody we have here today? Just persia, norsetto and me? :) [13:02] I am Efrain Valles ... the ever MOTU hopefull, just started learning the MOTU tools and the processes. I am working on merges :D [13:02] we need a fourth to play a good card game [13:03] hello effie_jayx :) [13:03] I'm here too... just a contributor indeed, but getting a lot of fun :) [13:03] warp10: great! :) [13:03] also effie_jayx is taking the time to write up sort of a MOTU Diary which is great [13:03] effie_jayx: can you give us the link again? [13:04] Hi all! My name is Miguel Ruiz (MOTU hopeful). I started to interact with MOTU Team during Gutsy Gibbon cycle [13:04] hey mruiz, great to have you here [13:04] dholbach, https://wiki.ubuntu.com/EfrainValles/MOTUJourney [13:04] I am a bit behind ... ... it looks like it'll be a very MOTU christmas for me to catch up [13:04] thanks dholbach :-) [13:05] I am definetelly learning though... [13:05] thanks effie_jayx [13:05] Im harrison, MOTU hopefull [13:05] hey harrisony, nice to have you here [13:05] * kelmo_lap having a look at what MOTU's learn about (these sessions been pretty good in recent past) [13:05] hey kelmo_lap [13:05] so who brought some interesting questions today? :) [13:06] Me [13:06] effie_jayx: fire away :-) [13:06] * persia has a question [13:06] I am Onkar, MOTU hopeful, I have been looking in some java related apps/libs recently. Have learnt quite a few things in last 2 weeks including CDBS & quilt. :-) [13:06] dholbach, I just did a merge. the change has been taken up by the debain mantainer... which is gret... [13:06] slytherin: hey Onkar [13:07] dholbach, do I have to check the new package to see if it has new changes and then determine if it is indeed a sync? [13:07] I'm also here.. MOTU hopeful =) [13:07] slytherin: that's great - you should talk to doko - he's always happy to have people who are interested in the Java world [13:07] hi Kmos [13:07] effie_jayx: You don't need to, but it's a good idea. If it's a sync, it's only worth pulling if there are also other changes in the Debian package that would be useful in Ubuntu. [13:07] effie_jayx: exactly... as a sync can not be simply reverted, it's important to always check if all ubuntu changes made it to debian [13:08] if they are, it's a good idea to file the sync (respecting freezes of course) [13:08] Since Ubuntu already has your patch, if that is the only thing changed in Debian, it's better to wait for the next Debian upload. [13:08] dholbach, great.. the pacakge was just uploaded to the debian ftp's yesterday. will it be listed again in MoM or DaD? [13:08] effie_jayx: after the next run, yes - until it's synced from debian [13:09] or rather "in sync" with debian [13:09] question answered? [13:09] dholbach, most definetelly [13:09] persia: you had a question? [13:09] * persia points to http://qa.ubuntuwire.com/multidistrotools/ just in case MoM and DaD seem unavailable, and there is interest in looking at package status. [13:09] thanks persia and dholbach [13:09] * dholbach hugs effie_jayx [13:10] My questions is: Is there a standard list of intepreters that scripts should use? [13:10] Do you mean a list of shebang lines that are count as 'accepted'? [13:11] Or, to put it another way, when packaging a script, should I restrict to only certain interpreters, or should dependencies handle this (and yes, to shebang lines) [13:11] Does everybody understand persia's question? If things are unclear, please ask [13:11] dholbach, explain it please... [13:11] persia: the only thing I can tell you is that the use of thing like /usr/bin/env python is discouraged [13:12] (lacking a link to policy reference though) [13:12] dholbach: That's what I found (and why I thought I'd ask the question). [13:12] dholbach: i thought the use of /usr/bin/env was encouraged :S [13:12] dholbach: why is /usr/bin/env discouraged? Looks suprising to me [13:13] harrisony: No, as the script should have been tested against either the system default python or a specific version of python. Using env means that we can't guarantee behaviour on the user's system, which makes it harder to support. [13:14] (people might have python3k in usr/local etc) [13:14] warp10: It's a little different, as upstream tends to recommend that, but it comes from different viewpoints: upstream tests against trunk or whatever, and wants reports of what works and what doesn't. Ubuntu wants a reliable system for a given codebase. [13:14] but I'm still trying to find a policy reference or something [13:14] mruiz: persia is talking about the shebang line in scripts, so something like #!/usr/bin/python [13:15] thanks dholbach [13:15] * persia notes that http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html says to use #!/usr/bin/python or #!/usr/bin/pythonX.Y, but doesn't find a general reference. [13:15] persia: ah, I see... so what should I do, as contributor, when I see env used in a file coming from upstream? Modify original tarball? Ask the developer? [13:16] warp10: I usually just add a small patch to the package. For upstream, env is correct, and it's not good to modify tarballs. [13:16] persia: ack. Thank you [13:17] I just asked for clarification in #ubuntu-devel [13:17] let's see if we get another opinion on the matter [13:17] * persia defers to the next question in the meantime [13:17] do we have any other questions? [13:17] yes! [13:18] * warp10 has a question [13:18] * Kmos I've a question.. [13:18] persia: seb128 says that "If a maintainer would like to provide the user with the possibility to override the Debian Python interpreter, he may want to use /usr/bin/env python or /usr/bin/env pythonX.Y. However this is not advisable as it bypasses Debian's dependency checking and makes the package vulnerable to incomplete local installations of python." should be good enough [13:19] mruiz: shoot [13:19] warp10 next, then Kmos [13:19] Well, I have a proposal, rather then a question. [13:19] dholbach: Yep. That's python. Answers the extra question :) [13:19] I was looking effie_jayx, MOTU web page. It is very interesting, and I like that he has "Lesson Notes" appended to it [13:19] What will happen with the outstanding merges? We moved to another tasks due the current development phase... [13:20] Why don't we setup a page on the wiki, something like a Quick Reference to most commond task, command, tips, and so on [13:20] mruiz: "Outstanding Merges" are very likely to be granted a DIF exception. "Updated Merges" need review. [13:20] mruiz: whatever is on the sponsoring queue will get sponsored - if you want to do a merge during the release cycle - that's fine (respecting freezes, etc), but it's not the 'main focus' right now [13:20] It could be useful for a contributor that doesn't remember something and don't wont to search the whole documentation [13:20] warp10: that's something I try to make http://wiki.ubuntu.com/PackagingGuide/Recipes [13:21] warp10: if you have ideas for more recipes, let me know - I'm happy to add it to my todo list [13:21] * persia has tried to put the very most common on https://wiki.ubuntu.com/MOTU/Contributing [13:21] yeah [13:21] that's a great one too [13:21] dholbach: I mean something even shorter, and managed by contributor, just like effie_jayx is doing [13:22] warp10: I'd suggest Recipes is the right place. Many of those have been written by Contributors. [13:22] warp10: If contributors help to keep the wiki in shape, that's awesome and I encourage it where I can [13:23] what I'd like to avoid is to have 78843456787654345678 individual wiki pages in different namespace that explain the same thing or similar things [13:23] they get abandoned, out of date, etc etc [13:23] I spent a lot of time reorganising the PackagingGuide, UbuntuDevelopment and MOTU namespaces for those reasons [13:23] warp10, I guess my journal falls into the "works for me" category ;). and I am trying to give it a noob focus to it... and always trying to document what I learn... in case I get [13:23] memory loss [13:23] * persia notes that we recently had that problem, which is why WIP is currently so prominent [13:24] effie_jayx: a very nice page indeed :) [13:24] There is a Fakesync document on MOTU wiki? i can't find it.. [13:24] you could add requests or ideas to https://wiki.ubuntu.com/PackagingGuide/Wishlist [13:24] Kmos: can you add that to the page in the link I just pasted? [13:24] warp10, but I always make reference to de UbuntuDevelopment wiki entries... so It's not like it was not there ;) [13:25] i'll do =) [13:25] thanks [13:25] Kmos: There isn't one. The rule for fakesync is; only change the changelog and maintainer. This only happens when the orig.tar.gz files differ. [13:25] thanks Kmos [13:25] dholbach: oh, thanks, I'll surely use it if needed [13:25] rock and roll [13:25] * slytherin has a question [13:25] thanks for that [13:25] slytherin: fire away [13:25] 2008 will be the year of good documentation - I can feel it [13:26] heh [13:26] * warp10 really hopes so [13:26] Kmos, dholbach explained fakesyncs here: https://lists.ubuntu.com/archives/ubuntu-motu-mentors/2007-June/000024.html [13:27] I observed that docbook-xsl-saxon has BTBFS because it depends on library in multiverse (but it should not be). I logged a bug 'move to universe' and it is now resolved by pitti. Now how to trigger rebuild of the docbook-xsl-saxon package. [13:27] slytherin: just ask pitti (or another build admin) in #ubuntu-devel to "give it back" [13:28] mruiz: thanks [13:28] Ok. Thanks. [13:28] * persia notes that that procedure only works when there are no binaries. [13:28] persia: Which procedure? [13:29] If there are binary packages built, and you want to transition the binary packages from multiverse to universe, you may need to upload a -build1 package, or a new "rebuild" -ubuntuN package. [13:29] persia: thank you :) we change the maintainer fields in debian package and make a debdiff against unmodified one ? [13:29] slytherin: Asking for a give-back. [13:29] Kmos: Only if a sync can't work. generally, a sync is better if we can. [13:29] dholbach: you should not need a give back when a build is depwait [13:30] persia: right. thanks [13:30] No. The package is in universe but had FTBFS since it depended on a multiverse lib [13:30] kmos: in that particular case it may be worth waiting for debian to update the package [13:30] ok, listen to seb128 :) [13:30] norsetto :-) [13:30] slytherin: docbook-xsl-saxon is in DEPWAIT [13:30] geser: latest status? I haven't checked. [13:30] so it's worth noting that DEPWAIT is different than FTBFS [13:31] does that make sense to everybody? are there questions about slytherin's question? [13:31] I was reading https://wiki.ubuntu.com/MOTU/Contributing, section "Preparing New Revisions". What is the difference between an "update to the Ubuntu repositories" and "new upstream version" ? [13:32] slytherin: https://edge.launchpad.net/ubuntu/hardy/+source/docbook-xsl-saxon/+builds [13:32] when a package is not available the build doesn't fail, it just waits for this one to be available [13:32] geser: Just checked it. Thanks. :-) [13:32] mruiz: A "New Upstream Version" is when the software developers make a new release (e.g. hello-2.3.2 -> hello 2.3.3). A "New Revision" is when Debian or Ubuntu makes some packaging changes to fix some bugs. [13:32] seb128: Thanks for explaination. [13:32] slytherin: my guess is that it takess some more hours until the buildds sees libsaxon-java in universe [13:32] you are welcome [13:33] persia, for me the new upstream version could be an update for Ubuntu as well... [13:33] mruiz: Yes. Every new upstream version is also a new revision, but not every new revision is a new upstream version. [13:34] I asked it because you should obtain a debdiff or interdiff (it depends on the type) [13:34] Essentially, the code is package_version-revision, where package is the name of the software, version is the official version for all distributions, and revision is the adjustments made by the distribution. [13:35] persia: to your previous question: [13:35] dholbach: using /usr/bin/env has a big drawback as opposed to just specifying the path (which IMHO you should) [13:35] dholbach: using /usr/bin/env makes it impossible to specify command-line arguments or switches to python (or perl) for example [13:35] * persia notes that my question was about unusual interpreters, but otherwise subsides [13:37] do we have any more questions? [13:37] I have one [13:37] a tong in cheek question.... [13:37] MoM or DaD? [13:37] slytherin: fire away [13:37] effie_jayx: Either, both, as you like (mdt is also good) [13:37] effie_jayx, it's my fault :-) [13:37] What is the procedure to own a package? [13:37] mruiz, yes... [13:38] slytherin: in Ubuntu we don't own packages [13:38] slytherin: I generally recommend taking it only on a second upload. [13:38] If there is a very good reason why you specifically want to own a package, you can list yourself as the maintainer, but that isn't universally respected. [13:38] I added a few notes about that here: https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#head-6a3fb9097d750eed261d7102adfa43ea39839a1e [13:39] Unless it's a very unusual case, it's best to either select a team, or just assign MOTU as the maintainer. [13:39] we respect if people are known to have a special area of expertise [13:39] but there is nothing like a big maintainer lock [13:39] * persia generally just subscribes to bugs for packages of interest, and uses the MOTU maintainer [13:39] What I mean is. I want to handle all the uploads of a package. I am one of the upstream maintainers. So what is the procedure? [13:39] persia: not respecting the maintainer field like that would have to be a @lartable offense, surely. [13:40] but yes, it's rarely done [13:40] Hobbsee: that's what I said about 'area of expertise' [13:40] right, yes, i didn't read that far when i wrote my reply :) [13:40] it's respected when you set yourself as the maintainer, but not to the point where "nobody but you is allowed to do uploads of that package" [13:41] slytherin: Why do you want to handle all of them? Is it not easier to handle the new upstreams, and also accept minor bugfixes from others? [13:41] If you subscribe to all the bugs, you'll see most of the traffic for the package. [13:41] slytherin: do the answers make sense to you? [13:42] a little bit, not completely. [13:42] * persia notes that setting specific maintainers can make library transitions difficult, which is one of the reasons it's discouraged [13:42] slytherin: what are your concerns or which reply does not make sense to you? [13:43] What I wanted to know is that if I am one of the upstream authors is there anyway I can get upload permission specific to this package? The package is in universe. [13:43] And I am not against anyone else uploading this package. [13:43] slytherin: do you mean "upload permission" until you're part of the MOTU team? [13:44] slytherin: Not at this time. There is an ongoing discussion about how to address that sort of thing in the mailing lists. [13:44] dholbach: No. I will try to use that upload permission as my entry point in MOTU. [13:44] persia: Ok. [13:44] Until that is resolved, the use of the sponsors queue is the best way to get your changes uploaded. [13:45] when your sponsors are happy with you and you've proved that you do good work, you can apply for MOTU membership [13:45] Ok. [13:45] it might be harder to demonstrate that if you've just done uploads of one package [13:45] but I know that you're not interested in only one package :-) [13:46] do we have any other questions? [13:47] anything unclear about processes? packaging problems? [13:48] ! [13:48] mruiz: just ask :) [13:50] I have a question... is ther a task timeline for motu tasks during a release cycle? [13:51] effie_jayx: we try to indicate that in MOTU homepage [13:51] http://wiki.ubuntu.com/MOTU/TODO always lists things that need to be done [13:51] any other questions? any holiday stories you want to share? [13:52] is there any plan to sponsor packages from mentors.debian.net ? Time ago I wanted to upgrade a package but the Debian maintainer did it before, but it packages are on mentors [13:52] effie_jayx: At a rough level, it's indicated by the freezes in the release schedule (e.g. https://wiki.ubuntu.com/HardyReleaseSchedule [13:52] ahhh cool [13:52] it gives me and Idea of where to start [13:52] mruiz: I think that our sponsors currently have enough to do just with REVU and the sponsoring queue - this might change in the future though [13:52] mruiz: We don't generally sync from mentors, but we can. It's a good source of orig.tar.gz, so we could sync later. === bigon` is now known as bigon [13:53] hi bigon [13:53] mruiz: If there are good changes, extracting them and creating a debdiff or interdiff is welcome [13:53] recently I have been doing lots of ubuntu travelling and I got unhooked for two weeks... and I am not confident enouht for the dayly TODO list [13:53] dholbach: hi :) [13:53] effie_jayx: I'm sure you'll do great [13:53] in this case the package is done, just I want to avoid duplicated work [13:54] One last question. [13:54] slytherin: shoot [13:54] mruiz: Understood. Using the mentors package as a base, and just adjusting the version and maintainer is often sufficient for an important bugfix. Otherwise, it's better to wait. [13:54] Are we for/against taking extra efforts to make java apps compile with GCJ? [13:55] slytherin: that's a question for doko - I can't comment on it [13:55] slytherin: That's a more general question. I'm in favor, but you should write a mailing list about it for general discussion. [13:55] there's also #ubuntu-java [13:55] there's a lot of talk about icedtea but I don't know if it's the answer to all questions [13:56] (simply due to not knowing enough about the whole java business) [13:56] is mentoring available for taks on MOTU/TODO ? [13:57] mruiz: just ask questions on #ubuntu-motu or ubuntu-motu-mentors@ or for a review once you've come up with a debdiff [13:57] mruiz: Not necessarily specifically, but if you want help with one, and ask on #ubuntu-motu, someone may well be willing to help (I certainly am for the WX transition) [13:57] help will come to those that ask (or something like that) [13:58] dholbach: There is one small problem. Most of the apps do not specify a target JVM in compile scripts. So compiling such packages with icedtea (target JVM 1.7) makes them unusable with all other JREs. So it is better to use common denominator, GCJ. :-) [13:58] slytherin: ok... you see: you know much more about it than I do :) [13:58] I will bug doko [13:58] ok... thanks everybody for joining today's MOTU Q&A session - I won't be around in the next two weeks, so we'll meet again in 2008 [13:58] a big hand to dholbach ... you are really getting people in the MOTU boat brother... keep up the great inspirational work. hats off to you dholbach [13:59] you all ROCK and I hope to see you as MOTUs in 2008 :-) [13:59] thanks guys.. I wish you good holidays and a merry Christmas [13:59] * effie_jayx claps [13:59] happy holidays everyone [13:59] * dholbach hugs effie_jayx - thanks a lot for the flowers [13:59] * dholbach hugs y'all :) [13:59] :-) [13:59] happy holidays [13:59] norsetto: the same to you [13:59] * effie_jayx hugs mruiz [14:00] * dholbach dashes out of the door to buy some missing presents :-) [14:00] dholbach, enjoy your holiday break [14:00] * norsetto dashes out of the door to have lunch ..... [14:00] * mruiz hugs everyone [14:00] norsetto: good point [14:00] thank you persia and mruiz for the great help with merges [14:01] effie_jayx, no worries! :D [14:01] effie_jayx: Thanks for helping keep the archive in shape. [14:01] persia, did I do that? [14:02] persia, thanks for your guidance :-) [14:02] effie_jayx: That's the end result of merges, syncs, bugfixes, etc. :) [14:03] :D === bigon is now known as bigon` === bigon` is now known as bigon === bigon is now known as bigon` === bigon` is now known as bigon === jpatrick_ is now known as jpatrick === bigon is now known as bigon` === bigon` is now known as bigon === bigon is now known as bigon` === bigon` is now known as bigon === bigon is now known as bigon` === bigon` is now known as bigon [19:35] salut [19:36] quit === txwikinger3 is now known as txwikinger === txwikinger3 is now known as txwikinger