=== stgraber_ is now known as stgraber [00:10] 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. === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [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 :/ === Mirv_ is now known as Mirv === fabo_ is now known as fabo [06:25] * skaet sees that linux has published on all architectures [06:25] who just accepted glib2.0 to proposed? [06:26] * skaet starting off image builds [06:32] 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] skaet: glib2.0 in proposed is replacing one that was FTBFS on arm*. [06:33] * infinity also decides to nap for a bit. === henrix_` is now known as henrix === blair_ is now known as blair === henrix is now known as henrix_ === henrix_ is now known as henrix [08:41] that flash-kernel upload above fixes a critical bug for arm images, please someone let it in [08:41] bug 1055938 [08:41] Launchpad bug 1055938 in flash-kernel "uboot and mlo not in boot partition after install" [High,Confirmed] https://launchpad.net/bugs/1055938 [08:53] ogra_: can you put it on the pad as respin trigger? [08:53] oh, yeah, sorry, forgot about it [08:56] added to the issues [08:57] if you want respins then respin trigger is the place for it [08:57] rebuild trigger [08:57] stgraber, lubuntu is the image for ac100 and it will stay like that [08:57] stgraber, so please keep it :) [08:59] done [08:59] and mark the affected images? [09:00] hmm, which kubuntu arm images are there ? [09:02] are today's server isos under building? it shoud be ready at UDT 7:00. [09:03] yes [09:03] they aren't on cron, so disregard any timing expectations you have [09:03] usual milestone thing [09:04] Laney, ok. thanks. [09:04] but I see them in progress [09:04] Laney, yes, I saw that, too. but it costs too much than usual [09:05] [2012-09-25 06:46:33] lb_testroot [09:05] P: Begin unmounting /dev/pts... [09:05] P: Begin unmounting filesystems... [09:05] P: Saving caches... [09:05] Reading package lists... [09:05] Building dependency tree... [09:05] *costs* too much? [09:06] cjwatson, yes, normally they should be ready at UTC 7:00 [09:06] $3.23/byte ? [09:06] if you mean takes too long - around milestones we're building lots of things together, so you can expect some queueing [09:06] babyface_: as Laney said, they are not being built from cron today, but manually, so forget your timing expectations [09:06] cjwatson, ah, ok. thanks [09:07] and there we go. patience is a virtue. :) [09:07] hah [09:07] cjwatson, thanks. [09:08] * Laney 's ISP has decided that alioth isn't a service he needs access to today === mmrazik is now known as mmrazik|lunch [10:28] 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] Launchpad bug 1055819 in ubiquity "'Partition in use' error when creating encrypted volumes" [Medium,Confirmed] https://launchpad.net/bugs/1055819 [10:29] and that sounds more like what I originally understood him to mean [10:30] 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] xnox: perhaps we're trying to traverse into locked partitions while building the cache or something? [10:31] partman-base/partlocked [10:31] hmm.... [10:31] i have logs open currently let me see. [10:34] 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] It should be possible to check for lockedness without having to hit the error [10:36] Look for the presence of a 'locked' file in the relevant partition directory under /var/lib/partman [10:36] Likewise for disks [10:36] 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] Plus, it'll be quicker [10:37] Ok. "Likewise for disks" - is there an easy way to get a locked disk? installation medium? [10:37] (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] disks> presence of a 'locked' file under the device directory in /var/lib/partman [10:38] installation medium is handled separately IIRC [10:38] ok. [10:46] 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] to mark "remove partition" button insensitive, as it's not possible to remove it. [10:47] (well partman doesn't support removing it from that menu) [10:47] I'd be inclined to suggest looking up the logic that partman-crypto itself uses and mimicking it. [10:47] ok. i will check that. [10:47] You could fish out the crypt_realdev file without actually having to traverse to that partition in debconf. [10:47] true. [10:47] So something like that's probably the best way. [10:48] well, as I'd add crypt_realdev to the diskcache, it will be simply dict lookups. [10:48] Quite. === doko_ is now known as doko [10:56] ^- 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] ha. partman-partitioning disables resize & delete if the device labe is == 'loop' nice and generic === mmrazik|lunch is now known as mmrazik [11:16] settings bug 1055967 to critical, ubiquity can't start :( [11:16] Launchpad bug 1055967 in ubiquity "ubiquity kde frontend is broken in current kubuntu daily builds" [Critical,Confirmed] https://launchpad.net/bugs/1055967 [11:18] are you able to work on a fix? [11:19] I don't think I know where to start, I'm just poking about randomly [11:24] mdeslaur_: presumably you'd object to reverting that dbus change? [11:41] Riddell: uhm, yes. Either start the bus yourself, or don't make whatever is trying to start it setuid [11:43] 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 === mdeslaur_ is now known as mdeslaur [11:45] 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] Does dbus object to the presence of a saved-user-ID? [11:46] cjwatson: yes, it does: [11:46] ++ is_setuid = (ruid != euid || ruid != suid || [11:46] ++ rgid != egid || rgid != sgid); [11:46] Apparently so, yeah [11:47] 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] Riddell: entirely untested, but maybe try http://paste.ubuntu.com/1226425/ [11:48] popey: so this precise unity SRU consists of nux + unity + unity-2d, right? [11:48] Riddell: they said that, and then decided that the best fix would be in libdbus itself [11:49] 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 === henrix_ is now known as henrix [11:58] cjwatson: making a USB disk with persistent storage so I can test that [11:59] cjwatson, Riddell: sorry for the inconvenience, I wasn't expecting this to be problematic [12:02] 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] heh [12:04] I was just wondering where those were [12:09] cjwatson, yes, hang fire, needs some additional testing on ARM, should I revert back to verification-needed? [12:11] popey: Yes [12:11] cjwatson, all of them? [12:11] No need for that [12:11] ok, ta [13:14] cjwatson: hmm that just leaves me with a black screen (X running but nothing on top of it) [13:32] Riddell: /var/log/installer/dm might help? [13:33] cjwatson: nothing much in that, just initializing extensions and finishes with Loading extension GLX [13:43] 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] ? [13:44] skaet: it only affects the kde frontend of ubiquity [13:44] Thanks Riddell. [13:49] Which is actually kind of curious since I thought we ran dbus-launch for all frontends. [13:49] Maybe it matters less elsewhere. [13:56] the same problem occurs when running ubiquity from a the full live session [14:22] can we have gtk+2.0 copied to release? [14:22] I'd like to accept the one in proposed [14:25] Laney, scope of impact? [14:25] well, the fix is for something in the printer dialog [14:25] opportunity target if you want to think of it like that [14:25] the one I'd accept is to fix overlay scrollbars for Qt applications [14:28] bug #? [14:30] https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1053891 fixed with the copy to release [14:30] 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] https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1005677 fixed with the accepts [14:30] 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] I'll reupload overlay-scrollbar with -v to close the bug [14:38] Laney, ack, have added them both to the pad then. [14:39] I never know if I'm allowed to do copies myself [14:44] 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] bug 1055819 [14:44] Launchpad bug 1055819 in ubiquity "Ubiquity should avoid partlocked error when rebuilding disk cache" [High,Fix committed] https://launchpad.net/bugs/1055819 [14:44] bug 1055815 [14:44] Launchpad bug 1055815 in ubiquity "No mountpoint option when manually partitioning with encrypted volumes" [Medium,Fix committed] https://launchpad.net/bugs/1055815 [14:45] bug 1055640 [14:45] Launchpad bug 1055640 in ubiquity "ubi-partman error 141 when removing encrypted partition" [High,Fix committed] https://launchpad.net/bugs/1055640 [14:45] none of these are marked as critical. all of them are in lp:ubiquity. [14:45] Add to the pad? Which section? [14:46] upload, add to opportunity targets and then mark the affected images with your numbe [14:46] r [14:46] Laney: what about the Kubuntu's live session / ubiquity-dm not starting at all? [14:47] what about it? [14:47] is there a fix? [14:47] wait for that as well, or upload as is, and reupload if that one gets added. [14:47] no, not yet. [14:47] is there likely to be one quite soon? [14:47] * xnox is not working on it. Riddell, any news / progress? [14:48] xnox, what Laney said. :) [14:48] I'm poking at various things but I doubt I have any real ideas how to progress it [14:48] it's not like ubiquity takes hours and hours to build [14:48] might as well upload and then upload again if necessary IMHO [14:49] 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] was just flash-kernel AFAIK, so yes [14:51] 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] I don't see evidence of that [14:54] he didn't upload anything. he accepted an upload to quantal-proposed. [14:55] which is still building anyway. [14:55] yeah [14:55] Laney, http://irclogs.ubuntu.com/2012/09/25/%23ubuntu-release.html#t06:33 [14:55] yep, which says he accepted it, not uploaded [14:56] anyway, it only needs to be on the pad if it's intended to land in quantal pre-b2 [14:56] yeah, corrected. [14:57] 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] 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] infinity: evo is now in the queue for the buil-dep change re: gtkhtml [14:59] skaet: those are the post-2.33.14-1 changes [14:59] they're all trying to resolve the FTBFS [14:59] 2.33.14-1 was a new upstream [14:59] which started with -1 [15:00] https://launchpad.net/ubuntu/+source/glib2.0/+changelog - ARM is currently on 2.33.12-3 [15:01] * skaet nods [15:02] cjwatson: so can I copy gtk+2.0? [15:02] In general can people copy stuff if it's all built and such? [15:02] 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] I would rather people didn't just copy at the moment [15:02] since its still building? [15:03] err, gtk+2.0 is built [15:03] different packages [15:03] but since we have another things we need to change on ARM anyway, seems sensible to take this one [15:04] yeah, cross wires on package names [15:04] it's mainly because I want the fix in queue [15:04] Laney: so go ahead, 'sru-release -r quantal gtk+2.0' [15:04] ty [15:04] do I need to wait for publisher or anything before accepting the new one? [15:04] anything else for ubiquity? it picked up flash-kernel & grub-installer. [15:05] Laney: new what wheree? [15:05] *where [15:05] new gtk+2.0 in queue [15:06] no need to wait for the publisher [15:07] xnox: not afaik - as said, if we find a fix for the KDE frontend we can reupload [15:08] ok [15:21] why on earth is pbuilder-scripts aimed at the proposed pocket? (and do we really need more pbuilder wrappers?) [15:23] 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] err, control [15:24] Daviey: the point of those uploads is to give the uploaders a sense of achievement and show them how things work [15:24] of course they are pointless, otherwise [15:25] tumbleweed: How many of them until that task is complete ? [15:26] 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] actually, Homepage uploads can be useful if there's no watch file [15:27] as well as helping to upstream bugs and look for patches [15:27] I'd rather a watch file upload [15:27] watch file would be more useful though... [15:27] or both [15:27] with all spelling corrections.... [15:27] 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] unfortunately, writing a watch file isn't as easy [15:30] tumbleweed: I disagree.. nearly all watch files are easy.. They only really become complicated if you need to repack IMO. [15:30] Home page does show up in Software Center so it's kind of useful to users [15:31] 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] 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] skaet: who do I ping about the amazon and ubuntuonemusic launchers not being overideable through gsettings as I was promised they'd? [15:35] something seems to override the overrides at session open time, adding those launchers even when the system wide setting specifically disables them [15:38] the problem seems to be the session migration script being stupid and always adding them... [15:38] popey, ^ who should stgraber talk to. stgraber, best open a bug to track this. [15:38] ? [15:39] 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] 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] stgraber, ack. [15:40] skaet: popey isn't in this channel btw [15:40] * skaet just noticed [15:41] olli, who should stgraber work with on this, mterry? [15:42] skaet, stgraber, reading [15:45] ubiquity added as opportunity trigger [16] [15:46] neat [15:46] olli, didrocks: I'm going to upload http://paste.ubuntu.com/1226871/ in 30min unless someone comes up with something better. [15:49] stgraber: you should contact the webapps team, it's them who are responsible of the migration script [15:49] stgraber: didn't check as I didn't upload that package [15:50] 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] 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] skaet: ^ [15:54] stgraber, didrocks I asked alex-abreu to touch base with you [15:55] stgraber: do you have a branch w/ the migration patch? [15:55] alex-abreu1: nope, but it's added to bug 1056274 and was briefly reviewed/discussed by mterry and kenvandine in #ubuntu-desktop [15:55] 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] stgraber, ack. [15:59] stgraber: ok for now, I'll work on a better fix upstream === alex-abreu1 is now known as alex-abreu [15:59] stgraber: thank you [16:05] skaet: fix uploaded, should hit the queue in a few minutes [16:05] stgraber, ok. I've updated the pad. Respin Edubuntu as soon as it lands? [16:05] might want to wait for ubiquity too [16:06] infinity, https://launchpadlibrarian.net/117296378/buildlog_ubuntu-quantal-armel.glib2.0_2.33.14-1ubuntu2_FAILEDTOBUILD.txt.gz [16:06] looks like armhf is ok though now. [16:06] skaet: might as well wait for ubiquity [16:06] stgraber, Laney, xnox - does it make sense to wait for ubiquity for the arm respins as well? [16:07] yeah, was doing [16:08] Laney: can you look at webapps-applications? [16:08] skaet: yes. [16:08] waiting for it to get diffy [16:09] * Laney eyes the hplib diff [16:09] hplip [16:09] skaet: arm desktop images that is. Since ubiquity embeds flash-kernel with a bugfix. [16:11] xnox, k [16:12] skaet: I wasn't the one that accepted glib. Either way, didn't really need padding, I was watching it. [16:13] someone want to score ubiquity/armel to make sure it gets in next? [16:13] 2 builders ... [16:14] Laney: doing [16:14] done [16:14] infinity, hadn't seen you in channel this morning, so leaving reference. [16:14] ty [16:14] webapps accepted [16:14] possibly score that up too if you want it for respins [16:15] * skaet really wants that queue logging..... :P [16:15] will do [16:16] Laney: well, no need actually, it's arch all so it's already building [16:16] oh, cool, didn't notice [16:17] 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] plars, thanks. [16:17] plars: thanks, can you please assign Luke to it? [16:18] didrocks: will do [16:18] thanks ;) [16:20] * cjwatson attempts to strace the kubuntu ubiquity-dm failure [16:23] 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] That's not a bad long-term solution, TBH; I've wanted to get rid of our reliance on pykde for ages [16:24] But it probably has some UI effects so I'd like to figure out the underlying bug anyway ... === Ursinha is now known as Ursinha-afk [16:28] http://people.canonical.com/~cjwatson/tmp/ubiquity-dm.trace.xz FWIW [16:31] ah, I see, failure possibly not where I thought it was === bulldog98_ is now known as bulldog98 [16:32] haha [16:32] # KApplication won't initialise if real UID != effective UID. On [16:32] # the other hand, we can't talk to D-Bus unless the effective user [16:32] # is the live CD user. Oh dear. The solution is to use saved IDs: [16:32] # if we hide our rootliness in the saved IDs, then neither [16:32] Apparently I documented this last time I fought with this stack ... [16:32] # KApplication nor D-Bus will spot it. [16:32] And now the assumptions have changed [16:33] So maybe QApplication is the right answer after all [16:33] it's mostly calls to icon loading and one dialogue that need changed I think [16:33] 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] yes they do [16:33] And KGuiItem [16:34] but it's not too hard I think [16:34] loading icons by path rather than name [16:34] replacing the KMessageBox probably needs a few lines of extra code [16:36] Riddelll: Any visible effect on UI? [16:36] The stuff from the KApplication header doesn't seem *desperately* necessary [16:36] here's my quick incomplete version http://starsky.19inch.net/~jr/tmp/kde_ui.py [16:36] accelerators, common menu entries, KConfig, session management, help invocation [16:37] yeah, we don't use most of that [16:37] I need to go out for an hour or two, can tidy up that code once I'm back [16:37] QtCore.KGuiItem and QtCore.KMessageBox presumably wrong :) [16:37] I said it was incomplete :) [16:38] OK - I think this is the right direction, just note you'll need to change ubi-usersetup too [16:38] the use of kdeui has long been a pain so if we can ditch it at the same time then great [16:49] ogra_, just to confirm, you'll be testing ac100 on lubuntu again? [17:01] 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] infinity, never mind, just saw it was done... [17:02] Yeah, it's already scored up sufficiently that more won't make a difference. [17:02] It's just waiting for active builds to complete. [17:02] * skaet nods [17:11] skaet, as always, yes [17:12] phillw, ^ ;) [17:12] ogra_ , thanks. [17:23] skaet: is there a reason why there are no netboot images posted on isotracker yet? [17:24] plars, they need to be manually set, and they appear to have been overlooked for setting up. :P doing now. [17:26] skaet: upgrade is not there either [17:36] plars, should be sorted now. [17:36] (netboot, and upgrades) === Ursinha-afk is now known as Ursinha [17:49] * skaet sees ubiquity is now pending publication for powerpc... [17:56] infinity, are you around to kick off the arm rebuilds? [17:57] I'm around. [17:57] I need to catch up with backscroll to see who's rebuilding what and why. [17:57] it's for flash-kernel [17:57] AIUI, anyway [17:58] Ahh, indeed. [17:58] Ugly bug. [17:59] 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] That looks like it'll just rebuild all live images, period, not just ARM. [18:02] As does the "desktop" pipeline. [18:02] So, we get to build ARM images twice. :P [18:06] 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] xnox: or is this all related to https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1042647 [18:06] I think skaet designed it as favours which do/do not include ARM [18:06] Launchpad bug 1042647 in ubiquity "[FFe] [UIFe] Manual Partitioning LVM" [High,New] [18:07] I suspect the pad predates ARM being moved into daily-live for many flavours. [18:07] Laney: Yeah, what cjwatson said. [18:07] cjwatson, arm part was accurate for beta 1 [18:07] 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] 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] cjwatson, ok. Excuted those sets last night when I did the full rebuild. [18:08] but if we can get it more efficient, +1. [18:10] there is still one preinstalled lubuntu image thouh [18:10] *though [18:10] ogra_: Yeah, I know. I'll fix this all up before I (re-)spin anything. [18:10] thx [18:12] * cjwatson rereads the pad in detail [18:12] infinity: actually, I think what's happening here is that the flavours that include arm are *only* built in the ARM section [18:12] so the ARM section is building images for x86 as well, in reality [18:13] Oh, yeah. I just noticed the lack of "ubuntu" in the "main" section. [18:13] Still, totally not as advertised. :P [18:13] So it's confusing but not inefficient, as I read it === yofel_ is now known as yofel [18:17] infinity, only respins expected at this point though are the arm ones. [18:17] though [18:17] And Kubuntu, or else it can't ship [18:18] See earlier conversation with Riddelll re bug 1055967 [18:18] Launchpad bug 1055967 in ubiquity "ubiquity kde frontend is broken in current kubuntu daily builds" [Critical,Confirmed] https://launchpad.net/bugs/1055967 [18:18] skaet: Sure, but the current layout of the pad means that respinning ARM respins all ubuntu desktop images, etc. [18:18] Not that this bugs me. If we have a new ubiquity, I'd rather do all live images. [18:20] 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] infinity, it was just individual invocations. [18:21] 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] 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] 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] 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] 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] cjwatson: does a respin with ubiquity bring in your changes for Lubuntu ppc-Desktop? [18:24] infinity, pad has the images that need to be respun. use individual lines and ARCHES=... to just get the necessary respins. [18:25] 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] phillw: I guess [18:26] infinity, was accepted as opportunity target, not as a respin trigger [18:27] great :) [18:27] Any current respin would pick up the yaboot-installer fix I merged; no idea whether it's already in [18:27] Check versions in the manifest file for that [18:27] (it's EOD for me now so I'm not going spelunking for it) [18:28] cjwatson: okies, again, thanks for the time you spend on this pesky flavour ;) [18:28] *shrug* wasn't anything Lubuntu-specific about it :) [18:29] cjwatson: I was refering to ppc :) [18:29] bug 1040544 was still there today. [18:29] Launchpad bug 1040544 in ubiquity "Installer dialog does not come up on PPC" [Undecided,Confirmed] https://launchpad.net/bugs/1040544 [18:29] powerpc is an architecture, not a flavour. :-) [18:29] Yeah, like I say, that bug is likely not an installer problem. Can't help you with that. [18:29] i was close! [18:30] x-org bug? [18:30] See my mail. [18:30] From a day or two ago, whenever it was. No point going over it again. [18:30] I'll go dig it out, I knew I had something to do today :/ [18:30] .. [18:49] 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] cjwatson: I'll take a look in a minute [18:58] infinity rather [18:59] Danke. [19:05] may I accept packages in no package set, which fix ftbfs issues? [19:05] doko: Better to check seeded-in-ubuntu(1) to make sure it doesn't appear to land on any images, but yes. [19:06] well, feature freeze still applies ... [19:06] Laney: FTBFS fixes aren't features. :P [19:06] If they /only/ fix the FTBFS, then indeed. [19:06] but that's not how the question was worded [19:06] That was the implication. doko's smart enough to know if he's misrepresenting himself. :P [19:07] infinity, I'll let python3.3 to you ... [19:07] I thought the implication was "can I break FF to fix FTBFS?" [19:07] :-) [19:07] Laney: No, the implication was "we're in a hard freeze and I want to accept FTBFS fixes in the queue" [19:07] I'll do that later after the freeze =) but currently debian doesn't have many new upstream versions [19:08] doko: Do I want to know what's wrong with py3.3 that you're pawning off on me? [19:09] Oh, the sync in the queue. [19:11] 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] doko: That python3.3 Debian upload doesn't seem to imply that it contains the changes from the last Ubuntu upload... [19:12] infinity, it does [19:12] skaet: Yeah, I was holding off until I heard back about kubuntu as well. [19:12] doko: Just your infamous lack of verbosity in changelogs at work here? :) [19:13] skaet: But for now, I might just spin some arm/ubuntu-desktop images for people to test Oli's fix. [19:14] s/some/one/, since we only build one... [19:14] thanks infinity, yes please. [19:15] skaet: Building now, then. === henrix is now known as henrix_ [19:22] ogra_, ping who is responible for updating the ARM OMAP install instructions [19:26] NCommander: I *believe* it is elfy [19:26] NCommander: https://wiki.ubuntu.com/QATeam/QuantalTestcaseUpdates [19:26] although that may well be seperate to install instructions :) === robbiew1 is now known as robbiew [19:41]