[09:56] <knome> is there any way to limit http://iso.qa.ubuntu.com/qatracker/milestones/210/builds to eg. xubuntu with get parameters?
[09:56] <knome> stgraber, ^ ?
[09:59] <knome> also, any idea why yesterdays builds of our desktop images appear at the tracker?
[09:59] <infinity> knome: Not sure, but you can just click on "Products" to disable them all, and then turn on Xubuntu.
[10:00] <knome> infinity, i know that :) i was just wondering because i wanted to *link* to the page but only with xubuntu images listed
[10:00] <infinity> knome: Yeah, not sure if that's doable, but stgraber will know.
[10:00] <knome> technically, it shouldn't be too hard to implement that for Q
[10:01] <infinity> knome: As for why the most recent are in the tracker, dailies auto-post, and we haven't turned off the cronjobs yet.
[10:01] <knome> (if it's not implemented already, i mean)
[10:01] <infinity> (I imagine we'll go manual on Monday)
[10:01] <knome> so, what should i test?
[10:02] <infinity> You can smoketest and let us know if things are horribly broken.
[10:02] <infinity> But we've had things like a new upstart and openssl (y'know, insignificant packages...) that would have required respins if we were in manual mode anyway.
[10:03] <knome> heh
[10:03] <infinity> I don't recommend doing deep end-to-end testing until we go manual, but quick smoketesting is always appreciated.
[10:04] <knome> mmh.
[10:04]  * knome zsyncs the xubuntu amd64 desktop
[10:06] <infinity> (Of course, if you're bored and have time to waste, no one will turn down end-to-end testing, just saying that if you have better things to do and want to retain your sanity, you might want to hold off until we've turned off dailies)
[10:06] <knome> heh
[10:06] <knome> let's say i'd like to generally see what we look like, and i can do testing meanwhile :)
[10:06]  * infinity nods.
[10:07] <infinity> I haven't spun up a Xubuntu CD yet this cycle.
[10:07] <infinity> I actually *run* Xubuntu, but my desktop is so customized that I have no idea what the Precise defaults are looking like.
[10:07] <knome> you should. we tweaked pretty much everything in the graphical side ;)
[10:07] <infinity> Speaking of, I really, really need to find the time to port the Human theme to GTK3.
[10:08] <knome> new logo, new wallpaper, improved plymouth theme, improved lightdm theme
[10:08] <infinity> (Yes, I use Human with Xubuntu, in a mad effort to recreate my GNOME2 experience from 5 years ago)
[10:08] <knome> improved gtk theme... :)
[10:11] <infinity> http://lucifer.0c3.net/~adconrad/xubuntu.png <-- See?
[10:11] <infinity> I'm a creature of habit. :P
[10:11] <knome> heh
[10:12] <knome> http://temp.knome.fi/other/shot-20120325.png
[10:13] <knome> i'm not giving up my panel layout either
[10:13] <infinity> Heh.
[10:13] <knome> but see, our new wallpaper graciously spans even 2 monitors! :)
[10:14] <infinity> Fancy.
[10:14] <infinity> Dear god, you run IRC black-on-white?
[10:14] <infinity> Heathen!
[10:15] <knome> that's our new default terminal color scheme
[10:15] <knome> see how well that fits the theme in the other terminal window?
[10:15] <knome> (the scrollbar BG is fixed for precise, btw)
[10:16] <infinity> http://lucifer.0c3.net/~adconrad/terminals_should_be_black.png
[10:17] <infinity> Crazy people and their light terminals.
[10:17] <knome> ugghh, that's way too much contrast :)
[10:17] <knome> either you have a bad monitor or you like to hurt your eyes
[10:17] <infinity> I do a lot of computing in the dark.
[10:17] <infinity> Bright screens hurt.
[10:17] <knome> i didn't say "bright screen" :)
[10:17] <knome> i said bad screen
[10:18] <knome> actually, i said bad monitor
[10:18] <knome> ;)
[10:18] <infinity> Heh.
[10:18] <infinity> Anyhow, speaking of the dark, I should sleep.
[10:18] <infinity> Happy smoketesting.
[10:18] <knome> heh, good night :)
[10:19] <knome> and thanks, i'm sure i will have a superfluously happy time ;)
[11:23] <Laney> any objections to approving the zsh ffe?
[11:24] <Laney> (seeding)
[13:11] <cjwatson> infinity: versioned deps in udebs aren't as useful as they look, no - but d-i's packaging system isn't meant to solve all the problems
[13:11] <cjwatson> Daviey: better to just rebuild d-i
[14:58] <ScottK> cjwatson: I assume you want this D-I upload in?
[15:09] <skaet> Daviey, looks like server amd64 has gone oversize,  what can get removed?
[15:11] <cjwatson> ScottK: yep, fixes libcrypto vs. libssl mismatch on server
[15:11] <ScottK> OK.  Accepting.
[15:11] <ScottK> DOne.
[15:13] <cjwatson> thanks
[15:14] <ScottK> No problem.  It was an easy diff to review ...
[15:14] <cjwatson> :-)
[15:19] <cjwatson> skaet: bug 545790 has had the rls-p-tracking tag removed, and should no longer be on http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html, but is
[15:19] <ubot2> Launchpad bug 545790 in dpkg "package PACKAGE failed to install/upgrade: error writing to '<standard output>': Success" [High,Triaged] https://launchpad.net/bugs/545790
[15:20] <skaet> cjwatson,  I'll ask it be regenerated properly on monday.   thanks.
[15:21] <cjwatson> thanks
[15:40] <Daviey> skaet: I am aware, i started trimming on Friday.. Will finish tommohrrowh
[15:40] <skaet> Thanks Daviey.  :)
[16:06] <Daviey> cjwatson: confirmed rebuild solved the issue, thanks.
[16:57] <ScottK> accepted raptor
[17:28] <stgraber> knome: it should be possible to implement but it's going to be a bit hackish :) the current filtering is done entirely with javascript + cookie
[17:29] <stgraber> knome: and it's saved in the cookie which you likely won't want to see happen when giving people a link
[17:30] <knome> stgraber, i see, but i don't think it's hackish :)
[17:31] <phillw> stgraber: we may have a regression for WiFi. I've seen it and it has been mentioned. Not sure what to raise it against. http://ubuntuforums.org/showthread.php?t=1873477 seems the nearest for it. Can you let me know what to report it against please?
[17:32] <phillw> https://www.facebook.com/groups/lubuntu.official/ has the screen shot
[17:35] <stgraber> phillw: can you copy the screenshot somewhere public? I don't have a facebook account
[17:35] <knome> stgraber, \o/
[17:36] <stgraber> from what I can see on the forum, this might be a question for cyphermox
[17:36] <phillw> stgraber: I'm just grabbing it & uploading it... a couple of minutes.
[17:45] <phillw> stgraber: http://thesii.org/Screenshot.jpg
[17:46] <phillw> sorry, it dodn't want to go the 1st time!
[18:02] <stgraber> phillw: sounds like policykit/nm/... might be worth opening a bug against network-manager for now so it at least gets looked at
[18:03] <phillw> stgraber: okies, I'll get a bug raised.
[19:15] <phillw> bug 964705 created
[19:15] <ubot2> Launchpad bug 964705 in network-manager "System policy prevents modification of network settings for all users" [Undecided,Confirmed] https://launchpad.net/bugs/964705
[19:55] <infinity> cjwatson: So, even post-release, that means the answer is to rebuild d-i any time some archive/initrd skew like this happens?
[19:56] <infinity> cjwatson: That just feels inelegant. :/
[20:31] <cjwatson> infinity: Yes
[20:32] <cjwatson> infinity: Normally kernel ABI bumps get to it first anyway.  This is the first time I can recall it being a problem.
[20:35] <infinity> cjwatson: Fair enough.  Though, we've never had to worry about this ssl/crypto split before now, have we?  This is a fairly new addition.
[20:36] <infinity> cjwatson: Though, I guess we don't be doing these sorts of libssl upgrades post-release.  Security fixes in libssl tend to be pretty surgically precise and non-disruptive.
[20:37] <cjwatson> libssl/libcrypto have been split for years
[20:37] <cjwatson> in udebs anyway
[20:38] <cjwatson> Perhaps the addition is that somebody actually cares about libssl in udeb form now, rather than it being a niche thing
[20:38] <infinity> cjwatson: Well, yeah, but I get the impression Daviey's use-case is new?  Maybe not.
[20:38] <cjwatson> Newish, yeah
[20:38] <cjwatson> But indeed, I'd find this kind of thing pretty ... surprising post-release
=== RAOF_ is now known as RAOF