=== bigon is now known as bigon` === neversfelde_ is now known as neversfelde [12:45] MOTU Q&A Session in 15 minutes! [12:46] dholbach: I had a question about debian/watch files for tracking Launchpad project downloads, but I found our very own hero jamesh had answered such a question on LP - question 21146 :) [12:46] dholbach: how long will it takes ? [12:46] seems like it might be useful for others [12:47] rzr: roughly an hour [12:47] This is the "How Not to Package" session, right? [12:47] Ng: rock and roll - it might make sense to add that to the debian/watch recipe [12:47] ok then i'll stay here then :) [12:48] http://wiki.ubuntu.com/PackagingGuide/Recipes [12:48] Do we want to have a gobby for listing deprecated methods? [12:49] I planned to just put them in my editor and go from there [12:49] dholbach: oki doki [12:49] but if somebody wants to set up a gobby session, that's fine with me [12:49] * dholbach hugs Ng [12:49] dholbach: OK. Makes sense. I'll feed you a list in about 5 minutes then, and let you lead :) [12:49] nice [12:55] It looks to me like a .deb can be of multiple compression formats, how do you know which one it is? [12:56] db-keen: man file ? [12:57] isn't .deb just an ar archive with 3 files in it, 2 being tar.gz's? [12:58] Not necessarily tar.*gz*. [12:58] You can always use "ar t" to check, of course. [12:58] it's not tar either, is it? [12:58] .deb is a "ar" file, containing several compressed files, where the compression format can be any of a number of things. [12:59] Each file when decompressed is a tarball, containing some portion of the package. [12:59] that one always gets me, tar vs ar [12:59] hello everybody - welcome to another MOTU Q&A session! Let's start with our usual round of introductions! [12:59] Inside the .deb? Three files, debian-binary (a plain text file), control.tar.gz and data.tar.gz. [13:00] * dholbach is Daniel Holbach, member of the MOTU team and trying to make becoming a MOTU as enjoyable and straight-forward as possible - if you have any ideas, let me know :) [13:00] The data.tar.gz can use other compression formats. [13:00] * persia is Emmet Hikory, member of MOTU, and interested in making sure those who aren't MOTU have as little difficulty contributing as possible [13:00] db-keen: you can use something like DEB_DH_BUILDDEB_ARGS := -- -Zbzip2 in debian/rules to use bz2 compression [13:00] it's time children ! [13:01] who else do we have here? [13:01] * rulus is Roel Huybrechts, and is just listening to learn more about Ubuntu packaging and the MOTU team [13:01] ahh, pedro_! :) [13:01] welcome rulus [13:01] thanks :) [13:01] heey dholbach ;-) [13:01] * Amaranth is Travis Watkins, driveby MOTU guy [13:02] pedro_ is Pedro Villavicencio - the GNOME Desktop Bug King [13:02] All hail pedro_ [13:02] :-) [13:02] * minghua is Ming Hua, MOTU member, another drive-by. [13:02] I'm happy we have a lot of people here today (even if they didn't introduce themselves yet..... :-)) [13:03] * rzr is Philippe Coval who packaged a few apps and is here because he's got time for [13:03] * Kmos is Marco Rodrigues, a MOTU helpful. [13:03] :) [13:03] * amarillion is Martijn van Iersel, trying to learn as much about packaging as he can [13:03] welcome Kmos, rzr and amarillion [13:03] haha [13:03] great to have you all here [13:03] * pedro_ hugs dholbach [13:03] dholbach: always ready :) [13:03] so nenolod proposed the following for today's Q&A Session: " dholbach, one suggestion for your MOTU Q&A sessions would be to go through how to NOT make a debian package" [13:04] Make an rpm? :P [13:04] hi dholbach: Happy New Year [13:04] so what I'd like us to do in the first five minutes of the session is: collect crackful ideas how to make the most broken, awful and horrific package possible [13:04] thanks a lot txwikinger2 [13:04] and the same to you [13:04] dholbach: run autofoo in the build [13:04] autoconversions from ebuild, rpm, etc. [13:04] automake, autoconf, etc [13:04] after that we should take the time to find out how to NOT do that :) [13:05] making a binary package directly... [13:05] or explain apt-build ? [13:05] ok... go wild! I'm taking notes [13:05] what else? [13:05] making a package that has a python rules file ;) [13:05] recursive patching? [13:05] are there pple from gentoo project around ? It would be nice to have a gentoo collaboration group if none exists already [13:06] mixing patches in diff.gz and debian/patches [13:06] what else? what makes it horrible for users? [13:06] what makes it horrible for other developers? [13:06] what makes it horrible for archive admins? [13:06] persia: I wouldn't say it's a terrible thing, as long as the patches are on different areas. [13:06] deleting all the settings, and reconstructing from scratch in the maintainer scripts [13:06] unneeded dependencies [13:06] good ideas... keep them coming :) [13:07] minghua: I've hit conflicts before with it, and unwinding was unpleasant. [13:07] making a package that build-deps on all of gnome and all of kde (oops, i did that) [13:07] :P [13:07] persia: Right, sucks for mergers, I suppose. [13:07] no copyright information - dodgy stuff "from the net" [13:07] download things from different places inside debian/rules [13:08] no docs at all, no manpages [13:08] txwikinger2: well, no, that has good uses [13:08] manpages? who needs those? :) [13:08] code is self-documenting :D [13:08] checkinstall, dbs, yada, debmake [13:08] * Amaranth stabs yada a million times [13:08] nothing excepts stuffs in /usr/share/doc ... this happends packaging libraries the wrong way :) [13:09] Access the internet at build-time [13:09] fail install script because db does not exist [13:09] interactive builds [13:09] is using dpkg -b to build a package a good idea/bad idea? [13:09] interactive installs [13:09] compwiz18: That falls under "making a binary package directly..." [13:09] an interactive build took out the buildds recently, didn't it? [13:09] lots of useless cruft in the package [13:10] missing .desktop file for a graphical application [13:10] icons in wrong places [13:10] missing files in the package [13:10] rulus: There were 237n of those last I checked, so maybe less critical (but yes). [13:10] installing to /opt [13:10] What is yada and why is it so bad? (Or is this not the place to ask that?) [13:11] amarillion: Don't ask. Don't google. Don't even look. You will be happier. [13:11] software without active upstream [13:11] inactive maintainer, no bug triage [13:11] * persia likes software without active upstream, if it is stable and well written. [13:11] dholbach, but what if the software is finished? [13:11] * rzr reads http://yada.alioth.debian.org [13:11] (software is never finished?) [13:11] * Kmos dies [13:12] why does the yada webpage talk about making lobster? [13:12] ok... shall we close our selection for this time around? [13:12] rulus: now, you need to be purified.. [13:12] dholbach: move on =) [13:12] dholbach: run autofoo in the build [13:12] automake, autoconf, etc [13:12] was the first ones we had [13:13] ok, should I explain? [13:13] Why can this be problematic? [13:13] Amaranth: great, go ahead [13:13] because of different versions of autofoo.... [13:13] Running automake or autoconf in the buildd can cause build failures due to different versions, a different environment, etc [13:13] ? [13:13] err, in the build [13:14] * txwikinger2 currentlu has this problem... work on ubuntu but not on debian [13:14] From my experience no two computers will ever produce the same output from running autoconf [13:14] are there cases in which it might be necessary to run any of the autotools again and how would you deal with those? === bigon` is now known as bigon [13:15] If you need to update the configure script or Makefiles to update dependencies and such you should update their configure.ac and Makefile.am counterparts then run automake or autoconf locally and put the diff between the new output and the original in a patch [13:16] does this make sense to everybody? do we have any questions about that? [13:16] I disagree. I think it's very reasonable to run autotools when build if you do it right. [13:16] Amaranth: remove generated files on make clean will help ? is it mandatory ? [13:17] well... do you need to run autoconf if you change the architecture? [13:17] one example that come to my mind are Launchpad Integration in the GNOME packages (report bug to launchpad, etc) [13:17] Isn't the problem if version-related files are part of the package? [13:17] To do it right, you need to build-depend proper version of autotools packages, and build-conflict troublesome ones. [13:17] speaking of the devil, seb128 the king of launchpad-integration and auto* patches is here :-) [13:18] We do it in compiz to add a dependency on X cursor stuff for cursor theme support [13:18] add the check to configure.ac, add the linker stuff to the Makefile.am, run autoconf and automake, diff the new versions to the old ones, dump the output into a patch, now we have our updated build system and the builder doesn't have to worry about it [13:19] minghua: Of course it can be done but it's basically always better if you don't [13:19] I think the best way to avoid this is to add an option for whatever changes you need in the configure.ac/Makefile.am files and get it upstream :) [13:19] Of course, but sometimes such things aren't possible :) [13:20] minghua and Amaranth both have points and it can be problematic [13:20] but it's probably not the first problem new contributors will run into :) [13:20] persia mentioned: autoconversions from ebuild, rpm, etc. [13:21] we have this every now and then, that dodgy ".deb files" turn up on blogs, the forums and other places that were produced that way [13:21] which is why we only review source packages and not .deb files that went through some mystic conversion process [13:21] making a binary package directly... [13:21] ^ means the same [13:21] alien is a great tool, and useful for an admin, but the resulting packages rarely have the right dependencies, and may be missing other useful bits. Best to create the binary packages from a .dsc based source, rather than srpm or ebuild (which are both source formats). [13:22] *nod* [13:22] thanks persia [13:22] making a package that has a python rules file ;) [13:22] Stick with the standard stuff, basically [13:23] it's best to try to keep the debian/rules file as simple and understandable as possible [13:23] Just because you think it's cool to make the package in a 'special' way doesn't mean the next person to touch it will agree with you [13:23] * txwikinger2 giggles [13:23] Makefile and shell elements are pretty common [13:23] and if python break you can not build anything .. [13:23] No. Makefile and shell elements only look similar [13:24] persia: what do you mean? [13:24] debian/rules is a Makefile, if you disagree with this you're probably a somewhat advanced packager :) [13:24] There is a proposal to mandate debian/rules as a Makefile in Debian Policy, IIRC. [13:25] dholbach: Trying anything tricky in a shell in a Makefile is likely to cause issues. Similarly, shell scripts handle recursion and parallel execution poorly. [13:25] I don't think it is good to conflate them, although much of the syntax is similar. [13:25] Anything run outside $(shell $(COMMAND)) is unlikely to have the expected behaviour. [13:26] right [13:26] recursive patching? [13:27] You asked me to be wild [13:27] To write a patch that patches a patch :D [13:27] This is a horrible thing to do [13:28] Just apply the first patch, make your changes, make a patch from that, and make sure the first patch gets applied before this new one [13:28] well exactly [13:28] patches can depend on others, that's why a lot of packages use enumeration for patches in debian/patches [13:28] 01change-foo [13:28] 02change-foo-more [13:29] Even so, it makes unwinding and feeding upstream difficult. Also it's a common mistake from using foo-edit-patch blindly. [13:29] Right, ideally you shouldn't have any patches at all, they should all go upstream as soon as possible [13:29] agreed :) [13:29] persia and minghua had some more ideas about patching: [13:29] mixing patches in diff.gz and debian/patches [13:29] persia: I wouldn't say it's a terrible thing, as long as the patches are on different areas. [13:29] minghua: I've hit conflicts before with it, and unwinding was unpleasant. [13:29] persia: Right, sucks for mergers, I suppose. [13:29] Sometimes you need a local patch (see e.g. the man-db package). [13:29] do you also use enumeration with quilt patch system ? [13:30] rzr: You don't have to (it keeps a list of the order) but you should anyway to make it obvious what goes where [13:30] yea the series file.. [13:30] we use quilt in compiz but our patches are still 01foo, 02foo, etc [13:30] (btw, i think we have like 20 patches :/) [13:31] Does any patch system rely on the enumeration for the order? Dpatch has a 00list file to record the order, too. [13:31] Another thing to not do: Learn best practices from the compiz patch [13:31] minghua: cdbs [13:31] err, from the compiz package [13:32] simple-patchsys he means, cdbs can use any dpatch, simple-patchsys or quilt depending of what is listed in the rules [13:32] well, yeah, but is simple-patchsys used anywhere else? [13:32] should be specific though [13:33] door bell - sorry [13:33] brb [13:33] It's a bomb! [13:33] It's M$ [13:33] dunno, but you can use cdbs without using simple-patchsys so saying cdbs is not right [13:33] I believe simple-patchsys is only available with CDBS [13:33] Right, I just forgot the name :) [13:34] OK. Next up: unneeded dependencies [13:34] This tends to happen when first making a package or when updating it to a new version [13:34] Make sure the dependencies listed for the package are actually needed, otherwise people have to install things they don't need [13:35] What is a good way to check? [13:35] hmm, i don't really know [13:35] Usually when a new release is made they mention new and dropped dependencies [13:36] For compiled packages, you can check to make sure the libraries are compiled in by looking at the -l calls in the build log (and there's a better way with objdump, with which I'm insufficiently familiar). [13:36] For scripting languages, you can look for #include lines (or the equivalent) in the source files. [13:36] Anyone have any other suggestions? [13:36] i check ldd for binaries [13:37] nm too ? [13:37] ldd and nm are good. [13:37] Next up: download things from different places inside debian/rules [13:37] of course nm doesn't work on stripped binaries [13:38] Amaranth: Should still list symbols for shared library access, no? [13:38] what is that thing about dependencies? [13:38] doesn't look like it, running it on /usr/bin/compiz.real gives no output [13:39] seb128: Ways to check to make sure the package really depends on things listed in Depends: [13:39] If you use ${shlibs:Depends}, there shouldn't be anything missing (unneeded, perhaps) library in the dependency, should there? [13:39] We're talking about listing things that aren't needed [13:39] Amaranth: readelf -a is verbose [13:39] well, libraries are usually automatically listed [13:40] Then ldd won't work either. [13:40] why do you want to use ldd? [13:40] dh_shlibdeps should give warnings these days anyway. [13:40] right [13:40] maybe the simplest way is just removing them one by one and trying with pbuilder [13:40] and that's not a packaging question [13:40] this could be automated [13:41] Amaranth: about foo.real <= is the .real suffix mentioned in some policy somewhere ? [13:41] rzr: For compiz we have a wrapper script to make sure it starts correctly so the actual binary gets moved to compiz.real [13:42] Not sure if there is some policy on this [13:42] Amaranth: I guessed that , but why call it .real or .bin or .elf ? [13:42] nothing else on my system has a .real version so i dunno [13:42] i know firefox has firefox-bin [13:43] I was wondering about that while building a native version of tuxguitar [13:43] OK. So, let's look at the next one. download things from different places inside debian/rules [13:43] ... [13:44] well.. what happens if the download place disappears [13:44] persia: you can merge this one with access to the internet at build time [13:45] txwikinger2: That's one part. The other being that the buildds don't have internet access :) [13:45] :) [13:45] rzr: Doing that. Thanks. [13:45] txwikinger: or be spoofed ? [13:45] txwikinger2: Any suggestions on how to work around that at packaging time? [13:45] I think all necessary stuff should be part of the orig tarball [13:45] txwikinger2: but in case they can not be distribuated ... [13:46] That's install time though, not build time [13:46] like flashplugin-nonfree [13:46] Also, sometimes there are out-of-tree patches maintained somewhere else that are interesting to include. [13:46] I dont see any alternative than a wrapper script like swf etc [13:46] If you need to install something at build time that is not redistributable then you should just not package such things [13:46] if buildds can't get it, it must be part of the package [13:47] Downloading things at install time can be alright, although this is (i think) really only for flash [13:47] Right. So you make sure to include it in the package. In orig.tar.gz if you must, or in diff.gz if upstream ships an otherwise clean orig.tar.gz. [13:47] do we have some package like that already ? why for ? [13:48] rzr: Like which? [13:48] which need to dl stuff at compilation time [13:49] Amaranth: Another existing example is the MS web core fonts. [13:49] ah, right [13:49] binaries only tough [13:49] rzr: Some example packages are those that use python ezinstall to download dependencies at build time. CPAN, gems, etc. are also sometimes issues. [13:49] rzr the germinate stuff cannot be automated because of it [13:49] oh yes I forgot them [13:49] rzr: What package can you think of that would need to download something from the internet at build time? [13:50] gems and such should simply be packages so you can build-dep on them properly [13:50] those people listening in today? were there any items discussed that you had problems understanding? [13:51] ok... seems to be all clear then :) [13:51] Amaranth: Yes, but it's an unfortunately common mistake, even in Debian sometimes (given the frequency with which arch:all packages are autobuilt) [13:51] dholbach: beside your question it's ok for me :) [13:51] :-) [13:51] no docs at all, no manpages [13:51] manpages? who needs those? :) [13:51] code is self-documenting :D [13:52] Alright then [13:52] I just thought [13:52] Even desktop applications should at least have a manpage explaining what they are and what (if any) command line arguments they take [13:52] it should be easy to parse foo --help and generate a template man page isnt it ? [13:52] For example, the alacarte manpage just says what alacarte is [13:53] and it's horrible, so don't ever look at it :) [13:53] Should manpages be translated? [13:53] it's not only about manpages... sometimes the upstream tarball ships documentation that is not installed into the package [13:53] the same goes for example code [13:53] can man page be too documented ? [13:54] a man page is documentation [13:54] rulus: That is nice, but at least including English as a base is best. See http://qa.ubuntuwire.com/lintian/reports/Tbinary-without-english-manpage.html for some example packages that missed that, and an explanantion why it isn't ideal. [13:54] rzr: I don't think it happens very often :) [13:54] persia: thanks :) [13:55] nothing excepts stuffs in /usr/share/doc ... this happends packaging libraries the wrong way :) [13:55] good point [13:55] what you can do is run dh_install --list-missing in the directory of the local build [13:55] wow, i think i should be taking notes :) [13:55] it will list all the files that are not installed into a package (especially in cases like rzr pointed out: where you have more than one binary package) [13:56] i forgot about dh_install --list-missing [13:56] Amaranth: Need help on alacarte man page? [13:56] it's a great tool [13:56] minghua: I don't think I really need anything else but if you want to spruce it up a bit go for it [13:56] you can also run debc in the local build directory to find out which files are installed in which package [13:56] ok, now i'm taking notes, i do all this junk manually :) [13:57] fail install script because db does not exist [13:57] Amaranth: I'll probably give it a try. Will let you know either way. [13:57] txwikinger2: can you say a bit more about this? [13:57] well.. there are often webapps that work with a db [13:58] when the db does not exist, they just fail and leave a faild-package in apt [13:58] right, they usually deal with those DBs in the postinst/prerm scripts, right? [13:58] yes [13:59] broken postinst/prerm scripts are a big problem for exactly the reason that txwikinger2 points out [13:59] if you're not careful enough, they will break the installation of your users [13:59] oh man, prerm is the worst [13:59] upgrade processes etc [13:59] well, and postrm [13:59] ask mvo about it, he has a lot to say about the topic :) [14:00] ok... it's time to close the session - thanks everybody for joining in [14:00] it sucks not being able to remove a package and getting your dpkg stuck an such a state [14:00] thanks persia for taking over [14:00] Being too agressive about update-alternatives and update-rc in maintainer scripts is frustrating as well. [14:00] I had a great time and I hope you did too [14:00] Has good, thanks to dholbach and persia for running this [14:00] Yeah, thanks dholbach and persia. [14:00] err, Was [14:00] \o/ dholbach [14:00] * Amaranth needs sleep [14:01] * dholbach hugs y'all [14:01] Amaranth: There are logs, so you can keep them if you want :) [14:01] yea thx all , that was my 1st course, i'll manage to be there on next one .. [14:01] see you all next week :) [14:02] rzr: Also feel free to ask questions in #ubuntu-motu at any time. There's less guarantee of an answer, but people may have time to get more in depth (I've seen 2-hour sessions spontaneously erupt on a single interesting issue). [14:02] Those are fun [14:02] I learned most of what I know from watching such things :) [14:03] try manpages too :) [14:03] man dh_* is good too [14:10] !topic + https://wiki.ubuntu.com/ClassroomTranscripts ? [14:25] Hello! === alleeHol is now known as allee === bigon is now known as bigon` === bigon` is now known as bigon