=== bmk789 is now known as bmk789_sick_bed === bigon is now known as bigon` [12:52] MOTU Q&A session in 8 minutes [12:52] dholbach: can i have a pony? [12:53] that depends.... ;-) [12:53] on? [12:53] :-) [12:53] * dholbach right now needs to find out what we covered last time [12:53] dholbach: what to not do i think [12:54] $ ./hello * [12:54] yeah, I have a list of the other items on my box, but don't recall which bits we covered and which we didn't [12:54] ah found it... great [12:59] Welcome to another MOTU Q&A Session! [12:59] Who's here for some MOTU Q&A action? [12:59] * warp10 raises his hand [12:59] * rzr _o/ [13:00] Let's start with another round of introductions.... :-) === bigon` is now known as bigon [13:00] * dholbach is Daniel Holbach, member of the MOTU team and tries to make the MOTU journey as pleasant and straight-forward as possible :) [13:00] _0/ [13:00] * Hobbsee is the looney one [13:01] * warp10 is Andrea Colangelo, MOTU helpful, getting a lot of fun :) [13:01] * slytherin is a motu hopeful with special interest in java related packages [13:01] rock on warp10, slytherin! :-) [13:01] * rzr recently joined MOTU an maintains some packages also debian side ... [13:02] great [13:02] slytherin: java , we need to do a Q&A session about this i fell [13:02] do we have some questions already? [13:02] * warp10 has a question [13:02] warp10: fire away [13:02] slangasek: someday at least [13:02] I would like to request syncs for some packages in contrib and non-free. Since they are not in Ubuntu yet, what's the best way to find out if such packages can land in universe or need to stay in mutilverse? [13:03] * Hobbsee wants to become a MOTU [13:03] warp10: sometimes the changelog or copyright of the debian package already points out why it was moved to non-free or contrib in the first place [13:04] the archive admins will check the package carefully, when it is in non-free/contrib in Debian [13:04] if all fails, you need to check the license texts in the package yourself [13:04] (and the headers of source files, etc) [13:04] any other questions? [13:05] dholbach: Ok, great. And for the procedural side, it is enough to report a bug (maybe using requestsync) or is there any special procedure? [13:05] warp10: no, that's exactly the process [13:05] Cool. Thank you :) [13:06] it helps to point out explicitly what you know about the package, when you file the bug, but that's all there is about it [13:06] ok... if we don't have questions right now I'm sure we'll have some later on :) [13:06] as suggested can we fix a java Q&A session date , since icedtea is on good way .. [13:06] I can help about gcj too [13:06] some of you might know, last session we answered the question "how do we make the most awful package ever?" [13:07] we still have some proposals on the list we didn't talk about last time [13:07] if nobody has other questions, I think we'll just chat a bit about the other items on the list [13:07] dholbach: we use yada [13:07] ! [13:07] oh, no...no, no.... [13:07] Hobbsee: yeah, that was one of the proposals [13:07] * Hobbsee has one better than that [13:07] where's steve? [13:07] in bed? :) [13:07] interactive builds [13:07] an interactive build took out the buildds recently, didn't it? [13:07] no, he's still awake [13:08] yeah, it did [13:08] what amaranth proposed is quite effective for a bad package :-) [13:08] hello all I will join this session [13:08] welcome TuxCrafter [13:08] were is the agenda? [13:08] TuxCrafter: if you have any questions, be sure to just ask them - right now we're discussing how to really produce packages [13:08] dholbach: try a debian/rules file building the .deb by hand. [13:08] (and clarify how best not to do that) [13:08] Hobbsee: we had that too [13:08] TuxCrafter: see topic [13:08] hang on [13:08] oh, you saw that? [13:08] pity [13:09] http://daniel.holba.ch/temp/qa-negative [13:09] that's the answers we got last time [13:09] we're at this one right now: [13:09] interactive builds [13:09] an interactive build took out the buildds recently, didn't it? [13:09] dholbach: you also got the packages that require sun java to build, which require a licence agreement, or programs that attempt to download from the internet? [13:09] * slytherin has a suggestion [13:10] Hobbsee raises a good point [13:10] if you install sun-java* it will ask you to accept a license agreement [13:10] on a build daemon this manual interaction is impossible [13:10] slytherin: fire away [13:10] dholbach: it is there are some hack to [13:10] dholbach: you finish first. I have suggestion regarding java packages [13:10] dholbach: let me find this out ... [13:10] rzr: the buildd admins have to do it manually [13:11] dholbach: you haven't mentioned the hardcoded dependancies either [13:12] Hobbsee: on things like libsomething12 ? [13:12] dholbach: as in, lack of understanding about shlibdeps, and so hardcoding all the packages it needs to depend on in Depends: [13:12] including libraries like that, yes [13:12] yeah good point - I've seen that a couple of times [13:12] * Hobbsee has seen that more than a couple [13:12] does everybody understand what Hobbsee is referring to? [13:12] *** got a question for Q&A: If i look at the fedora process they have a very nice structured system with cody, will there come a similar system for ubuntu? [13:13] TuxCrafter: what's cody? [13:13] TuxCrafter: got a URL or something? [13:13] TuxCrafter: I'm afraid I don't know anything about cody - can you elaborate? [13:13] Hobbsee: my firefox is down i have to restart internet for it so i can find the info brb [13:13] TuxCrafter: please raise your hand first before asking question so that you don't interupt the current discussion. :-) [13:14] slytherin: you wanted to raise another point? [13:14] dholbach: Can you please explain what Hobbsee was saying [13:14] ok [13:14] most packages (for example those written in C or C++) have something similar to this in their depends line: [13:14] Hobbsee: I noted how to workaround the "ask licence" blocker : http://rzr.online.fr/q/pbuilder [13:14] Depends ${shlibs:Depends}, some-other-package [13:14] Depends: ${shlibs:Depends}, some-other-package [13:15] the package build system will check which libraries the binaries are actually linked against, and then substitute ${shlibs:Depends} automatically [13:15] so it's wrong to have a fixed Depends: libsomething12 [13:16] this is important for example in cases of library transitions (libsomething12 -> libsomething13) [13:16] if you use ${shlibs:Depends} a simple rebuild will probably suffice [13:16] slytherin: does that make more sense now? [13:16] dholbach: Yes it does. Thanks. [13:17] ok great [13:17] I hope the "interactive" item was clear too [13:17] *** has a question [13:17] TuxCrafter: fire away [13:17] *** my dns is down and cant connect to web-pages on this moment and is sorry for this [13:18] * Hobbsee didn't find any object named "cody" when searching for fedora and cody, where cody was not a person. [13:18] Hobbsee: same here [13:18] I have compared some debian packages with ubuntu and some of the ubuntu packages have far more dependecies than the ones in ubuntu, what can we do about this? [13:18] dholbach: you forgot packages requring scons. [13:18] what procedures to follow [13:18] TuxCrafter: reread, and correct your statement :) [13:18] Hobbsee: that's not necessarily a problem [13:19] dholbach: if it is written well, sure [13:19] dholbach: still, i guess there's not that much you can do if upstream decides to use it [13:19] s/ones in ubuntu/ones in debian/ [13:19] TuxCrafter: do you have examples? [13:20] dholbach: i believe last time I checked it was pidgin [13:20] I noticed for example GNOME packages that use different linker options nowadays which should resolve that [13:21] I think it was wl,as-needed that they used for that [13:21] but I can't really comment on that, I'm no expert there [13:21] TuxCrafter: debian's pidgin and ubuntu's pidgin don't tend to overlap [13:21] I think the summary was "it should be all good now" :-) [13:21] or didn't, last i checked [13:22] dholbach: Now the suggestion I have to make is ; We should make some policy that when new java apps/libs are being added in Ubuntu (not present in Debian), we should prefer GCJ as compiler (java-gcj-compat-dev) [13:22] I'm looking at packages.debian.org and launchpad.net right now [13:23] slytherin: that's something the Debian / Ubuntu Java Team should decide - I can't really comment on the fitness of any compiler [13:24] Ok. [13:24] but the problem behind it was that there were some people thing of creating a distribution spin of ubuntu or debian for the eeepc, and choice for debian because the dependecy were better and there for the total install size was much smaller for the same functionality. To bad i cant give exact examples because of my current dns problem. [13:24] TuxCrafter: to me it seems like there's only liblaunchpad-integration0 which is in addition to the debian depends [13:24] s/thing/thinking/ [13:24] talking about that, when a java app can be built as native code, should it be ? what is the policy ? [13:25] rzr: we absolutely prefer that [13:25] there are packages in multiverse that ship pre-built .jar files, but we try to avoid it [13:25] I plan to do this on my packages, provide a -native and -java packages from the same source [13:25] *** is going to reset its modem to see if the dns problem resolves [13:26] TuxCrafter: I can't comment on that - it'd be nice to see the results of an investigation - at the moment I see no points indicating that [13:26] TuxCrafter: good luck [13:26] TuxCrafter: using other dns server may help [13:26] TuxCrafter: does adding "nameserver 141.1.1.1" to /etc/resolv.conf help or is it more complicated than that? [13:26] rzr: native may not be prefered. But I am not sure if there is any policy for/against that [13:26] TuxCrafter: opendns.com [13:27] Kmos: might be a bit hard to look it up without working DNS :) [13:27] slangasek: what are the reason to prefer jvm to native for applications ? [13:27] dholbach: right... [13:27] rzr: will they run with all the VMs? [13:28] rzr: oops, please excuse me if I don't understand the concept of native code [13:28] TuxCrafter: btw : nslookup opendns.com = 208.67.219.99 [13:28] 208.67.222.222 ; 208.67.220.220 -> opendns [13:28] *** everything working again [13:28] great [13:28] ok... any other questions? [13:28] (moving on while we have no real Java expert around) [13:29] (doko in #ubuntu-devel and man-di are the most knowledgeable people I know) [13:29] dholbach: I plan to become one before hardy. :-) [13:29] slytherin: excellent - that's highly appreciated :) [13:29] slytherin: i think it's a bit out topic, we'll talk about it the java q+a day :) [13:30] ok... anything else? if not we'll continue with our "how to make a BAD package" discussion :) [13:30] rzr: sure if we have one [13:31] missing .desktop file for a graphical application [13:31] https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles has a lot of information on the topic of .desktop files [13:31] it's generally a good idea to add them (preferrably in upstream land) [13:32] icons in wrong places [13:32] is a similar point [13:32] missing files in the package [13:32] is a really interesting one [13:32] if you have a source package that is split up in several binary packages this mistake is very easy to make [13:32] talking about icons, can we just automatize missing icons from screenshots of apps ? [13:33] *** got a other question [13:33] rzr: it's a lot of work :) [13:33] TuxCrafte1: fire away [13:33] dholbach: for a human , not a script shell , I'll note this down :) [13:34] were is the defined behaviour for the remove --purge options on packages, because some times they remove for example an init script and sometimes they dont. what are the rules for this and were can you find them and who is makeing them [13:36] as far as I know conf files are not to be removed, just if you purge the package [13:37] debian/conffiles is the file where they are registered [13:37] coming back to the "missing files in a package" item [13:37] one of the easiest ways to avoid this is running [13:38] debuild -us -uc && dh_install --list-missing [13:38] which will (of the built source tree) make a list of files that the upstream build system wants to install, but are not installed into one of the binary packages [13:38] Cool... [13:39] also it's annoying if the upstream tarball ships example code or documentation, which never makes it into /usr/share/doc/ [13:39] users should not have to download the upstream source to do that :) [13:39] if necessary you can split out documentation into a separate -doc package [13:39] software without active upstream [13:39] dholbach, but what if the software is finished? [13:39] * persia likes software without active upstream, if it is stable and well written. [13:39] (software is never finished?) [13:40] we often receive packages of new software where the last updates were made in 2004 [13:40] if you plan to maintain such a package, think twice if you really want to take care of bugs of this package, if there's nobody you can escalate problems to [13:41] a good relationship to the upstream maintainer (and maintainers of other distros) is really important [13:41] the next point on the list is somewhat similar: [13:41] inactive maintainer, no bug triage [13:41] if you plan to maintain a package, make sure that you plan to read bug reports of your users :-) [13:42] you don't need to fix them all yourself, but you somehow need to take care of them [13:42] any questions? [13:42] maybe indicate that a package has no active maintainer [13:42] both on the ubuntu side as upstream [13:42] TuxCrafte1: can you elaborate? [13:42] as part of the Q&A [13:43] I'm afraid I don't understand [13:44] dholbach: it can happen that people sent in bug reports and nothing happends to them, it would be nice for people the be able to see in lets say launcepad that the package has no active maintainers [13:44] this way you give some information about the quality/state of the used package [13:44] right, but I think no user should have to worry about that, that's why it's important to bear that in mind when you start packaging new software [13:45] a lot of packages have maintenance teams and not a dedicated maintainer [13:45] true [13:45] any other questions? [13:46] the session ended there last time, but persia had some items he encountered during reviews of packages [13:46] Changelog in debian/docs [13:46] debian/docs is the file where you specify which files of the source should go into /usr/share/doc/<...> [13:46] dholbach, how can one help with watchfiles? [13:47] the Changelog is different and should be installed by using dh_installchangelogs [13:47] effie_jayx: are you referring to http://qa.ubuntuwire.com/uehs/no_watch.php ? [13:48] dholbach, yes... where could I find usefull info on watchfiles and how can I help? [13:48] ah right [13:48] https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch is a good tutorial on writing watch files [13:49] the manpage of uscan(1) has more information too [13:49] does everybody know what a watch file is? [13:50] dholbach, trying to learn about them [13:50] debian/watch specifies where to get new upstream releases of the software you're packaging [13:50] uscan can be found in what package? [13:50] effie_jayx: devscripts [13:50] this is important as with uscan you can "automatically update a package" it does not fix all issues with it, but it simplifies the task a lot [13:51] also it's easy for others to see if your package it up to date [13:51] we could even automate the process and have a list of packages in the archive that are not up to date [13:51] ok... persia had another item on the list:; [13:51] - Patching upstream makefile to install extra stuff [13:52] where he notes: Use dh_install instead [13:52] does that make sense? [13:52] * rzr hides :) [13:53] ok... any questions? [13:53] dholbach: isn't it better to let upstream include the extra stuff [13:53] TuxCrafte1: sure, sometimes that works [13:54] in some cases the upstream maintainer and you might disagree [13:54] or you have user contributions like a new icons, etc [13:54] but in general you're right: the more work that goes upstream, the better [13:54] dholbach: is't it better then to create two packages one that is mainstream and one with ubuntu enhancements [13:55] if you add a package-extras package that just contains the additions that's probably fine [13:55] if you re-package everything the archive admins might be a bit unhappy :) [13:55] for reasons like: having to apply security fixes to two packages instead of one, disk space, etc etc :) [13:55] yea but in the spirit of bug tracking it is a lot better [13:56] let's just say that "getting the stuff upstream" is the best solution :) [13:56] *** got a question about motu/packaging training [13:56] TuxCrafte1: fire away [13:57] are there video tutorials for moto packaging, because there is o much info about this topic that when you start reading you dont now how much time it takes before you can build a good package [13:57] http://wiki.ubuntu.com/PackagingGuide [13:57] and I want to start packaging but the guide is so big [13:57] has a couple of "recipes" that are tutorials [13:58] which should be easy to follow [13:58] I don't know of any videos yet [13:58] ok... we're at the end of our session [13:59] dholbach: i see the guide is starting to get organized, nice to see this [13:59] I hope to see you all next week again [13:59] TuxCrafte1: thanks for the flowers - I put a lot of work into it :) [13:59] thanks for all the info [13:59] see ya thx dholbach it's always apreciated [13:59] thanks a lot for attending [13:59] see you all in #ubuntu-motu :-) [13:59] bye and thanks daniel [13:59] Thank you dholbach! :) [13:59] http://wiki.ubuntu.com/MOTU/GettingStarted (if you haven't read it yet) [14:00] dholbach: what do you think about joining the java team and make a special q&a on this topic ? [14:00] rzr: I'm afraid I'm not the right person to join the team [14:00] rzr: but I'll try to organise a session on the topic [14:00] I'll keep you updated [14:00] * dholbach is out to walk the dog - see you guys around! :) [14:01] nice [14:01] later === bigon is now known as bigon` === bigon` is now known as bigon === \sh_away is now known as \sh === Pricey is now known as PriceChild === 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 === bigon is now known as bigon` === bigon` is now known as bigon [20:05] hi everyone, sorry for being late [20:05] hi sistpoty [20:06] hi warp10 [20:06] so who's around for part 2 of the library packaging session? [20:06] hello sistpoty [20:06] hi albert23 [20:07] first off, there is an excellent guide about debian library packaging. We'll use this one as a reference for this session: [20:07] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html [20:09] thanks sistpoty for the wakeup call :) [20:09] hi nixternal :) [20:09] well howdy [20:09] ok, in part 1, we hopefully learned all the basic stuff about shared objects. [20:10] You wouldn't have a link to the log for that would you? [20:10] I was just gonna ask, I have a lib I gotta package up :) [20:10] http://irclogs.ubuntu.com/2008/01/17/%23ubuntu-classroom.html [20:10] ScottK: sorry.. no idea if this is publically logged somewhere [20:10] thanks albert23 [20:11] albert23: Thanks [20:11] now in part 2, we'll be packaging a library by example, and will discuss a few of the caveats [20:12] since I'm lazy, let's take libmyhello again from part 1 [20:12] http://www.potyra.de/library_packaging/libmyhello-1.0.1.tar.gz [20:13] everyone got it? [20:13] y [20:13] y [20:13] yep [20:13] ok, let's start with debianization... unpack it, rename the tarball so that we've got a valid .orig.tar.gz [20:14] let's take a look, we'll always need a few files in there, let's start with debian/copyright [20:16] put in the usual stuff there (this is not really important for the technical bits of library packaging) [20:17] what else do we need... I guess we'll be using debhelper, so let's create a compat in debian/ [20:17] everyone got it so far? [20:17] y [20:17] y [20:18] y [20:18] ok, now let's start with the interesting bits [20:18] the control-file [20:19] First off comes the usual stuff (I'll pastebin this) [20:19] hm... pastebin is kinda slow today :( [20:20] ok, I'll paste it right here... pastebin doesn't like me *g* [20:21] Source: libmyhello [20:21] Section: libdevel [20:21] Priority: optional [20:21] Maintainer: Your Name [20:21] Build-Depends: debhelper (>> 5.0.0) [20:21] Standards-Version: 3.7.2.0 [20:22] for a library, we'll always end up with two packages [20:22] two binary packages even [20:22] one package contains the shared object(s) [20:23] and another one, the -dev package will contain everything you need to develop applications with the shared object [20:24] i.e. header-files, eventually a statically linked library, eventually pkconfig files (which specify what to pass to the compiler/linker to link against this library) [20:25] so let's create an entry for the -dev package [20:25] Package: libmyhello-dev [20:25] Architecture: any [20:25] Description: myhello library headers [20:25] This package contains the development headers [20:25] for libmyhello. [20:26] * ScottK notes sistpoty needs to update to the current standards version... [20:26] ScottK: hehe, I'm not up to date [20:27] the package containing the shared object will need to be named in a special way: [20:28] it must be related to the soname. [20:28] the library packaging guide I mentioned contains the rules how it should be named [20:29] chapter 5, section 3 [20:29] remember the soname of libmyhello yet? [20:30] anyone? [20:30] mmm... libmyhello.so.1, maybe? [20:30] warp10: exactly [20:31] if you wouldn't have remembered, you could of course always use objdump -p to find out [20:33] so in this case, the name of the library would be libmyhello1 [20:33] if you've got a library, that contains more than one shared object [20:33] you'll need to create a binary package for each of these [20:33] let's add an entry for the binary package [20:34] Package: libmyhello1 [20:34] Architecture: any [20:34] Depends: ${shlibs:Depends} [20:34] Description: myhello library [20:34] This package contains the hello library. [20:35] ok. anyone got a clue, why the name of this binary must be related to the SONAME? [20:35] this binary package... [20:36] anoyne` [20:36] +? [20:36] we want to be able to install multiple versions of the library, when ABI changes [20:36] albert23: excellent [20:37] so does anyone have an idea why this could be needed? [20:38] sistpoty: maybe different packages may need different versions of the library? [20:38] warp10: this would be one argument, but not the main one. [20:38] let's just consider that a very essential library (maybe libc) will get updated [20:39] currently, I've got libc6 installed, and I guess almost all packages I've got installed will depend on libc6 [20:39] suddenly, a new libc7 appears [20:40] if it couldn't be installed side-by-side to libc6, that would mean that I had to remove *all* installed programs [20:40] or that all programs would immediately break if libc6 were removed by force [20:40] that's pretty bad, hm? [20:41] (I tried this once when I didn't have a clue... wasn't so funny back then *g*) [20:41] :) [20:41] any questions so far? [20:42] I have one [20:42] Why the -dev package doesn't need any Depends: field? [20:42] warp10: excellent question... it needs one :) [20:43] so, as I wrote earlier, the -dev package is what you install if you want to build programs using this library [20:44] so we need to make it depend at least on the library package [20:44] let's add the depends line there [20:45] the header files in question should always match what's in the shared object [20:45] hence we'll need to restrict the version for this dependency [20:46] Depends: libmyhello1 (= ${binary:Version}) [20:47] however often you'll need additional libraries to compile a program with a specific library [20:47] so you'll need to add the corresponding -dev packages there as well. [20:48] a good indication should give you the NEEDED entries of the shared object [20:49] so you'll just need to find the corresponding -dev package that contains these shared objects [20:50] so, what do we need here? [20:51] NEEDED libc.so.6 [20:51] great. [20:52] so let's find out in which package this is (we'll see a better method later) [20:52] just use dpkg -S libc.so.6 [20:53] hooray, it's libc6 :)... so we'll want libc6-dev [20:54] (libc6-dev is often ommitted, since build-essential already depends on it. however it's not wrong to add it) [20:55] as you might have noticed, in the case of libc6, the -dev package is not named like the source package [20:55] but instead it is named like the binary package + -dev [20:56] this is useful, if you want to have more than just one version of the library in the archive [20:56] (e.g. because one application needs the old one, and won't build with the new version) [20:56] then you'll need to be able to select which -dev package you want [20:57] There's a very recent thread on adding libc6 on debian-devel that came down pretty strongly in favor of adding it. [20:57] if you do this, you should have the -dev package(s) of the different versoin Provide and Conflict to libmyhello-dev package [20:58] ScottK: ah, haven't read that one yet [20:58] (or maybe I have but forgot *g*) [20:59] ok, does everyone have the control file so far? [20:59] y [20:59] y [21:00] hehe, mine is still missing the depends line *g* [21:01] ok [21:01] what else do we need... a changelog file. just create one with dch [21:03]