[00:18] <virtuald> why does karmics vsftpd enable anonymous access by default?
[00:20] <lool> pitti: syncing > libipc-sharelite-perl -- no objection from me; NCommander, ogra: if you are tempted to check first whether the new upstream versions passes on armel...
[00:21] <NCommander> lool, it should have gotten synced automagicially
[00:21] <NCommander> lool, we were using build vs. ubuntu in the version string
[00:24] <lool> NCommander: libipc-sharelite-perl | 0.13-1ubuntu1 |        jaunty | source, amd64, i386
[00:24] <lool> NCommander: I don't think so
[00:25] <lool> NCommander: there was a sourceful change to disable the testsuite on armel
[00:25] <lool> or ignore it
[00:25] <NCommander> lool, I thought we did a buildX for that, or at least that was how we originally disabled it
[00:28] <lool> NCommander: So feel free to check the testsuite of the new version for Martin
[00:31] <NCommander> lool, still fails on rimu
[00:41] <dtchen> virtuald: i'm pretty sure that's not an ubuntu delta
[01:15] <cody-somerville> I'm experiencing a very very weird bug.
[01:15] <cody-somerville> Like, my xchat window is showing showing up as pidgin in my windows list
[01:16] <cody-somerville> and certain widgets (ie. applications menu and my system tray) don't seem to be getting drawn but work as expected if you click where you think they are
[01:18] <cody-somerville> damn compiz
[01:51] <TheMuso> pitti: sorry I thought dtchen had backported the hal/udev migration stuff for pulse, but he hasn't. As it is, its still somewhat broken regarding ACLs, so I think we wait till its totally fixed upstream before backporting.
[01:52] <dtchen> right, i haven't pushed that yet; i'm giving it a spin on a spare machine
[01:52] <dtchen> don't think it's quite ready for alpha 2 :-)
[01:54] <Hobbsee> Oh dear.  Whatever climbed out of the rubbish bin and the sewer pipes, and is now on u-d-d?
[01:55] <TheMuso> Hobbsee: heh
[01:55] <ajmitch> last week's leftovers
[01:56] <ajmitch> Hobbsee: tag thread, delete all tagged
[01:56] <ajmitch> you'll be grateful
[01:56] <Hobbsee> yeah, exactly
[01:56] <directhex> Hobbsee, looks like a perfectly normal, daily occurrence to me
[01:56] <TheMuso> Its at times like that I wish I used mutt's threading function, so I could just delete the thread.
[01:56] <ajmitch> directhex: because your life is perfectly normal & sane
[01:56] <Hobbsee> directhex: yeah, well
[01:57]  * Hobbsee applauds thunderbird's threading
[01:57] <directhex> ajmitch, gotta /earn/ my astroturfing fee!
[01:58] <directhex> in this economy, it's not just a given anymore
[02:04] <h6w> Where do I go for discussion of app development on ubuntu?
[02:04] <h6w> I'm specifically looking for people who do regular package management.
[02:05] <TheMuso> h6w: probably #ubuntu-motu is where you want to go.
[02:05] <h6w> ok, cool.  Cheers. :-)
[02:10] <Hobbsee> ajmitch: actually, i can do one step better than that.  server side sieve script added to.
[02:10] <ajmitch> now that's getting fancy
[02:10] <Hobbsee> if subject contains blah, drop
[02:11] <directhex> bedtime!
[02:11] <directhex> i wonder what flames tomorrow holds
[02:12] <ajmitch> warm, crispy ones
[04:50] <dtchen> slangasek: / bryce: your sound being muted on login is now fixed in karmic's pa
[05:29] <slangasek> dtchen: oh? pa was muting the mixer?
[05:37] <calc> ugh the OOo build is taking a lot longer than i expected, must have been too much churn to cache anything :\
[05:37] <nixternal> pitti: hey, I just spent the past hour looking over the apport interactive-hooks and I have gone ahead and added the Qt4 support for it. I pushed it to ~nixternal/apport/interactive-hooks - tested it with pmount successfully
[05:37]  * calc will look at it in the morning and see if it worked out
[05:37]  * calc heads off to bed :-\
[05:38] <nixternal> g'nite calc
[05:41] <ajmitch> nixternal: that was quick work
[05:45] <nixternal> ajmitch: the only way to work :)
[05:46] <ajmitch> what, with copious amounts of alcohol? yeah, I can believe that :)
[05:48] <nixternal> no alcohol, just Dr. Pepper :)
[05:49] <StevenK> Ewww
[05:49] <nixternal> no eww
[05:49] <StevenK> Yes ewww, Dr. Pepper is horrid
[05:49] <nixternal> no way, gotta love the plum flavor :)
[05:50]  * ajmitch needs more V
[05:50] <nixternal> heh, texlive update in karmic, version 2007 :p
[05:50] <nixternal> gotta love that tex
[05:50] <ajmitch> at least it's sometime this decade
[05:50] <StevenK> Unlike TeTeX
[06:29] <slangasek> calc: ummm, if there's that much churn, then is the OOo-l10n you're planning to upload appropriate for upload the Tuesday of a milestone?
[06:55] <calc> slangasek: churn in the libraries OOo uses that caused my build not to be sufficiently cached to build in the time i expected it to
[06:55] <calc> slangasek: wrt ccache
[06:55] <slangasek> calc: ok, but not extensive source changes :)
[06:56] <calc> slangasek: not much no
[06:56] <calc> gar still building even now :-\
[06:56]  * calc really goes to bed now
[06:56] <calc> looks like for whatever reason its going to take probably 5hr+ to do the test build
[06:56] <calc> normally a cached build takes < 2 hr
[07:02] <pitti> Good morning
[07:03] <StevenK> Morning pitti
[07:03] <Hobbsee> heya pitti!
[07:04] <al-maisan> moin pitti
[07:04] <pitti> Keybuk: dk-disks> indeed, I guess that's still a lot of "example" code there as well
[07:05] <pitti> nixternal: I guess you'd write a new .ui file for that? for the GTK choices dialog I added a new one to the glade as well, easier than to write it in Python
[07:07] <pitti> TheMuso: okay, thanks
[07:07] <pitti> lool: ok, so I don't sync it then; thanks for testing
[07:07] <pitti> nixternal: rock, thanks!
[07:10] <dholbach> good morning
[07:11] <al-maisan> moin dholbach
[07:11] <dholbach> hiya al-maisan!
[07:29] <dholbach> pitti: what do you think about bug 300895 and bug 300896?
[07:32] <dholbach> I stumbled over it when I had a look at bug 383570
[07:33] <dholbach> hola dmb!
[07:35] <dmb> hey
[07:42] <pitti> dholbach: no opinion; I don't know d-shlibs at all
[07:43] <dholbach> pitti: me neither
[07:43] <dholbach> james_w: ^ do you know what needs to be done there?
[08:16] <nixternal> pitti: no problem...I can do the qt stuff from now on if you would like, so just throw stuff my way if you want
[08:16]  * dholbach hugs nixternal
[08:16]  * nixternal hugs dholbach 
[08:16] <nixternal> good morning sir
[08:17] <pitti> hey nixternal
[08:17] <nixternal> pitti: I would have been done sooner, but I went storm chasing today in hopes of coming across a tornado :)
[08:17] <pitti> ugh
[08:17] <nixternal> hehe
[08:17]  * pitti gazes at the bright blue sky and nice sun outside
[08:17] <nixternal> I am fascinated by weather, yet so afraid of it at the same time :)
[08:18] <dholbach> sponsoring! sponsoring! sponsoring!
[08:19] <nixternal> I will probably do some of that today :)
[08:19] <dholbach> woohoo!
[08:25] <nixternal> dholbach: you might appreciate this...my buddy RJ, Ubuntu Chicago representing, made this music thing...here are some links
[08:25] <nixternal> http://static.ak.fbcdn.net/swf/mvp.swf?8%3A152716%3A1&v=223015705720&ev=0   <- demo
[08:25] <nixternal> http://www.facebook.com/v/223020915720  <- explanation
[08:26]  * dholbach not on facebook
[08:26] <nixternal> it is public
[08:26] <nixternal> I am not either, facebook is evil!
[08:26] <dholbach> that looks crazy :)
[08:27] <nixternal> heh, it is somewhat portable too...gonna have to bring that all Ubuntu Chicago events now
[08:31] <loic-m> nixternal: I saw a video of that a few years ago
[08:32] <loic-m> but it was more impressive - they had two people playing music on the table together
[08:32] <loic-m> and it was electro, but the music they acheived was impressive
[08:32] <nixternal> loic-m: yes, and that one, which is from the netherlands == closed source
[08:32] <nixternal> rj did it all open source
[08:33] <nixternal> he just started working on that thing the past couple of weeks of being home from school
[08:33] <loic-m> Like 70s-early eighties experimental electronic music that became great modern music in less than a minute ;)
[08:33] <loic-m> nixternal: the one i saw was open source, i checked at the time
[08:34] <loic-m> it's actually the same thing AFAIK, the video you link to use the same pictograms
[08:34] <loic-m> I downloaded the code, but without the table there wasn't much use fot it ;)
[08:35] <loic-m> about one or two years ago
[08:36] <nixternal> ya, this is designed after the reactable which isn't open source...watching videos on that now..the guy is good with the music
[08:36] <wgrant> ubuntu-devel-discuss seems to be getting a bit out of hand.
[08:37] <nixternal> ahh, the object recognition is open source
[08:37] <loic-m> http://mtg.upf.es/reactable/?software
[08:38] <loic-m> wgrant: sorry
[08:38] <nixternal> right, that is just the vision framework and object recognition...this stuff is groovy...the music this one guy is doing is insane
[08:39] <wgrant> loic-m: Huh?
[08:39] <loic-m> nixternal: blows Surface completely
[08:39] <loic-m> wgrant: for the OT
[08:39] <nixternal> hell ya it does
[08:39] <nixternal> heh, reminds me of old herbie hancock
[08:45] <dpm> pitti: good morning. I've got a couple of questions re: https://lists.ubuntu.com/archives/ubuntu-translators/2009-June/002517.html, when you've got a minute
[08:45] <dpm> * pitti: On the first issue, I think he is not describing a problem, but just noticing the difference between 'delta' and 'base' langpacks
[08:46] <dpm> * pitti: On the second question, howcome there is no Jaunty -base package in the PPA archive? (https://edge.launchpad.net/~ubuntu-langpack/+archive/ppa/+index?field.name_filter=es&field.status_filter=published&field.series_filter=jaunty)
[08:46] <dpm> * pitti: Finally, I can reproduce the problem with Firefox: using the latest PPA it appears untranslated. What's the best way to report this? As a bug against langpack-o-matic? Or against some other package and subscribe Language Pack Builders?
[08:46] <pitti> nixternal: apport-qt works wonderfully now. thanks!
[08:47] <pitti> dpm: will get back to you in a bit
[08:47] <dpm> pitti: thanks
[08:47] <dholbach> is anybody having trouble with sound in karmic atm? http://paste.ubuntu.com/191481 is what I get?
[08:51] <nixternal> pitti: no prob. just scream at me if you have anything else to do :)
[08:52] <nixternal> jeesh, u-d-a is insane..... Mark All As Read!
[08:52]  * nixternal is on his way to inbox 0
[08:53] <pitti> nixternal: u-d-d@, I hope?
[08:53] <nixternal> interesting, I had 111 emails in there just from the past half day
[08:53] <nixternal> ya
[08:53] <nixternal> err, not announce :)
[08:53] <pitti> *phew* :)
[08:53] <Hobbsee> nixternal: just filter it.  problem solved.
[08:56] <nixternal> ctrl+r in mutt calls my "read all" macro, so I am good :)
[09:02] <nixternal> heh, these people screaming "MONO!" are the some of the same people who have complained on the forums, mailing lists, and bug reports about Flash not working
[09:02] <nixternal> some of these*
[09:03] <nixternal> would be fun to have an aprils fools release that is nothing but free software, close down multiverse and restricted and see who complains then ;p
[09:03] <dholbach> nixternal: and remove all the patented code!
[09:04] <nixternal> that would be fun
[09:04] <nixternal> I like how I can install free software only from the disc...I tried it out and all of my machines worked like a charm...talk about luck
[09:06] <dholbach> I think I only need a stupid piece of firmware for my scanner
[09:06] <nixternal> I don't even need that..HP PSC 1610 all-in-one
[09:06] <nixternal> works out of the box
[09:06] <dholbach> but I got that from the stupid driver CD anyway
[09:06] <loic-m> dholbach> nixternal: and remove all the patented code! > like the Linux kernel :D
[09:06] <dholbach> nice
[09:07] <nixternal> throw in hurd
[09:07] <loic-m> probably half of it will be "infringing" other patents as well
[09:07] <pitti> nixternal: "#FIXME: Need to finish this up" -> is that an actual issue?
[09:07] <nixternal> heh, forgot to remove that
[09:08] <nixternal> tis what I get for working in vim...trying to get used to it
[09:08] <loic-m> The only way a piece of code isn't "infriging" on patents is if it's not successful. Let every hardware maker support ogg on their media players, and it will be facing patent threats as well
[09:08] <nixternal> I have become so reliable on eclipse for everything (10+ years with it probably)
[09:08] <dholbach> I'm sorry I started the patent discussion
[09:09] <dholbach> let's talk about sponsoring instead!
[09:09] <nixternal> lol
[09:09] <nixternal> SPONSORS! SPONSORS! SPONSORS!
[09:09] <nixternal> dholbach: you need to play with ajax and django! now that is fun stuff
[09:09] <dholbach> nixternal: I'm a very web0.5 person
[09:10] <dholbach> no idea about ajax
[09:10] <nixternal> >.< this close from having build logs almost real time w/o sitting on lp hitting refresh :)
[09:10] <dholbach> and just very little idea of django
[09:10] <nixternal> dholbach: so was I until yesterday :)
[09:10] <pitti> nixternal: ok, I delete that comment in the merge then
[09:10] <lifeless> nixternal: API's count as hitting refresh
[09:10] <nixternal> pitti: groovy
[09:10] <nixternal> lifeless: ya, but they are doing it, not me :)
[09:10] <pitti> nixternal: vim == ♥ ♥ ♥
[09:10] <nixternal> heh, I was strictly emacs and eclipse
[09:10] <nixternal> need an evim, then maybe I will be happy :)
[09:11]  * nixternal misses org mode
[09:13] <nixternal> alrighty, time for sleep, 03:12 is all I can do
[09:13] <nixternal> g'nite all!
[09:13] <loic-m> nite nixternal... or should it be good morning?
[09:14] <pitti> nixternal: you are clearly on the wrong side of the planet :)
[09:14] <dholbach> nightie nixternal
[09:16] <cjwatson> jpds: you don't seem to be adding debian/changelog entries for your changes to ubuntu-dev-tools - is that deliberate?
[09:21] <pitti> * NCommander is now known as ApportRetracerPortsCommander
[09:21] <pitti> seb128: ^ FYI, NCommander now manages the powerpc and armel retracers
[09:21] <ApportRetracerPo> Bah
[09:22] <ApportRetracerPo> Freenode has a max nick limit
[09:22] <seb128> pitti: good
[09:22] <pitti> NCommander: so feel free to set up a sparc one if you want :)
[09:23] <NCommander> pitti, when someone uses apport on SPARC, then I'll set one up
[09:23] <NCommander> and as I'm the only one to use apport on ia64, it would be oddly serve serving
[09:24] <pitti> NCommander: FYI, we have 3 need-sparc-retrace and 0 need-ia64-retrace
[09:24] <NCommander> we do?
[09:24] <pitti> one in hal, one in gnash, one in firefox
[09:24] <pitti> NCommander: you can't see them, they are only visible to the apport user
[09:25] <NCommander> Oh
[09:25] <NCommander> I did send that firefox one
[09:25] <directhex> i still need to look at apport support for mono apps
[09:25] <pitti> ugh, two gutsy, one hardy alpha-something
[09:25] <NCommander> I'm surprised I can't see them
[09:25] <directhex> anyway, minibus time
[09:25] <NCommander> pitti, the firefox one is still revelent :-/
[09:25] <NCommander> I can still trip that one easily on SPARC
[09:27] <NCommander> pitti, so when apport files a bug, what is it filed against so I can't see it even if I'm in bugsquad
[09:27] <pitti> NCommander: it's private, and only visible to reporter and apport
[09:29] <NCommander> pitti, maybe I'm loosing it, but I thought the bug supervisor could see private bugs filed against a project
[09:29] <pitti> NCommander: the triaging team can see the retraced ones
[09:29] <pitti> NCommander: since they usually have their coredumps deleted
[09:30] <NCommander> No, that i know, I'm in that group
[09:34] <NCommander> pitti, what I'm not getting is how you can have a bug against the Ubuntu distribution which isn't visible to the bug supervisor
[09:35] <jpds> cjwatson: Yes, will add them later.
[09:36] <jandem> hello, in a recent mailing list message the ubuntu-boot list was mentioned, but i can't find it?
[09:37] <dholbach> jandem: https://launchpad.net/~ubuntu-boot
[09:38] <siretart`> would it be possible to pulish the list via gmane?
[09:39] <jandem> thanks dholbach, (i looked at lists.ubuntu.com)
[09:39] <Hobbsee> NCommander: ubuntu-qa can see it.
[09:39] <Hobbsee> (or whatever they're called)
[09:40] <Hobbsee> not the one that just anyone can join
[09:41] <NCommander> Hobbsee, you can see the three bugs that are needs-space-retrace/
[09:41] <siretart`> Hobbsee: Is there something confidential discussed/published there?
[09:42] <lifeless> Hobbsee: do we have a membership-board meeting tonight?
[09:42] <Hobbsee> siretart`: I thought it was just a general question, so i'm not sure.  Perhaps i've missed some context while studying.
[09:42] <Hobbsee> lifeless: -ENOTELKBUNTU
[09:42] <siretart`> let's ask Keybuk
[09:43] <Hobbsee> NCommander: if i could find where they're listed, i'll check
[09:43] <lifeless> Hobbsee: I know you're not.
[09:43] <siretart`> Keybuk: could the ubuntu-boot list be published on gmane? - it seems that it is currently restricted to members of ubuntu-qa...
[09:43] <NCommander> Hobbsee, https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=need-sparc-retrace
[09:43] <lifeless> Hobbsee: I am <confused> apparently though.
[09:44] <Hobbsee> lifeless: okay?  *is now more confused*
[09:45] <Keybuk> siretart`: I don't see why not
[09:45] <Hobbsee> NCommander: hm, i can't see that.
[09:46] <NCommander> Hobbsee, yeah, but I can see the powerpc retracing bugs (and I saw them get processed watching apport's logs0
[09:46] <Hobbsee> NCommander: very strange
[09:46] <siretart`> Keybuk: since it does not look publicly subscribable (you need and lp account that is member of ubuntu-qa or some subteam), hooking up to gmane seems hard atm
[09:46] <pitti> cjwatson: does http://cdimage.ubuntu.com/daily-live/20090607/karmic-desktop-i386.manifest tell us that it doesn't use grub2 yet?
[09:47] <NCommander> Hobbsee, that's why I don't understand why I can't see them :-/
[09:47] <\sh> hmm...when does update-grub or better ucf create an menu.lst.ucf-dist in /var/run/grub ?
[09:47] <Keybuk> siretart`: you'd need to talk to an LP team guy about that
[09:48] <Hobbsee> lifeless: based on fridge, apparently you do have a meeting.  But i'm still not sure why you're asking me :)
[09:48] <lifeless> Hobbsee: yes, as I said I was confused :)
[09:48] <siretart`> Keybuk: since I don't think I have time to become active on ubuntu-boot, I'd rather not invest time in that. I would have lurked on the list if it was on gmane, though.
[09:52] <cjwatson> pitti: maybe it ought to be changed, but grub-pc is available as a .deb on the live CD as well and it will use that
[09:52] <cjwatson> \sh: ages
[09:52] <cjwatson> \sh: or do you not mean "since when"?
[09:52] <pitti> cjwatson: ah, ok
[09:53] <\sh> cjwatson: no..."when in the update-grub process does ucf creates an ucf-dist file for menu.lst"...reading update-grub it should only be named /var/run/grub/menu.lst with the kernel list fragment
[09:54] <cjwatson> \sh: it's created if you (explicitly or otherwise) chose something other than "install new version of this file"; it's analogous to .dpkg-dist for conffile
[09:54] <cjwatson> s
[09:56] <\sh> cjwatson: hmm...I install grub and install the kernel...then running update-grub (menu.lst in /boot/grub/ is copied from somewhere to this location during automatical installation) but update-grub doesn't update the kernel list fragment...and in /var/run/grub/ there is still the menu.lst.ucf-dist
[09:56] <cjwatson> \sh: why do you care? :-)
[09:56] <cjwatson> you're not supposed to care about the existence of .ucf-dist, really
[09:56] <\sh> cjwatson: because it's not updating the kernel list in /boot/grub/menu.lst and after my installation is finished I have a grub with no kernel list ;)
[09:57] <cjwatson> \sh: oh, well, maybe you answered "no, keep my own version" in the past and it remembered that
[09:57] <cjwatson> \sh: ask slangasek when he wakes up
[09:57] <\sh> cjwatson: actually I didn't say anything..because there is no debconf questioning during unattended FAI installation ;)
[09:57]  * cjwatson blames FAI
[09:58] <\sh> -EBUTDEBIANWORKS ;)
[09:58] <james_w> dholbach: they need to be fixed :-)
[09:59] <cjwatson> \sh: FSVO "works"; ucf management of menu.lst was introduced for a reason
[09:59] <dholbach> james_w: do you know how?
[09:59] <james_w> it's a small patch to the package
[09:59] <james_w> alternatively you can work around it in the package that uses it
[09:59] <cjwatson> \sh: anyway, slangasek should be able to help you recover, I'm afraid I can never quite keep the details straight
[09:59] <cjwatson> looking forward to not having to care about this stuff with grub2
[09:59] <james_w> the main issue is checking whether it applies to Debian
[10:00] <\sh> cjwatson: k...I'll poke slangasek thx anyways :)
[10:00] <directhex> pitti, how does pkg-create-dbgsym behave if a package already has a -dbg defined in control?
[10:05] <NCommander> ../linux/arm/syscallent.h:435:3: error: #error fix me - wow, that's not vague :-/
[10:06] <pitti> directhex: it just grabs the debug info without stripping it, so that the following -dbg package creation won't fail
[10:07] <pitti> directhex: I have about 3 test cases in pkg-create-dbgsym's test suite to make sure that this mostly works
[10:07] <pitti> directhex: does it fail for one of your packages?
[10:08] <hyperair> hmm ia32-libs is broken.
[10:08] <hyperair> at least, the pulse bits are.
[10:08] <hyperair> skype and flash no longer work with pulseaudio
[10:09] <directhex> pitti, i'm trying to add support for mono apps (mdb debug symbols), but picked a package with a -dbg as my test case ;)
[10:12] <directhex> oh. oops. non-arch-all is the opposite behaviour to what i want!
[10:12] <pitti> slangasek: oh, wrt. our UDS discussion about hotkey-setup, I don't need this ominous sleep setting here; no visible difference with hotkey-setup and without
[10:12] <jpds> cjwatson: debian/changelog entries added.
[10:18] <Keybuk> pitti: devkit-disks is spoiling my bootchart <g>
[10:25] <directhex> pitti, hm. can you think of a way for pkg-create-dbgsym to be callable more than once for the same package? that is, some apps (say, Banshee) contain both C libs and mono apps, so both dh_strip and dh_clistrip get called on them. how to deal with that scenario?
[10:28] <pitti> Keybuk: because of the additional udev rules?
[10:28] <pitti> Keybuk: perhaps we can walk through them and check which ones are redundant?
[10:28] <TheMuso> asac: you wanted to talk to me about bluetooth and pulse?
[10:28] <Keybuk> pitti: because of the sudden increase in calls to things like blkid
[10:28] <Keybuk> I think we're calling it 2-3 times per block device all of a sudden
[10:29] <pitti> directhex: I guess these two would not have much in common, since CLI debug symbols look entirely different?
[10:29] <pitti> directhex: so they shouldn't get into each other's way?
[10:29] <pitti> directhex: do you wan to call them -dbgsym?
[10:29] <asac> TheMuso: yeah ;)
[10:29] <Keybuk> pitti: I was expecting 0.3s for udev, and got 0.8
[10:29] <pitti> directhex: if so, then I'd suggest to just add it to pkg_create_dbgsym itself
[10:29] <directhex> pitti, well, i suppose that's a workaround isn't it - use a different package name for the mdb symbols
[10:30] <TheMuso> asac: in short, I don't know where things stand. I need to grab the needed pieces, put them together, and test locally. I got myself a bluetooth headset for this purpose.
[10:30] <asac> TheMuso: whats the status of the -sink/-source pieces?
[10:30] <asac> ajh ok
[10:30] <pitti> Keybuk: I guess dk-disks should not really need to call blkid, since udev does that by default already?
[10:30] <Keybuk> pitti: exactly
[10:31] <directhex> pitti, the problem is that dh_strip and dh_clistrip get called separately, so pkg_create_dbgsym gets called by both of those (or a replacement tool for the mono version gets called)
[10:31] <pitti> directhex: right, we shuold just integrate it there instead of having yet another package, IMHO
[10:31] <pitti> directhex: it's also much easier to write, I guess
[10:31]  * pitti reboots, brb
[10:31] <asac> TheMuso: do your tests with gnome-bluetooth and not bluez-gnome (which will go away)
[10:31] <TheMuso> asac: give me a day at most to get things tested, and I'll get back to you.
[10:32] <TheMuso> asac: I know about that.
[10:32] <asac> TheMuso: great. lets talk tomorrow then.
[10:38] <gpocentek> k
[10:38] <gpocentek> (sorry)
[10:38] <ogra> asac, help, my FF shows me cryptic fonts today
[10:40] <asac> ogra: #ubuntu+1 :-P
[10:40] <asac> ogra: just kidding
[10:40] <asac> ogra: what changed since yesterday?
[10:40] <ogra> nothing
[10:40] <ogra> i didnt upgrade or anything
[10:40] <Keybuk> ogra: mine's been doing that for weeks
[10:40] <asac> screen please
[10:41] <Keybuk> seems to do it after suspend
[10:42] <Keybuk> so I figured it was some kind of pango cache corruption or something
[10:42] <ogra> asac, http://people.ubuntu.com/~ogra/ff_fonts.png
[10:42] <ogra> Keybuk, i didnt suspend
[10:42] <Keybuk> ogra: interesting
[10:42] <ogra> i did absolutely nothign
[10:42] <Keybuk> ogra: your screenshot is exactly what I get too
[10:42] <pitti> meh, that reboot took a while; interesting bug in g-p-m
[10:42] <ogra> it just started out of the blue
[10:43] <asac> wow
[10:43] <ogra> i deliberately skipped updates the last two days
[10:43] <asac> ogra: what graphics driver/chipset?
[10:43] <ogra> intel
[10:43] <ogra> using KMS
[10:44] <ogra> 8086:2a02 ... GM965/GL960
[10:44] <ogra> i dont see the issue in other programs
[10:45] <ogra> and i noticed it gets slightly better if i switch to a windows encoding and andale mono
[10:45] <ogra> but i cant make it go away completely
[10:45] <asac> let me get my notebook up
[10:46] <RAOF> I see that too, but only sometimes.  It seems to occur (a) after long idle periods and (b) after resume from suspend.
[10:46] <asac> sounds like driver issue then
[10:46] <RAOF> Also KMS, intel, GM9something.
[10:46] <RAOF> I'd guess so.
[10:46] <ogra> but funny that only FF exposes it
[10:47] <ogra> evo, different terminals i tried, xchat etc all work fine
[10:48] <directhex> pitti, i think it might be best to use a different command, and a different -suffix, for the mono debug symbols. i can't think of a sensible way to overcome the problem caused by pkg_create_dbgsym being called by dh_strip then dh_clistrip (or the other way round), without risking problems. every invocation of pkg_create_dbgsym ends with a call to "dpkg --build", so i can't see how to make sure that --build gets called once only, w
[10:48] <directhex> ith both elf symbols and mdb files.
[10:48]  * ogra goes to make some coffee
[10:48] <asac> ogra: can you check if using firefox-3.5 makes any difference?
[10:48] <RAOF> That's what I was using.
[10:49] <ogra> is it in the archive already ?
[10:49] <RAOF> I seem to remember it affecting other apps, but not to the same extent as firefox.
[10:49] <asac> ogra: yes. since jaunty
[10:49]  * ogra installs
[10:50] <asac> ogra: install firefox-3.5 ... the menu entry is called "Shiretoko" and has the old blue planet thing as icon
[10:54] <cjwatson> jpds: thanks!
[10:55] <asac> ogra: do i need to do something to use KMS?
[10:56] <cjwatson> jpds: I have a rewrite of 404main here using python-apt, but it uses some fairly bleeding-edge methods that (AFAICS) weren't in jaunty. Do you think it's fair enough for ubuntu-dev-tools to Depends: python-apt (>= 0.7.9) for this? I'm thinking most developers will either be on karmic already or moving over in the not too distant future
[10:58] <ogra> asac, https://wiki.ubuntu.com/X/KernelModeSetting
[10:58] <jpds> cjwatson: Yeah, I think that would be fine (I don't think anyone wants to backport u-d-t anytime soon).
[10:58] <pitti> Keybuk: so dk-disks git head doesn't change any udev rules, FYI
[10:59] <asac> ogra: so i need to build the kernel on my own?
[10:59] <pitti> directhex: it could still be the same package (pkg-create-dbgsym)
[10:59] <pitti> directhex: and you just add another wrapper for dh_clistrip
[10:59] <ogra> asac, no, karmic should have all you need
[10:59] <ogra> asac, samme behavior with 3.5 btw
[10:59] <asac> ogra: so i get that without doing anything?
[11:00] <asac> ogra: upgrading now. think last upgrade was 1 week ago or so
[11:00] <ogra> asac, create /etc/modprobe.d/i915-kms.conf, add "options i915 modeset=1"
[11:00] <cjwatson> jpds: ok, cool. committed
[11:01] <Keybuk> pitti: I didn't quite get why it has most of the ones it has
[11:01] <ogra> (and i would guess you need update-unutramfs -u thougth the wiki doesnt say that)
[11:01] <Keybuk> since udev now ships upstream rules, it can rely on them being there
[11:01] <Keybuk> even the mdadm/devmapper ones are in udev's tarball now
[11:01] <asac> ogra: ok will check after upgrade finishes
[11:01] <directhex> pitti, right. i assumed that was the best approach anyway, hence "ii  pkg-create-dbgsym                             0.26+dhx1                                     automatically build debug symbol ddeb packages"
[11:01] <directhex> pitti, so... any preferences? "-mdbsym"?
[11:01] <pitti> directhex: sounds fine :)
[11:02] <ogra> pitti, hal-storage-mount segfaults for unpartitioned (but formatted) usb keys, known bug ?
[11:02] <ogra> [344310.055062] sd 10:0:0:0: [sdb] Assuming drive cache: write through
[11:02] <ogra> [344310.055070]  sdb:
[11:02] <ogra> [344310.058098] sd 10:0:0:0: [sdb] Attached SCSI removable disk
[11:02] <ogra> [344311.862949] hal-storage-mou[23765]: segfault at 0 ip 0804a9ea sp bf985980 error 4 in hal-storage-mount[8048000+7000]
[11:03] <pitti> ogra: not known to me
[11:03] <pitti> ogra: but pretty uninteresting now, that we don't use hal for mounting any more
[11:03] <ogra> ogra@osiris:~$ sudo mount /dev/sdb /mnt/
[11:03] <ogra> ogra@osiris:~$ mount |grep sdb
[11:03] <ogra> /dev/sdb on /mnt type vfat (rw)
[11:03] <ogra> ok ..
[11:03] <pitti> Keybuk: eww, most of those look very familiar to what udev is doing anyway, indeed
[11:05] <pitti> Keybuk: I think the only real thing it adds is devkit-disks-probe-ata-smart
[11:05] <Keybuk> what does that do?
[11:06] <Keybuk> the smart values?
[11:06] <ogra> asac, OH ! i just notice that some tabs have proper fonts with 3.5
[11:06] <ogra> well, or at least a lot less errors
[11:06] <ogra> there still are some
[11:06] <pitti> Keybuk: just DKD_ATA_SMART_IS_AVAILABLE=1
[11:07] <pitti> Keybuk: not the actual values (they are read on demand by dk-disks daemon, when someone requests them over d-bus I guess)
[11:07] <pitti> Keybuk: I'm not sure what the ID_DRIVE_FLASH_{MS,SM,SD,CF} stuff is about
[11:08]  * asac reboots with kms
[11:16] <asac> ogra: dont see it ... even after resume. will keep my eyes open ;)
[11:16] <asac> ogra: curious: does pango-view -t "Test TEXT ... (make it longer)" --backend=cairo
[11:16] <asac> show the same problem?
[11:16] <ogra> i dont think its actually KMS i would expect to see it in any other apps too if it were a driver prob
[11:17] <ogra> nope, looks fine
[11:17] <asac> ogra: nah. ffox really uses cairo heavily ... so you will see driver issues in ffox you dont see elsewhere
[11:17] <asac> not saying its not a ffox bug. but the symptoms look really driver related
[11:18] <ogra> well, FF is the only thing exposing it (yet) ...
[11:18] <ogra> i dont say its a FF bug but i only see it with FF :)
[11:18] <asac> ogra: yeah. so can you confirm that this starts after resume? and after clean boot it works?
[11:19] <asac> (like what RAOF observed)
[11:19]  * ogra reboots
[11:21] <pitti> asac: KMS working well for you?
[11:22] <asac> pitti: not 100% if its running. i added the modprobe.d thing mentioned by ogra
[11:22] <asac> so far things work more or less well
[11:22] <asac> even compiz is on again ;)
[11:22] <pitti> asac: that's necessary to enable it in the first place
[11:22] <pitti> asac: tried suspend/resume?
[11:22] <asac> pitti: how can i check that i am using KMS?
[11:22] <pitti> asac: ctrl+alt+f1
[11:22] <pitti> if that's blazingly fast and you get a nice big VT, it's working
[11:23] <pitti> asac: and check suspend/resume, and if it comes back even faster than you can open the lid, it's working :)
[11:23] <asac> pitti: yeah so i am running it
[11:23] <ogra> asac, hrm, its gone after reboot
[11:23] <asac> and i already have one suspend/resume done after this boot
[11:23] <asac> let me do another
[11:23] <asac> ogra: thats what RAOF said. now suspend/resume ... if its coming back its 99.99% drier issue
[11:23] <pitti> unfortunately suspend is broken for me right now with current xorg-edgers PPA :/
[11:24] <asac> ok i do a three suspend resumes now ;)
[11:25] <ogra> hmm, not coming back it seems
[11:25] <asac>  ;)
[11:25] <mpt> Does anyone know what's happening with the video recordings from UDS?
[11:25] <asac> yeah. so i suspended a few times and it still works here
[11:26] <ogra> same here
[11:26] <ogra> weird
[11:27] <mpt> jcastro, do you know?
[11:44] <soren> mpt: I imagine they'll end up on http://video.ubuntu.com/ eventually.
[11:46] <cjwatson> I'm interested in the audio recordings too ...
[11:49] <soren> cjwatson: There were audio recordings?
[11:50] <soren> I though we only streamed the audio.
[11:53] <cjwatson> soren: I don't know
[12:00] <directhex> dpkg-deb: building package `libmono-microsoft-visualbasic8.0-cil-dbgsym' in `../libmono-microsoft-visualbasic8.0-cil-mdbsym_2.4-1_all.ddeb'.
[12:02] <geser> directhex: your pkg_create_dbgsym script is buggy, it creates wrong filenames :)
[12:02] <directhex> geser, howso?
[12:03] <geser> -mdbsym != -dbgsym
[12:03] <directhex> geser, indeed
[12:03] <hyperair> but all the debug symbols are .mdb files anyway
[12:03] <directhex> geser, it's the easiest workaround to the problem of packages containing both elf debug symbols, and mdb debug symbols, which would end up stripped twice
[12:03] <pochu> why not put everything in a single package?
[12:04] <directhex> pochu, i'd love to
[12:17] <maxb> There appears to be something broken with the kernel in jaunty-proposed. Launchpad says linux 2.6.28-13.44 was published into jaunty-proposed 7 days ago, but the actual binaries published to the Packages file are still ABI 12.
[12:19] <cjwatson> maxb: binary NEW, I started processing last night but had to fall asleep
[12:19] <cjwatson> I'll sort it out now
[12:19] <maxb> oh!
[12:20]  * maxb was confused that linux-meta abi 13 was in
[12:21] <cjwatson> it probably oughtn't to have been processed
[12:21] <cjwatson> anyway
[12:40] <cjwatson> mvo: I attempted to add support for update to rapt (lp:~cjwatson/rapt/update), but it's currently segfaulting and it looks like something inside apt/python-apt. Could you have a look if you get a minute?
[12:43] <mvo> cjwatson: sure
[12:43] <mvo> cjwatson: I merge and check
[12:43] <cjwatson> mvo: http://paste.ubuntu.com/191589/ is the traceback if that's any use
[12:44] <ion_> Ooo, rapt looks nice.
[12:45] <cjwatson> valgrind says "Access not within mapped region at address 0xFED8E900"
[12:45] <lifeless> mvo: https://edge.launchpad.net/rapt might like to turn on 'uses lp for development'
[12:46] <mvo> cjwatson: its doing improper type checking for the progress object :/
[12:46] <cjwatson> oh, did I give it the wrong thing?
[12:46] <ion_> Oh, wait. A different rapt. I was looking at http://www.steve.org.uk/Software/rapt/
[12:46] <\sh> hmm...which package adds the %admin group to /etc/sudoers?
[12:47] <mvo> cjwatson: yes, a TextFetchProgress will work
[12:47] <cjwatson> ah yes, just tried that :)
[12:47] <mvo> cjwatson: IIRC this is partly fixed in python-apt bzr
[12:48]  * cjwatson pushes a better version
[12:48] <ion_> Was it today or tomorrow when liw returns from his vacation?
[12:48] <mvo> lifeless: good point, added
[12:48] <liw> ion_, I'm back
[12:48] <ion_> liw: :-)
[12:48] <ion_> liw: I added some rambling to the end of https://wiki.ubuntu.com/AptSyncInKarmicSpec
[12:49] <liw> ion_, cool; I'll get to it eventually, I'm digging myself out of a ton of e-mail and stuff, but I'll get to it!
[12:49] <cjwatson> mvo: seems to work nicely now
[12:50] <ion_> liw: Aye
[12:50] <mvo> cjwatson: excellent, I will merge (and/or I can add you to be rapt-hackers if you want)
[12:51] <cjwatson> I've probably scratched my itch adequately now :-)
[12:51] <mvo> :)
[12:51] <cjwatson> do the DC porter boxes auto-upgrade rapt or do we need an RT ticket?
[12:53] <elmo> you need an RT ticket; since rapt isn't available for all the chroots we have
[12:59] <cjwatson> ok
[13:00] <directhex> pitti, okay, assuming we overlook the 2-debug-packages-for-some-apps issue, i have a working implementation for packaging up mono debug symbols. there are therefore 3 issues: 1) most apps/libs will need patching to actually produce debug symbols properly (many miss the creation of, or "make install"ing of .mdb files) 2) do we care about -mdbsym versus -dbgsym? it's messy, but is it a problem? 3) it doesn't work for mono itself, as
[13:00] <directhex>  mono uses a local copy of debian/dh_clistrip for some reason
[13:02] <cjwatson> mvo: hmm, don't merge that yet, I broke the blacklist stuff
[13:03] <cjwatson> (fixed)
[13:07] <cjwatson> maxb: accepted, belatedly
[13:09] <seb128> directhex: there is not so many applications using it right now, we can patch the build for the few which are shipped by default or interesting
[13:10] <directhex> seb128, right. i doubt it's a priority issue until debian stops sucking & gains something like pkg-create-dbgsym. but it's certainly worth fixing ad-hoc
[13:10] <directhex> seb128, and the other two points?
[13:10] <Brucevdk> Hey dholbach, I saw you were listed as an author for the IndustrialTango theme. I'm having some issues with the border theme when using Compiz as the window manager instead of Metacity (the window icon doesn't work). IndustrialTango seems to be the only theme with issues. Mind if we talk about it here? Maybe there's a more relevant channel, or pm?
[13:10] <seb128> 3 seems easy to patch or figure why it's using a copy
[13:10] <directhex> also, seems i need to rebase against the latest version of it, since i was using jaunty's version as a base :/
[13:10] <seb128> 2 doesn't seem a real issue to me
[13:10] <dholbach> Brucevdk: I just packaged it
[13:10] <dholbach> Brucevdk: ... ages ago
[13:11] <Brucevdk> dholbach: hmm looks like I'm going to have to talk to jdub then
[13:11] <dholbach> Brucevdk: is there an AUTHORS file?
[13:11] <Brucevdk> dholbach: yeah I was looking at the wrong authors file, the one from the package
[13:11] <directhex> seb128, the "why" appears to be "because it doesn't build-depend on cli-common-dev"
[13:11] <directhex> seb128, now, that introduces a NEW question :)
[13:12] <Brucevdk> dholbach: you were on IRC, hence, me showing up here ;-)
[13:12] <dholbach> :)
[13:12] <Brucevdk> anyho, I'll try and get in touch with jdub, meanwhile rock on ;-)
[13:12] <dholbach> you too!
[13:30] <pitti> directhex: well, what's your actual goal with -mdbsym?
[13:30] <pitti> directhex: e. g. we don't have a sensible mono<->apport integration yet (there's a blueprint, but nothing implemented)
[13:32] <directhex> pitti, 2 goals. some apps ship with he mdb files (which wastes space), or just throw away the symbols (which is a waste) or have manually written -dbg (which is a PITA to maintain). it provides a sensible way to store debug symbols for things
[13:32] <directhex> pitti, longer term, i want that apport integration
[13:32] <pitti> directhex: so for purely manual installation, producing -mdbsym sounds just fine
[13:33] <pitti> directhex: longer-term, I think it'd make sense to integrate it into dh_strip, or at least unify pkg-create-dbgsym to hook into both and then produce -dbgsym in whichever comes first, and for both gdb and mdb
[13:35] <directhex> pitti, my problem with visualising that has been how to deal with dh_strip and dh_clistrip given different parameters - you only know which parameters both have received on the SECOND call (if there is a second call), not first
[13:35] <pitti> directhex: ah, true that
[13:36] <directhex> pitti, at any rate, what i have so far is at http://paste.debian.net/38477/
[13:37] <pitti> directhex: any chance you could add a test case?
[13:39] <directhex> pitti, sure, let's take a look at this.........
[13:50] <directhex> pitti, aha, test case caught a bug ;)
[14:36] <jcastro> mpt: IS has them, afaik they get shipped someplace to be edited.
[14:40] <mpt> thanks Jorge
[14:43] <directhex> dpkg-deb: building package `dhtest2-dbgsym' in `../dhtest2-mdbsym_2.3-1_all.ddeb'.
[14:43] <directhex> hm. spot the deliberate error!
[14:48] <pitti> directhex: the general framework expects -dbgsym?
[14:49] <directhex> pitti, i just forgot some search/replace in pkg_create_mdbsym
[14:50] <pitti> directhex: test suites FTW! :-)
[14:50] <directhex> okay, that's a functional pure-c# test case. now for a mixed-mode test
[15:09] <Keybuk> holy crap
[15:09] <Keybuk> Fedora don't even get their mirrors in sync before release
[15:10] <Chipzz> oh noes!
[15:10] <Chipzz> ;)
[15:10] <directhex> PASS: mdbsym ddeb for dhtest1_2.3-1_all.deb exists
[15:10] <directhex> PASS: unpacked/usr/lib/crash/crash.exe has .mdb file
[15:13] <Keybuk> Chipzz: it's important ;) have to find out how fast F11 boots in the end
[15:17] <squirrelpimp> hi, when will packages.ubuntu.com be available again?
[15:20] <Ng> squirrelpimp: now :)
[15:20] <squirrelpimp> k
[15:20] <squirrelpimp> :)
[15:20] <squirrelpimp> thanks
[15:40] <lool> Could someone who uses ecryptfs somewhere tell me whether Mutt still works when emails are backed by an ecryptfs mount?  In my case the builtin pager causes the process to be killed
[15:44] <stgraber> pitti: thanks for your comments, I updated the MIR accordingly
[15:45] <pitti> stgraber: ah, thanks
[16:14] <pitti> stgraber: can you please set the bug status back to New?
[16:15] <stgraber> pitti: sure
[16:16] <stgraber> pitti: hmm, it already is
[16:16] <pitti> stgraber: ah, got bug mail, thnaks
[16:33] <bryce> dtchen: excellent
[16:35] <directhex> pitti, i'm sending a message to mono upstream to get their thoughts on how to hook apport into mono. is there anywhere I should suggest they talk to smart apport people, like an IRC channel or mailing list?
[16:37] <pitti> directhex: the apport project in LP has a ML, but TBH I haven't quite figured out yet how it works
[16:37] <pitti> directhex: for now, mailing me is fine
[16:38] <pitti> directhex: ah, try  apport-hackers@lists.launchpad.net
[16:42] <directhex> okay, mailed mono-devel. let's see how flamed i get
[16:44] <LaserJock> cjwatson: regarding gcompris, don't we need the gnet dependency in order for it to actually get moved into Main?
[16:45] <LaserJock> directhex: I suppose you're used to that by now ;-)
[16:45] <cjwatson> LaserJock: I sent a mail to mantha@u.c about that but it bounced ...
[16:45] <cjwatson> LaserJock: does that address not work any more?
[16:45] <LaserJock> cjwatson: it's laserjock@
[16:45] <cjwatson> LaserJock: ah, how about I bounce it to you
[16:45] <cjwatson> LaserJock: (and no, we don't need it immediately, it's OK to say "gcompris will build-depend on this as soon as it's in main)
[16:46] <cjwatson> +"
[16:46] <directhex> LaserJock, i start to feel cold & uneasy without some nice warming flames every day
[16:46] <LaserJock> directhex: heh
[16:47] <LaserJock> I think directhex should get the "Flame-retardant underwear of the year" award
[16:47] <directhex> LaserJock, Riddell provided a Qt t-shirt, does that count?
[16:47] <LaserJock> cjwatson: the gnet MIR has already been approved
[16:48] <LaserJock> directhex: perhaps, though some might consider it an accelerant
[16:48] <cjwatson> LaserJock: oh, it has?
[16:49] <cjwatson> LaserJock: it used to be in main but was demoted
[16:49] <cjwatson> I see nothing current on gnet's bug page
[16:49] <LaserJock> cjwatson: piti approved it ~ 4 days ago
[16:49] <directhex> i wonder if the mono t-shirt met sabdfl's minimum softness requirements
[16:49] <cjwatson> oh, meh, it looks as if it was promoted but then (auto-)re-demoted
[16:49] <LaserJock> cjwatson: bug #383948
[16:50] <cjwatson> yeah, I see it
[16:50] <cjwatson> ok, I'll fix up the overrides and reupload, thanks
[16:50] <LaserJock> oh, so it was auto demoted because nothing depended on it?
[16:50] <cjwatson> well, "auto"
[16:50] <cjwatson> as in an archive admin saw it on the "can be demoted" list and did it
[16:50] <cjwatson> LaserJock: BTW you also didn't talk to the most recent uploader listed on merges.u.c/main.html when working on the merge ;-)
[16:51] <cjwatson> or at least if you did I forgot ...
[16:51] <cjwatson> LaserJock: actually, perhaps you could upload gcompris with the gnet build-dep put back, so that somebody more appropriate ends up marked as touched-it-last?
[16:52] <cjwatson> I've promoted gnet again now
[16:52] <LaserJock> cjwatson: I hadn't actually worked on the merge and I didn't think a rebuild counted as "last uploader"
[16:52] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/gnet/+bug/383948 "I'm working on merging gcompris from Debian"
[16:53] <cjwatson> it does for the purposes of merges.u.c (unfortunately)
[16:54] <LaserJock> cjwatson: well, thanks for the merge in any case
[16:55] <LaserJock> cjwatson: I was just looking through the new upstream when I saw you'd uploaded it
[16:55] <LaserJock> cjwatson: I'll add gnet back in and upload
[16:57] <asac> TheMuso: any idea if libatk-bridge.so will move to dbus at some point (i think it uses corba atm)
[17:04] <cjwatson> LaserJock: ta
[17:32] <slangasek> \sh: manually tweak something in your automanaged kernel block; then adjust one of the magic variables; then run update-grub and you should get re-prompted.
[17:32] <slangasek> pitti: "ominous sleep setting" == "DOS"?
[17:32] <slangasek> I still need to talk to mjg59 about that, I think, to figure out why it was ever added
[17:33] <pitti> slangasek: the remaining bit in hotkey-setup's init script
[17:33] <slangasek> yep
[17:44] <LaserJock> cjwatson: would you have any opinion on if we should add a patch system or something to gcompris?
[17:45] <cjwatson> LaserJock: my opinion is that we should never add patch systems in Ubuntu when they are not present in Debian
[17:45] <LaserJock> cjwatson: would maintaining it in bzr help?
[17:45] <cjwatson> in the specific case of gcompris it seems too simple to be necessary; in fact it was *easier* to deal with the merge without a patch system
[17:46] <cjwatson> LaserJock: we'll get an import into bzr soon enough, along with the rest of the automatic imports ...
[17:46] <LaserJock> cjwatson: k
[17:49] <AnAnt> Hello, a question about grub2, will gfxmode be 640x480 in Ubuntu ?
[17:50] <AnAnt> let me rephrase the question please,
[17:50] <AnAnt> will there be a way to determine the current gfxmode resolution ?
[17:51] <cjwatson> from where?
[17:51] <AnAnt> cjwatson: grub2
[17:51] <ion_> /etc/grub.d/00_header:if [ "x${GRUB_GFXMODE}" = "x" ] ; then GRUB_GFXMODE=640x480 ; fi
[17:51] <cjwatson> it's a variable in grub2
[17:51] <cjwatson> the 'gfxmode' variable, specifically
[17:52] <AnAnt> ok, there is a /etc/grub.d/05_debian_theme currently
[17:52] <AnAnt> will that be replaced with a 05_ubuntu_theme ?
[17:52] <cjwatson> dunno, maybe :)
[17:53] <cjwatson> we've largely just dropped in the Debian package with some basic branding for the moment
[17:53] <cjwatson> theming is not a high priority since for the default case we'd prefer the menu not to be displayed
[17:53] <cjwatson> but we're not opposed to it
[17:53] <AnAnt> ok
[17:54] <AnAnt> any news about wether plymouth will replace usplash ?
[17:55] <ion_> Early Xorg will basically replace usplash AFAIU. Usplash will only be shown with fsck or equivalent.
[17:56] <cjwatson> plymouth isn't going to replace usplash, no
[17:56] <AnAnt> ok, thanks
[17:56] <AnAnt> ok, finally will the new GDM be used in Karmic ?
[17:57] <AnAnt> I heard that there is a new GDM that doesn't support the old GDM themes
[18:00] <sladen> I hear lots of things.  I heard a boat just go past, and birds twittering and in the distance I can hear cars too.
[18:00] <AnAnt> sladen: you like birds ?
[18:05] <cjwatson> AnAnt: https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus says yes
[18:07] <seb128> AnAnt: the new gdm is a background and a gtk dialog
[18:43] <slangasek> calc: are you going to have time to get bug #201114 fixed for hardy, or should I have a look at it myself?
[18:43] <slangasek> calc: in time for 8.04.3, I mean (which means getting it uploaded in the next week or so)
[18:52] <nixternal> pitti: heh, comments on my blog about "I can has bug report" and someone trying to fix the grammar :)
[18:53] <pitti> nixternal: they didn't get the joke? :-)
[18:55] <ion_> :-D
[18:57] <LaserJock> is there a lolcat translation team on LP?
[18:57] <LaserJock> if we've got klingon surely there should be lolcat
[18:57] <nixternal> I think they would have if it was s/has/haz/ maybe
[18:57] <tkamppeter> pitti, hi
[18:58] <slangasek> I has canned bug reports
[19:00] <pitti> hi tkamppeter
[19:00] <pitti> LaserJock: nuQneH?
[19:01]  * pitti remembers writing http://martin.piware.de/trek/pIqaD.txt and other stuff, from the times when I apparently had too much time
[19:01] <slangasek> heh
[19:02] <slangasek> does anyone have the spec for "refactor package management UI" handy?
[19:02] <directhex> i missed the UDS session. did lpia get the axe?
[19:02] <LaserJock> slangasek: https://wiki.ubuntu.com/AppCenter ?
[19:03] <slangasek> LaserJock: ta
[19:03] <tkamppeter> pitti, I will do the needed steps to get the Poppler-based pdftops filter into CUPS now. Users report in all related bug reports that their problems get solved.
[19:03] <slangasek> hmm, interesting, AppCenter doesn't mention replacing software-sources-gtk
[19:03] <tkamppeter> One question to master bug 382379
[19:03] <slangasek> er, software-properties-gtk
[19:04] <slangasek> mpt: ^^ do you have any designs on AppCenter superseding software-properties-gtk, or is that expected to stay the same?
[19:04] <ion_> “tlh- ke[ttle], air forced between tongue sides” The English education in Finnish basic schools generally sucks; incidentally they *never* even mentioned that the t kettle is pronounced any differently than the t in talk. I’ve only realized it basically by watching a lot of American TV-shows.
[19:05] <tkamppeter> Should I make all cited bugs duplicate of this bug or should I put all the individual bug numbers into the debian/changelog of my next CUPS update?
[19:05] <pitti> tkamppeter: great, thanks
[19:05] <pitti> tkamppeter: do duplicates, that's better for getting testing feedback, I think
[19:05] <slangasek> ion_: American, or British?  we don't pronounce kettle the same ;)
[19:05] <ion_> American
[19:06] <ion_> I think :-P
[19:07] <pitti> it's the effect that you get with saying "tl" primarily
[19:08] <mpt> slangasek, yes, I think it will subsume Software Sources eventually. Fixed. <https://wiki.ubuntu.com/AppCenter?action=diff&rev2=64&rev1=63>
[19:09] <slangasek> mpt: "eventually", but not necessarily in the karmic timeframe? (I'm trying to get MultiarchSpec right, which requires touching some of these components)
[19:10] <mpt> slangasek, yes, I expect in 9.10 software-properties-gtk will stay but possibly have some tweaks
[19:10] <calc> slangasek: i doubt i will have time in the next week, so if you have the time to look at it that would be good
[19:10] <slangasek> calc: ack, claiming the bug, thanks
[19:10] <slangasek> mpt: okie
[19:11] <Keybuk> http://people.ubuntu.com/~scott/boot-performance/Fedora-11-i686-Live_Dell-Mini9.png
[19:12] <mpt> slangasek, is that likely to involve interface changes to s-p-gtk
[19:12] <mpt> ?
[19:12] <mpt> The multiarch stuff, I mean
[19:12] <ogra> Keybuk, sill faster than ubuntu LTSP with unionfs-fuse :P
[19:14] <slangasek> mpt: yes; since this is meant to completely supersede ia32-libs and friends, it's important that users have a straightforward way to enable it, and s-p-gtk is the logical place for that to live
[19:14] <slangasek> mpt: I'm envisioning a trivial UI, fwiw, just one more checkbox or so ;)
[19:15] <mpt> I'm not familiar with ia32-libs, so I'm not clear about why it would need to be enabled or disabled
[19:16] <slangasek> Keybuk: I'm meaning to follow up on list as well, but I noticed your analysis of "must do before the desktop" doesn't include the network; that's going to break various enterprise use cases, does that factor into your design somewhere yet?
[19:16] <slangasek> mpt: it's needed if a user wants to run any 32-bit binaries on their 64-bit install; skype, wine, etc
[19:16] <slangasek> (flash)
[19:17] <slangasek> mpt: the alternative to having it in the s-p-gtk UI would seem to be giving users long instructions for mangling /etc/apt/sources.list at the commandline, and that's not really appropriate for ia32-libs' target audience IMHO
[19:17] <mpt> slangasek, so if your system if 64-bit but you want to run a 32-bit application, you need to replace some of your installed 64-bit libraries with the 32-bit equivalents? Or install the 32-bit equivalents alongside?
[19:18] <slangasek> mpt: alongside
[19:18] <mpt> if->is
[19:18] <slangasek> ia32-libs is the current, kludgirific way of doing this
[19:18] <mpt> slangasek, ok, so what would the option be?
[19:18] <slangasek> as in, what would the label say?
[19:19] <slangasek> "enable 32-bit software" or "enable 64-bit software", according to the architecture; or something better if you think that's a bad label
[19:24] <directhex> slangasek, two f's in kludgeriffic
[19:24] <mpt> slangasek, and what would the other choice be?
[19:24] <slangasek> mpt: mentioned now at https://wiki.ubuntu.com/MultiarchSpec#Migration; in the perfect world, the user would never need to click this because update-manager can take care of it on upgrade
[19:24] <slangasek> mpt: the other choice would be to not enable it
[19:24] <mpt> slangasek, and what would happen if you didn't?
[19:25] <slangasek> you would have access to all the software built for 64-bit Ubuntu, but not access to the packages needed in order to install closed-source 32-bit software
[19:26] <mpt> slangasek, ok, so why would someone want to not enable it?
[19:26] <mpt> (Sorry for these basic questions, this is all to help with the labelling)
[19:26] <slangasek> mpt: it doubles the bandwidth cost of an apt-get update because you have to grab two copies of each Packages file
[19:27] <slangasek> no worries; I expected that to be the next question :)
[19:27] <lajjr> hello pitti.
[19:27] <mpt> slangasek, and would that be the only difference?
[19:28] <slangasek> mpt: I think that, and possibly some slow-down on apt's own calculations, would be the only material difference users are going to care about
[19:29] <slangasek> I could say "you might accidentally pull in a 32-bit package because there's no 64-bit package available", but, er, good then :)
[19:31] <slangasek> mpt: I guess I would see this being similar to the fact that we give you the ability to disable downloads from main and universe, but enable them by default
[19:31] <mpt> slangasek, so let's say I'm using 64-bit Ubuntu, I have the option turned on, and I download a 32-bit Skype .deb and double-click on it. Will gdebi tell me that I need to install some 32-bit libraries that I already have 64-bit versions of?
[19:32] <mpt> Is that how it works?
[19:32] <walters> slangasek: is debian going to adopt this plan as well?
[19:33] <slangasek> mpt: I've actually never used gdebi; but assuming it's not reinventing the wheel, its behavior should be the same as if you click on a package that has other, 64-bit lib dependencies that need to be installed
[19:33] <slangasek> walters: I expect so; we have buy-in from a member of dpkg upstream
[19:34] <fta> slangasek, subversion seems to be broken now: http://paste.ubuntu.com/191846/   is that a known issue?
[19:35] <mpt> slangasek, sorry I don't know what that behavior is, I've never had a 64-bit installation
[19:36] <slangasek> mpt: s/64-bit //
[19:36] <slangasek> mpt: i.e.: the behavior should be identical to what it already does when you try to use it to install a .deb with currently unsatisfied dependencies
[19:37] <slangasek> presumably it will automatically install any that it can find, and throw an error for any it can't?  if it directs you to s-p-gtk in the latter case, even better
[19:37] <mpt> slangasek, ok. On the other hand, if I have the option turned off, it will ... what? fail?
[19:38] <slangasek> fta: wasn't known to me; sorry, file a bug and assign it to me, since apparently I broke it?
[19:38] <fta> slangasek, ok
[19:39] <slangasek> mpt: it would necessarily fail, yes; I don't have a preference for how it presents this failure to the user, I'm happy to have input there
[19:41] <mpt> slangasek, soooo ... Sorry if this has already been considered (I don't see it when scanning the spec), but did you think about downloading the 32-bit Packages file only if and when you're trying to install a 32-bit package that depends on uninstalled libraries?
[19:42] <mpt> (or uninstalled anything-else, I guess)
[19:43] <fta> slangasek, bug 385318
[19:44] <maxb> That's a dupe of one that I've made a debdiff for and subscribed sponsors
[19:45]  * maxb will find number once my desktop has booted
[19:47] <maxb> bug 384715
[19:48] <slangasek> mpt: while we could have gdebi trigger that automatically if we think that's reasonable, it can't be the only way to enable grabbing the 32-bit Packages file because there will be other use cases we want to support besides gdebi (e.g., Add/Remove Software or whatever will replace it, which can't reasonably have the index available without also downloading the Packages...)
[19:50] <slangasek> mpt: and, given that we prefer for philosophical reasons to have packages downloaded from the repositories instead of being installed by clicking on a .deb, the design shouldn't give a better user experience via gdebi :)
[19:50] <mpt> slangasek, I wasn't suggesting this for gdebi only, I was just using it as an example
[19:51] <mpt> but I guess if you haven't downloaded the 32-bit Packages file in the first place, you won't even see the 32-bit multiverse application you want to install, let alone its dependencies
[19:51] <slangasek> exactly
[19:53] <mpt> ok, I think I finally understand
[19:54] <mpt> thank you for your patience :-)
[19:54] <slangasek> no problem :)
[19:54] <slangasek> now that you understand, what guidance can you give me? :)
[19:54] <mpt> so I guess this checkbox would be sensitive only if you were actually running 64-bit
[19:55] <mpt> and it would say something like "Include 32-bit packages in available software"
[19:56] <slangasek> fwiw, there are use cases for being able to install 64-bit packages on 32-bit systems as well; though these are much more marginal and AFAIK are entirely developer-oriented, so I'm ok with not including the checkbox for that case
[19:57] <slangasek> directhex: etymologically incorrect, btw :)
[19:58] <directhex> slangasek, aw :(
[19:59] <ion_> To be accurate, “kludge” itself is etymologically incorrect. ;-)
[19:59] <ion_> http://catb.org/~esr/jargon/html/K/kludge.html
[20:02] <calc> ug i can't find where the old OOo build was symlinking the files
[20:02]  * calc thinks it was probably some magic stuff
[20:02] <slangasek> magic, in OOo's build? neveerrrr
[20:04] <calc> slangasek: hehe
[20:05]  * calc checks to see when it last actually worked properly
[20:05] <calc> 3.0.1-9ubuntu2, hmm wtf
[20:06] <calc> i can probably make it work again but it would be nice to find out why it stopped working, to make sure it didn't break anything else... and i can't see how it worked before :-\
[20:06] <slangasek> mpt: ok, thanks for you help - I've inserted your suggested language in the spec, now back to working on release-y stuff :)
[20:09] <calc> lmao, this works for debian, even more fun
[20:09] <calc> so now it looks like i get to see what i managed to break in a merge
[20:11] <mrooney> Anyone know if Empathy and Banshee will be default for Alpha 2?
[20:11] <mrooney> Also, grub2?
[20:12] <ion_> https://wiki.ubuntu.com/KernelTeam/Grub2Testing
[20:13] <directhex> apparently i no speel gud :(
[20:13] <seb128> mrooney: banshee will not be default until all the issues mentioned at uds will be fixed including accessibility which is not going to be today
[20:14] <seb128> not to mention some extra one, like banshee upstream not being able to have a clear schedule which means we don't know if 1.5 can be used before karmic
[20:16] <slangasek> maxb: 384715> ugh, that bug offends all my sensibilities
[20:16] <slangasek> so subversion was working just fine with neon 0.28.4, up until we rebuilt against it. yay.
[20:17] <maxb> slangasek: Yes, it's fundamentally dumb
[20:17] <maxb> But it is fixed more sanely in upstream 1.6
[20:18] <slangasek> I'll get the configure script neutered later today and upload
[20:18] <mrooney> seb128: ah ok. I saw your memory tests by the way, I have been keeping a list including a list of bugs and links at https://wiki.ubuntu.com/MikeRooney/KarmicBansheeAsDefault, thought you might be interested, it also includes a link to the upstream metabug
[20:31] <doko> why does libasound2 depend on libpython2.6?
[20:34] <slangasek> doko: because I fixed its previous build-dependency of python2.4-dev to point to python-dev like it was meant to :)
[20:35] <slangasek> /usr/lib/alsa-lib/smixer/smixer-python.so
[20:35] <doko> slangasek: hmm, is this really needed on the CD?
[20:36] <slangasek> doko: is that the only thing pulling libpython2.6 in?
[20:36] <slangasek> it's probably not needed on the CD, but I doubt it's worth the effort of splitting it if libpython2.6 is already there
[20:36] <doko> slangasek: well, I didn't check for the CD, just did see it in my chroot added.
[20:37] <slangasek> it was already on the CD in jaunty
[20:38] <doko> maybe we should fix these packages ...
[20:39] <slangasek> no objections from me if you think it should be dropped
[20:39] <slangasek> I was just fixing the python2.4-dev build-dep, which was clearly wrong
[20:40] <doko> I'll ask mterry ;-)
[20:40]  * slangasek grins
[20:41] <mterry> :-/
[20:41] <slangasek> anyway, no one in Debian or Ubuntu noticed that the asound python bit wasn't built, until I went cleaning up the python2.4 revdeps
[20:41] <mterry> I'm sure that falls under doko's 20%  :)
[20:42] <doko> mterry: only if you do the glibc-2.10 upgrade ;-p
[20:43] <mterry> doko: Couldn't I just do some laundry for ya or something instead?  My 80% of doko-time could be all your non-ubuntu tasks, so you can devote more hours to Ubuntu.
[20:44] <hyperair> hmm am i the only one who doesn't have working laptop brightness keys now?
[20:45] <doko> mterry: my luggage didn't arrive yet, you'll have to wait until tomorrow ...
[20:49] <slangasek> ttx: do you have a bug number for the likewise-open5 breakage?
[21:08] <slangasek> ttx: issue documented in the tech overview, but I would prefer to have an LP bug # that I can link in
[21:15] <Adri2000> mvo: do you plan an app-install-data-ubuntu sru for jaunty? it would be useful for bug #338419
[21:22] <mvo> Adri2000: I was not really planning one, but its trivial enough - if its anoying to enough users we can do it
[21:23] <mvo> Adri2000: lets talk about it tomorow, I need to leave for today
[21:23]  * mvo waves
[21:41] <slangasek> persia, YokoZar: what are the plans for MID looking like?  I see that livefs builds are commented out, with a pointer in y'all's direction. :)
[21:42] <YokoZar> slangasek: we need to transition a whole bunch of packages to rebase off Mer
[21:43] <slangasek> what's Mer, then?  That's the second mention I've seen of it, but I don't know what it is
[21:43] <YokoZar> Basically they're our new upstream
[21:44] <YokoZar> http://wiki.maemo.org/Mer
[21:44] <ogra> sladen, mer is the new maemo :)
[21:46] <ogra> err s/sladen/slangasek/
[21:49] <slangasek> hrm.  Mer is the new Maemo?  I thought MID was based on Moblin, not Maemo.  I'm so confused :(
[21:49] <cjwatson> mrooney: grub2> see ubuntu-devel-announce :-)
[21:50] <ogra> slangasek, right, mer is the attempt of freeing up maemo completely and moblin completely moved to netbooks, MID is rather for touchscreen driven devices will very small screens
[21:51] <ogra> so moblin isnt the right base for MID anymore
[21:51] <slangasek> oh
[21:51] <ogra> and mer is driven by the community
[22:02] <pochu> slangasek: would you mind including $release (e.g. Karmic) on your "Main frozen for Alpha X" mails? :)
[22:02] <slangasek> pochu: well, I don't guarantee that I'll consistently remember to include it
[22:03] <pochu> slangasek: that's ok. I thought you had a template or a script though ;)
[22:03] <james_w> I read that as "I don't guarantee to always remember what release it is"
[22:03] <pochu> lol
[22:03] <slangasek> no script, I just copy previous mails and edit them
[22:06]  * slangasek considers whether dropping libboost-mpi entirely would be ok
[22:07] <slangasek> james_w: that's not implausible, either ;)
[22:10] <slangasek> ScottK: do you have any opinion on pruning libboost-mpi?  Nothing uses it, and it would spare us a variety of mpi MIRs
[22:28] <TheMuso> asac: I'd say it will, but I don't know exactly when.
[22:30] <asac> TheMuso: was that really directed to me?
[22:31] <TheMuso> asac: hrm I thought you were the one who asked the question but I'd need to check my backlog again to be sure, sorry for the bother if it wasn't meant for you.
[22:40] <Viper550> has someone seen this? http://www.youtube.com/watch?v=a1U0dK2HpUk plymouth can run on ubuntu?
[22:40] <ogra> sure, but it wont be used
[22:41] <ogra> it can run on certain HW since jaunty
[22:42] <cjwatson> we discussed plymouth and decided not to use it because (a) usplash can run on kms too so there's no driving reason to drop it, (b) we'd basically have to bring plymouth up to par with usplash in various ways (c) plymouth doesn't really seem to offer anything stunningly new - for example it still uses .so objects for theming (AIUI)
[22:42] <ogra> d) a splash is just a way to hide a slow bootprocess ;)
[22:43] <cjwatson> oh, right, indeed, we'll be moving to avoiding a splash screen at all except when necessary for interaction
[22:43] <ogra> solving the basic prob is more elegant :)
[22:43] <cjwatson> and trying to bring X up as soon as possible instead
[22:43] <kirkland> Keybuk: around?  what's the proper way in the init-script-less world to start a daemon on boot?
[22:43] <kirkland> Keybuk: a newly developed from scratch daemon
[22:43] <kirkland> Keybuk: i'm trying to avoid an init script
[22:43] <sladen> kirkland: upstart files
[22:44] <kirkland> sladen: agreed; is there documentation on creating an upstart configuration for starting a daemon?
[22:44] <ogra> http://upstart.ubuntu.com/
[22:44] <ogra> http://upstart.ubuntu.com/wiki/
[22:44] <kirkland> ogra: thanks
[22:44] <sladen> kirkland: and have a look in /etc/event.d/ for the existing uses
[22:44] <cjwatson> kirkland: it's all going to change soon ...
[22:45] <slangasek> mr_pouit, cody-somerville, NCommander: xubuntu-desktop depends on xfce4-dict-plugin, which is NBS?
[22:45] <kirkland> cjwatson: right, those "changes" are what i'm asking about
[22:45] <cjwatson> so now is perhaps not the best time to do it; I would advise continuing to use init scripts for now
[22:45] <kirkland> (i think)
[22:45] <cjwatson> all I've heard is Keybuk talking abou ti
[22:45] <cjwatson> about it
[22:45] <kirkland> cjwatson: :-)
[22:45] <kirkland> cjwatson: right, this is why i'm trying to sync up with him
[22:45] <cjwatson> from what I have heard, I think the upstart wiki is probably not up to date with his latest work
[22:46] <slangasek> hmm?  there are going to be significant design changes?
[22:46] <kirkland> cjwatson: i was contemplating an @reboot cronjob, for kicking it off
[22:46] <kirkland> cjwatson: would this be horrible and evil?
[22:46] <cjwatson> kirkland: why not just use an init script?
[22:46] <cjwatson> seriously
[22:46] <kirkland> cjwatson: oh, i don't mind, using an init script, i just thought we were trying to get rid of init scripts
[22:46] <kirkland> cjwatson: and i was trying to avoid introducing a new one
[22:47] <cjwatson> yes, but we're not there yet, so I'm not sure anticipating that is helpful right now
[22:47]  * kirkland is quite happy with init scripts
[22:47] <sladen> kirkland: /etc/event.d/logd   exec ...   resprawn
[22:47] <kirkland> cjwatson: word.
[22:47] <slangasek> "why not" - because that leaves the admin with no way to manage the state of the daemon, and no way for package maintainer scripts to interact with it
[22:47] <cjwatson> slangasek: so I understand, yes
[22:47] <cjwatson> (significant design changes)
[22:48] <cjwatson> he was talking about it at various stages during UDS
[22:48] <kirkland> sladen: thanks
[22:48] <slangasek> cjwatson: are those going to be done by the 22nd? :)
[22:48] <kirkland> sladen: that looks like what i need
[22:48] <cjwatson> slangasek: now that I don't know, though I understand he's going to try of course
[22:48] <Viper550> hmm speaking of init, <leinir> bero's new init system is so fast that really, when the splash screen gets shown, you should already be loading up xorg :)
[22:48] <cjwatson> kirkland: logd is special because upstart itself owns that
[22:48] <cjwatson> kirkland: I don't think it should be used as an example by the rest of the archive yet
[22:49] <cjwatson> Viper550: is that fedora? they're using upstart
[22:49] <Viper550> no, ark linux. another rpm distro. we're currently starting to modernize it a bit for our long-anticpated 2009.1 release
[22:50] <kirkland> cjwatson: okay, init script it is
[22:50] <Viper550> we're switching to libzypp from APT-RPM
[22:50] <Viper550> and heck it even works with rpm5
[22:50] <cjwatson> Viper550: we should be able to do just that with karmic - load X when we're currently loading the splash screen, near enough
[22:50] <cjwatson> and that's definitely what we're shooting for
[22:51] <ogra> without reinventing an init system though :)
[22:51] <Viper550> so are we gonna minimalize the splash screen?
[22:51] <ogra> we already did that before
[22:51] <cjwatson> well, the init system is involved
[22:51] <cjwatson> what does "minimalize the splash screen" mean?
[22:51] <ogra> 2x2 px splash ? :)
[22:51] <slangasek> meh, NBS is such a mess right now
[22:51] <Viper550> as in...remember Windows Vista changed it to just a progress bar?
[22:52] <cjwatson> Viper550: it's already just a progress bar plus a background ... from my point of view, "whatever"
[22:52] <ogra> the plan is to be fast enough to not have a splash at all
[22:52] <cjwatson> I don't really care that much what the art guys do with it :)
[22:52] <sladen> Viper550: karmic+1 should have no visible splash (except in the case of fsck).  Some of the stuff might land sooner
[22:52] <Viper550> on 7 its just an animated "pulsing" progress bar with "Starting Windows..." below it
[22:53] <dtchen> slangasek: speaking of NBS, feel free to kill libpulsecore9
[22:53] <Viper550> maybe just a basic logo and throbber for the installed system on kamic.
[22:53] <sladen> Viper550: that's what usplash is, right?
[22:53] <ogra> just to see it flashing by ?
[22:54] <ogra> if you boot fast enough you dont need a splash
[22:54] <slangasek> dtchen: done.  is there an lpia build failure there that's being worked on?
[22:54] <Viper550> no, ours has a big logo and a thin progress bar
[22:54] <dtchen> slangasek: looking
[22:54] <cjwatson> Viper550: feel free to get in touch with the art folks about that
[22:54] <sladen> Viper550: what is that different?  ("ours" == fedora?)
[22:55] <Viper550> ubuntu has a big logo/thin progress bar
[22:55] <ogra> it wont anymore if there is no splash anymore
[22:56] <sladen> Viper550: it actually as a huge logo--- eg. 1024x768.  Most of it is black though
[22:56] <ogra> if your boot is fast enough you dont need a splash at all, you just start X
[22:56] <ogra> and thats the target
[22:56] <Viper550> but for the slower computers...it would still be good to have at least some indicator rather than a black screen. blank screens scare noobs.
[22:57] <Viper550> I think for karmic, just a greyed out ubuntu logo with a small circular throbber in it on the bottom-center
[22:57] <ogra> they will likely just have X with an idle cursor
[22:57] <ogra> not a black screen
[22:58] <sladen> Viper550: when you turn on the computer, you get ~10-15 seconds of black whilst the monitor warms up/syncs, and the initial bootstrap code loads.  ~3-5 seconds is alot less than that
[22:58] <Viper550> I got an lcd monitor
[22:58] <ogra> and your PC has a BIOS, doesnt it ?
[22:58] <ogra> common bioses take 5-20sec
[22:58] <Viper550> on 4 of our computers. and my bios on my HP in my room has a blue screen not a black one.
[22:58] <ogra> where you are at a black screen
[22:58] <Viper550> in between end splash and loading X
[22:59] <dtchen> slangasek: yes, lp #375595. chasing now.
[22:59] <sladen> Viper550: pretend that the splash wasn't there, and that same second of couple black was between grub and X
[22:59] <cjwatson> we'll certainly still have the facility to start usplash in various circumstances (e.g. fsck, dm-crypt), so running it on slow computers as well is basically an implementation detail AFAICS
[23:00] <Viper550> woah...
[23:00] <cjwatson> and I think that would indeed be a desirable thing to do
[23:00] <cody-somerville> slangasek, I'll fix that
 Viper550: karmic+1 should have no visible splash (except in the case of fsck)
[23:01] <Viper550> but for karmic,
[23:01] <cjwatson> sladen: whence "karmic+1"?
[23:01] <cjwatson> sladen: the plan of record is to do that for karmic
[23:01] <Viper550> it would be good to start on the right direction
[23:02] <sladen> Viper550: how most of these progress bars work, is that you allow a period of time, which is the maximum a user is comfortable with, without seeing any movement (eg. 100msc, or .5 second, or 3 seconds, depending on the situation).  And then at that point you poke/rotate the icon/progress bar/throbber
[23:03] <sladen> Viper550: in the case of boot, people are already used to seeing ~3 second black screens at X transition, and considerably more at the BIOS/pre-Grub.  Therefore, there's a 3 second budget before you have to poke the throbber/progress bar
[23:03] <Viper550> sladen, also one thing I noticed, last time I used ubuntu (yes, the computer I speak of, currently runs freedos for no appearant reason), there is always this part of the bootup where the progress bar "ping pongs" before it actually does anything
[23:03] <sladen> Viper550: so you can safely allow 3 seconds, and if X hasn't loaded by then, then you can fire up usplash
[23:04] <sladen> Viper550: it ping pongs until it's possible to estimate the 0-100% progress
[23:04] <cjwatson> Viper550: it turns out that we have sufficiently little idea in practice of how long the initramfs is going to take that displaying a throbber ("ping pong") there is better than a hopelessly inaccurate bar
[23:04] <cjwatson> we used to try to display a monotonic progress bar there; it didn't work out so well
[23:04] <Viper550> gOS (last version with Enlightenment I beleive, ubuntu based), I think, took about 24 seconds to boot through usplash (though it also had a rather ugly theme, BRIGHT GREEN BOOTUP FTW)
[23:05]  * ogra hugs stgraber ... thanks for getting us a "usable" LTSP for A2 :)
[23:05] <cjwatson> timings are meaningless without context :-) There are already machines that boot Ubuntu to a fully usable desktop in 12 seconds or so
[23:05] <Viper550> my computer has 256mb ram, and a P3 equiv
[23:05] <sladen> Viper550: yes, 25 seconds is about right for a recent *buntu
[23:06] <Viper550> its an athlon thunderbird
[23:07] <Viper550> and it has an older ATI graphics card (it replaced a Nvidia card it used to use, that started suffering from "scan line syndrome". We actually BOUGHT A NEW MONITOR cause we thought it was the monitor)
[23:08] <stgraber> ogra: well, I haven't tested that code on a clean install yet so who knows :) but it can't be worse than before anyway
[23:08] <ogra> i'd like to know if its as slow on real HW
[23:09] <ogra> my vbox surely had enough ram allocated
[23:10] <stgraber> I have a Core2Duo here as test thin clients, if it takes longer than 8s, then it slower than Jaunty :)
[23:10] <ogra> heh
[23:11] <ogra> if it takes less than 2min to boot i'm happy :)
[23:11] <ogra> (at least until mount --union comes)
[23:36] <soren> slangasek: I'm curious... When we build Hardy images after Hardy's released, do we still use the livecd-rootfs and cd building code that was in use when Hardy was released or do we use whatever's current?
[23:37] <slangasek> soren: we use what's current, though we're careful to guard any relevant code changes that are incompatible with hardy with a distroseries check
[23:37] <soren> slangasek: Interesting. Thanks.
[23:45] <calc> slangasek: it currently looks like fixing the symlinking issue will be fairly hard, i found the spot in the code that does it but due to us having a separate -l10n source i have to determine how to make it actually work properly with that
[23:45] <slangasek> calc: ok - not critical for alpha-2, so therefore not worth the risk of an upload right now
[23:46] <calc> slangasek: currently it looks in ooo-common and anything in that and also in the l10n-XX package gets a symlink, but i think for the l10n package the ooo-common no longer exists at all due to changing over to dh_install
[23:46] <slangasek> ah
[23:47] <calc> so i'm not sure how to fix it atm, will definitely be interesting, heh
[23:49] <calc> i delay my next upload until after a2 release and try to get the l10n size issue fixed as soon as i can determine how to, may be after my next upload though
[23:49] <calc> er i'll delay
[23:57] <maxb> Why does the apport retracer remove CoreDump.gz attachments? Is the rationale one of potential privacy issues?
[23:59] <slangasek> yes