| xnox | infinity: ok, added -pthread... i think.... not always sure things work with CMake the way you'd expect | 00:04 |
|---|---|---|
| nwmcsween | so is there a reason efilinux was used over something like barebox? | 00:04 |
| infinity | nwmcsween: 'cause? | 00:05 |
| infinity | nwmcsween: (Is there a reason everyone feels the need to bikeshed over it?) | 00:05 |
| xnox | infinity: thanks a lot. | 00:06 |
| nwmcsween | not bikeshedding barebox has nice code it's got people working on it and it's not ugly like grub 2 | 00:06 |
| xnox | infinity: sometimes dead obvious things are missed | 00:06 |
| cjwatson | We don't think GRUB 2 is ugly, so that's not a good start in trying to persuade us. | 00:06 |
| infinity | nwmcsween: Does it have EFI support? Last I checked, uBoot had no such thing. | 00:07 |
| cjwatson | Mostly I'd just never heard of barebox. | 00:07 |
| infinity | cjwatson: barebox is uboot2. | 00:07 |
| cjwatson | Yeah, google tells me as much. | 00:07 |
| nwmcsween | grub 2 has nested fucntions - it's ugly | 00:07 |
| nwmcsween | relies on gccisms | 00:07 |
| cjwatson | Only a few, and they'll go away eventually I think. | 00:07 |
| geofft | In fairness I'm worried about efilinux, but that's because I have investment into GRUB scripts | 00:07 |
| infinity | Good thing we build with GCC. | 00:07 |
| cjwatson | And yeah, GCCisms aren't a problem for us. | 00:08 |
| geofft | (for my own stuff) | 00:08 |
| infinity | xnox: Can I see your patch? Curious how/where you fixed it. | 00:08 |
| cjwatson | I'd rather they weren't there in this case, but it's cosmetic. | 00:08 |
| geofft | So I'm not sure "GRUB 2 is ugly" is an argument even I'd listen to, being someone unhappy with efilinux | 00:08 |
| xnox | 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 |
| nwmcsween | having executable stack isn't really too great | 00:09 |
| nwmcsween | I doubt it's a security issue with grub but still | 00:09 |
| cjwatson | *shrug*. | 00:09 |
| cjwatson | 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:09 |
| cjwatson | 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 |
| geofft | 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 |
| geofft | isn't it the case for x86 at least that "just turn off secure boot" suffices? | 00:10 |
| geofft | is the worry about non-x86? | 00:11 |
| infinity | geofft: Sure, but "Just turn off Secure Boot" is a tough thing to tell someone you handed a CD to. | 00:11 |
| cjwatson | 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 |
| infinity | 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:11 |
| cjwatson | That's a violation of the GPLv3, but the question is who has to cure it. | 00:12 |
| geofft | infinity: I'm curious about the legal argument, not the practical one. I understand why we need to support secure boot | 00:12 |
| infinity | geofft: Oh, then what Colin said. | 00:12 |
| geofft | cjwatson: Oh, we expect OEMs to erroneously not have the off button? Okay, sigh. | 00:12 |
| nwmcsween | because there are benifits | 00:12 |
| cjwatson | There's been some concern that we might end up having to disclose our private key in such a scenario. | 00:12 |
| geofft | Yeah, that makes sense | 00:12 |
| cjwatson | 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:12 |
| cjwatson | 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 |
| cjwatson | (Note that the logo guidelines *don't* necessarily require that a user be able to install their own keys, AIUI ...) | 00:14 |
| infinity | xnox: http://paste.ubuntu.com/1063467/ | 00:14 |
| infinity | xnox: ^-- That works here. | 00:14 |
| infinity | xnox: (Of course, then the build fails later with glibc single-includes fun, which is also an easy fix) | 00:15 |
| cjwatson | 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:15 |
| xnox | infinity: OWBuild is a build system based on CMake. | 00:16 |
| xnox | OWBuild is not a fork of CMake, it is simply a set of macros for CMake | 00:16 |
| xnox | that simplifies CMake scripts writing | 00:16 |
| * xnox head desk | 00:16 | |
| xnox | not another one | 00:16 |
| infinity | xnox: How about I fix the glib thing too and just upload, since I'm halfway there? :P | 00:16 |
| cjwatson | 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:16 |
| xnox | infinity: well you so my "mega" patch earlier of just removing the include ;-) go ahead | 00:17 |
| geofft | cjwatson: yeah, agreed. I mean, it's the OEM that's violating GRUB's/Ubuntu's copyrights / GPLv3 license! | 00:18 |
| geofft | cjwatson: but you guys not being able to find an actual lawyer that agrees is worrisome | 00:18 |
| cjwatson | 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:18 |
| cjwatson | (Speaking, mind you, as somebody who was advocating for using GRUB 2, so take with pinch of salt I suppose) | 00:19 |
| cjwatson | Unfortunately with this sort of thing it's not clear that my armchair lawyer's opinion suffices. :-) | 00:20 |
| infinity | xnox: Oh wait, hah. The pthread failure was after the glib one, not before. My fix didn't fix it. :P | 00:25 |
| infinity | xnox: Did yours? | 00:25 |
| xnox | infinity: nope | 00:26 |
| xnox | it's using funky OWBuild stuff with it's own supermacros | 00:26 |
| xnox | 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 |
| xnox | but it's not legal advice | 00:27 |
| xnox | "This phrase effectively stops three implementations: * Free software digitally signed * Free software used in DRM * Free software in closed environments" | 00:27 |
| xnox | GPLv3 fail | 00:27 |
| xnox | I'm guessing they were going aver the Tiovization | 00:27 |
| infinity | That was exactly the intent, yes. | 00:28 |
| cjwatson | Yeah, I can find lots of random armchair legal advice, but that's no more use to me than my own interpretation | 00:28 |
| xnox | yes. | 00:28 |
| cjwatson | (Which, FWIW, thinks that we would be OK, but that's only my personal opinion) | 00:28 |
| xnox | and 'real' legal advice will only come after it's been tried in court..... all lawyers rely on case-studies anyway | 00:29 |
| cjwatson | "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 |
| cjwatson | xnox: In this case, I believe that a clear statement from the FSF would suffice, as they're the sole copyright holder | 00:30 |
| cjwatson | (And look up "estoppel") | 00:31 |
| cjwatson | bryceh: oh, instead of that launchpadlib-based code, you could use rmadison, or something using the same backend CGI service | 00:38 |
| cjwatson | 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:39 |
| cjwatson | bryceh: also, worth checking for -updates before -proposed, since the same version of a package can be in both | 00:40 |
| bryceh | cjwatson, thanks | 00:41 |
| cjwatson | Or even apt-cache policy, come to think of it | 00:42 |
| cjwatson | though I expect there's a saner way to get at that information in python-apt, and conveniently you're in python already :) | 00:42 |
| bryceh | cjwatson, seems like I had tried both of those but didn't like it for some reason | 00:45 |
| cjwatson | apt-cache policy definitely seems to have the information and doesn't involve hitting the network at all | 00:46 |
| bryceh | 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 |
| cjwatson | it only tells you whether it matches what's currently in your Packages for -proposed/-update | 00:47 |
| cjwatson | ah, ok | 00:47 |
| bryceh | what this is trying to do is see what release status the user's system is | 00:47 |
| bryceh | IOW differentiate between stable release vs development release vs unsupported release | 00:47 |
| cjwatson | Consider distro-info for that | 00:48 |
| bryceh | 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 |
| bryceh | hmm | 00:48 |
| cjwatson | It's not installed by default right now, but it could be | 00:48 |
| bryceh | mm, so yeah if that were installed by default, that looks like it would be an ok substitution | 00:50 |
| cjwatson | Just depend on it if you need it | 00:50 |
| cjwatson | Then it will be :-) | 00:51 |
| cjwatson | It's tiny nowadays and it's in main | 00:51 |
| xnox | infinity: it looks like upstream has ditched the owbuild crap and gone pure cmake in 'tip' of their hg repo | 00:56 |
| infinity | xnox: http://paste.ubuntu.com/1063498/ | 00:56 |
| infinity | xnox: This worked for me for now. If upstream fixed it better, good, because my patch isn't remotely upstreamable. | 00:56 |
| infinity | xnox: It's a brute force "fuck it, I want it to build" patch. ;) | 00:56 |
| * infinity uploads. | 00:56 | |
| stlsaint | Hello all, Can tell me the file used to set default apps on unity bar for livecd builds? | 00:57 |
| stlsaint | hrm, can anyone... | 00:57 |
| stlsaint | sorry for grammar | 00:57 |
| StevenK | infinity: I was expecting it to be disgusting, but they're small and self contained. | 00:57 |
| infinity | 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 |
| xnox | infinity: aha! well done at tracing the real contents of ${CMAKE_THREAD_LIBS_INIT} | 00:58 |
| infinity | StevenK: (right on modern Linux, wrong everywhere else) | 00:58 |
| StevenK | infinity: Portable code is wrong code! | 00:58 |
| StevenK | Or something. | 00:58 |
| infinity | StevenK: Hah. | 00:58 |
| bryceh | cjwatson, actually looks like all I'd actually need is distro-info-data | 00:59 |
| bryceh | that's a csv file, python should be able to handle that :-) | 01:00 |
| bryceh | but wow, that's manually updated every release? | 01:00 |
| cjwatson | Is the format guaranteed though? | 01:00 |
| xnox | infinity: if ${CMAKE_THREAD_LIBS_INIT} broken, then upstream is still broken as well =) | 01:00 |
| cjwatson | Why not use python-distro-info? | 01:00 |
| bryceh | cjwatson, it would need to be, since distro-info is a dependency on it | 01:01 |
| infinity | 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 |
| cjwatson | Seeing as bdrung went to the effort of writing loads of bindings :-) | 01:01 |
| infinity | 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:01 |
| bryceh | infinity, well he could change distro-info and leave me broken too | 01:02 |
| infinity | xnox: Not necessarily, it's how owbuild is using that. | 01:02 |
| bryceh | infinity, as launchpad does all the fricken time ;-) | 01:02 |
| StevenK | bryceh: You're welcome. | 01:02 |
| infinity | 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 |
| StevenK | We aim to please. | 01:02 |
| cjwatson | 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 |
| infinity | xnox: But owbuild was jamming it into LD_FLAGS, and I was too lazy to figure out where. | 01:02 |
| xnox | infinity: you TIL, i'm not touching it ever again ;-) | 01:03 |
| infinity | xnox: Heh. | 01:03 |
| StevenK | infinity: I'm amused at it being 'owbuild'. You could almost use it as an explanation of failure. | 01:03 |
| infinity | 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 |
| infinity | StevenK: Indeed. | 01:03 |
| xnox | infinity: funny you should say that, cause a "little did you know" is coming up ;-) | 01:04 |
| * xnox hides. good night all! | 01:04 | |
| cjwatson | (Well, python3-distro-info.) | 01:06 |
| bryceh | no such package | 01:07 |
| bryceh | well, on precise anyway | 01:08 |
| bryceh | >>> import distro_info | 01:22 |
| bryceh | >>> udi = distro_info.UbuntuDistroInfo() | 01:22 |
| bryceh | >>> code_name = 'quantal' | 01:22 |
| bryceh | >>> code_name in udi.devel() | 01:22 |
| bryceh | True | 01:22 |
| bryceh | >>> code_name in udi.supported() | 01:22 |
| bryceh | True | 01:22 |
| bryceh | >>> code_name in udi.lts() | 01:22 |
| bryceh | False | 01:22 |
| bryceh | >>> udi.stable() | 01:22 |
| bryceh | 'precise' | 01:22 |
| bryceh | >>> udi.supported() | 01:22 |
| bryceh | ['hardy', 'lucid', 'natty', 'oneiric', 'precise', 'quantal'] | 01:22 |
| bryceh | >>> udi.unsupported() | 01:22 |
| bryceh | ['warty', 'hoary', 'breezy', 'dapper', 'edgy', 'feisty', 'gutsy', 'intrepid', 'jaunty', 'karmic', 'maverick'] | 01:23 |
| bryceh | >>> | 01:23 |
| bryceh | cjwatson, so yeah this looks like it should work, thanks | 01:23 |
| bryceh | hrm, the one problem is it doesn't appear to give the release _dates_ | 01:27 |
| micahg | distro-info-data will be SRUd as needed | 01:27 |
| jbicha | bryceh: have you heard of libosinfo? | 01:29 |
| bryceh | jbicha, yes, I did hear about that just recently. haven't played with it yet | 01:29 |
| jbicha | I don't know much about it, but it does have a database of disto releases | 01:30 |
| jbicha | http://git.fedorahosted.org/git/?p=libosinfo.git;a=blob;f=data/oses/ubuntu.xml | 01:30 |
| bryceh | 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:30 |
| infinity | bryceh: No, his point was that distro-info will always be accurate. | 01:31 |
| infinity | bryceh: (because data gets SRUed) | 01:31 |
| infinity | 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:31 |
| bryceh | infinity, oh gotcha, but no that's not what I meant | 01:32 |
| infinity | bryceh: Kay, what's the use case for release dates? | 01:32 |
| bryceh | I would expect it to be accurate, else I wouldn't consider it | 01:32 |
| infinity | bryceh: Or did you mean version numbers? | 01:32 |
| bryceh | no, although now that you mention it I don't know that I can get those either | 01:32 |
| infinity | bryceh: distro-info (the CLI) does numbers and codenames, no idea what the python module does. | 01:33 |
| infinity | bryceh: So, what did you want with dates? | 01:34 |
| bryceh | so far I'm only seeing codenames | 01:34 |
| bryceh | well, not so much dates as time since the release | 01:34 |
| infinity | bryceh: I'm trying to sort out why that's valuable. ;) | 01:35 |
| bryceh | 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 |
| infinity | bryceh: What's your cutoff for that? | 01:35 |
| bryceh | like a month or so | 01:35 |
| xnox | bryceh: int(release.version.split('.')[-1])+2? | 01:36 |
| bryceh | xnox, hehe | 01:36 |
| xnox | bryceh: int(release.version.split('.')[1])+2? | 01:36 |
| xnox | is better in case of a point release, e.g. 12.04.1 | 01:36 |
| infinity | bryceh: Again, not sure what the python module has, but the CLI version: "distro-info --date=2012-02-11 --supported" | 01:36 |
| infinity | bryceh: Gives you info as if it were that date. | 01:36 |
| micahg | bryceh: just wait until june/december :) | 01:36 |
| infinity | bryceh: So, just put yourself a month in the past and see if you exist yet! | 01:37 |
| xnox | bryceh: what if the clock/time is wrong on the machine? | 01:37 |
| infinity | Ecxcept that's buggy. | 01:37 |
| infinity | micahg: Hey Micah, fix distro-info. | 01:37 |
| infinity | micahg: --supported lists the devel release. | 01:37 |
| infinity | micahg: That's brimming with wrong. | 01:38 |
| infinity | bdrung: ^ | 01:38 |
| micahg | yeah, that's certainly wrong | 01:38 |
| infinity | Same bug with Debian. | 01:38 |
| infinity | (My machine claims that both wheezy and quantal are supported) | 01:39 |
| bryceh | 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 |
| infinity | (Or, if I go back in time, it tells me precise was supported before it was released) | 01:39 |
| bryceh | (and that would never get updated later) | 01:39 |
| infinity | bryceh: Other than the version, which is, like, the date? | 01:39 |
| infinity | bryceh: lsb_release -rs | 01:40 |
| bryceh | 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:40 |
| infinity | bryceh: Just be liberal in your window, then? | 01:42 |
| bryceh | I guess... | 01:42 |
| * micahg wonders why June/Dec 1 isn't good :) | 01:42 | |
| micahg | that's 4-6 weeks ATM | 01:42 |
| infinity | July4/Dec25, Independence from bugs day, and Merry Christmas, no more bugs. | 01:43 |
| bryceh | 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:43 |
| bryceh | which I suppose isn't a *bad* assumption given history, still... | 01:44 |
| infinity | bryceh: Random dates assume that, release versions assume nothing. | 01:44 |
| infinity | bryceh: Since we change the version when we slip. | 01:44 |
| infinity | bryceh: (See 6.06) | 01:44 |
| bryceh | infinity, true | 01:44 |
| infinity | Granted, this has only happened once. :P | 01:44 |
| bryceh | so, yeah xnox's solution would be the best for that | 01:45 |
| bryceh | 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:46 |
| micahg | bryceh: anonymous launchpad query | 01:47 |
| bryceh | hahaha | 01:48 |
| infinity | Modal dialog box with a question. OBVIOUSLY. | 01:48 |
| infinity | And make it too big to fit on a netbook display, for bonus points. | 01:48 |
| infinity | Also, use Motif. | 01:48 |
| bryceh | micahg, well I can go back to my launchpad query for this once launchpadlib's been updated to python3 | 01:49 |
| micahg | bryceh: actually, distro info should have the release date of the current stable release :) | 01:49 |
| micahg | *planned | 01:49 |
| bryceh | micahg, yeah that'd be nice | 01:49 |
| micahg | i.e. it should know enough about itself, not necessarily the next release immediately though | 01:50 |
| micahg | although in theory we can SRU that as soon as we know as well | 01:50 |
| infinity | If only https://api.launchpad.net/1.0/ubuntu/precise/datereleased didn't throw an embarassing 500. | 01:51 |
| bryceh | infinity, heh | 01:51 |
| infinity | (It has the right date) | 01:51 |
| bryceh | 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 |
| bryceh | and I totally don't blame StevenK for that! | 01:52 |
| infinity | StevenK: *stare* | 01:52 |
| infinity | StevenK: Why does https://api.launchpad.net/1.0/ubuntu/precise/datereleased 500? | 01:53 |
| micahg | XML Parsing Error: syntax error | 01:53 |
| infinity | micahg: Thank god someone's here to cover for my illiteracy. | 01:53 |
| infinity | micahg: Not quite what I meant by "why". | 01:53 |
| micahg | heh, just pointing out it seems to be another issue :) | 01:54 |
| bryceh | actually if you look at the source of that page, it looks like a legit date | 01:54 |
| micahg | s/it/there/ | 01:54 |
| bryceh | so maybe it's just that the content-type wasn't specified? | 01:54 |
| infinity | bryceh: It is the right date, yes, I said that. | 01:54 |
| infinity | If you wget it, it 500s all special-like. | 01:55 |
| StevenK | infinity: Haha. It actually contains the date | 01:55 |
| infinity | 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 |
| infinity | Since you don't need to actually DO any RPC here. | 01:55 |
| infinity | StevenK: I know. | 01:56 |
| StevenK | 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 |
| infinity | StevenK: HAHAHAHAHA. | 01:57 |
| infinity | wget -S https://api.launchpad.net/devel/ubuntu/precise/releasedate | 01:57 |
| infinity | It gives a 404, then proceeds to give me the date raw. | 01:58 |
| infinity | BRILLIANT. | 01:58 |
| infinity | Best. Webapp. Ever. | 01:58 |
| StevenK | infinity: That is what I meant by "[11:55] < StevenK> infinity: Haha. It actually contains the date" | 01:58 |
| infinity | StevenK: Yeah, but I thought you just meant the body (as I was seeing in a web browser) | 01:58 |
| infinity | StevenK: The full response is so much more entertaining. | 01:58 |
| StevenK | Our API sucks. News at 11. | 01:59 |
| infinity | Oh wait, that really was a 404, I typed it wrong... | 02:00 |
| TerminX | 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 |
| infinity | Yeah, the proper URL is a 500. :P | 02:00 |
| ubottu | Launchpad bug 991180 in compiz (Ubuntu) "Ubuntu 12.04 Nvidia Compiz Expo Mipmap" [Undecided,Confirmed] https://launchpad.net/bugs/991180 | 02:00 |
| infinity | And the date. | 02:00 |
| infinity | TerminX: "someone at nvidia"? | 02:02 |
| TerminX | yes, the patch posted to that bug is from one of the linux driver maintainers there | 02:03 |
| infinity | TerminX: To be fair, while you know that, I certainly don't. | 02:04 |
| infinity | 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 |
| infinity | TerminX: It happens. Bugs get missed. Hopping on IRC and calling people "pathetic" doesn't help. | 02:04 |
| wgrant | infinity, StevenK: The 500 doesn't contain the date. | 02:05 |
| infinity | wgrant: I bed to differ. | 02:05 |
| infinity | wgrant: Or beg. | 02:05 |
| TerminX | I called someone pathetic? | 02:05 |
| StevenK | wgrant: Run the wget _S | 02:05 |
| TerminX | I said the situation itself is pathetic | 02:05 |
| StevenK | s/_S/-S/ | 02:05 |
| wgrant | StevenK: What's the got to do with it? | 02:05 |
| wgrant | Accept | 02:05 |
| wgrant | browser sends a text/html or application/xhtml+xml Accept | 02:05 |
| infinity | wgrant: The date is in the body. | 02:05 |
| wgrant | So lazr.restful obliges | 02:05 |
| infinity | wgrant: Anyhow. It's broken either way. | 02:06 |
| wgrant | The 500 body looks to be 'TypeError', not the date | 02:06 |
| wgrant | You can see it at https://api.launchpad.net/1.0/ubuntu/precise/datereleased?ws.accept=application/json | 02:06 |
| infinity | TerminX: You don't see how it came across more confrontational than, say, helpful? | 02:07 |
| StevenK | wgrant: TypeError: datetime.datetime(2012, 4, 26, 12, 9, 10, 437678, tzinfo=<UTC>) is not JSON serializable | 02:07 |
| StevenK | Heh heh | 02:07 |
| wgrant | Yes. | 02:08 |
| wgrant | So it's broken, but not in a way that is even slightly special. | 02:08 |
| RAOF | TerminX: Fun fact: that patch breaks mipmapping on everything else :) | 02:10 |
| wgrant | bryceh: The date type difference is purely a client-side change. It is unrelated to any server-side error. | 02:11 |
| bryceh | wgrant, yeah I know | 02:11 |
| bryceh | wgrant, and IIRC not due to code changes from the launchpad team, so I blame them inappropriately :-) | 02:13 |
| wgrant | bryceh: Yeah, there's not enough people actively working on LP atm to break that :) | 02:13 |
| bryceh | wgrant, exactly | 02:14 |
| bryceh | 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 |
| wgrant | bryceh: It was in httplib2 itself? | 02:15 |
| bryceh | wgrant, it may be, or whatever the layer is above that. it faults in the json decoding logic | 02:16 |
| wgrant | bryceh: Above that is probably wadllib, which we own. | 02:17 |
| bryceh | 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:30 |
| TerminX | 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:31 |
| TerminX | I can't imagine it did much to break it further though since the bug also affects intel | 02:32 |
| RAOF | I have no idea whether he contacted Sam, but I do know that Sam's been working on fixing the mipmapping code. | 02:33 |
| TerminX | yeah, he told me he tried to contact him in several different ways and never got any sort of a response whatsoever | 02:34 |
| TerminX | 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:38 |
| TerminX | 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 |
| TerminX | do you have some sort of report where the patch was applied and something further broke? | 02:40 |
| RAOF | No, because it was never pushed out, as the breakage was picked up in testing. | 02:41 |
| plagman | was this documented anywhere? | 02:45 |
| TerminX | and what configurations was that on? it must have been several different configurations for you to say it "breaks mipmapping on everything else" | 02:45 |
| RAOF | plagman: Not as far as I'm aware, which is disappointing; this has just come up in my conversations with Sam. | 02:46 |
| plagman | in any case, jusding by its contents I strongly doubt that the patch broke anything by itself | 02:47 |
| RAOF | From what I gather it *might* be due to a bug in mesa. | 02:48 |
| RAOF | It would be nice for Sam to provide updates on bugs ☺ | 02:48 |
| plagman | or on irc pings or emails, for that matter | 02:49 |
| RAOF | Apparently he's in Canada at the moment, so he might have been flying? | 02:50 |
| TerminX | the cool thing about email is how when you receive one, it persists in your inbox until you do something with it | 02:50 |
| plagman | 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 |
| plagman | and in this case the patch just reversed that tendency | 02:51 |
| plagman | or Mesa works fine and the patch couldn't have really done anything harmful | 02:51 |
| plagman | and AFAIK Mesa reports it just fine | 02:52 |
| plagman | anyway, I'd be happy to discuss that with Sam over the bug or otherwise if he has any concerns | 02:54 |
| RAOF | 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 |
| RAOF | When I see him around I'll try and get sam to ping you. | 02:56 |
| TerminX | 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:57 |
| RAOF | Or it's hard. | 02:58 |
| StevenK | RAOF: "[54302.526085] NVRM: Xid (0000:01:00): 8, Channel 00000003" makes me have a sad. | 04:20 |
| RAOF | 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:20 |
| pitti | Good morning | 04:21 |
| StevenK | RAOF: Not really, it happens randomly and then X has a large sad. | 04:21 |
| RAOF | Yeah, that's your driver shouting obsceneties at your card. | 04:22 |
| StevenK | RAOF: Yeah, I only just looked up what 'Xid' actually means, the last time I mashed reset | 04:22 |
| StevenK | RAOF: So it's a driver bug? | 04:23 |
| plagman | not necessarily | 04:23 |
| plagman | could be memory corruption, bad HW, etc | 04:23 |
| plagman | could very well be, though | 04:23 |
| plagman | but impossible to say with just that data, that's the symptom | 04:23 |
| RAOF | Ah, you're still here :) | 04:23 |
| StevenK | 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 |
| plagman | yeah, though not at work anymore | 04:24 |
| StevenK | 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 |
| StevenK | (I already have this time, so next time ...) | 04:25 |
| plagman | run nvidia-bug-report.sh as root, after that error message pops up | 04:25 |
| plagman | preferrably while X is still running if that's possible | 04:25 |
| RAOF | I think ubuntu-bug nvidia collects all that information, too. | 04:25 |
| StevenK | Over ssh is okay? | 04:26 |
| RAOF | But that'll feed it to launchpad rather than as a nice tgz | 04:26 |
| plagman | should be, maybe you need to set DISPLAY | 04:26 |
| plagman | trying to narrow it down to a deterministic sequence of actions would be stellar of course | 04:27 |
| plagman | but that's hard | 04:27 |
| StevenK | plagman: Ugh, this script is horrid. :-) | 04:27 |
| plagman | is it? | 04:28 |
| StevenK | append_silent "/etc/redhat-release" | 04:28 |
| StevenK | ... | 04:28 |
| StevenK | append_silent "/etc/gentoo-release" | 04:28 |
| StevenK | Because you know, a for loop is hard. :-) | 04:28 |
| plagman | not that it would tremendously change the end-result | 04:28 |
| plagman | anyway, patches welcome | 04:29 |
| StevenK | plagman: Thanks for the pointer. | 04:30 |
| plagman | generally I would advise running that script and posting the result as an attachment on the nvnews linux forum | 04:30 |
| StevenK | plagman: That script could also grab /etc/lsb-release, since /etc/debian_version on an Ubuntu machine is going to be unhelpful. | 04:31 |
| plagman | does it also grab /etc/issue? | 04:32 |
| StevenK | Yeah, that's the first thing it does in that block. | 04:32 |
| plagman | that would probably cover ubuntu | 04:32 |
| plagman | but yeah, seems lsb-release could have value | 04:32 |
| === trijntje_ is now known as trijntje | ||
| dholbach | good morning | 06:49 |
| === smb` is now known as smb | ||
| === tkamppeter_ is now known as tkamppeter | ||
| bryceh | RAOF, ubuntu-bug nvidia will also generate and collect the .tgz in addition to the stuff we ask for. | 07:14 |
| jibel | pitti, what's your opinion on bug 1013334 , an issue on launchpad's side ? | 07:23 |
| ubottu | Launchpad bug 1013334 in apport (Ubuntu) "apport could not connect to crash database" [Undecided,Confirmed] https://launchpad.net/bugs/1013334 | 07:23 |
| pitti | jibel: no, it's indeed a bug in some hook, I'll follow up on it; thanks! | 07:24 |
| jibel | 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 |
| ubottu | 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 |
| jibel | or is there a way to force apport to file a bug ? | 08:42 |
| pitti | jibel: ah, it says it's already known? | 08:43 |
| jibel | pitti, yes | 08:43 |
| pitti | that's an apport bug indeed, it should allow you to file bugs for closed master bugs | 08:43 |
| pitti | jibel: you can edit the .crash file and remove the KnownBug: field | 08:43 |
| jibel | pitti, ack | 08:44 |
| pitti | jibel: sorry, KnownReport: | 08:44 |
| pitti | jibel: and then run it through apport-bug again; that should work | 08:44 |
| bdrung | infinity: define 'supported' | 08:45 |
| bdrung | bryceh: you can call distro-info --date=2012-05-28 --supported if you want to know what was supported last month | 08:48 |
| jibel | pitti, it worked thanks! | 08:53 |
| === doko_ is now known as doko | ||
| === StaffRingedSeal is now known as Myrtti | ||
| jml | how can I get the dependency dag for a package? | 09:09 |
| bryceh | bdrung, ok, and that should work similarly through the python api? | 09:20 |
| bryceh | bdrung, also, any concerns if [python-]distr-info is included in the CD image? | 09:21 |
| diwic | jml, see your email | 10:18 |
| alexbligh | 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? | 11:13 |
| === MacSlow is now known as MacSlow|lunch | ||
| cjwatson | 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 |
| cjwatson | alexbligh: It should be possible to make the same *source* package work on both. | 11:35 |
| cjwatson | 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). | 11:37 |
| === 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 | ||
| alexbligh | cjwatson, thanks | 12:19 |
| === yofel_ is now known as yofel | ||
| === _salem is now known as salem_ | ||
| === Nigel is now known as G | ||
| pgraner | ogra_, hey I think I might have found what the issue is with the monitors | 13:16 |
| ppisati | pgraner: if you have an installed system, give a try to this one: | 13:26 |
| ppisati | pgraner: http://people.canonical.com/~ppisati/linux-image-3.4.0-202-omap4_3.4.0-202.7_armhf.deb | 13:26 |
| ppisati | pgraner: it should resolve the video issue | 13:26 |
| pgraner | ppisati, ok, I'll try after this call I'm about to be on. | 13:29 |
| pgraner | ppisati, I'm finding when it fails I don't get a /sys/devices/omapdss/display0/edid file | 13:29 |
| ppisati | pgraner: edid is read after the monitor is detected, looks like hotplug is broken | 13:33 |
| ogra_ | pgraner, oh ? | 13:37 |
| pgraner | ogra_, see my comment above | 13:38 |
| ogra_ | ah, sweet | 13:38 |
| mterry | mvo, hello! FYI last night I just went ahead and committed a pep8 branch and some test improvement commits. I assumed such things don't need reviews | 13:46 |
| mterry | (to update-manager) | 13:46 |
| mvo | mterry: yeah, thats fine | 13:47 |
| mvo | mterry: thanks for this, given all the recent work I consider u-m really team owned, but me owned anymore | 13:47 |
| mvo | (which is a good thing :) | 13:47 |
| mterry | mvo, you can't escape that easily. ;) | 13:48 |
| cjwatson | Not sure anyone else really understands all the quirks handling and such as yet | 13:49 |
| stgraber | mvo: the code may be team owned, the bugs are still yours, don't worry ;) | 13:49 |
| cjwatson | Or indeed the controller | 13:49 |
| mvo | mterhaha | 13:52 |
| mvo | well, its fine, I don't try to sneak out here :) | 13:52 |
| mvo | just saying that I shouldn't be the lock/bootleneck/gil/bkl | 13:53 |
| mpt | james_w, hi, I'd like to ask you some questions about phased updates <https://wiki.ubuntu.com/PhasedUpdates#update-manager> so I can adjust the settings design | 14:09 |
| james_w | mpt, hi, sure thing | 14:21 |
| mpt | james_w, in "t = x/100 * (s^128 - 1)", what are t, x, and s? | 14:21 |
| james_w | mpt, good question :-) | 14:22 |
| james_w | mpt, try now? | 14:26 |
| james_w | mpt, it's converting a percentage as an integer between 0 and 100 in to a value to be compared with the output of md5 such that around x% of machines will fall below the value in the next step | 14:27 |
| james_w | i.e. it's just an implementation detail of how the percentage of machines is selected | 14:28 |
| james_w | otherwise in the next step (floor(md5(...)/2^128)) could be calculated and compared to x directly | 14:28 |
| mpt | james_w, ok. Next question: Why have an X-Update-Percentage integer instead of an X-Update-Phase float? Are you worried about the crippling CPU requirements of a floating arithmetic operation? :-) | 14:30 |
| james_w | heh | 14:31 |
| james_w | no strong reason for either I don't think | 14:31 |
| james_w | it will likely use floating point anyway with that algorithm as written, but could be avoided | 14:32 |
| james_w | mainly I think I chose that as it's quicker for humans to grasp | 14:32 |
| james_w | but it can certainly be changed if there's a good reason to use a float | 14:32 |
| mpt | james_w, only because it allows simplifying the definition | 14:33 |
| mpt | james_w, so would this be correct? "A computer is in the current testing set for a package if X-Update-Phase * (2^128 - 1) >= md5(machine-id + packagename + packageversion)." | 14:33 |
| james_w | mpt, yeah | 14:38 |
| mpt | splendid | 14:38 |
| james_w | though we probably need to shift the bounds slightly | 14:38 |
| james_w | otherwise some unlucky person could get the update if X-Update-Phase == 0 | 14:38 |
| mpt | So change ">=" to ">"? | 14:39 |
| james_w | and lose the "-1" I think | 14:39 |
| === Ursinha` is now known as Ursinha | ||
| mpt | james_w, next question: Are you familiar with the current emergent client-side phasing? https://wiki.ubuntu.com/SoftwareUpdates#Launching_automatically | 14:39 |
| james_w | otherwise X-Update-Phase == 1.0 doesn't mean that everyone gets it | 14:39 |
| james_w | yeah | 14:40 |
| mpt | james_w, so do you think this new phasing should be instead of, or in addition to? | 14:40 |
| james_w | and I'm not sure we need to do this explicit stuff given that we have that | 14:40 |
| mpt | (or not at all because, yeah) | 14:41 |
| mpt | An advantage of the explicit phasing might be that you can ramp it down again | 14:41 |
| james_w | that's true | 14:41 |
| mpt | or at least it gives you a mechanism to ramp down or pause an update that is less brutal than pulling the update entirely. | 14:41 |
| james_w | I'm not sure how the explicit would work with the settings people currently have though | 14:41 |
| mpt | Well, the reason I'm looking at this now is to change the settings design | 14:42 |
| mpt | But a disadvantage of the explicit phasing is that I don't know how to word it. | 14:42 |
| cousteau | will Ubuntu develop a handwritten-looking font? (if it were metrics-compatible with Comic Sans but less ugly that would rock) | 14:42 |
| james_w | my instinct is that putting them together is bad because it stretches out the phasing | 14:42 |
| james_w | mpt, I meant more with the spirit of the settings rather than their exact values | 14:43 |
| seb128 | bdmurray, hey, I heard you are doing SRU reviews today, could you review compiz,libunity,bamf? We would like to get those out this week if possible to have room for a new SRU round in 2 weeks | 14:43 |
| cousteau | or alternatively, include one of the many free handwritten-looking fonts that there already are (license would be a topic to look into) | 14:43 |
| mpt | james_w, the spirit of the current settings is to prevent you from being nagged two days in a row (unless it's a security update). | 14:43 |
| james_w | mpt, e.g. I don't know if switching to explicit means that everyone will get prompted for updates every day | 14:43 |
| mpt | cousteau, in general we lack someone with responsibility to say "okay, I have X MB of the Ubuntu ISO allocated to fonts, what would be the best possible default selection" | 14:44 |
| cousteau | I see | 14:44 |
| xnox | cousteau: about other design stuff #ubuntu-design channel might be better. Not sure if there is one just for fonts. | 14:45 |
| cousteau | maybe a package then... although there are already several packages | 14:45 |
| mpt | cousteau, and to get new fonts packaged -- there are all kinds of interesting free fonts from the League of Moveable Type and elsewhere, which aren't easily installable. | 14:45 |
| cousteau | xnox, ok | 14:45 |
| cousteau | how can a font not be easily installable? I usually just copy them to ~/.fonts/SomeFont/ | 14:46 |
| mpt | james_w, it doesn't, but it means it's pure chance. Depending on that formula, you might be nagged two days in a row, or 27 days apart, and there's no way to guess in advance without knowing the name of the package that will next be updated. | 14:46 |
| james_w | mpt, indeed, but in aggregate we can have some idea | 14:47 |
| james_w | if we push out an update a day then on average you will be prompted daily | 14:47 |
| mpt | cousteau, well sure, but I mean easily findable. Ubuntu Software Center has a Fonts category, but it contains only fonts that are packaged, and the UI isn't optimized for fonts. | 14:47 |
| mpt | e.g. you can't see previews when searching, things like that. | 14:48 |
| james_w | and I don't know if allowing that to be limited to once a week fundamentally interferes with the aims of phased updates | 14:49 |
| cousteau | I see... well, I'm not a big fan of the software center (although it's probably easier than aptitude or synaptics) | 14:49 |
| * james_w goes to get some food and think about it | 14:49 | |
| cousteau | maybe changing the icon of those packages to a representation of the font | 14:50 |
| mpt | cousteau, that would be nifty. In the long run I'd love to see a separate font utility for buying/installing/removing fonts ... but even fixing those icons in USC would be an improvement. | 14:52 |
| cousteau | a "software center for fonts" would be an interesting idea | 14:53 |
| doko | what is wrong with: | 14:53 |
| doko | W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/quantal/Release Unable to find expected entry 'main/binary---add-architecture'/Packages' in Release file (Wrong sources.list entry or malformed file) | 14:53 |
| cousteau | What I want to avoid, essentially, is that an artist (or anyone) decides to use Comic Sans because it has "comic" in it | 14:53 |
| doko | with deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports/ quantal main universe | 14:54 |
| doko | cjwatson, slangasek: ^^^ | 14:54 |
| cjwatson | doko: Is that in lxc? | 14:54 |
| cjwatson | doko: If so, bug 1017862, I believe | 14:54 |
| ubottu | Launchpad bug 1017862 in lxc (Ubuntu Precise) "Migrate to dpkg --add-architecture to track foreign architecture in template lxc-ubuntu" [Undecided,New] https://launchpad.net/bugs/1017862 | 14:54 |
| mpt | james_w, the reason Microsoft has "patch Tuesday" is so that admins and other people can plan for and organize installation of updates all at once. I'm not *at all* suggesting we should do that for security updates, but there's a similar motivation in grouping non-critical updates together so you install them all in one go. | 14:55 |
| cousteau | mpt, also, an "identify this font" online (or server-based) interface would be nice. Like WhatTheFont but for free fonts. | 14:55 |
| doko | cjwatson, no, just an amd64 chroot | 14:56 |
| cjwatson | doko: I'm not sure then; I'd suggest getting an strace -f to find out where apt's getting that string from | 14:56 |
| * jml discovers dpkg-dev-el | 14:57 | |
| arand | cousteau: There's http://fonts.debian.net/ which is outdated by now, but that combined with apturl, maybe? | 14:57 |
| mpt | cousteau, try Purisa. <http://apt.ubuntu.com/p/fonts-tlwg-purisa> It concentrates on Thai, but it has Latin characters too. | 14:57 |
| cousteau | I think I once tried it... | 14:58 |
| cousteau | actually when I said "handwritten" I was thinking more "comic" | 14:59 |
| barry | mvo: any word on command-not-found upload? | 14:59 |
| cousteau | (Komika Text is rather nice for both comic and handwritten imo... wonder if its license would allow to add it to repositories) | 15:00 |
| smoser | can someone help me out here. | 15:04 |
| smoser | i'm not sure where to go loking for this. | 15:04 |
| smoser | i laucnhed a fresh instance of quantal on ec2 | 15:04 |
| smoser | i apt-get install 'pastebinit' | 15:04 |
| smoser | it decides it needs to update-initramfs | 15:05 |
| smoser | is there some reason for that? or does update-initramfs always have to run on installation? | 15:05 |
| cjwatson | smoser: I suspect that's a trigger previously pulled by some other package that hadn't been activated. | 15:09 |
| cjwatson | Perhaps due to an installation failure or something when building the image. | 15:10 |
| smoser | cjwatson, what sort of thing would do that? | 15:10 |
| cjwatson | Anything that delivers files that get copied into the initramfs. | 15:10 |
| cjwatson | You can see the mechanism near the top of /usr/sbin/update-initramfs. | 15:11 |
| smoser | thanks. that was my next question. | 15:11 |
| cjwatson | So look for "update-initramfs: deferring update" in your build logs, compare with where update-initramfs is actually run, and see if there's a mismatch. | 15:11 |
| cjwatson | Then investigate from there. | 15:11 |
| smoser | gracias | 15:12 |
| cjwatson | de nada | 15:12 |
| james_w | mpt, I've added some thoughts to the unresolved questions section. | 15:13 |
| james_w | mpt, basically I think having an option like today to not prompt for non-security updates every day will be ok | 15:14 |
| james_w | we just need to understand that X-Update-Percentage: 80 means that < 80% of machines will have it installed | 15:14 |
| james_w | which is true anyway, that option would just make even more sure of that | 15:14 |
| * mpt tries to sketch some phase curves | 15:20 | |
| infinity | bdrung: I would argue that unreleased/devel releases shouldn't show as "supported", personally. | 15:22 |
| mpt | james_w, so if t = time, the normal update curve (resulting from the wait-a-week client behavior) is u(t), and your phase curve is p(t), the resulting update curve will be u(t)*p(t). | 15:25 |
| james_w | mpt, I think so, but my maths isn't up to thinking in a bounded plane | 15:27 |
| mpt | james_w, if you were in the office I could show you on this here whiteboard. :-) But give me a few minutes and I'll sketch it | 15:28 |
| james_w | mpt, I sketched a couple myself | 15:28 |
| james_w | two linear curves gave an s curve for me | 15:28 |
| bdmurray | seb128: neither of these bamf bugs have precise tasks (I've added them) nor a regression potential statement | 15:29 |
| mpt | james_w, p(t) might be linear, but u(t) is not, because people don't have their computer on every day, and even if they do, sometimes they'll click "Remind Me Later" | 15:30 |
| james_w | mpt, right, I was assuming u(t) was linear in that case | 15:30 |
| seb128 | sil2100, didrocks: ^ cf bdmurray's comment on the bamf SRU | 15:35 |
| sil2100 | seb128, bdmurray: looking into it, but I remember adding that during the sprint... | 15:36 |
| didrocks | and I remember double checking that | 15:37 |
| didrocks | well, regression potential is empty | 15:38 |
| sil2100 | Ouch | 15:39 |
| didrocks | sil2100: can you file them, please? | 15:39 |
| sil2100 | Will do, I think I didn't save them or something | 15:39 |
| seb128 | sil2100, didrocks: the precise lines where missing as well, anyway that's easily fixed | 15:40 |
| didrocks | seb128: well, when filing them for 20 bugs, I guess missing two in the row was unavoidable in double checking ;) (didn't happen in "my time" though :p) | 15:41 |
| ogra_ | hmm, do we have any magic cmdline option to debug plymouth ? | 15:43 |
| ogra_ | i suspect its broken on arm but cant find anything in any logs | 15:43 |
| bdmurray | I think there is a boot option / switch | 15:45 |
| bdmurray | https://wiki.ubuntu.com/Plymouth#Debugging | 15:45 |
| * ogra_ hugs bdmurray | 15:46 | |
| bdmurray | ogra_: ^ plymouth:debug | 15:46 |
| ogra_ | thanks ! | 15:46 |
| bdmurray | regarding the libunity SRU bug 893688 shouldn't be fix released for precise | 15:47 |
| ubottu | Launchpad bug 893688 in libunity "Unity.ActivationResponse does not work properly for python scopes" [Low,Fix committed] https://launchpad.net/bugs/893688 | 15:47 |
| james_w | ah, I see the difference, I think you were considering only a single update, and so update-manager opens as soon as the phase includes the current machine? | 15:48 |
| sil2100 | bdmurray: regression potentials editted | 15:48 |
| james_w | mpt, ^ | 15:48 |
| bdmurray | sil2100: thanks | 15:48 |
| mpt | james_w, I was considering a naive implementation where update-manager starts treating the update as being "available" only once the phase includes the current machine | 15:49 |
| mpt | james_w, and then starts the clock from that point | 15:49 |
| james_w | mpt, right, I think we got different curves because I was assuming that update-manager would be opening for other things | 15:50 |
| james_w | and so it might have opened just before your machine became part of the set, meaning that even though you were in the testing set now you wouldn't see update-manager for a week | 15:50 |
| mpt | james_w, we don't have to do it that way, though. update-manager could do a maximum instead: open when the computer is in the phase set, or when the week has passed, whichever is later. | 15:51 |
| james_w | mpt, my understanding was each day would go: are there security updates? no. Are there other updates for which I am in the testing set? Yes. Has it been a week since I last opened? | 15:53 |
| mpt | james_w, that makes sense. That would avoid the kink in this curve: http://imgur.com/rT5iV | 15:57 |
| mpt | (not that the kink matters much, but anyway) | 15:57 |
| bdmurray | seb128, sil2100: none of these compiz bugs are fixed in Quantal? | 15:58 |
| james_w | mpt, yeah, with that scheme I had something like a smooth version of your yellow curve | 15:58 |
| james_w | of course if we want to drive something like the orange one we can make p(t) non-linear | 15:59 |
| sil2100 | bdmurray: which bugs? | 15:59 |
| bdmurray | any of the bugs associated with the SRU for precise of compiz | 16:00 |
| seb128 | sil2100, the compiz sru ones | 16:00 |
| seb128 | https://bugs.launchpad.net/compiz-core/+bug/993608 | 16:00 |
| seb128 | https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1006335 | 16:00 |
| ubottu | Launchpad bug 993608 in compiz (Ubuntu Precise) "CMake Error at FindCompiz.cmake:84 (include): include could not find load file: CompizDefaults" [Undecided,New] | 16:00 |
| bdmurray | bug 1005569 for example | 16:00 |
| ubottu | Launchpad bug 1006335 in compiz (Ubuntu) "[callgrind] compiz spends ~7% of its time inserting into and destructing the events list in PrivateScreen::processEvents()" [Medium,Triaged] | 16:00 |
| ubottu | Launchpad bug 1005569 in compiz (Ubuntu Precise) "[callgrind] compiz spends ~25% of its time constructing/destructing strings in PrivateScreen::handleActionEvent" [High,In progress] https://launchpad.net/bugs/1005569 | 16:00 |
| mpt | james_w, ok, thanks for clarifying this with me, I understand it better now | 16:00 |
| sil2100 | bdmurray: they are, since those were cherry-picked from trunk, and trunk is used now in quantal | 16:00 |
| sil2100 | didrocks: you released compiz for quantal yesterday? | 16:01 |
| seb128 | bdmurray, oh | 16:01 |
| james_w | mpt, no problem, do you feel this is something that will work ok, and something that you can phrase for users? | 16:01 |
| seb128 | bdmurray, the quantal upload is in quantal-proposed | 16:01 |
| seb128 | sil2100, didrocks: ^ | 16:01 |
| seb128 | bdmurray, and launchpad will close them only when it's copied to quantal | 16:01 |
| seb128 | bdmurray, so they are pending "end of a2 freeze" | 16:01 |
| mpt | james_w, possibly. We can say something slightly vague like "After a week" (not mentioning exactly how long after...) | 16:01 |
| bdmurray | seb128: hmm, okay | 16:02 |
| seb128 | bdmurray, but you can probably count quantal-proposed as them being uploaded | 16:02 |
| didrocks | sil2100: I did, and yes, it's in proposed | 16:03 |
| bdmurray | seb128: well what is the point of having it fixed in the development release? Is it so the package gets some testing first? | 16:03 |
| didrocks | bdmurray: it's to ensure we have both fixes in both sides | 16:04 |
| seb128 | bdmurray, it's mostly so we are sure that bugs will get fixed in the new serie | 16:04 |
| didrocks | bdmurray: meaning, we won't trigger regressions but forgetting a fix | 16:04 |
| didrocks | by* | 16:04 |
| seb128 | bdmurray, some SRU team members are fine with having the fix commited in the vcs or available in upstream git pending the next update | 16:04 |
| slangasek | seb128: "end of a2 freeze" - but you're supposed to be able to upload to quantal-proposed? | 16:05 |
| seb128 | bdmurray, but even if you consider testing, the new version is being tested by quantal-proposed users | 16:05 |
| slangasek | oh, you say this one is | 16:05 |
| slangasek | so n/m | 16:05 |
| didrocks | slangasek: it's in -proposed | 16:05 |
| seb128 | slangasek, I'm waiting for it to be copied to quantal-proper :p | 16:05 |
| didrocks | I did the upload at the same time | 16:05 |
| slangasek | "quantal-proposed users" - there's not supposed to be any of those | 16:05 |
| slangasek | and we should not assume anything is getting tested by users in quantal-proposed | 16:06 |
| seb128 | slangasek, well, that's what you get by having freezes ;-) | 16:06 |
| seb128 | shrug | 16:06 |
| * ogra_ wonders if the dropping of the intel drm stuff broke plymouth on arm | 16:06 | |
| * ogra_ tries to downgrade to the precise version ... lets see | 16:06 | |
| seb128 | I want to kill alpha freezes | 16:06 |
| slangasek | that seems to be quite a different topic | 16:06 |
| infinity | bdmurray: My understanding of "fixed in devel" has always been that we want to make sure it's fixed in development so there won't be surprise regressions when people upgrade, not for extra testing (though testing is nice). | 16:07 |
| james_w | mpt, ok | 16:07 |
| seb128 | slangasek, anything as long as SRUs don't get blocked because stuff in quantal are in quantal-proposed and can't be copied over :p | 16:07 |
| infinity | bdmurray: Since "it's uploaded to quantal" is no guarantee anyone's actually using it (though, in the case of unity, people would be). | 16:07 |
| bdmurray | well the language does say 'It is, in general, not appropriate to release bug fixes for stable systems without first testing them in the current development branch.' | 16:07 |
| didrocks | that wasn't the practice at all | 16:08 |
| james_w | mpt, the other thing is that this requires LP changes as well as client-side, so if the new UI doesn't make sense for the current scheme we may want to be able to turn it on/off easily. | 16:08 |
| infinity | slangasek: I don't think it's safe to assume that anything in quantal-release is getting heavy testing either (though, like I said, we can be fairly sure unity is). | 16:08 |
| infinity | slangasek: For some leaf package, mind you, "uploaded to devel release" means nothing, except the guarantee that the fix won't regress when someone upgrades from 12.04 to 12.10 (which is the point of that bullet point, I thought). | 16:09 |
| didrocks | infinity: I had the same understanding at the time | 16:09 |
| ogra_ | slangasek, as one of the plymouth gods in here, does anything in the log from https://launchpadlibrarian.net/108854042/plymouth-debug.log stick out on a glance ? seems all arm images have the same prob that plamouth only shows a black screen on boot | 16:13 |
| bdrung | bryceh: yes, it's similar for the python API (the functions have an optional date parameter). i have no concerns about shipping it on CDs. | 16:16 |
| bdrung | infinity: it depends on the definition of support. the current behaviour is correct if unsupported = get's security updates | 16:18 |
| infinity | bdrung: Hrm? I assume you meant "supported = gets security updates". | 16:19 |
| bdrung | i meant unsupported = get's no security updates | 16:20 |
| infinity | bdrung: And that's not true at all. We often have security updates hit all stable/supported releases but miss the devel release because "we know it's fixed properly in the new upstream we're releasing in a week". | 16:20 |
| bdrung | infinity: but the updates will hit the devel release sooner or later | 16:20 |
| infinity | bdrung: Devel releases (in neither Ubuntu nor Debian) are "supported" in the way that any end-user would consider using the word, I suspect. | 16:21 |
| infinity | s/are/aren't/ | 16:21 |
| infinity | bdrung: Devel releases also have packages randomly dropped from the archive, and other such forms of "not supported" that aren't true in stable/supported releases. | 16:21 |
| bdrung | infinity: because end-user define "supported" as stable | 16:21 |
| infinity | bdrung: Well, there's also how *we* define supported, which is basically the same. :P | 16:22 |
| infinity | bdrung: Note the lack of quantal on http://changelogs.ubuntu.com/meta-release ;) | 16:23 |
| bdrung | infinity: there we have the definition difference: stable VS get's updates | 16:23 |
| infinity | bdrung: And we've tried to make it clear in Debian on many occasions that unstable/testing are both not "supported" too. | 16:23 |
| * ogra_ suspects the pylmouth issue has something to do with "[./plugin.c] ply_renderer_head_map:Creating buffer for 1920x1200 renderer head | 16:23 | |
| ogra_ | [./ply-renderer-libkms-driver.c] create_buffer:Could not allocate GEM object for frame buffer: 22" | 16:23 |
| bdrung | infinity: that file is called *release* | 16:23 |
| infinity | bdrung: Yeah, I was looking at the "Supported: N" stanza. | 16:24 |
| infinity | bdrung: http://changelogs.ubuntu.com/meta-release-development | 16:24 |
| infinity | bdrung: Which has a 0 for quantal. :) | 16:24 |
| === Exio is now known as EXIO | ||
| === wcchandler is now known as WCCHANDLER | ||
| slangasek | infinity, bdmurray, seb128: so I think one of the benefits to having fixes actually uploaded to the dev release before published in -updates *is* that it gives us additional confidence that the fix works; but yeah, if it's clearly on track I don't think we should treat that as a blocker for an SRU since the main purpose is to ensure we don't regress | 17:02 |
| * ogra_ grumbles ... libdrm-intel seems to give us something that makes plymouth work on arm framebuffers :( | 17:03 | |
| * ogra_ tries that theory and runs a plymouth build that pulls libdrm_intel back in | 17:03 | |
| slangasek | ogra_: plymouth> it looks to me like the regression is that the new plymouth in quantal now supports a generic DRM backend, so it's actually talking to omapdrm instead of using the framebuffer? | 17:04 |
| ogra_ | apart from the fact that there is no omapdrm that might be right :) | 17:05 |
| slangasek | ogra_: try rm /lib/plymouth/renderers/drm.so | 17:05 |
| ogra_ | this kernel still uses omapdss | 17:05 |
| slangasek | ogra_: your log says otherwise :) | 17:05 |
| slangasek | [./plugin.c] load_driver:Attempting to load driver 'omapdrm' | 17:05 |
| ogra_ | hmm, intresting | 17:05 |
| slangasek | so... maybe the problem is you have a drm driver not connected to the monitor :P | 17:05 |
| ogra_ | yup, that could be, i see the same issue on ac100 and omap though | 17:06 |
| ogra_ | (same behavior, havent logged yet) | 17:06 |
| ogra_ | so something changed that made it stop working on plain framebuffers i think | 17:06 |
| slangasek | cjwatson: do you know if we ever have /dev *not* by devtmpfs nowadays? Is that supported? | 17:06 |
| slangasek | ogra_: attach a separate log for ac100, please | 17:07 |
| ogra_ | yes, will do | 17:07 |
| slangasek | plymouth is *very* hardware specific, don't try to generalize bugs there | 17:07 |
| ogra_ | ok | 17:07 |
| slangasek | and please try that rm drm.so and see if that works - plymouth always prefers the drm renderer if it can get it, and only then falls back to fb | 17:07 |
| ogra_ | let me reinstall the qunatal version and try the removal ... | 17:07 |
| ogra_ | slangasek, thanks, that gets me fsck interaction and a splash :) | 17:13 |
| infinity | slangasek: It could be that it's universally loading omapdrm on all arm* machines, regardless of whether the driver does anything useful for the platform (which it won't for any right now, and won't for anything but omap* when the kernel is fixed) | 17:15 |
| infinity | slangasek: Which would explain ac100 being broken too. | 17:15 |
| ogra_ | ?? | 17:16 |
| ogra_ | how could ac100 load an omap4 kernel driver ? | 17:16 |
| ogra_ | or even think thats there | 17:16 |
| infinity | ogra_: I'm referring to the userspace. We don't *have* an omapdrm kernel driver yet, do we? :P | 17:16 |
| infinity | ogra_: We only just recently got an omap drm userspace library. | 17:17 |
| ogra_ | i think there is a stub or so | 17:17 |
| infinity | ogra_: And that's likely exploding the world. | 17:17 |
| ogra_ | right | 17:17 |
| ogra_ | though whats that userspace thing you talk about ? | 17:17 |
| * ogra_ never heard of omapdrm userspace libs | 17:17 | |
| infinity | libdrm-omap1 | 17:18 |
| infinity | Introduced in the recent libdrm upload. | 17:18 |
| ogra_ | oh ! | 17:18 |
| infinity | Needed for the omapdrm kernel driver, which won't work right until 3.5 | 17:18 |
| ogra_ | yeah, that would be it | 17:18 |
| ogra_ | damned, another package to watch :P | 17:18 |
| infinity | Obvsiouly, if that *is* causing issues, something's gone wrong, since having a drm userspace library shouldn't blow up the world (otherwise, having intel/nouveau/radeon installed on every x86 machine would end in tears) | 17:19 |
| infinity | So, this may need some input and fixing from Rob. | 17:20 |
| ogra_ | well, lets see how the ac100 behaves ... | 17:20 |
| ogra_ | but i wont test that today anymore ... | 17:20 |
| ogra_ | given i have to do my patriotic duty in 2h and watch the game i'll be off soon :) | 17:21 |
| ogra_ | err, 1h | 17:21 |
| slangasek | infinity: libdrm-omap1 still shouldn't explode ac100 unless /dev/dri/card0 is being created, and that's a kernel problem | 17:32 |
| infinity | slangasek: Well, even in that case, it still shouldn't. | 17:34 |
| slangasek | infinity: the issue on omap4 is that there *is* a /dev/dri/card0 and it's broken | 17:34 |
| infinity | slangasek: That certainly wouldn't help. | 17:34 |
| slangasek | I'm not going to speculate on the ac100 until I see a log :) | 17:34 |
| ogra_ | on ac100 there definitely isnt | 17:35 |
| ogra_ | a /dev/dri/card0 i mean | 17:35 |
| cjwatson | slangasek: /dev not by devtmpfs> Not if there's an initramfs, but I'm not sure about the non-initramfs case. | 17:35 |
| ogra_ | the ac100 3.1 kernel has similar probs with the framebuffer though (only works if you set console=tty1 now) | 17:36 |
| slangasek | cjwatson: AFAICS we have nothing that mounts it by default in the initramfsless case | 17:38 |
| slangasek | so hmm, maybe that explains some previously-reported bugs | 17:38 |
| slangasek | cjwatson: I ask because we have a job to fallback to calling MAKEDEV if /dev isn't devtmpfs, and lintian complains | 17:39 |
| slangasek | so I was wondering if that still makes sense or if we should drop the makedev dep | 17:39 |
| slangasek | I think I'm inclined to drop it anyway; makedev is prio: extra in Debian, and this job is definitely a no-op in the default case for Ubuntu | 17:40 |
| cjwatson | I would rather we arranged to mount it early, for consistency | 17:40 |
| cjwatson | Could init do this as part of its initial setup? | 17:40 |
| cjwatson | Or is that evil? | 17:41 |
| slangasek | cjwatson: I think it's evil to have init hard-code the information about what fs to mount | 17:56 |
| slangasek | devtmpfs is the flavor of the month, but who knows what it'll be next round | 17:56 |
| cjwatson | Perhaps we need an Upstart job for it that runs absolutely first, then | 17:57 |
| cjwatson | Maybe mountall, and audit everything earlier, would do? | 17:57 |
| slangasek | maybe | 17:57 |
| slangasek | mountall itself is already 'start on startup' and most things can't start until after | 17:58 |
| cjwatson | I see the job in question is already pretty early, but it's kicked off from mountall AIUI | 17:58 |
| cjwatson | Since it's "start on mounted MOUNTPOINT=/dev" | 17:58 |
| slangasek | right | 17:58 |
| cjwatson | Actually wait | 17:58 |
| cjwatson | ./src/fstab:16:none /dev devtmpfs,tmpfs mode=0755 0 0 | 17:58 |
| slangasek | my question about that is why /dev would ever be mounted but *not* be devtmpfs | 17:58 |
| cjwatson | So won't mountall already get this right? | 17:58 |
| slangasek | yeah, it appears so | 17:58 |
| slangasek | I had to think twice about what the 'none' there meant | 17:58 |
| cjwatson | Yeah, I'm having a hard time seeing how - either the kernel or a pathological initramfs would have to have done it | 17:59 |
| * slangasek nods | 18:00 | |
| slangasek | or a pathological /etc/fstab overriding /lib/init/fstab | 18:00 |
| cjwatson | Oh, well, if the kernel doesn't have devtmpfs, then it falls back to tmpfs | 18:00 |
| cjwatson | I think that's what that code in the job is for | 18:00 |
| slangasek | but does it make sense to install makedev on all machines to cater to that? | 18:01 |
| === dpb__ is now known as Guest1484 | ||
| cjwatson | devtmpfs is still optional, of course | 18:02 |
| cjwatson | No, I don't think so | 18:02 |
| cjwatson | Well, the failure mode is unfortunate of course | 18:02 |
| cjwatson | Do Debian kernels all have devtmpfs nowadays? | 18:02 |
| cjwatson | slangasek: So, how about this, simpler option | 18:04 |
| slangasek | I don't know if they all have devtmpfs, but surely any that don't must cope with the makedev requirement some other way | 18:04 |
| slangasek | given that it's prio: extra | 18:04 |
| cjwatson | slangasek: Ship /lib/mountall/devices/ or some such, which is a bit like /lib/udev/devices/, only this one contains the output of 'MAKEDEV std console fd ppp tun' and is only used in the non-devtmpfs case | 18:05 |
| cjwatson | Then you can just copy it, and it's a lightweight runtime requirement | 18:05 |
| slangasek | hmm | 18:05 |
| slangasek | that risks skew with the output of the makedev command | 18:05 |
| slangasek | and I'm still not sure why it should be needed at all on a recent system (Debian or Ubuntu) | 18:06 |
| cjwatson | Homebrew kernels | 18:06 |
| slangasek | but nothing's doing this in Debian today | 18:06 |
| slangasek | there's no equivalent to that job in Debian | 18:06 |
| cjwatson | In the sysvinit case? | 18:07 |
| slangasek | yeah | 18:07 |
| cjwatson | Maybe udev deals with it ... | 18:07 |
| slangasek | I believe it does | 18:07 |
| cjwatson | If it's being dealt with somehow, I'm certainly in favour of ditching the mounted-dev code, but it would be nice to know how | 18:08 |
| * slangasek nods | 18:08 | |
| cjwatson | There's /etc/udev/links.conf | 18:10 |
| cjwatson | (In Debian) | 18:10 |
| cjwatson | Which is read a couple of layers deep by /etc/init.d/udev | 18:12 |
| cjwatson | With Upstart, the question is whether that's early enough, because it's possible for other things to start between mounted-dev and udev | 18:13 |
| cjwatson | OTOH if you don't have a /dev/{null,console} then Upstart can't start any jobs | 18:13 |
| cjwatson | Anyhow, I think it is pub time | 18:13 |
| slangasek | yes; udev isn't started until "virtual-filesystems" are up, and things may assume that includes MAKEDEV std | 18:21 |
| slangasek | but we already don't work with initramfsless kernels because of the /dev/pts issue... I'm not sure that requiring users to hand-install makedev if they use a devtmpfsless kernel is really an issue | 18:23 |
| hallyn | @pilot in | 18:32 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal A2 prep | Archive: please use -proposed | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: hallyn | ||
| === zyga is now known as zyga-afk | ||
| === Pierre-Loup is now known as Plagman_ | ||
| ScottK | jelmer: Are we going to have a fix for Bug #1014570 soon? | 18:54 |
| ubottu | Launchpad bug 1014570 in bzr (Ubuntu Quantal) "bzr: Unable to sign commits: "no terminal at all requested"" [High,In progress] https://launchpad.net/bugs/1014570 | 18:54 |
| === ChanServ changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: hallyn | ||
| === cpg|away is now known as cpg | ||
| pgraner | ogasawara, ppisati, ogra_ : the new kernel linux-image-3.4.0-202-omap4_3.4.0-202.7_armhf.deb works just fine | 19:25 |
| ogasawara | pgraner: cool, I'm prepping the upload on behalf of ppisati right now | 19:26 |
| pgraner | ogasawara, great, appreciate it | 19:26 |
| infinity | ev: I forget, did I leave an HDMI/DVI-D cable in London, believing it was yours? | 19:27 |
| infinity | ev: If so, turns out it's vorlon's. ;) | 19:27 |
| ogasawara | skaet: re: omap4 kernel ^^, do you want me to upload that straight to the quantal release pocket or -proposed? Right now I have it (and the meta package since it's an ABI bump) going to -proposed. | 19:28 |
| infinity | pgraner / ogasawara: Yay. | 19:28 |
| infinity | ogasawara: Proposed, if you plan to push the meta at the same time, release if you're willing to wait on the meta. | 19:28 |
| ogasawara | infinity: I like firing both to -proposed since I can do both at the same time | 19:29 |
| skaet | infinity, have you cleaned out the others from proposed? | 19:29 |
| ogasawara | infinity: it just makes more work for you to then pocket copy | 19:29 |
| infinity | ogasawara: Yeah, it's much simpler. | 19:29 |
| infinity | ogasawara: The pocket copy isn't really effort. | 19:29 |
| infinity | skaet: Still carefully going through the list. Not copying things that are broken, etc. | 19:29 |
| ogasawara | infinity: ok cool, I'll fire off to -proposed then | 19:29 |
| infinity | skaet: But if you want a count of how many things are in proposed, go count before I do. :) | 19:29 |
| infinity | skaet: And add a few for the things we uploaded and subsequently copied/deleted during the freeze. | 19:30 |
| skaet | infinity, fair enough. if you want it in proposed, that's fine. | 19:30 |
| * skaet goes to count | 19:30 | |
| mterry | hallyn, heyo! If you're not busy with other stuff, I've got a couple branches I'd appreciate a review on. https://code.launchpad.net/~mterry/ubuntu-release-upgrader/pkexec/+merge/112638 and related https://code.launchpad.net/~mterry/update-manager/pkexec/+merge/112639 | 19:35 |
| mterry | br | 19:38 |
| mterry | brb | 19:38 |
| * skaet counts it at 90 packages in -proposed. ;) | 19:41 | |
| hallyn | mterry: taking a look | 19:41 |
| hallyn | mterry: changelog says "Implementation of "update on start" feature from spec https://wiki.ubuntu.com/SoftwareUpdates", but i don't see mention of that at that url | 19:59 |
| mterry | hallyn, that's not part of these branches, that's already in trunk. But the spec mentions that when you start update-manager, it should do an apt-get update (unlike precise's version which had a Check buton) | 20:00 |
| hallyn | d'oh | 20:01 |
| hallyn | mterry: i'm afraid it's almost all above my head, but paging through the diffs i didn't see any problems | 20:09 |
| mterry | hallyn, yar, I suppose I just need a "did I do anything stupid" check | 20:09 |
| mterry | hallyn, well, just mark 'em approved if you don't see anything crazy. Thanks for looking them over! | 20:19 |
| hallyn | mterry: will do, my pleasure | 20:19 |
| hallyn | mterry: a q on this - i take it htat pkexec is generally meant ot supplant gksu everywhere now? | 20:20 |
| mterry | hallyn, that's the idea | 20:20 |
| hallyn | (just for my education) | 20:20 |
| hallyn | ok. (that really means, more than ever, i want to go look at policykit source one of these days :) | 20:21 |
| hallyn | thanks :) | 20:21 |
| === imbrando1 is now known as imbrandon | ||
| hallyn | SpamapS: whenever you get a chance, could you look over https://code.launchpad.net/~serge-hallyn/ubuntu/quantal/pulseaudio/pa-upstart/+merge/112650 (which addresses previous review comments by you against my same branch for precise) ? | 20:47 |
| === salem_ is now known as _salem | ||
| SpamapS | hallyn: ACK, will try to get to it today, running quite behind tho | 20:49 |
| hallyn | SpamapS: thanks, no real hurry (i've taken my own sweet time) | 20:50 |
| ev | infinity: I'll have a look | 21:24 |
| infinity | ev: No big deal if you have it, it's not worth shipping it around the world. Just curious, cause I don't think I have it. :) | 21:27 |
| infinity | ev: Unless you want to give it to xnox to give to vorlon. | 21:27 |
| infinity | xnox: You're coming to Debconf, right? | 21:27 |
| xnox | infinity: yeap, what's up? | 21:27 |
| xnox | infinity: something related to what ev is going to look at? | 21:28 |
| infinity | xnox: I stole one of slangasek's cables and then left it on ev's desk. I think. ;) | 21:28 |
| xnox | infinity do I get to charge you 1st Class Royal Mail stamp for the service? | 21:28 |
| === james_w` is now known as james_w | ||
| infinity | xnox: Sure. I'll buy you a Nicaraguan beer. | 21:29 |
| * xnox drinks *cider* | 21:29 | |
| ev | yeah, it was in my suitcase. I think I brought it to UDS to give back to you | 21:29 |
| infinity | ev: Hahaha. | 21:29 |
| xnox | ev: and safely took it back? =) | 21:29 |
| * xnox the world-wide cable, eh? =))))) | 21:29 | |
| ev | cider? http://www.uniteddairy.com/htmlimages/Product_photos/Apple%20Cider/United_AppleCider_gallon.jpg | 21:30 |
| ev | xnox: indeed | 21:30 |
| xnox | ev: can I come in and work from the 'office' next week? | 21:30 |
| xnox | for a day | 21:30 |
| ev | xnox: you're welcome to work from the office whenever you want | 21:30 |
| ev | we have hot desks for such things | 21:31 |
| infinity | slangasek: So, xnox will be bringing you your cable, via ev. ;) | 21:31 |
| hallyn | gah i truly despise the 'progress info' on a bzr branch | 21:32 |
| slangasek | xnox, ev: don't go too far out of your way, I can just order a new cable :P | 21:32 |
| infinity | slangasek: This way's more fun. Shush. | 21:32 |
| slangasek | yes, but I think one or more of you have actual work to be doing | 21:32 |
| * infinity fixed an FTBFS while coordinating that. | 21:33 | |
| * ev did absolutely nothing | 21:33 | |
| slangasek | xnox, ev: let me know if I should order myself a new one | 21:33 |
| hallyn | hm, something i'm not clear on. if i'm doing UDD for a SRU (merging someone else's bzr tree), can i push to lp:ubuntu/release/package immediately, or do i just build and dput the package to -proposed and skip the udd steps? | 21:38 |
| slangasek | hallyn: the latter | 21:38 |
| slangasek | which is why I have an action item to document that UDD is not worth doing for SRUs because of the confusingness | 21:38 |
| hallyn | slangasek: sort of too bad, but expected. thanks. | 21:38 |
| hallyn | slangasek: yeah... though it does give a nicer trail while the patch is being considered (at least through patch pilot process) | 21:39 |
| slangasek | to some degree | 21:39 |
| slangasek | but creating the UDD branch in the first place is problematic | 21:39 |
| slangasek | because do you base it off precise, or precise-updates, or precise-proposed, or...? | 21:40 |
| hallyn | precise gets updated by precise-updates right? but yeah, right, -proposed gets lost, good point | 21:40 |
| hallyn | slangasek: thanks | 21:40 |
| hallyn | heh, here's hoping i didn't mess that up | 21:41 |
| xnox | ... or precise-security if it currently diverged from the current -proposed.... | 21:41 |
| hallyn | nope, looks good | 21:41 |
| hallyn | xnox: right | 21:41 |
| hallyn | cyphermox: hi, on https://code.launchpad.net/~poliva/ubuntu/precise/wpasupplicant/fix-for-994739/+merge/106704 you comment "i will take care of this in the merge". Does that mean that branch is handled (in terms of sponsoring)? you'll definately merge that? | 21:47 |
| cyphermox | yes, I'm about to upload it | 21:48 |
| hallyn | cyphermox: great, i'll keep my hands off then, thanks :) | 21:48 |
| cyphermox | np; sorry for the trouble ;) | 21:48 |
| cyphermox | hallyn: I'm also looking at freerdp | 21:49 |
| hallyn | paulliu's branch? | 21:50 |
| micahg | cjwatson: when you get a chance, MoM seems broke again (apologies if you've already been told or know) | 21:51 |
| === cpg is now known as cpg|away | ||
| cjwatson | micahg: thanks, hadn't realised, will take a look ASAP | 21:59 |
| hallyn | @pilot out | 22:03 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === bjsnider_ is now known as bjsnider | ||
| Daviey | http://lists.gnu.org/archive/html/grub-devel/2012-06/msg00093.html .. thought it would never happen! | 22:53 |
| cjwatson | micahg: Should be fixed for the next run, I think. MoM gets upset when packages fail to unpack. | 23:41 |
| cjwatson | I'll check back tomorrow morning. | 23:42 |
| micahg | cjwatson: ah, ok, thanks | 23:42 |
| === EXIO is now known as Exio | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
