[00:00] * ScottK ^^^ [00:01] That was me. [00:01] cool, was waiting for that [00:02] glib2.0 looks OK for precise; last call for objections before I copy [00:24] ^^^ There was already a sync in queue, so the direct upload was unnecessary. [00:54] copied glib2.0 to precise [00:55] * ScottK reviewed apport [01:01] partman-auto accepted [01:09] do I need an FFe to switch from python-gobject to python-gi? [01:24] ^^^ was me. [01:29] infinity: It might not be a bad time to start to rebalance back towards armel from armhf. [01:56] ScottK: do I need an FFe for the python-gi conversion? [01:56] Dunno. [01:57] I'd say do whatever you need to do and I'll sprinkle holy water on it as needed. [01:57] Don't screw up. [02:50] The nux upload I just sponsored for rsalveti is necessary to make all the work done for compiz/unity GLES support on ARM not be a complete waste of time. [02:50] If someone who isn't me wants to poke it and let it in, since I sponsored it. [02:51] that will finally allow (once the compiz changes are in place by ogra_) to have a working unity 3d experience on ARM [02:51] infinity: thanks for the upload btw [02:58] rsalveti: "once the compiz changes are in place"? Is 1:0.9.7.4-0ubuntu3 still not good enough? [02:58] infinity: iirc ogra_ was updating compiz-plugins-main [02:59] and I remember he was also fighting with a newer upstream update/rebase [02:59] so not yet sure if current compiz version will be the one used at the release [03:00] I should hope so. [03:00] or if it might just be something for -updates [03:00] Final freeze is tomorrow. :P [03:00] yeah, then we should be good :-) === jbicha is now known as Guest73631 [03:11] can someone approve that ^ [03:11] it fixes bug #978297 (and by extension bug #978147) [03:11] Launchpad bug 978297 in apparmor "apparmor should quietly return success in a container" [High,In progress] https://launchpad.net/bugs/978297 [03:11] Launchpad bug 978147 in lxc "rsyslogd fails to start in cloud template " [High,Confirmed] https://launchpad.net/bugs/978147 [03:12] so my comment in 978297 on testing performed. it is a simple patch [03:14] s/so my/see me/ [03:14] meh [03:14] see my === Guest73631 is now known as jbicha_ [03:20] jdstrand, looks reasonable. Thanks for getting the fix in. approved. [03:21] \o/ [03:21] skaet: thanks [03:22] jdstrand, is there an outlook on bug 969299? [03:22] Launchpad bug 969299 in apparmor "apparmor prevents dpkg-divert and localedef from working in a container" [Critical,Confirmed] https://launchpad.net/bugs/969299 [03:23] skaet: fyi, I will be sponsoring an upload for sbeattie for apparmor [03:23] skaet: he will be able to answer questions on the bugs, but he'll contact you [03:23] skaet: let me look [03:24] thanks jdstrand. could you please add the rls-p-tracking tag to it, if appropriate. [03:24] skaet: to which, 969299? [03:25] skaet: I think the workaround in lxc is what we will go with for precise. jjohansen was looking at this-- he should comment [03:26] jdstrand, skaet: right basically the two patches serge came up with, that disables apparmor load scripts inside the container [03:26] since apparmor does not support loading policy in the container for precise this is the cleanest solution [03:26] jjohansen: this is the mediate_deleted bug [03:27] no [03:27] (969299) [03:27] yes :) [03:27] jjohansen: not talking about upstart. skaet asked about 969299 separately [03:28] jdstrand, jjohansen, understanding if we'll be fixing this or not, is what I'm trying to understand. :) [03:28] jdstrand: err, which bug did you want me to comment on? ah [03:28] jjohansen: 969299/970647 [03:28] 969299 [03:28] skaet: no. The lxc adding the mediate_deleted flag to the profile is the work around for precise. [03:28] so the lxc work around [03:29] jjohansen, ok, can the bug milestone and priority for upstart be updated then to reflect this? [03:29] jdstrand: I am still trying to figure out bug#970647 [03:29] Right now its critical, which catches my attention ;) [03:30] I expect to sru it, but it isn't release critical, it can make figuring failures tricky but does not cause failures [03:30] s/upstart/apparmor/ [03:30] fair nuf, milestone target should be precise-updates then. Importance shouldn't be critical. [03:31] skaet: bug#970647 isn't marked critical, 969299 is but we can not do anything more than the workaround lxc is using for precise [03:31] for 969299. :) [03:31] infinity: the upstart bug is dealt with. we are talking about a different bug [03:31] I'm going to mark the 969299 as wontfix for apparmor [03:32] jdstrand: Yes, I know. Hence the correction to someone mentioning milestone and priority for an upstart bug. :P [03:32] we can sru 970647 [03:32] jdstrand: yes please [03:32] jdstrand: I think we should be able to [03:32] infinity: ah, read that the other way around [03:32] it will be a kernel patch, and it will be something pushed upstream too [03:33] jdstrand: Your sed runs backwards? ;) [03:34] infinity: more that I read confusion in general and assumed you were confused too. I apologize [03:34] ;) [03:34] skaet: 969299 should fall off your list now [03:34] :) [03:34] rsalveti: Say, speaking of sponsored uploads, whatever happened to xbmc? [03:34] thanks jdstrand, jjohansen. [03:35] infinity: pull request sent to upstream by the debian maintainer, avik is working on getting the new patch set/debdiff tomorrow [03:35] Mmkay. [03:36] superm1 also knows the current status of that, hopefully we'll get it sorted over the next few days [03:36] might be still good to get as sru [03:36] rsalveti: Sure, it's unseeded universe, so there's a bit of wiggle room. I'd *prefer* not to enable new arches as an SRU, but there's no technical reason we can't. [03:37] yeah, should know better tomorrow, once avik updates the merge proposal [03:37] will keep you updated [03:37] Danke. [03:42] * ScottK looks at nux [03:43] infinity: I'd appreciate it if you'd look at strigi. It's a trivial diff. [03:44] ScottK: I was waiting on an appserver to feed me a diff, cause I'm lazy. ;) [03:44] ScottK: But I intend to look through the whole queue tonight, I'm up for a while working. [03:44] OK. Thanks. [03:44] Strigi was uploaded 5 hours ago. If you don't have a diff by now, I don't think you'll get it. [03:45] Yeah. I'm getting that impression. :P [03:45] * infinity grabs the source. [03:45] In any case, nux is in. [03:45] Thanks. [03:46] Part of the reason I want to get strigi in is that the previous upload isn't built on armel and powerpc yet, so if it can get in, it'll save doing it twice on the slow archs. [03:46] Heh. [03:46] Uhm. [03:47] Maybe I'm just going cross-eyes, but this looks like the same symbol is being listed twice. [03:47] Oh, no. I'm just going cross-eyed. [03:47] But. [03:47] (optional=templinst|arch=i386 powerpc)_ZN10QDBusReplyI5QListI5QPairIb7QStringEEEC2ERK12QDBusMessage@Base 0.7.7 [03:47] ^-- Doesn't that nees the same s/i386 powerpc/!armel !armhf/ treatment? [03:47] need, too. [03:48] I can't type tonight, apparently. [03:49] ScottK: I'm happy to be proven wrong, but the diff looks a bit suspect. [03:50] It should change from i386 powerpc to !armel !armhf (i.e. add amd64) [03:50] ScottK: Yes, but it doesn't. :P [03:50] ScottK: (My point is that that construct is in two symbols in a row, the diff only changes one of those) [03:51] Looking [03:51] skaet: btw, what is the final freeze deadline? I know it is tomorrow, but what hour? [03:52] My bet's 2100UTC, people seem fond of that hour. [03:52] 2100 UTC [03:52] They aren't the same. [03:52] ScottK: No, I know they're not the same symbol. [03:52] OK. [03:52] Only one of them came up in the build log with a change. [03:52] infinity: they are fond of that, aren't they? :) [03:52] skaet: thanks [03:53] ScottK: I'm questioning that two nearly identically-named symbols are represented on a strange venn diagram of arches. [03:53] infinity, yup, that gives enough time for builds to complete before the overnight build, and catch in the work day, without lots of requests for extensions. [03:53] ScottK: But I guess we can let it in and see. :P [03:53] infinity: No, you're right. [03:54] infinity: Please reject and I'll upload again. [03:56] I can't tell you how many times I looked at that. Thanks for a careful check. [03:56] Re-uploaded. [03:56] symbols files hurt my head too, don't feel bad. [03:56] Especially since I always stupidly edit them by hand. [03:57] cf. Russ's recent indictment of symbols files for C++ libs on debian-devel [03:58] slangasek: Define recent? [03:58] last three months [03:58] Longish thread; ‘Do symbols make sense for C++’ [03:59] http://lists.debian.org/debian-devel/2012/01/msg00671.html [03:59] rather, http://lists.debian.org/debian-devel/2012/01/msg00727.html [04:02] ScottK: Looks gooder. [04:02] Great. [04:02] infinity: I did edit that one by hand too. [04:03] And I reviewed by eye. [04:03] Software be damned. [04:03] I use gimp for diffing [04:03] * infinity mails magnets to London and marks the envelope "eglibc upload". [04:04] But first, to Subway to fuel my evening. [04:28] * ScottK took care of ^^^ [04:43] do flavors need UIFe's for their own packages? [05:00] micahg: that's somewhat underspecified; but I'd say, it depends on the leads of that derivative being okay with it [05:00] pitti: he made the commit ;), should I just remind them to update their docs as necessary? [05:01] at some point we just need to update https://wiki.ubuntu.com/UserInterfaceFreeze [05:47] grrrrr at linaro again for not using the vcs… [05:47] 3 times in less than a week, [05:49] ^- ubiquity - giant diff, but mostly d-i stuff that's been approved already [05:49] cjwatson: will wait a bit to get a diff, then review [05:49] didrocks: Oh, for nux? [05:50] infinity: yeah, no coordination with us, and of course, the ppa for unity 5.10 release is now not working at all [05:50] didrocks: How did it break your PPA? [05:50] infinity: well, newer version with a version incompatible for the ABI… [05:50] didrocks: (You can probably blame me for not committing to your branch, though... I can clean that up now) [05:51] infinity: I'm doing that, I'll then apt-get source from the ppa and copy the changes over [05:51] Oh, you're already fixing it up? Kay. Sorry for the noise. [05:52] didrocks: does that mean we'll need another full round of PPA builds and testing? Or can that happen in -proposed? [05:52] infinity: no worry, but between that and compiz/compiz-plugins-main on Friday, I'm tired of fixing linaro's breaking the ppa :) [05:53] pitti: no, the switch is only building on armel, but I doubt of how the change good is, knowing that unity has no support for opengles [05:53] It works fine, AFAIK. [05:53] didrocks: if that's causing too much trouble, we could also just revert the nux upload [05:53] That was the whole drive for the compiz and nux changes. [05:54] infinity: it doesn't apparently, they have a huge branch that is under review upstream [05:54] infinity: so I doubt it's working :) [05:54] urgh, forgot to bump installer seed to 3.2.0-23 [05:54] "under review upstream"> should've landed last week? [05:54] (in Ubuntu) [05:54] done, but it's possible jenkins will hate us and require alternate/server respins, depending on exactly how it works out [05:54] didrocks: The backported stuff in Ubuntu works. [05:54] slangasek: no, we told them that we take compiz and compiz-plugins-main this cycle, but not nux nor unity [05:54] slangasek: as it was too late [05:54] ah [05:55] ok Vcs fixed, now fixing the ppa [05:59] infinity: so if they come with a bug unity patch for opengles, please ping me first ;) [05:59] (all fixed now, let's wait for newer testing) [05:59] didrocks: Check. [06:00] didrocks: This one wasn't particularly intrusive, and there were claims it actually made things work. [06:00] infinity: yeah, this one is fine, it's just a pity that it screwed the ppa for a while, but fortunatly, the upload was recent [06:01] Hm. How come this https://launchpad.net/ubuntu/+source/mysql-dfsg-5.1/5.1.62-0ubuntu0.10.04.1 mysql-dfsg-5.1 update has ended up in -proposed, not -updates or -security? [06:02] RAOF: You'd have to ask the security team, I imagine. [06:03] * cjwatson -> Millbank [06:04] RAOF: it needs more testing [06:04] RAOF: https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035035.html [06:05] micahg: Ta. [06:31] Anyone from the release team able to look at three bugs with debdiffs on them? I understand they'd need to get in today before final freeze. Or is this the wrong place to ask? [06:32] This is the right place. [06:32] Are they large changes? [06:32] Thank you. Bugs are: bug #972749, bug #972781 and bug #973373 [06:32] Launchpad bug 972749 in indicator-sound "Prefer pavucontrol over xfce4-mixer in ubuntustudio session" [Undecided,Fix committed] https://launchpad.net/bugs/972749 [06:32] Launchpad bug 972781 in xfce4-volumed "Prefer PulseAudio when XF86AudioMute is used for ubuntustudio session" [Undecided,Fix committed] https://launchpad.net/bugs/972781 [06:32] Launchpad bug 973373 in ubuntustudio-meta "package ubuntustudio-audio 0.90 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/973373 [06:33] infinity: No, quite trivial each. [06:34] astraljava: you should've caught infinity when he was piloting earlier [06:35] Indeed. [06:35] But, as it turns out, I'm still capable of doing all the same things. :P [06:35] Oh? Why's that? [06:35] Now, that said. Reading just the bug titles, while the patches may be trivial, the changes aren't. [06:36] infinity: Right, anything particular you want to talk about, or are you rejecting some|all of them off-hand? [06:38] astraljava: I haven't had a chance to actually look at the diffs or think about impact, I'll get back to you. [06:38] astraljava: But things like changing default mixer applets and whatnot are pretty major changes, even if it's a 1-line code change. :P [06:39] infinity: Sure, I get that. I'll be around if you want to have a chat. :) [07:26] ^ review appreciated (I uploaded) [07:26] * pitti reviews the other queue items [07:28] so starting to push the whole unity stack (we will maybe have a bamf release a little bit later) including compiz and c-p-m. There is no ABI break for those, so I can push them directly [07:28] then, for nux/unity/unity-2d I will use -proposed once the release is ready [07:31] pitti: Looking. [07:34] pitti: Accepted. [07:42] infinity: thanks [07:47] pitti: can you give back the g* failures here: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20120328-precise.html#ubuntustudio [07:48] micahg: what do you mean with "give back"? they all built fine [07:49] oh, I suppose the test rebuilds, yes [07:49] pitti: huh? they failed in the rebuild [07:49] I tried the archive [07:49] no, rebuild :), I can do archive give backs [07:49] * infinity does it. [07:49] micahg: done [07:50] infinity: ^ [07:50] thanks [07:50] Or, pitti will beat me to it. :P [07:50] still not sure what to do with the goffice rebuild failure, will have to think about it over the weekend [07:50] * micahg delegates [07:52] micahg: If our PCRE is UTF-8 clean, just patch that test out of goffice's configure? [07:52] infinity: that's one option :) [07:52] the weird thing is that it works in Debian [07:53] and Debian doesn't have the test binary either, so I figure I'm missing something [07:53] micahg: Really? [07:53] micahg: That is weird... [07:54] and it built the first time when the binary didn't exist either [07:54] Well, maybe you're misreading the test, and it doesn't require pcretest at all? [07:54] And maybe we really do have an issue the test is tripping on? [07:55] That check is pretty straightforward, though... [07:57] infinity: this is ugly, it's conditional on other tests failing which is probably why it works in Debian and worked in Oneiric [07:57] micahg: Yeah, I'm seeing that the Debian buildds don't even run the pcre tests... [07:58] neither did the oneiric build [07:58] (Does that mean they also don't end up linking pcre?) [07:58] That sounds like a bug. [07:58] Oh, I see, it wants pcre iff some glib feature isn't there. [07:59] yeah, not linked against pcre in Debian or Oneiric [07:59] * micahg thinks we should switch channels [07:59] So, the question is why does glib no longer have that feature? === doko_ is now known as doko [08:07] skaet: We just found a critical bug in LTSP (ldm actually), caused by a typo in one of the scripts ending up breaking the environment of the thin client session. Fix has been commited upstream and we're expecting a bugfix release to land in Debian later today/tomorrow which we'll then sync in Ubuntu [08:08] skaet: so won't make it before final freeze but should be there shortly after. The fix is a trivial one liner. [08:15] infinity: please give back goffice in the rebuild (or someone else) [08:16] micahg: looking at it [08:17] micahg: done [08:17] micahg: do you need the rebuild result quickly? [08:17] stgraber: no, just not to show up (it should be fine now) as it's on the xubuntu and lubuntu ISOs [08:17] k [08:32] wie baue ich die treiber nochmal manuell? [08:36] slangasek: the gnome-session upload is just for you ^ ;) [08:44] so it seems KDE .pot translation templates haven't been generated for the whole of the cycle [08:44] this means we are missing lots of strings [08:44] to fix it I need to do a mass upload of everything KDE [08:45] and then a mass upload of all the language packs [08:45] any problems? (besides taking up the build daemons for ages) [08:45] Riddell, why do you need uploads? you can upload the pot directly to launchpad without a source upload [08:46] hmm [08:46] Riddell, https://translations.launchpad.net/ubuntu/precise/+source/YOURSOURCE/+pots/YOURSOURCE/+upload [08:47] that's a million clicks rather than just scripting it [08:47] I'm asking dpm if it's possible in an easier way [08:48] Riddell, well it's easier a million clicks or a millions builds and updates throwing at the archive,buildds,users [08:48] easier->either [08:51] seb128: automated work >> manual work [08:52] Riddell, annoyance for thousand of users >> annoyance for 1 devel [08:53] Riddell, throwing ton of updates has a cost on buildd time, download time for users, etc [08:53] that's the price of using a development version [08:53] bandwidth for everyone... [08:53] Riddell, that devel is pre release frozen though [08:53] Riddell: I'd rather not rebuild all of KDE if there's no actual sane reason. [08:54] infinity: translations are a sane reason [08:54] Riddell, I would consider now is a time where you should rather script the pot upload to launchpad that abuse users and buildds [08:54] Riddell: But, by your own admission, the rebuilds are just to get them into rosetta, and into langpacks. [08:54] Riddell, you don't need source uploads for updating the templates [08:54] seb128: it can't be scripted [08:55] seb128: there is no other sane way to update the templates [08:55] Riddell, it can easily be scripted to call $webbrowser $uri for you and be one click by pot [08:55] it's like an half an hour job [08:56] Riddell, just get the list of source, iterate the url I gave you before replace YOURSOURCE by the template name [08:56] < dpm> it would take me a whole day to manually upload them into Launchpad [08:56] how many sources,templates are we talking about? [08:57] come on, iterating over your sources list with a script calling https://translations.launchpad.net/ubuntu/precise/+source/YOURSOURCE/+pots/YOURSOURCE/+upload [08:57] and doing 2 clicks [08:57] 50-150 sources, 100-1000 templates? [08:57] if you do it for 100 sources it's less than an hour [08:57] no it's a lot more than an hour [08:57] it takes you more than a minute to click 2 buttons? [08:57] there are a *lot* of templates [08:57] like pick the file, click the "upload" button [08:58] Riddell, seb128, I've actually got a script to do uploads, but I haven't been using it in a while and so it remains untested. But perhaps we could use it: http://bazaar.launchpad.net/~dpm/ubuntu-l10n-tools/trunk/view/head:/ubuntu_l10n_tools/lp_l10n_upload/__init__.py [08:58] it's part of the ubuntu-l10n-tools PPA [08:58] well not my call, but I think throwing 150 KDE builds to the builders and to users on hard freeze day is not 0 cost either [08:59] it might take a week for the armel builders to catch up [08:59] dpm: able to test it? [09:00] Riddell, sure, but even if it works, I'll need some help with the list of templates/source packages. Do you have a source package with a single template I could test it against? [09:01] dpm: rekonq? [09:02] Riddell, bulldog98, if you tell me the source package (I assume it's rekonq) and give me an up-to-date .pot file, I can test it straight away [09:03] * Riddell grabs [09:03] dpm: http://people.canonical.com/~jriddell/tmp/rekonq.pot [09:04] source: rekonq [09:07] Riddell, ok, thanks, give me a few minutes to see if the uploader script still works and can be used [09:08] argh ... I specifically poked the ubiquity slideshow guy about getting UIFe before doing any slideshow change... and now that I'm ready to do a translation upload I see they changed a bunch of screenshots without documentation [09:08] stgraber: just reject them? [09:11] Riddell: well, I'm the one uploading the package ;) so I need to go through the changes extract the actual bugfixes, revert the rest, then merge the translations and upload [09:11] so quite a bit more than the 2 minutes I was hoping for it to take [09:14] yes manual operations are no fun to do [09:17] infinity, stgraber, Riddell: I left a blurb about the gnome-session upload in https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/771896/comments/27, FTR [09:17] Launchpad bug 771896 in gnome-session "No way to save current session" [Low,Triaged] [09:20] I also reviewed pkg-kde-tools, please don't accept yet [09:20] (see pad) [09:22] pitti: right enough, rejecting pkg-kde-tools [09:23] Riddell: cheers [09:24] pitti: Yeah, I'm not really sure how anyone would even inject that variable into the environment. Well, any "normal" user who doesn't understand how X/dm/session startup works. [09:25] didrocks: ah, you're back [09:25] didrocks: FYI, I left a comment in bug 771896 [09:25] Launchpad bug 771896 in gnome-session "No way to save current session" [Low,Triaged] https://launchpad.net/bugs/771896 [09:25] pitti: yeah, I was logging out/in to test the plumbings [09:25] What was so wrong with have a UI tickbox that's off by default and warns against use? [09:25] pitti: looking [09:25] So the "power users" can break what they like? [09:26] session saving has never really worked the way it is implemented in g-session [09:26] Yeah, it's never worked well, and I don't use it. [09:26] it's spelled s-u-s-p-e-n-d [09:26] But clearly, lots of people prefer a broken solution to no solution. [09:26] pitti: well, we discused it at UDS [09:26] pitti: slangasek made a session at the last minute for it and was fine with a hidden way to get it back for people wanting it [09:26] and this causes so many weird bugs that we should just declare this broken and bury it for good IMHO [09:27] pitti: To be fair, without ksplice, and with our 2-week kernel update schedule, suspend isn't a great option to many either. :) [09:27] but *shrug*, as I said I won't veto it, but that env var approach seems rather undiscoverable [09:27] Do people *actually* prefer a broken solution, or do they *say* they'd prefer a broken solution? :) [09:27] RAOF: I dunno, have you read the bug log? [09:27] RAOF: There are a ton of people who talk about how awesome GNOME session saving was before we took it away. [09:27] Yes, but not recently. [09:28] And, since I know it was always crap. [09:28] They must like crap. [09:28] The end. [09:28] pitti: well, I don't mind, it's not for me and I don't use it. slangasek was pretty willing to have a way to get it back and we really don't want to expose as it's completely broken if you switch between session for instance [09:28] what didrocks said [09:28] didrocks: I think the environment thing is a bit of a joke, TBH. It's going to lead to weird forum HOWTOs on editing dm startup files in perverse ways that people will follow without knowing what they're doing. [09:29] slangasek find the current gnome-session saving good enough that's it's make him spare time and be useful so he asked for a way to be able to turn it back on [09:29] didrocks: If we're going to let them do it, just let them do it. [09:29] infinity: so, let's push it back. I did what was planned at UDS, that's all ;) [09:29] yeah, that no option, too bad for Steve ;-) [09:30] that->then [09:30] I'm just saying that a mystery environment key isn't exactly an option. :) [09:30] infinity: what do you propose then? [09:30] didrocks: Like I said, restore the tickbox to the UI, and add a "don't use this" warning? [09:31] infinity, it's a secret "make slangasek happy" option :p [09:31] infinity, we could change it by an username check :p [09:31] infinity: hum, not really, people will still use it without knowing and we will have even more people getting a broken state [09:31] seb128: And a ton of people in the forums, apparently. And following up to that bug. And... [09:31] didrocks: They'll use it anyway. [09:31] less user will use an env variable that the option I guess ;) [09:32] didrocks: Look at the number of people who muck around to turn off global menus. [09:32] didrocks: And the odds that even 2% of them know what they're doing in those conffiles seems slim. [09:32] but again, I don't care and don't have time to argue over it, I just did what we planned, reject if you want ;) now on unity [09:32] * infinity shrugs. [09:32] I'm passing on it, pitti's a desktop guy. :P [09:32] Or, he can make vorlon have the final say. [09:33] didrocks: as I said, I'm not vetoing it, I just question how useful it is [09:33] I don't use GNOME session saving anyway, so it's moot for me, I'm just trying to figure out the best way to solve things for people who think it's "good enough". [09:33] (Telling them they're wrong, while a GNOMEish answer, probably isn't helpful) [09:34] I really don't have the time to argue over it. I'll just have the filling I didn't promess something and didn't try to do it :) [09:34] feeling* [09:35] infinity, slangasek's point is that the session saving is "good enough" that he spares him 5 minutes or reopening and replacing windows on screen when he needs to restart [09:35] seb128: Yes, and lots of others agree. [09:35] so he really wanted a way to opt in for users who really want [09:35] seb128: (cf: the bug, and forum threads) [09:36] seb128: I'm saying that a magical environment key isn't really helpful to any but the most technical users (or people who routinely copy and paste from random forum threads) [09:36] we wouldn't give him an ui option though because we consider we shouldn't offer ui option for things we don't consider working well enough to be at that level [09:36] well, at least if you deal with environment option we can claim you did stuff in an hackish way non supported [09:36] seb128: If you can prove that the subset of "people who like the crappy session support" mostly overlaps with the set of "very technical people", then maybe it's a non-issue. [09:37] when it's us who provide a checkbox we have an harder time to bail out [09:37] ^^ pfb2t1c2pfb - debs match, drops dpatch in favor of source format 3.0 [09:37] That's the worst source package name ever... [09:40] is that in base64 or something? [09:42] pfb2t1c2pfb: convert pfb into more compressible format and back [09:42] pfb to t1c to pfb [09:42] Yeah, I can read the 2s. [09:42] uploaded ubiquity-slideshow-ubuntu, good luck to whoever reviews it... it took me md5sums to confirm the changes in the upstream branch were sane (for these I didn't revert) [09:42] It's still an awful name. :P [09:42] golang: that's for bug 979390 [09:42] Launchpad bug 979390 in golang "[FFe] Update golang to 2:1-3 in Precise" [Undecided,New] https://launchpad.net/bugs/979390 [09:43] (not actually FFe, as ScottK said) [09:43] someone should tell the maintainer that in dh_make -p the -p doesnt stand for password but for packagename :P [09:54] pitti, rickspencer3: have we made any decisions about whether we are going to recommend i386 or amd64 in the ubuntu.com/download page for Ubuntu Desktop? [09:55] Didn't we have a bunch of sessions and a spec about switching to amd64 as the recommended default? [09:56] pitti: infinity: cjwatson: so all unity plumbings now uploaded (with libgnomedesktop3). What remains is nux/unity/unity-2d (and gnome-control-center for the hud configuration depending on unity-2d). So I'm just waiting a little bit to see if we can sneak a focus fix in unity first. Anyway, all this will be uploaded to -proposed [09:56] ara: I'm not aware of an official decision [09:56] we had a session about that, whose work items mostly haven't been done [09:56] FWIW, I've run amd64 since hoary [09:57] so I think status quo wins [09:57] :) [09:57] https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-64bit-by-default [09:58] Oh, yeah. [09:58] None of that's solved. [09:58] Cross-grades? Really? [09:58] That was an ambitious session. I'm glad I didn't go :) [09:58] didrocks: ok, I guess the lenses etc. are not API sensitive and can go already [09:58] it mostly works in ubiquity, modulo bugs [09:58] pitti: right, they work with the older unity [09:58] where "crossgrade" is "install over the top and bodge" [09:59] Heh. [10:00] didrocks: erk @ gnome-desktop3 [10:01] didrocks: does that "just" add that new API, or does it change the functionality of libgnome-desktop itself? [10:02] pitti: it doesn't add it as an API in fact, it set on the root window the right color as an X property [10:02] pitti: the patch was reviewed by desrt last week [10:02]