=== nhandler_ is now known as nhandler [00:03] someone from ubuntu-release around? I want to ask if it's still enough time to start a OCaml "transition" (new upstream version) with FF only a week away. From a look at the (long) list of affected packages mostly only no-change rebuild will be necessary and only a few syncs. [00:04] (see bug #519199) [00:04] Launchpad bug 519199 in ocaml "Sync ocaml 3.11.2-1 (main) from Debian sid (main)" [Undecided,Triaged] https://launchpad.net/bugs/519199 [00:04] I would say it's possible; Then again, I am far from an expert on the topic :). [00:05] geser: yes, that's possible [00:06] slangasek: getting FF exceptions (when necessary) won't be a problem then? [00:06] shouldn't be, no [00:06] thanks [00:11] geser: If you need help, I'm happy to do so [00:13] StevenK: I'll certainly need sponsoring for the packages in main, thanks for the offer [00:24] geser: If it's just rebuilds I can do them, too [00:30] StevenK: mostly rebuilds as we have the same version as Debian testing/unstable. see the page from dmentre for the status and the rounds: http://bentobako.org/ubuntu-ocaml-status/transition_monitor/ocaml_transition_monitor.html [00:31] I guess dmentre will monitor it and announce when the next round can be started like he did during the last transition [00:35] hi [00:36] I'm looking to help by developing with ubuntu or related projects on my spare time. I chekced the wiki and it looks like I can start trying packaging and fixing bugs. Which sort of bugs would be best to start looking at? [00:36] arakthor: #ubuntu-motu might be a better starting point. [00:37] arand, thank you for the suggestion. the wiki seemed to say the motu was more appropriate for people with more packaging experience; however, I will look there. [00:41] arakthor: What sort of packages interest you? [00:42] arand: Why is -motu a better starting point? Does it not depend on people's interest? [00:45] hi persia, from my perspective I usually enjoy programming for low-level applications (on embedded platforms anyway - but I'm not an algorithm wizard). I also would like to learn more about security. I enjoy being able to see the changes from my code so desktop and utilities are probably my best starting point. [00:46] persia: just figured it a generally more active channel, and as a *startup* I though it would be more helpful, just as a channel... [00:46] arakthor: #ubuntu-desktop is the right channel for desktop stuff, and #ubuntu-hardened for security. We don't currently have much embedded stuff, although "embedded" is a funny term, and there's lots of Ubuntu that can run on very small hardware (as long as there's a couple gig flash). [00:47] most of my experience with embedded has been on hardware that cannot run ubuntu; usually with no OS or uCOS [00:47] Work on the low-level applications tends to happen here, but that's usually left to our most expert developers: I'd recommend working in other areas until you've gotten some experience with how we work. [00:48] arand: I guess I'm oversensitive: we used to force all new contributors to work with MOTU first, but now we're working on enabling interest-based groups to do stuff instead of forcing MOTU->core. As a result, I prefer to send people to channels that interest them, rather than pointing at MOTU who usually end up telling people to fix FTBFS or help with transitions and the like, which doesn't interest everyone. [00:49] arakthor: That's stuff we just can't handle :) [00:49] arakthor: There are ports to powerpc and armel though, some of which can run on devices some people consider "embedded". [00:50] yeah, not as hard anymore. I have maemo on my phone and that's rather nice in some ways. [00:50] and hardly "embedded" :) [00:50] slangasek: ping [00:51] well persia, thank you for the pointers. I will try to talk with somewhere there in the next day or two. have to go study now though. have a good night (or day; or morning) [00:52] arakthor: Good luck. [01:13] ev: https://code.edge.launchpad.net/~mbp/usb-creator/477529-cruzer/+merge/18311 please comment. [01:13] Fixes Are Good [01:39] bdmurray: I'm not exactly sure why bug #519119 hasn't been automatically marked as fixed [01:39] Launchpad bug 519119 in autofs "Transitional packages need some reworking" [Low,Triaged] https://launchpad.net/bugs/519119 [01:40] The fact that it got uploaded by zul doesn't seem to have been noted on the bug [01:40] That would happen if the .changes file didn't have the Launchpad-bugs-fixed: header. [01:40] Oh [01:41] So zul did something wrong when he built the package with my debdiff? [01:41] Last upload seems to be 14 weeks ago, according to https://launchpad.net/ubuntu/+source/autofs [01:42] Your patch appears to have the correct notation. [01:42] Hmm, ogra was pointing me at something yesterday that indicated two uploads [01:42] * Caesar consults rmadison [01:42] rmadison says it's at 5.0.4-3.1ubuntu4 [01:42] For binaries, but not for source. [01:42] * persia is confused [01:42] autofs5 | 5.0.4-3.1ubuntu4 | lucid | source, amd64, i386 [01:43] That says to me the whole box and dice [01:43] autofs vs autofs5 [01:43] the bug is against autofs, not autofs5 [01:43] Ah [01:43] It's all messy, the autofs5 source package is taking over some of the autofs(4) packages [01:43] Is the autofs source still needed with the presence of the autofs5 source? If not, it may be worth filing a removal bug. [01:44] Only some, or all? [01:44] No, it's no longer needed [01:44] So there are transition packages for all the binaries produced by autofs source? [01:44] Yes [01:44] There are now [01:44] Then yeah, file a removal bug :) [01:44] Will do [01:44] * persia can't ACK it, but maybe zul will [01:45] I'll just bump this bug over to autofs5 for anatomical correctness [01:45] But anyway, regarding the specifics of bug 519119 : ideally the bug task would have been changed to be against the autofs5 source if that was where it was being fixed. [01:45] Launchpad bug 519119 in autofs5 "Transitional packages need some reworking" [Low,Triaged] https://launchpad.net/bugs/519119 [01:46] And if that was done, then the bug should have been automatically closed by the upload. [01:46] Yeah I think I was a bit confused when I filed it [01:46] Okay, so I'll just mark the bug as fixed now? [01:46] No worries. Just mark it Fix Released manually, and note the package source and version that was uploaded to fix it. [01:46] Yes. [01:46] Done [01:47] Now to file the removal bug for autofs (source) [01:47] Any other questions about how this happened that I can answer, or was the above clear enough? [01:47] persia: no, that was all very helpful, thanks [01:47] Cool. [02:09] Does https://bugs.launchpad.net/ubuntu/+source/engine-pkcs11/+bug/512368 just need a sync request? [02:09] Ubuntu bug 512368 in engine-pkcs11 "Sync request: engine_pkcs11 0.1.8-2 from debian unstable (incoming)" [Wishlist,New] [02:09] It's fixed in Debian [02:11] Caesar: That *is* a sync request. [02:11] It's just waiting on an archive-admin to process it. [02:11] but no sponsors subscribed, just the archive admins [02:12] fabricesp doesn't count as a sponsor? [02:12] Oh, subscribed. [02:12] But he subscribed the archive-admins, so it oughtn't matter. [02:14] even with the status still at New? [02:14] Hrm. That's a good question. [02:15] StevenK: As a procedural matter, would an archive admin consider something actionable if the archive-admins were subscribed by a developer with upload permission to the affected package, but there wasnt an explicit ACK, and the bug state was "New"? === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [02:36] i have a question about kernel module [02:49] Am I mad? It looks like ubuntu-keyring STILL isn't using jetring [02:52] where can i check on the status of a kernel module? i want to see if a specific module is considered "stable" yet. === JFo is now known as JFo-afk [03:59] Can any GCC guru shed some light on https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/417009? [03:59] Ubuntu bug 417009 in openoffice.org "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic" [High,Confirmed] [04:00] I don't know enough about GCC's internals to understand if OpenOffice.org is goofing its test up or not, or theres a regressionin GCC === JamieBen1ett is now known as JamieBennett [04:37] Caesar: pong [05:28] slangasek: hi [05:29] I wanted to float the possibility of a import freeze exception for Puppet and Facter [05:31] Caesar: We have stopped automatic syncs, but manual syncs are still permitted until FF. [05:32] Unless we've changed it for Lucid. === dendro-afk is now known as dendrobates [05:38] anyone have info why the cryptsetup package inst upgraded to the 1.1.0? [05:38] its still using a release candidate for Lucid [05:38] the final has been released at http://code.google.com/p/cryptsetup/ [05:48] StevenK: ok thanks [06:40] Good morning === kenvandine_ is now known as kenvandine === tkamppeter_ is now known as tkamppeter === nenolod_ is now known as nenolod [08:11] good morning [09:11] pitti: is it expected that a jockey window pops up during a ubiquity installation? [09:11] (with an empty window) [09:13] pitti: http://people.canonical.com/~dholbach/Bildschirmfoto-QEMU.png [09:53] re [09:53] dholbach: I fixed that yesterday [09:53] dholbach: is that jockey 0.5.7? [09:53] pitti: it's yesterday's image, so yeah, it probably wasn't fixed back then [09:54] ah, *phew* :) [10:07] cjwatson: ping about some eucalyptus-udeb magic... [10:09] cjwatson: to support the case where there are multiple CCs (clusters) on a single network, spec says SC / NC should advertise which one (ideally by cluster name) they want to join [10:10] cjwatson: Ideally we would preseed eucalyptus/cluster-name in the SC or NC installs based on discovery [10:11] cjwatson: I'm just unsure how to best plug that into eucalyptus-udeb.postinst... At that point only the NC has a cluster selection, and it's IP address only. [10:16] * ttx wonders if multiple clusters on a single network really make any sense. [10:30] i'm starting a new package, trying to use bzr distributed development mode [10:30] how can i do what merge-upstream-release would do for the initial packaged release [10:30] james_w, ^? [10:31] it fails with : [10:31] bzr: ERROR: Unable to find the tag for the previous upstream version, 1.1.0, in the branch: upstream-1.1.0 [10:57] seb128: re: my seahorse-plugins upload: I did use bzr, and I did push my work to lp:ubuntu/seahorse-plugins [11:00] siretart:... [11:00] was that wrong? [11:00] siretart: apt-get source tell you what to use [11:00] or look to control [11:00] yes [11:00] it's under ubuntu-desktop with the debian dir only in bzr [11:00] oh, indeed. my bad, I'm sorry [11:01] siretart: np, I've fixed it yesterday since I had an another upload to do [11:01] hm. I generally dislike seperating debian/ from the upstream source. [11:02] in this case, it wouldn't have mattered since I didn't touch upstream code [11:02] so I was quite happy with the branch lp:ubuntu/seahorse-plugins [11:03] seb128: speaking of seahorse: do you know someone who could be bribed with an smartcard reader and a gpg smartcard to (finally) implement support for that in seahorse-agent? [11:04] siretart: not really [11:06] seb128: I notice that the seahorse-plugins packaging branch has a root directoy that contains only a subdirectory. can you explain my why not moving the contents of that subdirectoy one level up? [11:07] because that's how you use debian dir only with bzr-buildpackage [11:07] it will get the tarball and copy the debian dir over and build [11:08] bzr-buildpackage certainly doesn't require it [11:08] that's how we always did debian dir in vcs for gnome [11:08] since debian svn for pkg-gnome to current ubuntu-desktop workflow [11:09] nobody questionned it before ;-) [11:09] I'm questioning this practice since years [11:09] I find it handy to have the debian dir being named debian [11:09] for svn, it makes more sense because you have partial checkouts [11:09] rather than having ubuntu/ being the debian dir [11:09] well with current scheme you can cp debian over to a source [11:09] for bzr, I consider it utterly inconvenient and unnecessary [11:09] without having to mkdir debian [11:10] and cp ubuntu... [11:10] well, if the packaging was toplevel, you could just *checkout* in an upstream source directory [11:10] currently you have to clumsily fiddle around with cp/mv to have things in the right place [11:12] no you couldn't [11:12] since the directory is named ubuntu, not debian [11:12] I think I'll continue using the lp:ubuntu/$package branches and mail you the diff [11:12] you would get ubuntu with the debian dir content [11:12] of course you can: 'bzr get :~ubuntu-desktop/seahorse-plugins/ubuntu debian' [11:12] siretart: please don't, open a sponsoring request rather than private emailing me [11:12] of course you can: 'bzr get lp:~ubuntu-desktop/seahorse-plugins/ubuntu debian' [11:12] if you don't want to update the official bzr [11:13] that will create the branch in a subdirectory called 'debian' [11:13] is there something like svn-do for these branches? [11:13] Hi pitti, do you have a minute? Should the version of python-distutils-extra not be the same as the version of DistUtilsExtra.auto? [11:13] Laney, what does svn-do do again? [11:14] starts a subshell with the upstream source + debian dir [11:14] https://bugs.launchpad.net/ubuntu/+source/python-distutils-extra/+bug/520548 [11:14] Ubuntu bug 520548 in python-distutils-extra "DistUtilsExtra.auto.__version__ gives wrong version" [Undecided,New] [11:14] useful for doing patches, for exmaple [11:14] Laney, bzr bd-do [11:14] cool [11:14] seb128: opening sponsoring request? that sounds like an awful lot of burocracy and added latencies when I could also just upload it. this way my patch went into the official branch in hours (without attribution in the bzr log, but still) [11:15] siretart: not the official one [11:15] one which we are not using [11:15] Or does anybody else know the answer? [11:15] which break next upload since the official vcs is outdated [11:15] seb128: you can have those lp:ubuntu/xxx branches update to the ~ubuntu-desktop ones I think [11:15] to point to the^ [11:15] Laney: that is what I was using [11:15] Laney, we don't have a full source there [11:15] would that work too? [11:15] is that a requirement? [11:15] I don't know [11:15] james_w, ^ [11:16] siretart: you are just breaking other people package and workflow by doing that [11:16] it is a requirement [11:16] siretart: either update the official bzr or ask for sponsoring [11:17] I thought for UDD lp:ubuntu/$package was 'official' [11:18] I'll revisit the ubuntu wiki, need to run now, though. [11:18] Does anybody know who I should contact to not hide by default the menu items of the onscreen keyboard onboard that is part of the Ubuntu distribution? [11:18] siretart: dunno what is official or not but we don't use those for desktop components [11:19] see control file or apt-get source for the vcs to use [11:29] ttx: maybe the preseed file generated on the CC (debian/eucalyptus-udeb.finish-install) should set cluster-name to match the name of that cluster === frafu is now known as frafu_afk [11:29] cjwatson: that wouldn't solve it for the SC (which downloads from the CLC)... [11:30] ttx: it may well be a bug that SC installation doesn't do CC selection if it found more than one [11:30] cjwatson: I'm testing a fix right now [11:31] cjwatson: question: I'm using netboot for testing the latest crack, but apparently eucalyptus-udeb is downloaded before apt-setup/local0 takes effect [11:31] correct [11:31] apt-setup doesn't affect udeb installation anyway [11:31] apt => deb, anna => udeb [11:31] cjwatson: is there any way to preseed additional repositories in a way that would make it retrieve udebs from an alternate repo ? [11:33] I'm trying to netboot from my localmirror + a repo that has my eucalyptus WIP [11:33] ttx: you can't acquire udebs from more than one repo; the acquisition code isn't smart enough [11:33] you can change it to acquire from just a single repo [11:34] by setting mirror/http/hostname (and if necessary mirror/http/directory) on the kernel command line, I think [11:34] cjwatson: arh. [11:34] ttx: to fetch eucalyptus-udeb from somewhere else, I just use this trick: [11:35] d-i preseed/early_command string wget http://url/to/your/package && udpkg --unpack eucalyptus-udeb_whatever_whatever.udeb [11:35] and then boot with url=http://url/to/that/preseed.cfg [11:35] cjwatson: nice [11:35] I'll try that, thanks. === MacSlow is now known as MacSlow|pizza [11:57] Oh, we've dropped tracker by default? [11:57] I suppose this could be years ago. It's been a while since I've done a regular desktop install :=) [11:58] soren, since hardy [11:58] * soren chuckles [11:58] Ok :) [11:58] Did we replace it with something else? [11:59] no [11:59] Alright. [11:59] we decided that it was not useful enough to justify the io cost [11:59] linux is not good at handling io load nicely [11:59] * soren tends to agree [11:59] I was just curious to see that state of it and was surprised it wasn't installed. No worries at all. === MacSlow|pizza is now known as MacSlow [13:13] cjwatson: testing the early_command trick: I get "Menu item 'eucalyptus-udeb' selected" before 'download-installer', so eucalyptus-udeb.postinst fails with missing avahi lib [13:13] you might need to add in some manual wget/udpkg pairs for dependent udebs [13:13] bit of a hack [13:14] cjwatson: no way to run 'download-installer' module before 'eucalytpus-udeb' ? [13:15] dunno, sorry, can't think about this right now [13:15] cjwatson: no pb :) [13:15] don't see why udpkg --unpack would affect menu item ordering, you didn't change it to udpkg -i did you? [13:15] no... === jml is now known as jml-afk === jml-afk is now known as jml === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === _iron is now known as i_ron [14:17] cjwatson: fyi, looks like this works: early_command=anna net-retriever && wget eucalyptus-udeb... && && udpkg --unpack eucalyptus-udeb... [14:40] jdstrand: would be grand if you could do the udisks source NEW today; it's just an upstream product/source package renaming, not really a new thing [14:41] pitti: ack [14:43] jdstrand: thanks (just uploaded, should hit the queue in 2 mins) === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [14:45] k === JFo-afk is now known as JFo [14:59] Keybuk, around ? I'm wondering if you're expecting to address bug 504883 in near term. [14:59] Launchpad bug 504883 in udev "job with "mounted MOUNTPOINT=/ and net-device-up IFACE=eth0" blocks boot" [Medium,Triaged] https://launchpad.net/bugs/504883 [15:05] jdstrand: thanks, that was fast! [15:05] pitti: ask and ye shall receive :) [15:06] * persia watches for a wild flurry of requests [15:06] I want a pony! [15:07] actually, can I _give_ you a second of boot time? with getting rid of that, we'd be almost there :) [15:15] hehe [15:21] cjwatson: this grub-install issue is odd [15:22] so I press enter, and it prompts me what to do (including choose a different device) [15:22] I choose /dev/sda [15:22] it goes back, whirrs, and tells me that grub-install (hd0) failed again [15:26] smoser: bugs get addressed after FF [15:26] I have a bunch of updates before FF I want to do [15:26] then I'll fix bugs [15:26] because I'm sure my updates will cause lots of new bugs :p [15:26] (and may even fix that one anyway) [15:27] Keybuk, fair enough. my interest in this one is that when i then move cloud-init to running much earlier in the boot process, i'll likely have bugs myself. [15:27] so sooner rather than later would be nice [15:28] smoser: though I can't remember what solution to that one we decided [15:28] i think its a bug in udev and then those rules "should work", per slangasek [15:28] was that just the bug where the event went missing? [15:28] Keybuk: unfortunately my response to you is approximately the same as your response to smoser, because I have about three hours of work time left before FF :-/ === asac_ is now known as asac [15:28] cjwatson: that's fine ;) [15:29] Keybuk, right, missing event [15:29] cjwatson: obv it's critical for alpha 3 since you can't actually install right now ;) [15:29] but I can run grub-install by hand :p [15:29] Keybuk: I never did manage to reproduce your bug, but I only had a chance to try it through once in manual mode [15:29] Keybuk: manual mode worked fine for me ... [15:29] cjwatson: auto mode fails every time for me [15:29] even on a usb key with me being the chicken [15:30] oh, even auto mode with no preseeding? [15:30] right [15:30] *that* I can probably set up quickly [15:30] that's how I know it failed when I got to choose a different disk [15:30] I don't remember getting that choice with preseeding [15:30] though it could be related to using a USB key of course [15:30] my tests are in KVM with one disk, at the moment [15:30] superm1: around? [15:31] could be, though the automated stuff is NFS [15:31] hm [15:31] grub-installer shouldn't notice that [15:31] right === mathiaz_ is now known as mathiaz [16:12] ScottK: do you know where Lucas' rebuild test for foundations-lucid-supportable-binaries is? [16:12] ScottK: I'm sure I could do some quick analysis of it if that's what's required to unblock this spec [16:14] cjwatson: lucas just posted a new rebuild test : https://lists.ubuntu.com/archives/ubuntu-devel/2010-February/030230.html [16:15] cjwatson: From what I've heard (although this may not be complete), the idea is to try to get the number as low as possible, and then start filing removals later. [16:16] persia: thanks. we should prepare the method for getting the list in advance, though [16:16] because it isn't just Lucas' list; it's anything in Lucas' list that hasn't been otherwise rebuilt since karmic [16:17] cjwatson: Ah, so we need to compare against http://qa.ubuntuwire.com/multidistrotools/unchanged/unchanged_since_karmic [16:17] well, or the trivial python thing I have to do the same test [16:17] but sure [16:18] heh, that works too, but doesn't have a handy URL :) [16:19] LaserJock, what's up? [16:19] lp:~cjwatson/+junk/suite-diff [16:28] superm1: I just got bit by bug #506816 [16:28] Launchpad bug 506816 in dkms "wl missing after Karmic -> Lucid upgrade" [High,Confirmed] https://launchpad.net/bugs/506816 [16:29] LaserJock, cool! so hopefully you can help figure out the root cause :) [16:29] superm1: I saved the /var/lib/dkms/bcmwl directory and did the dpkg-reconfigure [16:30] superm1: what all do you need? [16:30] LaserJock, there is a make.log in there for the kernel that it didnt build on hopefully [16:30] superm1: the only kernel dir is for the Karmic kernel [16:31] superm1: I have a 5.10.91.9+bdcom dir and kernel-2.6.31-19-generic-i686 [16:32] LaserJock, ooh weird. [16:33] Could it potentially be that it built for the *running* kernel, rather than the newly installed kernel? [16:33] smoser: hey, you can use bzr dh_make from lp:bzr-builddeb or the upload I will be doing today [16:33] james_w, so heres what i did... tell me if i should bothe rwith dh_make [16:33] persia, i wouldnt suspect so at least, because the /etc/kernel/postinst.d scripts are called with the argument of the kernel to process [16:34] LaserJock, but it wouldnt hurt to run modinfo on the kernel module in that bcmwl directory to see if its built against the proper kernel [16:34] bzr init; mkdir debian; bzr add debian; (add some basic debian dir, with version 0.0) ; bzr add debian; bzr commit ; bzr tag upstream-0.0 -r 1; bzr merge-upstream [16:35] that seems to work with the only exception that i had to 'bzr resolve debian' === dendrobates is now known as dendro-afk [16:36] superm1: modinfo gives me: vermagic: 2.6.31-19-generic SMP mod_unload modversions 586 [16:36] slangasek: do we include plymouth in the initramfs? [16:37] tseliot: not unless we have to (cryptsetup) [16:38] slangasek: ok, so things should work without an initramfs, right? Provided that we have a framebuffer device and kms [16:38] LaserJock, well can you post the tgz of your /var/lib/dkms/bcmwl directory prior to dpkg-reconfigure'ing to the bug and this information so far from IRC. I dont have any other ideas off hand though unfortunately right now [16:39] slangasek: I mean by getting rid of the initramfs (not that I want to do that in Lucid but it may come in handy for oem) [16:40] slangasek was there a deliberation about whether it will be included in the casper case, or is that still up for discussion? [16:41] it should efinately stay in casper ... unless we speed it up a lot [16:41] i've currently got some tools that would be dependent upon that, but could possibly be refactored otherwise [16:42] ogra, well casper should be significantly faster thanks to JamieBennett's recent changes [16:42] not on arm though [16:43] he cut of a third from the bootptocess ... but thats not much with 1.5min [16:43] james_w, does the above look not ok ? [16:43] smoser: that works I guess [16:44] it gives you a slightly odd branch in that you will have two roots, but it's not illegal to have that [16:44] ogra, well I suppose perhaps the decision of whether or not plymouth is in the initramfs could also be arch dependent though, so x86 doesn't get it, but arm does [16:45] ogra, but what's the slowest piece now on arm? is there still a lot of room for improvement you think? [16:45] there likely is but not in lucid [16:45] plenty of x86 casper boots are still clearly slow enough to require a splash screen, and I don't anticipate that changing given typical CD read speeds [16:45] and indeed it could be based on arch detection [16:45] arch detection is a bit of a red herring there I think [16:46] you're right that it could, but I don't think it should [16:46] yeah, but technically you could do that [16:46] right [16:48] ogra, for lucid would ripping the extra scripts out that aren't used at all on arm help? Like moving the scripts that are say for UNE to a UNE casper package and those for KDE to a KDE casper package. I'm not sure how slow individual invocations of sh are though, so that might not do too much [16:49] no, there are more essential bits ... like locale-gen running at boottime [16:49] superm1: take a look at http://www.linuxuk.org/2010/02/ubuntu-live-cds-now-33-faster/ [16:49] has some bootcharts [16:50] given that we only run english by default and have no language selection on the image boot i'd vote for pregenerated en_GB/en_US for armel images, but that needs proper speccing and discussion, so nothing for lucid [16:51] ogra: But surely that's just because there's no gfxboot equivalent, no? [16:51] i'd think that would be useful across the board to have pregenerated english, and if other locales are chosen at language selection to generate them [16:51] persia, right [16:52] superm1, ++, lets have a spec at next UDS for that :) [16:52] superm1: as English speakers, I'm sure we both think that ;-) [16:52] hehe [16:52] ogra: superm1: agreed [16:52] but I always have to double-check my thinking every time that sort of thing crosses my mind [16:52] and I can never actually justify it to myself [16:52] * persia would think selecting the "top 5" locales would make more sense, perhaps following similar logic to that used to select langpacks to go on CDs, but can wait until May to be particularly interested [16:52] well, having them there and only generate additional langs surely doesnt do any harm [16:53] apart from costing a little space [16:54] 3MB for all English locales right now; although I'm not clear on why en_AG is so big [16:54] cjwatson, well if you try to look for the default case of what automatically times out if no selection is picked, and you try to optimize to that scenario at least. then you make a conscious decision that deviating the default scenario increases boot time [16:54] another issue we often have are broken board clocks that only are right after first boot .... fallout of that is that apt gets unhappy about the gpg keys somehow [16:54] for the pool dir on the image ... [16:54] superm1: and I think that goes against our commitment to give the best service we can to localised users; it seems like sloppy thinking to me, honestly [16:55] it's only justifiable if it's really a very tiny amount of space indeed, so perhaps just generating en_US.UTF-8 wouldn't be so bad [16:55] yeah [16:55] but otherwise we're crowding out other useful stuff that could go on the CD (including translations!) for the sake of making English faster [16:55] and indeed defaulting to that if no selection exists [16:56] * ogra would be happy with an arch specific hack for arm though [16:56] we have lots of space atm [16:56] $ du -cs /usr/lib/locale/en_US.utf8 [16:56] 1256 /usr/lib/locale/en_US.utf8 [16:56] that is not a trivial amount of space [16:56] dholbach: ping [16:57] ah, the reason that en_AG showed up as so big in my earlier test was hardlinks; all the English locales come out to about that size in isolation [16:57] ari-tczew: I was just about to head out [16:57] ari-tczew: how can I help? [16:58] dholbach: got a minute for sponsoring main? [16:58] basically I don't think we can justify an extra megabyte for live CD boot speed, at least not on x86. if you want to do that on armel then that's your business. :) [16:58] I have refreshed debdiff [16:58] ari-tczew: is this something nobody else can do? [16:59] dholbach: heh, doubt [16:59] ari-tczew: best to just ask in here [17:00] no need to block on me [17:00] dholbach: but there are not any active sponsors for main like for universe [17:01] ari-tczew: I'll see what I can do about it, but I really need to head out now [17:01] ok [17:01] ari-tczew: There are some, just not many. Just ask, and maybe someone will do it. [17:02] ok, so I'm looking for sponsoring @ bug 517297 bug 512430 [17:02] Launchpad bug 517297 in ttf-sil-scheherazade "Fake sync ttf-sil-scheherazade 1.001-6 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/517297 [17:02] Launchpad bug 512430 in geronimo-jta-1.0.1b-spec "Fake sync geronimo-jta-1.0.1b-spec 1.1-1 (main) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/512430 [17:08] ari-tczew: looking [17:08] ari-tczew: FWIW, you will get a better response if you say which things you want sponsored up-front, rather than starting with "anyone got a minute for sponsoring main" or similar [17:09] since then people know how much work they're signing up for [17:11] cjwatson, since the translations are kept within debconf for ubiquity, would that localegen stuff only be relevant for live mode, not --only mode? [17:12] superm1: yes and no, I suspect that some things will still be unhappy if setlocale() fails [17:12] superm1: but feel free to try it out obviously [17:13] Ok [17:14] certainly ubiquity is much less likely to have a problem; but remember that there are some failure modes in which ubiquity ends up falling through to gdm === deryck is now known as deryck[lunch] [17:14] That should be going away moreso with you adding a vesa fallback though, wont it? [17:15] not really [17:15] I'm talking about if ubiquity itself fails [17:15] but if that scenario is still a possibility, can always generate the locale "after" the fall through to gdm but before gdm gets started [17:15] sure [17:15] it's all soluble, just needs to not be forgotten [17:18] superm1: uploaded my bcmwl dir and added a comment, thanks [17:22] cjwatson: I quoted some of your good points regarding usb-modeswitch in my blog http://losca.blogspot.com/ [17:25] Mirv: you should discuss the quirks question with the kernel team; I was under the impression that updating that sort of thing might well be feasible [17:26] cjwatson: ok. next I was mostly thinking about asking usb-modeswitch developers if they'd rather like a more clear way for them to contribute the information they gather to both upstream and distribution kernels. [17:26] but yes, discussing with kernel team about it would be a good idea in the case of Ubuntu [17:27] I wouldn't be particularly surprised if the usb-modeswitch developers just plain like doing it in userspace [17:27] but different people are allowed to like different things ;-) [17:28] might be [17:28] tseliot: yes, even if we were shipping plymouth in the initramfs by default, we would still support initramfsless booting w/ splash [17:29] superm1: it's staying with casper, though we need some bits of casper fixed to talk to plymouth [17:33] Regarding usb mode quirks: please consider when looking at any solution that a single device may have interesting reasons to do multiple things. For instance, one may have a USB connection to a handheld and want to variously use it for storage, networking, audio, etc. over time. [17:37] the quirking in the kernel that I'm talking about doesn't prevent that [17:38] also, decent devices include a USB hub so that all the possible endpoints appear simultaneously [17:38] this mode-switching thing is AFAIK only done by ultra-cheap devices that want to force advertising on you by mass-storage; I've genuinely never seen it anywhere else [17:40] persia: or a wacom tablet with a pen and eraser and various other devices? [17:41]