| ScottK | 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 |
|---|---|---|
| SpamapS | 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:01 |
| ScottK | SpamapS: I think that's the wrong solution. | 00:02 |
| SpamapS | its pretty much the way the web is developed these days. | 00:02 |
| SpamapS | sane or not | 00:02 |
| lifeless | SpamapS: folk can choose to publish source or not | 00:03 |
| ScottK | 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 |
| lifeless | some upstreams are insane, and need to be helped to learn about open *SOURCE* | 00:03 |
| SpamapS | 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:03 |
| lifeless | ScottK: I think that we've segued. | 00:04 |
| ScottK | OK. | 00:04 |
| lifeless | ScottK: I'm not talking about mass important pypi | 00:04 |
| lifeless | or maven.org | 00:04 |
| SpamapS | I do see Scott's point though. That we're facilitating API madness. | 00:04 |
| * ScottK was in transit for a while. | 00:04 | |
| lifeless | 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 |
| ScottK | Yes. Please don't do that. | 00:04 |
| ScottK | 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 |
| lifeless | 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 |
| ScottK | (I know you know that) | 00:05 |
| lifeless | ScottK: ack | 00:06 |
| lifeless | ScottK: so the thing is that neither the java nor python packaging policies cater for this. | 00:06 |
| ScottK | True, but we also normally only ship one version in a final release unless there are multiple source packages. | 00:06 |
| lifeless | 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 |
| ScottK | lifeless: Actually what we're trying to do with separate binary packages for Python 3 is a form of this. | 00:07 |
| lifeless | ScottK: cool; I have to admit I haven't looked really closely at that. | 00:07 |
| lifeless | ScottK: did you see my use case on the debian-python list? | 00:07 |
| ScottK | lifeless: I did, but I confess I only skimmed it. | 00:07 |
| lifeless | ScottK: fair enough | 00:07 |
| lifeless | 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:08 |
| lifeless | this is orthogonal to whether launchpad itself would be a package. | 00:09 |
| lifeless | ScottK: re: different source packages & binary packages - I would expect different source packages in this scenario | 00:10 |
| lifeless | 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 |
| lifeless | (in no particular order) | 00:11 |
| lifeless | - have packages that build with easy_install and the like be fenced off from the internet and get their requirements from apt | 00:12 |
| lifeless | - when a user is using easy_install, have it preferentially find versions from apt | 00:12 |
| lifeless | (for java s/easy_install/maven/, etc) | 00:12 |
| lifeless | 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:13 |
| ScottK | In the world of cheap VMs isn't this a bit overenginieered? | 00:17 |
| ScottK | lifeless: Why not just run a separate VM for each one and don't worry about conflicts? | 00:19 |
| lifeless | ScottK: for a developer doing development, who has the same issues, vms are not at all that cheap. | 00:22 |
| lifeless | 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:23 |
| ScottK | OK. | 00:24 |
| SpamapS | Basically, just allow debian packagers to produce binary packages that play in upstream packaging space. | 00:24 |
| SpamapS | if pypi has a way to do version requirements, allow a .deb to satisfy that... | 00:25 |
| ScottK | SpamapS: I agree with that. | 00:27 |
| ScottK | Isn't that (at least sort of) what our patched easy_install does now? | 00:27 |
| lifeless | ScottK: two key missing points: | 00:29 |
| lifeless | - packagekit integration to get extra requirements on the fly | 00:29 |
| lifeless | - packaging policy change to put the version number (or as many significant bits as we choose) in the package name. | 00:29 |
| ScottK | packagekit is pretty broken with respect to Debian packages anyway. | 00:29 |
| lifeless | sadly :( | 00:30 |
| ScottK | 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 |
| lifeless | 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:30 |
| SpamapS | lifeless: or you could package your app, and the requirement would be resolved at install time. | 00:43 |
| lifeless | SpamapS: that doesn't help with runtime determined dependencies | 00:44 |
| lifeless | SpamapS: doesn't help *us* the *packagers* | 00:44 |
| SpamapS | lifeless: ok, my brain's full.. will need to process this a bit to feel good about it. :) | 00:55 |
| === bjf is now known as bjf[afk] | ||
| ScottK | 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:36 |
| lifeless | ScottK: by runtime I'm primarily thinking about build chains that do runtime determination | 01:37 |
| lifeless | ScottK: not after-packagin runtime dependencies | 01:37 |
| ScottK | Ah. OK. | 01:37 |
| ScottK | That's a bit different. | 01:37 |
| ScottK | POX has done some stuff kind around that idea in dh_python2/3. | 01:37 |
| persia | 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 |
| persia | The first is hugely useful for packagers. The latter is potentially useful for someone. | 01:42 |
| persia | If the output of the first is compatible to the input of the second, folk share. | 01:42 |
| ScottK | Step 0 though is upstreams that are willing to maintain API/ABI compatbility or document when they change. | 01:43 |
| lifeless | 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 |
| lifeless | ScottK: its nice then they do, but we don'tneed it. | 01:44 |
| persia | 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 |
| ScottK | Just use releases as API/ABI surrogates? | 01:45 |
| lifeless | sure | 01:45 |
| persia | 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 |
| ajmitch | as long as upstreams know how to | 01:46 |
| ajmitch | instead of doing things like bumping SONAME for every upstream release, or the equivalent | 01:46 |
| persia | Right, hence the importance of making better tools available, or *any* tools/convention for things like Java. | 01:47 |
| lifeless | and we're back to changing the packaging policy to encode more data ;) | 01:48 |
| ajmitch | yeah, we had this debate yesterday in #debian-cli :) | 01:48 |
| ScottK | lifeless: I'd start with an upstream concept and see how to extend it. | 01:48 |
| ScottK | For example, what do Python eggs not have that we need? | 01:48 |
| ScottK | Or if they have it, how do we exploit it? | 01:48 |
| lifeless | ScottK: thats where I started | 01:49 |
| lifeless | ScottK: pkg_resources.require, which is a setuptools (not distutils) thing, supports versioning of dependencies | 01:49 |
| lifeless | 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 |
| ScottK | lifeless: I'd talk to POX about what he's already doing to automatically generate versioned depends in dh_python. | 01:50 |
| ScottK | {2,3} | 01:50 |
| lifeless | where does he hang ou? | 01:50 |
| persia | And we can use that to populate autodependencies (${Python:Depends} in this case) | 01:50 |
| lifeless | persia: sure, but that is orthogonal to the problem I want to solve | 01:51 |
| ScottK | lifeless: #debian-python on OFTC is best, but #ubuntu-motu also often works. He's in .pl, so likely sleeping. | 01:51 |
| persia | 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:52 |
| lifeless | persia: I think it would nice to do so. | 01:56 |
| lifeless | persia: I'm saying that that is a separate benefit to being able to even *build* such things more easily. | 01:57 |
| persia | You want build-time installation of build-deps? | 01:57 |
| lifeless | persia: and to being able to *install* concurrent versions | 01:57 |
| lifeless | 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:58 |
| persia | 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 |
| persia | We have a solution for maven. | 01:59 |
| lifeless | persia: hah. no, we don't. | 01:59 |
| persia | Have had it for > 1 year. | 01:59 |
| lifeless | doesn't scale, doesn't handle enough cases. | 01:59 |
| persia | doesn't scale how? | 01:59 |
| persia | What cases doesn't it handle? | 01:59 |
| persia | Show me bugs, or explain yourself :) | 02:00 |
| lifeless | it doesn't handle the concurrent-deps case | 02:00 |
| lifeless | OSGI apps for instance | 02:00 |
| persia | Does if the package of the dep is concurrent-install safe. | 02:00 |
| persia | That we choose not to do that much is a different thing :) | 02:00 |
| ScottK | No policy changes are needed to do so, just will to do the work. | 02:01 |
| lifeless | persia: they aren't orthogonal; the maven helper whose code I saw doesn't understand concurrent installs | 02:01 |
| lifeless | ScottK: in which case it will be easy. | 02:01 |
| ldunn | 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 |
| ldunn | . I'm guessing that's to disable testing? | 02:01 |
| ubottu | Launchpad bug 644015 in bzr (Ubuntu) "bzr package build should run the test suite" [Undecided,New] | 02:01 |
| ldunn | If so, changing 'ifneq' to 'ifeq' should enable it, right? | 02:02 |
| lifeless | 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 |
| persia | 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:02 |
| persia | lifeless, Dunno much about python, but for Java, nthykier and mjj29 have been working on that for some time. | 02:03 |
| persia | 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 |
| lifeless | ok, java policy has been updated | 02:04 |
| lifeless | Some package must also provide a symbolic link from... <- a bit fragile for upgrades, still. | 02:05 |
| lifeless | however http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html is still no-allowance-for-concurrent | 02:07 |
| ajmitch | 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:08 |
| persia | lifeless, Java policy is still work-in-progress :) For python policy, definitely talk to POX before trying to invent something. | 02:09 |
| lifeless | persia: I hear you | 02:09 |
| lifeless | 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:09 |
| persia | Then they ought go talk to debian-python :) | 02:10 |
| ScottK | Which is where barry started. | 02:10 |
| persia | Excellent. Why are we talking about it here then? It's an interesting discussion, but I'm now confused. | 02:11 |
| ScottK | Not sure, but that's only the Python bits of this anyway. | 02:11 |
| lifeless | persia: because SpamapS told me his head was exploding. | 02:12 |
| lifeless | persia: and then we started over 3 times as new people weighed in | 02:12 |
| * persia gives SpamapS a exceedingly strong head restraint, for preservation of skull | 02:13 | |
| persia | lifeless, I didn't see that much repetition in the restarts, but maybe I didn't read closely enough. | 02:13 |
| jiboumans | 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:13 |
| lifeless | jiboumans: oh hai :P | 02:14 |
| ScottK | It's going to take someone that wants it enough to champion it. | 02:14 |
| * jiboumans omnipresent | 02:14 | |
| lifeless | jiboumans: I'm looking in the long term | 02:14 |
| jiboumans | 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 |
| lifeless | jiboumans: I'm happy to help organise etc, I don't think I can put in lots of time. | 02:15 |
| lifeless | 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 | |
| persia | 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 |
| lifeless | which is in equal parts reviled and adored all the Python worlds. | 02:15 |
| jiboumans | persia: i... failed to parse that.. eggs? cheese? | 02:16 |
| jiboumans | lifeless: what i'm getting at is that if there's a best practice, we can probably integrate and codify it | 02:16 |
| jiboumans | or at least give it a shot | 02:16 |
| persia | jiboumans, Uhhh : python things to help folk shop for code? Ask someone who doesn't run and hide when confronted with pythong. | 02:17 |
| lifeless | jiboumans: yes, thats what it is | 02:17 |
| lifeless | jiboumans: the 'it all works easily stuff' is built on: | 02:18 |
| lifeless | - distribute (new shiny) | 02:18 |
| lifeless | - eggs | 02:18 |
| lifeless | they have an ongoing discussion about metadata | 02:18 |
| jiboumans | heh | 02:18 |
| lifeless | but the critical bit is that in a app/library you say | 02:18 |
| lifeless | require('foo==1.3.2') | 02:18 |
| lifeless | import foo | 02:18 |
| jiboumans | i've been through this with perl, i have a vague idea of the space :) | 02:18 |
| lifeless | and you either get an error, or foo 1.3.2 | 02:18 |
| lifeless | require('foo>=1.3.2') | 02:19 |
| lifeless | import foo | 02:19 |
| lifeless | and you might get foo 1.4 | 02:19 |
| jiboumans | 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 |
| lifeless | jiboumans: exactly | 02:19 |
| lifeless | jiboumans: which requires two things: | 02:19 |
| lifeless | - disk layout | 02:19 |
| lifeless | - a symlink or something so that a trivial script that just does | 02:19 |
| lifeless | 'import foo | 02:19 |
| lifeless | ' | 02:19 |
| lifeless | will pickup the latest shiny. | 02:19 |
| lifeless | (or most stable shiny, whatever - policy not mechanism) | 02:20 |
| jiboumans | right.. alternatives can do that | 02:21 |
| jiboumans | we'd want debian to adopt that though, or we'd carry a nasty delta | 02:21 |
| lifeless | alternatives, a meta package (supplying the symlink and current 'best' dependency) | 02:21 |
| persia | Rather, we'd want to inherit the solution from Debian, although some of us may participate in it's creation. | 02:21 |
| lifeless | pysupport could put the link in place | 02:21 |
| lifeless | it is, in principle, very simple | 02:22 |
| jiboumans | SMOP ;) | 02:22 |
| lifeless | hah, perl 6 you say? | 02:22 |
| jiboumans | smop! | 02:22 |
| persia | 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 |
| jiboumans | and mind you, there's a release of perl 6 ;) | 02:23 |
| jiboumans | persia: *nods* | 02:23 |
| jiboumans | 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 |
| jiboumans | the 'we' there is not very likely my team though given our goals | 02:24 |
| persia | Yep. We tried the other way once (dh_iconcache) and it only made it harder to reach the correct final state. | 02:24 |
| jiboumans | (the latter we, who'd create it ;)... damn it's getting late | 02:24 |
| jiboumans | food calls & | 02:26 |
| ldunn | Hmm. So, bzr tests are running, and the fails so far have been unicode encoding errors. Can these be safely ignored? | 02:28 |
| persia | No. | 02:28 |
| ldunn | …ok then. | 02:28 |
| persia | Lots of folk use Ubuntu in places where non-unicode is unreadable confusing garbage. | 02:28 |
| persia | Do they fail only on the buildds or also run locally? | 02:29 |
| lifeless | possible a stable build-dep on testtools 0.9.6 | 02:29 |
| persia | I think the buildds default to C as a locale, which complicates things. | 02:29 |
| lifeless | persia: we turn off relevant test sfor that case | 02:29 |
| ldunn | Oh? Hm. I'm just running it in pbuilder at the moment. I'm new to this :) | 02:30 |
| lifeless | persia: but yes, it could be related | 02:30 |
| persia | lifeless, OK. That's safe then. | 02:30 |
| lifeless | ldunn: you might like to chat to maxb | 02:30 |
| * persia hasn't ever seen unicode work right when LANG=C | 02:30 | |
| ldunn | alrighty | 02:31 |
| * ldunn sits around, waits for tests to finish | 02:37 | |
| === hunger is now known as Guest97520 | ||
| * ScottK is sitting around waiting for builds to start. | 02:43 | |
| bdrung_ | ScottK: for what build? | 02:49 |
| ScottK | bdrung_: PPA uploads of the new clamav release for Lucid, Karmic, Jaunty, Hardy, and Dapper. | 02:50 |
| ldunn | ... bzr build failed. >:( | 02:53 |
| mathiaz | persia: hi! | 03:40 |
| mathiaz | persia: is there a standard way to find the current JAVA_HOME? | 03:40 |
| persia | mathiaz, In what context? | 03:57 |
| MarkDude | 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 |
| mathiaz | persia: https://issues.cloudera.org/browse/DISTRO-2 | 03:57 |
| mathiaz | persia: ^^ trying to support building with default-jdk *and* sun-java-jdk | 03:58 |
| mathiaz | persia: depending on which one is installed | 03:58 |
| mathiaz | persia: JAVA_HOME will be different IIUC | 03:58 |
| persia | 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 |
| mathiaz | persia: it seems that /usr/lib/jvm/default-java/ won't point to the sun-jdk if installed | 03:58 |
| persia | Yes, JAVA_HOME would differ. Why would you want to support building with sun-jdk? | 03:58 |
| mathiaz | persia: because that's what upstream strongly recommends | 04:00 |
| MarkDude | 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:00 |
| persia | Right, looking at recent discussions, it seems we're trying to move away from any expectation or dependence on JAVA_HOME | 04:01 |
| persia | MarkDude, Could you explain more about the topic and audience? I may be able to provide more targeted advice. | 04:01 |
| MarkDude | It will be primarily an MS crowd | 04:02 |
| MarkDude | not all tho | 04:02 |
| MarkDude | Silverlight, etc and Iphone | 04:02 |
| MarkDude | But some Android devs also | 04:02 |
| persia | 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:03 |
| persia | 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:04 |
| MarkDude | 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:05 |
| MarkDude | That would make sense- but I would use that info after - when talking to a specific person | 04:06 |
| MarkDude | Thank you developers, you folks ROCK! | 04:06 |
| persia | 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:06 |
| persia | 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:07 |
| persia | mathiaz, For extra points, remind upstream of the upcoming EOL date for sun-java, and that even Oracle primarily extends openjdk these days. | 04:08 |
| mathiaz | persia: yop - that's what I'm saying to upstream | 04:15 |
| mathiaz | persia: it seems that they're running into issues when using openjdk | 04:16 |
| mathiaz | persia: I'll look at the debian/rules again | 04:16 |
| mathiaz | persia: thanks again for your input on JAVA_HOME | 04:16 |
| persia | OpenJDK isn't bug free :) That said, when issues are encountered, upstream is usually happy to get patches. | 04:16 |
| persia | Sorry I didn't have more useful news. JAVA_HOME was all the rage some time back. | 04:17 |
| ldunn | Blugh. I'm lost with these tests | 04:19 |
| spiv | ldunn: for the bzr package? | 04:19 |
| ldunn | yeah | 04:19 |
| spiv | Pastebin the failures? | 04:19 |
| ldunn | Err. They're going way past my scrollback in gnome-terminal. Does pbuilder keep logs somewhere? | 04:20 |
| spiv | 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 |
| ldunn | 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:22 |
| * ldunn re-runs pbuilder and collects failures as they come | 04:23 | |
| ldunn | heh, I'm not going to be able to catch all of them | 04:29 |
| ldunn | http://ubuntu.pastebin.com/tYxTJ9i8 spiv, that's more or less what's come up so far, up to ~2500/25000 | 04:30 |
| spiv | It's not possible to redirect the output with > or tee? | 04:30 |
| ldunn | uh. Let me check | 04:30 |
| ldunn | there we go. | 04:32 |
| persia | pbuilder *does* make logs (although I don't use it, so don't know where). Check the docs, and save yourself hassles. | 04:33 |
| ldunn | bah, --logfile. :D | 04:34 |
| ldunn | ... ok, so... that... didn't really seem to work. | 05:05 |
| ldunn | Unless it doesn't store the log in the pwd | 05:05 |
| ldunn | In which case... here's a few more failures http://ubuntu.pastebin.com/ZgxFLrBn | 05:07 |
| ScottK | ldunn: You need to do --logfile [path to logfile from pwd including name] | 05:12 |
| ScottK | i.e. --logfile log | 05:12 |
| ldunn | That's what I have | 05:12 |
| ldunn | sudo pbuilder build bzr_2.2.0-1ubuntu1.dsc --logfile pbuilder.log | 05:12 |
| ScottK | Needs to go after build and before the .dsc | 05:13 |
| ScottK | pbuilder doesn't look after the .dsc | 05:13 |
| ldunn | ... oh! | 05:13 |
| ldunn | *that's* more like it. Thanks :) | 05:13 |
| * ldunn waits another half hour | 05:13 | |
| ScottK | You're welcome. | 05:14 |
| hyperair | ldunn: you might like to try sbuild, it works much faster ;-) | 05:14 |
| hyperair | especially those aufs + tmpfs builds | 05:14 |
| ldunn | oh? I'll investigate | 05:15 |
| hyperair | ;-) | 05:15 |
| nigelb | james_w: ahoy there! You're doing package training on Thursday - just a reminder :) | 05:21 |
| === almaisan-away is now known as al-maisan | ||
| ldunn[laptop] | Ok! Finally. http://pastebin.com/kVa8N0Pa | 06:33 |
| === amitk-afk is now known as amitk | ||
| ldunn[laptop] | 5750 lines... o.o | 06:36 |
| persia | ldunn, Yep, but only the test failures are interesting: most of the rest is just context. | 06:36 |
| ldunn[laptop] | Yeah | 06:37 |
| ldunn[laptop] | I figured I may as well paste it all in case there's some other info that might help | 06:37 |
| persia | 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:37 |
| ldunn[laptop] | 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 | |
| persia | There's some argument that preserves it (again, I have no idea which) | 06:38 |
| persia | If there's no way to preserve it, that's a bug in pbuilder | 06:38 |
| ldunn[laptop] | yeah | 06:38 |
| persia | 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:40 |
| spiv | persia: bzr includes the log entries with the failures | 06:45 |
| persia | spiv, Those little 4-5 line bits are the entirely of the test failure output? | 06:45 |
| spiv | Yes, although some are much longer! | 06:46 |
| spiv | See e.g. the log starting at line 4092 | 06:46 |
| persia | Tracebacks are interesting, but I have to admit, I really appreciate exception handlers that try to explain what went wrong for test failures. | 06:46 |
| spiv | Yes, me too :) | 06:47 |
| spiv | Some tests are much better than others at that... | 06:47 |
| persia | 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:48 |
| ldunn[laptop] | So, I guess some of these tests are failing because the pbuilder env isn't set up for unicode? | 06:49 |
| persia | ldunn, To put that another way, perhaps the tests are making unwarranted assumptions about the environment in which they are run. | 06:50 |
| spiv | Well, bzr's test suite is supposed to cope with LANG=C. | 06:50 |
| ldunn[laptop] | hmmm. | 06:50 |
| spiv | (By skipping tests, if necessary) | 06:50 |
| ldunn[laptop] | It skipped 246 unicode-related tests, apparently | 06:51 |
| persia | 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 |
| ldunn[laptop] | This is true. | 06:51 |
| persia | Another option would be to adjust build-depends, force LANG=${something-else}, and then run the tests. | 06:52 |
| persia | Either way, looks like a bug in the test suite (the test should have been skipped if it depended on LANG != C ) | 06:52 |
| ldunn[laptop] | Hm. :/ | 06:53 |
| spiv | That said, at least the bzrlib.tests.blackbox.test_alias.TestAlias.test_unicode_alias failure is reproducible with LANG=C | 06:54 |
| spiv | So it appears our test suite has some bugs here :/ | 06:55 |
| ldunn[laptop] | 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 | |
| spiv | At the moment, yes :( | 06:56 |
| spiv | Please attach that log to the relevant bug, if you haven't already. | 06:57 |
| ldunn[laptop] | I haven't, I'll do that | 06:57 |
| persia | ldunn, Based on the meeting last night, I believe the test suite is required to be enabled on that package. | 06:57 |
| spiv | I'll see how easy it is to fix these failures, it's probably not hard. | 06:57 |
| persia | new microrelease coming up ? :) | 06:57 |
| spiv | 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 |
| persia | (might wait until the test suite passes in a buildd environment before placing the final tag) | 06:58 |
| spiv | *nod* | 06:58 |
| spiv | Hmm, I notice python-paramiko isn't installed in that environment... that's good, paramiko has a bug that causes a test failure ;) | 06:59 |
| spiv | (I've submitted a patch to upstream and to the bug for the ubuntu package, but no response yet) | 07:00 |
| persia | 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:00 |
| spiv | Right. | 07:01 |
| spiv | 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 |
| spiv | But I expect that would be pretty tricky to do. | 07:02 |
| persia | 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:04 |
| spiv | Well, we already have http://babune.ladeuil.net:24842/ | 07:06 |
| spiv | Which currently exercises our trunk on a variety of platforms | 07:07 |
| ldunn[laptop] | I note it failed on maverick :P | 07:07 |
| spiv | (In addition to merges to trunk and the stable branches having to go through PQM, which runs 'make check') | 07:07 |
| persia | That's probably the right place to exercise it in a variety of environments on each platform then. | 07:07 |
| * persia has a 5 line patch that passes "make check" and causes complete system failure for all users | 07:08 | |
| spiv | ldunn[laptop]: failed to fetch the code due to a config issue: | 07:08 |
| spiv | http://babune.ladeuil.net:24842/job/selftest-maverick/lastFailedBuild/console | 07:08 |
| ldunn[laptop] | oh. Alright, heh | 07:08 |
| ldunn[laptop] | Ah, so I see. | 07:08 |
| spiv | persia: Me too, how about we apply it to the packaging? ;) | 07:09 |
| persia | Please no :) | 07:09 |
| persia | I think that fails the intent of the request to run the test suite, even if it satisfies the letter. | 07:09 |
| spiv | Right. | 07:09 |
| pitti | Good morning | 07:10 |
| Keybuk | Morrrrrning | 07:47 |
| ldunn | moin | 07:49 |
| pitti | hey Keybuk | 07:52 |
| Keybuk | morning pitti | 07:52 |
| Keybuk | Right, time to get the day started; it's Emacs time, baby, yeah! | 07:57 |
| ldunn | M-x start-day | 07:57 |
| pitti | emacs kills IRC clients!! | 08:02 |
| pitti | that's why vim is better!!11! | 08:02 |
| ldunn | :k irc | 08:03 |
| ldunn | Or something. | 08:03 |
| pitti | 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:12 |
| pitti | tseliot: can you please upload fglrx-installer for maverick as well? | 08:33 |
| tseliot | 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:34 |
| pitti | tseliot: ah, right; we disabled it in jockey, didn't we? | 08:47 |
| pitti | tseliot: so, not urgent then | 08:47 |
| tseliot | pitti: yep, I'll revert that change when the driver is ready | 08:47 |
| === apachelogger_ is now known as apachelogger | ||
| === spike_ is now known as spikeWRK | ||
| pitti | ara: nice work on qa.u.c.! | 09:16 |
| ara | pitti, thanks :) | 09:19 |
| apw | pitti, are we making work items db for natty yet ? | 09:30 |
| pitti | apw: we don't | 09:31 |
| apw | pitti, any idea when we're going to ? | 09:31 |
| pitti | I guess I should finally move the stuff from ~pitti to ~platform :) | 09:31 |
| ttx | hmm, looks like there is an issue with the recent apache2 security update | 09:50 |
| ttx | Three reports of bug 644853 | 09:50 |
| ubottu | 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:50 |
| ttx | !regression-alert ^^ | 09:52 |
| ttx | !regression-alert | 09:52 |
| ubottu | 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:52 |
| ttx | mdeslaur: ^ | 09:53 |
| ttx | hm, strange | 09:58 |
| pitti | weird, did that change in the packaging? | 09:59 |
| ttx | pitti: not in the security update... I suspect a more general upgrade issue introduced in a past update | 10:00 |
| pitti | http://launchpadlibrarian.net/53953428/apache2_2.2.14-5ubuntu8.1_2.2.14-5ubuntu8.2.diff.gz looks really strange, though | 10:00 |
| ttx | yes | 10:01 |
| * ttx checks out branch | 10:02 | |
| ttx | beh, no lucid-updates branch | 10:03 |
| soren | That debdiff is wrong. There were actual changes in the upload. | 10:06 |
| soren | None that should cause this, though. | 10:07 |
| soren | I found these two, though: | 10:07 |
| soren | https://bugs.edge.launchpad.net/ubuntu/+source/apache2/+bug/576255 | 10:07 |
| ubottu | Launchpad bug 576255 in apache2 (Ubuntu) "can't install apache2.2-common (2.2.14-5ubuntu8)" [Low,Invalid] | 10:07 |
| soren | https://bugs.edge.launchpad.net/ubuntu/+source/apache2/+bug/562370 | 10:07 |
| ubottu | 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:07 |
| ttx | right, the 8 -> 8.2 debdiff is clean | 10:08 |
| cjwatson | $ dpkg -c /home/lp_archive/ubuntu/pool/main/a/apache2/apache2.2-bin_2.2.14-5ubuntu8.2_i386.deb | grep reqtimeout | 10:10 |
| cjwatson | -rw-r--r-- root/root 13704 2010-08-19 03:23 ./usr/lib/apache2/modules/mod_reqtimeout.so | 10:10 |
| cjwatson | and that package was just configured ... | 10:10 |
| soren | if dpkg --compare-versions "$2" lt 2.2.15-1~0; | 10:10 |
| soren | looks really weird in a package with version 2.2.14-5ubuntu8.2 | 10:11 |
| soren | But maybe that's just me. | 10:11 |
| soren | (from apache2.2-common.postinst) | 10:11 |
| soren | Oh. | 10:14 |
| ttx | soren: yes, maybe the error is triggered once you pass twice that piece of code. | 10:14 |
| cjwatson | so the error specifically means that /etc/apache2/mods-available/reqtimeout.load doesn't exist | 10:14 |
| soren | a2enmod decides whether a module exists based on whether a conffile exists. | 10:14 |
| soren | ...so if the use deletes said conffile, the postinst goes boom. | 10:14 |
| soren | Forever. | 10:14 |
| cjwatson | quite so | 10:14 |
| ttx | so those three users would just have played too much manually with their conffiles ? | 10:15 |
| ttx | ah! ah! | 10:16 |
| ttx | a2enmod is supposed to be run only once. And with that update, it runs twice. | 10:16 |
| cjwatson | ttx: I still don't see how that could cause that error | 10:16 |
| cjwatson | a2enmod doesn't remove the .load file | 10:17 |
| ttx | cjwatson: wouldn't /etc/apache2/mods-available/reqtimeout.load move to mods-enabled or something ? | 10:17 |
| cjwatson | symlink | 10:17 |
| cjwatson | it's not moved, no. | 10:17 |
| ttx | arh, too bad for my explanation | 10:17 |
| * ttx should just set up a reproduction. | 10:17 | |
| cjwatson | a2enmod should be idempotent | 10:17 |
| cjwatson | the added a2enmod in the postinst matches the pattern of a2enmod calls above | 10:18 |
| soren | It's the exact same bug as this: | 10:18 |
| soren | https://bugs.edge.launchpad.net/ubuntu/+source/apache2/+bug/576255 | 10:18 |
| ubottu | Launchpad bug 576255 in apache2 (Ubuntu) "can't install apache2.2-common (2.2.14-5ubuntu8)" [Low,Invalid] | 10:18 |
| cjwatson | albeit ones for a fairly old version | 10:18 |
| ttx | cjwatson: except that the above ones are much more restrictive in versioning. | 10:18 |
| cjwatson | sure, but nevertheless | 10:18 |
| soren | The user reporting it just failed to mention that he got the error on upgrade, so it was marked Invalid. | 10:18 |
| soren | infinity probabaly assuming that the user just tried manually doing "a2enmod reqtimeout" and having removed the corresponding .load file had caused it himself. | 10:19 |
| cjwatson | certainly seems like || true would be a sufficient fix | 10:19 |
| soren | *nod* | 10:19 |
| cjwatson | and that the version guard should be fixed for the backport to lucid | 10:19 |
| soren | It's rather surprising this never happened before. | 10:20 |
| soren | There's a bunch of a2enmod calls in that postinst. | 10:20 |
| soren | There's probably a howto somewhere on the internetz telling people to delete that file. | 10:20 |
| soren | *sigh* | 10:20 |
| lifeless | soren: there's a howto for every bad idea ;P | 10:20 |
| cjwatson | having the list of available modules effectively come from /etc isn't really a great design | 10:21 |
| === ldunn[laptop] is now known as ldunn | ||
| soren | lifeless: Some day we should clear out the internet and start over. | 10:21 |
| ttx | soren: and appoint you as BMP reviewer, maybe | 10:22 |
| soren | ttx: BMP? | 10:22 |
| ttx | branch merge proposal | 10:22 |
| soren | Oh. | 10:22 |
| ttx | "Internet core committer" | 10:22 |
| soren | Yeah, keeping the internet in bzr sounds like a good idea. | 10:22 |
| soren | I can think of a few pages, I'd like to run "bzr blame" on. | 10:23 |
| lifeless | lol | 10:23 |
| ttx | soren: I see which precise one you mean. | 10:23 |
| soren | ttx: I'm sure you do :) | 10:23 |
| * soren shakes his fist in the Internet's general directoin | 10:23 | |
| * ttx discards the regression alert on the "Internet's fault" pile | 10:25 | |
| ttx | sorry for the noise chaps. Blame those 3 concurrent bug reports. | 10:26 |
| === hanska is now known as dapal | ||
| tkamppeter | pitti, what about only ignoring IOError (this upstream has introduced a little later) for bug 618017? | 10:50 |
| ubottu | Launchpad bug 618017 in splix (Ubuntu) "openprinting-ppds crashed with IOError in ls()" [High,Triaged] https://launchpad.net/bugs/618017 | 10:50 |
| pitti | tkamppeter: you can do that, but only at the actual print statement, not for the entire program | 10:50 |
| pitti | if it fails to open an output file, it should fail properly | 10:51 |
| tkamppeter | pitti, this program is rather simple. It only takes data which it contains by itself (the compressed PPDs are embedded in the program) and it does nothing else than putting the data out to stdout. It does not open any files. | 10:56 |
| didrocks | ev: hey, before you release the next ubiquity version, if you can just look at my merge proposal (bump dep on libindicator for ABI change). Thanks! | 10:57 |
| ev | didrocks: absolutely | 10:57 |
| pitti | tkamppeter: well, but hiding each and every error in it will make debugging a pain; you won't even know that it's this program which is at fault then | 10:57 |
| didrocks | ev: thanks a lot :) the new libindicator-dev will be available within the day | 10:58 |
| pitti | didrocks: wow, ubiquity is using indicators now? | 10:58 |
| ogra_ac | pitti, in the new minimal panel :) | 10:58 |
| didrocks | pitti: yeah, in the "install only" mode | 10:59 |
| tkamppeter | pitti, normally the program is called by CUPS and the output is piped into another program. The other program does not necessarily read all the output of the PPD archive and closes before the archive program finishes. This situation should not trigger Apport. | 10:59 |
| didrocks | pitti: you have a top panel now | 10:59 |
| ogra_ac | didrocks, pitti, or in oem-config mode | 11:00 |
| ogra_ac | its really slick and small | 11:00 |
| pitti | tkamppeter: ah, right; so the print should catch that IOError and cleanly exit the program then | 11:00 |
| ogra_ac | we should use it everywhere ! | 11:00 |
| pitti | tkamppeter: this at least explains the pipe error | 11:00 |
| didrocks | ogra_ac: yeah, it's great :) | 11:01 |
| apparle | hello guys, is there any API on linux similar to page 73 of this http://www.aquaphoenix.com/hardware/ledlamp/reference/synaptics_touchpad_interfacing_guide.pdf | 11:03 |
| apparle | or if you know a better channel to ask that, please forward me there | 11:04 |
| tkamppeter | pitti, I can do one of two things: | 11:07 |
| tkamppeter | pitti, 1. I use the upstream version of pyppd, as usually one should use programs as they come from upstream. It catches only KeyboardInterrupt and IOError but for the whole program. | 11:09 |
| tkamppeter | pitti, 2. I can consider the upstream program as not acceptable (reporting a bug to upstream), letting only KeyboardInterrupt being caught for the whole program and IOError only for the two print statements for the list and for the PPDs. | 11:11 |
| tkamppeter | pitti, WDYT? | 11:11 |
| pitti | tkamppeter: hm, I think use 1. and report a bug to them to only catch the IOError on the print | 11:12 |
| tkamppeter | pitti, OK. I will do so. | 11:12 |
| cjwatson | didrocks: FYI the Build-Depends change needs to be done in d-i/update-control | 11:13 |
| cjwatson | (in addition) | 11:13 |
| cjwatson | actually I should just say that in the merge proposal, shouldn't I | 11:13 |
| didrocks | cjwatson: really? I don't see them as rdepends of libindicator0 | 11:14 |
| didrocks | oh, the path | 11:14 |
| * didrocks is tired, sorry :) | 11:14 | |
| didrocks | cjwatson: ok, fixing that ;) | 11:14 |
| didrocks | cjwatson: merge reproposed, sorry for not seeing it | 11:17 |
| pitti | cjwatson: btw, I processed unapproved this morning (and now again); light-themes, compiz, and telepathy require more input, but I can't self-approve my udev and p-common uploads | 11:18 |
| === amitk is now known as amitk-afk | ||
| tkamppeter | pitti, new version of foomatic-db uploaded. Please check and tell me whether it is OK, after that I will do the rest. | 11:42 |
| tkamppeter | pitti, the pyppd there is now unpatched upstream. Functional change is only the "try: ... except: ...", all the noise in the debdiff is doc files and version number change. | 11:43 |
| pitti | tkamppeter: perhaps you could replace "apport popup" with "crash on SIGPIPE" | 11:46 |
| pitti | (but don't worry about that for foomatic-db) | 11:46 |
| pitti | tkamppeter: looks fine to me, accepting | 11:48 |
| ogra | mvo, sw-center change works (enables the PPA), but i get an "untrusted packages" error when trying to install from the PPA | 12:03 |
| mvo | ogra: thanks, could you file a bug please? | 12:10 |
| ogra | mvo, will do | 12:11 |
| ogra | any specific logs you want ? | 12:11 |
| === MacSlow is now known as MacSlow|lunch | ||
| hrw | hi | 12:15 |
| mvo | ogra: no, I think I know what the problem is | 12:15 |
| mvo | ogra: just the bug so that I can target it | 12:15 |
| ogra | mvo, k | 12:16 |
| ogra | filing as we speak :) | 12:16 |
| mvo | thanks! | 12:16 |
| ogra | mvo, bug 645120 for you | 12:22 |
| ubottu | Launchpad bug 645120 in software-center (Ubuntu Maverick) "using an apturl source that also enables a PPA pops up an "Untrusted Packages" message when installing from the PPA" [High,New] https://launchpad.net/bugs/645120 | 12:22 |
| === dmart_ is now known as dmart | ||
| ogra | mvo, oh ... i didnt click past the error message yet, seems hitting the install button is a no-op | 12:28 |
| ogra | is that a separate bug or related ? | 12:28 |
| tkamppeter | pitti, hplip is uploaded. | 12:31 |
| mvo | ogra: please add it to the bugreport (the info) | 12:32 |
| ogra | ok | 12:33 |
| === amitk-afk is now known as amitk | ||
| ogra | done | 12:34 |
| mvo | ev: I'm doing a fresh install now and selected "use entire disk" but in the confirmation screen I have only a ext4 now, no mention of a swap device. is that intentional (information most users will not care about). or did it for some reason not create a swap device? | 12:36 |
| * mvo is trying to reproduce the apt-cdrom bug that keybuk mentioned yesterday | 12:36 | |
| Keybuk | yeah, sorry, I oddly haven't been able to reproduce now it's all installed | 12:36 |
| Keybuk | what I originally did: | 12:36 |
| ogra | reinstall ! | 12:36 |
| ogra | :) | 12:36 |
| Keybuk | installed from CD-ROM, no network connection | 12:36 |
| mvo | Keybuk: no worries, I wanted to see the new installer anyway (its shinny!) | 12:37 |
| mvo | Keybuk: desktop install or alternate install? | 12:37 |
| Keybuk | did apt-cdrom add, apt-get update (which complained obv. about no network) then apt-get install bcmwl-kernel-source | 12:37 |
| Keybuk | desktop | 12:37 |
| Keybuk | then apt complained that it couldn't find the files | 12:37 |
| Keybuk | it gave the name of the CD exactly as it was | 12:37 |
| Keybuk | and it gave the paths exactly as they were on CD | 12:37 |
| Keybuk | CD was mounted at /media/apt | 12:37 |
| Keybuk | ogra: it was rather too much of a fight to get things installed in the first place! | 12:38 |
| ogra | Keybuk, yeah ... | 12:39 |
| * ogra has no ubuntu probelms anymore since he bought an armel netbook :) | 12:39 | |
| mvo | Keybuk: so it was the desktop-install cd? | 12:39 |
| Keybuk | it was | 12:39 |
| mvo | thanks | 12:39 |
| * mvo is doing the install now | 12:39 | |
| mvo | ev: its really shinny, kudos | 12:39 |
| Keybuk | right, lunch - grab me later or tomorrow if you can't replicate and I'll try and help out | 12:40 |
| mvo | Keybuk: bon appetite | 12:41 |
| ogra | mvo, hmm ... now i'm trying to install oo.o here, seemingly using the metapackage (sw-center says: openoffice.org office suite in the UI) but that only offers me an "update now" button, installing one of the components works though | 12:44 |
| mvo | ogra: oh, i check | 12:52 |
| ogra | mvo, seems i get the metapackage offered in "addon packages" in the writer screen | 12:53 |
| * ogra wonders if thats just a wanted design i'm to dumb to understand | 12:53 | |
| mvo | ogra: that OOo is not there is a bug | 12:54 |
| === al-maisan is now known as almaisan-away | ||
| ogra | mvo, ah, k, i was doubting my skills to understand mpt's decisions :) | 12:55 |
| mvo | you are not a target user ;) | 12:55 |
| mpt | wait what? | 12:55 |
| mvo | ogra: but seriously, this one is a bug | 12:55 |
| mvo | ogra: I think a bug in the meta-data to be precise | 12:56 |
| mvo | ogra: is that on i386?amd64?*cough* arm? | 12:56 |
| ogra | mvo, *cough* arm indeed :) | 12:57 |
| mpt | There shouldn't be an "Update Now" button anywhere afaik | 12:57 |
| mvo | ogra: ohhhhh | 12:57 |
| ogra | but writer installs just fine | 12:57 |
| ogra | oo.o finished building yesterday | 12:58 |
| ogra | so data should be available | 12:58 |
| mvo | mpt: it appears if there is meta-data for a item but we have no package for it, it usually means that /var/lib/apt/lists is empty for some reason | 12:58 |
| mvo | mpt: and a update fixes the issue | 12:58 |
| mpt | ah, I see | 12:58 |
| mvo | mpt: but apparently ogra has hit a bug on arm | 12:58 |
| ogra | \o/ | 12:59 |
| ogra | another one :) | 12:59 |
| mvo | ogra: what does apt-cache policy openoffice.org give you? | 12:59 |
| ogra | lets see | 12:59 |
| mvo | ogra: dude, if you find more bugs, you will have to rotate into QA! | 13:00 |
| ogra | installed and candidate say (none), rest is empty | 13:00 |
| ogra | mvo, nah, rotate more QA ppl to arm so i dont have to search them :) | 13:01 |
| mvo | ogra: hm, why is this? is the package not availalbe for arm at all? | 13:01 |
| * ogra cant ssh in currently and a writer install is running, i need to test OO.o for doko ... so i have to copy/brain/paste here | 13:01 | |
| mvo | ogra: at least LP says it is | 13:01 |
| ogra | yes, it is | 13:01 |
| mvo | but why does apt not know about it then :) ? | 13:02 |
| ogra | no idea | 13:02 |
| ogra | does the apturl stuff run an apt-get update if it enables them ? | 13:03 |
| ogra | s/them/PPAs/ | 13:03 |
| ogra | though the package cache should be up to date, the image was rolled this morning ... (3h ago) | 13:04 |
| === dendrobates is now known as dendro-afk | ||
| bullgard4 | What is an »unseeded package«? As in "ubuntu-release delegations for unseeded packages in universe/multiverse" | 13:14 |
| micahg | bullgard4: usually packages without a Task | 13:15 |
| bullgard4 | micahg: Thank you. | 13:16 |
| ev | mvo: thanks! Very much appreciated. | 13:23 |
| === almaisan-away is now known as al-maisan | ||
| cjwatson | mvo: Keybuk's problem might have been an installer bug instead - just uploaded a backport of a change I made to Debian a couple of days ago to fix a similar problem | 13:31 |
| mvo | ev: I just saw that a swap device is created so my earlier question is solved | 13:31 |
| mvo | cjwatson: aha, ok. what branch should I look at to see the diff? | 13:32 |
| === MacSlow|lunch is now known as MacSlow | ||
| cjwatson | mvo: lp:~ubuntu-core-dev/base-installer/ubuntu | 13:36 |
| mvo | thanks | 13:36 |
| mvo | cjwatson: that seems to be a bit confusing, I check why apt is requiring both | 13:37 |
| mvo | (confusing on apts side) | 13:37 |
| ogra | mvo, hmm, so even after apt-get update i dont see oo.o meta in apt-cache policy | 13:48 |
| ogra | mvo, http://paste.ubuntu.com/498447/ | 13:49 |
| * ogra has ssh now | 13:49 | |
| mvo | ogra: I can't see it in the packages file for armel on ports | 13:52 |
| ogra | weird | 13:53 |
| ogra | publisher hiccup ? | 13:53 |
| mvo | possible | 13:53 |
| wgrant | Unlikely. | 13:53 |
| * wgrant looks. | 13:53 | |
| cjwatson | ogra: you don't have universe enabled | 13:54 |
| cjwatson | openoffice.org | 1:3.2.1-6ubuntu2 | maverick/universe | amd64, armel, i386, powerpc | 13:54 |
| cjwatson | the metapackage has been in universe since lucid (I don't know why) | 13:54 |
| cjwatson | if it needs to be re-promoted, somebody should seed it | 13:55 |
| mvo | I can do that, I need to seed ubuntu-extras-keyring anyway | 13:55 |
| ogra | cjwatson, oh, weird | 13:56 |
| ogra | thanks ! | 13:56 |
| salty-horse | hey. I'd like to get this tiny bugfix in the cairo2 package -- should I just file a bug pointing to it? https://bugs.freedesktop.org/show_bug.cgi?id=30115 | 13:56 |
| ubottu | Freedesktop bug 30115 in general "cairo_device_type_t enum has a trailing comma" [Normal,Resolved: fixed] | 13:56 |
| mvo | cjwatson: can I ask for a quick advice? should I seed it into desktop ? or rather platform? I think desktop is better as we probably leave it out on the server, but I don't have a strong opinion. as it only contains new stuff it should not harm much to have it as a recommends on ubuntu-standard | 13:56 |
| ogra | cjwatson, mvo, hmm, shouldnt sw-center have told me that its in universe though ? (and offer to enable it) | 13:58 |
| cjwatson | mvo: I think ubuntu.maverick/supported-desktop-extra, given that there's already oo.o stuff there | 13:58 |
| mvo | ogra: it should have, that is a bug in the meta-data, I add a test for this | 13:58 |
| ogra | ok | 13:59 |
| ogra | thats what i thought | 13:59 |
| mvo | cjwatson: I meant where to seed "ubuntu-extras-keyring" :) | 13:59 |
| cjwatson | oh | 14:01 |
| cjwatson | mvo: my gut feel would be platform.maverick/desktop-common | 14:01 |
| mvo | cjwatson: yeah, that makes sense, thanks | 14:03 |
| mvo | hm, it looks like openoffice.org depends on some other universe stuff (like openoffice.org-filter-mobiledev | 14:07 |
| ogra | imho we dont need it seeded in main | 14:13 |
| mvo | ogra: ok, I fix the meta-data | 14:15 |
| ogra | (we dont use it on armel at all btw) | 14:16 |
| ogra | (in the images) | 14:16 |
| === badipod_ is now known as badipod | ||
| hrw | I have good news - armel cross compiler 4.5 landed in ubuntu (gcc-4.4 is on a way) | 14:44 |
| === bjf[afk] is now known as bjf | ||
| tkamppeter | pitti, all new packages for bug 618017 uploaded. | 15:13 |
| \sh | how can someone disable on lucid the write_net_rules script to overwrite self written /etc/udev/rules.d/70-persistent-net.rules file? during jaunty this behaviour was different somehow.. | 15:13 |
| ubottu | Launchpad bug 618017 in splix (Ubuntu) "openprinting-ppds crashed with IOError in ls()" [High,Fix committed] https://launchpad.net/bugs/618017 | 15:13 |
| === hanska is now known as dapal | ||
| \sh | oh damn....the format changed...halleluja | 15:18 |
| ogra | ScottK, in case you have a bored minute i'd like to draw youre attention to bug 645200 :) | 15:23 |
| ubottu | Launchpad bug 645200 in systemtap (Ubuntu) "please sync systemtap 1.3 from debian experimental" [Undecided,New] https://launchpad.net/bugs/645200 | 15:23 |
| === hanska is now known as dapal | ||
| === ivoks-afk is now known as ivoks | ||
| LLStarks | kenvandine, i found a glaring ambiance/radiance bug not fixed by your new release. | 15:58 |
| LLStarks | should i mark its bug for uife? | 15:58 |
| kenvandine | LLStarks, file a bug for sure... i know very little about the theme :) | 15:59 |
| kenvandine | but i can make sure someone looks at it asap | 15:59 |
| LLStarks | https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/622284 | 16:00 |
| ubottu | Launchpad bug 622284 in light-themes (Ubuntu) "font blur on some buttons in beta theme" [Medium,Confirmed] | 16:00 |
| LLStarks | oh wow | 16:01 |
| LLStarks | mark already jumped on it | 16:01 |
| LLStarks | i feel honored. | 16:02 |
| ev | mvo: http://paste.ubuntu.com/498545/ - interested? | 16:05 |
| jcastro | charlie-tca: https://wiki.ubuntu.com/UbuntuOpenWeek/Timetable can you pass that along to xubuntu folks? Sessions wanted! | 16:06 |
| mvo | ev: yes, checking | 16:06 |
| ev | that's roughly: fakeroot fakechroot -s debootstrap --variant=fakechroot maverick maverick; fakeroot fakechroot -s chroot maverick; apt-get -y install ubiquity ubiquity-frontend-gtk; apt-get -f install | 16:06 |
| charlie-tca | Be happy to.Thanks for letting us know | 16:07 |
| ev | I noticed you fixed a similar bug relatively recently, in ubuntu1, not sure if this is related though | 16:07 |
| mvo | ev: so that is from debootstrap? | 16:08 |
| ev | correct | 16:08 |
| ev | well | 16:09 |
| ev | sorry | 16:09 |
| ev | the error is not from bootstrap | 16:09 |
| ev | that succeeds after it retries a few times | 16:09 |
| ev | the error is from chrooting into the presumably successfully created chroot and trying to install ubiquity | 16:09 |
| ev | debootstrap returns 0 | 16:10 |
| \sh | oh I'm stucked now...I'm writing my own 70-persistent-net.rules file, and in jaunty write_net_rules never touched it when it was there..now on lucid, it always replaces my rules with its own...which is totally different behaviour, even chmod 444 of this file doesn't prevent udev to overwrite | 16:41 |
| JanC | cjwatson: it seems like the btrfs patch you added to GParted causes it to crash - https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/609447 | 16:43 |
| ubottu | Launchpad bug 609447 in gparted (Ubuntu) "gpartedbin crashed with signal 5 in Glib::exception_handlers_invoke()" [Medium,Confirmed] | 16:43 |
| cjwatson | psurbhi: ^- that was your btrfs patch for gparted - could you look at that, please? | 16:44 |
| === dendro-afk is now known as dendrobates | ||
| RoAkSoAx | cjwatson: you are the one who generates the cdimage .manifest-daily right :)? | 16:47 |
| === ivoks is now known as ivoks-afk | ||
| cjwatson | RoAkSoAx: scripts that I operate do it, yes | 16:49 |
| cjwatson | (though I am but one of the operators these days) | 16:50 |
| RoAkSoAx | cjwatson: Well I think there might be a mistake with this entry: " ubuntu maverick /kubuntu-mobile/daily-live/current/maverick-mobile-i386.iso 701138944"sionce it is pointing a kubuntu ISO instead of an ubuntu one :) | 16:51 |
| slangasek | pitti: 618017> the packages seem to have been accepted, in spite of your nack in the bug log - did you and tkamppeter work this out off-line? | 16:51 |
| pitti | slangasek: yes, I rejected the original ones, and he uploaded fixed versinos | 16:53 |
| slangasek | pitti: oh; the changelogs still all refer to try: main() except: pass | 16:53 |
| pitti | slangasek: really? where? | 16:54 |
| pitti | hplip (3.10.6-1ubuntu10) maverick; urgency=low | 16:54 |
| pitti | * debian/local/pyppd/pyppd/: Updated to pyppd 0.4.9, to suppress runtime | 16:54 |
| pitti | error tracebacks by putting a "try: ... except ...: pass" construct around | 16:54 |
| pitti | the main function call. This avoids Apport pop-ups when the execution of the | 16:54 |
| pitti | self-extracting compressed PPD file archives gets stopped by the calling | 16:54 |
| pitti | process (LP: #618017). | 16:54 |
| pitti | slangasek: those were the ones I've seen | 16:54 |
| pitti | slangasek: I think there was one package which got accepted before, something with p* | 16:54 |
| pitti | slangasek: but it got fixed again as well | 16:54 |
| slangasek | pitti: "around the main function call" - looks to me like exactly what you were objecting to | 16:55 |
| slangasek | anyway, if you're aware of it, I assume all is as it should be :) | 16:55 |
| pitti | slangasek: right, but now only KeyboardInterrupt and IOError | 16:55 |
| slangasek | ahh, ok | 16:55 |
| pitti | slangasek: the latter is still not quite well, but I asked Till to file an upstream bug | 16:55 |
| pitti | slangasek: and since the program is basically just one fancy print statement, I considered it "good enough" | 16:56 |
| cjwatson | RoAkSoAx: thanks, fixed | 16:56 |
| pitti | but I didn't want it to shadow things like ImportError, or wrong format strings, etc. | 16:56 |
| pitti | tkamppeter: bug 645328> oops, sorry about that, and thanks for finding; I'll get it fixed first thing tomorrow | 16:57 |
| ubottu | Launchpad bug 645328 in cups (Ubuntu Maverick) "use of dpkg-vendor requires dpkg-dev" [Undecided,New] https://launchpad.net/bugs/645328 | 16:57 |
| RoAkSoAx | cjwatson: thank you :) | 16:57 |
| === al-maisan is now known as almaisan-away | ||
| tkamppeter | pitti, thanks for passing through my uploads. Don't you have access to pass through ptouch-driver? | 17:03 |
| pitti | tkamppeter: perhaps it wasn't in the queue yet when I processed it; but we'll get it in, don't worry | 17:05 |
| * pitti -> dinner | 17:05 | |
| === dendrobates is now known as dendro-afk | ||
| mvo | zul: I noticed that after a recent upgrade squid seems to be not always started anymore, is that a know issue? might be something with squid-deb-proxy, I have not investigated yet | 17:15 |
| zul | mvo: ill take a look | 17:16 |
| mvo | thanks, I can dig more into it tomorrow (almost dinner time for me :) | 17:16 |
| === hrw is now known as hrw|gone | ||
| mvo | ev: apt bug is fixed, thanks for reporting it | 17:34 |
| ev | mvo: you rock! | 17:34 |
| mvo | thanks :) | 17:35 |
| * mvo will not say just how silly the bug was | 17:36 | |
| \sh | anyone have a short hint on how to enable debugging mode for udev? udev.conf: udev_log="debug" or something like this? | 17:38 |
| cjwatson | yes, that. or udevadm control --log-priority=debug | 17:39 |
| cjwatson | run update-initramfs -u after editing the file if you want debug output in the initramfs too | 17:39 |
| \sh | oh wow...if this is not a big bug | 17:41 |
| \sh | ok...here it goes: /lib/udev/write_net_rules writes into /etc/udev/rules.d/70-persistent-net.rules, while debugging enabled, it reads this 70-persistent-net.rules file, but adds stuff into the very same file, because the main rules files which triggers write_net_rules is 75-persistent-net-generator.rules | 17:42 |
| \sh | so 70 comes first, and 75 changes everything | 17:42 |
| cjwatson | I thought it had to be that way. the purpose of writing the net rules is to record the state of the mac->device mapping in this boot, to preserve it for future boots. thus writing the net rules has to come last | 17:43 |
| cjwatson | but I'm going out so can't debug this now | 17:44 |
| \sh | cjwatson: if you want to have a nic named "eth0 " on a different device, you need to say that normally in 70-persistent-net.rules but somehow this is not wanted by /lib/udev/rules.d | 17:44 |
| \sh | if the admin tells udev to "this is the action you need to do when finding this device with mac address X:Y:Z", the system shouldn't overwrite his wish | 17:45 |
| \sh | s/his/his\/her/ | 17:45 |
| \sh | the second bug I would say is, that write_net_rules helper script can't be prevented to write the 70-persistent-net.rules file, even if admin says that this file is chmod 444 | 17:51 |
| === beuno is now known as beuno-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| Darxus | Why do the graphical package management tools use apt-get instead of aptitude? | 17:57 |
| Darxus | They don't flag packages as installed as a dependancy, right? | 17:57 |
| hallyn | how does debuild -S decide what files to keep? iow, how does it decide whether to ignore .git/ ? | 18:08 |
| ev | hallyn: the DEBUILD_DPKG_BUILDPACKAGE_OPTS environment variable lets you control that | 18:13 |
| hallyn | ev: thanks! | 18:14 |
| hallyn | (wonder if there is a way to get 'bzr dailydeb' to honor that) | 18:15 |
| ev | ~/.devscripts most likely | 18:15 |
| pitti | DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I" | 18:17 |
| pitti | always a good thing to have | 18:17 |
| doko | http://qa.ubuntuwire.com/ftbfs/ isn't updated anymore | 18:17 |
| === ivoks-afk is now known as ivoks | ||
| ScottK | doko: The admin for that is away right now, but I've pinged them. | 18:29 |
| doko | ScottK: thanks | 18:30 |
| \sh | cjwatson: ok, the workaround is to overwrite 75-persistent-net-generator.rules in /etc/udev/rules.d/ but this should not be the case, when the README tells something else | 18:32 |
| \sh | and that doesn't work when you do it when you start the server up...*grmpf* | 18:36 |
| === rickspencer3_ is now known as rickspencer3 | ||
| === BlackZ_ is now known as BlackZ | ||
| achiang | does anyone know who calls sysv-style initscripts like "reboot" and "shutdown"? if i issue them as root from the cmdline, i think i'm directly calling the binaries in /sbin... | 18:52 |
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| === dendro-afk is now known as dendrobates | ||
| jcastro | charlie-tca: I've got karl looking at the tomboy menu thing | 19:07 |
| charlie-tca | Thank you | 19:07 |
| charlie-tca | I hope we can get it fixed | 19:07 |
| charlie-tca | It just seems not everyone can reproduce it. | 19:08 |
| jcastro | I think we got it | 19:08 |
| jcastro | charlie-tca: was there someone working on appindicator support for XFCE somewhere? I remember seeing something a while back. | 19:09 |
| charlie-tca | I don't remember. I will have to go looking | 19:09 |
| jcastro | ok if you run into anything lmk. (That being said the fallback is supposed to be working anyway) | 19:10 |
| charlie-tca | I will do that. Thanks | 19:10 |
| jcastro | if someone is interested but needs help I can get them help too | 19:11 |
| === dendrobates is now known as dendro-afk | ||
| mr_pouit | jcastro: not really. There's a panel plugin (xfce4-indicator-plugin), but nothing in xfce core. | 19:17 |
| tkamppeter | pitti, I have reported the pyppd problem upstream now. | 19:19 |
| === dendro-afk is now known as dendrobates | ||
| hallyn | hggdh: my bug-control membership is about to expire, you're listed as someone to get in touch with - can you renew? | 20:18 |
| hggdh | hallyn: doing it now | 20:19 |
| hallyn | hggdh: thanks! | 20:19 |
| hggdh | hallyn: what is your LP id? | 20:19 |
| hggdh | hallyn: forget, got it. You are all set. | 20:21 |
| === hrw|gone is now known as hrw | ||
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| === hrw is now known as hrw|gone | ||
| mvo | ogra: the channel adding stuff should be fixed in trunk now (in software-center) | 20:54 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| === bjf is now known as bjf[afk] | ||
| === tkamppeter_ is now known as tkamppeter | ||
| === ivoks is now known as ivoks-afk | ||
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!