/srv/irclogs.ubuntu.com/2008/01/11/#ubuntu-classroom.txt

=== bigon is now known as bigon`
=== neversfelde_ is now known as neversfelde
dholbachMOTU Q&A Session in 15 minutes!12:45
Ngdholbach: 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
rzrdholbach: how long will it takes ?12:46
Ngseems like it might be useful for others12:46
dholbachrzr: roughly an hour12:47
persiaThis is the "How Not to Package" session, right?12:47
dholbachNg: rock and roll - it might make sense to add that to the debian/watch recipe12:47
rzrok then i'll stay here then :)12:47
dholbachhttp://wiki.ubuntu.com/PackagingGuide/Recipes12:48
persiaDo we want to have a gobby for listing deprecated methods?12:48
dholbachI planned to just put them in my editor and go from there12:49
Ngdholbach: oki doki12:49
dholbachbut if somebody wants to set up a gobby session, that's fine with me12:49
* dholbach hugs Ng12:49
persiadholbach: OK.  Makes sense.  I'll feed you a list in about 5 minutes then, and let you lead :)12:49
dholbachnice12:49
db-keenIt looks to me like a .deb can be of multiple compression formats, how do you know which one it is?12:55
rzrdb-keen: man file  ?12:56
stdinisn't .deb just an ar archive with 3 files in it, 2 being tar.gz's?12:57
minghuaNot necessarily tar.*gz*.12:58
minghuaYou can always use "ar t" to check, of course.12:58
Amaranthit's not tar either, is it?12:58
persia.deb is a "ar" file, containing several compressed files, where the compression format can be any of a number of things.12:58
persiaEach file when decompressed is a tarball, containing some portion of the package.12:59
Amaranththat one always gets me, tar vs ar12:59
dholbachhello everybody - welcome to another MOTU Q&A session! Let's start with our usual round of introductions!12:59
minghuaInside the .deb?  Three files, debian-binary (a plain text file), control.tar.gz and data.tar.gz.12:59
* 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
minghuaThe 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 possible13:00
dholbachdb-keen: you can use something like         DEB_DH_BUILDDEB_ARGS := -- -Zbzip2               in debian/rules to use bz2 compression13:00
rzrit's time children !13:00
dholbachwho else do we have here?13:01
* rulus is Roel Huybrechts, and is just listening to learn more about Ubuntu packaging and the MOTU team13:01
dholbachahh, pedro_! :)13:01
dholbachwelcome rulus13:01
rulusthanks :)13:01
pedro_heey dholbach ;-)13:01
* Amaranth is Travis Watkins, driveby MOTU guy13:01
dholbachpedro_ is Pedro Villavicencio - the GNOME Desktop Bug King13:02
AmaranthAll hail pedro_13:02
dholbach:-)13:02
* minghua is Ming Hua, MOTU member, another drive-by.13:02
dholbachI'm happy we have a lot of people here today (even if they didn't introduce themselves yet..... :-))13:02
* 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
Kmos:)13:03
* amarillion is Martijn van Iersel, trying to learn as much about packaging as he can13:03
dholbachwelcome Kmos, rzr and amarillion13:03
pedro_haha13:03
dholbachgreat to have you all here13:03
* pedro_ hugs dholbach13:03
Kmosdholbach: always ready :)13:03
dholbachso nenolod proposed the following for today's Q&A Session: "<nenolod> dholbach, one suggestion for your MOTU Q&A sessions would be to go through how to NOT make a debian package"13:03
AmaranthMake an rpm? :P13:04
txwikinger2hi dholbach: Happy New Year13:04
dholbachso 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 possible13:04
dholbachthanks a lot txwikinger213:04
dholbachand the same to you13:04
Amaranthdholbach: run autofoo in the build13:04
persiaautoconversions from ebuild, rpm, etc.13:04
Amaranthautomake, autoconf, etc13:04
dholbachafter that we should take the time to find out how to NOT do that :)13:04
amarillionmaking a binary package directly...13:05
rzror explain apt-build ?13:05
dholbachok... go wild! I'm taking notes13:05
dholbachwhat else?13:05
Amaranthmaking a package that has a python rules file ;)13:05
txwikinger2recursive patching?13:05
rzrare there pple from gentoo project around ? It would be nice to have a gentoo collaboration group if none exists already13:05
persiamixing patches in diff.gz and debian/patches13:06
dholbachwhat else? what makes it horrible for users?13:06
dholbachwhat makes it horrible for other developers?13:06
dholbachwhat makes it horrible for archive admins?13:06
minghuapersia: I wouldn't say it's a terrible thing, as long as the patches are on different areas.13:06
persiadeleting all the settings, and reconstructing from scratch in the maintainer scripts13:06
Amaranthunneeded dependencies13:06
dholbachgood ideas... keep them coming :)13:06
persiaminghua: I've hit conflicts before with it, and unwinding was unpleasant.13:07
Amaranthmaking a package that build-deps on all of gnome and all of kde (oops, i did that)13:07
Amaranth:P13:07
minghuapersia: Right, sucks for mergers, I suppose.13:07
dholbachno copyright information - dodgy stuff "from the net"13:07
txwikinger2download things from different places inside debian/rules13:07
dholbachno docs at all, no manpages13:08
Amaranthtxwikinger2: well, no, that has good uses13:08
Amaranthmanpages? who needs those? :)13:08
txwikinger2code is self-documenting :D13:08
persiacheckinstall, dbs, yada, debmake13:08
* Amaranth stabs yada a million times13:08
rzrnothing excepts stuffs in /usr/share/doc ... this happends packaging libraries the wrong way :)13:08
persiaAccess the internet at build-time13:09
txwikinger2fail install script because db does not exist13:09
Amaranthinteractive builds13:09
compwiz18is using dpkg -b to build a package a good idea/bad idea?13:09
persiainteractive installs13:09
persiacompwiz18: That falls under "making a binary package directly..."13:09
Amaranthan interactive build took out the buildds recently, didn't it?13:09
dholbachlots of useless cruft in the package13:09
rulusmissing .desktop file for a graphical application13:10
txwikinger2icons in wrong places13:10
dholbachmissing files in the package13:10
persiarulus: There were 237n of those last I checked, so maybe less critical (but yes).13:10
Amaranthinstalling to /opt13:10
amarillionWhat is yada and why is it so bad? (Or is this not the place to ask that?)13:10
persiaamarillion: Don't ask.  Don't google.  Don't even look.  You will be happier.13:11
dholbachsoftware without active upstream13:11
dholbachinactive maintainer, no bug triage13:11
* persia likes software without active upstream, if it is stable and well written.13:11
amarilliondholbach, but what if the software is finished?13:11
* rzr reads http://yada.alioth.debian.org13:11
rulus(software is never finished?)13:11
* Kmos dies13:11
Amaranthwhy does the yada webpage talk about making lobster?13:12
dholbachok... shall we close our selection for this time around?13:12
Kmosrulus: now, you need to be purified..13:12
Kmosdholbach: move on =)13:12
dholbach<Amaranth> dholbach: run autofoo in the build13:12
dholbach<Amaranth> automake, autoconf, etc13:12
dholbachwas the first ones we had13:12
Amaranthok, should I explain?13:13
dholbachWhy can this be problematic?13:13
dholbachAmaranth: great, go ahead13:13
txwikinger2because of different versions of autofoo....13:13
AmaranthRunning automake or autoconf in the buildd can cause build failures due to different versions, a different environment, etc13:13
txwikinger2?13:13
Amarantherr, in the build13:13
* txwikinger2 currentlu has this problem... work on ubuntu but not on debian13:14
AmaranthFrom my experience no two computers will ever produce the same output from running autoconf13:14
dholbachare there cases in which it might be necessary to run any of the autotools again and how would you deal with those?13:14
=== bigon` is now known as bigon
AmaranthIf 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 patch13:15
dholbachdoes this make sense to everybody? do we have any questions about that?13:16
minghuaI disagree.  I think it's very reasonable to run autotools when build if you do it right.13:16
rzrAmaranth: remove generated files on make clean will help ? is it mandatory ?13:16
txwikinger2well... do you need to run autoconf if you change the architecture?13:17
dholbachone example that come to my mind are Launchpad Integration in the GNOME packages (report bug to launchpad, etc)13:17
txwikinger2Isn't the problem if version-related files are part of the package?13:17
minghuaTo do it right, you need to build-depend proper version of autotools packages, and build-conflict troublesome ones.13:17
dholbachspeaking of the devil, seb128 the king of launchpad-integration and auto* patches is here :-)13:17
AmaranthWe do it in compiz to add a dependency on X cursor stuff for cursor theme support13:18
Amaranthadd 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 it13:18
Amaranthminghua: Of course it can be done but it's basically always better if you don't13:19
dholbachI 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
AmaranthOf course, but sometimes such things aren't possible :)13:19
dholbachminghua and Amaranth both have points and it can be problematic13:20
dholbachbut it's probably not the first problem new contributors will run into :)13:20
dholbachpersia mentioned: <persia> autoconversions from ebuild, rpm, etc.13:20
dholbachwe have this every now and then, that dodgy ".deb files" turn up on blogs, the forums and other places that were produced that way13:21
dholbachwhich is why we only review source packages and not .deb files that went through some mystic conversion process13:21
dholbach<amarillion> making a binary package directly...13:21
dholbach^ means the same13:21
persiaalien 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:21
dholbach*nod*13:22
dholbachthanks persia13:22
dholbach<Amaranth> making a package that has a python rules file ;)13:22
AmaranthStick with the standard stuff, basically13:22
dholbachit's best to try to keep the debian/rules file as simple and understandable as possible13:23
AmaranthJust 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 you13:23
* txwikinger2 giggles13:23
dholbachMakefile and shell elements are pretty common13:23
rzrand if python break you can not build anything ..13:23
persiaNo.  Makefile and shell elements only look similar13:23
dholbachpersia: what do you mean?13:24
Amaranthdebian/rules is a Makefile, if you disagree with this you're probably a somewhat advanced packager :)13:24
minghuaThere is a proposal to mandate debian/rules as a Makefile in Debian Policy, IIRC.13:24
persiadholbach: 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
persiaI don't think it is good to conflate them, although much of the syntax is similar.13:25
persiaAnything run outside $(shell $(COMMAND)) is unlikely to have the expected behaviour.13:25
dholbachright13:26
dholbach<txwikinger2> recursive patching?13:26
txwikinger2You asked me to be wild13:27
txwikinger2To write a patch that patches a patch :D13:27
AmaranthThis is a horrible thing to do13:27
AmaranthJust apply the first patch, make your changes, make a patch from that, and make sure the first patch gets applied before this new one13:28
txwikinger2well exactly13:28
dholbachpatches can depend on others, that's why a lot of packages use enumeration for patches in debian/patches13:28
Amaranth01change-foo13:28
Amaranth02change-foo-more13:28
persiaEven so, it makes unwinding and feeding upstream difficult.  Also it's a common mistake from using foo-edit-patch blindly.13:29
AmaranthRight, ideally you shouldn't have any patches at all, they should all go upstream as soon as possible13:29
dholbachagreed :)13:29
dholbachpersia and minghua had some more ideas about patching:13:29
dholbach<persia> mixing patches in diff.gz and debian/patches13:29
dholbach<minghua> persia: I wouldn't say it's a terrible thing, as long as the patches are on different areas.13:29
dholbach<persia> minghua: I've hit conflicts before with it, and unwinding was unpleasant.13:29
dholbach<minghua> persia: Right, sucks for mergers, I suppose.13:29
persiaSometimes you need a local patch (see e.g. the man-db package).13:29
rzrdo you also use enumeration with quilt patch system ?13:29
Amaranthrzr: You don't have to (it keeps a list of the order) but you should anyway to make it obvious what goes where13:30
rzryea the series file..13:30
Amaranthwe use quilt in compiz but our patches are still 01foo, 02foo, etc13:30
Amaranth(btw, i think we have like 20 patches :/)13:30
minghuaDoes any patch system rely on the enumeration for the order?  Dpatch has a 00list file to record the order, too.13:31
AmaranthAnother thing to not do: Learn best practices from the compiz patch13:31
Amaranthminghua: cdbs13:31
Amarantherr, from the compiz package13:31
seb128simple-patchsys he means, cdbs can use any dpatch, simple-patchsys or quilt depending of what is listed in the rules13:32
Amaranthwell, yeah, but is simple-patchsys used anywhere else?13:32
Amaranthshould be specific though13:32
dholbachdoor bell - sorry13:33
dholbachbrb13:33
AmaranthIt's a bomb!13:33
txwikinger2It's M$13:33
seb128dunno, but you can use cdbs without using simple-patchsys so saying cdbs is not right13:33
persiaI believe simple-patchsys is only available with CDBS13:33
AmaranthRight, I just forgot the name :)13:33
persiaOK.  Next up: <Amaranth> unneeded dependencies13:34
AmaranthThis tends to happen when first making a package or when updating it to a new version13:34
AmaranthMake sure the dependencies listed for the package are actually needed, otherwise people have to install things they don't need13:34
persiaWhat is a good way to check?13:35
Amaranthhmm, i don't really know13:35
AmaranthUsually when a new release is made they mention new and dropped dependencies13:35
persiaFor 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
persiaFor scripting languages, you can look for #include lines (or the equivalent) in the source files.13:36
persiaAnyone have any other suggestions?13:36
Amaranthi check ldd for binaries13:36
rzrnm too ?13:37
persialdd and nm are good.13:37
persiaNext up: <txwikinger2> download things from different places inside debian/rules13:37
Amaranthof course nm doesn't work on stripped binaries13:37
persiaAmaranth: Should still list symbols for shared library access, no?13:38
seb128what is that thing about dependencies?13:38
Amaranthdoesn't look like it, running it on /usr/bin/compiz.real gives no output13:38
persiaseb128: Ways to check to make sure the package really depends on things listed in Depends:13:39
minghuaIf you use ${shlibs:Depends}, there shouldn't be anything missing (unneeded, perhaps) library in the dependency, should there?13:39
AmaranthWe're talking about listing things that aren't needed13:39
rzrAmaranth: readelf -a is verbose13:39
seb128well, libraries are usually automatically listed13:39
minghuaThen ldd won't work either.13:40
seb128why do you want to use ldd?13:40
minghuadh_shlibdeps should give warnings these days anyway.13:40
seb128right13:40
amarillionmaybe the simplest way is just removing them one by one and trying with pbuilder13:40
seb128and that's not a packaging question13:40
amarillionthis could be automated13:40
rzrAmaranth: about foo.real <= is the .real suffix mentioned in some policy somewhere ?13:41
Amaranthrzr: For compiz we have a wrapper script to make sure it starts correctly so the actual binary gets moved to compiz.real13:41
AmaranthNot sure if there is some policy on this13:42
rzrAmaranth: I guessed that , but why call it .real or .bin or .elf ?13:42
Amaranthnothing else on my system has a .real version so i dunno13:42
Amaranthi know firefox has firefox-bin13:42
rzrI was wondering about that while building a native version of tuxguitar13:43
persiaOK.  So, let's look at the next one.   <txwikinger2> download things from different places inside debian/rules13:43
rzr...13:43
txwikinger2well.. what happens if the download place disappears13:44
rzrpersia: you can merge this one with access to the internet at build time13:44
persiatxwikinger2: That's one part.  The other being that the buildds don't have internet access :)13:45
txwikinger2:)13:45
persiarzr: Doing that.  Thanks.13:45
rzrtxwikinger: or be spoofed ?13:45
persiatxwikinger2: Any suggestions on how to work around that at packaging time?13:45
txwikinger2I think all necessary stuff should be part of the orig tarball13:45
rzrtxwikinger2: but in case they can not be distribuated ...13:45
AmaranthThat's install time though, not build time13:46
Amaranthlike flashplugin-nonfree13:46
persiaAlso, sometimes there are out-of-tree patches maintained somewhere else that are interesting to include.13:46
rzrI dont see any alternative than a wrapper script like swf etc13:46
AmaranthIf you need to install something at build time that is not redistributable then you should just not package such things13:46
txwikinger2if buildds can't get it, it must be part of the package13:46
AmaranthDownloading things at install time can be alright, although this is (i think) really only for flash13:47
persiaRight.  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
rzrdo we have some package like that already ? why for ?13:47
persiarzr: Like which?13:48
rzrwhich need to dl stuff at compilation time13:48
minghuaAmaranth: Another existing example is the MS web core fonts.13:49
Amaranthah, right13:49
rzrbinaries only tough13:49
persiarzr: Some example packages are those that use python ezinstall to download dependencies at build time.  CPAN, gems, etc. are also sometimes issues.13:49
txwikinger2rzr the germinate stuff cannot be automated because of it13:49
rzroh yes I forgot them13:49
Amaranthrzr: What package can you think of that would need to download something from the internet at build time?13:49
Amaranthgems and such should simply be packages so you can build-dep on them properly13:50
dholbachthose people listening in today? were there any items discussed that you had problems understanding?13:50
dholbachok... seems to be all clear then :)13:51
persiaAmaranth: Yes, but it's an unfortunately common mistake, even in Debian sometimes (given the frequency with which arch:all packages are autobuilt)13:51
rzrdholbach: beside your question it's ok for me :)13:51
dholbach:-)13:51
dholbach<dholbach> no docs at all, no manpages13:51
dholbach<Amaranth> manpages? who needs those? :)13:51
dholbach<txwikinger2> code is self-documenting :D13:51
AmaranthAlright then13:52
rzrI just thought13:52
AmaranthEven desktop applications should at least have a manpage explaining what they are and what (if any) command line arguments they take13:52
rzrit should be easy to parse foo --help and generate a template man page isnt it ?13:52
AmaranthFor example, the alacarte manpage just says what alacarte is13:52
Amaranthand it's horrible, so don't ever look at it :)13:53
rulusShould manpages be translated?13:53
dholbachit's not only about manpages... sometimes the upstream tarball ships documentation that is not installed into the package13:53
dholbachthe same goes for example code13:53
rzrcan man page be too documented ?13:53
Amarantha man page is documentation13:54
persiarulus: 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
dholbachrzr: I don't think it happens very often :)13:54
ruluspersia: thanks :)13:54
dholbach<rzr> nothing excepts stuffs in /usr/share/doc ... this happends packaging libraries the wrong way :)13:55
dholbachgood point13:55
dholbachwhat you can do is run    dh_install --list-missing   in the directory of the local build13:55
Amaranthwow, i think i should be taking notes :)13:55
dholbachit 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:55
Amaranthi forgot about dh_install --list-missing13:56
minghuaAmaranth: Need help on alacarte man page?13:56
dholbachit's a great tool13:56
Amaranthminghua: I don't think I really need anything else but if you want to spruce it up a bit go for it13:56
dholbachyou can also run     debc    in the local build directory to find out which files are installed in which package13:56
Amaranthok, now i'm taking notes, i do all this junk manually :)13:56
dholbach<txwikinger2> fail install script because db does not exist13:57
minghuaAmaranth: I'll probably give it a try.  Will let you know either way.13:57
dholbachtxwikinger2: can you say a bit more about this?13:57
txwikinger2well.. there are often webapps that work with a db13:57
txwikinger2when the db does not exist, they just fail and leave a faild-package in apt13:58
dholbachright, they usually deal with those DBs in the postinst/prerm scripts, right?13:58
txwikinger2yes13:58
dholbachbroken postinst/prerm scripts are a big problem for exactly the reason that txwikinger2 points out13:59
dholbachif you're not careful enough, they will break the installation of your users13:59
Amaranthoh man, prerm is the worst13:59
dholbachupgrade processes etc13:59
Amaranthwell, and postrm13:59
dholbachask mvo about it, he has a lot to say about the topic :)13:59
dholbachok... it's time to close the session - thanks everybody for joining in14:00
Amaranthit sucks not being able to remove a package and getting your dpkg stuck an such a state14:00
dholbachthanks persia for taking over14:00
persiaBeing too agressive about update-alternatives and update-rc in maintainer scripts is frustrating as well.14:00
dholbachI had a great time and I hope you did too14:00
AmaranthHas good, thanks to dholbach and persia for running this14:00
minghuaYeah, thanks dholbach and persia.14:00
Amarantherr, Was14:00
txwikinger2\o/ dholbach14:00
* Amaranth needs sleep14:00
* dholbach hugs y'all14:01
persiaAmaranth: There are logs, so you can keep them if you want :)14:01
rzryea thx all , that was my 1st course, i'll manage to be there on next one ..14:01
dholbachsee you all next week :)14:01
persiarzr: 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
AmaranthThose are fun14:02
AmaranthI learned most of what I know from watching such things :)14:02
rzrtry manpages too :)14:03
Amaranthman dh_* is good too14:03
rzr!topic + https://wiki.ubuntu.com/ClassroomTranscripts ?14:10
santiago-veHello!14:25
=== alleeHol is now known as allee
=== bigon is now known as bigon`
=== bigon` is now known as bigon

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