[08:34] <ara> Hello!
[08:34] <ara> There are more and more systems with hybrid graphics in the market (UMA + discrete)
[08:35] <ara> Are there plans in the installer development to support this (i.e. switching between one or the other during installation time)
[08:35] <ara> ?
[09:57] <cjwatson> ara: on the face of it, it doesn't sound like something an installer should concern itself with; better to keep it simple at installation time, and I don't think users would be surprised by the installer keeping it simple
[10:59] <CIA-14> ubiquity: cjwatson * r4763 trunk/ (3 files in 3 dirs): Recreate .pyc modules excluded from the live filesystem.
[11:00] <cjwatson> now I suppose I have to finish fixing eglibc so that ubiquity can build :-/
[12:26] <cjwatson> ah, the package that actually needed to be updated was langpack-locales, not eglibc
[12:26] <cjwatson> that's nice since it might build in finite time
[12:34] <CIA-14> ubiquity: cjwatson * r4764 trunk/ (d-i/manifest debian/changelog):
[12:34] <CIA-14> ubiquity: Automatic update of included source packages: grub-installer
[12:34] <CIA-14> ubiquity: 1.64ubuntu3, user-setup 1.28ubuntu16.
[12:55] <ScottK> ev: I took a look at the ubiquity powerpc build failure and it seems like some locale change that I don't understand.  It replicates on i386 now, so it's only due to archive skew it only failed powerpc.
[12:55] <ev> lovely
[12:56] <ev> I'll have a look tomorrow (swamped in wubi framework investigation work today)
[12:56] <ScottK> Thanks.
[13:09] <cjwatson> ScottK: that's what I was referring to above ...
[13:10] <ScottK> cjwatson: Oh.  I only skimmed the backscroll.  Missed it.
[13:10] <cjwatson> I uploaded langpack-locales about three-quarters of an hour ago to fix it
[13:10] <ScottK> Cool.
[13:10]  * ScottK goes to look at the diff and maybe learn something.
[13:11] <ScottK> (the maybe is reflective of the odds of me learning, not their being something there to learn)
[13:13] <cjwatson> the changelog is probably the most informative bit ...
[13:56] <CIA-14> ubiquity: cjwatson * r4765 trunk/debian/changelog: releasing version 2.7.10
[16:23] <seb128> hi
[16:23] <cjwatson> ev: speaking of Wubi on #u-m - could you upgrade your build system to grub-pc-bin 1.99-8ubuntu1 and build wubi r220, please?
[16:23] <ev> sure thing
[16:23] <seb128> so ubiquity seems some gconf to gsettings love, do you prefer one bug "port to gconf"
[16:23] <ev> on it now
[16:24] <ev> yes
[16:24] <seb128> or different bugs like "settings migration should migrate gconf datas as well" or "read http proxy key in the wrong database"
[16:24] <seb128> or "unactive automount using a deprecated way"
[16:25] <seb128> "port to gsettings" I meant ;-)
[16:30] <ScottK> Was there any benchmarking done to check if removing the .pyc files has an effect on how fast Ubiquity starts up/installs?
[16:31] <cjwatson> no
[16:31] <ScottK> OK.  Thanks.
[16:31] <cjwatson> I decided not to worry too much about that since (a) the space savings are so large and (b) I suspect that I/O will tend to dominate
[16:32] <ScottK> Makes sense.  I figured it was a have to do kind of change for the space savings.  Just a matter of curiosity.
[16:36] <seb128> cjwatson, any opinion on the bugs filing question?
[16:36] <seb128> or is that an ev's thing?
[16:36] <seb128> I would like to file those
[16:36] <cjwatson> I actually didn't test a live filesystem without the .pyc files directly; I just modified ubiquity not to copy them in the bulk copy pass (since that was a lot quicker)
[16:36] <cjwatson> seb128: whatever ev wants on this is fine by me
[16:37] <ev> I think one giant bug is fine.
[16:37] <ev> as long as it's detailed in what it's requesting
[16:37] <seb128> it's going to be mediumly-small don't worry ;-)
[16:37] <seb128> ev, ok, doing that
[16:37] <seb128> thanks
[16:38] <ev> sure thing
[16:38] <bdmurray> cjwatson: I've quite a few grub2 apport-package bugs regarding '/usr/sbin/grub-probe: error: /boot/grub/device.map:2: No open parenthesis found.'  Is that something already fixed or is there already a master bug for that?
[16:41] <cjwatson> bdmurray: I've not heard of it
[16:41] <cjwatson> could be a local misconfiguration
[16:42] <cjwatson> bug#?
[16:42] <cjwatson> especially one that has an example device.map attached :-)
[16:42] <bdmurray> bug 797065 (I'll have to look harder for a device.map one)
[16:42] <ubot2> Launchpad bug 797065 in grub2 "package linux-image-2.6.32-32-generic 2.6.32-32.62 failed to install/upgrade: post-installation script instalaturik azpiprozesuak 1 errorea eman du irteeran" [Undecided,New] https://launchpad.net/bugs/797065
[16:44] <bdmurray> cjwatson: okay not too hard don't see any attachments named *device*
[16:52] <cjwatson> I've requested it
[16:53] <cjwatson> and I'll modify grub2's apport hook to attach it too
[16:54] <bdmurray> cjwatson: I've some work to do on that anyway so could do it
[16:55] <cjwatson> already done :)
[16:55] <bdmurray> ah, great
[16:55] <cjwatson> in Debian, anyway
[16:56] <cjwatson> will pick it up at the next upload/merge
[16:57] <bdmurray> bug 642290 is rather odd too - its an error regarding /etc/grub.d/README
[16:57] <ubot2> Launchpad bug 642290 in grub2 "package linux-image-2.6.32-24-generic 2.6.32-24.43 failed to install/upgrade: sub-processo script post-installation instalado retornou estado de saída de erro 2" [Undecided,New] https://launchpad.net/bugs/642290
[16:57] <cjwatson> bdmurray: incidentally, I notice that even though bug 797065 was apparently initially filed on grub2, grub2's apport hook doesn't seem to have taken effect
[16:57] <ubot2> Launchpad bug 797065 in grub2 "package linux-image-2.6.32-32-generic 2.6.32-32.62 failed to install/upgrade: post-installation script instalaturik azpiprozesuak 1 errorea eman du irteeran" [Undecided,Incomplete] https://launchpad.net/bugs/797065
[16:58] <cjwatson> README> I thought I fixed that upstream ages ago
[16:58] <bdmurray> cjwatson: yes, I see that in the changelog now
[16:58] <cjwatson> huh, perhaps not
[16:58] <cjwatson> oh yes, there it is
[16:59] <bdmurray> cjwatson: there is no grub apport hook in lucid
[16:59] <cjwatson> ah, ok
[16:59] <cjwatson> I'll close out 642290
[16:59] <bdmurray> there are many more like that which I'll take care of
[17:00] <cjwatson> that's odd, it was supposed to have been fixed in lucid
[17:00] <seb128> ev, cjwatson: bug #800760
[17:00] <ubot2> Launchpad bug 800760 in ubiquity "Needs gconf to gsettings updates" [Undecided,New] https://launchpad.net/bugs/800760
[17:01] <cjwatson> perhaps some kind of local weirdness - anyway I gave a workaround
[17:01] <cjwatson> or maybe I got the patch wrwong in lucid somehow
[17:01] <seb128> ev, cjwatson: I've dumped notes on what I found with a grep gconf in the current ubiquity sources, I will update the bug during the cycle if,when desktop side change or if I get other comments
[17:03] <bdmurray> cjwatson: its too bad that at least 642290 doesn't have the grub package version in it
[17:03] <ev> seb128: thanks for the attention to detail on that! Very much appreciated
[17:03] <seb128> ev, yw ;-)
[17:16] <cjwatson> bdmurray: agreed
[17:28] <ev> new wubi is up
[17:32] <bdmurray> cjwatson: it seems to me the fix isn't in grub2 in lucid-updates
[17:32] <bdmurray> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/grub2/lucid-updates/view/head:/util/grub-mkconfig_lib.in#L129
[17:37] <cjwatson> bdmurray: look in debian/patches/972_ignore_grub.d_README.diff
[17:37] <cjwatson> it wasn't upstream at the time lucid was released
[17:37] <cjwatson> ev: thanks
[17:38] <bdmurray> ah, got it
[19:28] <bdmurray> cjwatson: regarding the grub apport hook there is a request to have /etc/default/grub to plymouth bug reports - so I was planning on moving some of the grub hook to apport itself.  Does that seem reasonable?
[21:07] <cjwatson> bdmurray: hmm, maybe have it in both with the same keys - I'd like it to be obvious that the grub one is freestanding to some extent
[21:07] <cjwatson> if that makes sense
[21:25] <bdmurray> cjwatson: I was looking at the _atach_file_filtered function in particular and only that
[22:41] <bdmurray> cjwatson: additionally it looks to me like /etc/default/grub just gets added to the report if it is invalid
[22:51] <cjwatson> how so?
[22:52] <cjwatson> EtcDefaultGrub should be added either way
[22:52] <cjwatson> InvalidGrubScript is a separate thing, largely intended for doing some kind of pre-reporting UI in the future
[22:54] <TheMuso> ev: How far along is the pygobject port? I am just wondering whether I should base my a11y work on that branch.
[22:54] <TheMuso> In the meantime, I'll use trunk
[23:34] <bdmurray> cjwatson:
[23:34] <bdmurray>         if not check_shell_syntax('/etc/default/grub'):
[23:34] <bdmurray>             invalid_grub_script.append('/etc/default/grub')
[23:34] <bdmurray> so its just adding without going through _attach_file_filtered right()?
[23:39] <cjwatson> no, that's preparing the value that goes into InvalidGrubScript, see above
[23:39] <cjwatson> entirely different key
[23:39] <cjwatson> EtcDefaultGrub is added before any of that stuff
[23:46] <bdmurray> I see its adding the string '/etc/default/grub' not the contents
[23:48] <cjwatson> yes, the (future) purpose of InvalidGrubScript is to display UI saying "these files are in an invalid syntax [list] so you probably stuffed it up locally" or some such
[23:48] <cjwatson> for now it's something we can scan bugs for
[23:49] <cjwatson> at least I assume that's the idea, I think jibel wrote it
[23:49] <cjwatson> and it's only in >= natty