[07:36] <darkxst> infinity, hi, can organise someone to setup ddebs on that ppa today (ppa:gnome3-team/gnome3-next), thanks!
[15:03] <slangasek> ara, stgraber: looks like we're sorted now wrt old-releases?  (apparently it required a manual sync by IS?)
[15:07] <stgraber> slangasek: the sync is still failing but at least they triggered one manually
[15:08]  * slangasek nods
[15:08] <slangasek> which should be as many as we need for the next few months
[15:12] <ara> cool, thanks!
[16:36] <rtg> sarnold, can you process bug #1214979 now that the point release is done ?
[16:36] <ubot2`> Launchpad bug 1214979 in apparmor (Ubuntu Precise) "Feature buffer full in precise with LTS kernel" [Undecided,Fix committed] https://launchpad.net/bugs/1214979
[16:38] <sarnold> rtg: yes, thanks for the reminder
[18:42] <NikTh> Hello,
[18:42] <NikTh> Can someone to change this[1] please ?  [1] - http://i.imgur.com/McFyLrP.jpg
[18:43] <infinity> NikTh: Yup.
[18:43] <NikTh> infinity: Thanks :-)
[18:43] <slangasek> grumble, how'd I miss that
[18:43] <slangasek> infinity: thanks
[18:44] <infinity> slangasek: Because the front page indexes are done by hand, and someone always forgets a bit?
[18:44] <slangasek> well, I followed the checklist
[18:44] <slangasek> so maybe the checklist is missing a bit
[18:44] <infinity> NikTh: Done.
[18:45] <infinity> slangasek: It could be missing the "verify correctness of simple/HEADER.html" bit.
[18:46] <NikTh> Also here https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop , the LibreOffice version is 3.5.7 , not 3.5.4 .. but this I can change it my self :-)
[18:46] <infinity> slangasek: Although, publish-image-set used to have some verbage to that effect, I thought.
[18:46] <slangasek> infinity: publish-image-set has some verbiage which is completely wrong for the point release, fwiw
[18:47] <infinity> slangasek: That would do it. :P
[18:47] <NikTh> infinity: Maybe the 10.04.4 LTS should be removed from there ? Or place a (server only) next to it ?
[18:48] <infinity> NikTh: Certainly not removed.
[18:48] <infinity> NikTh: You'll note if you click through that it only has server ISOs, I archived the desktop ones off.
[18:49] <NikTh> infinity: Yes, you have right.  Server Install CD , only. OK.
[18:52] <infinity> I suppose if we think people are trying to make informed decisions about what to install based on that page, either a prominent pointer to a lifecycle page on the wiki, or an "(Approximate EOL: Foo 13, 20XX)" after each one might be helpful.
[18:52] <infinity> If I could remember the name of the wiki page with the release/eol dates...
[18:53] <NikTh> infinity: https://wiki.ubuntu.com/Releases
[18:55] <infinity> NikTh: Danke.  You'd think I'd remember that, given the edits I've done to it.
[18:55]  * infinity is still convinced that wikis are where data goes to die.
[18:56] <NikTh> infinity:  :-)
[19:06] <NikTh> Question (of topic a little bit). gnome-session --version , results in 3.2 version (on 12.04.3 LTS) , but "system monitor"(GUI) reads 3.4 version of Gnome. How you define the gnome version in an Ubuntu release ?
[20:12] <slangasek> xnox: bug #1216853> er... since when do we support PXE booting livefs images?
[20:12] <ubot2`> Launchpad bug 1216853 in casper (Ubuntu) "LiveCD missing nfs/crypt kernel modules in the initramfs - During PXE booting failed to mount nfs directory" [High,Confirmed] https://launchpad.net/bugs/1216853
[20:13] <cjwatson> since years
[20:13] <cjwatson> I remember lifeless (I think) helping to get that working way back when
[20:14] <cjwatson> well, I don't know about "support" since it isn't well-tested, but it is meant to work
[20:16] <slangasek> oh, hmm
[20:16] <slangasek> I thought we only PXE booted the d-i images
[20:18] <cjwatson> it was definitely made to work end to end with ubiquity at one point
[20:18] <cjwatson> ... or at least live session booting, but I think ubiquity too
[20:21] <xnox> yeah, it does work and i think even someone deploys desktop machines like that.
[20:26] <xnox> let's see if fixing bug 1217041 resolves bug 1216853
[20:26] <ubot2`> Launchpad bug 1217041 in initramfs-tools (Ubuntu Precise) "initramfs-tools: please include separated nfs modules" [Undecided,Confirmed] https://launchpad.net/bugs/1217041
[20:26] <ubot2`> Launchpad bug 1216853 in casper (Ubuntu) "LiveCD missing nfs/crypt kernel modules in the initramfs - During PXE booting failed to mount nfs directory" [High,Confirmed] https://launchpad.net/bugs/1216853
[20:52] <infinity> xnox: Oh bah, I thought I backported that to precise. :/
[20:53] <xnox> infinity: =/ happens. I am confused about crypt modules. cryptsetup was changed to only include them in the initramfs, if needed or if a flag variable is set. Can live-cd somehow include crypt modules in the initramfs unconditionally?
[20:53] <infinity> xnox: The problem is that that won't fix the ISO, even if we backport it now.
[20:54] <infinity> (Unless we respin the point release)
[20:54] <xnox> infinity: well not 12.04.3, but i somehow thought precise-daily will get fixed and well 12.04.4.
[21:04] <xnox> Yeah, -rc7 which hopefully fixes javac SEGV =)
[21:05] <xnox> infinity: are precise-dailies build with -proposed enabled again?
[21:06] <infinity> xnox: Nope, but could do.
[21:07]  * infinity tried to remember the syntax...
[21:07] <infinity> slangasek: When you tore all the PROPOSED out of crontab, was it "PROPOSED=1"?
[21:07] <slangasek> infinity: yes
[21:08] <slangasek> is that what we want at this point?
[21:08] <slangasek> or should that only be done for one-off testing?
[21:08] <infinity> slangasek: Why not?  May as well have proposed enabled up until a few weeks before .4
[21:09] <infinity> It shouldn't suffer the same consistency/installability issues that devel-proposed does, and if it does, we want to know about it anyway.
[21:09] <slangasek> well, ok
[21:10] <infinity> xnox: precise-daily is all proposey again.
[21:11]  * infinity still finds it bizarre that anyone outside our QA labs would consider PXE booting the desktop CD a sane and reasonable option.
[21:11] <infinity> Different strokes, I guess.
[21:11] <xnox> slangasek: infinity: i guess the price cd will gain all the verification-failed packages which haven't been removed from -proposed.
[21:12] <infinity> xnox: That's fine.  It's incentive for us to actually remove stuff from proposed. :P
[21:29] <slangasek> cjwatson: so can you remind me the rationale for https://help.ubuntu.com/community/UbuntuHashes and it's annoying immutability?
[21:30] <slangasek> s/it's/its/
[21:33] <infinity> slangasek: I think the rationale was that it's https, and provides a trust path for people who don't/can't trust the GPG signed hashes for some weird reason or other.
[21:33] <infinity> (A weak rationale, to be sure, but there it is)
[21:34] <infinity> It could use all the EOL releases removed...
[21:34] <slangasek> is that something we want to encourage, though?  (maybe, maybe not - just want to make sure we have a clear and understood rationale for this thing that lives outside ubuntu-cdimage's control and causes more work)
[21:35] <infinity> I'm not sure.  The argument seems a bit dubious when it's indistinguishable from a random wiki page that could also be https and made to look identical with incorrect values.
[21:36] <slangasek> well, it's a "well-known" address, it's https, and it's not generally modifiable
[21:36] <infinity> Perhaps replacing it with a GPG verification HOWTO (including Win32 instructions) might not be a bad plan, and https links to our signing keys.
[21:41] <xnox> infinity: where are the GPG key fingerprints published? not many have trust of path to that, is there some https location with those?
[21:42] <infinity> xnox: We could make one.
[21:42] <infinity> (If there isn't one already)
[21:43] <slangasek> if we do, please make sure that updating it becomes part of the documented key rotation process
[21:43] <xnox> a fingerprint is listed here: https://help.ubuntu.com/community/VerifyIsoHowto but that's not explicit, just a by-product of the procedure output.
[21:43] <infinity> slangasek: Or have it automagic somehow.
[21:43] <slangasek> infinity: which is not going to happen day 1, so it needs to be documented :P
[21:44] <xnox> http://archive.ubuntu.com/ubuntu/project/ has the keyring.
[21:44] <slangasek> not the cdimage keyring
[21:44]  * xnox never knew we have souce.isos
[21:44] <infinity> We ship the cdimage key in the ubuntu-keyring package, is that not the same keyring found on /ubuntu/project/?
[21:47] <slangasek> infinity: why would we ship the cdimage key in the ubuntu-keyring package?  Oh, is that needed for trusting the apt sources on alternate CDs?
[21:47] <infinity> slangasek: That, yes.
[21:47] <infinity> slangasek: See `apt-key list`
[21:48] <slangasek> hmm, ok
[21:48] <slangasek> regardless, the point is to have an https trust path for those that don't already have the joy of running Ubuntu
[21:49] <infinity> Right, so an automated process that tears out the keyring from ubuntu-keyring and dumps it to a well-known https location doesn't sound like it'd be rocket surgery.
[21:49] <infinity> In both GPG keyring format and massive ASCII-armored blob of doom.
[21:51] <infinity> A bit of work, sure, but would cut down on skinning cats seven different ways down the road.
[21:52] <infinity> And, realistically, anyone who can't be bothered to set up PGP/GPG to test the MD5SUM signature probably also won't do due diligence to make sure our SSL cert is trustworthy in any meaningful way. :P
[21:55] <infinity> (Alternately, we could stick with the status quo, but maybe open up the list of people who can update that page a little bit...)
[21:59] <sarnold> if we're redesigning things, I'd quite like an .asc file for each .iso, to save the hassle of downloading a sha256sums file and seeing a few dozen FAIL messages, or juggling three or four sha256sums files depending upon the versions of ubuntu I've downloaded
[22:00] <sarnold> if we had a nice gpg detached sig for each iso, there'd be no name collisions and no dozen listed files that I _didn't_ download..
[22:03] <infinity> sarnold: The only minor concern with that is that it makes the directory a bit messier and confusing to people who have no idea what an "asc" is, download the wrong file, and wonder why they can't burn it.
[22:03] <infinity> One would hope that people that easily confused are downloading via direct links from www.u.c/download, but I suspect that's not always true.
[22:04] <sarnold> infinity: yeah, it would roughly double the files in each directory. But I hope the one-second download time might be a clue that it isn't a full-featured operating system they just downloaded :)
[22:04] <infinity> sarnold: Maybe it's just really efficient?
[22:04] <sarnold> infinity: haha, very efficient :)
[22:09] <infinity> sarnold: I'm sure I could download some old Slack or Debian floppies on my link in a second or so.  That Linux thing isn't supposed to be bloated like Windows, right? :)
[22:10] <sarnold> infinity: just be sure you've got at least 16 megabytes of RAM if you're going to use X11!
[22:16] <darkxst> infinity, hi
[22:16] <infinity> darkxst: Yo.
[22:17] <darkxst> infinity, can you get those ddebs sorted for me ;)
[22:17] <infinity> darkxst: Remind me of which PPA it was?
[22:17] <darkxst> ppa:gnome3-team/gnome3-next
[22:23] <infinity> darkxst: Iz done.
[22:23] <darkxst> infinity, thanks ;)
[22:57] <xnox> infinity: can linux-signed be hinted to not wait for autopackagetest of a wrong version to pass, the right version has passed.
[22:58] <infinity> xnox: Yeah, I'll hint it in a bit, and try to get someone to dig deeper into WTF goes wrong there.
[23:59] <stgraber> cjwatson: FYI I'm going to override the autopkgtest result for network-manager as britney seems to be confused. It's the second upload where it thinks it's still running even though it passed.