| === anthony is now known as tonyyarusso | ||
| === tonyyarusso is now known as anthony | ||
| === neversfelde_ is now known as neversfelde | ||
| james_w | Hi all, there's a MOTU School session scheduled for here in 20 minutes, that doesn't clash with anythin does it? | 19:41 |
|---|---|---|
| james_w | I realise this is a bit late to be checking | 19:41 |
| pleia2 | nope, it's fine | 19:42 |
| james_w | thanks pleia2 | 19:45 |
| geser | Hi james_w | 19:51 |
| james_w | hi geser | 19:51 |
| james_w | thanks for helping out | 19:52 |
| james_w | I might say some stupid things, so please feel free to correct me if I do. | 19:52 |
| james_w | Hi, all, it's 20:00, time to get started? | 20:00 |
| james_w | Who's here for the MOTU School session? | 20:00 |
| * sebner is | 20:00 | |
| * RainCT is around to see what's going on :) | 20:01 | |
| sebner | aloha RainCT btw :) | 20:01 |
| * Iulian too | 20:01 | |
| * highvoltage is here ready for duty | 20:01 | |
| * ssweeny three | 20:01 | |
| * geser is here to help out where needed | 20:01 | |
| james_w | hi all, good to see you all. | 20:01 |
| james_w | feel free to ask any questions as we go, or to just point out where I'm being silly. | 20:02 |
| james_w | First off, who can tell me what FTBFS stands for? | 20:02 |
| sebner | Fails to Build from Source | 20:02 |
| highvoltage | failed to build from source! | 20:02 |
| james_w | I neglected to put that in the announcement email, which I saw confused at least one person. | 20:02 |
| highvoltage | (without the exclamation mark) | 20:02 |
| james_w | cool, that's a good start. | 20:02 |
| james_w | has anyone worked with them before | 20:03 |
| james_w | ? | 20:03 |
| * geser has :) | 20:03 | |
| * sebner also | 20:03 | |
| sebner | aloha DktrKranz :) :) :) | 20:03 |
| highvoltage | had to fix them before, but not for ubuntu/debian packages really. | 20:03 |
| DktrKranz | hi sebner | 20:03 |
| james_w | right, so I think a quick overview is all that is called for then. | 20:03 |
| james_w | FTBFS means that a source package was uploaded, but it couldn't be built on the buildd. | 20:04 |
| james_w | This means that the binary packages are not available in the archive, so users are not able to get the bug fixes or the juicy new features that are available. | 20:04 |
| james_w | so, it's obviously important to keep on top of the failures, so that the packages make it out to the users | 20:05 |
| james_w | also they are pretty annoying if you are trying to do a transition, as if the packages don't build it's more work to complete the transition | 20:05 |
| james_w | so, where do we find out what packages FTBFS? | 20:05 |
| james_w | we start off by going to the ubuntuwire QA page: | 20:06 |
| james_w | http://qa.ubuntuwire.com/ | 20:06 |
| james_w | there's two pages there we can look at, the first link: | 20:06 |
| james_w | http://builder.ubuntuwire.com:9998/dist/hardy/arch/i386 | 20:06 |
| james_w | is just a record of a lot of rebuilds, a bit lower down is the one we are going to look at: | 20:06 |
| james_w | http://people.ubuntuwire.com/~geser/build_status/ | 20:06 |
| james_w | if you open that you can see that it lists all the source packages that failed to build on at least on architecture. | 20:07 |
| === neversfelde_ is now known as neversfelde | ||
| sebner | geser: a lot of work for you :P | 20:07 |
| james_w | you can see that there are a lot of failures on some architectures, such as hppa. | 20:07 |
| james_w | and fewer for the more common architectures, such as i386 | 20:08 |
| james_w | sometimes you can see a horizontal row of red, which means that the package failed on all architectures, | 20:08 |
| james_w | this will often mean that the package is really bad, or there is some silly mistake in the rules file or similar, | 20:09 |
| geser | just for comparison http://people.ubuntuwire.com/~geser/build_status-gutsy/ where there wasn't much effort to fix FTBFS | 20:09 |
| james_w | these ones are usually either really easy, or really hard. | 20:09 |
| james_w | so, there are three main colours in use. | 20:10 |
| james_w | The first is green, which means that the package is currently building, we can ignore these until they fail. | 20:10 |
| james_w | The second is amber, which means that the package is in the dep-wait state. | 20:10 |
| james_w | This means for instance that the package has a versioned build-dependency that cannot be satisfied currently. | 20:11 |
| geser | green is failed to upload, which means the package build successfully but soyuz failed to upload the debs to the archive for some reason | 20:11 |
| sebner | geser: what reason could that be? | 20:11 |
| james_w | ah, my apologies, it links to the log with BUILDING, I should have read the key. | 20:12 |
| james_w | you can find the key to the colours at the top of the page. | 20:12 |
| geser | sebner: e.g. LP tried to build packages again which weren't touched since breezy (the version is still the same) and the archive didn't accept the "second" upload | 20:13 |
| james_w | geser: am I right in saying that packages in the dep-wait state usually take care of themselves? | 20:14 |
| sebner | geser: k :) | 20:14 |
| slangasek | most of them do | 20:14 |
| geser | james_w: yes, if the waited build-dependency is available they will build automatically | 20:14 |
| james_w | thanks | 20:15 |
| geser | but it can't hurt to look why they are in dep-wait | 20:15 |
| geser | e.g. the build-dependency failed to build | 20:15 |
| geser | or a main package build-depending on something from universe | 20:15 |
| slangasek | but some of them won't, because the build-dependency will never become available for the arch - wrong build-depend on the architecture, package not appropriate for the arch and should be moved to P-a-s, or some buildd admin goofed when setting a manual dep-wait | 20:15 |
| james_w | so, that leaves packages in the red as the third main group, these are the ones where the build failed for some reason, and always require manual intervention. | 20:16 |
| rockstar_ | geser, in the case of a main package depending on something from universe, how do you proceed? | 20:16 |
| james_w | sometimes that intervention is as simple as trying again. | 20:16 |
| james_w | rockstar_: if the dependency is for some optional functionality that can be abandoned then the build-depends can be dropped. | 20:16 |
| james_w | if it's a required dependency then a Main inclusion request should be filed for the package in universe so that the main package can depend on it. | 20:17 |
| james_w | another choice would be to split the package in main if possible to move the part that depends on the universe package to universe. This may be appropriate for plugins packages and the like. | 20:18 |
| james_w | so, how do we deal with a package in the failed state? | 20:19 |
| james_w | firstly you can see what the status of the package is in Debian, as a lot of the failures will occur there as well. | 20:19 |
| james_w | if you look in the rightmost column of the table you will see pairs of links, | 20:20 |
| james_w | "PTS" and "BTS" | 20:20 |
| james_w | the second is the bug tracking system for the Debian package. | 20:20 |
| james_w | click on that and you will be taken to the bug page. | 20:20 |
| james_w | Failures to build are often reported very quickly to the Debian BTS, as there are a few people that regurlarly rebuild the entire archive, and so pick up on these problems quickly. | 20:21 |
| james_w | there are also bugs filed if an upload fails to build. | 20:21 |
| james_w | so, if you click on the BTS link for acl2 you will see an example | 20:22 |
| james_w | http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=acl2 | 20:22 |
| james_w | the string FTBFS will usually be in the summary of bug reports, so you can quickly search for that, in this case you will see | 20:23 |
| james_w | http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=acl2 | 20:23 |
| james_w | sorry, | 20:23 |
| james_w | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=459060 | 20:23 |
| james_w | this could well be the problem with the package in Ubuntu as well. | 20:24 |
| slangasek | (also, FTBFS bugs in Debian /should/ be filed as severity important or serious) | 20:24 |
| james_w | yes, so they will usually be right at the top of the page. | 20:24 |
| james_w | the other alternative is that the problem has already been fixed in Debian, in which case the bug | 20:24 |
| james_w | will be closed, and show up further down. | 20:24 |
| james_w | The PTS link can also help here, as it points to the various uploads of the package and other things, so you can work out what happened to the package. | 20:25 |
| highvoltage | would an FTBFS bug in universe also be marked as serious or important, or just for main? | 20:25 |
| james_w | highvoltage: this is for Debian, which doesn't have that distinction. | 20:25 |
| highvoltage | ok | 20:25 |
| slangasek | right, the distinction in Debian is regression -> serious, needs porting -> important | 20:26 |
| james_w | however, if a bug was filed in launchpad for a FTBFS then I assume that it would be given a Critical or High severity. | 20:26 |
| geser | it's also good to compare the build logs to see if it's the same FTBFS error | 20:26 |
| slangasek | but it's simplest to just look at both groups if you're looking in the Debian BTS | 20:26 |
| james_w | but as geser says you can't just assume that it is the same problem, so let's look at the build log to see how we work out what went wrong. | 20:26 |
| james_w | In Debian the bug will either contain the last part of the build log, or the full thing will be attached (or both) | 20:27 |
| sebner | james_w: SHELL = /usr/bin/bash in debian/rules ? | 20:28 |
| james_w | in Ubuntu you can go back to the status page and click on the failed entry in the arch you are interested in, so let's look at the one for acl2 | 20:28 |
| james_w | sebner: it may be, as it is reported to be a bash problem, but that's not the preferred solution really. | 20:28 |
| sebner | james_w: k :) | 20:28 |
| james_w | so the acl2 log for i386 is at | 20:28 |
| james_w | http://launchpadlibrarian.net/7731665/buildlog_ubuntu-gutsy-i386.acl2_3.2-1_FAILEDTOBUILD.txt.gz | 20:28 |
| james_w | if we open it and scroll to near the end you will see what the problem was in Ubuntu | 20:29 |
| james_w | and in this case you will see that it appears to be the same error message, and so it appears to be the same problem. | 20:29 |
| james_w | for those that don't know about this issue I will say a few words on it. | 20:30 |
| james_w | There are a whole bunch of shells available. The default on Ubuntu (and Debian) for when you log in as your user is /bin/bash | 20:30 |
| james_w | however Ubuntu took the decision to switch /bin/sh to point to /bin/dash instead of /bin/bash, which it has historically done in Debian, and older releases of Ubuntu | 20:31 |
| geser | one note: acl2 FTBFS only on i386 (and succeed on the others). The FTBFS list shows only the i386 entry. arch:all packages have also only one entry as the package is only build on the i386 buildd. So lines with i386 only may also be equal important as lines full red. | 20:31 |
| james_w | dash, as the name suggests, is faster than bash | 20:32 |
| geser | james_w: are you looking at the correct log? the last version of acl2 is 3.3-1ubuntu1: http://launchpadlibrarian.net/12247407/buildlog_ubuntu-hardy-i386.acl2_3.3-1ubuntu1_FAILEDTOBUILD.txt.gz | 20:33 |
| james_w | and as /bin/sh is what system scripts get as their interpreter this makes things run quicker, including the boot process | 20:33 |
| slangasek | (hmm, I wonder what it suggested back when it was just called "ash" ;) | 20:33 |
| sebner | james_w: when we log in as user it's /bin/bash. why not /bin/dash ? | 20:33 |
| RainCT | sebner: bash has more features :) | 20:34 |
| james_w | geser: dammit, I switched to the gutsy page to have a look, thanks for pointing that out. | 20:34 |
| sebner | RainCT: but dash is faster? | 20:34 |
| james_w | sebner: because /bin/bash is in /etc/passwd for your user | 20:34 |
| sebner | They should merge ^^ | 20:34 |
| slangasek | dash is not a very good interactive shell | 20:34 |
| geser | sebner: because /etc/passwd has /bin/bash as shell for you | 20:34 |
| slangasek | e.g., it doesn't have readline support | 20:34 |
| sebner | k | 20:35 |
| RainCT | sebner: dash is faster, but bash is more convenient for interactive usage | 20:35 |
| james_w | ok, so I'll drop the bash/dash discussion as it's not relevant here | 20:35 |
| james_w | except to say that this was the cause of a lot of problems for Ubuntu, and so a lot was fixed. However, Debian also aims to allow this change to be made, and so they care now about the fixes | 20:36 |
| james_w | so if you fix something in a package to do with bash/dash, make sure to forward the fix to Debian, as it is a release goal for lenny. | 20:36 |
| james_w | ok, so we'll instead look at the package that I picked out for this, can you all open | 20:37 |
| james_w | http://launchpadlibrarian.net/12605855/buildlog_ubuntu-hardy-i386.dag2html_1.01-2build1_FAILEDTOBUILD.txt.gz | 20:37 |
| james_w | and scroll to the bottom? | 20:37 |
| james_w | you will see that this package fails to build with an error | 20:37 |
| james_w | (I picked an easy one on purpose) | 20:37 |
| james_w | make[1]: camlp4r: Command not found | 20:38 |
| james_w | make[1]: *** [dag2html.cmo] Error 127 | 20:38 |
| james_w | so, the build uses a command that isn't available. | 20:38 |
| james_w | This is another common source of problems. | 20:38 |
| sebner | missing build-dep? | 20:38 |
| james_w | If the build uses a command then the package should Build-Depend on the package that provides the command. | 20:39 |
| james_w | sebner: exactly | 20:39 |
| james_w | so, let's fix this one shall we. | 20:39 |
| james_w | First, you should install "apt-file" if you haven't already. | 20:39 |
| james_w | "sudo aptitude install apt-file && sudo apt-file update" | 20:39 |
| james_w | now, you will be able to query apt-file to find which package contains the command | 20:39 |
| james_w | apt-file search camlp4r | 20:40 |
| geser | or packages.ubuntu.com for the lazy ones :) | 20:40 |
| james_w | which tell me (amongst other things) | 20:40 |
| james_w | camlp4: /usr/bin/camlp4r | 20:40 |
| james_w | so, we can grab the source of the package in question (dag2html) | 20:41 |
| james_w | apt-get source dag2html | 20:41 |
| james_w | and check its debian/control file for the Build-Depends line | 20:41 |
| james_w | Build-Depends: debhelper (>= 4.0.0), ocaml-native-compilers | 20:42 |
| james_w | so, it doesn't list the package we found, but first we should make sure that it is supposed to, what's this "ocaml-native-compilers" package? | 20:42 |
| james_w | apt-cache show ocaml-native-compilers | 20:42 |
| james_w | that contains: | 20:43 |
| james_w | This package contains the native code version of the compilers and lexer | 20:43 |
| james_w | (ocamlc.opt, ocamllex.opt, ocamlopt.opt, camlp4o.opt and camlp4r.opt). | 20:43 |
| james_w | hmm, it says "camlp4r.opt", and we want camlp4r, maybe that's the problem. | 20:43 |
| Flare183 | looks like it | 20:44 |
| james_w | so, what do we think the solution is? | 20:44 |
| geser | it looks like camlp4r moved from ocaml-nox (gutsy) into it's own package camlp4r in hardy | 20:45 |
| sebner | geser: camlp4 | 20:45 |
| sebner | http://packages.ubuntu.com/hardy/camlp4 | 20:45 |
| Flare183 | looks like something in the rules file | 20:46 |
| sebner | d.p on camlp4 | 20:46 |
| geser | sebner: yes, I typed the package name from head | 20:46 |
| sebner | k | 20:46 |
| james_w | so, in the build log I can see "dh_clean: Compatibility levels before 4 are deprecated." | 20:46 |
| james_w | so it's possible that this is an old package that has not been keeping up with transitions | 20:47 |
| geser | [2004-09-15] Accepted 1.01-2 in unstable (low) (Cyril Bouthors) | 20:47 |
| geser | the last upload to Debian | 20:48 |
| james_w | thanks geser | 20:48 |
| geser | that info is from the PTS entry for that package | 20:49 |
| james_w | ok, so thanks to geser we know that ocaml-nox used to contain the file | 20:50 |
| james_w | ocaml-native-compilers is in the Build-Dependencies, and that depends on ocaml-nox | 20:50 |
| james_w | so that would have made the commands available before the transition | 20:51 |
| james_w | so, we need to add camlp4 to Build-Depends to bring the commands back I think | 20:51 |
| geser | that would be my guess too | 20:52 |
| james_w | that is why when you create a package you should ensure that anything it uses, either when building, or when running, is provided *directly* by the Build-Depends. | 20:52 |
| james_w | if you rely on an indirect dependency then this may happen eventually, which creates more work. | 20:52 |
| james_w | so, I'll create a patch for this package, so that we can remove one more package from the list. | 20:53 |
| james_w | however, it's important to still test the patched package, as a build log will only show you the first failure, it's possible the package will fail with a different error once this is corrected. | 20:54 |
| james_w | has anyone got any questions? | 20:54 |
| james_w | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443029 is the Debian bug report, so I will send any patch their as well. | 20:54 |
| sebner | james_w: we don't need any versioning here right? | 20:55 |
| slangasek | (how many licks does it take to get to the center of a tootsie roll FTBFS?) | 20:55 |
| james_w | sebner: I don't think so no. | 20:55 |
| james_w | slangasek: tootsie roll? | 20:56 |
| slangasek | james_w: nevermind, I'm just making oblique cultural references to US TV commercials... :) | 20:57 |
| geser | sebner: a versioned build-dependency is only needed when an old package won't be sufficient | 20:57 |
| sebner | geser: k | 20:57 |
| james_w | ok, so if there's no more questions we'll wrap this up and I'll get on with the patch. | 20:58 |
| geser | sebner: the most common case: debhelper >= 5 if one uses compat level 5 (debhelper 4 doesn't support obviously level 5) | 20:58 |
| james_w | thanks to geser and slangasek for correcting me, and to everyone else for coming. | 20:58 |
| rockstar_ | Thanks for taking the reins james_w | 20:59 |
| sebner | geser: k | 20:59 |
| james_w | I don't know what the session will be next month, so if you have any ideas or suggestions please vote on the wiki. | 20:59 |
| james_w | though given the date perhaps "how to have a rocking release party" would be a good session. | 20:59 |
| slangasek | :-) | 21:00 |
| slangasek | step 1) fix the FTBFS bugs before release | 21:00 |
| james_w | or perhaps doing it after release would make more sense, in which case it would be "how to hug slangasek" | 21:00 |
| slangasek | heh | 21:00 |
| geser | some note to the depwait on the ftbfs list: as the list gets generated once daily some dep-waits may be gone when one looks as the list, e.g. clutter-cairo right now, so it's good idea to double-check the build-status on LP | 21:00 |
| sebner | james_w: ehm. just test builded. now I have a different error. it still FTBFS | 21:06 |
| james_w | sebner: damn | 21:06 |
| james_w | sebner: shall we take this to -motu? | 21:07 |
| sebner | james_w: well. it's a FTBFS session ^^ | 21:09 |
| sebner | james_w: http://pastebin.com/m4e44a0e8 | 21:09 |
| sebner | But I'm wondering why nobody except me test-builded it | 21:10 |
| james_w | sebner: in the session? | 21:11 |
| sebner | james_w: Well I'm the only one complaining | 21:11 |
| james_w | sebner: I think everyone else was treating it as a theoretical thing | 21:13 |
| sebner | It seems that I have further experience ^^ | 21:13 |
| sebner | james_w: already found the mistake? | 21:23 |
| james_w | sebner: still installing the build dependencies | 21:24 |
| sebner | ah ^^ | 21:24 |
| sebner | james_w: I suppose you have the same error? | 21:32 |
| Laney | sebner: I see it too | 21:36 |
| james_w | sebner: yep. | 21:38 |
| geser | pa_ru.cmo was part of ocaml-nox in gutsy but vanished in hardy | 21:41 |
| james_w | yep | 21:43 |
| james_w | I think we should just kill the package. | 21:43 |
| sebner | james_w: that's another way to kill FTBFS bugs ^^ | 21:43 |
| mok0 | I was afraid it was coming to this... | 21:44 |
| james_w | mok0: are you a fan of the package | 21:44 |
| mok0 | no | 21:45 |
| mok0 | Just waiting to see the bug resolved in the tutorial :-) | 21:45 |
| sebner | hrhr | 21:45 |
| Laney | At least 59 people have it installed, according to popcon ;) | 21:45 |
| james_w | mok0: :-) | 21:45 |
| mok0 | so this is a bug in camlp4 that was discovered here... | 21:47 |
| james_w | why? | 21:47 |
| mok0 | because a file that used to be present in ocaml and was not moved to camlp4 | 21:48 |
| james_w | perhaps, I don't know enough about it to say whether that is a bug | 21:50 |
| mok0 | ... a consequence, at least | 21:50 |
| Laney | http://caml.inria.fr/pub/docs/manual-camlp4/manual002.html talks about pa_ru.cmo | 21:51 |
| james_w | I'm going to email a bunch of people about this package | 21:52 |
| james_w | namely the maintainer, the pkg-ocaml team, and debian-qa. | 21:52 |
| geser | james_w: you should've picked up an easier case for the session :) | 21:56 |
| james_w | I thought it was easy :-) | 21:56 |
| james_w | they never are... | 21:56 |
| james_w | actually, I had a better one, but someone uploaded a fixed version at the weekend. | 21:56 |
| geser | james_w: you should've picked ocaml-alsa | 21:57 |
| geser | it was an easy one (and 6 other ocaml-* packages with the same error) | 21:57 |
| james_w | it will be useful though if we get to kick a bad package from the archive. | 22:00 |
| sebner | well no one knows. everybody left ^^ | 22:00 |
| geser | james_w: good you didn't pick scala as an example (the build log is huge) | 22:01 |
| geser | 383M 2008-02-27 08:06 buildlog_ubuntu-hardy-i386.scala_2.5.0-1_FAILEDTOBUILD.txt | 22:03 |
| sebner | geser: what's scala? | 22:04 |
| geser | a package with a FTBFS | 22:04 |
| geser | I don't know more | 22:04 |
| sebner | xD | 22:04 |
| geser | only that the build log killed my old box (1 GB RAM, no swap) | 22:05 |
| geser | I tried to open that build log in firefox | 22:05 |
| DareDevil | Hello I have a problem with ubuntu can you help me please?? | 22:05 |
| sebner | DareDevil: #ubuntu | 22:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!