[12:20] <jdub> tseng: apparently it's not in the desktop suite
[12:38] <tseng> jdub: well, I know the reason its not there
[12:38] <tseng> jdub: on that level.. any reason it shouldnt be promoted and in -desktop?
[12:39] <jdub> not that i know of
[12:39] <tseng> hm
[12:39] <jdub> it's a pretty widely distributed chipset now
[12:39] <tseng> its quite a pain getting networking up sometimes to install it
[12:39] <tseng> depending on where you are
[12:40] <tseng> for some reason dhclient isnt acking dchp offers for me atm
[12:40] <tseng> (on the wire)
[12:40] <tseng> gotta put in my long ass wepkey
[12:54] <pygi> ho hi Keybuk 
[12:54] <Keybuk> oh, that's good, firefox don't work *cry*
[01:00] <Keybuk> or at least hurt
[01:00] <LaserJock> yeah, you want him to be able to recover and fix it ;-)
[01:03] <Keybuk> yes, but I don't necessarily want him to live much longer afterwards
[01:03] <Keybuk> lynx just isn't that useful for porn
[01:04] <bddebian> Howdy folks
[01:20] <Chipzz> Keybuk: my eyes bleed when I start firefox :(
[01:20] <Keybuk> why?
[01:20] <Keybuk> I just get a XUL/XML error
[01:20] <Chipzz> some really sucky ui regressions
[01:20] <Chipzz> remember the go button?
[01:21] <Chipzz> not only is it a part of the url bar now, so it cannot be removed
[01:21] <Chipzz> either you have both the url bar and the go button, or neither
[01:21] <Chipzz> but it is also way to big
[01:22] <Chipzz> the url bar takes less than 50% of the width now
[01:22] <Chipzz> http://apocalypse.realroot.be/~chipzz/ff2beta.png
[01:22] <Chipzz> which would be usefull to you if firefox actually worked for you ;)
[01:23] <HrdwrBoB> you're right, it's massively large
[01:23] <Keybuk> tried the usual crap like removing the profile and that didn't help either
[01:23] <Chipzz> the search bar is also a big regression imo
[01:23] <Keybuk> that looks more like a busted theme
[01:24] <Chipzz> I only removed some buttons from the toolbar actually
[01:24] <Chipzz> the rest is whatever ubuntu ships
[01:26] <Chipzz> the backspace -> pageup instead of back is also very annoying
[01:26] <Keybuk> did you update it?
[01:26] <geser> Chipzz: are you using a theme from firefox-ubuntu-themes?
[01:27] <Chipzz> chipzz@Reel:~$ dpkg --get-selections | grep firefox
[01:27] <Chipzz> firefox                                         install
[01:27] <Chipzz> firefox-gnome-support                           install
[01:27] <Chipzz> firefox-themes-ubuntu                           install
[01:28] <Chipzz> and I'm using whatever ubuntu has the user use as a theme for firefox with those packages installed
[01:29] <geser> the problem with the themes is known as bug 60643
[01:29] <Ubugtu> Malone bug 60643 in firefox-themes-ubuntu "[Edgy]  The "Go" button is much to wide when using Firefox 2.0b2" [Untriaged,Confirmed]  http://launchpad.net/bugs/60643
[01:33] <Chipzz> at the rate this is going I'm considering downgrading firefox to the 1.5 version and putting it on hold permanently
[03:02] <Keybuk> oh, that's weird
[03:03] <Keybuk> it's not just evo doing the "folder display|..." thing
[03:03] <Keybuk> totem is doing "short time format|..."
[03:04] <bddebian> Keybuk!!
[03:04] <bddebian> You probably know
[03:05] <bddebian> Are we supposed to be including .la files any longer or not?
[03:05] <Keybuk> yes
[03:05] <bddebian> Crap.  I swore I heard that we were not
[03:05] <Keybuk> there are differing opinions on this
[03:05] <Keybuk> some people are wrong
[03:06] <bddebian> Gah
[03:06] <Keybuk> lol
[03:06] <Keybuk> why?
[03:06] <bddebian> Because I suck?
[03:07] <Keybuk> why do you suck?
[03:07] <bddebian> Because I'm stupid?
[03:07] <Keybuk> why are you stupid?
[03:07] <Keybuk> you seem perfectly able to me
[03:07] <LaserJock> mhm
[03:10] <bddebian> Keybuk: Well now obviously you are now uninformed ;-)
[03:10] <Keybuk> I'm sure the person who told you was someone like seb128
[03:10] <Keybuk> who is firmly in the anti-libtool brigade
[03:11] <jdub> heh
[03:11] <Keybuk> the basic problem is that they cause bugs to show up
[03:11] <Keybuk> which seb would rather sweep under the carpet and pretend were somebody else's problem
[03:11] <Keybuk> :p
[03:12] <jdub> like, say, YOURS
[03:12] <bddebian> By including them or not including them?
[03:12] <Keybuk> including them
[03:12] <Keybuk> mine?
[03:12] <jdub> your problem!
[03:12] <Keybuk> what's my problem?
[03:13] <jdub> seb's under-carpet mess
[03:13] <Keybuk> I haven't maintained Libtool for a couple of years
[03:13] <Keybuk> seb's mess shows up in other places
[03:13] <Keybuk> like the other day when symbols mysteriously vanished from a library without a SONAME bump
[03:13] <Keybuk> which he still claims wasn't an ABI change :p
[03:19] <bddebian> You folks keep confusing my dumb ass :-)
[03:19] <lifeless> thats so an ABI change
[03:21] <tseng> bddebian: oh stop
[03:34] <bod> any ubuntu sysadmins about?
[03:34] <jdub> sure
[03:35] <bod> need to see what's wrong with optus@syncproxy.ubuntu.com, the password no longer seems to work
[03:40] <zul> isit just me or is the wiki slow?
[03:40] <zul> hey spaz
[03:41] <jdong> zul: yeah, the wiki's been slow recently
[03:56] <Seveas> bod, #ubuntu-mirrors (usually they're there at non-insane UTC+1 hours)
[03:59] <jdong> why is gnome-power-manager all of a sudden pulling numbers out of its ass?
[04:00] <Seveas> because it can find no useful numbers?
[04:01] <jdong> well, it used to do everything right
[04:01] <jdong> now, it's pulling percentages and times out of it ass
[04:01] <jdong> look! I have 18 hours of battery life left!
[04:01] <jdong> 75%
[04:01] <jdub> bod: ah, i was thinking "admins of ubuntu-based systems" ;-)
[04:02] <jdong> while acpi -V tells me I have 35 minutes / 15% left
[04:02] <jdub> bod: you can use the mailing list too
[04:02] <jdong> now, I consider that pulling numbers out of its ass
[04:03] <Seveas> jdub, shouldn't you be on your way to brussels? 
[04:04] <Seveas> jdong, woah, I want a battery with 18h lifetime!
[04:04] <Seveas> preferably if it weighs less than a metric shitload
[04:04] <jdong> Seveas: yeah, gnome-power-manager is really trying to tease me on this one :)
[04:05] <jdub> Seveas: unfortunately for various reasons, i won't be there
[04:05] <Seveas> jdub, dang!
[04:06] <bddebian> We need an all doko all the time channel :-)
[04:07] <Seveas> heh
[04:07] <jdong> aha! the bullshit originates from HAL :)
[04:09] <Seveas> jdong, excellent quote to take out of context
[04:09] <jdong> Seveas: hehe....
[05:31] <fabbione> slomo: ping?
[06:02] <fabbione> jdub: ping?
[06:05] <jdub> fabbione: pong
[06:05] <fabbione> jdub: can you test a fixed mdadm for me?
[06:05] <jdub> sure
[06:07] <fabbione> ok
[06:07] <fabbione> one sec that i am building it
[06:07] <keescook> fabbione: what's been fixed in mdadm?
[06:07] <HrdwrBoB> keescook: it wanted to stop arrays on upgrade
[06:08] <fabbione> and it needs to kick an initramfs update
[06:08] <keescook> ah-ha, cool.
[06:09] <fabbione> jdub: people.u.c/~fabbione/mdadm_2.4.1-6ubuntu3_i386.deb
[06:11] <jdub> man, initramfs build takes ages these days
[06:12] <jdub> fabbione: !!!1111
[06:12] <jdub> fabbione: it installed! :)
[06:13] <jdub> also, i'm getting this during initramfs builds atm:
[06:13] <jdub> cpio: ./sbin/vgchange: No such file or directory
[06:13] <jdub> i'll file
[06:13] <fabbione> i didn't get that
[06:14] <fabbione> Setting up mdadm (2.4.1-6ubuntu3) ...
[06:14] <fabbione> update-initramfs: Generating /boot/initrd.img-2.6.17-7-generic
[06:14] <fabbione>  * Starting RAID monitoring service mdadm --monitor                                                                                 [ ok ]  
[06:14] <fabbione> that's about it
[06:14] <fabbione> can you check if that symlink actually exists on your system
[06:14] <fabbione> bah feh
[06:14] <fabbione> that comes from lvm
[06:14] <infinity> Yeah.
[06:14] <fabbione> do you have lvm2 installed?
[06:14] <jdub> fabbione: you probably have lvm installed
[06:14] <jdub> no
[06:15] <fabbione> iz not a buf
[06:15] <fabbione> bug
[06:15] <jdub> it is a minor issue ;)
[06:15] <fabbione> and it's not an md issue
[06:15] <infinity> jdub: Can you trace through and find what's trying to copy it?
[06:15] <jdub> yeah
[06:15] <infinity> jdub: That was specifically hacked around in dapper, I'm trying to find if someone dropped my change.
[06:16] <jdub> it's now #60996
[06:17] <infinity> jdub: initramfs-tools itself doesn't copy vgchange anywhere anymore.
[06:17] <infinity> jdub: So, can you rgrep through /usr/share/initramfs-tools and /etc/initramfs-tools for the offending string?
[06:18] <jdub> oh
[06:18] <jdub> i was just sh -x ing it
[06:18] <jdub> $ grep -rl vgchange /usr/share/initramfs-tools /etc/initramfs-tools
[06:18] <jdub> /usr/share/initramfs-tools/scripts/local-top/lvm
[06:18] <jdub> /usr/share/initramfs-tools/hooks/lvm
[06:19] <infinity> jdub: Right, and we don't ship either of those.
[06:19] <fabbione> so you have lvm partially installed
[06:19] <fabbione> infinity: we do in lvm
[06:19] <infinity> Oh, lvm-common ships those.
[06:19] <jdub> it's the latter
[06:19] <infinity> if [ ! -x /sbin/vgchange -a ! -d /lib/lvm-200 ] ; then
[06:19] <jdub> which is installed!
[06:19] <infinity>         exit 0
[06:19] <infinity> fi
[06:19] <infinity> Clearly, that's not tripping.
[06:19] <jdub> and i can remove it
[06:20] <infinity> Yeah, I don't want you to remove it.
[06:20] <infinity> This should work.
[06:20] <fabbione> infinity: want to take care of it?
[06:20] <fabbione> or should i?
[06:20] <fabbione> but for me removing lvm is not an option
[06:20] <infinity> I'm removing lvm right now. :)
[06:20] <fabbione>  /dev/mapper/gordian-root on / type ext3 (rw,data=ordered)
[06:20] <fabbione> thanks :)
[06:20] <jdub> yeah, i'll only remove it after testing this
[06:21] <infinity> jdub: What's responsible for /lib/lvm-200 existing on your system?
[06:21] <infinity> jdub: When I remove lvm2, it's completely gone.
[06:21] <jdub> it's not
[06:21] <jdub> but
[06:21] <jdub> this is interesting
[06:21] <jdub> $ ls /sbin/vgchange
[06:21] <jdub> lrwxrwxrwx 1 root root 13 2005-09-17 08:17 /sbin/vgchange -> lvmiopversion
[06:21] <infinity> Yeah, that's correct.
[06:21] <jdub> alternatives?
[06:22] <fabbione> no
[06:22] <fabbione> all lvm calls are calling the same binary
[06:22] <infinity> No, not an alternative.
[06:22] <jdub> ah
[06:22] <infinity> lvm is thpethial.
[06:22] <fabbione> lvm decides how it has been called from $0
[06:22] <fabbione> lvm binary is like a shell
[06:22] <infinity> And lvm-common ships a wrapper binary to auto-select lvm10 versus lvm2
[06:22] <jdub> $ if [ ! -x /sbin/vgchange -a ! -d /lib/lvm-200 ] ; then echo pants; fi; echo $?
[06:22] <fabbione> try to invoke lvm alone and you get the same set of commands
[06:22] <jdub> 0
[06:23] <infinity> jdub: Err, wait.  No pants?
[06:23] <jdub> no pants man. the way it ought to be. except in this case.
[06:23] <infinity> jdub: Oh, crap.  Yes, I can reproduce.
[06:23] <infinity> jdub: I'll dig.
[06:23] <fabbione> dash'ism?
[06:23] <fabbione> bashism?
[06:23] <infinity> Oh, duh.
[06:23] <infinity> '-a' is a bashism.
[06:23] <infinity> Thanks, Fabio.
[06:24] <jdub> ]  && {
[06:24] <jdub> well
[06:24] <jdub> without the typo
[06:24] <jdub> rad
[06:27] <infinity> Also, that was always wrong anyway..
[06:28] <infinity> That should be an OR, not an AND...
[06:42] <pitti> Good morning
[06:42] <ajmitch> hi pitti 
[06:43] <fabbione> hey pitti
[06:43] <Hobbsee> hey pitti!
[06:44] <pitti> hey ajmitch
[06:44] <Hobbsee> ooh, group hug.  dont let me get squished :P
[06:45] <fabbione> Hobbsee: did you ever file a bug for that ubuntulog thingy?
[06:45] <fabbione> pitti: that's because you are skinny :)
[06:45] <Hobbsee> fabbione: no, it's on my mental to-do list, or just to bug you when you had stopped talking
[06:46] <Hobbsee> hah
[06:46] <fabbione> pitti: take my 1.82 and add the power of the size :P
[06:59] <keescook> hiya pitti
[07:00] <pitti> hi keescook, how are you?
[07:00] <keescook> great! you?  I was just digging around in malone, and thought I'd build a fix for the clamav cve...
[07:01] <keescook> the control file reverted the Standards-Version from 3.7.0 to 3.6.2, and I don't know why... :P
[07:04] <Burgundavia> whiprush: http://ubuntuforums.org/showthread.php?t=259210
[07:05] <whiprush> looking
[07:05] <Burgundavia> ajmitch: you had better be at Mountainview
[07:06] <ajmitch> Burgundavia: unlikely, it'd require sponsorship
[07:07] <whiprush> wasabi left a good comment on my blog post yesterday about this stuff.
[07:09] <pitti> keescook: some buglet introduced by merging; feel free to revert
[07:09] <keescook> pitti: yeah, sorta dropped that part of the debdiff (see bug 59915)
[07:09] <Ubugtu> Malone bug 59915 in clamav "clamav in dapper vulnerable to critical heap overflow" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59915
[07:10] <ajmitch> whiprush: yeah, I should make some notes on that stuff..
[07:10] <pitti> keescook: apart from the version number, this looks good
[07:10] <ajmitch> like I have the code for getting the info from SRV records, etc
[07:11] <keescook> pitti: what should the version number be? 1.1 instead of 2?
[07:11] <pitti> keescook: exactly
[07:11] <Burgundavia> whiprush: holy crap "In order to address this gap, Red Hat, Novell, Ubuntu and others must work together. It will require a concentrated combined effort that draws together expertise from a wide variety of sources. That way, Linux application developers could work with a standardardized but modularized tool.," Ted Haeger
[07:11] <whiprush> ajmitch: I am going to start speccing some of the other stuff
[07:11] <pitti> keescook: also, can you please state the origin of the patch in the changelog?
[07:11] <Burgundavia> ok, ted is bloody brilliant
[07:11] <keescook> pitti: okay, adjusting
[07:11] <pitti> keescook: (upstream cvs, other distro, some other bug report, etc)
[07:11] <ajmitch> whiprush: yeah, I'd love to sit down with you & some beers :)
[07:12] <whiprush> put in for sponsorship, you never know. *shrug*
[07:12] <ajmitch> whiprush: written my name down
[07:12] <whiprush> sweet
[07:12] <pitti> keescook: building coreutils now, btw
[07:13] <keescook> pitti: okay, cool.  FYI, I needed to give debuild -e SHELL to pass the weird dircolors test.
[07:14] <keescook> pitti: is "Patch from upstream version 0.88.4." sufficient, or should I be even more explicit?
[07:14] <pitti> keescook: that's fine
[07:14] <pitti> keescook: just that we can track whether we invented it ourselves, or where it came from
[07:14] <ajmitch> whiprush: I'd love to spec out some of the desktop love that's needed soon
[07:14] <pitti> keescook: e. g. sometimes we take them from fedora bug report attachments, etc
[07:18] <ajmitch> pitti: we'll probably want new libpam-{krb5,heimdal} to go along with krb5, I'll file for syncs later tonight
[07:18] <pitti> ajmitch: I only requested a sync for the security update, it shouldn't change any API/ABI?
[07:18] <ajmitch> it shouldn't, but I still want them :)
[07:19] <ajmitch> seeing the bug just reminded me of it
[07:19] <pitti> ok, so it doesn't need coordination
[07:19] <ajmitch> oh, and I uploaded libgphoto2 without libhal-dev change, in case you get a flood of bugs :)
[07:20] <keescook> pitti: okay, 59915 has been updated with a better debdiff.
[07:23] <pitti> keescook: thanks; will upload today
[07:24] <Burgundavia> whiprush: another interesting piece for today, via planet gentoo: http://blog.stuartherbert.com/gentoo.php/2006/09/17/are_we_on_the_rpath
[07:30] <keescook> pitti: I emailed you a "details" section for clamav, I'm off to bed.  :)  
[07:30] <pitti> keescook: thanks; sleep well!
[07:31] <pitti> keescook: oh, a minute please
[07:31] <keescook> yup, still here
[07:47] <dholbach> good morning
[07:49] <poningru> dholbach: saw your hackergotchi in a magazine couple of days ago
[07:49] <pitti> hey dholbach 
[07:50] <dholbach> heya pitti - hey poningru
[07:50] <dholbach> poningru: which one was that?
[07:50] <dholbach> poningru: linux format something?
[07:50] <dholbach> hey slomo
[07:51] <poningru> yeah linux format
[07:51] <poningru> http://www.flickr.com/photos/puggles/244944977/
[07:51] <poningru> that shows the magazine cover
[07:52] <dholbach> they wrote "dan holbach"
[07:53] <dholbach> nobody on earth calls me "dan", but anyway - i got my "best bits" coverd - LOL! :)
[07:54] <dholbach> (it said "dan's best bits" above a tiny piece of text they quoted me on)
[07:55] <dholbach> btw. Happy REVU day!
[08:43] <ajmitch> desrt: you know you want a group hug
[08:47] <ajmitch> hi Kamion 
[08:48] <Kamion> morning
[08:48] <pitti> Hi Kamion 
[08:48] <dholbach> hi Kamion
[09:01] <carlos> pitti: morning
[09:01] <pitti> hi carlos 
[09:02] <carlos> pitti: so, what should I do with dapper lang packs? touch those .po files?
[09:02] <carlos> or will you use the tarball I gave you?
[09:02] <pitti> carlos: if you can, yes; as I said, otherwise I need to hack my scripts to incorporate them at every build, but that's not going to be very robust
[09:03] <carlos> ok, I will do it then
[09:03] <pitti> carlos: don't you have access to the db to touch the timestamps of the affected packages with a script?
[09:03] <carlos> did you upload a new lang pack for dapper already?
[09:03] <pitti> carlos: I must not upload to *-updates ATM
[09:03] <carlos> pitti: yeah, but that changes some metadata, that's why I tried to find another solution
[09:03] <carlos> pitti: ok
[09:04] <fabbione> ok.. let's give a shot to d-i on sparc
[09:05] <pitti> fabbione: (I don't know what you are up to, but I did not release the new kernel to the official archive yet)
[09:06] <fabbione> pitti: yes i am aware of that. the problem arise once we delete the old ABI kernel from the archive
[09:06] <fabbione> pitti: at that point d-i netboot/netinstall won't be able to fetch the udeb
[09:06] <fabbione> and so it needs to be updated
[09:06] <pitti> yes
[09:06] <fabbione> for the old releases we didn't really care
[09:07] <fabbione> but now we do support a netboot/netinstall only machine
[09:07] <fabbione> and we care
[09:07] <fabbione> anyway there is no hurry
[09:07] <fabbione> untill there is the old kernel everything is good
[09:09] <dholbach> weird, LP says that pilot-link 0.12.1-3 has built on all arches (2 days ago), it has no new binary packges, but is not in the archive yet
[09:33] <infinity> dholbach: Let me look around.
[09:35] <dholbach> infinity: thank you
[09:36] <infinity> It was accepted...
[09:37] <infinity>          | N libpisock9/0.12.1-3/i386 Component: main Section: libs Priority: OPTIONAL
[09:37] <infinity> SONAME bump?
[09:37] <infinity> Indeed.
[09:37] <infinity> dholbach: It was binary NEW.  SONAME bump.
[09:38] <infinity> dholbach: Check "apt-cache rdepends libpisock8"... Are you ready to upload to rebuild all of those after I pass this through NEW?
[09:38] <dholbach> oh?
[09:38] <dholbach> happy to do so
[09:38] <infinity> Alright.  I'll process it now, then.
[09:39] <dholbach> thank a lot!
[09:39] <dholbach> gnome-pilot{,-conduits} should be done soon, I'll look after the others
[09:40] <infinity> Alright.  Processed and accepted.
[09:40] <infinity> Thank you for shopping at #ubuntu-devel.  Please, come again.
[10:17] <dholbach> woohoo, knot-3 in the news: http://www.golem.de/0609/47851.html
[10:18] <seb128> rock :)
[10:23] <HiddenWolf> dholbach: nice article. :)
[10:26] <cbx33> hi sladen 
[10:33] <sladen> seems NickServ ate my instructions to sivang for finding my house!
[10:33] <StevenK> sladen: Hopefully, you can remember how to get to your house.
[10:43] <popey> lo cbx33 
[10:47] <cbx33> hi popey 
[10:48] <cbx33> how are you?
[10:55] <slomo> fabbione: pong
[10:55] <fabbione> slomo: do I remember right that you were pinging me for mono on sparc?
[10:56] <fabbione> mvo: hey dude
[10:56] <fabbione> mvo: could you be so kind to fix bug 59403 ?
[10:56] <Ubugtu> Malone bug 59403 in gnome-app-install "g-a-i postinst fails if X is not running" [Critical,Needs info]  http://launchpad.net/bugs/59403
[10:57] <slomo> fabbione: yes... but the build failure happened only the first time... the 3 uploads afterwards worked fine although nothing sparc specific was changed ;)
[10:57] <fabbione> slomo: ok perfect. it was probably a kernel/toolchain issue that has been fixed
[10:59] <slomo> fabbione: maybe... but the second upload was only a few hours later :) well, let's hope it never shows up again
[10:59] <fabbione> hmm ok
[11:01] <mvo> fabbione: having a look now
[11:01] <fabbione> mvo: thanks
[11:06] <pitti> aah, mvo, good morning
[11:06] <mvo> hey pitti
[11:07] <dholbach> heya mvo
[11:15] <jordi> mvo: AHA
[11:15] <jordi> mvo: finally!
[11:15] <jordi> mvo: where doyou get the po files for the "Package Descriptions" product?
[11:16] <mvo> jordi: hello!
[11:17] <mvo> jordi: https://launchpad.net/products/ddtp-ubuntu/+translations
[11:22] <jordi> mvo: okay
[11:22] <jordi> mvo: where did a "go.po" come from then?
[11:22] <mvo> jordi: probably from debian, I importet the current state of the debian translations
[11:22] <mvo> jordi: (from ddtp.debian.net)
[11:22] <jordi> what is "go"? There are several broken files in there: km_KH, pl_PL, go
[11:22] <jordi> mvo: oh I see.
[11:23] <jordi> I'll ping bubulle then
[11:24] <mvo> jordi: where is this go.po? I can't find it now
[11:24] <jordi> https://launchpad.net/rosetta/imports?target=products&status=NEEDS_REVIEW&type=all
[11:25] <jordi> heh
[11:25] <jordi> empty fil
[11:25] <jordi> +e
[11:25] <mvo> jordi: uh, I see. what will rosetta do with them? it looks like my script can produce them
[11:26] <mvo> jordi: if this is a problem, I can fix it
[11:28] <jordi> mvo: rosetta doesn't know what to do
[11:28] <jordi> so I can either delete them or block them
[11:28] <mvo> jordi: just delete them, I will add more logic to my script to make sure it does not produce empty files
[11:29] <jordi> ok
[11:31] <mvo> fabbione: in bug #59403, do you have DISPLAY set at all?
[11:31] <Ubugtu> Malone bug 59403 in gnome-app-install "g-a-i postinst fails if X is not running" [Critical,Needs info]  http://launchpad.net/bugs/59403
[11:31] <fabbione> mvo: no, it's not set..
[11:31] <fabbione> mvo: no more no less like when you login as root on console
[11:31] <fabbione> DISPLAY=""
[11:31] <jordi> mvo: what about the dupes? pl_PL vs pl
[11:32] <jordi> oh, empty files as well
[11:32] <mvo> fabbione: at least the later version of gtk can deal with this and won't die
[11:32] <fabbione> mvo: ok..
[11:32] <mvo> jordi: I guess that comes from inconsitency between rosetta and ddtp.d.o. rosetta always uses the full name and ddtp almost always the short language code
[11:33] <mvo> jordi: I have seen this for other translations as well (people translating pl and pl_PL independently)
[11:33] <mvo> jordi: (in the past)
[11:33] <kagou> iwj, i'v always bug in fontconfig-config
[11:33] <Tonio__> hi
[11:33] <jordi> mvo: it's bad
[11:34] <mvo> jordi: I totally agree. so what can we do :) ?
[11:34] <jordi> mvo: rosetta did, in the past. Not anymore
[11:35] <jordi> or it shouldn't.
[11:35] <jordi> that's why I'm nagging here :P
[11:35] <mvo> jordi: so what can I do? rename them all from pl -> pl_PL (etc) ?
[11:36] <jordi> if it's safe, yeah: ie, not both of them exist
[11:37] <jordi> if there's a conflict like sv vs sv_SE, I guess we need bubulle
[11:37] <kagou> iwj, i talk about Bug #56682
[11:37] <Ubugtu> Malone bug 56682 in fontconfig "Raster fonts appear in Edgy" [Medium,In progress]  http://launchpad.net/bugs/56682
[11:38] <mvo> jordi: some of the conflicts are probably due to the fact that I imported them as they where (e.g. sv) and that then some people started to translate them in rosetta and created sv_SE along the way). does that make sense?
[11:39] <jordi> not really
[11:39] <jordi> because the sv_SE file was uploaded by you, ie, it's one of the initial files
[11:39] <jordi> sv_SE.po in Package Descriptions for Ubuntu Series: ubuntu   	 	 [Edit] 
[11:39] <jordi> Uploaded by Michael Vogt on 2006-08-08 18:33:23 CEST
[11:41] <iwj> kagou: Hi.
[11:41] <mvo> jordi: its not on ddtp.debian.net though, so probably my bad somehow
[11:42] <jordi> mvo: weird
[11:42] <jordi> mvo: killing it
[11:42] <kagou> hey iwj :)
[11:42] <mvo> jordi: thanks, I will investigate
[11:45] <iwj> kagou: Can you say   echo 'get fontconfig/enable_bitmaps' |debconf-communicate
[11:45] <iwj> and tell me what it says ?
[11:46] <kagou> iwj, one minut, i power on my notebook, cause i'v do some hacking on fontconfig here ;)
[11:46] <iwj> Right ...
[11:48] <kagou> iwj,  said : 0 true
[11:49] <iwj> And you did dpkg-reconfigure after installing 2.3.2-7ubuntu2 ?
[11:49] <kagou> iwj, i think not
[11:50] <kagou> but i'm not sure now, cause i'v did many things since
[11:50] <iwj> Hmm.
[11:51] <iwj> Well, you have 2.3.2-7ubuntu2 (or something later) now, right ?  And does dpkg-reconfigure --default-priority fontconfig-config  fix it ?
[11:51] <iwj> You'll have to reinstall the .deb too.
[11:51] <iwj> (Maybe.)
[11:52] <iwj> Morning sabdfl.
[11:52] <sabdfl> hi folks
[11:52] <ajmitch> hi sabdfl 
[11:52] <sabdfl> evening ajmitch
[11:52] <kagou> iwj, no. doing dpkg-reconfig --default-priority create 30-debconf-yes ... in all case
[11:52] <pitti> hey sabdfl
[11:52] <kagou> hi sabdfl 
[11:54] <fabbione> hey sabdfl 
[11:55] <kagou> iwj, by "in all cases" i mean that if i already have a "30-debconf-yes..." OR NOT doing reconfigure create it
[11:55] <iwj> For me, it always recreates 30-debconf-no-...
[11:56] <iwj> Can you email me copies of your /var/lib/dpkg/info/fontconfig-config.config and .postinst ?
[11:56] <iwj> iwj@ubuntu.com
[11:56] <iwj> This is very mysterious.
[11:58] <iwj> Oh, I'm misunderstanding what dpkg-reconfigure does.
[11:58] <iwj> pitti: Freaky.  You must have a virus.
[11:58] <pitti> iwj: sometimes it works, sometimes not. Smells like a race condition
[12:01] <kagou> iwj, done
[12:03] <kagou> iwj, have "db_input mpw fontconfig/enable_bitmaps || true" in .config may be it's the problem ?!
[12:04] <kagou> sorry -> have "db_input low fontconfig/enable_bitmaps || true" in .config may be it's the problem ?!
[12:04] <imbrandon> moins sabdfl and Keybuk 
[12:06] <iwj> kagou: No, that's normal and just causes the question to (perhaps) be asked.
[12:07] <Tonio_> imbrandon: gwenview builds, I'm writing main inclusion report now
[12:08] <imbrandon> umm a UVFe you mean ;)
[12:08] <Keybuk> mvo: do you have ubuntu-minimal installed?
[12:08] <Tonio_> imbrandon: just woke up, forget this ;)
[12:08] <mvo> Keybuk: yes
[12:08] <Tonio_> Keybuk: yep
[12:09] <seb128> carlos: around?
[12:09] <mvo> Keybuk: everything up-to-date etc
[12:09] <mvo> Keybuk: how can I turn it into debug mode? 
[12:09] <carlos> seb128: hi
[12:09] <seb128> hey carlos
[12:09] <Keybuk> mvo: boot with --debug
[12:09] <seb128> carlos: how do I know when the template for a package has been imported to rosetta, from what version of the source package it's coming?
[12:09] <mvo> Keybuk: I also did not get any checkrootfs messages on a different machine
[12:10] <Keybuk> mvo: that's a different bug
[12:10] <carlos> seb128: I don't have that information stored, but I can give you the date when the POT was generated
[12:10] <mvo> Keybuk: init=/sbin/init --debug? 
[12:10] <seb128> carlos: I'm wondering what version of gtk+2.0 src package for gtk20
[12:10] <carlos> seb128: and once I fix some permissions issues, you should be able to see it tooo
[12:10] <Keybuk> mvo: yes
[12:10] <seb128> carlos: would be nice, thank you
[12:11] <carlos> seb128: we are a bit behind on those, I'm approving them atm, we still don't support paths with the version of the release
[12:11] <carlos> so we need to approve them manually
[12:11] <seb128> carlos: it's about https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/60614 in fact
[12:11] <Ubugtu> Malone bug 60614 in gtk+2.0 "Wrong string in gtk20 po file" [Untriaged,Needs info]  
[12:11] <mvo> Keybuk: ok, thanks! I do this now and let you know the results
[12:12] <Keybuk> mvo: ok, I've got to pop out for a quick bit -- will be back soon
[12:12] <mvo> Keybuk: ok
[12:13] <jsgotangco> its fast for sure
[12:16] <iwj> kagou: Well, I have done a lot of experiments and I have concluded: 1. purging fontconfig-config and reinstalling it restores everything to normality as expected (dpkg --purge --force-depends; dpkg -i);  2. It is possible to fix it with  echo PURGE | debconf-communicate fontconfig-config   and then   dpkg-reconfigure --default-priority fontconfig-config   3. I don't understand debconf properly.
[12:16] <iwj> Nevertheless I'm convinced that new installs will be correct.
[12:16] <iwj> And upgrades from dapper should be good too.
[12:16] <seb128> carlos: thank you for updating the bug and reassigning
[12:16] <carlos> seb128: you are welcome
[12:16] <kagou> iwj, i will do fresh install with the daily iso tommorrow
[12:17] <seb128> carlos: did you figure from when is the current template? just curious about it :p
[12:17] <iwj> Thanks.
[12:17] <kagou> iwj, your welcome
[12:17] <iwj> If you want your own install fixed, I suggest the purge/reinstall.
[12:17] <kagou> iwj, i test this. thanks
[12:17] <iwj> If that doesn't work please let me know :-).
[12:17] <kagou> =)
[12:18] <carlos> seb128: well, when you pinged me, I think a new .pot file was imported already
[12:18] <carlos> what's current version?
[12:18] <carlos> in edgy
[12:18] <seb128> 2.10.3
[12:18] <carlos> seb128: ok, then I think it was 2.10.0 (same problem with glib)
[12:19] <seb128> carlos: ok, that explains the mismatch with upstream then, it has been changed for 2.10.2
[12:21] <kagou> iwj, it's working
[12:22] <thom> hrm, firefox beta2 seems much less stable for me :(
[12:25] <jsgotangco> yeah
[12:30] <iwj> kagou: *phew*  Thanks for your help and sorry for the run-around.
[12:33] <Tonio_> pitti: ping ?
[12:34] <mvo> Keybuk: sorry for the noise, it seems my laptop problem was just a "can't see messages from fsck" problem. 
[12:40] <Treenaks> I think I might have set a new record..
[12:40] <Treenaks> 13784 mstreek   22   5 1804m 1.6g  536 D    0 80.7   0:09.45 objcopy                                
[12:40] <ajmitch> Treenaks: not bad
[12:40] <Treenaks> ajmitch: that's firefox + java + crash
[12:41] <ajmitch> yeah, I had firefox using 1.0GB RSS
[12:41] <kagou> iwj, in fact i will test fresh daily iso installation, when they will be available again ;)
[12:41] <ajmitch> so you have me beaten
[12:41] <ajmitch> I didn't get to use java though :)
[12:41] <StevenK> My firefox is a wimpy 300Mb
[12:42] <giftnudel> hmm, i had eclipse with 8xx ... ;)
[12:42] <Treenaks> ajmitch: this is apport's objcopy...
[12:42] <StevenK> However, Quod Libet is 400.
[12:42] <Treenaks> and now I ahve to reboot (OOPS)
[12:42] <Treenaks> brb
[12:42] <ajmitch> ouch
[12:43] <Fujitsu> ajmitch, it has a habit of doing that.
[12:43] <iwj> kagou: *snort*
[12:45] <iwj> IBM updated the bios in my laptop and now usplash works.  Oh well, so much for that prospective bug report.
[12:45] <kagou> sorry iwj , what is *snort* :)
[12:45] <iwj> It's a short nasal kind of laugh.  gnrgkl or some such.
[12:45] <kagou> ok :p
[12:45] <iwj> nasal/guttural.
[12:46] <jdub> it's what iwj does when your joke isn't funny enough for a laugh
[12:46] <iwj> ROTFL
[12:46] <jdub> unlike that one! score!
[12:46] <Fujitsu> Hey jdub :)
[12:46] <crispin> pitti: any thoughts on where to do with my tracking down of the race in bug #55809 ?
[12:46] <Ubugtu> Malone bug 55809 in hal "HAL changes wireless interface (net.80211) to wired (net.80203) in info.category after suspend" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55809
[12:50] <Kamion> kagou: (I just turned the cron jobs back on)
[12:50] <Kamion> (for cdimage)
[12:52] <kagou> Kamion, nice ! thanks
[01:18] <Treenaks> ok.. my Nvidia + usplash = broken output; that + fsck = 'WTF isn't my machine booting?!?'
[01:20] <Fujitsu> Treenaks, you can't see fsck output anyway, with upstart.
[01:21] <HiddenWolf> Treenaks: +1 on that one
[01:30] <Keybuk> mvo: ah ok
[01:32] <mvo> Keybuk: what needs to be done to get the checkfs messages to the terminal?
[01:32] <Keybuk> mvo: need to modify the checkfs script somehow
[01:32] <Keybuk> it should also send them to uslash, you see
[01:35] <Fujitsu> Keybuk, that'd be good.
[01:39] <fabbione> Treenaks: same reason i was offline 3 hours yesterday
[01:39] <fabbione> Treenaks: couldn't figure out why my machine did hang at boot (HI SCOTT!)
[01:41] <Keybuk> hmm?
[01:41] <Fujitsu> fabbione, that's got me a few times, but then I noticed the HDD access.
[01:41] <fabbione> Keybuk: no fsck output to usplash or no output at all...
[01:41] <Fujitsu> Keybuk, fsck isn't visible at boot any more. Confuses everybody.
[01:41] <seb128> StevenK: ?
[01:41] <Keybuk> fabbione: blah blah blah
[01:41] <fabbione> Fujitsu: i don't have such luxury.. the 700GB raid was on another controller with no led
[01:41] <fabbione> Keybuk: ;)
[01:41] <StevenK> seb128: Ahh ha, someone to help.
[01:41] <Fujitsu> Hahahah.
[01:42] <fabbione> Keybuk: i didn't yell at you.. come on.. it was sunday ;)
[01:42] <StevenK> seb128: http://librarian.launchpad.net/4295062/buildlog_ubuntu-edgy-amd64.diacanvas2_0.14.4-3_FAILEDTOBUILD.txt.gz
[01:42] <seb128> StevenK: https://launchpad.net/distros/ubuntu/+source/pygobject/+bug/57182
[01:42] <Ubugtu> Malone bug 57182 in pygobject "Problem importing codegen from desextras" [Medium,Confirmed]  
[01:43] <StevenK> Ah ha!
[01:43] <seb128> StevenK: thank you for working on it ;)
[01:43] <ajmitch> great to have willing volunteers, isn't it?
[01:43] <seb128> exactly!
[01:43] <seb128> :)
[01:44] <StevenK> :-P
[01:44] <Fujitsu> Hey, there are a few bugs blocked on that.
[01:45] <StevenK> Fujitsu: Feel free to help.
[01:45] <Fujitsu> I've got no idea about it :P
[01:46] <ajmitch> wasn't bddebian looking into that?
[01:47] <StevenK> Fujitsu: You mean you don't know Python? :-P
[01:47] <Fujitsu> StevenK, I know Python quite well.
[01:49] <StevenK> Right. There's a problem in pygobject, and another in diacanvas2
[01:49] <pitti> Tonio_: pong
[01:50] <pitti> crispin: not yet, sorry
[01:50] <Fujitsu> diacanvas2's is easy to fix, but I'm not sure about pygobject's.
[01:51] <StevenK> Yes, diacanvas2's is fix the override file
[01:52] <StevenK> Hah, and now that I fix the override file.
[01:52] <StevenK> ERROR: Could not find a recent version of pygtk.
[01:52] <StevenK> Oh wait, for python2.5
[01:53] <Fujitsu> Yes, it does that.
[01:53] <StevenK> Right, fixed it.
[01:53] <StevenK> Do we care that we don't have a 2.5 version of diacanvas2?
[01:53] <Fujitsu> The whole thing?
[01:54] <Fujitsu> Until we get pygtk for 2.5, I don't think so.
[01:54] <StevenK> With a bit of work, I can produce a patch for diacanvas2, and also one for pygobject
[01:55] <seb128> Fujitsu, StevenK: somebody should probably forward the pygobject issue upstream
[01:56] <Fujitsu> Probably, yes...
[01:56] <Fujitsu> Ah.
[01:56] <Fujitsu> Part of pyGTK, of course.
[01:57] <StevenK> seb128: Sure, but we should be selfish and fix our version first?
[01:57] <mvo> Keybuk: one more question about upstart. I just switched to my terminal from X with C-A-F1 and did some stuff in the shell, then loged out (CTRL-D) again. now I can't type anything anymore and ALT-Fn is no longer working. could this be releated to upstart?
[01:57] <StevenK> s/\(we\) \(should\)/\2 \1/
[01:57] <Fujitsu> StevenK, we've got universe freeze shortly, so I presume so.
[01:58] <seb128> StevenK: why not working with upstream, they might be useful and fix it faster the we do :p
[01:58] <StevenK> Fujitsu: pygobject is in man
[01:58] <StevenK> Um
[01:58] <StevenK> main
[01:58] <Fujitsu> Hm.
[01:58] <Fujitsu> So it is.
[01:58] <StevenK> seb128: Oh, I know why.
[01:58] <seb128> why what?
[01:58] <StevenK> seb128: Because that involves touching bugzilla.
[01:58] <Fujitsu> StevenK, urgh.
[01:58] <StevenK> And dun wanna, icky
[01:59] <seb128> StevenK: such comment are not really useful ...
[01:59] <Fujitsu> I'd say bug #60583 was a dupe...
[01:59] <Ubugtu> Malone bug 60583 in gst-python "FTBFS: RuntimeError: Function gst_pad_get_negotiated_caps is being overridden more than once" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60583
[01:59] <seb128> no
[01:59] <seb128> that one looks a python2.5 being stricter
[01:59] <StevenK> seb128: True, but I like whinging.
[02:00] <Keybuk> mvo: I don't think so ...
[02:00] <Keybuk> Alt-Fn not working implies the kernel has panic'd ?
[02:00] <Fujitsu> Of course, Launchpad was designed to prevent this sort of business.
[02:01] <StevenK> I can't see Launchpad logging into Gnome's bugzilla and creating a report for me. :-P
[02:01] <mvo> Keybuk: no, I just can't use ALT-F1,2,3 etc. strnage enough, CTRL-ALT-F7 brings me back to X (and C-A-Fn works as well)
[02:01] <ajmitch> StevenK: magic
[02:01] <mvo> Keybuk: and only after I logout of one terminal with CTRL-D
[02:02] <StevenK> ajmitch: Heh
[02:02] <Keybuk> mvo: does that getty not respawn?
[02:03] <mvo> Keybuk: it does. maybe just something entirely different.
[02:03] <Keybuk> hmm?
[02:03] <zul> hello
[02:04] <ajmitch> hey zul 
[02:04] <Keybuk> so after the getty dies, the new one spawns, but you can't type into it?
[02:04] <mvo> Keybuk: yes. but apparently I can not reproduce it all the time :( 
[02:05] <hunger> How do I configure my console keymap to use a layout available in my X setup but which is not part of ubuntu?
[02:05] <pitti> fabbione: do you have an idea why so many packages still depend on libgnutls12 on sparc? all other main arches don't have any dependency on it any more in main
[02:06] <Keybuk> mvo: odd, let me see here
[02:06] <Keybuk> the fact your keyboard goes away is a little strange
[02:06] <fabbione> pitti: no i don't check these kind of things...
[02:06] <fabbione> pitti: do you know what pkgs are?
[02:07] <mvo> Keybuk: I had this two time now, since the weekend (when I upgraded this machine), but it might as well be some X problem or something
[02:07] <pitti> fabbione: yes, a minute
[02:07] <hunger> Is console-setup known to crash the X server by the way?
[02:07] <fabbione> pitti: also.. when we did switch version, did you also add a versione B-D ?
[02:07] <fabbione> versioned even
[02:08] <pitti> fabbione: http://pastebin.ca/174992
[02:08] <fabbione> if not, you might have uploaded the other packages in a limbo state when gnutls13 was not yet available for sparc
[02:08] <Keybuk> mvo: yeah, I would suspect X or console-setup to be likely ... as they actually do things with the keyboard
[02:08] <Keybuk> I took the "reset the console" code out of upstart
[02:08] <pitti> fabbione: hm, we switched version almost two months ago
[02:08] <mvo> Keybuk: ok, thanks!
[02:08] <fabbione> pitti: have been these pkgs rebuilt since? are the binaries in the archive?.
[02:08] <pitti> fabbione: for most packages I didn't bother to actively transition them, it just happened over time
[02:09] <pitti> fabbione: I just cleared the last four some days ago
[02:09] <fabbione> pitti:  i don't know.. this is something you need to clear with infinity and LP.
[02:09] <pitti> fabbione: libgnutls-dev_1.4.0-3_sparc.deb     04-Jul-2006 21:18  359K
[02:09] <pitti> fabbione: ok, I'll ask infinity 
[02:10] <fabbione> pitti: it's much easier for infinity to check what went wrong than for me
[02:10] <fabbione> he has access to all infrastructure
[02:10] <fabbione> while i would have to do everything manually
[02:10] <pitti> fabbione: ok, I just wanted to know whether there was a specific issue with 13 I didn't know about
[02:10] <pitti> fabbione: thanks
[02:10] <fabbione> i only heard about the transition a few days back at the meeting
[02:11] <fabbione> and wasn't able to check much for the past weeks
[02:11] <pitti> fabbione: do we have a sparc developer box in the DC with a current edgy chroot?
[02:11] <fabbione> faure.ubuntu.com
[02:11] <pitti> ah, nice
[02:11] <fabbione> it's always been there since.. dapper
[02:11] <pitti> fabbione: yeah, sorry, I don't deal with it much, so I forgot
[02:12] <fabbione> pitti: you lazy boy :P
[02:12] <pitti> fabbione: feh, it seems that just the sparc mirror on rookery is out of date
[02:13] <pitti> fabbione: ah, it appears in anastacia as it should be
[02:13] <fabbione> #!@!!!!!!
[02:13] <pitti> fabbione: sorry, dude, up to a few weeks ago the mirror was just fine
[02:13] <administrator> how do you undone /ignore?
[02:13] <fabbione> don't worry
[02:14] <administrator> undo*
[02:16] <pitti> Keybuk: can you please demote gnutls12, just to be sure no main package will pick it up again?
[02:17] <Keybuk> done
[02:35] <Keybuk> odd, X crashed
[02:36] <Mithrandir> Kamion: https://launchpad.net/distros/ubuntu/+source/xorg-server/+bug/58016 ; this looks like a bad xkeyboard-config default, but is it correct that live keys would be preferred in the UK?
[02:36] <Ubug2> Malone bug 58016 in xorg-server "Edgy choice of UK Dead Keys Layout in Gnome" [Low,Confirmed]  
[02:41] <Keybuk> did mdz flush an old mail out of his queue or something?
[02:41] <pitti> probably mailman administration
[02:42] <Fujitsu> Burgundavia cleaned the spam filter 48 hours ago...
[02:43] <Hobbsee> yes.  unfortunately :P
[03:15] <Kamion> Mithrandir: I have the fix for that in hand, although I don't know how to deal with upgrades
[03:15] <Kamion>     uk) XMAP="gb"; VARIANT="intl";;
[03:15] <Kamion> ^-- retarded
[03:15] <Mithrandir> so UK people don't want dead keys?
[03:15] <Kamion> hell no
[03:16] <Mithrandir> heh, 'k
[03:16] <Kamion> I'll upload the fix for fresh installs now
[03:16] <Kamion> dead keys produce a "WTF" reaction here
[03:18] <abattoir> Kamion: hi, are you aware of http://paste.ubuntu-nl.org/23877 ?
[03:19] <jdong> bad archive! stop your md5sum mismatching!
[03:21] <Kamion> abattoir: oops, yes, I have a fix for that pending upload
[03:21] <abattoir> Kamion: i also noticed that /usr/sbin/oem-config doesnt have the option for kde-ui, could you add that too?
[03:21] <Kamion> abattoir: sure
[03:22] <abattoir> Kamion: and i have fixed the indenting too
[03:22] <jdong> Kamion: was ubiquity supposed to work in knot3?
[03:22] <Mithrandir> jdong: no, we just released it for the heck of it.
[03:22] <Kamion> what he said
[03:22] <jdong> Mithrandir: seriously or sarcastically?
[03:22] <Mithrandir> (what do you think?  Yes, of course it was supposed to work)
[03:23] <Mithrandir> we spent resources on testing, we don't tend to do that just for the heck of it.
[03:23] <jdong> well, the installation didn't launch at all on my amd64
[03:23] <jdong> it would backtrace on launch
[03:23] <Mithrandir> worked for me
[03:23] <jdong> so I forced it to dist-upgrade on the livecd....
[03:23] <Kamion> file a bug please
[03:23] <jdong> then it would launch
[03:23] <Kamion> with the traceback and the logs
[03:23] <Kamion> like the error message tells you to
[03:23] <jdong> k, when I get a chance to, I'll regenerate the error
[03:24] <Kamion> asking on IRC at random intervals is about the least productive way to draw my attention to a ubiquity problem. :)
[03:25] <jdong> sorry, I was just making sure it wasn't a known issue
[03:25] <Kamion> I'd rather you filed a potential duplicate
[03:26] <jdong> k, duly noted for the future
[03:26] <Kamion> *much* rather
[03:26] <Hobbsee> Mithrandir: *g* @ the response
[03:28] <carlos> Riddell: hi, around?
[03:30] <Riddell> hi carlos 
[03:30] <carlos> Riddell: hi
[03:30] <carlos> Riddell: I would like to know what should I do about https://launchpad.net/bugs/58579
[03:30] <Ubug2> Malone bug 58579 in kopete "no kopete translations in edgy" [Untriaged,Confirmed]  
[03:30] <carlos> Riddell: should I wait until new KDE to import the new .pot file?
[03:31] <carlos> or import it right now and move it from the old package to the new kopete one?
[03:31] <Riddell> carlos: I would say so yes, else we'll have more duplication than normal
[03:31] <Riddell> carlos: wait that is
[03:31] <carlos> Riddell: ok
[03:32] <Riddell> Hobbsee: what for?
[03:32] <Hobbsee> the kopete stuff
[03:32] <carlos> Riddell: thanks for the input
[03:32] <Hobbsee> seeing as i'm usually the one who changes it
[03:32] <Hobbsee> and we're keeping the source split, right?
[03:33] <jdong> Kamion: can I ask you about when/if #58139 is to be decided upon?
[03:33] <Riddell> Hobbsee: yes
[03:33] <jdong> *ahem* bug 57139
[03:33] <Ubug2> Malone bug 57139 in linux-source-2.6.17 "Add lm-sensors support for nForce 410 and 430" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57139
[03:33] <jdong> not that one
[03:33] <Hobbsee> Riddell: good
[03:33] <jdong> bug 58139
[03:33] <Ubug2> Malone bug 58139 in ktorrent "UVF exception request ktorrent 2.0.1 -> 2.0.2" [Low,Unconfirmed]  http://launchpad.net/bugs/58139
[03:33] <jdong> that one
[03:34] <Kamion> jdong: I hadn't seen the new information on the bug yet because I'm very behind on my bugs folder; I've queued it up for my review now
[03:35] <jdong> Kamion: ok, thanks. The bug it fixes is quite irritating.. large downloads just stop going after a while
[03:41] <infinity> mvo: Around?
[03:42] <mvo> infinity: yes, hello
[03:43] <dholbach> Riddell: I'll do a no-changes rebuild upload for kdepim (libpisock8 -> libpisock9), is that ok with you?
[03:43] <Riddell> dholbach: sure
[03:44] <infinity> mvo: It's been brought up in #debian-release that app-install-data probably contains non-free data (acrobat icon and such), and our own app-install-data-commercial would obviously suffer similar issues.  We ship both in main, and Debian's is in main as well, of course.
[03:44] <dholbach> Riddell: excellent
[03:44] <infinity> mvo: Can you think of any clever way to resolve that?
[03:44] <infinity> mvo: (In Debian, the easiest solution is probably just to replace the icons with free alternatives, not sure what you want to do for Ubuntu)
[03:45] <mvo> infinity: I never uploaded it to debian and I very much doubt that whoever uploaded it re-ran it over the debian archive (also I may be wrong here of course). my advice for debian would be to remove it because it is likely to contain incorrect data (for debian) anyway
[03:45] <infinity> mvo: We do commit to main being free, but since you want g-a-i to depend on app-install-data-commercial, that gets tricky.
[03:46] <infinity> mvo: Ahh, that wasn't your doing.  Check.
[03:46] <mvo> infinity: ubuntu is more tricky :/
[03:47] <mvo> infinity: we could make app-install-data-commercial a recommends of ubuntu-desktop. this way people can easily get rid of it at least
[03:47] <infinity> mvo: But where do we ship it?
[03:48] <infinity> mvo: We don't enable -commercial by default, so that's out, and we've committed to restricted being for hardware support only, though perhaps mdz would be willing to bend that rule for this case.
[03:48] <mvo> infinity: right. either -restricted or we remove all non-free icons 
[03:49] <mvo> infinity: as for app-install-data, I will have a look at the sutff from multiverse and remove the icons
[03:49] <mvo> (or check for free alternatives)
[03:49] <infinity> mvo: Awesome.  You rule.
[03:49] <mvo> messy problem :(
[03:49] <infinity> mvo: Can you file a placeholder bug for this and subscribe me to it?
[03:50] <infinity> mvo: Most things (like acroread for sure) should have free icons that would suffice.
[03:50] <infinity> mvo: For -commercial, I assume the vendors would be miffed if we didn't use their logos, so we'd have no choice but to ship them in a nonf-ree component, I suspect.
[03:51] <jdub> there's nothing wildly wrong about shipping trademarks that refer to a product
[03:51] <jdub> i mean, we ship apache after all
[03:51] <jdub> and gnome
[03:52] <Mithrandir> jdub: this isn't about trademarks, but copyright.
[03:52] <jdub> what's the copyright issue?
[03:52] <Mithrandir> jdub: they're probably not free (in the DFSG sense) so can't go to main.
[03:53] <infinity> Shipping vendors' unmodifiable logos?
[03:53] <jdub> we ship quite a few trademarks
[03:53] <infinity> One could make an argument that shipping a logo that is also a trademark is a sketchy grey area, but I'd prefer not to go there.
[03:53] <Mithrandir> (the copyright issue being "they're unmodifiable due to copyright")
[03:53] <jdub> including projects that, if modified, you're required to change the name
[03:53] <jdub> Mithrandir: how is that different to "apache"?
[03:53] <Mithrandir> jdub: requiring name changes is ok wrt the DFSG.
[03:53] <jdub> (red hat ship "httpd")
[03:54] <infinity> jdub: You can't modify the Acrobat logo at all.  You can modify the word "apache" all you want.
[03:54] <jdub> ok, the gnome foot
[03:54] <infinity> jdub: The GNOME foot is unmodifiable?
[03:54] <jdub> infinity: it's a trademark
[03:54] <infinity> Yes, so?
[03:54] <infinity> That doesn't make in unmodifiable.
[03:54] <infinity> It makes it a trademark.
[03:54] <infinity> You're mixing and matching laws here.
[03:54] <jdub> no, i'm not
[03:55] <infinity> s/make in/make it/
[03:55] <jdub> there are very few trademarks you can modify without a license
[03:55] <jdub> to do so
[03:55] <infinity> You can easily license the foot to be freely modifiable and still say "the foot is a trademark of the GNOME foundation".
[03:55] <jdub> no you can't
[03:55] <jdub> because you are not protecting your trademark
[03:56] <infinity> Erm, no.  Really.  A mark can be modified for non-competitive use and not violate the mark.
[03:56] <jdub> there are lots of things shipped in ubuntu that are not modifyable per trademark or copyright; the GPL is a good example
[03:56] <Mithrandir> jdub: a modified work might not look anything like the gnome foot.  If it's derived from the gnome foot, it's still covered by copyright "taintedness" from the foot.  However, if it doesn't look like the foot, it's not covered by the trademark.
[03:56] <jdub> infinity: that is not correct.
[03:56] <Burgundavia> Keybuk: see my mail to -devel about it
[03:56] <infinity> If it's competitive use, it becomes a trademark issue, not a copyright issue.  And copyright law plays no part in that.
[03:56] <jdub> infinity: that is not correct.
[03:56] <jdub> Mithrandir: if it's nothing like the gnome foot, it's not a trademark issue.
[03:57] <infinity> jdub: But could still be a copyright issue.
[03:57] <infinity> jdub: That's the point.
[03:57] <Mithrandir> jdub: it can easily be a trademark issue without being a copyright issue too.
[03:57] <jdub> Mithrandir: absolutely
[03:57] <dholbach> rodarvus: ROCK ON! :)
[03:57] <jdub> Mithrandir: that's roughly my point
[03:57] <rodarvus> dholbach, heh :)
[03:57] <rodarvus> hey, on an unrelated subject. I noticed you like drum'n bass
[03:58] <dholbach> hehe, yeah, you could say that :-)
[03:58] <rodarvus> there is a drum'n bass "specialization" in brazil, which I think you might like (or maybe you already know)
[03:58] <rodarvus> called 'sambarock'
[03:59] <dholbach> I need to get more into it, but I know there's a lot of very good brazilian dnb DJs
[03:59] <Riddell> Mithrandir: are you going to upload casper sometime with the accessibility changes?
[03:59] <Mithrandir> Riddell: yeah, I have a bunch of other changes I need to get in too, for upstart.
[03:59] <rodarvus> we have some really good stuff on this genre here
[04:00] <dholbach> rodarvus: I didn't know you were into drum'n'bass music
[04:00] <mvo> jdub: so you say shiping those icons maybe unproblematic?
[04:00] <jdub> Mithrandir: you're basically arguing that shipping trademarked icons in reference to a product is not DFSG compliant. that's pretty hairy - should the DFSG cover trademarks? *highly* problematic. in DFSG terms, you can replace these icons with whatever you want.
[04:00] <jdub> mvo: i think it comes down to a trademark issue, not a DFSG issue.
[04:00] <jdub> mvo: because getting trademarks caught up in DFSG stuff is extraordinarily problematic.
[04:01] <Mithrandir> jdub: the DFSG traditionally isn't interpreted to cover trademarks, but if we were to make it cover trademarked icons too, we'd need to only ship non-trademarked (or with trademarks which allows modification) bits.
[04:01] <infinity> jdub: And if we take a step back and say the icons aren't trademarks (the ones in question may be, but may not be), but they're still unmodifiable?
[04:01] <rodarvus> dholbach, I'm into electronic music, generally. just happen to enjoy some of dnb as it has strong roots in brazil
[04:01] <dholbach> rodarvus: I'll send you a link to some mixtapes, then ;-)
[04:02] <infinity> jdub: You're giving trademark logos the same blanket "turn a blind eye" stance that we give to license texts, and I can see the argument for that, but we hadn't actually established that these icons were all registered marks in the first place, just that they were non-free images. :)
[04:02] <rodarvus> dholbach, if I knew you like it, I could have brought you some brazilian dnb (can do it next time too, if you want)
[04:02] <jdub> infinity: ends up being a different issue.
[04:02] <rodarvus> nice, appreciated :)
[04:02] <ogra> rodarvus, ping
[04:02] <rodarvus> ogra, pong
[04:02] <jdub> Mithrandir: then you have the firefox issue impact everything. eek. ;)
[04:03] <dholbach> rodarvus: that sounds super
[04:03] <ogra> rodarvus, whats the reason for patching all the upstream tarballs of the X drivers instead of using debian/patches ? 
[04:03] <rodarvus> none, really
[04:03] <Mithrandir> jdub: the DFSG _does_ cover copyright bits though so we need to make sure whatever we include at least is modifiable, even if the trademark licence forbids it.
[04:04] <Kamion> infinity: non-free data probably falls in the region where we diverge from the DFSG on a case-by-case basis anyway
[04:04] <infinity> ogra: When Daniel first packages all the modular stuff, he only added debian/patches and a dpatch build-dep as things needed patching.  So some packages have them, and some never did.
[04:04] <ogra> rodarvus, we had quite an hard time here at the ltsp hackfest because the via driver doesnt work on *anything* anymore with the GIT patch you added
[04:04] <rodarvus> wanted to rush them for Knot 3, but using quilt would be better, of course
[04:04] <rodarvus> ogra, oh?
[04:04] <infinity> ogra: I suspect others (like rodarvus) have just maintained the status quo. :)
[04:04] <ogra> could you please revert that ? 
[04:04] <Kamion> "Ubuntu contains licensed and copyrighted works that are not application software. For example, the default Ubuntu installation includes documentation, images, sounds, video clips and firmware. The Ubuntu community will make decisions on the inclusion of these works on a case-by-case basis, ensuring that these works do not restrict our ability to make Ubuntu available free of charge, and that Ubuntu remains redistributa
[04:04] <Kamion> http://www.ubuntu.com/ubuntu/licensing
[04:04] <rodarvus> ogra, that patch is actually meant to make it work. it wouldn' work without that patch
[04:04] <ogra> none of the disklessworkstations.com terminals work anymore and it took me some time to figure that out
[04:05] <infinity> Kamion: Fair enough.  If that's the case, then mvo can just yell at Debian for being slack about this, and we can pretend we don't care? :)
[04:05] <jdub> Mithrandir: i think you end up with a sticky ball of confusion if you try to separate those too much
[04:05] <rodarvus> ogra, can you send me the Xorg.0.log so I can take a look at it?
[04:05] <rodarvus> and inspect the exact cause of the problem
[04:05] <ogra> if i compile the package with the plain upstream source tarball from freedesktop.org it works fine everywhere
[04:05] <Mithrandir> jdub: why?  They're totally separate issues.
[04:05] <jdub> Mithrandir: almost totally - in theory.
[04:05] <ogra> rodarvus, ok, will do
[04:05] <rodarvus> thanks, appreciated
[04:06] <ogra> err
[04:06] <jdub> Mithrandir: in practice, they're often intimiately wed. how many images do you think we ship that are unmodifiable, but not due to trademark restrictions?
[04:06] <ogra> rodarvus, err, well, it will be a bit hard to get them since the terminal hardlocks as soon as X starts ...
[04:06] <ogra> but i'll try my best 
[04:07] <Mithrandir> jdub: I have no idea; I did actually assume we didn't ship non-free data apart from GFDL-ed docs.
[04:07] <ogra> the fedore guys actually had the same prob, was quite funny that i fixed their package alongside ;)
[04:07] <jdub> Mithrandir: and licenses. and trademarks. ;-)
[04:07] <rodarvus> ogra, it was a problem on the upstream release, actually
[04:07] <rodarvus> which my patch is supposed to fix (usage of assert())
[04:08] <infinity> jdub: Well, without licesnes we can't ship anything (except a few MB of public domain stuff) at all, so we pretty much have to hand-wave that one past.
[04:08] <ogra> rodarvus, well, when they reverted to the upstream tarball it worked for them as well ... apart from the fact that they also have a DRI problem that still needs fixing (the forcefully enable DRI everywhere ;) )
[04:08] <infinity> jdub: I'd prefer not to see "license texts are non-free!" be someone's toehold to argue for more such exceptions, cause that just makes no sense.
[04:09] <rodarvus> ogra, haha, I fixed that too! :)
[04:09] <ogra> rodarvus, i dont think its the assret stuff that breaks it, but rather the GIT commit to the source
[04:09] <ogra> *assert
[04:09] <jdub> infinity: the point being that trademarks should be regarded as legitimately non-modifiable.
[04:10] <rodarvus> ogra, the strange thing is I don't have any other complain with the current version of this driver :/
[04:10] <ogra> (isnt the assert change only one line ?)
[04:10] <rodarvus> yes
[04:10] <ogra> right
[04:10] <Mithrandir> jdub: modification doesn't make sense in the context of a trademark.  If you create something from scratch it can still violate a trademark.  You _can't_ violate copyright by creating from scratch.
[04:11] <ogra> well, i have at least three thin clients here where it works fine with dapper and with the plain upstream source but not with the patched one
[04:11] <rodarvus> ogra, oh, so you want me to revert the OpenChrome changesets?
[04:11] <ogra> right
[04:11] <rodarvus> *glup*
[04:11] <rodarvus> ok :)
[04:11] <jdub> Mithrandir: well, you can, but for different reasons. but yes, i know what you mean, and that is accurate.
[04:11] <ogra> we should rather get unichrome fixed and to main at some point :)
[04:12] <rodarvus> ogra, do you think its possible for you to try a locally built version, and then, if it works we can later upload it?
[04:12] <ogra> yep, i'll talk to jim if i can borrow one of the clients where it breaks until mountain view 
[04:12] <Mithrandir> jdub: oh yes, s/copyright/the licence/ if that makes you happier.  By cleanrooming something you avoid any restrictions the licence used imposes on you.
[04:12] <ogra> luckily i can return it in november :)
[04:12] <rodarvus> ogra, anyhow, the OpenChrome changesets are exactly meant to fix DRI
[04:12] <jdub> Mithrandir: doesn't help with a book, though. :-)
[04:12] <ogra> rodarvus, aha
[04:12] <rodarvus> without them, we'll be in the same situation as Fedora
[04:13] <ogra> well, not really 
[04:13] <ogra> seems the binary i built just worked on the fedore system they have here ;)
[04:13] <ogra> they only replaced their module with mine and it started to magically work *g*
[04:16] <rodarvus> O_O
[04:16] <jsgotangco> haha
[04:16] <HiddenWolf> ubuntu doesn't have enough bugs to keep awesome ogra busy all day and night. ;)
[04:17] <ogra> heh
[04:20] <jdong|laptop> there, posted my two grips to KubuntuKDEMedia
[04:20] <jdong|laptop> oops, wrong channel
[04:21] <rodarvus> ogra, http://people.ubuntu.com/~rodarvus/packages/xserver-xorg-video-via/
[04:22] <ogra> whoops ... gdebi kicked in *g*
[04:25] <rodarvus> nice, please report here when youu have results :)
[04:28] <ogra> rodarvus, looks fine 
[04:29] <rodarvus> good
[04:29] <rodarvus> a working driver is always good news
[04:29] <rodarvus> ogra, and wrt DRI, I suppose its not rocking?
[04:34] <pitti> Keybuk: good idea, given that we are just out of knot-3 freeze; it becomes cold in here
[04:35] <rodarvus> on a semi-related subject ("three days until Beta Freeze"). about two weeks ago I requested UVF exception for Mesa (which was at version 6.5.1rc2 at the time). mdz asked me to wait for 6.5.1 final, due to the rather intrusive changes applied to Mesa since the last package update (~20 days before the UVF exception request)
[04:35] <rodarvus> well, Mesa 6.5.1 was released this weekend.
[04:40] <carlos> Keybuk: hi, around?
[04:41] <Keybuk> carlos: yeah, what's up?
[04:41] <carlos> Keybuk: hi
[04:41] <ogra> rodarvus, dri doesnt work on thin clients anyway ...
[04:41] <rodarvus> ogra, I'm not worried about (only) the thin clients, but via driver users in general
[04:41] <rodarvus> :)
[04:41] <ogra> evil jdub 
[04:42] <ogra> rodarvus, i dont have any other via HW to test it 
[04:42] <rodarvus> ogra, hey, do you have a spare thin client you could test the new and shinning 'unichrome' driver on?
[04:42] <carlos> Keybuk: would be possible to fix upstart's source to stop mixing '\r' and '\r\n' in the same gettext messages? 
[04:42] <ogra> rodarvus, i tried that one when we had the probelm ... it didnt work, xorg fell back to vesa
[04:42] <carlos> Keybuk: https://lists.ubuntu.com/archives/rosetta-users/2006-September/001805.html
[04:43] <ogra> and when i forced it, it didnt start
[04:43] <rodarvus> its an alternate driver for via boards - it (knowingly) doesn't works on all via boards, but it is said to be better than the 'official' driver for the ones it supports
[04:43] <Keybuk> carlos: err, what's the problem?
[04:43] <Keybuk> that string is correct
[04:43] <rodarvus> oh
[04:43] <ogra> but i'll get the client where the via driver broke to take it home, i'll be able to test more by the end of the week 
[04:43] <ogra> so i can provide logs etc then 
[04:44] <carlos> Keybuk: why do you mix them? is any technical need? 
[04:44] <Keybuk> carlos: because \r and \n are different characters?
[04:44] <ogra> i just dont have more time i can waste with general bugfixing here, i'm here to finish off the ltsp upstream erge
[04:44] <Keybuk> and do different things?
[04:44] <carlos> Keybuk: I don't mind if you use '\r' or '\n'
[04:44] <Keybuk> carlos: eh?
[04:44] <carlos> Keybuk: What I'm asking is to not mix both in the same sentence
[04:44] <Keybuk> why not?
[04:44] <Keybuk> what's wrong with mixing them?
[04:44] <carlos> either us '\r' or '\n' or '\r\n'
[04:44] <Keybuk> no
[04:44] <Keybuk> BZZT
[04:45] <carlos> well, from the translation point of view
[04:45] <ogra> rodarvus, (flying back tomorrow night, so i'll have time from thursday on to hunt that for you)
[04:45] <carlos> you drive our translators crazy
[04:45] <Keybuk> what has this got to do with translations ?!
[04:45] <Keybuk> you are making no sense
[04:45] <carlos> from the Rosetta point of view... upstart will be rejected 
[04:45] <Keybuk> why?
[04:45] <Keybuk> is there a bug in Rosetta?
[04:45] <carlos> Keybuk: that allows you to import such strings, yes
[04:45] <Keybuk> eh?
[04:45] <Keybuk> dude, please start from the beginning
[04:46] <Keybuk> what is the problem with that string?
[04:46] <Keybuk> it is correct
[04:46] <rodarvus> ogra, thanks, appreciated!
[04:46] <carlos> technically is correct, right
[04:46] <carlos> but, from the translator point of view
[04:46] <Keybuk> what have translations got to do with it?
[04:46] <Keybuk> the french shutdown message still needs to return to the beggining of the line before writing over a terminal
[04:46] <carlos> Keybuk: what happens if a translator translates '\r foo \r\n' with '\n foo \n' ?
[04:46] <Keybuk> then they will get the wrong thing
[04:46] <Keybuk> and that translator should be slapped
[04:47] <Keybuk> it should be \r foo \r\n
[04:47] <carlos> Keybuk: so technically you need exactly that information?
[04:47] <Keybuk> or, at least, \r f \r\n
[04:47] <Keybuk> yes
[04:47] <carlos> ok
[04:47] <Keybuk> \r and \n are different characters
[04:47] <Keybuk> they do different things
[04:47] <Keybuk> anyone thinking they are the same needs re-education
[04:47] <carlos> I know
[04:48] <Keybuk> so what's the problem?!
[04:48] <Keybuk> I am utterly confused here
[04:48] <carlos> but most of the time (always since we started with Rosetta) people used '\r' when they were thinking on '\n' so I was just checking if that's the case here
[04:48] <Keybuk> no
[04:48] <giftnudel> Keybuk: I think it was not clear, that you need both \r and \n exactly
[04:48] <Keybuk> it's definitely not the case
[04:48] <carlos> Keybuk: ok
[04:48] <carlos> next question
[04:48] <Keybuk> the \r at the start is required to reset the cursor position
[04:48] <Keybuk> as that message is written over whatever is on any terminal already
[04:49] <Keybuk> the \r\n at the end are needed because you don't know the settings of the terminals you are writing to
[04:49] <Keybuk> so need to explicitly return and advance the carriage
[04:49] <carlos> Keybuk: would be possible to move out those tags from the gettext string?
[04:49] <Keybuk> no, because it needs to be done in a single write
[04:49] <carlos> this will break a lot of translations because many translators don't even know about that difference
[04:49] <carlos> I see
[04:49] <carlos> ok
[04:50] <Keybuk> otherwise you'll end up with a shtudown message broken up across a terminal running anything that attempts to actively update the display
[04:50] <carlos> then we will need to figure a way to help translators to handle that without breaking upstart
[04:50] <giftnudel> carlos: maybe some education will help?
[04:50] <Keybuk> it wouldn't break upstart, they'd just get jumbled up shutdown messages
[04:50] <carlos> and fix also Rosetta now that we found the first case that actually need that mix of chars
[04:50] <Keybuk> seriously, translators should at least know some fundamentals about C strings, no?
[04:51] <Kamion> Keybuk: you could still assemble the string in memory first and then write it in one go
[04:51] <Keybuk> Kamion: perhaps
[04:51] <Kamion> I think that would be a good idea - it's somewhat analogous to security vulnerabilities due to incorrect format string translations
[04:51] <carlos> Keybuk: no, that's not why Rosetta is being developed. It's something good that they know about it, but we shouldn't need to teach them about it
[04:51] <Kamion> I've been trying to improve d-i to rely less on translator knowledge
[04:51] <Keybuk> that's already an ugly piece of code just for dealing with translations
[04:52] <carlos> Keybuk: thanks for your time
[04:52] <Keybuk> it was one of those where I almost did a Jane over translation <g>
[04:52] <ogra> Keybuk, ping
[04:52] <Keybuk> ogra: I'm not here, I've been away for the past hour, and am not returning for another three
[04:52] <Keybuk> I'm not even here now
[04:53] <Nafallo> lol
[04:53] <ogra> udevinfo -qenv -n fd0 (or /bock/fd0) retunr nothing here 
[04:53] <ivoks> jee... Keybuk has a bot :)
[04:53] <Keybuk> ogra: what did you expect it to return?
[04:53] <ogra> Keybuk, something ? 
[04:53] <jdub> the messiah.
[04:53] <Keybuk> ogra: such as?
[04:53] <Kamion> ogra: last time I asked a similar question, Scott's answer was "if udev doesn't change anything versus what the kernel recommended for that device, then udevinfo won't print anything"
[04:53] <ogra> ID_BUS, ID_TYPE
[04:53] <Kamion> or words to that effect
[04:53] <thom> i don't think block devices can be very naughty boys
[04:53] <Keybuk> ogra: we don't record that information for floppy devices
[04:54] <Keybuk> users get annoyed at the *chuggggchunkwhrrr* on boot :p
[04:54] <ogra> sbalneav say ok, thats fine ... we'll make up a name ...
[04:54] <Keybuk> and for a floppy, that's pretty much hard-codable anyway, no?
[04:54] <Keybuk> bus=floppy
[04:54] <ogra> *says
[04:54] <Keybuk> type=floppy
[04:54] <Keybuk> :p
[04:55] <ogra> will work, at least for one 
[04:55] <Keybuk> for one?
[04:55] <Keybuk> why not for two?
[04:55] <ogra> dunno if that'll work with multiple floppes though
[04:55] <Keybuk> fd0, iirc, is only ever XT floppy devices
[04:55] <ogra> ok
[04:55] <Keybuk> sure, the id is just the 0, 1, 2, etc. bit on the end
[04:56] <ogra> ok, thanks for now :)
[05:00] <ogra> iwj, i have some weird problems with flash on ltsp here ... seems if i use a dapper chroot (thus the dapper X server) it works fine, as soon as i switch to edgy (even with vesa) firefox just crashes 
[05:01] <ogra> (on flash sites)
[05:03] <iwj> ogra: I blame flash.   Err.
[05:03] <ogra> hmm
[05:03] <ogra> but the only thing i change is the X server ... i'm tempted to blame X
[05:03] <ogra> or ssh ...
[05:03] <iwj> Sorry, but Flash is not free software so I can't help.  Debugging it would involve reverse-engineering, which is forbidden by Macromedia, even if I were prepared and motivated to attempt it without the source.
[05:03] <ogra> but thats the only thing thats different
[05:03] <ivoks> ogra: it's compositing manager
[05:03] <ivoks> ogra: turn it off
[05:03] <iwj> ivoks is probably right.
[05:04] <Keybuk> iwj: talking of Firefox ... mine doesn't work
[05:04] <ogra> how ? i didnt turn it on deliberately ...
[05:04] <iwj> Keybuk: Oh ?
[05:04] <ivoks> i was smashing my head for days cause of this :/
[05:04] <Keybuk> I get an XML Parsing Error when it starts
[05:04] <Keybuk> edgy, current
[05:04] <iwj> Yay!
[05:04] <Keybuk> tried a fresh profile
[05:04] <iwj> That's crazy.
[05:04] <iwj> And this apparently only happens to you.  How weird.
[05:04] <iwj> Does it mention the filename that has the problem ?
[05:04] <Keybuk> "undefined entity" is on <toolbarbutton id="go-button"  and <menuitem id="menu_HelpPopup_reportPhisingtoolmenu"
[05:04] <Nafallo> there are bugs about that
[05:04] <ogra> ivoks, thanks thats a good hint, thanks a million
[05:05] <Keybuk> chrome://browser/content/browser.xul
[05:05] <ivoks> ogra: np
[05:07] <Keybuk> iwj: is there any super-debugging-power thing I can do to help?
[05:07] <Keybuk> obviously there's not enough info for a bug report here yet
[05:07] <giftnudel> Keybuk: can confirm this bug
[05:07] <iwj> Keybuk: Can you try running it with LANG=C and no other locale variables ?
[05:08] <Keybuk> iwj: "LANG=C firefox" works
[05:08] <iwj> Right.
[05:08] <iwj> The problem will be fixed when the langpacks are updated.
[05:08] <Keybuk> iwj: "LANG=en_GB.UTF-8 firefox" doesn't (my default lang)
[05:08] <Keybuk> ah, I see an updated langpack thing
[05:08] <Keybuk> I'll try installing that
[05:08] <iwj> Yes, do :-).
[05:09] <iwj> Hey, that was too easy.  Ask me another one.
[05:09] <Keybuk> iwj: Would you like any toast?
[05:09] <Nafallo> iwj, Keybuk: I have seen a bug-report about that already where Kamion suggested using LANG=C etc...
[05:09] <Nafallo> I'm trying to find it now
[05:09] <iwj> Nafallo: Never mind, we know what the answer is.  Although we should express this in dependencies somehow.
[05:10] <Keybuk> iwj: yes, that fixed it
[05:10] <Nafallo> well, that answer is in the bugreport aswell, and have been the whole weekend ;-)
[05:10] <iwj> m-f-l-thing Breaks: firefox (!= the one it's intended for)
[05:11] <iwj> Nafallo: I often find that rediscovering the answer to easy questions is faster and more reliable than looking at what people say in bug reports :-).
[05:11] <Nafallo> hehe, with the amount of bugreports against the said package I understand you :-P
[05:12] <mvo> Kamion: does my suggestion to fix #52718 sound ok? If so, I wil implement it now. note that I would like to rename the environment used for this
[05:12] <Keybuk> bah, greasemonkey not available
[05:15] <seb128> mvo: are you sure those are different options?
[05:15] <seb128> mvo: that looks like "make GST_NO_INSTALL_NTP does what it used to do and mask the ntp setting too"
[05:16] <Kamion> mvo: sure, no opinion on the environment variable, just let me know what you decide
[05:19] <azeem> dholbach: if you manage to fix the multisync build WRT libpisock, please let me know :)
[05:20] <mvo> seb128: well, I think when we just hide the checkbutton/button complettely that should be enough, no? 
[05:20] <seb128> mvo: which one?
[05:21] <seb128> oh, the ntp and ntpdate options you mean (ie: everything between the timezone and the buttons bar)?
[05:22] <iwj> pitti: BTW, my latest attempt at ff 1.5 for breezy is building.
[05:23] <pitti> ah, nice
[05:23] <pitti> iwj: I am off for a bit now, and when I return later this evening I'll chat with mdz about tbird 1.5
[05:23] <mvo> seb128: the old patch did remove the button "install ntp now". but when the installer runs time-admin, it does not need the ntp stuff. so the checkbox "sync system clock with the net" and the button "choose server". ntpdate is installed so the "sync now" button can probably stay
[05:24] <seb128> mvo: ok, works for me :)
[05:26] <dholbach> azeem: dlp_ReadRecordById dropped one argument
[05:26] <FliesLikeALap> mvo you around?
[05:26] <dholbach> azeem: I did a small patch for evolution too
[05:27] <mvo> seb128: ok, I will do that then
[05:27] <mvo> FliesLikeALap: yes
[05:28] <FliesLikeALap> mvo, may I strike up a private query with you?
[05:28] <mvo> FliesLikeALap: sure
[05:28] <bddebian> Heya folks
[05:30] <bluefoxicy> who is generally in charge of Ubuntu/Canonical finances?
[05:30] <bluefoxicy> sabdfl?
[05:31] <azeem> dholbach: oh, ok.  I only had a very superficial look at it so far and it looked non-trivial to me :)
[05:31] <bluefoxicy> Someone is asking me about getting financial support for something so I figure I'll send him towards the proper channels
[05:34] <Seveas> bluefoxicy, jane.silber at c.com
[05:34] <bluefoxicy> Seveas:  nods.  I'll send him that way then.
[05:35] <bluefoxicy> c == canonical?
[05:36] <Seveas> yes
[05:36] <bluefoxicy> kay.
[05:41] <tkamppeter> Who is responsible for merges.ubuntu.com?
[05:41] <pitti> tkamppeter: Keybuk 
[05:41] <tkamppeter> There are missing: foomatic-filters, foomatic-db, foomatic-db-hpijs
[05:42] <tkamppeter> Keybuk, I these packages need to be updated for Edgy to fix several bugs and to update hardware support.
[05:42] <tkamppeter> Thanks, pitti.
[05:43] <pitti> tkamppeter: usually they are missing because we have a newer version than Debian
[05:43] <StevenK> pitti: Not in this case.
[05:43] <Kamion> in this case I imagine they're missing because we never made Ubuntu-specific modifications
[05:43] <Kamion> foomatic-filters | 3.0.2-20060530-1 |          edgy | source, all
[05:43] <tkamppeter> So I directly update such packages, as I usually did with Mandriva.
[05:43] <Kamion> tkamppeter: shouldn't we sync them from Debian?
[05:44] <pitti> tkamppeter: oh, in that case a sync is better
[05:44] <Kamion> foomatic-filters | 3.0.2-20060712-3 |      unstable | source, all
[05:44] <Kamion> for instance
[05:44] <Keybuk> that's weird
[05:44] <Kamion> we're generally happier with syncs where possible, because it broadens the base of people we can expect to have tested the packags
[05:44] <Kamion> packages
[05:45] <Kamion> unless of course newer versions still are required, over what Debian has
[05:45] <tkamppeter> Perhaps we need even newer, to fix several bugs which I have recently fixed upstream, as
[05:46] <pitti> tkamppeter: if that's the case, please apply modifications on top of sid's package instead of our's
[05:46] <pitti> tkamppeter: so that we don't run into merge troubles later
[05:46] <crispin> Keybuk: thanks for the info on /proc/bus/usb - the VMware guys are apparently aware of the situation with it
[05:46] <tkamppeter> bug 36532 (wrong recommended driver gimp-print)
[05:46] <Ubugtu> Malone bug 36532 in cupsys "Unable to print text or ps/pdf to gutenprint printer" [Unknown,Unconfirmed]  http://launchpad.net/bugs/36532
[05:47] <tkamppeter> bug 16703
[05:47] <Ubugtu> Malone bug 16703 in foomatic-db "hpijs is recommended for hp laserjet 1100A but ljet4 prints better" [Medium,Confirmed]  http://launchpad.net/bugs/16703
[05:48] <tkamppeter> bug 23461
[05:48] <Ubugtu> Malone bug 23461 in cupsys "gs-esp dies when it is called by cups" [Medium,Needs info]  http://launchpad.net/bugs/23461
[05:51] <tkamppeter> pitti, so you think, I should generate a patch out of the current snapshot of each Foomatic package and add this to the appropriate Debian unstable package to get a Ubuntu package making up the current snapshot of Foomatic?
[05:51] <pitti> tkamppeter: yes
[05:51] <tkamppeter> Is it not easier to simply take today's upstream snapshots?
[05:54] <tkamppeter> And also bug 39465 and 41789, and probably many others which I found by myself or by reports to other distros or to the linuxprinting.org mailing lists ...
[05:54] <Ubugtu> Malone bug 39465 in foomatic-db "Samsung ML-1740 Not Listed" [Medium,Confirmed]  http://launchpad.net/bugs/39465
[05:54] <Ubugtu> Malone bug 41789 in foomatic-db "the Samsung ML-1610 printer works with ML-1510 driver" [Medium,Confirmed]  http://launchpad.net/bugs/41789
[05:57] <pitti> tkamppeter: no, I mean use 'uupdate' in Debian sid's version, not our's
[05:57] <pitti> tkamppeter: so that the next automatic merge will be easier
[05:58] <pitti> tkamppeter: you can still use today's upstream snapshot (all under the assumption that mdz approves, of course)
[06:18] <carlos> Riddell: hi, do you have time to debug a problem with Edgy's kdelibs.pot file?
[06:20] <Riddell> carlos: I can try
[06:20] <Riddell> I know we're missing the stock strings
[06:20] <carlos> Riddell: we got an email from a user related to some strings being set as obsolete (let me look for the thread...)
[06:20] <carlos> oh, I see
[06:20] <carlos> so that's the problem
[06:20] <carlos> Riddell: is there any bug report open so we can point our users to it?
[06:21] <Riddell> carlos: not that I know of
[06:21] <Riddell> I'll try and look at that today
[06:21] <carlos> do you want that I file a bug?
[06:22] <carlos> if you think today it would be fixed, that's enough for me
[06:22] <Riddell> sure, do file a bug
[06:22] <carlos> ok
[06:30] <carlos> Riddell: https://launchpad.net/distros/ubuntu/+source/kdelibs/+bug/61107
[06:30] <Ubugtu> Malone bug 61107 in kdelibs "Some stock strings are not extracted to be translated" [Untriaged,Confirmed]  
[06:32] <iwj> pitti: The problem you had before with the new ff was   gtk_stock_lookup: assertion `stock_id != NULL' failed   I take it ?  (Followed by glibc detected free invalid pointer)
[06:33] <ogra> mdz, ping
[06:39] <mdz> ogra: pong
[06:40] <ogra> mdz, sorry for bug 57329 i added an explanation ...
[06:40] <Ubugtu> Malone bug 57329 in xorg-server "upgrade to latest xorg has stopped my CLE266 from working" [Medium,Fix released]  http://launchpad.net/bugs/57329
[06:41] <ogra> mdz, but that wasnt the reason for my ping ... sbalneav has made a proper upstream package of ltspfs now, and we merged the source into one sourcepacke, would it be ok for an UVF exception ?
[06:42] <mdz> ogra: what would be the benefit in edgy?
[06:42] <ogra> (i'll file a request etc, but wanted to ask you first)
[06:42] <ogra> we'd have only one ltspfs package and sbalneav actually would maintain it (with me sponsoring)
[06:42] <ogra> s/package/sourcepackage/
[06:43] <ogra> and the fixes we worked out here wouldnt have to be backported to my packages
[06:43] <ogra> (floppy handling improvements, path improvements for the mounting etc)
[06:46] <ogra> ltspfs upstream is completely maintained on LP and in bzr now btw :)
[06:47] <iwj> mvo: Is there a way to turn off the crash reporter so I can have a corefile for my debugger ?
[06:48] <iwj> I can't remember what it's called so I can't find the corefile in /var/whereever either.
[06:48] <Mithrandir> iwj: apport-unpack /var/crash/$whatever /tmp/unpack-foo
[06:49] <iwj> Uh.  Excuse me, I have no brain.  I would have found that if it had existed.  But I'm using _breezy_ which doesn't have it.  duh.
[06:50] <iwj> But that leaves the question, where's my corefile and what put up a dialogue box about the crash ?
[06:50] <gnomefreak> mjg59: ping
[06:50] <jdong> mother of god... how long does it take for apport to prepare a crash report about firefox?
[06:50] <gnomefreak> jdong: they are large
[06:51] <gnomefreak> jdong: like 20+ mb
[06:53] <jdong> there, done
[06:56] <iwj> pitti: Hmm.  I'm rebuilding ff unoptimised so my gdb works.  No doubt the bug will vanish.
[06:57] <pitti> iwj: I'm not sure about the particular crash, sorry
[06:58] <pitti> iwj: I just know that ffox itself worked flawlessly and most gtkmozembed apps (yelp, epiphany, etc.) broke
[06:59] <mvo> iwj: apport and apport-gtk are responsible for this
[07:03] <iwj> Right.  I'm working with yelp atm because it's relatively small :-).
[07:03] <iwj> I'll leave this debug build running and pick it up tomorrow morning.
[07:04] <mind> hi, where i can find the ubuntu's build log? i'm looking for something similar to buildd.debian.org
[07:04] <bddebian> mind: Launcpad
[07:04] <Keybuk> 21308 root      25   0 72144  68m 1072 R  100  3.4   0:39.98 ld
[07:04] <Keybuk> *blink*
[07:04] <Keybuk> what in gods name is it linking?!
[07:05] <bddebian> mind: More specificially:  https://launchpad.net/distros/ubuntu  and put in your package name
[07:06] <pitti> iwj: sudo /etc/init.d/apport stop, btw
[07:06] <pitti> iwj: (edgy+1 will have a more user friendly method)
[07:07] <gnomefreak> init.d still works in edgy?
[07:08] <Keybuk> yes
[07:08] <gnomefreak> is it changing in edgy+1 or later in edgy?
[07:08] <mind> bddebian: thanks
[07:09] <Keybuk> we'll begin changing to upstart jobs in +1 and finish in +2 or so I guess
[07:09] <iwj> pitti: Right, thanks, but it turned out to be me being stupid.
[07:09] <mind> bye
[07:09] <gnomefreak> ah cool ty Keybuk 
[07:09] <iwj> Keybuk: How easy would it be to have a little stub init.d which talks to upstart, for the ease of compatibility (cron jobs, finger macros, etc.)
[07:09] <Keybuk> for edgy we're just using upstart to drive init.d
[07:10] <iwj> Right.
[07:10] <Keybuk> iwj: easy; though it's easier and less error-prone just to keep /etc/init.d/rc around
[07:10] <Keybuk> unless I'm wildly missing something?
[07:10] <iwj> Err, well, yes, but it would be nicer in the end to have daemons that live as direct children of upstart.
[07:10] <Keybuk> yes, this is true
[07:11] <pitti> however, in the interest of legacy and Debian compatiblity (and not to the least, merging), wouldn't it be better to just replace the symlinks with upstart scripts, and have the upstart jobs call the existing init scripts?
[07:12] <Keybuk> pitti: wouldn't work
[07:12] <Keybuk> upstart jobs and init scripts behave differently, remember
[07:12] <Keybuk> you could call the init script with "start" as the argument, and then treat it as a daemon that forked into the background, and hunt for a process -- but it's manual configuration per-package then
[07:12] <iwj> I think this needs some serious thought and design.
[07:12] <pitti> well, right now upstart scripts call rc, so there must be a way to write adapters for them
[07:12] <Keybuk> (to name the daemon you're looking for, or the pid file to read)
[07:12] <iwj> Ie, more than random wibblings on IRC :-).
[07:13] <Keybuk> I'm not sure we need those adapters?
[07:13] <pitti> Keybuk: hm, right
[07:13] <pitti> well, if we have to touch all packages with an init script anyway, we can as well do it properly
[07:13] <Chipzz> pitti: and upstart calling rc gains us what, exactly?
[07:13] <Keybuk> Chipzz: existing init scripts run without modification
[07:13] <Chipzz> pitti: daemons won't start in parallel
[07:13] <pitti> Chipzz: if we could use Debian's init scripts unmodified, a lot less merge work
[07:13] <pitti> Chipzz: why not?
[07:14] <pitti> Chipzz: I'm not talking about using the rc?.d symlinks
[07:14] <Keybuk> pitti: tbh, I doubt it will be an increase in merge work -- we've touched most things in main with an init script already
[07:14] <pitti> Chipzz: just about using the init scripts to do the footwork
[07:14] <Chipzz> because rc is just a simple for loop?
[07:14] <Keybuk> Chipzz: fsvo simple
[07:14] <pitti> Keybuk: well, many, if not the majority of lsb init scripts have been adopted in Debian
[07:14] <pitti> Keybuk: I never had a rejected Debian bug report about it
[07:15] <pitti> and most were applied within a reasonable time
[07:15] <Keybuk> I was thinking about teardown
[07:15] <Chipzz> Keybuk: fsvo?
[07:15] <Keybuk> Chipzz: for some value of
[07:15] <Nafallo> hmm
[07:15] <Chipzz> Keybuk: you know what I meant ;)
[07:15] <Keybuk> pitti: we've adjusted many update-rc.d calls, wouldn't be much extra to just drop them
[07:15] <pitti> Keybuk: right
[07:15] <Nafallo> I can't open upstarts sv.po (extracted from Rosetta) in gtranslator :-P
[07:16] <Chipzz> Keybuk: "it boils down to a for-loop calling the scripts sequentially"
[07:16] <pitti> Keybuk: but I thought you want to not use init scripts at all any more and instead provide an upstart-ish script to every package
[07:16] <Chipzz> pitti: allow me to rephrase: why do we need compatibility with something we had in the first place?
[07:16] <pitti> Chipzz: I don't know what you mean
[07:17] <Chipzz> we had init calling rc (being a for-loop)
[07:17] <pitti> Chipzz: I mean, 'Debian' -> using most of Debian's packaging with just a few bits modified
[07:17] <Chipzz> now we have upstart calling rc (also being a for-loop)
[07:17] <pitti> Chipzz: and 'legacy' -> scripts and users being used to run /etc/init.d/foo
[07:17] <pitti> Chipzz: yeah, but upstart calling rc is just a transitional solution for edgy
[07:17] <Chipzz> yes I know why upstart is good
[07:17] <Chipzz> and I'm all in favor of it too :)
[07:18] <Chipzz> pitti: but the transitional solution gains us very little
[07:18] <pitti> Chipzz: right, just testing of upstart itself and the possiblity to play with it
[07:18] <pitti> and one release is just too short to do everything
[07:18] <Chipzz> the real value of upstart would be to be able to dump the rc script :)
[07:19] <pitti> I never questioned that either
[07:19] <pitti> Chipzz: I was talking about init scripts, not rc
[07:19] <pitti> i. e. /etc/init.d/postgresql start -> bring up my damn database and do whatever is necessary
[07:20] <Keybuk> pitti: eventually. sure; but I'd vaguely envisioned Debian being onboard too by that point
[07:20] <pitti> Keybuk: I truly hope so :)
[07:20] <Nafallo> hehe, #ubuntu-worlddomination :-P
[07:25] <desrt> lmanul; hello
[07:25] <Chipzz> Keybuk: can we have a mix of the old and new system?
[07:25] <Chipzz> or would that break?
[07:25] <Keybuk> Chipzz: sure, we do now, technically
[07:25] <desrt> lmanul; i have some questions about your SoC work
[07:25] <Chipzz> I meant something else ;)
[07:25] <Keybuk> what did you mean?
[07:26] <Chipzz> I meant some daemons being started with their /etc/init.d scripts
[07:26] <Chipzz> and some the upstart way
[07:26] <Chipzz> or is it a one-shot thing?
[07:26] <Keybuk> how do you mean?
[07:26] <Chipzz> well
[07:27] <Chipzz> obviously you can't start a daemon twice
[07:27] <Chipzz> (once the upstart way, and once using the symlink to /etc/init.d/foo)
[07:27] <Keybuk> you can gradually convert daemons to be run by upstart jobs by removing their symlinks from rc?.d so rc doesn't run them
[07:27] <Chipzz> well maybe you could, but for some daemons madness would ensue
[07:27] <Chipzz> yes
[07:28] <Keybuk> while still having upstart run rc
[07:28] <Chipzz> but removing the symlinks would break backwards compatibility
[07:28] <Chipzz> ie you couldn't go back to a pure sysvinit system if upstart breaks?
[07:28] <Keybuk> that's not backwards compatibility
[07:29] <Keybuk> but yes, that's correct; you can't ship both sysvinit and upstart handling
[07:29] <lmanul> desrt: Sure
[07:29] <Keybuk> well, you can, but you'd have to make upstart not run rc
[07:29] <lmanul> desrt: I'm listening :)
[07:30] <Keybuk> at which point you force yourself to convert everything at that point
[07:30] <Chipzz> Keybuk: that's part of what I was thinking
[07:30] <Chipzz> Keybuk: and removing the symlinks would break for people not having installed upstart
[07:31] <Keybuk> heh, people may not be able to install sysvinit anyway
[07:31] <Chipzz> so you would be forcing everyone to upgrade to upstart
[07:31] <Keybuk> yes
[07:31] <desrt> lmanul; i need to know about the stop-the-cursor-blinking stuff you did
[07:31] <desrt> lmanul; did you add an XSetting for it?
[07:31] <Keybuk> (to fix the upgrade problems, we may be forced to replace sysvinit with an empty package that depends on upstart, upstart-compat-sysv, etc.)
[07:33] <desrt> or mark upstart-compat-sysv as depending on upstart and as replaces/conflicts sysvinit?
[07:33] <bluefoxicy> fuck mplayer, it crashes X.
[07:33] <desrt> (disclaimer: that was actually a question)
[07:34] <lmanul> desrt: Yes, I did add an XSetting
[07:34] <desrt> oh.  that sick!
[07:34] <desrt> is your code in gtk?
[07:34] <lmanul> desrt: See http://www.manucornet.net/code/2006_GTK_cursor_blink_lifetime.diff
[07:34] <Keybuk> desrt: that doesn't cause upstart-compat-sysv to get installed in the first place
[07:34] <Keybuk> which is our problem
[07:34] <Keybuk> people have lost ubuntu-minimal in the past
[07:34] <lmanul> desrt: Not sure it's been forwarded upstream, but I do think so
[07:34] <desrt> Keybuk; oh.  people who don't have ubuntu-...
[07:34] <desrt> right
[07:35] <Keybuk> sysvinit becomes non-essential and nothing depends on it, so apt cheerfully removes that for them
[07:35] <desrt> lmanul; can you please make sure?
[07:35] <Keybuk> but nothing causaes them to get upstart and upstart-compat-sysv in its place
[07:35] <desrt> lmanul; i want to use that code asap :p
[07:35] <lmanul> desrt: Matthias Clasen (among others) did some minor tweaking, and probably put it into GTK
[07:35] <lmanul> desrt: Hmm there's a bug about this I think
[07:35] <lmanul> desrt: Let me see
[07:35] <desrt> lemme look at gtk CVS
[07:36] <desrt> since it's a string API i could always just make the call and watch it fail if the user has old GTK
[07:36] <pitti> mvo: btw, we have a problem in edgy: as soon as ubuntu-desktop vanishes, apt wants to uninstall 2348234 package
[07:36] <pitti> s
[07:36] <Keybuk> of course, if everybody used dselect, this wouldn't be a problem
[07:36] <pitti> mvo: how did we solve that problem with aptitude?
[07:36] <Keybuk> because dselect ensures everything with a high priority is installed anyway

[07:36] <pitti> mvo: (same for ubuntu-standard and -minimal)
[07:36] <Keybuk> dselect: 1 - apt: 0
[07:36] <pitti> mvo: i. e. if I try to remove wpasupplicant, I break my complete system
[07:37] <mvo> pitti: is this on a upgraded system? or a fresh install?
[07:37] <pitti> mvo: fresh knot-3
[07:37] <imbrandon> mvo: same with kubuntu-desktop FWIW
[07:37] <pitti> mvo: maybe the installation should mark the direct -meta dependencies as 'wanted'
[07:37] <desrt> lmanul; i don't see your xsettings changes here
[07:38] <Keybuk> pitti: which defeats the spec -- the point was to cause -meta changes to result in packages being removed
[07:38] <mvo> pitti: I think we "just" need change the way that packages are installed on the livecd, I talk to infinity about it
[07:38] <pitti> Keybuk: but *all* of them?
[07:38] <Keybuk> apt really needs first-class tasks
[07:38] <Keybuk> so you can say that you want ubuntu-desktop installed without wpasupplicant
[07:38] <pitti> Keybuk: forcing people to use *-meta can hardly be the right answer
[07:38] <lmanul> desrt: Thanks to Arjan at Intel and Matthias and Manu's patch the next version
[07:38] <lmanul> of gtk we have in rawhide will include the cursor blinking patches.  You
[07:38] <lmanul> can set the timeout in the gtkrc with this:
[07:38] <lmanul> desrt: 11:14 <@mclasen> gtk-cursor-blink-timeout = <n seconds>
[07:38] <lmanul> 11:14 <@mclasen> in your gtkrc
[07:39] <lmanul> desrt: the two limit cases are
[07:39] <lmanul> gtk-cursor-blink-timeout = 0 --> no blinking (we already had a boolean
[07:39] <lmanul>                                 setting for that)
[07:39] <lmanul> gtk-cursor-blink-timeout = MAXINT --> blinks forever (the current
[07:39] <lmanul>                                      behaviour)
[07:39] <lmanul> Any user interaction (button press, key press, focus change) restarts
[07:39] <lmanul> the blinking.
[07:39] <desrt> lmanul; all nice and good, but...... where's the code?
[07:40] <imbrandon> well if they were marked as wanted durring installation and say you replaced oo.o with koffice it woudlent want to remove ALL the other stuff only kubuntu-meta
[07:40] <lmanul> desrt: See   http://bugzilla.gnome.org/show_bug.cgi?id=352442
[07:40] <Ubugtu> Gnome bug 352442 in GtkTextView "Support for cursor blinking timeout" [Enhancement,Unconfirmed]  
[07:40] <desrt> http://cvs.gnome.org/viewcvs/gtk%2B/gdk/x11/gdksettings.c?rev=1.2&view=markup
[07:40] <desrt> no "lifetime" yet :(
[07:41] <imbrandon> but would kinda defeat the pourpouse of the spec too
[07:41] <imbrandon> but forcing *-desktop to stay installed sucks also ....... /me gos back to lurking
[07:42] <mvo> imbrandon: no worries, we find a solution that will not involve removing a gazillion things
[07:42] <imbrandon> ;)
[07:43] <desrt> ah.  some patches later down in this bug address this problem
[07:43] <desrt> ok
[07:43] <desrt> lmanul; k.  thanks.
[07:44] <lmanul> desrt: http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtktextview.c?rev=1.322&view=log   (see also GtkEntry)
[07:44] <lmanul> desrt: No problem :)
[07:45] <lmanul> desrt: Oh, really? nice :)
[07:46] <desrt> time given in seconds is annoying :p
[07:54] <Riddell> carlos: ping?
[07:55] <carlos> Riddell: pong
[07:55] <Riddell> carlos: about importing the upstream .desktop translations into rosetta, is it sane to create a new package with those in it?
[07:56] <carlos> Riddell: didn't we agreed on doing that using different packages?
[07:57] <carlos> Riddell: for Rosetta is not an issue at all, just warn me when you do that and give me the list of translation domain affected (usually the .pot filename) so I move the ones we already have to the new sourcepackage
[07:57] <carlos> from the language pack point of view, nothing changes
[07:58] <Riddell> carlos: so we'd end up with teh .pots in the KDE source packages, but the upstream .pos in a special source package
[07:59] <Riddell> of course that's a source package with no binary packages, which may not be sane
[08:00] <carlos> Riddell: oh, so you are talking about just moving the .po files to a new package instead of adding them to kde-l10n?
[08:00] <carlos> Riddell: that requires some changes in our side
[08:01] <Riddell> I'll look at doing some automated fetching in kde-i18n-xx
[08:02] <carlos> Riddell: I would prefer it...
[08:04] <mjg59> gnomefreak: Hi
[08:22] <gnomefreak> mjg59: for bug number 60621 should that be on usplash or usplash-theme-ubuntu
[08:26] <mjg59> gnomefreak: No idea
[08:26] <mjg59> Kamion: Any clue about the right way of doing #60621?
[08:27] <gnomefreak> hmmmm
[08:49] <Rathann> hi
[08:49] <Rathann> slomo: are you around?
[08:50] <slomo> Rathann: yes
[08:50] <Rathann> great
[08:51] <Rathann> I'd like to have a word with you about mplayer packaging
[08:51] <Rathann> you did great, but there are still some issues
[08:52] <slomo> thanks, tell me which ones (apart from it being broken in edgy because of ffmpeg) :)
[08:52] <Rathann> you disabled mp3lib because of some audio decoding problems
[08:52] <Rathann> but this hasn't been reported to us...
[08:53] <Rathann> I didn't even know about this
[08:53] <Rathann> 'till I read the report in ubuntu bugtracker
[08:53] <Rathann> please, push the reports upstream whenever you can
[08:53] <slomo> oh but can you reproduce it? and no, it wasn't reported... probably forgotten at some point :(
[08:53] <Rathann> ok
[08:54] <Rathann> next, why did you patch ve_lavc to disable those two options?
[08:54] <slomo> because we build against our own ffmpeg which was (is) too old and does not have this two options
[08:55] <Rathann> slomo: and yes, I can reproduce the mp3lib issue with my RPMs ;)
[08:55] <slomo> and which is currently the reason why mplayer is somewhat broken in edgy... but that's on my todo list
[08:55] <Rathann> I see
[08:55] <Rathann> ok
[08:55] <Rathann> why do you add config.sub and config.guess?
[08:55] <Rathann> they are completely useless for non-autoconf configure
[08:56] <Kamion> mjg59: usplash-theme-ubuntu should be fixed to ship a 640x480 (and/or 640x400?) theme
[08:57] <slomo> Rathann: oh they're added because of a boilerplate in debian/rules that updates it at build time... right, it's not needed for mplayer because it doesn't use autoconf but it doesn't hurt ;) i'll remove that part later... thanks for noticing
[08:57] <Rathann> :)
[08:57] <Rathann> makes the diff smaller
[08:58] <Rathann> ok
[08:58] <slomo> Rathann: but as you're mplayer upstream... can you tell me something about the bundled liba52? would it be somehow possible to use an external liba52? last time i tried some private parts of liba52 were used and after fixing those it simply segfaulted ;)
[08:58] <Rathann> oh, just noticed: you install codecs.conf? that's bad
[08:59] <Rathann> mplayer has a built-in codecs.conf
[08:59] <Rathann> the file is only for adding support for new codecs/testing
[08:59] <Rathann> users shouldn't mess with it
[09:00] <slomo> yep, i know... but the file was already in the versions that we had ages ago and removing config files it not that easy
[09:00] <slomo> especially when all versions are slightly different... and we can't know whether a user changed the file or not
[09:00] <slomo> so we decided to keep that file
[09:01] <Rathann> we've had many weird bugreports we couldn't reproduce
[09:01] <Rathann> which were caused by an obsolete codecs.conf laying around
[09:01] <Rathann> well mplayer now checks this
[09:01] <Rathann> but still
[09:01] <slomo> the only way how a obsolete one could lie around is when the user changes the file
[09:01] <slomo> and then he is notified at install time about it
[09:02] <Rathann> well they can copy it to ~/.mplayer/
[09:02] <Rathann> that's why we want packagers NOT to ship it at all
[09:03] <slomo> sure... but we can't just unconditionally delete /etc/mplayer/codecs.conf as the user could loose his settings...
[09:03] <Rathann> I see
[09:03] <_ion> You could rename it to codecs.conf.old and print a warning in postinst.
[09:03] <Keybuk> slomo: use the standard recipie?
[09:04] <slomo> _ion: yes, that would work
[09:04] <slomo> Keybuk: md5sum etc? impossible because we had many different versions of the file and they're not in the archive anymore
[09:04] <Keybuk> slomo: compare the md5sum against status
[09:05] <slomo> Rathann: anything else that you don't want to have shipped?
[09:05] <slomo> Keybuk: right... thanks :)
[09:05] <Rathann> no, codecs.conf was the only one ;)
[09:05] <slomo> Rathann: ok, so what about liba52? :)
[09:06] <Rathann> my fellow developer tells me it's possible
[09:06] <Rathann> but we don't support it
[09:06] <Rathann> anyway, our liba52 is pretty much synced to current upstream
[09:06] <Rathann> or rather, upstream has accepted our patches ;)
[09:07] <Rathann> though I agree that it should be possible to use external liba52
[09:07] <Rathann> patches are welcome ;)
[09:07] <Rathann> ah, I see you have gui/nogui version
[09:07] <slomo> ok, i'll try to get it done then ;) what's the liba52 version that contains all your stuff?
[09:08] <Rathann> but they're conflicting...
[09:08] <Rathann> hm
[09:08] <Rathann> the latest cvs probably
[09:08] <Rathann> in liba52/ there are diffs 
[09:08] <Rathann> between upstream and our version
[09:09] <Rathann> and liba52 syncs to upstream are mentioned in changelog, let me check
[09:09] <slomo> yep, i saw them... hm, this needs to be fixed anyway... otherwise it's impossible to use an external ffmpeg
[09:10] <Rathann> how so?
[09:10] <Rathann> mplayer supports external libav*
[09:10] <Rathann> i.e. shared
[09:10] <Rathann> oh, BTW
[09:11] <ogra> mdz, ?? any word about ltspfs ? 
[09:11] <Rathann> I think you have an old version of libavcodec...
[09:12] <mdz> ogra: your response didn't mention my name and I missed it
[09:12] <ogra> oh
[09:12] <slomo> Rathann: we have? why?
[09:12] <Rathann> slomo: I think the a52 version in 1.0pre8 is 0.7.3 but I'm not sure
[09:12] <ogra> mdz, 
 (i'll file a request etc, but wanted to ask you first)
 we'd have only one ltspfs package and sbalneav actually would maintain it (with me sponsoring)
[09:12] <ogra> * raphink hat die Verbindung getrennt (Read error: 104 (Connection reset by peer))
 s/package/sourcepackage/
 and the fixes we worked out here wouldnt have to be backported to my packages
 (floppy handling improvements, path improvements for the mounting etc)
 ltspfs upstream is completely maintained on LP and in bzr now btw :)
[09:12] <mdz> ogra: I'm interested in what's changed from our package, and justification for a feature freeze exception
[09:13] <Rathann> slomo: because one of the recent bugreports contained a gdb trace
[09:13] <slomo> Rathann: and it breaks because libavcodec export liba52 symbols and you then link your own liba52 to the same binary... and boom
[09:13] <ogra> i'd really really like to have it in ... its improved a lot 
[09:13] <Rathann> and it showed mplayer linked to /usr/lib/libavcodec.so.0d
[09:13] <Rathann> there's never been such version
[09:13] <Rathann> it should be something like libavcodec.so.49
[09:14] <Rathann> slomo: I see, then it should be fixed
[09:14] <slomo> Rathann: that's the debian version... debian soname because the ffmpeg guys didn't use it right in the past from what i heard
[09:14] <Rathann> is there anything preventing you from packaging the latest SVN snapshot?
[09:14] <ogra> mdz, right, that will go into the request ayway, but some of the foppy stuff wasnt tested well in our packages and sbalneav did a really great job with his first package and the fixes, he deserves to get it in even if its only for his motu application ;)
[09:14] <ogra> *floppy
[09:15] <slomo> Rathann: time :) the version we have is from 2006-08-23
[09:15] <ogra> s/and the fixes/and the fixes for floppy handling/
[09:15] <Rathann> slomo: it's true that in the past ffmpeg didn't care about shared versions
[09:15] <mdz> ogra: it's about the release, not giving someone a reward
[09:15] <Rathann> but that's no longer true
[09:15] <Rathann> slomo: ah, ok
[09:15] <slomo> cool... that's good news :)
[09:15] <Rathann> which reminds me
[09:15] <Rathann> why 0.99?
[09:15] <mdz> ogra: I'll look for your email
[09:15] <dholbach> Riddell: do you know a package using cmake to build offhand?
[09:15] <ogra> mdz, i know ... our floppy handling is simply broken ... but the new package will need some changes to ldm thats something i'd like to have done before beta freeze ...
[09:16] <slomo> Rathann: because 0.99+1.0pre8 < 1.0 < 1.0pre8 for dpkg :)
[09:16] <ogra> ok, i'll mail as soo as i'm home then ... 
[09:16] <Rathann> don't you have something like epochs in rpm?
[09:16] <ogra> *soon
[09:16] <Rathann> i.e. 1:0.1 > 0:5.0
[09:16] <ogra> (have to look at the initramfs-tools as well ..
[09:16] <Mithrandir> Rathann: we do, but we try not to use them unless we have to.
[09:16] <Rathann> ?
[09:16] <ogra> )
[09:16] <Rathann> ah
[09:16] <Rathann> well that's one of those cases I think
[09:16] <_ion> 1.0~pre8 could be used.
[09:16] <slomo> Rathann: we have... also with a colon... but if we used them always we would have 1234:1.0 for some packages probably ;)
[09:16] <Rathann> I'd prefer it if you used the same version as we do
[09:16] <Rathann> well good news
[09:17] <Rathann> we're going to do 1.0rc1 soon
[09:17] <Rathann> probably rc2 too
[09:17] <Rathann> and then 1.0
[09:17] <slomo> _ion: yes but at that time ~ was not recommended
[09:17] <Rathann> and then 1.1. and so on
[09:17] <slomo> cool :)
[09:17] <Rathann> so no more weird preN ;)
[09:18] <Rathann> ok, next issue
[09:18] <_ion> rathann: 1.0rc1 would also be 0.99+1.0rc1 under the old recommendation. :-)
[09:18] <Rathann> why do you have so many --enable-*?
[09:18] <Rathann> most of the stuff is autodetectable
[09:18] <Rathann> provided you have the appropriate -dev package installed
[09:19] <Rathann> in fact, we discourage the use of --enable
[09:19] <dholbach> imbrandon, raphink: does anbody of you know a package using cmake to build?
[09:19] <_ion> rathann: Perhaps to make it complain if a packager has forgot a dependency that should be there.
[09:19] <slomo> Rathann: i know... it's there to keep track of what we want to have enabled
[09:19] <Rathann> because it's known to break things
[09:19] <slomo> how could it break things?
[09:19] <Rathann> if you don't provide --extra-libs and --extra-includes
[09:19] <imbrandon> dholbach: and kde4 stuff
[09:19] <Rathann> because it may fail to link
[09:19] <imbrandon> s/and/any
[09:19] <slomo> Rathann: well it but then it would be a build failure which we would notice and fix then :)
[09:19] <dholbach> imbrandon: ok, got an example package?
[09:20] <Rathann> slomo: keeping track of builddeps should be enough
[09:20] <Rathann> --enable are evil
[09:20] <imbrandon> i THINK speedcrunch , i will have to check one sec
[09:20] <Rathann> ;)
[09:20] <slomo> Rathann: imho it's easier this way ;) and until now we always had a mplayer that was buildable ;)
[09:21] <dholbach> imbrandon: doesn't look like it
[09:21] <imbrandon> dholbach: i just pinged Riddell  he will know for sure
[09:22] <imbrandon> not much outside kde4 does atm
[09:22] <dholbach> imbrandon, Riddell: i'm trying to help the telepathy-qt upstream author to package it and get it into ubuntu
[09:22] <Rathann> ok, that's your choice
[09:23] <Rathann> slomo: but if you didn't use --enable then you wouldn't have to patch configure for aalib, fontconfig and faac detection
[09:23] <imbrandon> dholbach: check kde4base
[09:23] <dholbach> imbrandon: rock and roll - checking
[09:24] <Rathann> slomo: ok, next issue
[09:24] <slomo> Rathann: probably, i'll consider it with the next release
[09:24] <Rathann> AFAIK libmpdvdkit2 (libdvdcss) doesn't contain decss
[09:25] <dholbach> imbrandon: thanks a lot
[09:25] <imbrandon> dholbach: np
[09:25] <slomo> Rathann: at least in the past it did
[09:25] <Riddell> dholbach: strigi probably an easier starting point
[09:25] <Rathann> it never did AFAIK
[09:25] <Riddell> dholbach: there's a cmake.mk cdbs file in there
[09:26] <dholbach> Riddell: neat - that should be in our cdbs too, no?
[09:26] <Rathann> well, that doesn't really matter if you link with libdvdread
[09:26] <Rathann> next issue
[09:26] <Riddell> dholbach: no, it's just included within the package for now
[09:26] <dholbach> hm
[09:26] <slomo> Rathann: it's still in there... just look in your tarball ;)
[09:26] <imbrandon> dholbach: tell him/her they are welcome to pop in #kubuntu-devel anytime also , we'll try to help
[09:26] <Rathann> slomo: what is in there?
[09:27] <Rathann> and which tarball do you mean?
[09:27] <slomo> Rathann: libdvdcss (and the tarball from mplayerhq.hu
[09:27] <Rathann> yes and?
[09:27] <Rathann> it doesn't contain the illegally obtained CSS keys
[09:28] <Rathann> which was what the fuss was about mainly
[09:28] <Rathann> it's still illegal according to DMCA, probably, though
[09:28] <Rathann> but that's another discussion ;)
[09:29] <slomo> yes... and we simply don't want to ship it but this was already discussed a million times everywhere ;)
[09:29] <Rathann> ok
[09:29] <Rathann> what else... ah
[09:30] <Rathann> mplayer and mplayer with GUI (gmplayer) can be installed simultaneously
[09:30] <Rathann> just rename the binary with gui to gmplayer
[09:31] <slomo> i know... currently the guy package has gmplayer as link to mplayer
[09:31] <slomo> but what sense would it make to have almost the same binary installed twice?
[09:31] <Rathann> well, gmplayer is more broken than  mplayer ;)
[09:31] <Rathann> but some people insist on using it
[09:32] <Rathann> so when something doesn't work with gui
[09:32] <slomo> Rathann: even when using it as "mplayer", i.e. without gui?
[09:32] <Rathann> we can tell people to try without gui
[09:32] <Rathann> yes
[09:32] <Rathann> because some codepaths are different then
[09:32] <Rathann> well, it's your choice, really
[09:33] <Rathann> I package mplayer and mplayer-gui in such way that they can be installed simultaneously
[09:33] <Rathann> ah, good thing you don't have Depends: w32codecs
[09:33] <Rathann> and good thing you use scalable font by default
[09:33] <slomo> that won't work anyway as we don't have it packaged anywhere ;)
[09:34] <Rathann> although instead of linking it to usr/share/mplayer/subfont.ttf
[09:34] <Rathann> you can add fontconfig=yes and font="font name" to mplayer.conf
[09:35] <Rathann> since you already link with fontconfig
[09:35] <Rathann> just a tip to consider
[09:35] <slomo> sounds sane ;)
[09:35] <Rathann> that's about it
[09:36] <Rathann> oh, did you read the packaging guidelines?
[09:36] <Rathann> in DOCS/tech/ ?
[09:36] <slomo> ages ago, yes
[09:36] <Rathann> ok
[09:38] <Rathann> slomo: next time, please forward the bugreports to us, ok?
[09:38] <Rathann> thanks for packaging mplayer :)
[09:38] <Rathann> and keep up the good work
[09:39] <Rathann> also, please have a word with ffmpeg pkg maintainer
[09:39] <Rathann> about updating it
[09:39] <slomo> Rathann: sure :) i guess he will update it soon in debian
[09:39] <Rathann> good
[09:40] <Rathann> see you around then (come to #mplayer/#mplayerdev sometimes, we don't bite... much) ;)
[09:40] <slomo> here on freenode?
[09:40] <Rathann> yes
[09:40] <slomo> ok, perfect :)
[09:40] <slomo> thanks for your time :)
[09:41] <Rathann> np.
[10:06] <Kamion> hmm, a dilemma
[10:06] <_ion> The answer is 42.
[10:07] <Kamion> I'd like to add something to ubiquity to say "make sure you've done a CD integrity check before reporting this crash"
[10:07] <Kamion> but if I do that, a sizeable number of people will reboot to do that check before saving the log files
[10:07] <Kamion> and some problems will certainly be lost forever
[10:10] <Kamion> it would be better if there were actually a useful way to report such errors - the problem is that they can and do manifest in practically every imaginable way
[10:10] <Kamion> from failures to read certain files, to corrupted code running in the live session
[10:10] <Kamion> I can't even trust debconf to work reliably in that environment, small though it is
[10:11] <Kamion> at least with the alternate install CD, most of the running code is found close to the centre of the CD, and seems to be less prone to random corruption - MD5 checks on Packages files catch the rest
[10:12] <mjg59> Kamion: People seem to be running out of RAM on ubiquity even on 256MB systems
[10:12] <mjg59> Kamion: I think we're going to need to consider a pure-ubiquity (ie, non-Gnome) option
[10:13] <Kamion> Mithrandir: how insane do you think it would be to put an md5sum.txt somewhere and have all the files in the squashfs checked on startup?
[10:13] <Kamion> I mean, would it actually work out insanely slow, given that we have to read big chunks of it anyway?
[10:13] <Kamion> mjg59: patches welcome. (seriously. I hate that kind of code.)
[10:13] <Kamion> I hate writing it, anyway
[10:13] <mjg59> Kamion: Right
[10:14] <Mithrandir> Kamion: I could just make the cdrom-checker bit non-optional and non-rebooting.
[10:14] <Kamion> also I'm not sure we've exhausted our "just make it use less memory" options
[10:14] <mjg59> Kamion: This is cheap and can be implemented fairly fast
[10:14] <mjg59> But obviously general resource usage improvement would be better :)
[10:14] <Kamion> sure, but it also has heavy UI implications
[10:15] <mjg59> Do you have time allocated for that before release?
[10:15] <Kamion> at present, I'm entirely bug-fixing, and memory use counts
[10:15] <Kamion> well, pretty much entirely
[10:15] <mjg59> Kamion: Ok
[10:15] <Kamion> currently I'm trying to get the ubiquity bug list under control, and fixing stuff along the way
[10:20] <shackan> xfce is not an option ?
[10:21] <Kamion> not here
[10:21] <Kamion> the Ubuntu desktop CD also serves as a demonstration of the Ubuntu desktop, which is GNOME
[10:21] <Kamion> we do not have room to put XFCE on the disk as well
[10:29] <dholbach> Riddell, slomo: is libdbus-qt4-1-dev meant to be used?
[10:29] <slomo> dholbach: no... something from qt4-x11-kdecopy should be used
[10:30] <dholbach> aha
[10:30] <slomo> dholbach: libdbus-qt4-1* will disappear soon after openoffice is finally rebuild against new dbus
[10:31] <slomo> dholbach: but better talk to Riddell about qt stuff... i try to touch c++ as less as possible ;)
[10:32] <dholbach> libqt4-core-kdecopy? maybe?
[10:32] <slomo> yes
[10:48] <dholbach> good night everybody
[10:49] <Riddell> dholbach: you need qt 4 dbus?
[10:49] <dholbach> Riddell: telepathy-qt does
[10:50] <Riddell> dholbach: unless it's using qt 4.2 use libdbus-qt4-1-dev
[10:50] <dholbach> Riddell: hum, that's not installable
[10:51] <Riddell> uh oh
[11:06] <slomo> BenC: ping?
[11:14] <Kamion> bug 54787> you know I'd never really considered the notion of putting /var on NTFS ...
[11:14] <Ubugtu> Malone bug 54787 in ubiquity "Installer crashes" [Untriaged,Needs info]  http://launchpad.net/bugs/54787
[11:14] <Kamion> though I did add a check for it, but only along with a bunch of other stuff :)
[11:21] <dieman> Kamion: heh
[11:21] <dieman> Kamion: i could see putting /boot on NTFS though
[11:22] <dieman> alltho i'd just use fat32 at that point
[11:22] <dieman> makes it easier to edit grub's config from windows if you want to automate boot changes
[11:31] <Kamion> dieman: I don't think I'd want to put /boot on a filesystem that Linux can't write to reliably
[11:34] <Kamion> bug 55106 wins some kind of descriptive bug subject prize
[11:50] <desrt> bug 55106
[11:50] <Ubugtu> Malone bug 55106 in ubiquity "?" [Untriaged,Needs info]  http://launchpad.net/bugs/55106
[11:52] <shining> lol
[11:54] <shining> found this quite funny, but I've to admit I generally don't find it obvious how to correctly report a bug, what information is relevant
[11:56] <Kamion> shining: a clue is that if a dialog pops up asking you to report a bug and attach certain pieces of information, then you should follow its instructions ;)
[12:00] <shining> oh :) it's worse than I thought then
[12:07] <Kamion> mjg59: could you have a look at bug 46853?
[12:07] <Ubugtu> Malone bug 46853 in ubiquity "grub install fails on Macbook Pro" [Medium,Confirmed]  http://launchpad.net/bugs/46853
[12:07] <Kamion> suggestions of grub patches in there