| stokachu | stgraber: ping | 00:21 |
|---|---|---|
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| pitti | Good morning | 05:03 |
| dholbach | good morning | 06:02 |
| stgraber | stokachu: pong | 06:19 |
| === security is now known as megha | ||
| === tvoss is now known as tvoss|exercise | ||
| === jono is now known as Guest50668 | ||
| stgraber | roaksoax, Daviey: So MAAS was uploaded after final freeze. How critical is it that you have it on media for 13.04? | 07:35 |
| === smb` is now known as smb | ||
| infinity | pitti: Methinks it's probably final langpack time? | 08:04 |
| infinity | pitti: (Unless that happened when I wasn't looking, it's been a weird week for me) | 08:04 |
| pitti | stgraber, infinity: I'm about to upload a new network-manager with more tests, and resurrecting the dnsmasq autopkgtest; no changes to the actual code, is that okay? | 08:05 |
| pitti | infinity: ah, good point; requesting full export now | 08:05 |
| infinity | pitti: More tests are fine, if they pass. :P | 08:05 |
| pitti | infinity: yes, I'm pre-testing in a jenkins-like VM | 08:05 |
| pitti | and they now cover WPA and WPA2 as well | 08:05 |
| pitti | infinity: actually, we got a full export yesterday, so unless we are heading for an even fresher one I'll take that one | 08:06 |
| infinity | pitti: Also, I've lost track through all the apport/whoopsie iterations what the new and improved "we're about to release" workflow is for stuff. Do we still do some bit twiddle on apport, or is that a thing of the past? | 08:06 |
| pitti | infinity: we still have to twiddle, but that already happened for raring | 08:06 |
| infinity | pitti: Yesterday should probably be fine. | 08:06 |
| infinity | pitti: Okay, cool beans. | 08:07 |
| infinity | pitti: Did your langpack chroot ever get upgraded, or are you still fudging it on a porter? | 08:08 |
| pitti | infinity: it was, all working fine on macquarie now | 08:08 |
| pitti | the cron'ed ones also come from there | 08:09 |
| infinity | \o/ | 08:09 |
| infinity | Hrm, I wonder if I should try to fast-track Marc's apt-ftparchive change in precise to get it on pepo before we generate raring's final Sources.gz | 08:10 |
| pitti | infinity: the only thing left to do there is to figure out how I can copy/rsync the precise ones from the porter box to macquarie | 08:10 |
| pitti | I haven't yet found a suitable route through ssh/firewalls/etc (except through my box, which would take ages) | 08:10 |
| infinity | pitti: netcat ftw? | 08:10 |
| infinity | pitti: Or just ask a GSA to do it for you. | 08:11 |
| pitti | infinity: yeah, probably an RT | 08:11 |
| pitti | infinity: I tried that back then, can't directly ping/cat from macquarie to osageorange | 08:11 |
| pitti | (or the other way round) | 08:12 |
| * pitti turns the crank for building packs | 08:12 | |
| pitti | as we currently have four amd64 and four i386 buildds, I guess one should be permanently reassigned back to i386? | 08:13 |
| pitti | allspice? | 08:13 |
| === Amaranthus is now known as Amaranth | ||
| infinity | pitti: Oh, we should toss more than one back when we accept this mess anyway. | 08:15 |
| infinity | pitti: Like, all but one. :P | 08:15 |
| pitti | right, but only temporarily | 08:15 |
| infinity | Yeah. | 08:15 |
| pitti | but I thought we permanently have 5 i386 and 3 amd64 | 08:15 |
| infinity | Usually, yeah. I rebalanced cause we had a bunch of heavy arch:any jobs on the go. | 08:15 |
| infinity | Making that a shared pool is on my TODO for the next cycle. | 08:16 |
| infinity | pitti: Anyhow, crank away. You have 7 i386 builders now. | 08:18 |
| infinity | pitti: Once you verify those source packages are building right and looking sane or whatever, feel free to self-accept the lot. | 08:18 |
| pitti | infinity: it'll take some two or three hours to build the (source) packages on macquarie and then I want to test them first | 08:18 |
| pitti | infinity: ack, will do | 08:19 |
| cjwatson | infinity: pepo's on lucid, not precise, FWIW | 08:19 |
| infinity | cjwatson: Oh, right. Derp. | 08:19 |
| infinity | cjwatson: I can backport his patch for IS. | 08:19 |
| cjwatson | I thought that's what barry had done | 08:19 |
| infinity | Oh, did someone already get there? :P | 08:19 |
| cjwatson | Did that not happen? He was certainly talking about it in foundations meetings ... | 08:19 |
| infinity | I've been missing those meetings of late. | 08:20 |
| cjwatson | Yeah, it's on pepo | 08:20 |
| infinity | Yeahp, so it is. | 08:20 |
| infinity | Shiny. | 08:20 |
| cjwatson | http://paste.ubuntu.com/5720945/ - head of /usr/share/doc/apt-utils/changelog.gz | 08:20 |
| infinity | He says to the man staring at that in a terminal. | 08:20 |
| cjwatson | Heh | 08:21 |
| infinity | Was there a plan to also push that to lucid-updates, so it doesn't get lost after a security update? | 08:21 |
| cjwatson | Not sure. barry? | 08:22 |
| infinity | I mean, ideally, pepo will be precise some day. But, I don't know when that day it. | 08:22 |
| infinity | s/it/is/ | 08:22 |
| * cjwatson fixes up the bug metadata | 08:23 | |
| * infinity gives the i386 chroot a quick refresh before pitti goes all langpacky. | 08:23 | |
| pitti | infinity: ah, thanks | 08:24 |
| infinity | Actually, I guess I'll do them all. It's not like I can sleep anyway. | 08:24 |
| stgraber | infinity: are you trying to shift to the Australian timezone right before flying to Europe? you really like jetlag that much? :) | 08:26 |
| * infinity wonders why his Panda thinks it's 2012... | 08:26 | |
| infinity | stgraber: I've only slept about 8 hours since Sunday. It's not by choice, I assure you. | 08:26 |
| pitti | urgh | 08:27 |
| stgraber | infinity: ouch | 08:27 |
| seb128 | xnox, hey | 08:36 |
| xnox | seb128: heya. | 08:36 |
| seb128 | xnox, https://bugs.launchpad.net/ubuntu-geonames/+bug/1150109 ... is "fix commited", what is needed for it to be "fix released"? #is to deploy the update? | 08:36 |
| ubottu | Launchpad bug 1150109 in Ubuntu Geonames "Ubuntu's geonames only knows about Hong Kong in Guyana, not in China" [Undecided,Fix committed] | 08:36 |
| xnox | seb128: pending RT ticket I believe. | 08:37 |
| seb128 | xnox, ok, thanks | 08:37 |
| seb128 | xnox, do you have the rt number by any chance? ;-) | 08:37 |
| seb128 | xnox, 60594 I guess | 08:38 |
| xnox | seb128: correct. =) you are quick with RT | 08:38 |
| seb128 | xnox, :p | 08:39 |
| xnox | seb128: /me was waiting on thunderbird to launch and find the emails. | 08:39 |
| seb128 | I went on the site and typed "geoname" in the query field | 08:39 |
| seb128 | that listed only 2 tickets | 08:39 |
| seb128 | so easy enough ;-) | 08:39 |
| xnox | 2...? interesting..... | 08:39 |
| seb128 | xnox, the other one is "Make geonames a fully webops managed service" | 08:40 |
| xnox | seb128: interesting =) maybe I should look into that. | 08:40 |
| cjwatson | infinity: Think I should flip base-files now, for the sake of minimal obstacles to release candidate being true candidate? | 08:43 |
| infinity | cjwatson: Go nuts. | 08:44 |
| infinity | cjwatson: We really need to rewrite these checklists as we go. They're a bit stale. | 08:45 |
| cjwatson | Yeah | 08:45 |
| cjwatson | Fighting the last battle | 08:45 |
| infinity | cjwatson: Twiddling CONF.sh early isn't an awful plan either, IMO. | 08:45 |
| cjwatson | Indeed | 08:45 |
| cjwatson | Hm, I've not done os-release before. Any objections to me setting PRETTY_NAME to "Ubuntu 13.04", rather than something in the style of "Ubuntu quantal (12.10)" as was used for 12.10? | 08:49 |
| infinity | cjwatson: How's it look in Debian? I'm not too picky, since we've not really done much with os-release... | 08:50 |
| infinity | PRETTY_NAME="Debian GNU/Linux 7.0 (wheezy)" | 08:50 |
| infinity | So, seems to match vaguely the format of issue.net | 08:51 |
| stgraber | cjwatson: I think it makes sense not to use the codename for the released version. | 08:51 |
| cjwatson | OK, I'll go for "Ubuntu 13.04"; people can reupload if they object | 08:51 |
| seb128 | the upstream definition is "A pretty operating system name in a format suitable for presentation to the user. May or may not contain a release code name or OS version of some kind, as suitable." | 08:51 |
| seb128 | "Ubuntu 13.04" seems fine to me | 08:51 |
| infinity | cjwatson: That sounds good to me. | 08:51 |
| infinity | Oh, wait, that means you're stealing base-files TILM from me. Grr. :) | 08:54 |
| infinity | I geuss I'll resync in a week. :P | 08:54 |
| cjwatson | Heh | 08:55 |
| cjwatson | Feel free | 08:55 |
| ev | mpt: current theory: code is sound, we just need to run build_errors_by_release twice. | 08:55 |
| mpt | ev, you've unit-tested? | 08:55 |
| ev | mpt: I have for the case of one system that reports an error a week ago, then a day later, then a day later | 08:55 |
| ev | mpt: feel free to suggest more test cases | 08:55 |
| ev | but I realised that the work of build_errors_by_release would be inaccurate after the first run. FirstError will not be correct until we've seen all the data, and so ErrorsByRelease will not be correct until a second run. | 08:56 |
| ev | We're not processing the error reports in time order. We can't. | 08:57 |
| === zyga_ is now known as zyga | ||
| ev | So for one system, if we see a report from a day ago and write it into FirstError and ErrorsByRelease, then we see a report from a week ago and write it into FirstError and ErrorsByRelease, the data in FirstError will be correct, but that first error report value in ErrorsByRelease will be inaccurate, because it was based on a report from a week ago being the first error report seen for the given release. | 08:58 |
| cjwatson | base-files uploaded, CONF.sh twiddled | 08:59 |
| ev | I have no idea why this didn't occur to me straight away | 08:59 |
| ev | mpt: I'll be posting a merge proposal for you and bdmurray to review today. I'll try to make the unit test as readable as possible. | 09:01 |
| infinity | cjwatson: Cheers. | 09:01 |
| === ckpringle_ is now known as ckpringle | ||
| infinity | pitti: chroots are all updates, BTW. Should be good to go when you're ready. | 09:20 |
| infinity | s/updates/updated/ | 09:20 |
| pitti | infinity: thanks | 09:20 |
| pitti | sources finished building, I'll give them a smoke test and binary debdiff now | 09:21 |
| infinity | pitti: If you have buildd admin, feel free to give amd64 a few machines back when you're done. | 09:21 |
| pitti | infinity: I have, will do | 09:21 |
| * infinity goes to see if he can get a couple hours of sleep... | 09:22 | |
| infinity | Maybe I'll get lucky tonight. | 09:23 |
| cjwatson | Good luck | 09:25 |
| pitti | infinity: sleep well! | 09:26 |
| pitti | new langpacks look good, and have a lot of previously missing domains | 09:48 |
| * pitti uploads; buildds, brace for impact | 09:48 | |
| seb128 | pitti, do you want/need testers? | 09:49 |
| pitti | seb128: if you wish; hang on, I'll build French ones | 09:50 |
| pitti | I checked English and German | 09:50 |
| pitti | there's no particular reason to believe anything is broken, but it can't hurt of course | 09:50 |
| pitti | seb128: les paquets de language sont ici: http://people.canonical.com/~pitti/tmp/langpack/ | 09:54 |
| pitti | "de lange" | 09:54 |
| pitti | "de langue" | 09:54 |
| pitti | didrocks, cjwatson, stgraber: perhaps for the final freeze we should disable the daily autolanding? | 09:55 |
| didrocks | pitti: it's in manual mode | 09:56 |
| seb128 | pitti, what daily autolanding? | 09:56 |
| seb128 | what didrocks said | 09:56 |
| pitti | didrocks: ah, because I just see builds | 09:56 |
| didrocks | pitti: yeah, it's building everyday | 09:56 |
| didrocks | trying tests | 09:56 |
| didrocks | but doesn't publish | 09:56 |
| pitti | oh, that's just for the PPA, ignore me | 09:56 |
| didrocks | yep :) | 09:56 |
| infinity | didrocks: Disabling even those PPA builds next week might be nice, in case they happen to clog the buildds at Just The Wrong Time and we need to get someone to kill them. | 09:58 |
| didrocks | infinity: we can do that temporarly, however, we are preparing SRU0 | 09:58 |
| didrocks | infinity: so yeah, if you see anything critical, we can kill them. however, right now, what's building is more the touch stacks for S that we bootstrap than stuff in daily release | 09:59 |
| didrocks | infinity: meaning, like, this morning, only 2 source packages built for raring (in indicators stack) | 09:59 |
| didrocks | nothing else on the daily release "r" | 09:59 |
| infinity | didrocks: Well, for release minus 48h, it might be nice to not have a panic conflict, but I also know which shoulders to tap if I need a buildd Right Now too. | 10:00 |
| didrocks | infinity: agreed, can be disabled by then, we need to have mterry, cyphermox, robru and kenvandine do the "disable bits" for it (it's not a global switch) | 10:00 |
| infinity | didrocks: Ahh, well. I'll talk to you next week about it when we're in the same timezone. | 10:01 |
| didrocks | infinity: sounds good :) | 10:01 |
| seb128 | pitti, language-pack works fine for me, gnome-calculator is in french, all good ;-) | 10:01 |
| pitti | so much for sleeping :( | 10:01 |
| infinity | pitti: I'm asleep right now, can't you tell? | 10:02 |
| pitti | seb128: ah, most important app ever! | 10:02 |
| pitti | seb128: merci | 10:02 |
| seb128 | pitti, lol | 10:02 |
| seb128 | pitti, that's the one that I know about which was missing its template ;-) | 10:02 |
| seb128 | pitti, de rien | 10:02 |
| pitti | infinity: your IRC proxy clearly passes the Turing test! | 10:02 |
| infinity | pitti: Can you elaborate on that? | 10:05 |
| === tvoss|exercise is now known as tvoss | ||
| pitti | Eliza, how are you today? | 10:06 |
| infinity | :) | 10:06 |
| infinity | And here I was, afraid you wouldn't get the reference. | 10:07 |
| pitti | the most important emacs feature missing in vim! | 10:07 |
| highvolt1ge | in a very poor school district in south africa, I migrated a few schools form Fedora to Ubuntu a few years ago | 10:08 |
| highvolt1ge | and received a bunch of faxes begging to bring back emacs because the kids wanted it back badly | 10:08 |
| highvolt1ge | I was a bit confused as to why the kids wanted emacs so badly. turned out it was for the psychologist :) | 10:09 |
| infinity | Heh. | 10:09 |
| infinity | Damn you, Launchpad, for not instantly knowing about new Debian uploads. | 10:11 |
| infinity | http://packages.qa.debian.org/l/lolcat/news/20130419T100008Z.html | 10:11 |
| infinity | ^-- Inclusion thereof is clearly RC for raring. | 10:12 |
| StevenK | infinity: You have to wait for gina | 10:12 |
| infinity | StevenK: DON'T WANNA. | 10:12 |
| xnox | infinity: veto, unless is also ships a loldog symlink. | 10:13 |
| * StevenK overrules xnox, since he is an archive admin | 10:13 | |
| * xnox :`( | 10:13 | |
| * infinity removes emacs from the archive to spite xnox. | 10:14 | |
| xnox | /msg doko please blacklist lolcat | 10:14 |
| xnox | infinity: please do, everyone should be using emacs24 by now ;-) | 10:14 |
| infinity | xnox: I meant all emacsen. :P | 10:14 |
| xnox | /o\ | 10:14 |
| StevenK | infinity: Some way to track Debian uploads without having to have a mirror on iron (and probably somewhere else in the DC) and gina would be awesome | 10:15 |
| StevenK | Oh, no, it's the debbugs mirror that is bounced twice, iron is not | 10:15 |
| infinity | StevenK: You'd think we could get near instant turnaround by tracking a changes list and pulling from incoming. | 10:16 |
| StevenK | Hmm | 10:16 |
| infinity | Though, incoming suffers the problem that there's no signed index, so we're blindly trusting the signatures on the .dsc files. | 10:16 |
| infinity | Which is likely bad. :P | 10:17 |
| cjwatson | Which is pretty much why we wait for a mirror, yeah | 10:17 |
| StevenK | And at this point, we stuck until katie runs and ftp.uk is pulsed | 10:17 |
| infinity | Of course, incoming DOES have a signed index at /buildd/ | 10:17 |
| infinity | Shame it's no accessible to the public. | 10:17 |
| StevenK | infinity: Not even a DD? | 10:18 |
| infinity | Weeeell. | 10:18 |
| xnox | not _all_ DD | 10:18 |
| infinity | All buildd admins have access to the buildd bits. | 10:18 |
| StevenK | Right | 10:18 |
| xnox | legal issues prevents access to incomming?! | 10:19 |
| infinity | Maybe we could get someone to agree that allowing us to pull from there would be cool. | 10:19 |
| StevenK | Back in my day, you couldn't build from incoming | 10:19 |
| StevenK | xnox: Yup | 10:19 |
| StevenK | xnox: It's a fun legal issue | 10:19 |
| infinity | Hrm? There are no legal issues with incoming. | 10:19 |
| infinity | incoming.debian.org is poorly named, it should be accepted.debian.org. :P | 10:20 |
| xnox | infinity: if it's new and ftp-master hasn't reviewed it yet..... oh incoming is not NEW?! | 10:20 |
| infinity | The only technical issue with us pulling from incoming is that it has no trust path. | 10:20 |
| StevenK | incoming is not NEW, no | 10:20 |
| infinity | xnox: incoming.debian.org is queue/accepted. Not to be confused with queue/incoming, which is the precursor to new/by-hand/etc. | 10:21 |
| StevenK | NEW is locked down, due to some US acroymn and having to announce packages to the US government because they may contain crypto, but my knowledge might be years out of date | 10:21 |
| infinity | Serious terminology overload. | 10:21 |
| StevenK | I thought BYHAND was mostly dead? | 10:22 |
| xnox | StevenK: right, which debian was requested to stop mailing, but simply keep a record & produce it upon request. | 10:22 |
| xnox | aren't docs and d-i bits still BYHAND? | 10:22 |
| StevenK | xnox: I was around when BenC produced the first list, which was 8,000 pages | 10:22 |
| xnox | wow =) | 10:22 |
| infinity | And one wonders why DPLs burn out and disappear. | 10:23 |
| * xnox is very young ;-) | 10:23 | |
| StevenK | I've been a DD for 12 years | 10:23 |
| infinity | And you've still not fully repented for linda. | 10:23 |
| StevenK | Linda had her uses. And a fan club. | 10:24 |
| infinity | Charles Manson has a fan club. | 10:24 |
| infinity | Just sayin'. | 10:24 |
| StevenK | infinity: Here, I have something for you. It's called 'ether' | 10:25 |
| infinity | Yes, please. | 10:25 |
| * xnox ponders how to check when one became a DD | 10:25 | |
| * infinity takes the hint and goes to stare at the ceiling some more. | 10:25 | |
| StevenK | xnox: nm.debian.org | 10:25 |
| StevenK | But only those who went through the new NM process | 10:26 |
| Laney | https://nm.debian.org/public/process/13678 | 10:26 |
| xnox | meh just a year. | 10:26 |
| * xnox just under 2 years from start to finish. | 10:26 | |
| Laney | I think that might be a relative definition of "new" | 10:26 |
| StevenK | https://nm.debian.org/public/process/13201 is me | 10:27 |
| infinity | Sweet. Sledge has been a DD since the UNIX epoch. | 10:27 |
| StevenK | Haha | 10:27 |
| infinity | https://nm.debian.org/public/people/dd_u <-- Might have accuracy issues for people who predate the NM database... | 10:27 |
| StevenK | Maybe just a bit | 10:27 |
| xnox | StevenK: hmm... 5 days that's swift. | 10:27 |
| StevenK | xnox: Yup | 10:27 |
| StevenK | xnox: I didn't hear about the "NM problems" until after I became a DD and I was "What problems?" | 10:28 |
| xnox | StevenK: I also had something like 7m+ hunting down for someone to sign my key. | 10:29 |
| infinity | StevenK: My AM was a slacker compared to yours. | 10:29 |
| === doko_ is now known as doko | ||
| StevenK | I've been accused by others of having my dates changed by the klecker fire, and by one person that "I must have gotten access to the NM system and changed my own dates" | 10:29 |
| StevenK | infinity: Who was your AM? | 10:29 |
| infinity | opal | 10:30 |
| highvolt1ge | n/win 12 | 10:30 |
| StevenK | infinity: tbm talked to joeyh about me, joeyh said "Yeah, Steve knows what he's doing", and tbm went "Right, there's T&S done." | 10:30 |
| === highvolt1ge is now known as highvoltage | ||
| mpt | ev, the simplest test case would be one machine that reported one error today producing a weighted error rate of 1/90 | 10:31 |
| StevenK | xnox: Ah, I had no issues with that, Sydney has a large number of DDs | 10:31 |
| infinity | I didn't have any DDs nearby, but I had some kernel devs that were considered strongly connected enough. | 10:32 |
| StevenK | I think I had four or five DD signatures by the time I applied | 10:32 |
| ev | mpt: if a machine reported one error today and it was their only error for the release, wouldn't that be 0, not 1/90? | 10:32 |
| ev | it's been 0 days since their first error. | 10:32 |
| StevenK | bod, wildfire, gus spring to mind | 10:32 |
| infinity | pasc, csmall? | 10:33 |
| StevenK | Indeed | 10:33 |
| infinity | Man, I haven't seen pasc in ages. | 10:33 |
| StevenK | I pre-date pasc being a DD | 10:33 |
| infinity | Right. Sleep. No reminiscing. | 10:33 |
| mpt | ev, yep, you're right :-) | 10:33 |
| mpt | (off-by-one error!) | 10:33 |
| ev | I feel like balloons should be falling from the ceiling right now and someone should be approaching my desk with an award | 10:34 |
| ev | maybe a cake | 10:34 |
| === ckpringle_ is now known as ckpringle | ||
| * katie runs for StevenK | 11:18 | |
| ev | bdmurray: happy to report that the only OOPS reports in https://errors.ubuntu.com/oops-local/2013-04-18/ yesterday were caused by me | 11:20 |
| StevenK | Haha | 11:20 |
| StevenK | katie: The *other* katie | 11:21 |
| ev | (I have a branch to fix the bug, I'm just a bit stuck on the YUI DataSource.Get code for catching a 404 raised by the API when the user cannot be found) | 11:21 |
| cjwatson | tjaalton: bug 1169071 - are they superseded by some other packages? just trying to work out what to write in the removal comment | 11:24 |
| ubottu | bug 1169071 in nvidia-settings-experimental-304 (Ubuntu) "please remove from the archive" [Wishlist,Confirmed] https://launchpad.net/bugs/1169071 | 11:24 |
| tjaalton | cjwatson: yes, we have nvidia-304/310 already | 11:27 |
| tjaalton | tseliot knows the right answer I think :) | 11:28 |
| tjaalton | why we had both | 11:28 |
| === security is now known as megha | ||
| DktrKranz | cjwatson: wrt bug #1083091, I can't do it right now in Debian because of its rdep gtg. It's on my radar, and it'll be gone as soon as Wheezy is released :) | 11:44 |
| ubottu | bug 1083091 in liblarch-gtk (Ubuntu) "Remove liblarch-gtk from the archive" [Wishlist,Fix released] https://launchpad.net/bugs/1083091 | 11:44 |
| obounaim | What is the lowest level packaging command that is called by all the other packaging tools like pbuilder, sbuild..? | 11:53 |
| tumbleweed | dpkg-buildpackage -b | 11:55 |
| tumbleweed | which essentially calls debian/rules build; fakeroot debian/rules binary | 11:55 |
| obounaim | ok thanks | 12:01 |
| obounaim | I am looking for to integrate scan-build int the packaging system, any ideas how to do that? | 12:02 |
| obounaim | for a way | 12:02 |
| tumbleweed | scan-build? | 12:03 |
| pitti | infinity: FTR, roseapple and allspice sent back to amd64 duty | 12:04 |
| obounaim | yes a static analyzer for C/C++ programs | 12:04 |
| xnox | jibel: how would you like installer bugs tagged that affect ubuntu-gnome images? "ubuntu-gnome" tag? Are you ubuntu-gnome team monitor those? | 12:23 |
| xnox | (e.g. in ubiquity package we use kubuntu, xubuntu, lubuntu tags when it only affects those images) | 12:24 |
| lool | cjwatson: Hmm ISTR that ffmpeg was in a germinate blacklist, but I can't find it anymore; did the situation change or is this something that we were checking manually? | 12:27 |
| lool | I see it in supported-desktop-extra now | 12:27 |
| lool | cjwatson: ah! found libavcodec in ubuntu.raring/usb-ship-live, nm | 12:28 |
| lool | seb128: ^ | 12:28 |
| jibel | xnox, your question is for jbicha? | 12:28 |
| xnox | jibel: correct. | 12:30 |
| xnox | jibel: he is not here =) hmm... will catch him some other time. | 12:30 |
| ScottK | Sweetsha1k: There's a bug asking for lo-menubar to be removed from raring. Is that correct? | 12:35 |
| seb128 | ScottK, yes, that got replaced by an upstream implementation in libreoffice itself, but that was for quantal, I'm surprised we still have the old source in the archive | 12:40 |
| seb128 | hum | 12:40 |
| seb128 | so indicator-weather is just broken | 12:40 |
| ScottK | Thanks. | 12:40 |
| seb128 | is anyone working on it/upstream for it? | 12:40 |
| seb128 | or should we just drop it from raring? | 12:41 |
| tseliot | cjwatson: nvidia-310-updates has transitional packages for experimental-310 and 304->updates for experimental-304 | 12:49 |
| === _salem is now known as salem_ | ||
| mpt | Could someone please answer my questions in bug 1166230 about why there are ever updates to "transitional dummy packages"? Thanks kindly. | 13:00 |
| ubottu | bug 1166230 in update-manager (Ubuntu) "Updater lists many transitional dummy packages" [Medium,Confirmed] https://launchpad.net/bugs/1166230 | 13:00 |
| seb128 | mpt, they are updated because they are typically built from the same source as the real package | 13:03 |
| seb128 | mpt, like gcalctool -> gnome-calculator | 13:03 |
| seb128 | mpt, so they have the source version | 13:03 |
| mitya57 | hey seb128, do you think we can backport https://bug691040.bugzilla-attachments.gnome.org/attachment.cgi?id=238204 for raring gtk2? | 13:08 |
| mitya57 | (bug 1125260) | 13:08 |
| ubottu | bug 1125260 in gtk+2.0 (Ubuntu) "gtk_file_chooser_get_current_folder() function is broken in 2.24.10 < GTK+ < 2.24.15" [Undecided,Confirmed] https://launchpad.net/bugs/1125260 | 13:08 |
| seb128 | mitya57, (sorry, otp, seems reasonable but maybe check with Laney/the release team) | 13:08 |
| mitya57 | it'll be nice to have it at least as a sru | 13:10 |
| === mitya57 is now known as mitya57_ | ||
| === mitya57__ is now known as mitya57 | ||
| geser | mpt: at your 2nd questions: it's not always possible to remove those transitional packages yet as the transition isn't complete (e.g. ubuntu-minimal -> module-init-tools which is a transitional package to kmod) | 13:12 |
| doko | jibel, pitti: everything green now with the python autopkg tests? | 13:14 |
| pitti | no, still not :( | 13:15 |
| pitti | https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python3.3/10/ARCH=i386,label=adt/ | 13:15 |
| pitti | https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python2.7/6/ARCH=i386,label=adt/ | 13:16 |
| pitti | python2.7: can't open file '/usr/lib//test/regrtest.py': [Errno 2] No such file or directory | 13:16 |
| jibel | doko, it wasn't last time I checked, dbm test failed | 13:16 |
| xnox | mpt: furthermore, we support LTS->LTS upgrades thus when we renamed gcalctool -> gnome-calculator, we kept a dummy empty package gcalctool which simply depends and installs gnome-calculator, such that a Precise user upgrades to 14.04 his "gcalctool" upgraded package installs "gnome-calculator". Then in 14.10 we can remove gcalctool transitional package. | 13:16 |
| xnox | thus most of transitional packages stick around for 2 years or less. | 13:16 |
| jibel | doko, for 3.3 | 13:16 |
| pitti | jibel, doko: right, for 3.3 there are three failures in dbm | 13:16 |
| Sweetsha1k | ScottK: we can do that yeah. its a transitional by now. | 13:17 |
| Sweetsha1k | ScottK: /me in call | 13:17 |
| === wedgwood_away is now known as wedgwood | ||
| rbasak | rsalveti: I'm just looking at the avogadro FTBFS. It's another example of the GLdouble declaration conflict. https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=gldouble+previous+declaration has nine others. Would it be an idea to collapse these into a single bug with multiple tasks? Is there a simple fix that will fix them all, or does each package need individual treatment? | 13:20 |
| doko | jibel, pitti: crap about 2.7/testsuite. can't see the test_io failure here with 2.7/testsuite-dbg | 13:21 |
| doko | jibel, doko: hmm, the test_dbm failure isn't reproducible here either | 13:25 |
| cjwatson | rbasak: Each package needs individual treatment, so it should remain separate bugs rather than being collapsed into a single bug with multiple tasks. See https://wiki.ubuntu.com/ARM/FTBFS#OpenGL_and_Qt_combination | 13:43 |
| cjwatson | DktrKranz: Oh, I hadn't noticed that the liblarch that builds python-liblarch-gtk is still only in experimental. | 13:43 |
| tseliot | pitti: is it possible that jockey is trying to set the alternative in enable() before XorgDriverHandler.enable() finishes. This would explain our problem | 13:47 |
| barry | cjwatson, infinity yes, it's probably a good idea to backport the patch to lucid. i can do that | 13:47 |
| tseliot | ? | 13:47 |
| tseliot | pitti: also maybe in a separate thread? | 13:48 |
| pitti | tseliot: jockey doesn't use threads | 13:49 |
| pitti | tseliot: so unless the nvidia.py handler calls them in the wrong order, no | 13:50 |
| tseliot | pitti: could it be that apt/dpkg does though? | 13:50 |
| tseliot | pitti: if so, as a workaround, I can make sure that the alternatives are set in enabled() instead of enable() | 13:51 |
| pitti | tseliot: no, enabled() must not change anything | 13:53 |
| tseliot | pitti: hmm... I guess I'm out of ideas on bug 804662 (on the nvidia-common side) | 13:54 |
| ubottu | bug 804662 in nvidia-common (Ubuntu Precise) "jockey-gtk crashed with TypeError in _execute_child(): execv() arg 2 must contain only strings" [High,Triaged] https://launchpad.net/bugs/804662 | 13:54 |
| pitti | need to run out for a bit, back in 45 ins | 13:54 |
| tjaalton | slangasek: looks like I've come up with a fix for the plymouth race bug http://pastebin.com/2bZu24yG (+ 'and plymouth-ready' to *dm.conf) | 13:55 |
| tjaalton | on another note, can someone explain why 'pkg-config --libs nss' doesn't show -lpthread, while it's linked against it? | 13:56 |
| diwic | tjaalton, are you sure that it should, as long as the host software doesn't need -lpthread ? | 13:57 |
| tjaalton | -ldl is also missing, these both caused build issues with sssd | 13:57 |
| cjwatson | tjaalton: it's only linked against it indirectly | 13:57 |
| tjaalton | diwic: I don't know | 13:57 |
| tjaalton | cjwatson: ahh, ok | 13:57 |
| cjwatson | use 'objdump foo.so | grep NEEDED' rather than ldd | 13:57 |
| cjwatson | sorry, objdump -p | 13:57 |
| tjaalton | gotcha, thanks | 13:58 |
| cjwatson | so sssd must either be linked against something else that fails to specify that you need -lpthread; or it's using pthread directly and erroneously not specifying it | 13:58 |
| tjaalton | nah the build-issues have been fixed, but upstream (or fedora) is complaining why these fixes are proposed there :) | 13:59 |
| cjwatson | libnssutil3 and libnspr4 are both directly linked against -lpthread | 13:59 |
| tjaalton | or something, pinging me about it anyway | 13:59 |
| cjwatson | hm, and pkg-config --libs nss says -lnssutil3 | 13:59 |
| cjwatson | well; -lpthread should not be necessary in sssd unless it uses pthread functions directly, should it? | 14:00 |
| tjaalton | there are some components that do use it | 14:00 |
| cjwatson | which it does | 14:00 |
| cjwatson | so it's sssd's fault then. use directly, link directly. | 14:00 |
| cjwatson | and don't use directly, don't link directly. should be very simple :) | 14:00 |
| seb128 | lool, we are discussing the gettext issue on #ubuntu-hardened | 14:00 |
| cjwatson | lool: ubuntu.raring/ship-live is generally the governing one, but yes | 14:01 |
| tjaalton | cjwatson: ok, but shouldn't nss.pc have -lpthread then if libnssutil3 links to it? | 14:03 |
| cjwatson | tjaalton: only if the mere fact of using the nssutil API causes the program using it to have *direct* references to symbols in libpthread | 14:04 |
| cjwatson | tjaalton: for example if an nssutil header file had macros that expanded to pthread_* | 14:04 |
| tjaalton | cjwatson: alright.. think I got it this time | 14:04 |
| cjwatson | programs shouldn't overlink by re-specifying all the indirect linkage of the libraries they use | 14:05 |
| cjwatson | at least not on Linux | 14:05 |
| tjaalton | what changed it for raring? | 14:05 |
| cjwatson | it actually causes some subtle problems if they do | 14:05 |
| cjwatson | not aware of any toolchain-level changes here for raring | 14:05 |
| cjwatson | maybe something changed in nss, dunno | 14:06 |
| Laney | mitya57: is the patch reviewed/committed upstream? | 14:06 |
| tjaalton | maybe it's nss/nspr then | 14:06 |
| tjaalton | right | 14:06 |
| tjaalton | ok, case closed anyway | 14:06 |
| mitya57 | Laney: looks like a different set of patches was committed, I didn't yet figure out which of them actually fixes the bug | 14:07 |
| Laney | mitya57: sounds like SRU would be better then | 14:07 |
| mitya57 | there are *lots* of gtkfilechooserbutton fixes @ https://git.gnome.org/browse/gtk+/log/?h=gtk-2-24 | 14:07 |
| Laney | even since .17? | 14:08 |
| mitya57 | yes | 14:08 |
| * mitya57 wonders whether it'll be better to backport the whole set of fixes | 14:08 | |
| Laney | so there are | 14:08 |
| Laney | maybe there will be another release | 14:09 |
| mitya57 | Laney: is "another release" OK for SRU? | 14:10 |
| Laney | GNOME micro releases are | 14:10 |
| mitya57 | Laney: OK, so let's wait for the new release, I'll prepare a SRU then | 14:11 |
| Laney | might be good to find out if/when that is planned for | 14:12 |
| mitya57 | I don't think there is any schedule | 14:14 |
| mitya57 | xnox: do you know why your reply is shown at http://www.riverbankcomputing.com/pipermail/pyqt/2013-April/thread.html, but my original mail isn't? | 14:14 |
| xnox | mitya57: are you subscribed to the mailing list? as far as I remember it's moderated list. | 14:15 |
| mitya57 | xnox: is it auto-moderated for those who are subscribed? I am not (yet) | 14:16 |
| xnox | mitya57: yeah. rather not moderated at all if posted by subscribers, kind of like launchpad mailing lists. | 14:17 |
| mitya57 | ok, let's hope they will read my mail via yours :) | 14:18 |
| mitya57 | xnox: by the way, did you already test if phablet toolkit works with PyQt? | 14:20 |
| xnox | mitya57: it could be me building it wrong though =/ I am surprised it build at all =)))) | 14:20 |
| xnox | mitya57: nope. I have only tried simple standard show a QApplication with a label =) | 14:21 |
| mitya57 | but the target is the toolkit, right? or why do you need it? | 14:21 |
| xnox | mitya57: my initial target is getting a non-trivial gui app working (e.g. ubiquity) or something QML based. | 14:22 |
| mitya57 | xnox: fwiw, apart from QFont constructor and Xserver crashes, I am able to run ReText under Qt 5 | 14:22 |
| xnox | mitya57: the target is to get oem-config (ubiquity) frontend in python with ubuntu-touch Qml components. | 14:22 |
| xnox | mitya57: but we'd want pyqt4 (with qt5.... and eventually pyqt5) regardless of anything. | 14:23 |
| mitya57 | yes, let's hope PyQt5 will be available soon | 14:24 |
| mitya57 | and thanks for the work you have done! | 14:25 |
| xnox | mitya57: i would not hold my breath waiting for PyQt5 release | 14:25 |
| ogra_ | well, probably if you are a professional diver ... | 14:26 |
| xnox | ogra_: i'm no Linus ;-) | 14:28 |
| ogra_ | hehe | 14:28 |
| mitya57 | seb128: I think https://plus.google.com/u/0/106010143685041042333/posts/XeygQ6A9dEk indicates that the author is not going to continue i-w development | 14:29 |
| rbasak | cjwatson: thanks, and for the wiki link - I had googled but not found it. | 14:29 |
| cjwatson | Might be a plan to grab the UbuntuKylin people and point them at that post - hard | 14:31 |
| mitya57 | (Vadim is here, and his nick is roignac) | 14:32 |
| seb128 | mitya57, oh ok, thanks for pointing it, shame that he got offended just because those guys forked some code, they are pretty new to opensource communities and are learning... | 14:33 |
| seb128 | mitya57, well, from what I see that yahoo service has been discontinued for a while .... in any case if nobody is wanting to fix it, just drop the source from raring, that's a shame though :/ | 14:34 |
| mitya57 | yes, let's drop it | 14:36 |
| * mitya57 has to leave | 14:39 | |
| slangasek | tjaalton: 'start on filesystem' is very late, I don't think that's what you want - that's going to unnecessarily slow the boot down in some cases | 14:50 |
| tjaalton | slangasek: 'startup' didn't work | 14:51 |
| slangasek | tjaalton: I think you instead want 'start on startup or started plymouth-splash' | 14:51 |
| tjaalton | hmm let me try again | 14:51 |
| slangasek | tjaalton: 'startup' didn't work for the plymouth-in-initramfs case? | 14:51 |
| tjaalton | I think so, hang on | 14:51 |
| tjaalton | got some ideas from #upstart too, added sleep 0.1 and dropped console-output | 14:52 |
| tjaalton | oh now it worked, heh | 14:52 |
| === nemo is now known as hedgewars|nemo | ||
| Riddell | ogra_: I've come to the conclusion that the kubuntu nexus images you made don't work | 14:54 |
| ogra_ | haha, thats a prompt reply | 14:54 |
| Riddell | ogra_: flashing them to the nexus just stops indefinately | 14:54 |
| Riddell | ogra_: http://paste.kde.org/728402/ | 14:55 |
| Riddell | ogra_: that's quite reproducable on two nexus 7s | 14:55 |
| ogra_ | erm | 14:55 |
| ogra_ | when do you flash boot ? | 14:55 |
| ogra_ | oh i see ... | 14:55 |
| Riddell | ogra_: when it's in firmware mode | 14:56 |
| ogra_ | your images are to big | 14:56 |
| Riddell | hum | 14:56 |
| ogra_ | you can try using the -S option for fastboot | 14:56 |
| ogra_ | but thats sadly unreliable and doesnt work on all models | 14:56 |
| ogra_ | try with -S 512M | 14:57 |
| ogra_ | that will cut the img in little chunks while transferring | 14:57 |
| cjwatson | Daviey: Could you or somebody on your team confirm bug 1017609? | 15:02 |
| ubottu | bug 1017609 in python-melangeclient (Ubuntu) "Please remove melange from ubuntu archive" [Undecided,New] https://launchpad.net/bugs/1017609 | 15:02 |
| slangasek | tjaalton: also, I think you want to drop the 'stop' rule, add an 'instance $UPSTART_EVENTS', and lose the while loop | 15:06 |
| tjaalton | slangasek: ok.. | 15:07 |
| Riddell | ogra_: well that seems to successfully copy over but then on reboot it drops me to an initramfs command line | 15:07 |
| Riddell | saying "mounting /dev/mmcblk0p9 on /root failed: invalid argument" | 15:08 |
| slangasek | tjaalton: e.g., (untested): http://paste.ubuntu.com/5721802/ | 15:09 |
| ogra_ | Riddell, thats with the matching bootimg file in place ? | 15:10 |
| Riddell | ogra_: yep | 15:11 |
| slangasek | tjaalton: caveat: for the plymouth-in-initramfs case, this will emit the event twice | 15:11 |
| slangasek | tjaalton: which means, actually, that the initctl emit should be --no-wai | 15:11 |
| slangasek | t | 15:11 |
| ogra_ | Riddell, what kind of n7 is that (what size) | 15:11 |
| ogra_ | just the 8G one or something bigger ? | 15:11 |
| slangasek | Laney: indicator-weather upstart respawn> haha, +1 | 15:12 |
| ogra_ | uuuh ! | 15:12 |
| Riddell | ogra_: Google Nexus 7 Tablet PC (Android 4.1 Jellybean) - 16 GB | 15:12 |
| ogra_ | as someone who had his disk eaten by indicator-weather i strongly disagree ! | 15:12 |
| slangasek | ogra_: oh, but you had your disk eaten by it because it was writing to .xsession-errors... as an upstart job you're safe from that ;) | 15:13 |
| ogra_ | Riddell, hmm, might be that mmcblk0p9 isnt the userdata partition on that device | 15:13 |
| slangasek | ogra_: you can even just remove .cache/upstart/indicator-weather.log, and upstart will automatically re-open the logfile automatically ;) | 15:13 |
| ogra_ | slangasek, haha, so upstart doesnt log ? | 15:13 |
| ogra_ | heh | 15:13 |
| ogra_ | great | 15:14 |
| slangasek | it *does* log - /properly/ | 15:14 |
| ogra_ | i could write an upstart job to remove it once it hits a certain size ! | 15:14 |
| Riddell | ogra_: ubuntu images work fine on it | 15:15 |
| slangasek | tjaalton: so does my counterproposal make sense? | 15:15 |
| Laney | slangasek: :-) | 15:15 |
| slangasek | (happy to explain it if not - also happy to take the discussion to #upstart, now that I've noticed I had fallen off the channel) | 15:16 |
| tjaalton | slangasek: yeah, I'll test it in a bit | 15:19 |
| slangasek | tjaalton: ok, cool | 15:19 |
| tjaalton | I had --no-wait there first since I copied the idea from somewhere | 15:19 |
| ogra_ | Riddell, hmm, try with a more recent bootimg then | 15:20 |
| cjwatson | How often is the rdepends data on qa.ubuntuwire.com updated? | 15:23 |
| tjaalton | duh, forgot that modemmanager doesn't work with my old laptop (3g builtin). it hangs in shutdown and timeouts after some minutes, not a nice machine for quick testing | 15:23 |
| tjaalton | then again, power button | 15:23 |
| slangasek | tjaalton: modemmanager> hmmm please escalate that to cyphermox | 15:23 |
| cyphermox | err what? | 15:23 |
| slangasek | modemmanager is supposed to be shutdown cleanly by NM | 15:23 |
| cyphermox | yes | 15:24 |
| slangasek | if it's still hanging on shutdown, that's a pretty serious bug | 15:24 |
| tjaalton | cyphermox: I'll update the machine and get back to you later :) | 15:24 |
| cyphermox | it wasn't, but I'll take a look | 15:24 |
| tjaalton | slangasek: seems to work on the non-initrd (=normal) case | 15:26 |
| tjaalton | next the odd one | 15:26 |
| === hedgewars|nemo is now known as nemo | ||
| tjaalton | slangasek: hmm, works without --no-wait | 15:36 |
| tjaalton | slangasek: the non-initrd case | 15:36 |
| tjaalton | slangasek: same thing with initrd case | 15:38 |
| tjaalton | that's probably why it suddenly started working for me, when I dropped it :) | 15:39 |
| tjaalton | slangasek: actually the initrd-case isn't working with your version | 15:42 |
| tim` | hrmm - there appears to be a libqwt6 package but no libqwt6-qw4-dev package | 15:47 |
| tim` | how are you supposed to get qwt6 dev headers? | 15:47 |
| cjwatson | tim`: libqwt-dev | 15:48 |
| roaksoax | stgraber: howdy!! there are critical fixes that I think *need* to be fixed because it truly affects how it behaves in distributed environments and could potenttially break deployments. As far as the media side, i think I would be fine to accept it as a 0-day sru, as long as it hits the archives as part of raring | 15:48 |
| roaksoax | stgraber: Daviey would be a better person to discuss this with :). | 15:49 |
| tim` | cjwatson: thx is 6 default now then ? | 15:49 |
| roaksoax | stgraber: but idk whether he is back in the UK or whether he is flying now. | 15:49 |
| cjwatson | tim`: no idea, I just looked at the package structure ... | 15:50 |
| tjaalton | slangasek: 'status plymouth-splash' should never return 'started' for the initrd case | 15:50 |
| stgraber | roaksoax: ok. We haven't technically started spinning RC media at this point, so if you're 100% sure this won't cause regressions, I think I'm fine to accept it (as 0 day SRUs for main pieces of software is always a bit annoying) | 15:52 |
| tjaalton | slangasek: adding " || plymouth --ping" fixed it :) | 15:53 |
| cjwatson | tseliot: I don't see a transitional package for nvidia-settings-experimental-304 - is it OK to remove anyway? | 15:53 |
| Riddell | ogra_: curiouser, on my other nexus it mounts fine (same boot image) and shows plymouth then goes to a blank screen | 15:53 |
| cjwatson | tseliot: ah, it's provided by nvidia-settings-304/nvidia-settings-304-updates I see; so would "superseded by nvidia-settings-304/nvidia-settings-304-updates" be a suitable removal message? | 15:54 |
| Riddell | ogra_: Serial Debug Shell doesn't work | 15:54 |
| tseliot | cjwatson: oh, good point. I guess it will be ok, since the new drivers will pull in the relevant nvidia-settings flavour anyway | 15:54 |
| === Zic is now known as Guest51927 | ||
| cjwatson | tseliot: The Conflicts/Replaces/Provides are probably sufficient, if those are the correct replacement packages | 15:56 |
| tseliot | cjwatson: I guess a number of packages provide that though | 15:57 |
| cjwatson | tseliot: Yep - well, decide quickly whether you want me to remove it now or whether you want some further packaging change | 15:58 |
| tseliot | cjwatson: ok then please leave the nvidia-settings-* there for now, I'll make sure I come up with some proper transitional packages | 15:59 |
| smb | stgraber, So with that unpleasant UEFI experience there is something that probably should go into the release notes. Problem is that the kernel driver for efivars now refuses to add the ubuntu boot key when the space is already filled up to a certain degree. However the installer does not realize this a just shows the "reboot now" dialogue. Which then does not find anything to boot. | 15:59 |
| stgraber | smb: yep, not sure about what to put in the release notes though... "If you install on UEFI and don't see an Ubuntu entry post-reboot, your system is broken, turn BIOS mode back on and use that."? :) | 16:01 |
| slangasek | smb: oh, is *that* what's happening! | 16:01 |
| slangasek | (bug #1170183) | 16:01 |
| smb | Unfortunately (maybe again AMI) a GPT partition with something in does not count as bootable. Most seem to only look for EFI/BOOT/BOOTxxx.EFI. | 16:01 |
| ubottu | bug 1170183 in grub2 (Ubuntu) "can not boot up in uefi secure boot mode unbuntu 13.04, can run in a live from cd uefi secure mode. will boot non secure boot mode" [Undecided,New] https://launchpad.net/bugs/1170183 | 16:01 |
| stgraber | or actually "reboot your system twice and try again" (as it's the AMI way of triggering the garbage collector and hopefully save some space) | 16:01 |
| smb | stgraber, Did not seem to help on that board... hence caused me to issue the command of doom | 16:02 |
| stgraber | but yeah, I've had that specific issue on one of my UEFI machines and ended up going with a factory reset of the firmware which wiped enough stuff to let me write a new boot entry | 16:02 |
| stgraber | smb: how long had you been using that board with UEFI on raring? | 16:02 |
| stgraber | smb: I'm wondering whether you may have had some kernel panic dumps in pstore/nvram back when we still had that enabled in our kernel which would have caused your nvram to be pretty full and prevent any extra write (that was the cause for the broken efibootmgr on my other UEFI machine) | 16:03 |
| smb | stgraber, Not really long. That board is maybe 1 or two months old. And from that time I only did a UEFI install of 12.04.2 and kept that running. And then had some non-efi installs for other tings. Raring I probably only had tried the one or two weeks | 16:04 |
| smb | The dumpstore output of all variables did not seem to contains anything like dumps | 16:05 |
| stgraber | smb: hmm, ok, so that's not it. 12.04.2 doesn't have pstore efi nvram IIRC and if you only had raring for a couple of weeks you never had that in your kernel (sforshee turned that off after I bricked my laptop for the second time, so 1-2 months ago) | 16:05 |
| smb | But maybe hidden through compression or so. Who knows. Yesterday I still was able to get the ubuntu entry written after I booted through efi shell and re-issued dpkg-reconfigure grub-efi-amd64 | 16:06 |
| smb | Not anymore today | 16:06 |
| stgraber | though I have no idea what kind of crap the firmware may end up storing in there causing it to grow slowly and eventually reach the 50% threshold | 16:06 |
| smb | Yeah, I could not really tell | 16:07 |
| smb | Just hope that not too many people install aside a win8 and secure boot requiring the efi bios... | 16:08 |
| cjwatson | ogra_: I think bug 1153313 may need your attention before the archive team can do anything with it | 16:08 |
| ubottu | bug 1153313 in usb-imagewriter (Ubuntu) "Please port usb-imagewriter to modern APIs, or remove it" [Undecided,New] https://launchpad.net/bugs/1153313 | 16:08 |
| stgraber | well, that's just every single machine you currently find in stores... (and apparently they all have some flavour of the broken AMI firmware, haven't heard of anything shipping with a non-AMI UEFI firmware yet) | 16:09 |
| roaksoax | stgraber: yeah I have been testing this the past week and have not found any regressions. | 16:09 |
| stgraber | roaksoax: ok, good enough for me. I'll let it in now. I can't remember seeing anything horribly wrong when reviewing the diff the other day | 16:09 |
| stgraber | s/other day/this morning/ | 16:10 |
| ogra_ | cjwatson, do you need any attention from me to remove it from the archive ? | 16:10 |
| ogra_ | cjwatson, updated the title :) | 16:11 |
| cjwatson | ogra_: comment in the bug ... | 16:11 |
| smb | stgraber, Yeah, if one would not have missed the good old bios already... anyway, the brick is packed to be sent msi's way. | 16:11 |
| roaksoax | stgraber: i'd like to do a quick run now though? or at what time do you have to release this? | 16:11 |
| roaksoax | stgraber: i think I spotted a tiny issue that I would like to get tested | 16:11 |
| cjwatson | ogra_: https://bugs.launchpad.net/ubuntu/+source/usb-imagewriter/+bug/1153313/comments/1 | 16:11 |
| ubottu | Launchpad bug 1153313 in usb-imagewriter (Ubuntu) "Please remove usb-imagewriter from the archive" [Undecided,New] | 16:11 |
| ogra_ | yeah, just saw it | 16:12 |
| ogra_ | if SSO wouldnt constantly time out on me i could fix that wiki ... | 16:13 |
| stgraber | roaksoax: well, too late, it's already been accepted into the archive... if that issue is problematic enough, just upload again and I'll review the new one | 16:13 |
| ogra_ | cjwatson, added a note that this is only supported until 12.10 | 16:18 |
| ogra_ | feel free to remove it | 16:18 |
| tjaalton | cyphermox: turns out it was caused by (ahem) buggy sssd upstart job which leaves upstart thinking it's running when in fact it failed to start.. so my fault :P | 16:26 |
| tjaalton | "sssd stop/killed, process 1239" -> shutdown waits for 5min until it proceeds | 16:26 |
| tjaalton | but modemmanager at least used to segfault all the time on this machine, I need to revisit that issue.. | 16:27 |
| slangasek | zyga: hi, did you end up filing any bug reports for your efivars/pstore issues? | 16:32 |
| slangasek | zyga: cf. bug #1170183, another user who I've asked to run 'grub-install --uefi-secure-boot' whose boot config failed to be updated | 16:33 |
| ubottu | bug 1170183 in grub2 (Ubuntu) "can not boot up in uefi secure boot mode unbuntu 13.04, can run in a live from cd uefi secure mode. will boot non secure boot mode" [Undecided,New] https://launchpad.net/bugs/1170183 | 16:33 |
| zyga | slangasek: hi | 16:39 |
| zyga | slangasek: actually no, I only sent an email to the ubuntu-devel ML | 16:40 |
| zyga | slangasek: let's see | 16:40 |
| zyga | slangasek: interesting | 16:44 |
| zyga | slangasek: the symptopms are similar, I wonder if the cause is as well | 16:45 |
| roaksoax | stgraber: alright. Uploaded a new package, is a really tiny change to one of the patches. SOrry about that | 16:45 |
| slangasek | zyga: since this seems to be a new install, it seems unlikely to be caused by the kernel filling the nvram | 16:45 |
| zyga | slangasek: indeed | 16:45 |
| zyga | slangasek: but if you recall, there were two oddities in my casae | 16:46 |
| zyga | case | 16:46 |
| zyga | slangasek: nvram going dry _and_ the incorrect image being loaded | 16:46 |
| hallyn | slangasek: ok, so after going through some more links and edk2/ovmf code: indeed you can NOT currently save efi nvram to a file from qemu. david woodhouse was working on a patch in january toward this (http://permalink.gmane.org/gmane.comp.bios.tianocore.devel/1706), and others talk about using qemu's flash fs support. i'll keep looking, and perhaps jump in on the patch to support that. | 16:53 |
| slangasek | hallyn: ah, alrighty | 16:53 |
| hallyn | (see for instance http://blog.hansenpartnership.com/uefi-secure-boot and http://sourceforge.net/mailarchive/forum.php?thread_name=CAFe8ug_dnTdU0OWR_LiGAzmcLgUDvumQJ%3DYgT9jZQmd14BNwHQ%40mail.gmail.com&forum_name=edk2-devel for more confirmation that you can't right now) | 16:53 |
| === Guest51927 is now known as Zic | ||
| xnox | bdmurray: are you uploading ndiswrapper to raring? as far as i can see we want it into precise as well due to linux-lts-raring | 17:07 |
| xnox | or do you want me to upload? | 17:07 |
| bdmurray | xnox: I uploaded it to raring, you could do precise | 17:07 |
| xnox | bdmurray: ack. adding to my todo list for some time later e.g. by 12.04.3 i'm guessing. | 17:08 |
| slangasek | smb, cking: so regarding pstore... why should we not just patch out pstore writing to uefi nvram? | 17:54 |
| slangasek | smb, cking: it seems to be causing us no end of problems, and pre-3.9 there isn't even a "good" way to get at the data to maintain it, AIUI | 17:55 |
| === yofel_ is now known as yofel | ||
| cking | sforshee, ^^ didn't pstore uefi get disabled in raring? | 17:56 |
| stgraber | slangasek: we did actually | 17:57 |
| slangasek | oh | 17:57 |
| stgraber | cking, slangasek: Ubuntu carries an extra patch that disables UEFI nvram storage as a pstore backend | 17:57 |
| slangasek | so we're not pstoring in efi at all anymore? | 17:57 |
| slangasek | cool | 17:57 |
| slangasek | ok, then I guess zyga's problem was just because he managed to fill nvram before that | 17:57 |
| slangasek | and this patch will go (or has gone) into 12.04 enablement kernel, right? | 17:58 |
| stgraber | sforshee wrote that one after we discovered the whole "thinkpad turn into brick on panic" bug | 17:58 |
| stgraber | slangasek: I guess so | 17:58 |
| cking | but also there was a patch to limit uefi vars from filling > 50% or so of space to avoid bricking issues too | 17:59 |
| stgraber | slangasek: I think that in theory we could remove mjg59 change to restrict nvram writes when > 50% of space used as without the pstore use case, it should be relatively safe to do so | 17:59 |
| cking | one issue is that now we may not have enough free space to set the boot vars and hence installs fail if we run low | 18:00 |
| stgraber | cking: right, both try to address the same problem in different ways. mjg59's patch simply rejects any write done when we're past 50% of used space and that's what actually prevents efibootmgr from doing its job on some systems. sforshee's patch is specific to the use of nvram for pstore and essentially disables the biggest source of nvram writes | 18:00 |
| cking | stgraber, yep, i concur with that | 18:00 |
| stgraber | so it "should" be safe to turn off the 50% one on Ubuntu, though this may still lead to some bricks if for example you have too many secureboot keys being added or any similar thing | 18:01 |
| cking | stgraber, we just need to make sure users now don't tidy up their uefi vars by deleting them all and bricking their machines :-/ | 18:01 |
| stgraber | (it's a case where all solution sucks... the real solution is to get a fixed firmware on those machine that does proper garbage collection and doesn't blow up when the nvram is empty or full) | 18:02 |
| cking | stgraber, indeed. firmware sucks | 18:02 |
| slangasek | other issues: - efibootmgr doesn't output any error messages on failure; - grub-install doesn't capture the error code from efibootmgr | 18:02 |
| cking | slangasek, yes, the silent fail is a big fail | 18:02 |
| stgraber | slangasek: right, I saw that on a machine and didn't even realize it was caused by the 50% thing... I (wrongly) assumed it was a bad firmware, I updated to the new one which fixed it (likely because it forced the garbage collector or freeed some nvram variables) | 18:03 |
| stgraber | cking: does the kernel at least log something when it refuses a write because of the 50% stuff? A dmesg entry would be kind of nice (on top of having the userspace tools return an error message) | 18:03 |
| cking | stgraber, ideally the failed update should return an error code so apps can react to that, not sure about the kernel messages | 18:04 |
| cking | sforshee, any ideas ^^ | 18:04 |
| * sforshee tries to catch up after returning from lunch | 18:06 | |
| sforshee | stgraber, if writes are done via the raw_var sysfs attribute then there should be an error code and something in dmesg | 18:09 |
| cking | something like efivars: set_variable() failed: status=.... ? | 18:10 |
| sforshee | yes | 18:11 |
| cking | I think if it ends in 9 then you've run out of free spafe | 18:11 |
| cking | *space | 18:11 |
| cking | ..and you get -EIO on a failed write I believe | 18:11 |
| sforshee | some other paths don't print to dmesg, but they all ought to return errors | 18:13 |
| stgraber | sforshee: is there an easy way to special case the boot order variable? | 18:14 |
| stgraber | All of ^Boot* actually | 18:15 |
| sforshee | stgraber, with the way the driver is today there are multiple paths by which the variable could be written | 18:16 |
| sforshee | stgraber, there are probably only a couple that matter though | 18:17 |
| cking | ultimately one is at the mercy of the firmware run time service to update the vars though | 18:17 |
| stgraber | yeah, my guess is that we always want BootOrder and BootXXXX so that we can setup the boot entry | 18:17 |
| slangasek | hmm, I think I've spotted a simpler explanation for bug #1170183; we'll see what the submitter comes back wiht. | 18:18 |
| ubottu | bug 1170183 in grub2 (Ubuntu) "can not boot up in uefi secure boot mode unbuntu 13.04, can run in a live from cd uefi secure mode. will boot non secure boot mode" [Undecided,New] https://launchpad.net/bugs/1170183 | 18:18 |
| slangasek | stgraber: "special case" them how? excluding them from the 50% restriction? | 18:18 |
| stgraber | slangasek: yep | 18:19 |
| cking | and then risking bricking some machines? | 18:19 |
| slangasek | right - the machines that are affected won't care how much over 50% you are | 18:22 |
| slangasek | the failsafe is there because we don't have a saner option | 18:22 |
| slangasek | so I think it's more important instead to fix efibootmgr+grub-install wrt error reporting | 18:22 |
| === Ursinha is now known as Ursinha-afk | ||
| * cking got kids to sort out - sorry, need to go | 18:23 | |
| stgraber | and say what? sorry you can't use UEFI on that box because your firmware is crap, switch back to BIOS and try again? (I rechecked the post by Matthew and yeah, I agree we shouldn't write past the 50%. I had the hope it'd only apply to new variables but apparently not) | 18:24 |
| cking | stgraber, essentially, yes, firmware is the limiting factor | 18:24 |
| stgraber | would be nice if we could somehow detect that before wiping the user's harddisk... | 18:25 |
| cking | either it bricks (v bad) or won't install (annoying) | 18:25 |
| slangasek | stgraber: not "sorry your firmware is crap", but "sorry your nvram is full, here's some helpful advice on how to clean it up safely" | 18:26 |
| sforshee | slangasek, do we have advice on how to clean it up safely other than "try rebooting a couple of times and see if that helps"? | 18:26 |
| stgraber | hmm, yeah, I guess we could recommend doing a firmware factory reset and reboot twice, that "may" help freeing up nvram space | 18:27 |
| slangasek | sforshee: well, what I had zyga do was "rm /sys/firmware/efi/efivars/dump*" | 18:27 |
| sforshee | that's only going to help people who were running raring during development though | 18:27 |
| slangasek | that's the only confirmed cause of too-full nvram so far | 18:28 |
| slangasek | and no, it's not raring-only... this problem was seen in quantal too | 18:28 |
| slangasek | maybe raring's kernel is the only one with the 50% guard, but you could have already filled your nvram up by running quantal | 18:28 |
| sforshee | ah, that's right | 18:28 |
| stgraber | ah, we had nvram backend pstore in quantal? | 18:29 |
| stgraber | if we did, I was extremely lucky not to brick my machine before the 3.8 kernel | 18:29 |
| slangasek | stgraber: yes, that's basically what was bricking the samsung machines | 18:29 |
| zyga | hmm | 18:30 |
| zyga | slangasek: did my email start any internal discussion about how to use nvram? | 18:30 |
| slangasek | zyga: no | 18:30 |
| slangasek | zyga: I asked you to file bugs :) | 18:30 |
| slangasek | zyga: but it sounds like the kernel team was already on the ball and patched out nvram pstore in raring... you just already had a too-full nvram by that point | 18:31 |
| zyga | slangasek: you are right, I should have filed them right away | 18:31 |
| * zyga sometimes feels that with the swarm of bugs, a message to a mailing list works better to start a conversation about a diffucult topic | 18:33 | |
| === Ursinha-afk is now known as Ursinha | ||
| tjaalton | slangasek: i've pushed plymouth to ubuntu-x-swat/x-staging ppa | 19:01 |
| tjaalton | with the job | 19:02 |
| slangasek | tjaalton: ok. care to raise a branch mp to go with it? | 19:02 |
| tjaalton | slangasek: I'd need to use bzr, that takes time :) | 19:02 |
| slangasek | pff | 19:02 |
| tjaalton | checking out | 19:03 |
| slangasek | actually, looks like the branch is out of date because infinity and the package importer both failed to update it | 19:03 |
| slangasek | let me fix that | 19:03 |
| tjaalton | yeah looks like it | 19:04 |
| tjaalton | added plymouth.plymouth-ready.upstart and dh_installinit line to rules | 19:04 |
| slangasek | branch updated | 19:05 |
| mlankhorst | ogasawara: what happens with armel for the enablement stack, is it explicitly unsupported? | 19:06 |
| bdmurray | where is the python-apt upstream? lp:python-apt is behind ubuntu raring | 19:06 |
| ogasawara | mlankhorst: it's not supported | 19:06 |
| slangasek | (well, modulo race condition with my shell not having returned yet from 'bzr push') | 19:06 |
| slangasek | bdmurray: 'debcheckout -a python-apt' should DTRT here I think | 19:06 |
| tjaalton | hmm, bzr pull didn't do what I wanted? | 19:07 |
| mlankhorst | ok good, I'll fix up mesa-lts-raring to not fail to build on armel, but I'm 90% sure it won't actually run | 19:07 |
| slangasek | tjaalton: did you hit the race with me telling you it was done before it was (sorry)? :) | 19:07 |
| tjaalton | slangasek: no, pulled afterwards | 19:08 |
| slangasek | tjaalton: ok. if it didn't do what you wanted, what /did/ it do? | 19:08 |
| tjaalton | I'll just clone it again | 19:08 |
| tjaalton | not sure what happened, bzr diff looks messy | 19:08 |
| tjaalton | ooh, managed to push it too | 19:14 |
| tjaalton | slangasek: so how to do the mp? | 19:15 |
| tjaalton | oh there it is | 19:16 |
| tjaalton | https://code.launchpad.net/~tjaalton/plymouth/race-fix | 19:16 |
| slangasek | tjaalton: ta | 19:42 |
| bdmurray | stgraber: there is a crash on errors that is only about isc-dhcp version 4.2.4-1ubuntu10.2 from quantal-proposed | 19:53 |
| bdmurray | https://errors.ubuntu.com/bucket/?id=/sbin/dhclient%3A11%3Aoption_state_reference%3Apacket_to_lease%3Adhcpoffer%3Abootp%3Aassemble_hw_header | 19:54 |
| stgraber | bdmurray: odd, the only actual source change in that SRU is the UDP checksum offload, but it's been taken as-is from RedHat and is used in all RedHat derivatives and in raring, so I'm quite surprised it only shows up in quantal-proposed | 19:58 |
| bdmurray | Well it could be that the bucketing is too specific. | 19:59 |
| bdmurray | ah maybe its bug 1048403 | 20:00 |
| ubottu | Error: Launchpad bug 1048403 could not be found | 20:00 |
| stgraber | the stacktrace also doesn't show anything that's been touched by the extra patch | 20:00 |
| bdmurray | https://errors.ubuntu.com/bucket/?id=/sbin/dhclient%3A11%3Aoption_state_reference%3Apacket_to_lease%3Adhcpoffer%3Abootp%3Ado_packet | 20:00 |
| stgraber | if it was a bug introduced by the SRU, I'd have expected to see decode_udp_ip_header in the trace | 20:00 |
| stgraber | bdmurray: ah yeah, that looks pretty similar. | 20:01 |
| stgraber | bdmurray: it's actually the same guy that triggered both entries (look at the IPs in the trace, they're the same) | 20:02 |
| bdmurray | thanks for looking | 20:05 |
| stgraber | so yeah, I don't think we should worry too much about this. Typically isc-dhcp issues are a pain to figure out from coredump, as they're almost impossible to replicate. | 20:05 |
| stgraber | If they guy ever gets around to reporting it on Launchpad and is technical enough, I'll ask him for a pcap of the DHCP traffic, with that it's then trivial to reproduce | 20:06 |
| slangasek | Mirv: hey, so bug #1131636 (which should probably be duped to #1155327) has a claim now that QtWebkit 2.3.1 fixes the skype/nvidia/webkit regression... is there something here that you could maybe cherry-pick for us? | 20:11 |
| ubottu | bug 1131636 in skype (Ubuntu) "After QtWebkit update Skype is not launching" [Undecided,Confirmed] https://launchpad.net/bugs/1131636 | 20:11 |
| hallyn | is there a 'proper' command-line way to detect http proxies specified in apt.conf? | 20:23 |
| slangasek | hallyn: interesting question. Why do you want them? | 20:24 |
| slangasek | hallyn: last time I tried to use "http proxy specified in apt.conf" for something that wasn't apt, google yelled at me ;) | 20:24 |
| hallyn | slangasek: I'm looking for an intelligent deafult for containers | 20:25 |
| slangasek | hallyn: so you want to extract the setting from the host for provisioning the guest? | 20:25 |
| hallyn | right now we support a MIRROR variable in lxc.conf, but it has been suggested that the /etc/apt/apt.conf/70-procy or wahtever is the way to go | 20:25 |
| hallyn | right | 20:25 |
| slangasek | hallyn: 'apt-config shell'; cf. /etc/cron.daily/apt | 20:26 |
| hallyn | (thanks, looking) | 20:28 |
| infinity | hallyn: | 20:29 |
| infinity | (base)adconrad@cthulhu:~$ apt-config shell APT_PROXY Acquire::http::Proxy | 20:29 |
| infinity | APT_PROXY='http://127.0.0.1:3142/' | 20:29 |
| infinity | ^-- For example. | 20:29 |
| infinity | (And then just eval that) | 20:30 |
| hallyn | thanks | 20:30 |
| hallyn | of course, if people commonly do localhost (like you did), then that won't work. but i guess i can autodetect that | 20:31 |
| infinity | It's a pretty common setup for people with apt caches. | 20:31 |
| dtchen | yeah, it helps heaps with these test-rebuilds | 20:33 |
| hallyn | right. i do it - but i wasn't sure that meant others would :) | 20:33 |
| hallyn | all right well i can just ignore it if its 127.anything | 20:33 |
| hallyn | (and still let MIRROR override it) | 20:33 |
| hallyn | thanks again | 20:33 |
| infinity | dtchen: Oh, I didn't want to go rejecting things because an FTBFS patch that works is better than none at all. | 20:35 |
| infinity | dtchen: But you should try to avoid the layering violation of injecting DEB_HOST_MULTIARCH into upstream configure checks, etc. | 20:35 |
| infinity | dtchen: And instead push patches upstream to actually use the compiler to find things instead of fighting against it by guessing at paths. | 20:36 |
| === salem_ is now known as _salem | ||
| dtchen | infinity: noted | 20:36 |
| === wedgwood is now known as wedgwood_away | ||
| === wedgwood_away is now known as wedgwood | ||
| === _salem is now known as salem_ | ||
| === rickspencer3_ is now known as rickspencer3 | ||
| === Ursinha is now known as Ursinha-afk | ||
| === salem_ is now known as _salem | ||
| mhough | can anyone help me with the removal of libgoogle-glog-dev? | 22:55 |
| mhough | the launchpad info just doesn't make sense | 22:56 |
| mhough | said removed for qa reason but the bug listed is for a different package/language | 22:56 |
| ScottK | mhough: Link | 22:58 |
| mhough | thanks | 22:59 |
| mhough | https://launchpad.net/ubuntu/precise/amd64/libgoogle-glog-dev | 22:59 |
| mhough | if you follow the bug link does that make sense? | 23:00 |
| cjwatson | mhough: Launchpad renders the link wrongly | 23:03 |
| cjwatson | mhough: Try http://bugs.debian.org/662137 | 23:03 |
| ubottu | Debian bug 662137 in ftp.debian.org "RM: google-glog -- RoQA; FTBFS, unackowledged" [Normal,Open] | 23:03 |
| cjwatson | mhough: FWIW that was a largely automatic removal - we tend to track packages that have been removed from Debian unless there's some special reason not to (substantial Ubuntu modifications, remaining reverse-dependencies, present on one of the images we build, etc.) | 23:04 |
| mhough | I see. Thanks for all the help | 23:05 |
| sarnold | why was it only removed from precise and not oneiric, quantal, or raring? | 23:05 |
| cjwatson | Well it clearly couldn't have been removed from quantal or raring since they didn't exist yet | 23:05 |
| mhough | what is an RC bug? | 23:05 |
| cjwatson | And we don't remove packages from existing stable releases | 23:06 |
| cjwatson | release-critical (Debian term) | 23:06 |
| sarnold | cjwatson: ah :) thanks | 23:06 |
| cjwatson | Looks like it was later reintroduced | 23:07 |
| cjwatson | Somebody picked it up and fixed the RC bugs | 23:07 |
| cjwatson | But nevertheless I think it's right to err on the side of not shipping packages that we may not be able to stand behind | 23:08 |
| cjwatson | https://launchpad.net/ubuntu/+source/google-glog/+publishinghistory shows the sequence of events | 23:08 |
| jbicha | bug 1151844 is interesting then | 23:08 |
| ubottu | bug 1151844 in google-glog (Ubuntu) "[MIR] google-glog" [Undecided,Fix committed] https://launchpad.net/bugs/1151844 | 23:08 |
| mhough | does that mean the package be readded? | 23:09 |
| cjwatson | mhough: Yes, in >=12.10 | 23:09 |
| cjwatson | jbicha: Well, as I say, the package was fixed up and reintroduced in quantal | 23:09 |
| jbicha | oh never mind then :) | 23:09 |
| mhough | the maintainer of another package is asking me the best way for people to read the package to build his package on precise | 23:10 |
| mhough | sorry re-add | 23:10 |
| cjwatson | Probably easiest to put it in a PPA | 23:10 |
| mhough | the 12.10 version? | 23:10 |
| cjwatson | If that works | 23:10 |
| mhough | gotcha | 23:10 |
| mhough | thanks | 23:10 |
| cjwatson | It would be extremely rare and exceptional for us to introduce (effectively) new packages in stable updates | 23:10 |
| mhough | no I see that | 23:11 |
| cjwatson | It does happen but there'd have to be a driving reason | 23:11 |
| mhough | sure | 23:11 |
| mhough | probably not for obscure DICOM package | 23:11 |
| cjwatson | That might be a tough sell | 23:11 |
| ScottK | It could be added in backports. | 23:15 |
| cjwatson | True | 23:15 |
| mhough | well I don't mind adding it to a launchpad PPA to learn how to do that | 23:17 |
| ScottK | !backports | mhough | 23:17 |
| ubottu | mhough: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging | 23:17 |
| mhough | but if you think its worth adding it to | 23:17 |
| ScottK | updated can also mean doesn't exist. | 23:17 |
| mhough | ok | 23:17 |
| ScottK | You're call. | 23:17 |
| ScottK | your | 23:18 |
| mhough | hopefully his package will be in neurodebian or med debian | 23:18 |
| mhough | is orthanc there yet? | 23:18 |
| cjwatson | http://packages.qa.debian.org/o/orthanc.html ? | 23:19 |
| mhough | yeah I see in unstable sid | 23:19 |
| cjwatson | It's in raring too. https://launchpad.net/ubuntu/+source/orthanc/+publishinghistory | 23:19 |
| cjwatson | We try to keep track of new packages as well as removals ;-) | 23:20 |
| cjwatson | (Actually rather better - that side is more fully automated) | 23:20 |
| mhough | so would that justify libgoogle-glog-dev for a backport? | 23:20 |
| cjwatson | If you were backporting orthanc too, yes | 23:21 |
| mhough | I see | 23:22 |
| mhough | let me see how it goes with them on my ppa first I guess right? | 23:23 |
| cjwatson | Sure | 23:23 |
| * cjwatson gets the archive admin to-do list down to three long-term items (one in progress) and one removal pending verification by the server team | 23:24 | |
| cjwatson | Phew | 23:24 |
| === wedgwood is now known as wedgwood_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!