[00:04] infinity: ok, added -pthread... i think.... not always sure things work with CMake the way you'd expect [00:04] so is there a reason efilinux was used over something like barebox? [00:05] nwmcsween: 'cause? [00:05] nwmcsween: (Is there a reason everyone feels the need to bikeshed over it?) [00:06] infinity: thanks a lot. [00:06] not bikeshedding barebox has nice code it's got people working on it and it's not ugly like grub 2 [00:06] infinity: sometimes dead obvious things are missed [00:06] We don't think GRUB 2 is ugly, so that's not a good start in trying to persuade us. [00:07] nwmcsween: Does it have EFI support? Last I checked, uBoot had no such thing. [00:07] Mostly I'd just never heard of barebox. [00:07] cjwatson: barebox is uboot2. [00:07] Yeah, google tells me as much. [00:07] grub 2 has nested fucntions - it's ugly [00:07] relies on gccisms [00:07] Only a few, and they'll go away eventually I think. [00:07] In fairness I'm worried about efilinux, but that's because I have investment into GRUB scripts [00:07] Good thing we build with GCC. [00:08] And yeah, GCCisms aren't a problem for us. [00:08] (for my own stuff) [00:08] xnox: Can I see your patch? Curious how/where you fixed it. [00:08] I'd rather they weren't there in this case, but it's cosmetic. [00:08] So I'm not sure "GRUB 2 is ugly" is an argument even I'd listen to, being someone unhappy with efilinux [00:09] infinity: building, don't know if it works yet, cause CMake 'forces' me to purge everything to reconfigure. Unless I'm doing it wrong... [00:09] having executable stack isn't really too great [00:09] I doubt it's a security issue with grub but still [00:09] *shrug*. [00:09] If we got authoritative assurance that we weren't going to get bitten by GPLv3 if an OEM screws up, I'm pretty sure we'd be back to GRUB 2 from efilinux like a shot. [00:10] Until then we'll go with small and simple on the grounds that that probably means we don't have to invest too much effort in it. [00:10] cjwatson, not to ask you to beat this horse too dead, but I'm curious what the nature of the argument is there [00:10] isn't it the case for x86 at least that "just turn off secure boot" suffices? [00:11] is the worry about non-x86? [00:11] geofft: Sure, but "Just turn off Secure Boot" is a tough thing to tell someone you handed a CD to. [00:11] geofft: No, the worry is an OEM shipping a "User Product" (in GPLv3 language) that has preinstalled Ubuntu and erroneously doesn't permit disabling secure boot. [00:11] geofft: Our target audience is "everyone", and most of the "everyones" I know don't even know their systems have firmware, let alone how to enter and configure it. [00:12] That's a violation of the GPLv3, but the question is who has to cure it. [00:12] infinity: I'm curious about the legal argument, not the practical one. I understand why we need to support secure boot [00:12] geofft: Oh, then what Colin said. [00:12] cjwatson: Oh, we expect OEMs to erroneously not have the off button? Okay, sigh. [00:12] because there are benifits [00:12] There's been some concern that we might end up having to disclose our private key in such a scenario. [00:12] Yeah, that makes sense [00:12] geofft: We very much hope they don't - and they'd be in violation of the Microsoft logo guidelines too - but it's a possibility [00:14] Also, it's possible to detect from software whether secure boot is enabled, and I can imagine proprietary software acting conditionally on that. Is an unsigned GRUB binary with secure boot disabled an equivalent replacement for a signed GRUB binary with secure boot enabled on such a system? [00:14] (Note that the logo guidelines *don't* necessarily require that a user be able to install their own keys, AIUI ...) [00:14] xnox: http://paste.ubuntu.com/1063467/ [00:14] xnox: ^-- That works here. [00:15] xnox: (Of course, then the build fails later with glibc single-includes fun, which is also an easy fix) [00:15] My feeling for how it *should* work involves recognising that Ubuntu is just trying to get things working, and isn't interested in locking down people's systems. But I'm not 100% certain that that's how the licence works. [00:16] infinity: OWBuild is a build system based on CMake. [00:16] OWBuild is not a fork of CMake, it is simply a set of macros for CMake [00:16] that simplifies CMake scripts writing [00:16] * xnox head desk [00:16] not another one [00:16] xnox: How about I fix the glib thing too and just upload, since I'm halfway there? :P [00:16] And IMO the cure for such a scenario would be to require the OEM, who did the locking down, to provide users with an unlock mechanism - i.e. in such a hypothetical scenario they ought to be counted as the violators, not us. [00:17] infinity: well you so my "mega" patch earlier of just removing the include ;-) go ahead [00:18] cjwatson: yeah, agreed. I mean, it's the OEM that's violating GRUB's/Ubuntu's copyrights / GPLv3 license! [00:18] cjwatson: but you guys not being able to find an actual lawyer that agrees is worrisome [00:18] If we could get a legal opinion, or an FSF statement, that that's what GPLv3 section 6 means, then I think that would fix the problem for us. But from what I saw we weren't able to get such a thing. I don't know if it's just that we weren't stating the problem clearly enough. [00:19] (Speaking, mind you, as somebody who was advocating for using GRUB 2, so take with pinch of salt I suppose) [00:20] Unfortunately with this sort of thing it's not clear that my armchair lawyer's opinion suffices. :-) [00:25] xnox: Oh wait, hah. The pthread failure was after the glib one, not before. My fix didn't fix it. :P [00:25] xnox: Did yours? [00:26] infinity: nope [00:26] it's using funky OWBuild stuff with it's own supermacros [00:27] cjwatson: there are many comments on http://gplv3.fsf.org/comments/gplv3-draft-4.html#3469:3310:3412:3479: and the question of 'this bit prevents providing supported signed software' was raised [00:27] but it's not legal advice [00:27] "This phrase effectively stops three implementations: * Free software digitally signed * Free software used in DRM * Free software in closed environments" [00:27] GPLv3 fail [00:27] I'm guessing they were going aver the Tiovization [00:28] That was exactly the intent, yes. [00:28] Yeah, I can find lots of random armchair legal advice, but that's no more use to me than my own interpretation [00:28] yes. [00:28] (Which, FWIW, thinks that we would be OK, but that's only my personal opinion) [00:29] and 'real' legal advice will only come after it's been tried in court..... all lawyers rely on case-studies anyway [00:30] "Free software digitally signed" is obviously nonsense armchair advice because, for example, I'm pretty sure the FSF has said they're not out to stop e.g. distributions signing their packages for the purpose of integrity [00:30] xnox: In this case, I believe that a clear statement from the FSF would suffice, as they're the sole copyright holder [00:31] (And look up "estoppel") [00:38] bryceh: oh, instead of that launchpadlib-based code, you could use rmadison, or something using the same backend CGI service [00:39] bryceh: though that's only really expecting to be a developer service and not particularly scalable - but anyway, what I mean is that if all you need is "is this in -proposed" or "is this in -updates" there are lighter-weight approaches than launchpadlib for a desktop system [00:40] bryceh: also, worth checking for -updates before -proposed, since the same version of a package can be in both [00:41] cjwatson, thanks [00:42] Or even apt-cache policy, come to think of it [00:42] though I expect there's a saner way to get at that information in python-apt, and conveniently you're in python already :) [00:45] cjwatson, seems like I had tried both of those but didn't like it for some reason [00:46] apt-cache policy definitely seems to have the information and doesn't involve hitting the network at all [00:47] oh right; the "is this in -proposed or -updates" bit is actually a patch bdmurray is proposing. What i actually am using lpl for in my apport hook is something different [00:47] it only tells you whether it matches what's currently in your Packages for -proposed/-update [00:47] ah, ok [00:47] what this is trying to do is see what release status the user's system is [00:47] IOW differentiate between stable release vs development release vs unsupported release [00:48] Consider distro-info for that [00:48] cjwatson, for that I couldn't find an existing tool that'd already be on the user's system... but maybe you know of one? [00:48] hmm [00:48] It's not installed by default right now, but it could be [00:50] mm, so yeah if that were installed by default, that looks like it would be an ok substitution [00:50] Just depend on it if you need it [00:51] Then it will be :-) [00:51] It's tiny nowadays and it's in main [00:56] infinity: it looks like upstream has ditched the owbuild crap and gone pure cmake in 'tip' of their hg repo [00:56] xnox: http://paste.ubuntu.com/1063498/ [00:56] xnox: This worked for me for now. If upstream fixed it better, good, because my patch isn't remotely upstreamable. [00:56] xnox: It's a brute force "fuck it, I want it to build" patch. ;) [00:56] * infinity uploads. [00:57] Hello all, Can tell me the file used to set default apps on unity bar for livecd builds? [00:57] hrm, can anyone... [00:57] sorry for grammar [00:57] infinity: I was expecting it to be disgusting, but they're small and self contained. [00:58] StevenK: No, they're readable, it's just that harcoding '-pthread' after it goes to the trouble of trying to detect how to link pthreads is hilariously wrong. [00:58] infinity: aha! well done at tracing the real contents of ${CMAKE_THREAD_LIBS_INIT} [00:58] StevenK: (right on modern Linux, wrong everywhere else) [00:58] infinity: Portable code is wrong code! [00:58] Or something. [00:58] StevenK: Hah. [00:59] cjwatson, actually looks like all I'd actually need is distro-info-data [01:00] that's a csv file, python should be able to handle that :-) [01:00] but wow, that's manually updated every release? [01:00] Is the format guaranteed though? [01:00] infinity: if ${CMAKE_THREAD_LIBS_INIT} broken, then upstream is still broken as well =) [01:00] Why not use python-distro-info? [01:01] cjwatson, it would need to be, since distro-info is a dependency on it [01:01] bryceh: I was about to say that, yeah. I think only the distro-info interface is (vaguely) guaranteed, the data files could randomly change (though, I imagine they won't) [01:01] Seeing as bdrung went to the effort of writing loads of bindings :-) [01:01] bryceh: distro-info and distro-info-data are tied together, he could change the data, make distro-info love it, and leave you broken. :P [01:02] infinity, well he could change distro-info and leave me broken too [01:02] xnox: Not necessarily, it's how owbuild is using that. [01:02] infinity, as launchpad does all the fricken time ;-) [01:02] bryceh: You're welcome. [01:02] xnox: FindThreads isn't inherently broken, it's that what it spits out is meant to be a library -llink line (ie: in LD_LIBS) [01:02] We aim to please. [01:02] bryceh: published interface vs. unpublished interface. Use 'import distro_info' from python-distro-info rather than rolling your own. It's easier anyway. [01:02] xnox: But owbuild was jamming it into LD_FLAGS, and I was too lazy to figure out where. [01:03] infinity: you TIL, i'm not touching it ever again ;-) [01:03] xnox: Heh. [01:03] infinity: I'm amused at it being 'owbuild'. You could almost use it as an explanation of failure. [01:03] xnox: If the next upstream is a reorg of the source anyway, I'm sure I can just sync over my hack when the time comes. [01:03] StevenK: Indeed. [01:04] infinity: funny you should say that, cause a "little did you know" is coming up ;-) [01:04] * xnox hides. good night all! [01:06] (Well, python3-distro-info.) [01:07] no such package [01:08] well, on precise anyway [01:22] >>> import distro_info [01:22] >>> udi = distro_info.UbuntuDistroInfo() [01:22] >>> code_name = 'quantal' [01:22] >>> code_name in udi.devel() [01:22] True [01:22] >>> code_name in udi.supported() [01:22] True [01:22] >>> code_name in udi.lts() [01:22] False [01:22] >>> udi.stable() [01:22] 'precise' [01:22] >>> udi.supported() [01:22] ['hardy', 'lucid', 'natty', 'oneiric', 'precise', 'quantal'] [01:22] >>> udi.unsupported() [01:23] ['warty', 'hoary', 'breezy', 'dapper', 'edgy', 'feisty', 'gutsy', 'intrepid', 'jaunty', 'karmic', 'maverick'] [01:23] >>> [01:23] cjwatson, so yeah this looks like it should work, thanks [01:27] hrm, the one problem is it doesn't appear to give the release _dates_ [01:27] distro-info-data will be SRUd as needed [01:29] bryceh: have you heard of libosinfo? [01:29] jbicha, yes, I did hear about that just recently. haven't played with it yet [01:30] I don't know much about it, but it does have a database of disto releases [01:30] http://git.fedorahosted.org/git/?p=libosinfo.git;a=blob;f=data/oses/ubuntu.xml [01:30] micahg, yeah but cjwatson and infinity said not to use that directly. but I do know it has the dates I'm looking for [01:31] bryceh: No, his point was that distro-info will always be accurate. [01:31] bryceh: (because data gets SRUed) [01:31] bryceh: So you don't need dates, as long as you're not on an EOL release, you can just rely on it to not lie (well, within a week or two). [01:32] infinity, oh gotcha, but no that's not what I meant [01:32] bryceh: Kay, what's the use case for release dates? [01:32] I would expect it to be accurate, else I wouldn't consider it [01:32] bryceh: Or did you mean version numbers? [01:32] no, although now that you mention it I don't know that I can get those either [01:33] bryceh: distro-info (the CLI) does numbers and codenames, no idea what the python module does. [01:34] bryceh: So, what did you want with dates? [01:34] so far I'm only seeing codenames [01:34] well, not so much dates as time since the release [01:35] bryceh: I'm trying to sort out why that's valuable. ;) [01:35] there's certain checks I'm doing for post-release bug reports which I'd like to be less strict about if the release *just* came out. [01:35] bryceh: What's your cutoff for that? [01:35] like a month or so [01:36] bryceh: int(release.version.split('.')[-1])+2? [01:36] xnox, hehe [01:36] bryceh: int(release.version.split('.')[1])+2? [01:36] is better in case of a point release, e.g. 12.04.1 [01:36] bryceh: Again, not sure what the python module has, but the CLI version: "distro-info --date=2012-02-11 --supported" [01:36] bryceh: Gives you info as if it were that date. [01:36] bryceh: just wait until june/december :) [01:37] bryceh: So, just put yourself a month in the past and see if you exist yet! [01:37] bryceh: what if the clock/time is wrong on the machine? [01:37] Ecxcept that's buggy. [01:37] micahg: Hey Micah, fix distro-info. [01:37] micahg: --supported lists the devel release. [01:38] micahg: That's brimming with wrong. [01:38] bdrung: ^ [01:38] yeah, that's certainly wrong [01:38] Same bug with Debian. [01:39] (My machine claims that both wheezy and quantal are supported) [01:39] yeah there's probably a few ways to achieve this. I've been wondering if there's a file on the system with a date that dependably matches to the release date? [01:39] (Or, if I go back in time, it tells me precise was supported before it was released) [01:39] (and that would never get updated later) [01:39] bryceh: Other than the version, which is, like, the date? [01:40] bryceh: lsb_release -rs [01:40] infinity, no I do agree that's one way of doing it, but if the release is at the start of the month vs. the end of the month, that could give me a lot more or less than 30 days [01:42] bryceh: Just be liberal in your window, then? [01:42] I guess... [01:42] * micahg wonders why June/Dec 1 isn't good :) [01:42] that's 4-6 weeks ATM [01:43] July4/Dec25, Independence from bugs day, and Merry Christmas, no more bugs. [01:43] I guess my hesitation here is just that these solutions are all built on the assumption that ubuntu will always be released in april and october [01:44] which I suppose isn't a *bad* assumption given history, still... [01:44] bryceh: Random dates assume that, release versions assume nothing. [01:44] bryceh: Since we change the version when we slip. [01:44] bryceh: (See 6.06) [01:44] infinity, true [01:44] Granted, this has only happened once. :P [01:45] so, yeah xnox's solution would be the best for that [01:46] hey, so tell me, if I'd said I needed within 7 days of the release, what solutions would you guys come up with for that? [01:47] bryceh: anonymous launchpad query [01:48] hahaha [01:48] Modal dialog box with a question. OBVIOUSLY. [01:48] And make it too big to fit on a netbook display, for bonus points. [01:48] Also, use Motif. [01:49] micahg, well I can go back to my launchpad query for this once launchpadlib's been updated to python3 [01:49] bryceh: actually, distro info should have the release date of the current stable release :) [01:49] *planned [01:49] micahg, yeah that'd be nice [01:50] i.e. it should know enough about itself, not necessarily the next release immediately though [01:50] although in theory we can SRU that as soon as we know as well [01:51] If only https://api.launchpad.net/1.0/ubuntu/precise/datereleased didn't throw an embarassing 500. [01:51] infinity, heh [01:51] (It has the right date) [01:52] infinity, yeah I bet that's due to the change in date object type that happened a bit ago. I'm still fixing my launchpad scripts due to that change. [01:52] and I totally don't blame StevenK for that! [01:52] StevenK: *stare* [01:53] StevenK: Why does https://api.launchpad.net/1.0/ubuntu/precise/datereleased 500? [01:53] XML Parsing Error: syntax error [01:53] micahg: Thank god someone's here to cover for my illiteracy. [01:53] micahg: Not quite what I meant by "why". [01:54] heh, just pointing out it seems to be another issue :) [01:54] actually if you look at the source of that page, it looks like a legit date [01:54] s/it/there/ [01:54] so maybe it's just that the content-type wasn't specified? [01:54] bryceh: It is the right date, yes, I said that. [01:55] If you wget it, it 500s all special-like. [01:55] infinity: Haha. It actually contains the date [01:55] Anyhow, I was going to point at the static http API (rather than the xmlrpc bits) as a perfectly reasonable non-lplib way for you to get info. [01:55] Since you don't need to actually DO any RPC here. [01:56] StevenK: I know. [01:57] infinity: You can grab precise like that. I guess the lazr.restful machinery does not like you trying to get attributes like that [01:57] StevenK: HAHAHAHAHA. [01:57] wget -S https://api.launchpad.net/devel/ubuntu/precise/releasedate [01:58] It gives a 404, then proceeds to give me the date raw. [01:58] BRILLIANT. [01:58] Best. Webapp. Ever. [01:58] infinity: That is what I meant by "[11:55] < StevenK> infinity: Haha. It actually contains the date" [01:58] StevenK: Yeah, but I thought you just meant the body (as I was seeing in a web browser) [01:58] StevenK: The full response is so much more entertaining. [01:59] Our API sucks. News at 11. [02:00] Oh wait, that really was a 404, I typed it wrong... [02:00] does anyone know if mipmapping is ever going to be fixed in compiz? it's pretty pathetic that it's still broken 2 months after someone at nvidia submitted a patch to fix it on launchpad (bug 991180) [02:00] Yeah, the proper URL is a 500. :P [02:00] Launchpad bug 991180 in compiz (Ubuntu) "Ubuntu 12.04 Nvidia Compiz Expo Mipmap" [Undecided,Confirmed] https://launchpad.net/bugs/991180 [02:00] And the date. [02:02] TerminX: "someone at nvidia"? [02:03] yes, the patch posted to that bug is from one of the linux driver maintainers there [02:04] TerminX: To be fair, while you know that, I certainly don't. [02:04] TerminX: It just looks like a drive-by patch (one that, I assume, no one's noticed yet, since no one's decided to nominate for a release, prepare an SRU, etc) [02:04] TerminX: It happens. Bugs get missed. Hopping on IRC and calling people "pathetic" doesn't help. [02:05] infinity, StevenK: The 500 doesn't contain the date. [02:05] wgrant: I bed to differ. [02:05] wgrant: Or beg. [02:05] I called someone pathetic? [02:05] wgrant: Run the wget _S [02:05] I said the situation itself is pathetic [02:05] s/_S/-S/ [02:05] StevenK: What's the got to do with it? [02:05] Accept [02:05] browser sends a text/html or application/xhtml+xml Accept [02:05] wgrant: The date is in the body. [02:05] So lazr.restful obliges [02:06] wgrant: Anyhow. It's broken either way. [02:06] The 500 body looks to be 'TypeError', not the date [02:06] You can see it at https://api.launchpad.net/1.0/ubuntu/precise/datereleased?ws.accept=application/json [02:07] TerminX: You don't see how it came across more confrontational than, say, helpful? [02:07] wgrant: TypeError: datetime.datetime(2012, 4, 26, 12, 9, 10, 437678, tzinfo=) is not JSON serializable [02:07] Heh heh [02:08] Yes. [02:08] So it's broken, but not in a way that is even slightly special. [02:10] TerminX: Fun fact: that patch breaks mipmapping on everything else :) [02:11] bryceh: The date type difference is purely a client-side change. It is unrelated to any server-side error. [02:11] wgrant, yeah I know [02:13] wgrant, and IIRC not due to code changes from the launchpad team, so I blame them inappropriately :-) [02:13] bryceh: Yeah, there's not enough people actively working on LP atm to break that :) [02:14] wgrant, exactly [02:15] there's also a launchpadlib cache corruption bug that's been a chronic irritation, but again has ended up being something wonky client-side, in code not maintained by the LP crew [02:15] bryceh: It was in httplib2 itself? [02:16] wgrant, it may be, or whatever the layer is above that. it faults in the json decoding logic [02:17] bryceh: Above that is probably wadllib, which we own. [02:30] wgrant, maybe. The error in question is httplib.IncompleteRead, but I think that gets generated because the cache file is truncated and it's trying to "read" from that. I don't know what code truncates the cache file though. [02:31] RAOF: does it? maybe the guy who wrote it would know that and fix it properly if the maintainer he tried contacting (sam spilsbury) didn't just ignore him heh [02:32] I can't imagine it did much to break it further though since the bug also affects intel [02:33] I have no idea whether he contacted Sam, but I do know that Sam's been working on fixing the mipmapping code. [02:34] yeah, he told me he tried to contact him in several different ways and never got any sort of a response whatsoever [02:38] how recently has he been working on fixing it? bisection of what change broke it in the first place revealed that the bug was caused by one of sam's changes anyway [02:40] and considering the bug was confirmed to occur on at least intel in addition to nvidia I can't really see how it was broken any further by correcting the code in question [02:40] do you have some sort of report where the patch was applied and something further broke? [02:41] No, because it was never pushed out, as the breakage was picked up in testing. [02:45] was this documented anywhere? [02:45] and what configurations was that on? it must have been several different configurations for you to say it "breaks mipmapping on everything else" [02:46] plagman: Not as far as I'm aware, which is disappointing; this has just come up in my conversations with Sam. [02:47] in any case, jusding by its contents I strongly doubt that the patch broke anything by itself [02:48] From what I gather it *might* be due to a bug in mesa. [02:48] It would be nice for Sam to provide updates on bugs ☺ [02:49] or on irc pings or emails, for that matter [02:50] Apparently he's in Canada at the moment, so he might have been flying? [02:50] the cool thing about email is how when you receive one, it persists in your inbox until you do something with it [02:51] either Mesa is broken and doesn't know how to report the GLX_BIND_TO_MIPMAP_TEXTURE fbconfig attribute properly and this would mean that mipmaps were broken _only on Mesa_ before Sam's change that moved the context initialization around and after Sam's change on everything else [02:51] and in this case the patch just reversed that tendency [02:51] or Mesa works fine and the patch couldn't have really done anything harmful [02:52] and AFAIK Mesa reports it just fine [02:54] anyway, I'd be happy to discuss that with Sam over the bug or otherwise if he has any concerns [02:56] I don't know; I'm just running from what I picked up as he was complaining about all drivers, everywhere, while trying to fix the bug. [02:56] When I see him around I'll try and get sam to ping you. [02:57] regardless, it's a pretty significant bug to have in an LTS release. I'm guessing mipmapping isn't enabled by default or else we'd be hearing a LOT about it (or more likely it would have just been fixed months ago) [02:58] Or it's hard. [04:20] RAOF: "[54302.526085] NVRM: Xid (0000:01:00): 8, Channel 00000003" makes me have a sad. [04:20] StevenK: Do you know how to trigger that? We should have made it as easy as possible for you to file that bug on nvforums, where nvidia want it(!). [04:21] Good morning [04:21] RAOF: Not really, it happens randomly and then X has a large sad. [04:22] Yeah, that's your driver shouting obsceneties at your card. [04:22] RAOF: Yeah, I only just looked up what 'Xid' actually means, the last time I mashed reset [04:23] RAOF: So it's a driver bug? [04:23] not necessarily [04:23] could be memory corruption, bad HW, etc [04:23] could very well be, though [04:23] but impossible to say with just that data, that's the symptom [04:23] Ah, you're still here :) [04:24] I'm happy to try and diagnose when it happens, I have easy ssh access into the box, but I can't trust anything on the screen. [04:24] yeah, though not at work anymore [04:25] plagman: Oh, just some pointers about what information would be helpful to collect before I go and napalm my X session and the module would be nice. [04:25] (I already have this time, so next time ...) [04:25] run nvidia-bug-report.sh as root, after that error message pops up [04:25] preferrably while X is still running if that's possible [04:25] I think ubuntu-bug nvidia collects all that information, too. [04:26] Over ssh is okay? [04:26] But that'll feed it to launchpad rather than as a nice tgz [04:26] should be, maybe you need to set DISPLAY [04:27] trying to narrow it down to a deterministic sequence of actions would be stellar of course [04:27] but that's hard [04:27] plagman: Ugh, this script is horrid. :-) [04:28] is it? [04:28] append_silent "/etc/redhat-release" [04:28] ... [04:28] append_silent "/etc/gentoo-release" [04:28] Because you know, a for loop is hard. :-) [04:28] not that it would tremendously change the end-result [04:29] anyway, patches welcome [04:30] plagman: Thanks for the pointer. [04:30] generally I would advise running that script and posting the result as an attachment on the nvnews linux forum [04:31] plagman: That script could also grab /etc/lsb-release, since /etc/debian_version on an Ubuntu machine is going to be unhelpful. [04:32] does it also grab /etc/issue? [04:32] Yeah, that's the first thing it does in that block. [04:32] that would probably cover ubuntu [04:32] but yeah, seems lsb-release could have value === trijntje_ is now known as trijntje [06:49] good morning === smb` is now known as smb === tkamppeter_ is now known as tkamppeter [07:14] RAOF, ubuntu-bug nvidia will also generate and collect the .tgz in addition to the stuff we ask for. [07:23] pitti, what's your opinion on bug 1013334 , an issue on launchpad's side ? [07:23] Launchpad bug 1013334 in apport (Ubuntu) "apport could not connect to crash database" [Undecided,Confirmed] https://launchpad.net/bugs/1013334 [07:24] jibel: no, it's indeed a bug in some hook, I'll follow up on it; thanks! [08:42] pitti, I get a crash in Ubiquity: "TypeError: update() takes exactly 2 arguments (1 given)" but apport redirects me to bug 194688. can you check the signature ? [08:42] Launchpad bug 194688 in ubiquity (Ubuntu) "ubiquity crashed with TypeError: on_partition_list_edit_activate() takes exactly 2 arguments (4 given)" [Undecided,Fix released] https://launchpad.net/bugs/194688 [08:42] or is there a way to force apport to file a bug ? [08:43] jibel: ah, it says it's already known? [08:43] pitti, yes [08:43] that's an apport bug indeed, it should allow you to file bugs for closed master bugs [08:43] jibel: you can edit the .crash file and remove the KnownBug: field [08:44] pitti, ack [08:44] jibel: sorry, KnownReport: [08:44] jibel: and then run it through apport-bug again; that should work [08:45] infinity: define 'supported' [08:48] bryceh: you can call distro-info --date=2012-05-28 --supported if you want to know what was supported last month [08:53] pitti, it worked thanks! === doko_ is now known as doko === StaffRingedSeal is now known as Myrtti [09:09] how can I get the dependency dag for a package? [09:20] bdrung, ok, and that should work similarly through the python api? [09:21] bdrung, also, any concerns if [python-]distr-info is included in the CD image? [10:18] jml, see your email [11:13] I want to build a package that will install on both Lucid and Precise. ${shlibs:Depends} brings in a dependency on libssl0.9.8, but this then fails to work on Precise which iuses libssl1.0.0. I've had similar problems with libmysqlclient18 and libdbi1. Ideally I'd like just one package, but one package for Precise and one for Lucid would I suppose be ok provided I can build it in one place. What's the best way here? === MacSlow is now known as MacSlow|lunch [11:35] alexbligh: In general you can't avoid this problem. precise users should still be able to install libssl0.9.8 even though it's not the default. We normally rebuild packages against the current set of library sonames rather than keeping a zillion old libraries around, though. [11:35] alexbligh: It should be possible to make the same *source* package work on both. [11:37] If you must have a single binary package, build on the oldest of the releases you want to support, and then at least there's a fighting chance that the worst case will be that users of newer releases will need to dig out older libraries (which perhaps can be automated with cunning use of apt pinning). === slomo_ is now known as slomo === cpg is now known as cpg|away === davmor2_ is now known as davmor2 === MacSlow|lunch is now known as MacSlow === agateau_ is now known as agateau [12:19] cjwatson, thanks === yofel_ is now known as yofel === _salem is now known as salem_ === Nigel is now known as G [13:16] ogra_, hey I think I might have found what the issue is with the monitors [13:26] pgraner: if you have an installed system, give a try to this one: [13:26] pgraner: http://people.canonical.com/~ppisati/linux-image-3.4.0-202-omap4_3.4.0-202.7_armhf.deb [13:26] pgraner: it should resolve the video issue [13:29] ppisati, ok, I'll try after this call I'm about to be on. [13:29] ppisati, I'm finding when it fails I don't get a /sys/devices/omapdss/display0/edid file [13:33] pgraner: edid is read after the monitor is detected, looks like hotplug is broken [13:37] pgraner, oh ? [13:38] ogra_, see my comment above [13:38] ah, sweet [13:46]