[03:56]  * ScottK always thought it was clear that anything that hit New needed an FFe and is said to see the rules lawyers have taken over.
[13:25] <fginther> Greetings! May I ask someone to review some precise uploads (evemu, frame, grail and geis) or at least provide an estimate of when this might occur? Thanks.
[13:51] <cyphermox> ScottK: micahg: what I wrote before was precisely because I knew it was missing an FFE, sorry if that wasn't clear.
[13:53] <cyphermox> just filed for this: https://bugs.launchpad.net/ubuntu/+source/indicator-sync/+bug/1043343
[13:53] <ubot2`> Ubuntu bug 1043343 in indicator-sync "FFE: indicator-sync 12.10.1 -- fix namespacing errors in Gir and module naming consistency" [Undecided,New]
[13:54] <cyphermox> I'm going to need to do another upload because it failed to build on arm* and powerpc anyway
[14:03] <psivaa> There are some inconsistencies in the folder structure for quantal d-i images for amd64
[14:04] <psivaa> bsdtar reports boot
[14:04] <psivaa> boot/grub
[14:04] <psivaa> instead of ./boot
[14:04] <psivaa> ./boot/grub
[14:07] <tumbleweed> what's the difference?
[14:08] <psivaa> hmm may be not
[16:08] <rtg> I am planning to upload a new kernel with a fix for uvcvideo that has caused a number of lockups during live CD installations. Any objections? (no ABI bump required)
[16:08] <stgraber> bugfix only, no ABI bump, sounds good to me
[16:23] <rtg> stgraber, 2 bug fixes: bug #1042903 and bug #1042809
[16:23] <ubot2`> Launchpad bug 1042903 in linux "mgag200 driver hangs on HP ProLiant Gen 8 platform" [Medium,Confirmed] https://launchpad.net/bugs/1042903
[16:23] <ubot2`> Launchpad bug 1042809 in linux "HP Webcam-101 (uvcvideo) locking machine" [High,Confirmed] https://launchpad.net/bugs/1042809
[16:42] <stgraber> rtg: right, so assuming you're not planning another upload for beta1, I think this should be uploaded now so it's all built by the time we freeze tomorrow
[16:43] <rtg> stgraber, mere seconds ago...
[16:49] <tedg> So I've got a couple FFe's that I'm tracking and I'd like to figure out their status.  bug 1042757  and bug 1040221
[16:49] <ubot2`> Launchpad bug 1042757 in unity-greeter "FFe request: Unity greeter network indicator" [Undecided,New] https://launchpad.net/bugs/1042757
[16:49] <ubot2`> Launchpad bug 1040221 in unity-greeter "FFe request: Provide remote login options" [Undecided,New] https://launchpad.net/bugs/1040221
[16:49] <tedg> The second is still waiting on MIR reviews from security, but they've said they would be doing them today.
[17:01] <tedg> slangasek, Laney, do you guys perhaps know?  ^
[17:06] <Laney> seems skaet is on it
[17:07] <seb128> Laney, where do you see that?
[17:08] <Laney>  Kate Stewart (kate.stewart) wrote 3 minutes ago: 	#1
[17:08] <Laney> When can the code land?
[17:08] <Laney> https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1042757/comments/1
[17:08] <ubot2`> Ubuntu bug 1042757 in unity-greeter "FFe request: Unity greeter network indicator" [Undecided,New]
[17:10] <seb128> Laney, oh, I didn't see the updates yet ;-)
[17:10] <Laney> :P
[17:14] <Daviey> Has someone reverted the squashfs usage in server iso?  It's in A3, but not in daily.
[17:15] <ogra_> Daviey, i definitely see it in my daily arm images
[17:15] <ogra_> must be that crappy x86 arch
[17:16] <slangasek> cronjob still shows 'buildlive ubuntu-server daily && for-project ubuntu-server cron.daily'
[17:17] <slangasek> it also shows a daily i386 iso being built.  have those not been turned off?
[17:19] <Daviey> they should not have been turned off
[17:19] <slangasek> Daviey: but we're not releasing them, so why build them?
[17:19] <slangasek> or are you still gathering info about whether to release them?
[17:21] <Daviey> dave@frap:~$ curl http://cdimage.ubuntu.com/ubuntu-server/daily/current/quantal-server-amd64.list  2>/dev/null | grep filesystem.squashfs
[17:21] <Daviey> dave@frap:~$ curl http://cdimage.ubuntu.com/releases/quantal/alpha-3/quantal-server-amd64.list 2>/dev/null | grep filesystem.squashfs
[17:21] <Daviey> /casper/filesystem.squashfs
[17:21] <Daviey> slangasek: gather info.. the deal is to be promoting amd64.. but we should still be building i386..
[17:22] <Daviey> If i wanted i386 to stop being built, i'd have done it :)
[17:22] <Daviey> ogra_ / slangasek: So somthing has changed between alpha 3 and now.
[17:22] <slangasek> Daviey: well, the message I saw earlier this cycle was that you were proposing to not ship i386 server at all
[17:23] <ogra_> we got a new live-build very recently
[17:23] <slangasek> ogra_: which should not impact whether the squashfs is included in the CD
[17:23] <ogra_> did you chekck the contents of your squashfs ?
[17:23] <slangasek> the squashfs /isn't included on the CD/, live-build can't have caused that
[17:23] <Daviey> slangasek: that was the message.. but everywhere i've said that, i also said that we would still be building it.. just not 'releasing it'
[17:23] <Daviey> which has been the status for all the Alpha's so far.
[17:24] <slangasek> Daviey: hmm, well.  I don't see the point in having it built if it's not going to be released
[17:25] <Daviey> slangasek: The not releasing it for milestones was an effort to gather "oh noes".  We will likely still be releasing it for final.. but a step whcih requires thought to retrieve
[17:25] <Daviey> (we know too many people are downloing i386 when they really want amd64, so this is to help them :)
[17:26] <slangasek> Daviey: ah
[17:26] <ogra_> ogra@anubis:~/Desktop/images$ mount-image-partition quantal-server-armhf+omap4.img 2 /mnt/
[17:26] <ogra_> ogra@anubis:~/Desktop/images$ find /mnt -name *.squashfs
[17:26] <ogra_> /mnt/install/filesystem.squashfs
[17:26] <ogra_> thats todays armhf build
[17:27] <Daviey> i'm going to blame ogra_ :)
[17:28] <ogra_> heh, wasnt me :)
[17:28] <ogra_> sadly the .list files are generated for the first partition the script finds it seems
[17:28] <ogra_> so my .list looks quite different from x86
[17:30] <ogra_> even more intresting is that you had a /casper in your server images ... live-installer uses /install afaik
[17:30] <slangasek> Daviey: when was the last known-good build?
[17:30] <slangasek> nothing more recent than a3?
[17:30] <slangasek> the last commit that seems to change squashfs handling in the debian-cd branch is cjwatson's 1802 from 2012-07-31
[17:32] <Daviey> yeah
[17:32] <Daviey> slangasek: Well, we don't have legacy images atm :(
[17:32] <Daviey> i'm wondering if the jenkins install log exposes this.. but i doubt it
[17:32] <slangasek> "legacy images"?
[17:34] <slangasek> Daviey: how did you determine that the squashfs wasn't there?  only by looking at the .list?
[17:35] <slangasek> seems to be a bug in the .list generation
[17:35] <slangasek> because when I download the image, it's there
[17:35] <Daviey> slangasek: yes, i looked at the .list
[17:35] <Daviey> wait, you see it in the daily?
[17:35] <slangasek> yes
[17:35] <ogra_> slangasek, you would have huge amounts of bugs from testers and complaining people on IRC if it wasnt there
[17:35] <slangasek> the .list generation is buggy in some way I haven't bothered to track down
[17:35] <Daviey> i'm looking at it right now.. not in /casper/filesystem.casper?
[17:35] <ogra_> (installs would all fail)
[17:35] <slangasek> ogra_: no, you wouldn't
[17:35] <slangasek> Daviey: /install/filesystem.squashfs
[17:36] <Daviey> ogra_: it falls back gracefully
[17:36] <Daviey> GRR
[17:36] <Daviey> slangasek: it was moved from /casper/ .. I didn't know. Sorry.
[17:36] <Daviey> Why was it moved?
[17:36] <slangasek> so in fact, this is due to cjwatson's change moving the file on you ;)
[17:36] <ogra_> oh, we still have the packages for a debootstrap on the images ?
[17:36] <slangasek> maybe because casper/ is a misnomer?
[17:36] <Daviey> Curse that man! ;)
[17:37] <slangasek> ogra_: no, we don't, but debian-cd includes the packages *only* if it doesn't find them in the squashfs
[17:37] <ogra_> oh, ok, a build time fallback
[17:37]  * ogra_ thought install time
[17:37] <Daviey> (and runtime)
[17:37] <slangasek> (rather, in the manifest, since it can't actually introspect the squashfs)
[17:37] <slangasek> Daviey: well, a runtime fallback wouldn't do much good if the packages weren't actually available on the image... but the image build ensures that they are if necessary
[17:38] <Daviey> ogra_: Unless i am mistaken, di looks in a given location for the squashfs.. if it doesn't exist.. (or location preseeded (inc. http)), it will use the mirror, either local pool or a.u.c for debs
[17:39] <ogra_> Daviey, ah, network would be possible, yeah, though live-installer would still bark at you i guess
[17:39] <Daviey> ogra_: I don't think it does bark.. just fallback.
[17:39] <ogra_> k
[17:40] <Daviey> ogra_: netinstall therefore defaults to using debs, but can be preseeded (or have the squashfs already in the right place) to use live-install.
[17:40] <Daviey> I might be mistaken.. that was my understanding, and assumption i've been working on.
[17:41] <ogra_> your assumption might be right :)
[21:52] <sbeattie> SpamapS: can you use your SRU admin powers to release icedtea-web in natty-proposed and oneiric-proposed to their respective security pockets (they fix a regression introduced by a security update).
[21:52] <sbeattie> also, releasing icedtea-web for precise-updates would be appreciated, too.
[22:02] <slangasek> what are those rejects about?
[22:03] <infinity> Working with cnd on it all right now.
[22:03] <slangasek> ok
[22:22] <Daviey> sbeattie: Spamaps is at a conf'.. might have better luck with another member of the team.
[22:25] <slangasek> infinity: bug #1043517 is an interesting dupe; desktop install with no ubuntu-desktop package installed
[22:25] <ubot2`> Launchpad bug 1043517 in resolvconf "package resolvconf 1.63ubuntu15 failed to install/upgrade: ErrorMessage: pre-dependency problem - not installing resolvconf (dup-of: 1017001)" [Undecided,New] https://launchpad.net/bugs/1043517
[22:25] <ubot2`> Launchpad bug 1017001 in apt "package resolvconf 1.63ubuntu14 failed to install/upgrade: ErrorMessage: pre-dependency problem - not installing resolvconf" [Critical,Confirmed] https://launchpad.net/bugs/1017001
[22:25] <slangasek> sbeattie, Daviey: looking
[22:27] <slangasek> sbeattie: the same package version is also in {natty,oneiric}-updates; does it need copied there too?
[22:28] <sbeattie> slangasek: yes, the versions in {natty,oneiric}-proposed should also be copied to -updates
[22:28] <slangasek> ok
[22:28] <slangasek> reading the bug now
[22:29] <sbeattie> (I wasn't sure if that would happen automagically or not)
[22:29] <slangasek> the natty package hasn't built on armel
[22:29] <sbeattie> yeah, it won't because openjdk-6 FTBFS on armel.
[22:30] <slangasek> ok.  is this a regression vs. the previous version in natty-updates?
[22:30] <slangasek> seems not
[22:30] <sbeattie> no, it's not.
[22:31] <slangasek> sbeattie: ok, done
[22:31] <slangasek> (well, once I accept from this silly unapproved queue)
[22:32] <sbeattie> slangasek: thanks! :)
[22:34] <infinity> slangasek: Are you using an old sru-release?
[22:35] <slangasek> maybe?
[22:35]  * slangasek checks
[22:35] <slangasek> I didn't think I was
[22:35] <infinity> slangasek: "sru-release -s natty icedtea-web" would have just autmagically copied-with-accept to updates and security.
[22:35] <slangasek> oh
[22:35] <infinity> slangasek: Shouldn't hit unapproved.
[22:35] <slangasek> right, so no I'm not because I didn't use 'sru-release' at all but copy-package :P
[22:35] <infinity> Ahh.
[22:35] <slangasek> which was bad of me
[22:36] <infinity> Meh, gets the job done.
[22:36] <slangasek> doesn't append the bug comments though
[22:36] <infinity> Nope, that it doesn't.
[22:36] <infinity> Of course, while I'm praising the joys of sru-release, I just got an OOPS mailed to me from my latest copy.
[22:36] <infinity> Grr.
[22:54] <knome> there's an awkward bug with xfwm4 in quantal. it appeared maybe a week ago, and the problem is that 1px wide window borders are not drawn/drawn incorrectly with nvidia proprietary drivers. we're quite sure this relates to a recent xorg update. anybody has any ideas what might have causing that?
[22:56] <knome> it also happens on vbox installations, so it's probably not (only) linked to nvidia drivers
[22:58] <infinity> knome: Filing a bug on xorg-server might be a good start, then.
[22:59] <knome> infinity, obviously, i've gathered that much myself. thanks anyway.