[00:01] Ultimately some kind of software engineering discipline is required. Let's figure out how to have infinite variants of all libraries interact with each other is a recipe for insanity. [00:01] ScottK: We all agree on that. We are trying to deal with exactly that lack of discipline by providing the ability to assemble multiple versions of Ubuntu/Debian packaged software for a single application's expectations. [00:02] SpamapS: I think that's the wrong solution. [00:02] its pretty much the way the web is developed these days. [00:02] sane or not [00:03] SpamapS: folk can choose to publish source or not [00:03] I think it's reasonable for developers to be able to layer cpan/pypy/maven/gems/etc on top of the distro, but I think can't make that part of the distro. [00:03] some upstreams are insane, and need to be helped to learn about open *SOURCE* [00:03] You're saying if 99% of zope is good, but 1% of it breaks its API in the next release of Ubuntu, people who are relying on said API should ... not use zope? [00:04] ScottK: I think that we've segued. [00:04] OK. [00:04] ScottK: I'm not talking about mass important pypi [00:04] or maven.org [00:04] I do see Scott's point though. That we're facilitating API madness. [00:04] * ScottK was in transit for a while. [00:04] ScottK: I'm talking about removing the *technical limitation* that prevents coinstalling incompatible versions of a dependency shared by either (other packages) or (user installed software) [00:04] Yes. Please don't do that. [00:05] lifeless: If packages are packaged for co-installation that's not a problem. People just have to be convinced it's worth the trouble. See the postgresql packaging for a excellent example of how to do it. [00:05] ScottK: right now for C/C++/CLR packages we support this by putting the soname in the library package, and making clients of the library depend on the libraryname-soname package, with some minimum version specified [00:05] (I know you know that) [00:06] ScottK: ack [00:06] ScottK: so the thing is that neither the java nor python packaging policies cater for this. [00:06] True, but we also normally only ship one version in a final release unless there are multiple source packages. [00:07] ScottK: *and* we need some sensible upstream support/blessing for making 'get the newest $soname-like thing' for the more dynamic (python and ruby specifically) languages. [00:07] lifeless: Actually what we're trying to do with separate binary packages for Python 3 is a form of this. [00:07] ScottK: cool; I have to admit I haven't looked really closely at that. [00:07] ScottK: did you see my use case on the debian-python list? [00:07] lifeless: I did, but I confess I only skimmed it. [00:07] ScottK: fair enough [00:08] very briefly, the scenario is to be able to have two versions of launchpad installed on a machine, (which commonly requires two different releases of (say) zope.publication) [00:09] this is orthogonal to whether launchpad itself would be a package. [00:10] ScottK: re: different source packages & binary packages - I would expect different source packages in this scenario [00:11] ScottK: all the discussion about maven and pypi glue for finding stuff is simply saying: if we can support a richer set of $language packages, then we can -more easily- do the following things: [00:11] (in no particular order) [00:12] - have packages that build with easy_install and the like be fenced off from the internet and get their requirements from apt [00:12] - when a user is using easy_install, have it preferentially find versions from apt [00:12] (for java s/easy_install/maven/, etc) [00:13] I'd personally still expect to be looking at a deb source package and putting license metadata into place - perhaps assisteded by some automation, but such automation is also orthogonal [00:17] In the world of cheap VMs isn't this a bit overenginieered? [00:19] lifeless: Why not just run a separate VM for each one and don't worry about conflicts? [00:22] ScottK: for a developer doing development, who has the same issues, vms are not at all that cheap. [00:23] ScottK: one could say the same thing about having libgettext4 and libgettext5 installed - just use a vm fo rthe programs that need the old/new thing. [00:24] OK. [00:24] Basically, just allow debian packagers to produce binary packages that play in upstream packaging space. [00:25] if pypi has a way to do version requirements, allow a .deb to satisfy that... [00:27] SpamapS: I agree with that. [00:27] Isn't that (at least sort of) what our patched easy_install does now? [00:29] ScottK: two key missing points: [00:29] - packagekit integration to get extra requirements on the fly [00:29] - packaging policy change to put the version number (or as many significant bits as we choose) in the package name. [00:29] packagekit is pretty broken with respect to Debian packages anyway. [00:30] sadly :( [00:30] In order for Kpackagekit to know if it needs extra packages, it actually has to attempt a simulated install and see the results (or something close to that) [00:30] so the idea though, of user space code being able to say "I need this library, please, now" is useful but not strictly needed. [00:43] lifeless: or you could package your app, and the requirement would be resolved at install time. [00:44] SpamapS: that doesn't help with runtime determined dependencies [00:44] SpamapS: doesn't help *us* the *packagers* [00:55] lifeless: ok, my brain's full.. will need to process this a bit to feel good about it. :) === bjf is now known as bjf[afk] [01:36] SpamapS: I think run time dependency discovery is not a great idea. Imagine a web page waiting for a new library to install before it can render. [01:37] ScottK: by runtime I'm primarily thinking about build chains that do runtime determination [01:37] ScottK: not after-packagin runtime dependencies [01:37] Ah. OK. [01:37] That's a bit different. [01:37] POX has done some stuff kind around that idea in dh_python2/3. [01:42] Probably nice to split the problem space: have one thing that tries to determine what is missing. Have an entirely different thing that tries to address this perceived lack. [01:42] The first is hugely useful for packagers. The latter is potentially useful for someone. [01:42] If the output of the first is compatible to the input of the second, folk share. [01:43] Step 0 though is upstreams that are willing to maintain API/ABI compatbility or document when they change. [01:44] ScottK: I don't really see that as hugely important; we can do what we did with e.g. libcamel for upstreams that don't. [01:44] ScottK: its nice then they do, but we don'tneed it. [01:45] There's vast potential to improve the interface for upstreams to be able to do so easily. Some languages don't even have a convention available to indicate a version. [01:45] Just use releases as API/ABI surrogates? [01:45] sure [01:46] That said, I've found it a rare upstream that isn't willing to track API/ABI, assuming they can be shown how to do so. [01:46] as long as upstreams know how to [01:46] instead of doing things like bumping SONAME for every upstream release, or the equivalent [01:47] Right, hence the importance of making better tools available, or *any* tools/convention for things like Java. [01:48] and we're back to changing the packaging policy to encode more data ;) [01:48] yeah, we had this debate yesterday in #debian-cli :) [01:48] lifeless: I'd start with an upstream concept and see how to extend it. [01:48] For example, what do Python eggs not have that we need? [01:48] Or if they have it, how do we exploit it? [01:49] ScottK: thats where I started [01:49] ScottK: pkg_resources.require, which is a setuptools (not distutils) thing, supports versioning of dependencies [01:50] if we say (reasonably so) that you should use that if you need versioned depends, then the upstream angle is taken vare of [01:50] lifeless: I'd talk to POX about what he's already doing to automatically generate versioned depends in dh_python. [01:50] {2,3} [01:50] where does he hang ou? [01:50] And we can use that to populate autodependencies (${Python:Depends} in this case) [01:51] persia: sure, but that is orthogonal to the problem I want to solve [01:51] lifeless: #debian-python on OFTC is best, but #ubuntu-motu also often works. He's in .pl, so likely sleeping. [01:52] lifeless, I'm thinking about "by runtime I'm primarily thinking about build chains that do runtime determination". Why would the build-chain output not want to auto-generate package dependencies? end-user-runtime differs. [01:56] persia: I think it would nice to do so. [01:57] persia: I'm saying that that is a separate benefit to being able to even *build* such things more easily. [01:57] You want build-time installation of build-deps? [01:57] persia: and to being able to *install* concurrent versions [01:58] persia: yes, its a key thing for both maven and easy_install chains; its not -mandatory- but we can save a lot of packager headache if we do it well [01:59] Concurrent installation isn't hard, if one packages it in a namespace-safe manner. That said, having been involved with the pain that was maven, I'm convinced the idea of build-time install of build-deps is misguided at best, and potentially actively harmful. [01:59] We have a solution for maven. [01:59] persia: hah. no, we don't. [01:59] Have had it for > 1 year. [01:59] doesn't scale, doesn't handle enough cases. [01:59] doesn't scale how? [01:59] What cases doesn't it handle? [02:00] Show me bugs, or explain yourself :) [02:00] it doesn't handle the concurrent-deps case [02:00] OSGI apps for instance [02:00] Does if the package of the dep is concurrent-install safe. [02:00] That we choose not to do that much is a different thing :) [02:01] No policy changes are needed to do so, just will to do the work. [02:01] persia: they aren't orthogonal; the maven helper whose code I saw doesn't understand concurrent installs [02:01] ScottK: in which case it will be easy. [02:01] Hi, I'm looking at https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/644015, and in debian/rules, there's the following line: ifneq (,$(findstring test,$(DEB_BUILD_OPTIONS))) [02:01] . I'm guessing that's to disable testing? [02:01] Launchpad bug 644015 in bzr (Ubuntu) "bzr package build should run the test suite" [Undecided,New] [02:02] If so, changing 'ifneq' to 'ifeq' should enable it, right? [02:02] hey, I'm not trying to make this it a Big Thing. Last I checked though, bother the java and python policy specified *how* packages were named, and didn't provide an abi-or-equivalent field. [02:02] lifeless, It's been a while since I looked, but my memory was that concurrency was experessed by installing two different packages (versioned), which provided two different .pom files, which maven happily processed. [02:03] lifeless, Dunno much about python, but for Java, nthykier and mjj29 have been working on that for some time. [02:04] Won't hit policy until there's a healthy bundle of stuff in the archive, and very unlikely to go pre-squeeze-release because of the RC load that level of policy violation would create (RT would kill folk) [02:04] ok, java policy has been updated [02:05] Some package must also provide a symbolic link from... <- a bit fragile for upgrades, still. [02:07] however http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html is still no-allowance-for-concurrent [02:08] with the cli policy, libraries are installed into a versioned directory & can be requested by version, because they contain the version information within them [02:09] lifeless, Java policy is still work-in-progress :) For python policy, definitely talk to POX before trying to invent something. [02:09] persia: I hear you [02:09] persia: I sent mail to barry/spamaps/jos precisely because I don't have time to invent something... but I want to benefit from it ;) [02:10] Then they ought go talk to debian-python :) [02:10] Which is where barry started. [02:11] Excellent. Why are we talking about it here then? It's an interesting discussion, but I'm now confused. [02:11] Not sure, but that's only the Python bits of this anyway. [02:12] persia: because SpamapS told me his head was exploding. [02:12] persia: and then we started over 3 times as new people weighed in [02:13] * persia gives SpamapS a exceedingly strong head restraint, for preservation of skull [02:13] lifeless, I didn't see that much repetition in the restarts, but maybe I didn't read closely enough. [02:13] lifeless: fwiw, i understand what you want to achieve. there's a similar problem in perl (except require foo 2.3 works). this does seem like an issue for python/debian-python though that we might support, not one we can likely drive =/ [02:14] jiboumans: oh hai :P [02:14] It's going to take someone that wants it enough to champion it. [02:14] * jiboumans omnipresent [02:14] jiboumans: I'm looking in the long term [02:15] lifeless: not being a python expert, is there a 'proper' python way to do it now if i were installing from source/github? [02:15] jiboumans: I'm happy to help organise etc, I don't think I can put in lots of time. [02:15] jiboumans: pkg_resources.require, part of the setuptools (now distribute) stack. [02:15] * ScottK calls on the spirit of barry to cover all things Pythonic. [02:15] jiboumans, eggs are about as close as you'll find for that sort of thing, and the cheeseshop is a better example than github for use. [02:15] which is in equal parts reviled and adored all the Python worlds. [02:16] persia: i... failed to parse that.. eggs? cheese? [02:16] lifeless: what i'm getting at is that if there's a best practice, we can probably integrate and codify it [02:16] or at least give it a shot [02:17] jiboumans, Uhhh : python things to help folk shop for code? Ask someone who doesn't run and hide when confronted with pythong. [02:17] jiboumans: yes, thats what it is [02:18] jiboumans: the 'it all works easily stuff' is built on: [02:18] - distribute (new shiny) [02:18] - eggs [02:18] they have an ongoing discussion about metadata [02:18] heh [02:18] but the critical bit is that in a app/library you say [02:18] require('foo==1.3.2') [02:18] import foo [02:18] i've been through this with perl, i have a vague idea of the space :) [02:18] and you either get an error, or foo 1.3.2 [02:19] require('foo>=1.3.2') [02:19] import foo [02:19] and you might get foo 1.4 [02:19] lifeless: right, so now we have to make sure you can install foo 1.3.2 and foo 1.3.3 at the same time and life is good [02:19] jiboumans: exactly [02:19] jiboumans: which requires two things: [02:19] - disk layout [02:19] - a symlink or something so that a trivial script that just does [02:19] 'import foo [02:19] ' [02:19] will pickup the latest shiny. [02:20] (or most stable shiny, whatever - policy not mechanism) [02:21] right.. alternatives can do that [02:21] we'd want debian to adopt that though, or we'd carry a nasty delta [02:21] alternatives, a meta package (supplying the symlink and current 'best' dependency) [02:21] Rather, we'd want to inherit the solution from Debian, although some of us may participate in it's creation. [02:21] pysupport could put the link in place [02:22] it is, in principle, very simple [02:22] SMOP ;) [02:22] hah, perl 6 you say? [02:22] smop! [02:23] jiboumans, More than that, programming + working with all the people who need to use the feature to make sure they adopt it as the one-true-way. [02:23] and mind you, there's a release of perl 6 ;) [02:23] persia: *nods* [02:24] intuitively it feels like debian is the place where this would happen though and we'd follow, even as you said we'd participate in the creation [02:24] the 'we' there is not very likely my team though given our goals [02:24] Yep. We tried the other way once (dh_iconcache) and it only made it harder to reach the correct final state. [02:24] (the latter we, who'd create it ;)... damn it's getting late [02:26] food calls & [02:28] Hmm. So, bzr tests are running, and the fails so far have been unicode encoding errors. Can these be safely ignored? [02:28] No. [02:28] …ok then. [02:28] Lots of folk use Ubuntu in places where non-unicode is unreadable confusing garbage. [02:29] Do they fail only on the buildds or also run locally? [02:29] possible a stable build-dep on testtools 0.9.6 [02:29] I think the buildds default to C as a locale, which complicates things. [02:29] persia: we turn off relevant test sfor that case [02:30] Oh? Hm. I'm just running it in pbuilder at the moment. I'm new to this :) [02:30] persia: but yes, it could be related [02:30] lifeless, OK. That's safe then. [02:30] ldunn: you might like to chat to maxb [02:30] * persia hasn't ever seen unicode work right when LANG=C [02:31] alrighty [02:37] * ldunn sits around, waits for tests to finish === hunger is now known as Guest97520 [02:43] * ScottK is sitting around waiting for builds to start. [02:49] ScottK: for what build? [02:50] bdrung_: PPA uploads of the new clamav release for Lucid, Karmic, Jaunty, Hardy, and Dapper. [02:53] ... bzr build failed. >:( [03:40] persia: hi! [03:40] persia: is there a standard way to find the current JAVA_HOME? [03:57] mathiaz, In what context? [03:57] So is there a better more up to date source for info on app submission process then : https://wiki.ubuntu.com/PostReleaseApps/Process -- I need info for a session at Code Camp [03:57] persia: https://issues.cloudera.org/browse/DISTRO-2 [03:58] persia: ^^ trying to support building with default-jdk *and* sun-java-jdk [03:58] persia: depending on which one is installed [03:58] persia: JAVA_HOME will be different IIUC [03:58] MarkDude, That's about as close as it gets. Note that under current semantics that submits applications to something that isn't Ubuntu, but dependent on Ubuntu. [03:58] persia: it seems that /usr/lib/jvm/default-java/ won't point to the sun-jdk if installed [03:58] Yes, JAVA_HOME would differ. Why would you want to support building with sun-jdk? [04:00] persia: because that's what upstream strongly recommends [04:00] ok persia - and the important thing for me to stress would be that; the process is *still fluid*. Also that the process is *open* and public - correct? [04:01] Right, looking at recent discussions, it seems we're trying to move away from any expectation or dependence on JAVA_HOME [04:01] MarkDude, Could you explain more about the topic and audience? I may be able to provide more targeted advice. [04:02] It will be primarily an MS crowd [04:02] not all tho [04:02] Silverlight, etc and Iphone [04:02] But some Android devs also [04:03] Yeah, that's probably best for now. There are other processes (also still fluid) that would be more appropriate for people working on primary system applications, but if you're talking to a bundle of folk who just want to have some little bit, they can use that. [04:04] Note that if their work is interesting, it might make sense to incorporate that as a system application, but that's a more complicated message than is easy to put across in a short time (plus, making it a system application creates an expectation of ongoing maintenance, etc.) [04:05] Cool. ty. I might come back in a week or so to see if I could get some nice person to glance at my notes :) [04:06] That would make sense- but I would use that info after - when talking to a specific person [04:06] Thank you developers, you folks ROCK! [04:06] mathiaz, I've just reviewed the current draft of what will become Java policy, and it specifically fails to mention JAVA_HOME, as most stuff is packaged to not require this. [04:07] mathiaz, My recommendation for the upstream solution would be to check for the JAVA_HOME environment variable, and if not set, use the regular Ubuntu way to build stuff. If set, use it. [04:08] mathiaz, For extra points, remind upstream of the upcoming EOL date for sun-java, and that even Oracle primarily extends openjdk these days. [04:15] persia: yop - that's what I'm saying to upstream [04:16] persia: it seems that they're running into issues when using openjdk [04:16] persia: I'll look at the debian/rules again [04:16] persia: thanks again for your input on JAVA_HOME [04:16] OpenJDK isn't bug free :) That said, when issues are encountered, upstream is usually happy to get patches. [04:17] Sorry I didn't have more useful news. JAVA_HOME was all the rage some time back. [04:19] Blugh. I'm lost with these tests [04:19] ldunn: for the bzr package? [04:19] yeah [04:19] Pastebin the failures? [04:20] Err. They're going way past my scrollback in gnome-terminal. Does pbuilder keep logs somewhere? [04:22] I don't know, sorry. (But I am a bzr dev, so I may be able to help with the bzr test failures) [04:22] Hm, well there were 16 failures, I think about 5 were related to unicode errors, and a few were broken pipes with the HTTP server [04:23] * ldunn re-runs pbuilder and collects failures as they come [04:29] heh, I'm not going to be able to catch all of them [04:30] http://ubuntu.pastebin.com/tYxTJ9i8 spiv, that's more or less what's come up so far, up to ~2500/25000 [04:30] It's not possible to redirect the output with > or tee? [04:30] uh. Let me check [04:32] there we go. [04:33] pbuilder *does* make logs (although I don't use it, so don't know where). Check the docs, and save yourself hassles. [04:34] bah, --logfile. :D [05:05] ... ok, so... that... didn't really seem to work. [05:05] Unless it doesn't store the log in the pwd [05:07] In which case... here's a few more failures http://ubuntu.pastebin.com/ZgxFLrBn [05:12] ldunn: You need to do --logfile [path to logfile from pwd including name] [05:12] i.e. --logfile log [05:12] That's what I have [05:12] sudo pbuilder build bzr_2.2.0-1ubuntu1.dsc --logfile pbuilder.log [05:13] Needs to go after build and before the .dsc [05:13] pbuilder doesn't look after the .dsc [05:13] ... oh! [05:13] *that's* more like it. Thanks :) [05:13] * ldunn waits another half hour [05:14] You're welcome. [05:14] ldunn: you might like to try sbuild, it works much faster ;-) [05:14] especially those aufs + tmpfs builds [05:15] oh? I'll investigate [05:15] ;-) [05:21] james_w: ahoy there! You're doing package training on Thursday - just a reminder :) === almaisan-away is now known as al-maisan [06:33] Ok! Finally. http://pastebin.com/kVa8N0Pa === amitk-afk is now known as amitk [06:36] 5750 lines... o.o [06:36] ldunn, Yep, but only the test failures are interesting: most of the rest is just context. [06:37] Yeah [06:37] I figured I may as well paste it all in case there's some other info that might help [06:37] from the looks of it, the tests store test logs somewhere: is the dirty build environment still available? There may be files of interest there. [06:38] It seems like pbuilder removes the environment. "I: removing directory /var/cache/pbuilder/build//2021 and its subdirectories" [06:38] * ldunn[laptop] pokes the manpage a bit more [06:38] There's some argument that preserves it (again, I have no idea which) [06:38] If there's no way to preserve it, that's a bug in pbuilder [06:38] yeah [06:40] It's also worth inspecting the test source: lots of times it's possible to figure out the issue from the way the test fails and the test source. [06:45] persia: bzr includes the log entries with the failures [06:45] spiv, Those little 4-5 line bits are the entirely of the test failure output? [06:46] Yes, although some are much longer! [06:46] See e.g. the log starting at line 4092 [06:46] Tracebacks are interesting, but I have to admit, I really appreciate exception handlers that try to explain what went wrong for test failures. [06:47] Yes, me too :) [06:47] Some tests are much better than others at that... [06:48] It's always the case. It's easy to mandate that folk write tests when committing code. It's much harder to convince folk that their tests need to fail in a helpful manner without accusations of recursive TDD [06:49] So, I guess some of these tests are failing because the pbuilder env isn't set up for unicode? [06:50] ldunn, To put that another way, perhaps the tests are making unwarranted assumptions about the environment in which they are run. [06:50] Well, bzr's test suite is supposed to cope with LANG=C. [06:50] hmmm. [06:50] (By skipping tests, if necessary) [06:51] It skipped 246 unicode-related tests, apparently [06:51] Mind you, skipping tests isn't usually the best way to get around stuff, as it might defeat the point of the tests running during the build :) [06:51] This is true. [06:52] Another option would be to adjust build-depends, force LANG=${something-else}, and then run the tests. [06:52] Either way, looks like a bug in the test suite (the test should have been skipped if it depended on LANG != C ) [06:53] Hm. :/ [06:54] That said, at least the bzrlib.tests.blackbox.test_alias.TestAlias.test_unicode_alias failure is reproducible with LANG=C [06:55] So it appears our test suite has some bugs here :/ [06:56] So, at the moment, the test suite probably shouldn't be enabled on this package? [06:56] * spiv kicks off a local test run [06:56] At the moment, yes :( [06:57] Please attach that log to the relevant bug, if you haven't already. [06:57] I haven't, I'll do that [06:57] ldunn, Based on the meeting last night, I believe the test suite is required to be enabled on that package. [06:57] I'll see how easy it is to fix these failures, it's probably not hard. [06:57] new microrelease coming up ? :) [06:58] If LANG=C is the only cause, a reasonable workaround may be to set it to something else (and cause more tests to run too, as an added benefit) [06:58] (might wait until the test suite passes in a buildd environment before placing the final tag) [06:58] *nod* [06:59] Hmm, I notice python-paramiko isn't installed in that environment... that's good, paramiko has a bug that causes a test failure ;) [07:00] (I've submitted a patch to upstream and to the bug for the ubuntu package, but no response yet) [07:00] That's part of why we use the specialised environment: we can control what packages are installed there (save a certain minimal set, but anything that doesn't work with those is probably suspect anyway) [07:01] Right. [07:02] In an ideal world, perhaps the package build would manage to run the test suite twice: once with the minimal dependencies, and once with all the Recommends and Suggests as well. [07:02] But I expect that would be pretty tricky to do. [07:04] spiv, Requires turning on (limited) network access mid-build, which then permits packages to significantly vary behaviour based on contents of internet sources, which permits a number of interesting avenues to enable running arbitrary code on arbitrary machines. That said, a responsible upstream wanting to make sure their testsuite runs under adverse conditions can always add all sorts of random things to build-depends to test it. [07:06] Well, we already have http://babune.ladeuil.net:24842/ [07:07] Which currently exercises our trunk on a variety of platforms [07:07] I note it failed on maverick :P [07:07] (In addition to merges to trunk and the stable branches having to go through PQM, which runs 'make check') [07:07] That's probably the right place to exercise it in a variety of environments on each platform then. [07:08] * persia has a 5 line patch that passes "make check" and causes complete system failure for all users [07:08] ldunn[laptop]: failed to fetch the code due to a config issue: [07:08] http://babune.ladeuil.net:24842/job/selftest-maverick/lastFailedBuild/console [07:08] oh. Alright, heh [07:08] Ah, so I see. [07:09] persia: Me too, how about we apply it to the packaging? ;) [07:09] Please no :) [07:09] I think that fails the intent of the request to run the test suite, even if it satisfies the letter. [07:09] Right. [07:10] Good morning [07:47] Morrrrrning [07:49] moin [07:52] hey Keybuk [07:52] morning pitti [07:57] Right, time to get the day started; it's Emacs time, baby, yeah! [07:57] M-x start-day [08:02] emacs kills IRC clients!! [08:02] that's why vim is better!!11! [08:03] :k irc [08:03] Or something. [08:12] tkamppeter: I reject your "ignore every error" uploads; this is a way too big hammer (and a wrong one, too) to fix this crash [08:33] tseliot: can you please upload fglrx-installer for maverick as well? [08:34] pitti: yes, now I can, however it was broken in maverick because it wasn't compatible with the new X (not only because of the security fix) [08:47] tseliot: ah, right; we disabled it in jockey, didn't we? [08:47] tseliot: so, not urgent then [08:47] pitti: yep, I'll revert that change when the driver is ready === apachelogger_ is now known as apachelogger === spike_ is now known as spikeWRK [09:16] ara: nice work on qa.u.c.! [09:19] pitti, thanks :) [09:30] pitti, are we making work items db for natty yet ? [09:31] apw: we don't [09:31] pitti, any idea when we're going to ? [09:31] I guess I should finally move the stuff from ~pitti to ~platform :) [09:50] hmm, looks like there is an issue with the recent apache2 security update [09:50] Three reports of bug 644853 [09:50] Launchpad bug 644853 in apache2 (Ubuntu) "apache2.2-common 2.2.14-5ubuntu8.2 failed to install/upgrade: Module reqtimeout does not exist!" [High,Confirmed] https://launchpad.net/bugs/644853 [09:52] !regression-alert ^^ [09:52] !regression-alert [09:52] cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive [09:53] mdeslaur: ^ [09:58] hm, strange [09:59] weird, did that change in the packaging? [10:00] pitti: not in the security update... I suspect a more general upgrade issue introduced in a past update [10:00] http://launchpadlibrarian.net/53953428/apache2_2.2.14-5ubuntu8.1_2.2.14-5ubuntu8.2.diff.gz looks really strange, though [10:01] yes [10:02] * ttx checks out branch [10:03] beh, no lucid-updates branch [10:06] That debdiff is wrong. There were actual changes in the upload. [10:07] None that should cause this, though. [10:07] I found these two, though: [10:07] https://bugs.edge.launchpad.net/ubuntu/+source/apache2/+bug/576255 [10:07] Launchpad bug 576255 in apache2 (Ubuntu) "can't install apache2.2-common (2.2.14-5ubuntu8)" [Low,Invalid] [10:07] https://bugs.edge.launchpad.net/ubuntu/+source/apache2/+bug/562370 [10:07] Launchpad bug 562370 in apache2 (Ubuntu Lucid) "Upgrade from 2.2.14-5ubuntu6 to 2.2.14-5ubuntu7 results in syntax error, missing module" [Critical,Fix released] [10:08] right, the 8 -> 8.2 debdiff is clean [10:10] $ dpkg -c /home/lp_archive/ubuntu/pool/main/a/apache2/apache2.2-bin_2.2.14-5ubuntu8.2_i386.deb | grep reqtimeout [10:10] -rw-r--r-- root/root 13704 2010-08-19 03:23 ./usr/lib/apache2/modules/mod_reqtimeout.so [10:10] and that package was just configured ... [10:10] if dpkg --compare-versions "$2" lt 2.2.15-1~0; [10:11] looks really weird in a package with version 2.2.14-5ubuntu8.2 [10:11] But maybe that's just me. [10:11] (from apache2.2-common.postinst) [10:14] Oh. [10:14] soren: yes, maybe the error is triggered once you pass twice that piece of code. [10:14] so the error specifically means that /etc/apache2/mods-available/reqtimeout.load doesn't exist [10:14] a2enmod decides whether a module exists based on whether a conffile exists. [10:14] ...so if the use deletes said conffile, the postinst goes boom. [10:14] Forever. [10:14] quite so [10:15] so those three users would just have played too much manually with their conffiles ? [10:16] ah! ah! [10:16] a2enmod is supposed to be run only once. And with that update, it runs twice. [10:16] ttx: I still don't see how that could cause that error [10:17] a2enmod doesn't remove the .load file [10:17] cjwatson: wouldn't /etc/apache2/mods-available/reqtimeout.load move to mods-enabled or something ? [10:17] symlink [10:17] it's not moved, no. [10:17] arh, too bad for my explanation [10:17] * ttx should just set up a reproduction. [10:17] a2enmod should be idempotent [10:18] the added a2enmod in the postinst matches the pattern of a2enmod calls above [10:18] It's the exact same bug as this: [10:18] https://bugs.edge.launchpad.net/ubuntu/+source/apache2/+bug/576255 [10:18] Launchpad bug 576255 in apache2 (Ubuntu) "can't install apache2.2-common (2.2.14-5ubuntu8)" [Low,Invalid] [10:18]