[00:10] <infinity> Right, then.  Out for the evening, will try to swing by to spin some images in ~6-7h, but if someone else notices the kernels are done and beats me to it, I won't complain.
[01:44]  * skaet checks and sees armel/armhf/powerpc still building linux,  sigh.
[01:48]  * phillw hides as skaet mentioned ppc and armhf which include lubuntu :/
[06:25]  * skaet sees that linux has published on all architectures
[06:25] <skaet> who just accepted glib2.0 to proposed?
[06:26]  * skaet starting off image builds
[06:32] <skaet> infinity, cjwatson - I've started off the image builds now for all the images on nusakan.    Should be emerging on the iso tracker as Beta 2.
[06:32]  * skaet --> back to zzz
[06:33] <infinity> skaet: glib2.0 in proposed is replacing one that was FTBFS on arm*.
[06:33]  * infinity also decides to nap for a bit.
[08:41] <ogra_> that flash-kernel upload above fixes a critical bug for arm images, please someone let it in
[08:41] <ogra_> bug 1055938
[08:41] <ubot2> Launchpad bug 1055938 in flash-kernel "uboot and mlo not in boot partition after install" [High,Confirmed] https://launchpad.net/bugs/1055938
[08:53] <Laney> ogra_: can you put it on the pad as respin trigger?
[08:53] <ogra_> oh, yeah, sorry, forgot about it
[08:56] <ogra_> added to the issues
[08:57] <Laney> if you want respins then respin trigger is the place for it
[08:57] <Laney> rebuild trigger
[08:57] <ogra_> stgraber, lubuntu is the image for ac100 and it will stay like that
[08:57] <ogra_> stgraber, so please keep it :)
[08:59] <ogra_> done
[08:59] <Laney> and mark the affected images?
[09:00] <ogra_> hmm, which kubuntu arm images are there ?
[09:02] <babyface_> are today's server isos under building?  it shoud be ready at UDT 7:00.
[09:03] <Laney> yes
[09:03] <Laney> they aren't on cron, so disregard any timing expectations you have
[09:03] <Laney> usual milestone thing
[09:04] <babyface_> Laney, ok. thanks.
[09:04] <Laney> but I see them in progress
[09:04] <babyface_> Laney, yes, I saw that, too. but it costs too much than usual
[09:05] <babyface_> [2012-09-25 06:46:33] lb_testroot
[09:05] <babyface_> P: Begin unmounting /dev/pts...
[09:05] <babyface_> P: Begin unmounting filesystems...
[09:05] <babyface_> P: Saving caches...
[09:05] <babyface_> Reading package lists...
[09:05] <babyface_> Building dependency tree...
[09:05] <cjwatson> *costs* too much?
[09:06] <babyface_> cjwatson, yes, normally they should be ready at UTC 7:00
[09:06] <ogra_> $3.23/byte ?
[09:06] <cjwatson> if you mean takes too long - around milestones we're building lots of things together, so you can expect some queueing
[09:06] <cjwatson> babyface_: as Laney said, they are not being built from cron today, but manually, so forget your timing expectations
[09:06] <babyface_> cjwatson, ah, ok. thanks
[09:07] <cjwatson> and there we go.  patience is a virtue. :)
[09:07] <ogra_> hah
[09:07] <babyface_> cjwatson, thanks.
[09:08]  * Laney 's ISP has decided that alioth isn't a service he needs access to today
[10:28] <cjwatson> xnox: oh, we were talking about partman-crypto/confirm_nochanges the other day in response to plars' report, but that's *not* what he reports in bug 1055819
[10:28] <ubot2> Launchpad bug 1055819 in ubiquity "'Partition in use' error when creating encrypted volumes" [Medium,Confirmed] https://launchpad.net/bugs/1055819
[10:29] <cjwatson> and that sounds more like what I originally understood him to mean
[10:30] <cjwatson> xnox: that indicates an attempt to modify the partition while locked (partman-base/partlocked with partman-crypto/text/in_use substituted in) and indicates a logic error somewhere, not just a warning that should be silenced
[10:31] <cjwatson> xnox: perhaps we're trying to traverse into locked partitions while building the cache or something?
[10:31] <xnox> partman-base/partlocked
[10:31] <xnox> hmm....
[10:31] <xnox> i have logs open currently let me see.
[10:34] <xnox> cjwatson: yes, we do hit that upon rebuilding the cache. And I do store the 'partlocked' flag in the cache when it does, to later correctly set all action buttons insensitive on that partition. But I still fall through to showing the error dialog.
[10:35] <cjwatson> It should be possible to check for lockedness without having to hit the error
[10:36] <cjwatson> Look for the presence of a 'locked' file in the relevant partition directory under /var/lib/partman
[10:36] <cjwatson> Likewise for disks
[10:36] <cjwatson> I think in this case it's better to have a look-before-you-leap pattern, so that we don't accidentally silence *un*expected errors
[10:37] <cjwatson> Plus, it'll be quicker
[10:37] <xnox> Ok. "Likewise for disks" - is there an easy way to get a locked disk? installation medium?
[10:37] <cjwatson> (Traversing takes noticeable time, anything you can do to minimise it will make the partitioner snappier - compare https://wiki.ubuntu.com/Ubiquity/PartitionerOptimisation)
[10:38] <cjwatson> disks> presence of a 'locked' file under the device directory in /var/lib/partman
[10:38] <cjwatson> installation medium is handled separately IIRC
[10:38] <xnox> ok.
[10:46] <xnox> cjwatson: what's the best way to detect that "partition" is in fact the acting_filesystem within encrypted volume. (i) Filter on the name '*crypt' (ii) transverse to disk -> crypt_realdev -> locked status (iii) something else?
[10:46] <xnox> to mark "remove partition" button insensitive, as it's not possible to remove it.
[10:47] <xnox> (well partman doesn't support removing it from that menu)
[10:47] <cjwatson> I'd be inclined to suggest looking up the logic that partman-crypto itself uses and mimicking it.
[10:47] <xnox> ok. i will check that.
[10:47] <cjwatson> You could fish out the crypt_realdev file without actually having to traverse to that partition in debconf.
[10:47] <xnox> true.
[10:47] <cjwatson> So something like that's probably the best way.
[10:48] <xnox> well, as I'd add crypt_realdev to the diskcache, it will be simply dict lookups.
[10:48] <cjwatson> Quite.
[10:56] <cjwatson> ^- would be good if somebody could process that, as there are scattered reports of failures on precise systems with the new dual-signed index files
[11:01] <xnox> ha. partman-partitioning disables resize & delete if the device labe is == 'loop' nice and generic
[11:16] <Riddell> settings bug 1055967 to critical, ubiquity can't start :(
[11:16] <ubot2> Launchpad bug 1055967 in ubiquity "ubiquity kde frontend is broken in current kubuntu daily builds" [Critical,Confirmed] https://launchpad.net/bugs/1055967
[11:18] <cjwatson> are you able to work on a fix?
[11:19] <Riddell> I don't think I know where to start, I'm just poking about randomly
[11:24] <Riddell> mdeslaur_: presumably you'd object to reverting that dbus change?
[11:41] <mdeslaur_> Riddell: uhm, yes. Either start the bus yourself, or don't make whatever is trying to start it setuid
[11:43] <cjwatson> ubiquity has to go to some contortions for this kind of thing because it's not fully frontend/backend-separated, but mostly I don't care because it's the installer damnit
[11:45] <cjwatson> But we do call os.setgid and os.setuid when calling dbus-launch, if I'm looking in the right place (which isn't clear)
[11:45] <cjwatson> Does dbus object to the presence of a saved-user-ID?
[11:46] <mdeslaur> cjwatson: yes, it does:
[11:46] <mdeslaur> ++      is_setuid = (ruid != euid || ruid != suid ||
[11:46] <mdeslaur> ++                   rgid != egid || rgid != sgid);
[11:46] <cjwatson> Apparently so, yeah
[11:47] <Riddell> the CVE says "NOTE: libdbus maintainers state that this is a vulnerability in the applications that do not cleanse environment variables, not in libdbus itself"
[11:48] <cjwatson> Riddell: entirely untested, but maybe try http://paste.ubuntu.com/1226425/
[11:48] <cjwatson> popey: so this precise unity SRU consists of nux + unity + unity-2d, right?
[11:48] <mdeslaur> Riddell: they said that, and then decided that the best fix would be in libdbus itself
[11:49] <mdeslaur> Riddell: this is an upstream patch, if you don't fix it now, you'll have to fix it soon when the new dbus hits
[11:58] <Riddell> cjwatson: making a USB disk with persistent storage so I can test that
[11:59] <mdeslaur> cjwatson, Riddell: sorry for the inconvenience, I wasn't expecting this to be problematic
[12:02] <cjwatson> I would prefer to fix this without reverting, of course, but we also do have a release to get out - on Thursday, not whenever the next upstream release of dbus hits
[12:04] <Laney> heh
[12:04] <Laney> I was just wondering where those were
[12:09] <popey> cjwatson, yes, hang fire, needs some additional testing on ARM, should I revert back to verification-needed?
[12:11] <cjwatson> popey: Yes
[12:11] <popey> cjwatson, all of them?
[12:11] <cjwatson> No need for that
[12:11] <popey> ok, ta
[13:14] <Riddell> cjwatson: hmm that just leaves me with a black screen (X running but nothing on top of it)
[13:32] <cjwatson> Riddell: /var/log/installer/dm might help?
[13:33] <Riddell> cjwatson: nothing much in that, just initializing extensions and finishes with Loading extension GLX
[13:43] <skaet> Riddell,  can you give me more background on what you're seeing/which image, etc.    I'm seeing Ubuntu and Lubuntu on the ISO tracker have results so not sure if its a pervasive issues or not.
[13:43] <skaet> ?
[13:44] <Riddell> skaet: it only affects the kde frontend of ubiquity
[13:44] <skaet> Thanks Riddell.
[13:49] <cjwatson> Which is actually kind of curious since I thought we ran dbus-launch for all frontends.
[13:49] <cjwatson> Maybe it matters less elsewhere.
[13:56] <Riddell> the same problem occurs when running ubiquity from a the full live session
[14:22] <Laney> can we have gtk+2.0 copied to release?
[14:22] <Laney> I'd like to accept the one in proposed
[14:25] <skaet> Laney,   scope of impact?
[14:25] <Laney> well, the fix is for something in the printer dialog
[14:25] <Laney> opportunity target if you want to think of it like that
[14:25] <Laney> the one I'd accept is to fix overlay scrollbars for Qt applications
[14:28] <skaet> bug #?
[14:30] <Laney> https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1053891 fixed with the copy to release
[14:30] <ubot2> Launchpad bug 1053891 in gtk+2.0 "GTK print dialog does not allow printing and does not show options of a remote DNS-SD/Bonjour printer" [High,Fix committed]
[14:30] <Laney> https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1005677 fixed with the accepts
[14:30] <ubot2> Launchpad bug 1005677 in ayatana-scrollbar "Re-emergence of "Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WIDGET (widget)'" Makes vlc and other Qt apps crashing crashing" [High,In progress]
[14:31] <Laney> I'll reupload overlay-scrollbar with -v to close the bug
[14:38] <skaet> Laney,  ack,  have added them both to the pad then.
[14:39] <Laney> I never know if I'm allowed to do copies myself
[14:44] <xnox> I have a couple of ubiquity bugfixes for advanced-crypto. From my point of view they are opportunity targets if all desktop cds with gtk ubiquity are respun.
[14:44] <xnox> bug 1055819
[14:44] <ubot2> Launchpad bug 1055819 in ubiquity "Ubiquity should avoid partlocked error when rebuilding disk cache" [High,Fix committed] https://launchpad.net/bugs/1055819
[14:44] <xnox> bug 1055815
[14:44] <ubot2> Launchpad bug 1055815 in ubiquity "No mountpoint option when manually partitioning with encrypted volumes" [Medium,Fix committed] https://launchpad.net/bugs/1055815
[14:45] <xnox> bug 1055640
[14:45] <ubot2> Launchpad bug 1055640 in ubiquity "ubi-partman error 141 when removing encrypted partition" [High,Fix committed] https://launchpad.net/bugs/1055640
[14:45] <xnox> none of these are marked as critical. all of them are in lp:ubiquity.
[14:45] <xnox> Add to the pad? Which section?
[14:46] <Laney> upload, add to opportunity targets and then mark the affected images with your numbe
[14:46] <Laney> r
[14:46] <xnox> Laney: what about the Kubuntu's live session / ubiquity-dm not starting at all?
[14:47] <Laney> what about it?
[14:47] <Laney> is there a fix?
[14:47] <xnox> wait for that as well, or upload as is, and reupload if that one gets added.
[14:47] <xnox> no, not yet.
[14:47] <Laney> is there likely to be one quite soon?
[14:47]  * xnox is not working on it. Riddell, any news / progress?
[14:48] <skaet> xnox,  what Laney said.  :)
[14:48] <Riddelll> I'm poking at various things but I doubt I have any real ideas how to progress it
[14:48] <Laney> it's not like ubiquity takes hours and hours to build
[14:48] <Laney> might as well upload and then upload again if necessary IMHO
[14:49] <skaet> have all the necessary bits for arm landed?   We need to respin those to get the images and testing infrastructure usuable for them.
[14:50] <Laney> was just flash-kernel AFAIK, so yes
[14:51] <skaet> there was also the glib2.0 that adam uploaded last night to fix FTBFS
[14:52]  * skaet nudges infinity to remember to update the pad, when he lands things. :P
[14:53] <Laney> I don't see evidence of that
[14:54] <cjwatson> he didn't upload anything.  he accepted an upload to quantal-proposed.
[14:55] <cjwatson> which is still building anyway.
[14:55] <Laney> yeah
[14:55] <skaet> Laney,  http://irclogs.ubuntu.com/2012/09/25/%23ubuntu-release.html#t06:33
[14:55] <cjwatson> yep, which says he accepted it, not uploaded
[14:56] <cjwatson> anyway, it only needs to be on the pad if it's intended to land in quantal pre-b2
[14:56] <skaet> yeah,  corrected.
[14:57] <cjwatson> which amounts to a question of whether it's problematic for ARM not to have the changes in https://launchpad.net/ubuntu/+source/glib2.0/2.33.14-1; it hasn't resulted in uninstallability
[14:58] <skaet> yep,  jsut looking at it,  and looks like the fixes in it were from pitti to clean up some testing infrastructure,  so not critical I think.
[14:58] <cyphermox> infinity: evo is now in the queue for the buil-dep change re: gtkhtml
[14:59] <cjwatson> skaet: those are the post-2.33.14-1 changes
[14:59] <Laney> they're all trying to resolve the FTBFS
[14:59] <cjwatson> 2.33.14-1 was a new upstream
[14:59] <Laney> which started with -1
[15:00] <cjwatson> https://launchpad.net/ubuntu/+source/glib2.0/+changelog - ARM is currently on 2.33.12-3
[15:01]  * skaet nods
[15:02] <Laney> cjwatson: so can I copy gtk+2.0?
[15:02] <Laney> In general can people copy stuff if it's all built and such?
[15:02] <skaet> well,  its looking close to finishing at this point.   And it looks like the other architectures are on -14,  so wait for it to finish,  then copy?
[15:02] <cjwatson> I would rather people didn't just copy at the moment
[15:02] <skaet> since its still building?
[15:03] <cjwatson> err, gtk+2.0 is built
[15:03] <cjwatson> different packages
[15:03] <cjwatson> but since we have another things we need to change on ARM anyway, seems sensible to take this one
[15:04] <skaet> yeah,  cross wires on package names
[15:04] <Laney> it's mainly because I want the fix in queue
[15:04] <cjwatson> Laney: so go ahead, 'sru-release -r quantal gtk+2.0'
[15:04] <Laney> ty
[15:04] <Laney> do I need to wait for publisher or anything before accepting the new one?
[15:04] <xnox> anything else for ubiquity? it picked up flash-kernel & grub-installer.
[15:05] <cjwatson> Laney: new what wheree?
[15:05] <cjwatson> *where
[15:05] <Laney> new gtk+2.0 in queue
[15:06] <cjwatson> no need to wait for the publisher
[15:07] <cjwatson> xnox: not afaik - as said, if we find a fix for the KDE frontend we can reupload
[15:08] <xnox> ok
[15:21] <tumbleweed> why on earth is pbuilder-scripts aimed at the proposed pocket? (and do we really need more pbuilder wrappers?)
[15:23] <Laney> I wonder if it still has those conflicts :(
[15:24]  * Daviey questions the validity of doing uploads that simply add a Homepage to debian/changelog
[15:24] <Daviey> err, control
[15:24] <tumbleweed> Daviey: the point of those uploads is to give the uploaders a sense of achievement and show them how things work
[15:24] <tumbleweed> of course they are pointless, otherwise
[15:25] <Daviey> tumbleweed: How many of them until that task is complete ?
[15:26] <tumbleweed> Daviey: it's endless :) (although I wish they'd do something vaguely more useful than missing home pages - spelling mistakes are more valuable)
[15:26]  * xnox likes that suddenly spelling mistakes are welcome =)
[15:27] <micahg> actually, Homepage uploads can be useful if there's no watch file
[15:27] <micahg> as well as helping to upstream bugs and look for patches
[15:27] <Laney> I'd rather a watch file upload
[15:27] <xnox> watch file would be more useful though...
[15:27] <Laney> or both
[15:27] <xnox> with all spelling corrections....
[15:27] <micahg> they're not mutually exclusive, maybe add a note to the bug fixing initiative to check for watch file as well as homepage
[15:29] <tumbleweed> unfortunately, writing a watch file isn't as easy
[15:30] <Daviey> tumbleweed: I disagree.. nearly all watch files are easy.. They only really become complicated if you need to repack IMO.
[15:30] <jbicha> Home page does show up in Software Center so it's kind of useful to users
[15:31] <tumbleweed> Daviey: you should tell me debian sponsorees that - it can take a lot of back and forth to get them to produce a working watch file
[15:33] <Daviey> tumbleweed: I helped someone this week write a dfsg repack one.. It needed a few back and forth's.. The issue was they they didn't know how to test it.
[15:34] <stgraber> skaet: who do I ping about the amazon and ubuntuonemusic launchers not being overideable through gsettings as I was promised they'd?
[15:35] <stgraber> something seems to override the overrides at session open time, adding those launchers even when the system wide setting specifically disables them
[15:38] <stgraber> the problem seems to be the session migration script being stupid and always adding them...
[15:38] <skaet> popey,  ^  who should stgraber talk to.       stgraber,  best open a bug to track this.
[15:38] <skaet> ?
[15:39] <stgraber> skaet: well, I have a fix for it but that's going to be a unity-webapps-common upload, not an edubuntu-specific package
[15:39] <stgraber> I'm not planning on waiting for the unity guys to fix their stuff this time around, I was told that the workaround we put in place would work, ...
[15:40] <skaet> stgraber, ack.
[15:40] <stgraber> skaet: popey isn't in this channel btw
[15:40]  * skaet just noticed
[15:41] <skaet> olli,   who should stgraber work with on this,  mterry?
[15:42] <olli> skaet, stgraber, reading
[15:45] <xnox> ubiquity added as opportunity trigger [16]
[15:46] <Laney> neat
[15:46] <stgraber> olli, didrocks: I'm going to upload http://paste.ubuntu.com/1226871/ in 30min unless someone comes up with something better.
[15:49] <didrocks> stgraber: you should contact the webapps team, it's them who are responsible of the migration script
[15:49] <didrocks> stgraber: didn't check as I didn't upload that package
[15:50] <stgraber> didrocks: ok. I just filed bug 1056274 about it. My fix certainly works even if it's not a generic fix for the issue, so unless I get a reply on the bug with a better one, I'll just push that and they can always improve it after beta2 is out
[15:50] <ubot2> Launchpad bug 1056274 in webapps-applications "Icons are getting added on Edubuntu systems even though we override the system wide key" [Undecided,New] https://launchpad.net/bugs/1056274
[15:50] <stgraber> skaet: ^
[15:54] <olli> stgraber, didrocks I asked alex-abreu to touch base with you
[15:55] <alex-abreu1> stgraber: do you have a branch w/ the migration patch?
[15:55] <stgraber> alex-abreu1: nope, but it's added to bug 1056274 and was briefly reviewed/discussed by mterry and kenvandine in #ubuntu-desktop
[15:55] <ubot2> Launchpad bug 1056274 in webapps-applications "Icons are getting added on Edubuntu systems even though we override the system wide key" [Undecided,New] https://launchpad.net/bugs/1056274
[15:59] <skaet> stgraber, ack.
[15:59] <alex-abreu1> stgraber: ok for now, I'll work on a better fix upstream
[15:59] <alex-abreu> stgraber: thank you
[16:05] <stgraber> skaet: fix uploaded, should hit the queue in a few minutes
[16:05] <skaet> stgraber,  ok.   I've updated the pad.   Respin Edubuntu as soon as it lands?
[16:05] <Laney> might want to wait for ubiquity too
[16:06] <skaet> infinity,  https://launchpadlibrarian.net/117296378/buildlog_ubuntu-quantal-armel.glib2.0_2.33.14-1ubuntu2_FAILEDTOBUILD.txt.gz
[16:06] <skaet> looks like armhf is ok though now.
[16:06] <stgraber> skaet: might as well wait for ubiquity
[16:06] <skaet> stgraber, Laney, xnox -  does it make sense to wait for ubiquity for the arm respins as well?
[16:07] <Laney> yeah, was doing
[16:08] <stgraber> Laney: can you look at webapps-applications?
[16:08] <xnox> skaet: yes.
[16:08] <Laney> waiting for it to get diffy
[16:09]  * Laney eyes the hplib diff
[16:09] <Laney> hplip
[16:09] <xnox> skaet: arm desktop images that is. Since ubiquity embeds flash-kernel with a bugfix.
[16:11] <skaet> xnox,  k
[16:12] <infinity> skaet: I wasn't the one that accepted glib.  Either way, didn't really need padding, I was watching it.
[16:13] <Laney> someone want to score ubiquity/armel to make sure it gets in next?
[16:13] <Laney> 2 builders ...
[16:14] <stgraber> Laney: doing
[16:14] <stgraber> done
[16:14] <skaet> infinity,  hadn't seen you in channel this morning,  so leaving reference.
[16:14] <Laney> ty
[16:14] <Laney> webapps accepted
[16:14] <Laney> possibly score that up too if you want it for respins
[16:15]  * skaet really wants that queue logging.....  :P
[16:15] <stgraber> will do
[16:16] <stgraber> Laney: well, no need actually, it's arch all so it's already building
[16:16] <Laney> oh, cool, didn't notice
[16:17] <plars> skaet, didrocks, and anyone else interested: orca seems to quit reading after the welcome screen on ubiquity now, I'll have a bug# for you in a moment
[16:17] <skaet> plars,  thanks.
[16:17] <didrocks> plars: thanks, can you please assign Luke to it?
[16:18] <plars> didrocks: will do
[16:18] <didrocks> thanks ;)
[16:20]  * cjwatson attempts to strace the kubuntu ubiquity-dm failure
[16:23] <Riddelll> one workaround for the kde ubiquity issue is to change from a KApplication to a QApplication and just avoid much of dbus usage
[16:23] <cjwatson> That's not a bad long-term solution, TBH; I've wanted to get rid of our reliance on pykde for ages
[16:24] <cjwatson> But it probably has some UI effects so I'd like to figure out the underlying bug anyway ...
[16:28] <cjwatson> http://people.canonical.com/~cjwatson/tmp/ubiquity-dm.trace.xz FWIW
[16:31] <cjwatson> ah, I see, failure possibly not where I thought it was
[16:32] <cjwatson> haha
[16:32] <cjwatson>         # KApplication won't initialise if real UID != effective UID.  On
[16:32] <cjwatson>         # the other hand, we can't talk to D-Bus unless the effective user
[16:32] <cjwatson>         # is the live CD user.  Oh dear.  The solution is to use saved IDs:
[16:32] <cjwatson>         # if we hide our rootliness in the saved IDs, then neither
[16:32] <cjwatson> Apparently I documented this last time I fought with this stack ...
[16:32] <cjwatson>         # KApplication nor D-Bus will spot it.
[16:32] <cjwatson> And now the assumptions have changed
[16:33] <cjwatson> So maybe QApplication is the right answer after all
[16:33] <Riddelll> it's mostly calls to icon loading and one dialogue that need changed I think
[16:33] <cjwatson> Riddelll: How big a change would that be to the UI and the code?  Do the other uses of kdeui (KMainWindow, KIcon, KMessageBox) need to change too?
[16:33] <Riddelll> yes they do
[16:33] <cjwatson> And KGuiItem
[16:34] <Riddelll> but it's not too hard I think
[16:34] <Riddelll> loading icons by path rather than name
[16:34] <Riddelll> replacing the KMessageBox probably needs a few lines of extra code
[16:36] <cjwatson> Riddelll: Any visible effect on UI?
[16:36] <cjwatson> The stuff from the KApplication header doesn't seem *desperately* necessary
[16:36] <Riddelll> here's my quick incomplete version http://starsky.19inch.net/~jr/tmp/kde_ui.py
[16:36] <cjwatson> accelerators, common menu entries, KConfig, session management, help invocation
[16:37] <Riddelll> yeah, we don't use most of that
[16:37] <Riddelll> I need to go out for an hour or two, can tidy up that code once I'm back
[16:37] <cjwatson> QtCore.KGuiItem and QtCore.KMessageBox presumably wrong :)
[16:37] <Riddelll> I said it was incomplete :)
[16:38] <cjwatson> OK - I think this is the right direction, just note you'll need to change ubi-usersetup too
[16:38] <cjwatson> the use of kdeui has long been a pain so if we can ditch it at the same time then great
[16:49] <skaet> ogra_, just to confirm,  you'll be testing ac100 on lubuntu again?
[17:01] <skaet> infinity,  can you score up the powerpc build,  so we can get ubiquity built and coherent across the architectures,  and kick off the arm rebuilds.
[17:02] <skaet> infinity,  never mind,  just saw it was done...
[17:02] <cjwatson> Yeah, it's already scored up sufficiently that more won't make a difference.
[17:02] <cjwatson> It's just waiting for active builds to complete.
[17:02]  * skaet nods
[17:11] <ogra_> skaet, as always, yes
[17:12] <skaet> phillw, ^  ;)
[17:12] <skaet> ogra_ ,  thanks.
[17:23] <plars> skaet: is there a reason why there are no netboot images posted on isotracker yet?
[17:24] <skaet> plars,  they need to be manually set,  and they appear to have been overlooked for setting up. :P   doing now.
[17:26] <plars> skaet: upgrade is not there either
[17:36] <skaet> plars,  should be sorted now.
[17:36] <skaet> (netboot, and upgrades)
[17:49]  * skaet sees ubiquity is now pending publication for powerpc...
[17:56] <skaet> infinity, are you around to kick off the arm rebuilds?
[17:57] <infinity> I'm around.
[17:57] <infinity> I need to catch up with backscroll to see who's rebuilding what and why.
[17:57] <Laney> it's for flash-kernel
[17:57] <Laney> AIUI, anyway
[17:58] <infinity> Ahh, indeed.
[17:58] <infinity> Ugly bug.
[17:59] <skaet> infinity,  pad should be up to date, but ...  edit if something missed
[18:02]  * infinity wonders about that "arm" pipeline on the pad.
[18:02] <infinity> That looks like it'll just rebuild all live images, period, not just ARM.
[18:02] <infinity> As does the "desktop" pipeline.
[18:02] <infinity> So, we get to build ARM images twice. :P
[18:06] <plars> xnox: so if I've previously done an lvm install, and now I want to do manual partitioning, what's the best way to go about that? I don't seem to have a good way to take care of the things LVM left behind from the partitioner
[18:06] <plars> xnox: or is this all related to https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1042647
[18:06] <Laney> I think skaet designed it as favours which do/do not include ARM
[18:06] <ubot2> Launchpad bug 1042647 in ubiquity "[FFe] [UIFe] Manual Partitioning LVM" [High,New]
[18:07] <cjwatson> I suspect the pad predates ARM being moved into daily-live for many flavours.
[18:07] <infinity> Laney: Yeah, what cjwatson said.
[18:07] <skaet> cjwatson,  arm part was accurate for beta 1
[18:07] <infinity> I think someone just faithfully turned daily-preinstalled into daily, and didn't think that this meant we now just have two of (almost) everything.
[18:08] <cjwatson> skaet: The ARM -> daily-live change predated that by some way, though.  I suspect we just never noticed the problem, or else somebody edited it on the fly.
[18:08] <skaet> cjwatson,  ok.   Excuted those sets last night when I did the full rebuild.
[18:08] <skaet> but if we can get it more efficient, +1.
[18:10] <ogra_> there is still one preinstalled lubuntu image thouh
[18:10] <ogra_> *though
[18:10] <infinity> ogra_: Yeah, I know.  I'll fix this all up before I (re-)spin anything.
[18:10] <ogra_> thx
[18:12]  * cjwatson rereads the pad in detail
[18:12] <cjwatson> infinity: actually, I think what's happening here is that the flavours that include arm are *only* built in the ARM section
[18:12] <cjwatson> so the ARM section is building images for x86 as well, in reality
[18:13] <infinity> Oh, yeah.  I just noticed the lack of "ubuntu" in the "main" section.
[18:13] <infinity> Still, totally not as advertised. :P
[18:13] <cjwatson> So it's confusing but not inefficient, as I read it
[18:17] <skaet> infinity,  only respins expected at this point though are the arm ones.
[18:17] <skaet> though
[18:17] <cjwatson> And Kubuntu, or else it can't ship
[18:18] <cjwatson> See earlier conversation with Riddelll re bug 1055967
[18:18] <ubot2> Launchpad bug 1055967 in ubiquity "ubiquity kde frontend is broken in current kubuntu daily builds" [Critical,Confirmed] https://launchpad.net/bugs/1055967
[18:18] <infinity> skaet: Sure, but the current layout of the pad means that respinning ARM respins all ubuntu desktop images, etc.
[18:18] <infinity> Not that this bugs me.  If we have a new ubiquity, I'd rather do all live images.
[18:20] <phillw> infinity: so, a respin of all of Desktop editions? It's no problem, just I'd like to inform the testers so they don't go testing something that is due for replacement :)
[18:21] <skaet> infinity,  it was just individual invocations.
[18:21] <infinity> phillw: There's no such thing as wasted testing.  If they find bugs and file them now, that's better than doing so in a day.
[18:21] <skaet> infinity,  not sure we want to do a full respin on the other architectures,  since testing started very late, and not sure its as critical there.
[18:22] <infinity> phillw: This culture of "waiting for the golden RC image" needs to die in a fire, otherwise people sit around twiddling their thumbs until 2 days before a final release.
[18:22] <phillw> infinity: with the excpetion of ppc, the lubuntu ones were behaving. It is more a case of keeping the testers in the loop :)
[18:22] <phillw> infinity: oh, you need not fear that! They love to go play, just keeping them informed is also nice :)
[18:23]  * cjwatson bisects memory sizes in KVM; oh what fun
[18:24] <phillw> cjwatson: does a respin with ubiquity bring in your changes for Lubuntu ppc-Desktop?
[18:24] <skaet> infinity,  pad has the images that need to be respun.  use individual lines and ARCHES=... to just get the necessary respins.
[18:25] <infinity> skaet: Yes, I know.  I was saying that "as written", it implies that would somehow just do ARM.  Either way, with new ubiquities, we really should be testing them.
[18:26] <cjwatson> phillw: I guess
[18:26] <skaet> infinity,  was accepted as opportunity target,  not as a respin trigger
[18:27] <phillw> great :)
[18:27] <cjwatson> Any current respin would pick up the yaboot-installer fix I merged; no idea whether it's already in
[18:27] <cjwatson> Check versions in the manifest file for that
[18:27] <cjwatson> (it's EOD for me now so I'm not going spelunking for it)
[18:28] <phillw> cjwatson: okies, again, thanks for the time you spend on this pesky flavour ;)
[18:28] <cjwatson> *shrug* wasn't anything Lubuntu-specific about it :)
[18:29] <phillw> cjwatson: I was refering to ppc :)
[18:29] <phillw> bug 1040544 was still there today.
[18:29] <ubot2> Launchpad bug 1040544 in ubiquity "Installer dialog does not come up on PPC" [Undecided,Confirmed] https://launchpad.net/bugs/1040544
[18:29] <cjwatson> powerpc is an architecture, not a flavour. :-)
[18:29] <cjwatson> Yeah, like I say, that bug is likely not an installer problem.  Can't help you with that.
[18:29] <phillw> i was close!
[18:30] <phillw> x-org bug?
[18:30] <cjwatson> See my mail.
[18:30] <cjwatson> From a day or two ago, whenever it was.  No point going over it again.
[18:30] <phillw> I'll go dig it out, I knew I had something to do today :/
[18:30] <phillw> ..
[18:49] <infinity> cjwatson / Riddelll : So, I don't see any interesting updates on this ubiquity/kubuntu bug.  Was that going to be dealt with $later?
[18:57] <Riddelll> cjwatson: I'll take a look in a minute
[18:58] <Riddelll> infinity rather
[18:59] <infinity> Danke.
[19:05] <doko> may I accept packages in no package set, which fix ftbfs issues?
[19:05] <infinity> doko: Better to check seeded-in-ubuntu(1) to make sure it doesn't appear to land on any images, but yes.
[19:06] <Laney> well, feature freeze still applies ...
[19:06] <infinity> Laney: FTBFS fixes aren't features. :P
[19:06] <Laney> If they /only/ fix the FTBFS, then indeed.
[19:06] <Laney> but that's not how the question was worded
[19:06] <infinity> That was the implication.  doko's smart enough to know if he's misrepresenting himself. :P
[19:07] <doko> infinity, I'll let python3.3 to you ...
[19:07] <Laney> I thought the implication was "can I break FF to fix FTBFS?"
[19:07] <Laney> :-)
[19:07] <infinity> Laney: No, the implication was "we're in a hard freeze and I want to accept FTBFS fixes in the queue"
[19:07] <doko> I'll do that later after the freeze =) but currently debian doesn't have many new upstream versions
[19:08] <infinity> doko: Do I want to know what's wrong with py3.3 that you're pawning off on me?
[19:09] <infinity> Oh, the sync in the queue.
[19:11] <skaet> infinity,  after some discussion with plars in another channel,  preference is to hold off of the respins for ubuquity for ubuntu other than the arm platform.   There are some other fixes they'd like to see included before retesting.   However if none of them land,   a respin later tonight/tomorrow morning of the i386/amd64/etc.  and retest then.
[19:12] <infinity> doko: That python3.3 Debian upload doesn't seem to imply that it contains the changes from the last Ubuntu upload...
[19:12] <doko> infinity, it does
[19:12] <infinity> skaet: Yeah, I was holding off until I heard back about kubuntu as well.
[19:12] <infinity> doko: Just your infamous lack of verbosity in changelogs at work here? :)
[19:13] <infinity> skaet: But for now, I might just spin some arm/ubuntu-desktop images for people to test Oli's fix.
[19:14] <infinity> s/some/one/, since we only build one...
[19:14] <skaet> thanks infinity,  yes please.
[19:15] <infinity> skaet: Building now, then.
[19:22] <NCommander> ogra_, ping who is responible for updating the ARM OMAP install instructions
[19:26] <phillw> NCommander: I *believe* it is elfy
[19:26] <phillw> NCommander: https://wiki.ubuntu.com/QATeam/QuantalTestcaseUpdates
[19:26] <phillw> although that may well be seperate to install instructions :)
[19:41] <Daviey> cjwatson: hey, i'd really like to make our squashfs available outside of the iso, vi cdimage..  Can we make this happen?
[19:56] <skaet> cjwatson,  after a bit of spelunking, not spotting the yaboot-installer merge you were referencing earlier.   Do you have a bug number handy?
[19:58] <infinity> skaet: https://launchpad.net/ubuntu/+source/yaboot-installer/1.1.22ubuntu2
[19:58] <infinity> skaet: Included in https://launchpad.net/ubuntu/+source/ubiquity/2.12.3
[20:05] <skaet> thanks
[20:15] <Riddelll> cjwatson, infinity: able to eye over the changes I just pushed to ubiquity?
[20:20] <Riddell> xnox: ^^
[20:40] <cjwatson> Daviey: sure, easy enough
[20:45] <cjwatson> Riddell: ubiquity/plugins/ubi-usersetup.py still uses PyKDE4.kdeui.KIconLoader
[20:46] <cjwatson> Riddell: Can we ditch the misc.drop_privileges_save() / misc.regain_privileges_save() pair around the QApplication constructor, or does QA still need that?
[20:46] <Riddell> cjwatson: sure you have the latest version?  I changed ubiquity/plugins/ubi-usersetup.py
[20:48] <Riddell> cjwatson: mm yes it does work without the privilages changes, fixing
[20:50] <cjwatson> Riddell: Yes, I'm sure I have the latest version - r5696
[20:50] <cjwatson> ubiquity/plugins/ubi-usersetup.py:463:        from PyKDE4.kdeui import KIconLoader
[20:51] <cjwatson> Ah, you just forgot to remove the import, I think?
[20:52] <Riddell> cjwatson: oh aye, fixing
[20:53] <cjwatson> tests/run-pyflakes would have told you if xnox hadn't partially broken it by removing all the print_function imports :)
[20:53] <cjwatson> I'm going to put those back - Python 2 or no Python 2, it's too useful to have a sufficiently functional pyflakes
[20:54] <cjwatson> Riddell: oh, if you rejected that, can you make it UNRELEASED again in bzr?  I'd like to make a few minor changes at the same time
[20:54] <Riddell> ok
[20:54] <cjwatson> (and delete the tag I guess)
[20:55] <Riddell> done
[20:58] <skaet> infinity,  what order will the respun arm images be emerging in?
[20:59] <skaet> plars is eagerly awaiting the arm server one.... ;-)
[20:59] <infinity> skaet: Uhm.  That one.  I only respun ubuntu-desktop/armhf+omap4.
[20:59] <infinity> skaet: I'll do server right now for him. :P
[21:00] <phillw> can someone quickly check to see if ubiquity has forgotten to ask people to ensure their (laptop) is plugged into the mains? I've just got this by email & am asking the OP to raise a bug.
[21:00] <infinity> skaet: (I figured desktop was enough to test the bugfix, since the world will more than likely get respun for a whole new ubiquity later, but server's on the way too now)
[21:02] <skaet> infinity, ack.
[21:07] <cjwatson> Riddell: nearly finished ...
[21:17] <cjwatson> Riddell: r5701 has everything I care about; be my guest for another upload
[21:24] <cjwatson> stgraber: FYI you can make changes to post-qa in the public cdimage branch in future.  I'm porting your changes across now
[21:31] <cjwatson> Daviey: done now for future builds, I think; and as a free bonus I put the .squashfs files in place for the current ubuntu-server/daily build
[21:31] <Daviey> cjwatson: hah, i did that a few days ago.. but was obv. lost.
[21:31] <Daviey> I love free bonuses!
[21:31] <Daviey> thanks.
[21:31] <cjwatson> did which, dropped them manually into place?
[21:33] <stgraber> cjwatson: ok, thanks
[21:34] <Daviey> cjwatson: I dropped it manually a few days ago.
[21:35] <cjwatson> yeah, that ain't gonna persist without help ;)
[21:35] <Daviey> in a .squashfs/ .. so it wasn't visible
[21:35] <Daviey> Well yeah.. i knew that :)
[21:36] <cjwatson> FWIW, it'd be nice if, whenever anyone feels the need to touch the published cdimage/releases trees by hand (beyond the known times when it's necessary such as the odd tweak when publishing milestones) they mention it here
[21:36] <cjwatson> I can imagine things getting out of hand fairly easily
[21:37] <Laney> what /is/ the public cdimage branch? the one lp:ubuntu-cdimage imports from?
[21:39] <plars> ogra_: ping?
[21:39] <cjwatson> Yeah, unfortunately the mirroring is broken right now
[21:39] <cjwatson> Which I plan to fix before 12.10
[21:39] <cjwatson> bzr+ssh://nusakan/srv/cdimage.ubuntu.com/bzr/cdimage/
[21:39] <cjwatson> for those with access
[21:39] <plars> ogra_: next round of armhf images are not going to work, I think we need something else in the flash-kernel fix
[21:40] <cjwatson> the cdimage branches are mid-reorg - it should all be a lot more rational by the time I'm done
[21:41] <Laney> Fair. Because I was wondering if I was really supposed to be trying to push to a branch on people.c.c
[21:41] <cjwatson> Nah, that basically dates from a previous era in LP branch management
[21:41] <cjwatson> Seeing as cdimage is older than Launchpad
[21:46] <hallyn> hi all - stgraber found that latest quantal was failing in kvm-spice.  I opened bug 1056381 to track it, and list there what I needed to fix it.
[21:46] <ubot2> Launchpad bug 1056381 in xserver-xorg-video-qxl "error on x startup" [High,Confirmed] https://launchpad.net/bugs/1056381
[21:46] <hallyn> summary: need spice and spice-protocol 0.12, and a bunc hof patches from xserver-xorg-video-qxl upstream
[21:47] <hallyn> i suppose maybe i should push those and everything depending on them into a ppa...
[21:47] <hallyn> biab
[21:51] <stgraber> the final set of changes required doesn't seem too scary especially as it's limited to spice which isn't that commonly used (or we'd have noticed it being broken earlier I'd think)
[21:57] <infinity> plars: The images I just spun still don't work?
[21:57] <plars> infinity: they flash-kernel fix is no good, I just tried it via the netboot image and it failed
[21:58] <infinity> plars: What's the failure mode?  Do you have logs?
[21:58] <plars> infinity: yeah, one sec
[21:59] <plars> infinity: http://paste.ubuntu.com/1227506/
[21:59] <plars> infinity: somewhere, the boot partition is getting removed, so setting the label rather than formatting it was not the right fix
[22:01] <infinity> plars: Uhm.  Wow.  That so shouldn't be happening at all, given that we just re-use that partition.  Or, did so in the past.
[22:01] <plars> infinity: that's the best explanation I have at the moment... looking at the mmc card, there is no partition on it it seems
[22:01]  * infinity fears he's going to have to delve into f-k this afternoon.
[22:02] <infinity> plars: Well, it will be "invisible" after the rename, which is sort of the point.
[22:02] <infinity> plars: Ish.
[22:02] <infinity> plars: I'll block off some time this afternoovening to look at it.
[22:03] <plars> infinity: but my guess is that was the command complaining that there was no /dev/mmcblk0p1
[22:03] <infinity> plars: Can you test the server image I spun and confirm that it fails the same(ish) way?
[22:03] <plars> infinity: yep, is it done?
[22:03] <infinity> queuebot claimed it was done a while ago.
[22:03] <infinity> About an hour ago or so.
[22:03] <infinity> 20120925.2
[22:04] <infinity> I'm going to run and get some lunch/dinner/whatver and then settle in for an evening of figuring this out.
[22:04] <hallyn> stgraber: should i slap an 'ffe' on that bug?
[22:04] <hallyn> well lemme see how mcuh i can cram into a ppa before i have to run
[22:05]  * hallyn wonders if he can figure out how to do a sync from debian to ppa
[22:06] <plars> infinity: that was desktop actually I think, but I can check it with that one too
[22:06] <infinity> plars: No, I did server after desktop.
[22:06] <stgraber> hallyn: by your description of it, xserver-xorg-video-qxl should be a bugfix only cherry-pick, so won't need a FFe. Not sure about spice and spice-protocol, if those are also just bugfixes, then no need for an FFe.
[22:06] <infinity> 14:23 -queuebot:#ubuntu-release- Builds: Ubuntu Desktop armhf+omap4 [Quantal Beta 2] has been updated (20120925.2)
[22:06] <infinity> 15:11 -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+omap4 [Quantal Beta 2] has been updated (20120925.2)
[22:07] <infinity> ^-- From /lastlog
[22:07] <cjwatson> hallyn: if syncpackage can't do it, copy-package in lp:ubuntu-archive-tools likely can.
[22:07] <cjwatson> It should be a swiss army knife for basically all the things LP itself allows doing with copies.
[22:07] <infinity> I suspect sync can't target PPAs, but copy certainly can.
[22:08] <hallyn> cjwatson: will try copy-package, thx
[22:09] <hallyn> oh, sync-package --nolp should do what i need
[22:09] <hggdh> infinity, plars: I am running the server install now
[22:09] <infinity> hggdh: Thanks.
[22:09] <plars> hggdh: awesome, go for it :)
[22:09] <infinity> hggdh: If it doesn't fail, cool to know, if it does, the more detailed you can get the logging, the shinier.
[22:09]  * plars needs to go afk for a bit anyway
[22:09] <hggdh> infinity: ack. Should take anothe 10 min
[22:10] <plars> infinity: I have a failed case sitting right in front of me if there's anything you can think of that would help
[22:10] <infinity> Right.  Ima go grab some Subway and pretend that's a healthy meal.
[22:10] <infinity> Jared wouldn't lie, right?
[22:10] <hggdh> nevah
[22:10] <cjwatson> hallyn: syncpackage --no-lp can be used for that kind of thing, yeah, but it's kind of crude.
[22:14]  * micahg would suggest backportpackage in place of syncpackage --no-lp if not copying to the archive proper
[22:15] <micahg> *planning on copying to the archive proper
[22:15] <plars> hggdh: https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1056482 has what I've captured of it so far
[22:15] <ubot2> Launchpad bug 1056482 in flash-kernel "/dev/mmcblk0p1 is not a block device when installing flash-kernel" [Undecided,New]
[22:15] <TheLordOfTime> so... anyone here mind answering a question about the retracer for me...?  regarding a quantal crash bug i saw in passing.
[22:15] <hggdh> plars: I will add to it
[22:15] <TheLordOfTime> or should i poke around elsewhere?  (nothing from -bugs thus far)
[22:21] <hallyn> cjwatson: heh, sorry.  my old copy of ubuntu-archive-tools doesn't have copy-package, i'll fetch a new one and look through it
[22:23] <hallyn> there it is
[22:23] <hallyn> --to-ppa-name.  nice :)
[22:23] <hallyn> all right.  next time.
[22:26] <hggdh> plars: flash-installer works on -server
[22:27]  * skaet --> afk for evening.
[22:30] <plars> hggdh: oh? interesting
[22:35] <hggdh> plars: just checked mmcblkp1, seems correct
[22:35] <cjwatson> Riddell: still up?
[22:36] <cjwatson> Riddell: I'm going to go ahead and reupload ubiquity
[22:38] <xnox> plars: infinity: well 2.12.4 ubiquity with the flash-kernel fix landed after the 20120925.2 build unless I am reading it wrong.
[22:39] <xnox> wait. 20120925.2 has ubiquity 2.12.4, never mind me.
[22:39] <xnox> cjwatson: I guess i'm down to port py3flakes....
[22:40] <cjwatson> once there is a pyflakes that doesn't throw errors on Python 3 print(file=...), you can drop print_function again :-)
[22:46]  * xnox is happy and off to cook some dumplings with meat. comfort food after seeing that commit notification =)
[22:46] <cjwatson> poor xnox ;-)
[22:49] <xnox> cjwatson: barry is joining on the py3flakes effort @ uds-r
[22:49] <barry> yeah, that one made me cry too :)
[22:55] <cjwatson> I'm not in a desperate rush; leaving print_function in mostly lets it do a fine job
[22:55] <cjwatson> somebody please review that ubiquity upload?  should fix kubuntu
[22:56] <RAOF> I'll trade SRU reviews if someone would like to give colord a push into precise-proposed. It'd be nice to verify that it does indeed fix the 5th most common 12.04 crash report.
[22:57]  * cjwatson -> bed; if you need to fix ubiquity further, upload a .6 :)
[22:58]  * xnox likes the black market of bird seeds for reviews&button pushing on various queues =)))))
[23:28] <infinity> plars: Oh, wait.  You said that was a netboot.  Was that writing the netboot image to an SD card, or booting via PXE?