[12:17] <crimsun> funman: excellent, thank you
[12:18] <funman> :)
[12:19] <funman> was the package updated already ?
[12:19] <joejaxx> Kamion: are you around?
[12:20] <crimsun> funman: not yet, I'm still at work and have not been able to wrest time for Ubuntu yet (but will within the next 4 hours). If Sam hasn't updated the vlc source package in Sid, I'll backport from svn directly.
[12:21] <funman> ok
[01:25] <jdong> what would trigger a xen0 "attempted to kill idle process" panic on boot?
[01:25] <jdong> is that equivalent to not being able to mount root?
[01:26] <funman> probably
[01:27] <jdong> mmmkay
[01:27] <jdong> my root is a bit out of the ordinary (on dm/LVM)
[01:27] <funman> dm ?
[01:27] <jdong> device mapper
[01:27] <jdong>  /dev/mapper/main-root
[01:32] <funman> look at the logs
[01:32] <funman> xm log
[01:33] <jdong> what logs?
[01:33] <funman> xen logs
[01:33] <funman> hum is it for domU or dom0 ?
[01:33] <jdong> oh cool, xen can write to undetected filesystems?
[01:33] <jdong> it's for dom0
[01:34] <jdong> my hd is not touched at all before xen panics
[01:34] <jdong> and then a few seconds later, it auto-reboots
[01:34] <jdong> the backtrace wasn't scrollable
[01:34] <jdong> barely readable for a few seconds
[01:36] <funman> sorry
[01:37] <funman> sorry xen write logs about domUs
[01:37] <jdong> yeah, I can imagine it does
[01:37] <funman> then maybe the kernel is fucked
[01:37] <funman> what is it ?
[01:38] <jdong> the xen kernel that edgy has
[01:38] <jdong> it's on amd64
[01:39] <funman> :/
[01:39] <funman> sorry i don't run ubuntu
[01:39] <funman> nor i own a 64bits pc
[01:40] <jdong> k, I'll play with it some more
[01:40] <funman> try to recompile a kernel
[01:40] <jdong> not in the mood for that....
[01:40] <funman> https://alioth.debian.org/download.php/1561/linux-2.6.16-xen3.0.2-hg9629.patch.gz
[01:40] <jdong> I don't want to see if xen works that badly
[01:41] <jdong> I just wanted to see if edgy's xen would work out of the box
[01:41] <funman> :p
[01:41] <funman> hmm
[01:41] <jdong> I actually don't have much of a reason for running xen, except for fun
[01:41] <funman> i had issues about initrd
[01:41] <jdong> I am suspecting the initrd doesn't start LVM/device-mapper properly
[01:41] <jdong> I'll ask mr. xen tomorrow
[01:48] <gnomefreak> i thought i remember someone saying pyton-gtk-1.2 was fixed?
[01:49] <gnomefreak> python-gtk-1.2 even
[02:09] <_ion> Wow, avahi-daemon is installed by default? That rules.
[02:11] <Seveas> _ion, it was added to the seeds today
[02:11] <_ion> Yeah, i just read the ubuntu-meta changelog.
[03:07] <bddebian> Howdy
[03:09] <grexk> hello everyone, is pam_ldap broken in edgy?
[03:10] <LaserJock> grexk: Launchpad would be the place to look for that info
[03:12] <grexk> http://pastebin.ca/192561 I have this configuration, when I reboot it stuck before mounting local filesystem
[03:13] <grexk> but when I remove ldap from /etc/nsswitch.conf, I can boot without problems.
[03:13] <grexk> brb
[04:55] <BenC> anyone here have ich8 chipset machine that uses the achi driver?
[05:40] <thejoe> I'm trying to install Ubuntu 6.06LTS.  I already have partitions set. I manually edit the partitions during the installation to set up swap and root partitions.  I set up the swap partition, but when I click next the size displays 0kb and I'm unable to install.
[05:42] <minghua> thejoe: please ask support questions on #ubuntu, thanks
[05:42] <thejoe> Ok
[08:27] <tfheen> ajmitch: why do you put the xen udev rules in /etc/udev rather than in /etc/udev/rules.d?
[08:31] <ajmitch> tfheen: probably something I missed when checking it
[08:32] <desrt> dir.d is weird... not made any better by some particularly high profile misusers
[08:34] <tfheen> ajmitch: that's wrong.  In ubuntu, the rules should go into the rules.d, none of the symlinking stuff which is in Debian.
[08:36] <ajmitch> looks like there's a few packages thet get it wrong. I'll fix up xen
[08:36] <tfheen> thanks.
[08:36] <tfheen> make sure to get the "move the conffile" bits correct too
[08:36] <esac> hi, how does one go about getting a new version of a program included in the apt repositories for dapper ?
[08:37] <tfheen> esac: you don't.  Dapper's released.
[08:37] <esac> but what about upgrades ?
[08:37] <tfheen> what do you mean?
[08:37] <esac> in dapper if i do apt-get install rdesktop, i get 1.4.1 .. 1.5.0 has since been released
[08:38] <tfheen> yes, and?  We don't update a released distro with new versions.
[08:38] <esac> seriously ? :) ok i was under the mistaken impression that when i did an apt-get upgrade, that it picked up new versions of packages
[08:39] <tfheen> esac: I have no idea where you got that impression from, since we've never done things that way.
[08:46] <Ubugtu> Malone bug 57872 in gnome-power "regression: pressing power button no longer brings up logout dialog" [Unknown,Unconfirmed]  http://launchpad.net/bugs/57872
[09:10] <pitti> Good morning
[09:11] <tfheen> morning, pitti
[09:11] <janimo> hi pitti
[09:12] <pitti> hi janimo, hey tfheen
[09:18] <desrt>
[09:19] <desrt> erp
[09:41] <dholbach> good morning
[09:41] <janimo> dholbach: morning
[09:42] <dholbach> hey janimo
[09:48] <sivang> morning
[09:50] <janimo> hi sivang
[09:50] <sivang> hi janimo , what's up?
[09:58] <Chipzz> esac: you do get new versions, just not new *upstream* versions. you get bugfixes
[10:19] <janimo> seb128: hi, python-gnome2 FTBFS, should I work aorund that ar are you going to?
[10:19] <seb128> give me a break
[10:19] <janimo> seb128: a proper fix needs to be found, but until then make check should be disabled
[10:19] <seb128> you already commented on the wrong bug about it
[10:20] <janimo> seb128: why wrong? It was that change that causes it no?
[10:20] <seb128> any reason it should not be fixed properly now?
[10:20] <seb128> right
[10:20] <seb128> the bug was about the split
[10:20] <seb128> and you commented saying the new version ftbfs
[10:20] <janimo> seb128: well if you got a ifx at hand sure. If it takes a few days it may be good to fix the FTBFS first
[10:20] <seb128> which is a totally different issue
[10:20] <janimo> to let the new binarties in the archive
[10:21] <seb128> I'll fix it, we don't let thing not building, don't worry
[10:21] <seb128> no need to ping me every day about it
[10:22] <tfheen> mvo: you seem to have a lot of 6.10-targetted bugs; are you in control of them?  There are also some bugs which aren't assigned to you, but where you're probably the guy who knows most about them.
[10:22] <janimo> seb128: that was not the wrong bug btw, and it was not about the split AFAICT
[10:22] <janimo> seb128: bug 28279
[10:22] <Ubugtu> Malone bug 28279 in kdetoys "kdetoys: new changes from Debian require merging" [Medium,Rejected]  http://launchpad.net/bugs/28279
[10:22] <seb128> janimo: it was the wrong bug, it was a fixed bug
[10:22] <mvo> tfheen: I used the milestone quite liberally, I will go over them now to see wich are really critical. A lot of those should already be closed
[10:23] <janimo> typo
[10:23] <seb128> janimo: no point to argue, there is a build issue you open a bug about it, you don't comment on a fixed bug
[10:23] <tfheen> mvo: ok, thanks.
[10:23] <tfheen> mvo: please do target stuff, it gives me a feel for what needs to be fixed. :-)
[10:23] <janimo> seb128: you should use pbuilder before uploading
[10:24] <seb128> janimo: give me a break
[10:24] <mvo> tfheen: sure :) I used it for stuff like "nice-to-have" as a reminder for myself a lot as well as for really critical stuff
[10:24] <seb128> janimo: bothering people is anti-productive, you know that?
[10:25] <janimo> seb128: stop being arrogant!
[10:25] <fabbione> janimo, seb128: please guys.. take it easy eh?
[10:25] <seb128> janimo: you just make me waste 5 min to reply to your stupid arguments for I bug I know about and will fix
[10:25] <fabbione> it's not even 11am and i am hacking on glibc
[10:25] <seb128> I could have fixed the bug during that time
[10:25] <janimo> you made an upload which FTBFS I ask if I can fix it or you get around it yourself and you start with your BS again
[10:25] <seb128> hey fabbione ;)
[10:26] <fabbione> hey seb128
[10:26] <fabbione> janimo: calm down please
[10:26] <fabbione> both of you
[10:26] <fabbione> no point in arguing
[10:26] <seb128> janimo: you already bug commented on launchpad yesterday, I don't need to be pinged several time about the same issue, that's just annoying
[10:26] <seb128> pressure don't make things go faster
[10:26] <seb128> I've lot to do, let me a day to fix it
[10:26] <janimo> seb128: I pinged because I could upload the fix myself to let you work on other things
[10:27] <janimo> seb128: but ok go ahead youself
[10:27] <fabbione> STOP
[10:27] <seb128> you don't have a fix, you just want to revert the change
[10:27] <fabbione> all friends like before
[10:27] <seb128> :)
[10:27] <fabbione> :D
[10:28] <fabbione> janimo: btw.. i did install xubuntu on one of my toys...
[10:28] <fabbione> not too bad..
[10:28] <fabbione> i expected worst to be hounest :)
[10:28] <tfheen> seb128: I promised I wouldn't nag you about stuff assigned to desktop bugs for 6.10, but bug 36251 is 6.10-targetted and not assigned to ubuntu-desktop.  Are you handling those or do you want me to reassign or ... ?
[10:28] <Ubugtu> Malone bug 36251 in edgy-gdm-themes "Unreadable Font Size for GDM Login/Password" [Medium,Confirmed]  http://launchpad.net/bugs/36251
[10:29] <seb128> tfheen: iz artwork bug
[10:29] <janimo> fabbione: anything you find lacking in xubuntu?
[10:29] <tfheen> seb128: ok, so fschoep then?
[10:29] <fabbione> janimo: not really.. no.. it's enough for what i usually do.. that means opening a few xterms and ssh to servers :)
[10:29] <seb128> tfheen: I'll speak with dholbach to know what is the way to get an artwork fix properly, I don't know if they use some bzr or something
[10:30] <tfheen> seb128: thanks.
[10:30] <seb128> np
[10:30] <dholbach> seb128, tfheen: fschoep works on that, afaik
[10:31] <janimo> fabbione: even twm is enough for that ;)
[10:31] <fabbione> janimo: yeah i know :)
[10:31] <fabbione> oh
[10:31] <fabbione> there was something
[10:31] <fabbione> xterm in xubuntu doesn't set PATH properly
[10:31] <fabbione> ~/bin specifically
[10:32] <tfheen> fabbione: xterm doesn't set PATH. :-P
[10:32] <fabbione> tfheen: tsk.. it does in ubuntu...
[10:32] <tfheen> fabbione: no, bash or zsh or whatever does
[10:33] <janimo> fabbione: I just ran an xterm and it sourced .bashrc fine, I have ~/bin set
[10:33] <fabbione> janimo: not here
[10:33] <fabbione> tfheen: right.. bash.. well you got the point
[10:33] <janimo> fabbione: did you run plain xterm? (say via alt-f2)
[10:34] <fabbione> janimo: from the menu iirc
[10:34] <fabbione> i can check later tho
[10:34] <fabbione> right now the machine is doing a test install
[10:34] <janimo> fabbione: and is it xterm or some other terminal like xfce4-terminal?
[10:35] <fabbione> janimo: i will need to re-check.. i use that installation as external viewer for x-plane.. nothing too fancy :)
[10:35] <janimo> ok
[10:35] <fabbione> the only reason i noticed is because i need an LD_PRELOAD
[10:35] <fabbione> and i use a script in ~/bon
[10:35] <fabbione> yeah right.. bon(G)
[10:35] <fabbione> bin
[10:35] <fabbione> you get it
[10:52] <xorl> how long does pbuilder take to check itself on initial
[10:53] <Hobbsee> xorl: depends how fast your computer is
[10:53] <Hobbsee> andhwat your download speed is
[10:53] <xorl> 20down 2.2Ghz AMD64, pretty fast?
[10:53] <Hobbsee> shouldnt take that long then
[10:53] <Hobbsee> hey Keybuk
[10:54] <Keybuk> *yawns*
[10:54] <Hobbsee> that'll wake you up
[10:54] <Keybuk> heh
[10:54] <Keybuk> that's just the kind of thing David would do
[10:54] <lifeless> morning Keybuk
[10:54] <xorl> how long does it usually take? like 20-30 min or less, never used it before.
[10:54] <lifeless> congrats on upstart, it is looking sweet
[10:54] <Hobbsee> Keybuk: david?
[10:55] <Hobbsee> xorl: probably.  just wait
[10:55] <xorl> making base.tgz already
[10:55] <xorl> ll
[10:55] <xorl> lol so i can safely assume it's damn near done.
[10:56] <Hobbsee> yeah
[10:56] <Keybuk> Hobbsee: my partner
[10:56] <Keybuk> lifeless: thanks
[10:56] <Hobbsee> Keybuk: ahh..
[11:00] <sivang> sladen: would it be possible to install bzr on muse?
[11:03] <sivang> hi Hobbsee , what are you up to today?
[11:04] <Hobbsee> sivang: heya.  not sure yet.  might go visit a friend o fmine
[11:04] <sivang> Hobbsee: I mean in packaging, kubuntuing etc :-)
[11:05] <Keybuk> pitti: so the ddebs contain the full binaries?
[11:06] <Hobbsee> sivang: well, if i'm there, i wont be doing any packaging
[11:07] <tfheen> morning, Hobbsee
[11:08] <Seveas> tsss, the almighty Hobbsee can't even split herself? ;)
[11:08] <sivang> hey Seveas
[11:08] <Seveas> hi
[11:11] <Hobbsee> Seveas: not when there's only dialup internet there :P
[11:11] <Hobbsee> hey tfheen!
[11:11] <ajmitch> Hobbsee: how unfortunate
[11:11] <ajmitch> Hobbsee: you need to pick better friends ;)
[11:11] <Hobbsee> ajmitch: indeed
[11:11] <Hobbsee> hah
[11:11] <pitti> Keybuk: no, just the detached debug symbols
[11:12] <seb128> pitti: any plan to make them ship the source code too btw? I think the debug rpm do that
[11:12] <pitti> seb128: ugh, that would make them even bigger
[11:12] <pepsiman> pitti: how do you detach debug symbols?  objcopy?
[11:12] <Keybuk> pitti: aren't the things in /usr/lib/debug/sbin etc. supposed to be full binaries?
[11:12] <pitti> pepsiman: yes
[11:13] <sladen> sivang: hmm, bzr isn't in sarge
[11:13] <Keybuk> quest dbg% file usr/lib/debug/sbin/init
[11:13] <Keybuk> usr/lib/debug/sbin/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
[11:13] <ogra> pitti, oooh, i guess you forgot about the gstreamer autosink stuff as well, right ? i just remembered we have soemthing left to look into ...
[11:13] <Keybuk> pitti: clearly I'm missing something ... ?
[11:13] <pitti> Keybuk: not to my knowledge; /usr/lib/debug is the standard path for detached debug symbols (where gdb looks for them by default)
[11:13] <pitti> Keybuk: and the original dh_strip also only puts the debug symbols there, not the full binaries
[11:14] <pitti> Keybuk: well, they are ELF files, but there's no code :)
[11:14] <Keybuk> pitti: aahhh
[11:15] <pitti> $ /usr/lib/debug/usr/bin/gedit
[11:15] <pitti> bash: /usr/lib/debug/usr/bin/gedit: cannot execute binary file
[11:15] <Keybuk> so if I install that, gdb will automatically locate the debug symbols for it?
[11:15] <seb128> correct
[11:16] <pitti> Keybuk: yes
[11:16] <sladen> sivang: build/point me to the debs.  OTOH muse only appears to have 38MB of disk free
[11:16] <Keybuk> why -dbgsym, not -dbg?
[11:16] <pitti> seb128: the symbolic stack trace has file names and line numbers; that should be sufficient IMHO and avoids doubling the package sizes again
[11:16] <pitti> Keybuk: to not conflict with existing -dbg packages
[11:16] <Keybuk> how do you generate them?
[11:17] <pitti> Keybuk: apt-cache show pkg-create-dbgsym
[11:17] <sivang> sladen: ah, then nevermind, I don't want to consume more disk space there then.
[11:17] <sladen> Keybuk: and AFAIK they only have symbols, split out afterwards
[11:17] <seb128> pitti: right
[11:17] <sivang> sladen: I should probably use supermirror to store my branches instead :-)
[11:17] <Keybuk> pitti: heh
[11:17] <Keybuk> cute
[11:17] <pitti> Keybuk: FYI, https://wiki.ubuntu.com/AptElfDebugSymbols
[11:17] <sladen> sivang: you don't actually need bzr to store a copy of your branches
[11:18] <pitti> Keybuk: yeah, another debhelper Hack of Death :)
[11:18] <Keybuk> pitti: btw, on apport, last time I had a crash, it didn't actually do anything to file the bug for me
[11:18] <Keybuk> it just gave me a window with the crash filename
[11:18] <sladen> Keybuk: it's the type of daft crack you'd come up with, only pitti got there first
[11:18] <Keybuk> is that all it's supposed to do?
[11:18] <pitti> Keybuk: it's supposed to open the packages' bug page in the browser
[11:18] <Keybuk> sladen: I'd just change debhelper directly and mail pictures to joeyh
[11:19] <Keybuk> pitti: I was expecting it to actually file the bug, and automatically detect duplicates
[11:19] <Keybuk> I guess that's the "next version"?
[11:19] <Keybuk> (I'd heard you talking about that at some point)
[11:19] <pitti> Keybuk: yeah, that's 'bug reporting tool'
[11:19] <pitti> Keybuk: apart from that, I do not think that we should file actual bugs for automatic crash detections
[11:19] <pitti> we'll get flooded
[11:19] <pitti> we need a separate db for that IMHO
[11:19] <Keybuk> yeah, those need to be support requests or something
[11:20] <Keybuk> or have a Malone "crash reports" section
[11:20] <pitti> the latter rather
[11:20] <Keybuk> view all crash reports -> link crash report to bug -> etc.
[11:20] <pitti> exactly
[11:20] <pitti> and an automatic dup finder
[11:21] <pitti> Keybuk: it should actually work since it's spawned from the kernel
[11:21] <pitti> but right, would be interesting
[11:21] <Keybuk> init does install its own segv handler
[11:21] <sivang> pitti: a dup filter running agains the same speperate db yes?
[11:21] <pitti> Keybuk: ah, then it won't be called
[11:21] <sivang> *against
[11:21] <Keybuk> actually, it probably would
[11:22] <pitti> Keybuk: but it might not install a handler for SIGFPE or SIGBUS
[11:22] <pitti> apport triggers on those, too
[11:22] <Keybuk> the segv handler forks, and in the child sets the segv signal back to default, then raises SIGSEGV
[11:22] <Keybuk> and in the parent, just waits for the child to finish, before carrying on and pretending nothing happened
[11:22] <pitti> heh, clever
[11:22] <pitti> bbiab
[11:23] <Keybuk> we stared at the kernel code hard enough to decide that there was no major consequences of ignoring a SEGV
[11:23] <xorl> man for one file (qingy) the deps on that thing are nuts with pbuilder
[11:23] <xorl> lol
[11:23] <Hobbsee> hey sfllaw
[11:23] <jernst> hi, is there any official ubuntu kernel with soft RAID built-in (RAID0) ?
[11:24] <sivang> morning sfllaw
[11:26] <fabbione> jernst: all of them..
[11:26] <ogra> http://pastebin.ca/192862 ouch
[11:26] <ogra> thats from a chroot upgrade dapper->edgy
[11:26] <ogra> is our linux-image package missing a dependency ?
[11:26] <jernst> fabbione: it seems that raid comes in a module so that it's not possible to have a root filesystem on raid0
[11:27] <fabbione> jernst: it's a module, but it is perfectly possible to have root on it. use initramfs
[11:27] <ogra> s/dependency/versioned dependency/
[11:27] <gnomefreak> ogra: i got that on an upgrade and rebooted into kernel and it would set up using dpkg --config -a
[11:28] <ogra> gnomefreak, well, it should have the right version of mkinitramfs if it tries what it does imho
[11:28] <gnomefreak> agree
[11:28] <ogra> kernel team ?? ^^^^
[11:30] <ogra> (fabbione, BenC ??)
[11:30] <fabbione> ogra: what?
[11:30] <ogra> see above
[11:30] <ogra> http://pastebin.ca/192862 happens during an upgrade of a dapper chroot to edgy
[11:31] <fabbione> and why on earth do you have a kernel installed in a chroot?
[11:31] <ogra> fabbione, thin clients :)
[11:31] <jernst> fabbione: thanks, I didn't know about it. Will do some research... Is there a Debian/Ubuntu way of doing it so that it is correctly build when the kernel is updated (sorry to ask questions here, but the user channel doesn't seem to know about such issues)
[11:31] <fabbione> jernst: it's our default way of doing stuff.
[11:32] <fabbione> jernst: man update-initramfs
[11:32] <ogra> fabbione, looks to me like we should have a versioned dependency on the right initramfs-tools package
[11:32] <dholbach> hey heno
[11:32] <fabbione> jernst: but please move this somewhere else.. it's really offtopic here
[11:32] <heno> hey dholbach
[11:32] <fabbione> ogra: i have never seen that error upgrading machines here
[11:32] <ogra> well, gnomefreak said he saw it on a normal upgrade
[11:33] <ogra> and solved it with dpkg --configure -a after reboot
[11:33] <gnomefreak> fabbione: i saw it on 2 of my upgrades
[11:33] <fabbione> gnomefreak: i did a dist upgrade 2 hours ago... and i didn't see it
[11:33] <gnomefreak> it looks exactly like it from what i remember
[11:33] <fabbione> ogra: how did you upgrade?
[11:33] <ogra> dapper->edgy ?
[11:33] <gnomefreak> fabbione: this was weeks ago
[11:34] <gnomefreak> ogra: yeah ive been testing upgrades so i can keep help up to date
[11:34] <fabbione> ogra: "how" not "what"? what tool did you use?
[11:34] <ogra> http://pastebin.ca/192871
[11:34] <ogra> essentially after that reciepe
[11:35] <ogra> (i'm not the one upgrading, cbx33 is testing thin client upgrades for me)
[11:35] <xorl> cant build a deb package out of this, nuts.
[11:36] <iwj> tfheen: bug 57161> Nothing is happening with it; thanks for bringing it to my attention.  The right answer is to use libnspr-dev, not libnspr4-dev.
[11:36] <Ubugtu> Malone bug 57161 in xulrunner "Impossible to install libsmjs-dev with firefox present" [Unknown,Confirmed]  http://launchpad.net/bugs/57161
[11:36] <xorl> the configure script cant find directfb although it's part of the deps
[11:36] <fabbione> ogra: well get the info, because even using apt-get dist-ugrade, initramfs-tools are updated before the kernel
[11:36] <ogra> which info ?
[11:37] <fabbione> ogra: on how he did test the upgrade?
[11:37] <tfheen> iwj: there's that and an epiphany-breaking bug which are your bugs that are targetted for 6.10.  If you could look at them and fix them urgently-ish, that'd be good.
[11:37] <ogra> fabbione, after the reciepe in http://pastebin.ca/192871
[11:37] <ogra> a simple dist-upgrade
[11:38] <iwj> I have just assigned #57161 to me; it wasn't, previously.
[11:38] <xorl> with pbuilder why cant I see the config.log error?
[11:38] <iwj> dholbach mentioned the epiphany bug and said it wasn't particularly urgent.  But fine, if it's urgent for you I'll get right on it.
[11:38] <tfheen> iwj: it's targetted for 6.10, RC freeze is on Thursday.
[11:39] <iwj> 6 days from today, yes.
[11:39] <tfheen> yes, and with a weekend in between.
[11:39] <iwj> Right.
[11:39] <tfheen> that's urgently-ish
[11:39] <tfheen> (in my vocabulary)
[11:39] <iwj> I think it would be better to do the epiphany fix on Monday rather than today.  If it breaks something it will be easier to fix straight away.
[11:40] <tfheen> iwj: fine with me
[11:40] <iwj> Right.
[11:40] <Keybuk> yeah, there's bad history with iwj touching mozilla-related packages on Friday ;)
[11:40] <ogra> heh
[11:40] <tfheen> just trying to make sure it gets fixed, I don't care that deeply about it happening today or monday, but I do want it before thursday.
[11:40] <iwj> Right.
[11:41] <heno> tfheen: I tested the (ubuntu) live CD yesterday with the F5 option but still no joy :(
[11:41] <tfheen> heno: :-(
[11:41] <tfheen> heno: did you manage to get it debugged?
[11:42] <heno> tfheen: not sure where to poke. the at-spi stuff is not turned on; it doesn't seem to activate anything
[11:43] <tfheen> heno: hmm, ok.  I'll poke it after finding some food, I think.
[11:43] <heno> tfheen: thanks, I'll bring it up at the a11y meeting
[11:44] <heno> Luke might poke around a bit as well
[11:44] <heno> TheMuso: ^ we're talking about the casper settings on the live CDs
[11:46] <xorl> when i run pbuilder when its done compiling and all that good shtuff it dpkg-deb gives an error tar: -: file name read contains nul character (this the dash after the ver  prog_ver-1_arch.deb?)
[11:55] <iwj> mvo: Can you shed any light on bug 64012 ?  It seems that this person's /var/lib/dpkg/available contains `Status' fields.
[11:55] <Ubugtu> Malone bug 64012 in dpkg "Bogus chars in "available" file after upgrade" [Medium,Needs info]  http://launchpad.net/bugs/64012
[11:57] <mvo> iwj: no, I don't have more information than what is in the report. But as I wrote there I strongly suspect a HW problem. I just wanted to have a second pair off eyes looking at it
[11:58] <jernst> fabbione: thanks for your help, everything works now
[11:58] <TheMuso> tfheen: Any references to gnopernicus in scripts/30accessibility can be changed to orca.
[11:58] <fabbione> jernst: no problem
[11:59] <TheMuso> There are probably other necessary changes, but I need to look into those further.
[11:59] <TheMuso> WIll get back to you.
[12:01] <iwj> mvo: Fair enough.  It's definitely very strange.
[12:02] <tfheen> TheMuso: just s/gnopernicus/orca/g in that file?  I'll do that.
[12:02] <tfheen> TheMuso: if you can test the rest too, excellent
[12:02] <TheMuso> Will do. I think some of the stuff related to magnification needs changing as well, but I will know more once I have tested it.
[12:03] <dholbach> a11y team meeting about to start (for those of you, who're interested).
[12:07] <xorl> what keyserver does the dpkg-buildpackage check?
[12:07] <tfheen> your local keyring.
[12:08] <tfheen> pitti: re 56755, was it you or mdz who made it 6.10?  With the obvious approach not working, I'm not sure it's doable for 6.10?
[12:09] <pitti> tfheen: I added the milestone since it initially seemed easy to do
[12:09] <pitti> tfheen: I'll remove it probably
[12:09] <pitti> it's too intrusive to fix it now IMHO
[12:09] <tfheen> pitti: yeah, agreed.  If it had been the easy fix it looked like it would have been fine, but when it's not -> defer.
[12:12] <xorl> night guys
[12:14] <Keybuk> there's still one guy utterly *convinced* that mount-by-UUID is all about tracking users
[12:15] <ajmitch> canonical is out to control the world again?
[12:15] <infinity> Keybuk: mount-by-UID could be interesting, I guess...
[12:15] <Ng> haha
[12:20] <Keybuk> of course, we could send a little packet every time a filesystem is mounted containing its UUIDs and where it was mounted
[12:20] <Keybuk> and then Jane could track them, and gain a unique user count
[12:20] <Keybuk> then we wouldn't need to do with with ntp <g>
[12:20] <Keybuk> but I better not give silbs ideas
[12:21] <infinity> I hear that users really like "product activation", we could just give that a try.
[12:22] <ajmitch> Microsoft are doing some nice innovations with vista in that area
[12:22] <Keybuk> heh
[12:22] <Keybuk> I like the MS product activation stuff
[12:22] <Keybuk> whenever it fails, just phone them
[12:22] <infinity> A friendly dialog that says "Yes, the source is free, if you don't like activation, fork."
[12:22] <Keybuk> they appear to assume nobody pirating their software would have the balls to call them and ask for a key
[12:24] <pitti> Keybuk: wrt bug 63738, file-rc does not support the multiuser option, right? So I cannot just add an alternative dependency
[12:24] <Ubugtu> Malone bug 63738 in cupsys "cupsys breaks systems with file-rc installed" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63738
[12:24] <infinity> Keybuk: We could just do "phone-only activation", with no internet option, to give people in the office someone to talk to.
[12:24] <Keybuk> pitti: *shrug* it's a bit irrelevant in edgy
[12:25] <Keybuk> I sincerely doubt upstart can even run file-rc :p
[12:25] <pitti> ok :)
[12:25] <pitti> then I'll just reject the bug, I guess
[12:26] <ogra> Keybuk, my usb problem on the thin client definately is triggered by DO_NOT_SWITCH_TV
[12:26] <ogra> *VT
[12:26] <Keybuk> certainly if you have file-rc installed, you can't have upstart-compat-sysv installed
[12:26] <Keybuk> ogra: lies.
[12:26] <Keybuk> you have a USB device that breaks if your machine does not call "chvt 1" at an appropriate place?
[12:26] <ogra> if i drop the variable in front of the usplash start command it works...
[12:27] <ogra> as well as if i put a chvt -t 7 in front of it
[12:27] <ogra> it only breaks with the variable set
[12:27] <Keybuk> ogra: I look forward to reading your debugging analaysis
[12:27] <ogra> so i suspect its a race with X or something
[12:28] <ogra> the devices work if i replug them once i'm in X
[12:28] <infinity> X and kernel in a bus-scanning race?
[12:28] <ogra> well, i'll look into it, but currently the chvt -t 7 gives me exactly what i want on the thin client ...
[12:29] <ogra> so i lean to just stay with it ... (we only have tty1 and 7 on thin clients anyway)
[12:29] <Keybuk> ogra: I'd recommend finding out why it breaks first, before deploying random fixes
[12:30] <ogra> as i said, i'll look into it ... but it works fine as is now ...
[12:30] <Keybuk> ogra: what is the USB device?
[12:31] <ogra> lsusb doesnt show me the mouse ...
[12:31] <Keybuk> it's a mouse?
[12:31] <ogra> the keyboard is 0430:0005
[12:31] <Keybuk> you're using /dev/input/mice in xorg.conf, not /mouseN or /inputN ?
[12:31] <Keybuk> oh, usb keyboard
[12:31] <Keybuk> yeah, you're probably racing X
[12:31] <Keybuk> "sleep 1" would solve it to, I suspect
[12:31] <ogra> i use whatever the postinst creates in xorg.conf
[12:31] <Keybuk> the lack of chvt just means you get to X slightly fasty
[12:31] <Keybuk> uh, faster
[12:31] <ogra> we're running dpkg-reconfigure during boot
[12:33] <ogra> hmm, well ... the xorg.conf generation happens as pre-last servbice in rcS and X is started as the second service in rc"
[12:33] <ogra> *rc2
[12:33] <ogra> so its probably still generating the config ...
[12:33] <ogra> no
[12:33] <ogra> hmm
[12:33] <ogra> X wouldnt start
[12:36] <Keybuk> Will remove the following packages from edgy:
[12:36] <Keybuk>    file-rc |     0.8.10 | source, amd64, hppa, i386, ia64, powerpc, sparc
[12:36] <Keybuk> oops
[12:36] <Keybuk> :)
[12:38] <infinity> Man, OpenOffice is really clunky...
[12:40] <ogra> hmm, looking at usplash init i dont see why it should break ...
[12:40] <zul> 'ksg ajmitch hi
[12:40] <zul> doh
[12:41] <ajmitch> heh
[12:44] <smurf> usplash doesn't seem to like 800x640 screens very much -- either that, or something mis-guesses my iBook's resolution
[12:53] <smurf> *grumble* worked in dapper. I hate regressions.
[12:55] <Keybuk> mjg59: around?
[01:09] <mjg59> Keybuk: Hi
[01:09] <Keybuk> mjg59: I've proposed a spec for edgy+1 ... get rid of the usplash timeout entirely
[01:10] <Keybuk> are you going to be in attendance?
[01:10] <mjg59> Keybuk: Nope
[01:10] <infinity> Rationale being that "we don't display stuff on the console anymore anyway, so why bother timing out?"
[01:10] <Keybuk> infinity: exactly
[01:11] <mjg59> Keybuk: We still display kernel errors
[01:11] <infinity> Not true if one drops "quiet" from their commandline, mind you.
[01:11] <infinity> And yeah, we display errors.
[01:11] <mjg59> And right now, have no way of getting those into usplash
[01:12] <Keybuk> why can't we get those into usplash?
[01:12] <mjg59> But if you can provide some mechanism to ensure that things like missing root filesystems or a kernel oops get reported to the user without them having to fiddle with configuration, that would be good
[01:12] <infinity> I propose something called "bluesplash", which will blit OOPSes and PANICs to the framebuffer in a pleasant white-on-blue VGA font.
[01:13] <infinity> It'll be revolutionary.
[01:13] <Keybuk> infinity: brown!
[01:13] <Keybuk> BROWN SCREEN OF DEATH!
[01:13] <Keybuk> can you think of a more appropriate colour?
[01:13] <Keybuk> we could nickname it the shit-screen
[01:13] <infinity> "Ubuntu pooped!"
[01:13] <imbrandon> lol
[01:14] <infinity> Not quite as cool as a guru meditation, but I suppose it would do.
[01:14] <Ng> nothing will ever beat a guru
[01:15] <Keybuk> we could have a picture of a very angry elmo
[01:15] <imbrandon> heh
[01:15] <infinity> "Tickle this!"?
[01:15] <Treenaks> Keybuk: http://www.netsplit.com/events/2005/ubuntu-down-under/ubuntu-down-under-027_screen.jpg ;)
[01:15] <pitti> mjg59: I'd appreciate your opinion on bug 29529 -- do you agree to raising the timeouts?
[01:15] <Ubugtu> Malone bug 29529 in laptop-mode-tools "Laptop HDD powerdown every 5 seconds" [Medium,Confirmed]  http://launchpad.net/bugs/29529
[01:16] <infinity> We could go back to our roots and make it a pr0n screen of death.
[01:16] <StevenK> elmo, showing the true sysadmin attitude.
[01:16] <infinity> Hey, that's my hand in that picture.  I'M FAMOUS.
[01:16] <mjg59> pitti: Uhm. The *entire point* of laptop mode is that the drive spins down quickly.
[01:17] <pitti> mjg59: but starting and stopping the drive every 5 seconds will kill it, apart from that it doesn't help to safe power
[01:17] <infinity> mjg59: 5 seconds seems excessively quick.  Won't it just eat power constantly spinning it back up?
[01:17] <mjg59> infinity: 5 seconds may be slight overkill, but not hugely
[01:17] <mjg59> If you set a longer timeout, it'll never spin down
[01:18] <mjg59> Certainly 15 minutes is entirely pointless
[01:18] <pitti> mjg59: the point is, if I constantly access my HD, it *shall* not spin down
[01:18] <infinity> I know the power draw of spinning up drives is non-trivial.  To the point where my old desktop required a two-pass power-on sequence (I'd hit the switch once to power on the drives, but the mobo and video would be dead, then quickly kill and re-power while the drives were still spinning to get the rest of the system up)
[01:18] <mjg59> pitti: 15 minute timeout = if you access the drive once during those 15 minutes, the drive will not spin down
[01:18] <smurf> mjg59: there's probably a sensible compromise somewhere between these two extremes ...
[01:18] <mjg59> pitti: Which will mean that you might as well set it to forever, because /something/ during that time is going to read of disk
[01:19] <StevenK> infinity: That sounds like your power supply is a little underpowered.
[01:19] <pitti> mjg59: I'm just concerned about killing my drive; you can only spin up and down a drive so many times
[01:19] <pitti> 5 minutes or so might be a good compromise
[01:19] <infinity> StevenK: It was, yes.  Was a 300W PSU and it had 8 10,000RPM drives in it.  I was too lazy to buy a new PSU.
[01:19] <pitti> mjg59: but I see absolutely no reason to spin down the drive when it's connected to AC
[01:19] <Ng> does the new power graphing stuff in edgy give sufficient resolution to compare leaving the drive spinning vs powering it up frequently?
[01:19] <Keybuk> pitti: why does your drive spin up?
[01:19] <Keybuk> that would be worth debugging?
[01:19] <mjg59> pitti: Right, there's no reason for it when it's on AC
[01:19] <StevenK> infinity: JESUS. No wonder. :_P
[01:19] <pitti> Keybuk: well, because I'm working with my computer? :)
[01:19] <mjg59> pitti: And if that's happening, that should be fixed
[01:20] <Keybuk> pitti: an ordinary emacs/gcc/run cycle shouldn't cause a spin up
[01:20] <pitti> mjg59: yeah, the default configuration seems to indend to use 2 hours, but it's 5 seconds nevertheless
[01:20] <Keybuk> it'd be worth checking whether you have some gnomeish thing of doom
[01:20] <pitti> Keybuk: no, it happens everytime I start something in the shell
[01:20] <mjg59> pitti: But, for reference, with these settings my 2.5 year old laptop is still well within limits (according to SMART)
[01:20] <Keybuk> pitti: what kinds of things do you start?
[01:20] <smurf> infinity: so put in the delay-spin-up jumpers. That's what they're there fore.
[01:20] <mjg59> pitti: So fix that, rather than anything else :)
[01:21] <pitti> Keybuk: unusual commands, like 'ls', 'vi', or 'ps'
[01:21] <Keybuk> pitti: none of those on usual files should cause a spin up
[01:21] <pitti> Keybuk: well, they do, I can't help it
[01:21] <Keybuk> the results of ls should be in the page cache from last time you did it
[01:21] <Keybuk> then debug why they do
[01:21] <Keybuk> look at vm/block_dump
[01:21] <infinity> smurf: Don't have the box anymore, but I'm pretty sure the drives didn't have hard jumpers for that.
[01:21] <pitti> I still think that 5 minutes would be a more sensible limit than 5 seconds
[01:22] <Keybuk> 5 minutes is far too long
[01:22] <pitti> if, as Keybuk says, machines with more memory do not access the disk so often, then 5 minutes would work for them, too
[01:22] <mjg59> pitti: And I think it's likely that that would be equivalent to 5 hours
[01:22] <Keybuk> that means that if, in a 5 minute window, you cause the disk to spin up, it won't spin down!
[01:22] <Keybuk> which effectively means it will never spin down
[01:22] <pitti> Keybuk: right
[01:22] <pitti> Keybuk: that's exactly what I want -- if I'm working with the computer, leave the disk running
[01:22] <Keybuk> when I'm on laptop mode, my disk only spins up every few minutes, and then only for five seconds
[01:22] <Keybuk> pitti: turn off laptop mode
[01:22] <pitti> hmm
[01:23] <pitti> Keybuk: well, I know how to do that, but not every user might
[01:23] <mjg59> We don't enable laptop mode by default in any case
[01:23] <Keybuk> the whole point of laptop mode is that it keeps your disk DOWN for as long as possible
[01:23] <Keybuk> not UP
[01:23] <pitti> mjg59: I never enabled it, so it must be by default
[01:23] <pitti> it's a fresh edgy beta install
[01:23] <mjg59> pitti: Is this on PPC?
[01:23] <pitti> Keybuk: yeah, but up/down/up/down/up/down every 5 seconds spoils that
[01:23] <pitti> mjg59: yes
[01:23] <Keybuk> pitti: then debug why that happens
[01:23] <mjg59> pitti: Ok. Fix PPC :)
[01:23] <tfheen> Keybuk: re making the scheduler explode -- are topics up already?
[01:24] <Keybuk> tfheen: I've been proposing things, yeah
[01:24] <mjg59> pitti: I don't have any mobile PPC hardware, so I've no idea why that's happening. It's not the case on x86.
[01:24] <Keybuk> and I'm using my "very small spec" method again
[01:24] <pitti> Keybuk: dude, because I'm executing something in /bin :) and 256 MB memory isn't enough to keep the world in the cache
[01:24] <Keybuk> pitti: then turn off laptop mode
[01:24] <pitti> mjg59: ok, good to know; I'll look into that then
[01:25] <mjg59> pitti: I've no intention in changing the laptop-mode settings. On x86, things work (and the drive gets set back to sensible timeouts on AC)
[01:26] <pitti> mjg59: NB that the bug reporter is on x86
[01:26] <pitti> so it doesn't seem to work on all hw either
[01:26] <Keybuk> the correct thing to do when laptop-mode is spinning up the drive all the time is debug why it's spinning up at all
[01:26] <Keybuk> not to break it
[01:26] <mjg59> pitti: The bug is ancient and ought to have been closed
[01:26] <giftnudel> Keybuk: it's the apps
[01:27] <giftnudel> Keybuk: like epiphany spins up the disk on loading an image and closing a tab, so browsing with epiphany + laptop-mode = pointless
[01:27] <Keybuk> giftnudel: why does epiphany load the image off the disk?
[01:27] <pitti> as I said, it happens with simple shell commands, too
[01:27] <giftnudel> laptop-mode is working just fine
[01:27] <Keybuk> why is the image not in the page cache?
[01:27] <Keybuk> pitti: ls should be in your page cache
[01:28] <giftnudel> Keybuk: if it adds it to the disk cache i suppose
[01:28] <pitti> Keybuk: maybe ls itself, but not the directory it's displaying?
[01:28] <Keybuk> pitti: you really ls random directories all over your disk while on battery power?
[01:28] <ogra> sooo, sleep doesnt help either with my usb/usplash race ... seems the only thing that really prevents the breakage is the chvt 7
[01:28] <mjg59> I think my useful contribution to this discussion is done
[01:28] <Keybuk> pitti: challenging yourself to find a directory you've never looked at before?
[01:28] <pitti> Keybuk: *sigh* I discovered that bug for the reason that I worked normally with my box, not to annoy people
[01:29] <giftnudel> I suppose you have to fix all apps that constantly access the hardrive
[01:29] <Keybuk> pitti: right, but your proposed solution is wrong
[01:29] <Keybuk> increasing the laptop mode timeout beyond a matter of seconds would make it effectively useless
[01:29] <pitti> Keybuk: well, we have a different opinion about the effectiveness of fast spindowns
[01:29] <pitti> that doesn't make mine wrong per se
[01:29] <Keybuk> if, as you say, you cause your disk to spin up EVERY FIVE SECONDS
[01:30] <Keybuk> then increasing the timeout would just make it never spin down, no?
[01:30] <pitti> correct
[01:30] <Keybuk> so why not just turn off laptop mode?
[01:30] <Keybuk> if you never want your disk to spin down, you want laptop mode disabled
[01:30] <pitti> Keybuk: because I'm a dumb user and do not know how to turn it off
[01:30] <Keybuk> it's not turned ON by default
[01:30] <pitti> Keybuk: I never turned it on
[01:30] <Keybuk> at some point you have enabled it
[01:30] <pitti> until yesterday I wasn't even aware of it
[01:30] <giftnudel> well, the point is not to never spin the disk down but not up-down-up-down ...
[01:31] <Keybuk> pitti: grep LAPTOP_MODE /etc/default/acpi-support
[01:31] <pitti> Keybuk: powerpc, no acpi
[01:31] <shawarma> giftnudel: No. up-down-up-down is fine at the right intervals.
[01:31] <Keybuk> pitti: that's probably the bug
[01:31] <giftnudel> shawarma: yes, but not 4 times in 40 seconds
[01:31] <Keybuk> giftnudel: if the disk needs to come up every 5s, there's no way to prevent that
[01:32] <Keybuk> mjg59: is laptop mode enabled by default on powerpc?
[01:32] <pitti> Keybuk: you really want to tell me that it's the right thing to spin down the disk if I need it every 5 seconds?
[01:32] <Keybuk> pitti: no, if you need it every 5 seconds you don't want it ever spun down at all
[01:32] <pitti> (that has nothing to do with fixing apps to not do that, of coruse)
[01:32] <Keybuk> however it's the right thing to spin down the disk after 5s if you don't need it
[01:32] <shawarma> giftnudel: actually, I'm quite sure the original benchmarking done when designing laptopmode showed that 10 seconds was a very reasonable setting.
[01:32] <pitti> Keybuk: right, and that's what I keep saying all the time
[01:33] <giftnudel> shawarma: i'm just scared that it kills my hd
[01:33] <giftnudel> maybe add something like a back-off algorithm
[01:33] <giftnudel> wait more if spun up often
[01:34] <Keybuk> pitti: to me, the bug is that laptop mode gets enabled on powerpc because there's no acpi-support conffile, so there's no ENABLE_LAPTOP_MODE=false
[01:34] <shawarma> The article in LinuxJournal about it (with some benchmarks): http://www.linuxjournal.com/article/7539
[01:34] <giftnudel> shawarma: thanks
[01:34] <pitti> Keybuk: ah, that sheds some light now, thanks
[01:34] <shawarma> pitti: What does /proc/sys/vm/laptop_mode say?
[01:34] <mjg59> Keybuk: Conceivably, which (as I mentioned) is a bug
[01:35] <pitti> shawarma: '2'
[01:35] <smurf> Keybuk: care to take a quick look at bug 64327 ?
[01:35] <Ubugtu> Malone bug 64327 in upstart "No console stdout when booting the LiveCD with "single"" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64327
[01:35] <Keybuk> pitti: as for the timeout, try increasing it a second at time
[01:35] <pitti> mjg59: laptop-mode-tools reads /etc/default/acpi-support, or another file, too?
[01:35] <Keybuk> you may find that 7s is the right point for you
[01:35] <AlinuxOS> doko_, ping.
[01:35] <mjg59> pitti: Possibly just acpi-support
[01:36] <Keybuk> smurf: it's not a bug?  that's deliberate
[01:36] <doko_> AlinuxOS: pong
[01:37] <Seveas> mjg59, your 'don't use palettes' usplash_svga patch broke usplash_put_part, usplash_clear and usplash_text. I get blueness in the kubuntu theme with revision 82, not with revision 81 (bug 64171). I tried to debug it, but am at a loss :/
[01:37] <Ubugtu> Malone bug 64171 in usplash "Colors look bad " [Undecided,Unconfirmed]  http://launchpad.net/bugs/64171
[01:37] <smurf> Keybuk: why the hell should single-user mode not write startup messages to the console?
[01:37] <pitti> mjg59: hmm, the best equivalent I can think of is pbbuttonsd -- its postinst could generate an /etc/default/acpi-support with 'ENABLE_LAPTOP_MODE=false' if it's not yet present
[01:37] <infinity> smurf: Nothing writes console messages anymore, unless you boot without "quiet" on the command line.
[01:38] <AlinuxOS> doko_, hello, I don't know really what happened but since last update of georgian (ka) locale there is no icons on OpenOffice.org Writer's interface and others..
[01:38] <AlinuxOS> something is wrong I think :/
[01:39] <smurf> infinity: I *do* boot without "quiet" on the command line
[01:39] <Seveas> err, I mean blueness in the ubuntu theme (kubuntu is *supposed* to be blue ;))
[01:39] <infinity> smurf: Right.  Hence, no messages.
[01:39] <smurf> "debug", even. Heaps of nice kernel messages, but none from userspace.
[01:40] <infinity> smurf: Err, wait.  I read that was "with", not "without".
[01:40] <smurf> infinity: 'xactly.
[01:40] <infinity> smurf: upstart is *meant* to give output without quiet...
[01:40] <doko_> AlinuxOS: which desktop? did you do a complete dist-upgrade? did you change the icon-styles yourself in the OOo options?
[01:40] <smurf> infinity: ... which is why I filed that bug ...
[01:41] <AlinuxOS> no doko_ , no changes ... just a user communicated it for me in this moment..
[01:41] <AlinuxOS> I've started my OO.org writer and there is no icons
[01:41] <infinity> smurf: Well, assuming upstart-logd is installed, anyway.
 AlinuxOS: which desktop? did you do a complete dist-upgrade?
[01:42] <pitti> mjg59: alternatively to the pbbuttonsd hack, can I change /etc/init.d/laptop-mode to not enable laptop mode if /etc/default/acpi-support is not present at all?
[01:43] <AlinuxOS> Edgy Eft, Calculating upgrade... Done
[01:43] <AlinuxOS> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[01:43] <AlinuxOS> doko_, no new dist-upgrade packages.
[01:44] <doko_> doko_> <doko_> AlinuxOS: which desktop?
[01:44] <AlinuxOS> http://taya.convert.ge/screenshot35.png
[01:44] <AlinuxOS> http://taya.convert.ge/screenshot36.png
[01:44] <mjg59> pitti: Uh. That would just never make it work on ppc.
[01:44] <smurf> OK, changed the bug to say "debug single" instead of "single". That doesn't make the bug go away unfortunately. ;-)
[01:44] <doko_> AlinuxOS: ok, KDE
[01:44] <mjg59> pitti: It should have a config file on PPC too
[01:44] <AlinuxOS> User: Kubuntu Edgy Eft.
[01:44] <pitti> mjg59: well, I guess this setting really belongs to /etc/default/laptop-mode
[01:45] <AlinuxOS> Me: Ubuntu Edgy eft = GNOME
[01:45] <mjg59> pitti: Not really on x86, since it's handled by the acpi scripts
[01:45] <AlinuxOS> the same result.
[01:45] <AlinuxOS> doko_,
[01:45] <pitti> hmm
[01:46] <doko_> AlinuxOS: dpkg -l openoffice.org-style*
[01:46] <pitti> mjg59: hm, since acpi-support doesn't exist on ppc, I'm also fine with creating the default file in pbbuttonsd's postinst; it's a nasty hack, but unintrusive
[01:47] <mjg59> pitti: Hm. What does policy have to say about this? :)
[01:47] <pitti> mjg59: it wouldn't like it
[01:47] <mjg59> Yeah.
[01:47] <mjg59> Adding a laptop-mode config file on PPC and checking that sounds like the Right thing to do
[01:48] <mjg59> It's fine to source from both of them (in the case of them existing)
[01:48] <pitti> but if l-m uses a configuration file from a non-depended package, it's already an unclean situation, so how much worse can it get :)
[01:48] <pitti> mjg59: ok, WFM, too
[01:50] <AlinuxOS> doko_, http://paste.ubuntu-nl.org/25802/
[01:50] <pitti> mjg59: /usr/sbin/laptop_mode reads ENABLE_LAPTOP_MODE from /etc/default/laptop-mode
[01:51] <pitti> mjg59: this file doesn't seem to exist by default, so maybe I can just use this on ppc?
[01:51] <mjg59> Sure
[01:51] <doko_> AlinuxOS: is openoffice.org-kde installed in the KDE installation?
[01:52] <AlinuxOS> doko_, that's users: http://paste.ubuntu-nl.org/25803/
[01:52] <AlinuxOS> doko_, ok I'll ask her.
[01:54] <pitti> mjg59: oh, ugh, l-m-tools is arch:all, so I'll create it in the postinst
[01:54] <AlinuxOS> doko_, no it's not installed on her pc.
[01:55] <AlinuxOS> on my computer there is no openoffice.org-gnome.
[01:55] <doko_> AlinuxOS: you should install these ... (dependency of ubuntu-desktop / kubuntu-desktop)
[01:56] <AlinuxOS> doko_, testing...
[01:57] <tfheen> mjg59: oh, do you happen to know why the usplash text is dark blue on black?
[01:57] <AlinuxOS> doko_, do you still accept gsi files (updates I mean) ?
[01:58] <doko_> AlinuxOS: probably
[01:58] <AlinuxOS> is there a dead line or something ?
[01:58] <doko_> iwj: ping
[01:59] <AlinuxOS> every month or , once in 2months there is some corrections and updates in UI.
[01:59] <Keybuk> smurf: why should it?
[01:59] <Keybuk> if you use the "(recovery mode)" option, it will write messages
[01:59] <mjg59> tfheen: Because usplash_put_part is broken
[02:00] <mjg59> tfheen: Which I don't entirely understand, given that I'm pretty sure I just cut and paste the same code from usplash_put and it works fine there
[02:00] <tfheen> hmm, and reconfiguring gnome-power-manager makes usplash unhappy.
[02:00] <AlinuxOS> doko_, (you are doing super!) it's great to see improvements. As Georgian Ministry of Instruction is going to use Kubuntu in schools.
[02:01] <mjg59> Ok, I'm bored of this now.
[02:01] <mjg59> Can we please have some mechanism to prevent people filing bugs against "acpi" unless they really mean to?
[02:02] <Keybuk> mjg59: I liked the guy who filed bugs against usplash because his sound card and network card wasn't working
[02:02] <zul> like electro-shock treatment
[02:02] <Fujitsu> mjg59, /everything/ is either the fault of acpi or upstart. There's no other possibility.
[02:02] <Fujitsu> zul, those LP guys are really taking their time implementing that feature.
[02:02] <mjg59> Fujitsu: Given that acpi is a command line tool that parses /proc/acpi and prints useless information, the things I blame it for are limited
[02:02] <zul> heh...maybe someone should spec it out
[02:03] <Keybuk> Fujitsu: or "boot", a package of bootstrapping functions for GNU R
[02:03] <Fujitsu> Keybuk, that's impressive.
[02:03] <kristog> it's possibile to use cdeboostrap for bootstrap edgy?
[02:03] <Fujitsu> mjg59, so of course everything is caused by it.
[02:03] <Kamion> kristog: no, it's not supported as far as I know
[02:03] <tucoz> i found a bug and a solution to a problem when running dpkg-reconfigure xserver-xorg. who should i talk to?
[02:03] <Kamion> kristog: but there's no point anyway
[02:04] <mjg59> tucoz: launchpad.net
[02:04] <tucoz> :)
[02:04] <Kamion> kristog: everything cdebootstrap was useful for (automatic dependency resolution, basically) debootstrap now does
[02:04] <mjg59> tucoz: In general (this isn't true in all cases) putting it in Launchpad will ensure that the right people see it. Picking one individual person won't necessarily
[02:05] <shawarma> pitti: /win 2
[02:05] <shawarma> doh...
[02:05] <tucoz> mjg59, ok. thanks.
[02:07] <iwj> doko_: Hi.
[02:08] <iwj> Err, amd64.  I assume it must be something with your setup.  I haven't built ff on the colo amd64's recently and I don't have one here, but it built in LP so I propose to just apply the patch and build it on i386 and expect the LP buildd to DTRT.
[02:08] <doko_> iwj: about firefox/xulrunner ... the problem with eclipse: it only works with xulrunner now, problems with the NS_InitEmbedding stuff in firefox.
[02:09] <iwj> Err, is this a new thing ?  I don't know anything about it ...
[02:10] <doko_> no, not new, just needed by eclipse
[02:11] <iwj> doko: Do you have a bug reference or something with some details ?
[02:12] <Kamion> ok, with any luck that's the tasksel/usplash mess fixed
[02:12] <Kamion> that only needed fixes in four separate places
[02:13] <Fujitsu> And was an upstart bug. Or was it acpi? Or both?
[02:14] <doko_> iwj: http://dev.eclipse.org/mhonarc/lists/linux-distros-dev/msg00082.html
[02:17] <kristog> Kamion: we should file a bug to include edgy in the debian debootstrap package.
[02:17] <Kamion> kristog: I believe there already is one
[02:18] <Kamion> kristog: but it should *NOT* be included until edgy is final
[02:18] <Kamion> because the edgy debootstrap script does change occasionally throughout development
[02:18] <Kamion> ah, there's one for Ubuntu dapper
[02:19] <kristog> Kamion: yes
[02:20] <tfheen> the dapper one works fine as long as you pass --resolve-deps, iirc
[02:33] <doko_> Kamion, Keybuk: please sync ecj-bootstrap before the weekend (#64073), I would like to use it for the next OOo build over the weekend
[02:38] <Keybuk> smurf: removing quiet and adding single works for me -- have attached screenshots to the bug
[02:46] <Keybuk> smurf: also, from reading the kernel source, quiet trumps debug
[02:49] <smurf> Keybuk: looks like you didn't do that on the LiveCD
[02:49] <Keybuk> smurf: that looks like a LiveCD syslinux prompt to me
[02:52] <tfheen> that'd be special.  The desktop cd uses isolinux, not syslinx.
[02:52] <tfheen> not syslinux even
[02:52] <Keybuk> ok, isolinux then
[02:52] <Keybuk> :)
[02:56] <Kamion> doko_: please describe the Ubuntu changes you want to overwrite in the bug
[02:56] <Kamion> doko_: we won't process sync requests without that, I'm afraid
[02:58] <smurf> Keybuk: Hmm. You seem to be right, seems to have been a mix-up on my part.
[02:58] <smurf> Keybuk: Anyway, the last kernel message I see on my PPC is the one from squashfs, then there's a lot of CD acctivity but nothing more to be seen. :-/
[02:58] <Keybuk> smurf: if you left "splash" in, the output would have been on tty7 under usplash
[02:58] <Keybuk> smurf: that's because the PPC boot loader doesn't let you remove kernel options
[02:59] <doko_> Kamion: is this sufficient?
[03:01] <Keybuk> https://features.launchpad.net/distros/ubuntu/+spec/webcam-gestures
[03:01] <Keybuk> *giggle*
[03:03] <funman> helo
[03:03] <Kamion> doko_: yes, thanks, although in future we prefer a description rather than just a changelog paste; in practice too many people seem to automate the changelog paste and we've found that not everyone actually checks ...
[03:04] <pitti> seb128: did you ever get an useful apport report with SIGABRT?
[03:04] <seb128> pitti: no
[03:04] <pitti> seb128: they usually come from exception hanndlers or assertion failures
[03:04] <pitti> seb128: and usually the backtrace is useless for them
[03:04] <seb128> right, that's my opinion too
[03:04] <pitti> seb128: I'm pondering to just ignore SIGABRT for now
[03:05] <pitti> seb128: I have a bug open about grabbing the text of the message (similar to grabbing mono's stack trace output) but that's nothing for edgy
[03:05] <pitti> when we have that ^, we should catch abort again
[03:05] <seb128> ignoring SIGABRT looks fine to me
[03:05] <seb128> right
[03:06] <seb128> having the assertion message is useful
[03:13] <fabbione> Kamion: when you have time bug #59228
[03:13] <Ubugtu> Malone bug 59228 in cpio "cpio build glitch breaks Unicode char handling" [Unknown,Fix released]  http://launchpad.net/bugs/59228
[03:13] <fabbione> Kamion: we are close to the end of the tunnel :)
[03:19] <sabdfl> mjg59: ping
[03:19] <desrt> seb128; it's difficult to get a good read from inside a signal handler
[03:20] <seb128> desrt: why?
[03:20] <desrt> seb128; in the case of a segfault a good strategy might be to fire up the debugger in 'continue' mode and then have the signal handler return
[03:20] <desrt> that'll re-trigger the crash
[03:20] <desrt> and the debugger will get a better read
[03:20] <seb128> ah
[03:20] <desrt> seb128; if you think about how signal handlers are called, it's pretty random
[03:21] <seb128> but you should get a function calls history still though, no?
[03:21] <desrt> seb128; they happen at any point in the code... so in some cases your stackframe is gonna be in a messed up state
[03:21] <mjg59> sabdfl: Hi
[03:22] <desrt> seb128; also, signal handlers don't return to the normal place in the code... they return to a special kernel trampoline (to restore the values of registers, etc)
[03:23] <desrt> it's amazing backtracing works at all when a signal handler is running, imo :)
[03:23] <desrt> (obviously has some special help for it built-in to the debugger)
[03:24] <seb128> hum
[03:24] <seb128> I see
[03:24] <seb128> doesn't look trivial to change though :/
[03:25] <desrt> nice
[03:25] <desrt> abort gets rethrown if the signal handler returns
[03:26] <desrt> seb128; correct solution, i think, is to modify the part of bug-buddy (or whatever) that lives in process
[03:26] <desrt> seb128; currently it attaches gdb to the process and issues 'bt' straight away
[03:27] <desrt> seb128; it should actually attach gdb, issue 'c' then the process should return to where it was executing in which case the abort or the segv will be thrown again and the debugger will catch it and get a much cleaner trace
[03:27] <seb128> desrt:
[03:27] <seb128> $ cat /usr/share/bug-buddy/gdb-cmd
[03:27] <seb128> bt
[03:27] <seb128> thread apply all bt full
[03:27] <seb128> q
[03:27] <desrt> yup.  first there should be a 'c' :)
[03:27] <desrt> (with appropriate support in-process)
[03:28] <desrt> i think the parent currently ends up in waitpid() or something
[03:28] <desrt> (having seen a billion bugbuddy stacktraces you think i'd know this more certainly)
[03:28] <seb128> I don't really get why abort or segv will be thrown again
[03:28] <desrt> abort contains code specifically so that it will be thrown again if the handler returns
[03:29] <seb128> ah
[03:29] <desrt> including explicitly unsetting the handler, it seems
[03:29] <desrt> segv will happen again unless your handler manages to deal with the problem that caused the crash
[03:29] <desrt> like.. the null pointer will still be null (or whatever)
[03:29] <desrt> so it'll try again and crash again
[03:31] <desrt> seb128; presumably a synchronous version of g_spawn or something is used to launch the bugbuddy... a good first crack would be to try changing that to async, then add a sleep(10); or something to wait for the debugger to start and attach to the process
[03:31] <desrt> then just return from the signal handler
[03:31] <desrt> and add a "c" to the gdb commands file
[03:32] <desrt> if you're sufficiently lucky then that may work :)
[03:32] <desrt> (and makes a good start at a patch that you might want to get upstreamed)
[03:32] <seb128> that looks like a crackish idea
[03:33] <seb128> might work though ;)
[03:33] <desrt> the idea of calling a debugger on yourself from a signal handler is crackish
[03:33] <desrt> this is equivalently crackish, yes :)
[03:33] <seb128> how else would you get a backtrace?
[03:34] <desrt> "remember what you did to cause the crash and do it again while running under the debugger" used to be a popular favourite
[03:34] <seb128> it works better
[03:34] <seb128> I used to ask people to copy the bt from bug-buddy
[03:35] <seb128> for some months I ask them to run it under gdb though
[03:35] <seb128> I had some cases or bug-buddy was giving nothing useful and where gdb works fine
[03:36] <seb128> seems to be a real issue for evolution triagers though
[03:36] <seb128> most of their bt are empty
[03:37] <desrt> well, hopefully i am right :)
[03:37] <seb128> desrt: do you think you could have a try to a proof of concept? ;)
[03:37] <desrt> i don't know for sure... but empirical knowledge and intuition says that it must be true
[03:37] <seb128> I'll otherwise, but probably not before edgy
[03:37] <desrt> ok.  if i know you're not working on it i'll try something this weekend at the cottage
[03:38] <desrt> are there any weird libbugbuddy package or something or is it all one thing?
[03:38] <desrt> libgnome, maybe?
[03:40] <seb128> desrt: libgnomeui set the crash handler
[03:40] <desrt> awesome.  thanks.
[03:40] <seb128> desrt: bug-buddy is called and run gdb
[03:41] <seb128> np, thank you for having a look at it :)
[03:41] <desrt> i probably don't even need bugbuddy source
[03:41] <desrt> but can't hurt :)
[03:41] <seb128> the edgy package has a patch to libgnomeui to not set the crash handler if /apps/bug-buddy/run_on_crash is set
[03:42] <seb128> that's a "let apport doing its job" patch :)
[03:42] <seb128> but apport doesn't do better job at getting the bt
[03:42] <desrt> is apport this spiffy new bugbuddy-type thing?
[03:43] <desrt> er.  one case that my idea will deal poorly with is if you manually send a sigsegv/sigabrt to an app
[03:43] <desrt> because then the bugbuddy will start up but when the signal handler returns it won't be rethrown
[03:44] <desrt> that's a pretty border case, though
[03:44] <seb128> desrt: right, apport is the distro wide bug-buddy pitti worked on for edgy
[03:44] <desrt> k
[03:44] <desrt> maybe i'll grab source for that, too :)
[03:45] <desrt> is it python?
[03:45] <desrt> er.  does it run some sort of a system daemon?
[03:45] <seb128> the dump is made by the kernel itself
[03:45] <desrt> oh!  of course!
[03:45] <desrt> that's what people used to do
[03:46] <desrt> they used to have corefiles
[03:46] <desrt> and run the debugger on that
[03:46] <seb128> that's what apport do
[03:46] <seb128> doesn' work better than bug-buddy though
[03:46] <desrt> that's useful information
[03:46] <desrt> i wonder if libgnomeui's abrt/segv handler still runs?
[03:47] <seb128> bug-buddy runs first
[03:47] <desrt> ok.  so that's why.
[03:47] <seb128> if you don't unset /apps/bug-buddy/run_on_crash
[03:47] <desrt> i bet if you cut bugbuddy out of the picture entirely then apport would work a lot better
[03:48] <seb128> no
[03:48] <tfheen> Riddell: did you have a chance to test the kubuntu accessibility stuff?
[03:48] <desrt> apport gets run by the bugbuddy code?
[03:48] <seb128> desrt: my libgnomeui patch doesn't set the signal handler if the gconf-key is not set
[03:48] <seb128> no, I've patched libgnomeui
[03:48] <seb128> by default it's running
[03:48] <desrt> ok
[03:48] <desrt> i'm confused
[03:48] <Riddell> tfheen: no, not yet I'm afraid
[03:48] <desrt> how does apport find out about crashed processes?
[03:49] <seb128> if you unset /apps/bug-buddy/run_on_crash then the signal handler is not set
[03:49] <seb128> and apport get the crash
[03:49] <desrt> right... but how does it know that a crash has happened?
[03:49] <seb128> pitti: around? ;)
[03:49] <desrt> i'll figure it out :)
[03:50] <desrt> anyway.  i'm away for the long weekend
[03:50] <desrt> cheers
[03:50] <seb128> desrt: apport has a kernel side for the crash detection and the dump apparently, I've not looked into details
[03:50] <seb128> desrt: have fun!
[04:09] <bddebian> Howdy
[04:16] <AlinuxOS> mjg59, hello, You have alredy fixed Georgian (ka) fontconfig issue and it's good. But, but in Edgy or Dapper repos there still remains an old (0.2 version) ttf-bpg-georgian-fonts package. Please see tha last comment here: https://launchpad.net/distros/ubuntu/+source/ttf-bpg-georgian-fonts/+bug/55966 Thank You a lot.
[04:16] <Ubugtu> Malone bug 55966 in ttf-bpg-georgian-fonts "ttf-bpg-georgian-fonts.conf problem." [Undecided,Confirmed]
[04:16] <AlinuxOS> "ttf-bpg-georgian-fonts.conf problem." there is no fontconfig problem anyway.
[04:27] <jdong> who is in charge of gnome-power-manager?
[04:27] <Treenaks> in charge! good pun! :P
[04:27] <jdong> I didn't mean it :)
[04:28] <jdong> I've found the fix for the logout dialog not coming up
[04:28] <Seveas> jdong, ooh!
[04:29] <Seveas> nice one
[04:29] <jdong> Seveas: yeah, ooh is right :)
[04:29] <jdong> patch # 56 , hunk #1
[04:29] <Seveas> I was puzzled by not getting that dialog when pressing the power button
[04:29] <jdong> yeah, apparently whoever wrote patch 56 went overboard on removing gnome_client_request_save() calls :D
[04:30] <jdong> so that the code branch for interactive logout was basically nil :)
[04:30] <jdong> I commented in the bug report already, but it doesn't look like there's anyone in there that's paying attention from the packaging standpoint
[04:31] <jdong> which is why I asked who's in charge of the package
[04:31] <jdong> (looking at the package and its outstanding bugs, it doesn't look terribly maintained either....)
[04:42] <highvoltage> where can I get more information on Ubuntu landscape?
[04:42] <jdong> huh?
[04:43] <highvoltage> apt-cache show landscape-client
[04:43] <highvoltage> it sounds like a web-minny thing for ubuntu
[04:44] <jdong> does sound very cool
[04:44] <jdong> have you tried searching landscape on the wiki?
[04:44] <highvoltage> I googled, but it wasn't very useful (wiki'ing now)
[04:45] <highvoltage> nope, not there either
[04:45] <Kamion> it's not a public project yet
[04:45] <Kamion> only its name by virtue of the package name :-)
[04:45] <highvoltage> ok :)
[04:45] <highvoltage> will it be free software?
[04:45] <Kamion> I don't honestly know
[04:46] <Kamion> I've not paid a lot of attention to it
[04:46] <highvoltage> ok, np. I'll hold on and see what happens :)
[04:46] <jdong> Kamion: have you had a chance to consider my ntfsprogs proposal yet?
[04:59] <Kamion> fabbione: gotcha
[04:59] <Kamion> jdong: not yet - will look now
[04:59] <Kamion> I've had Andreas Lloyd here for most of the day
[05:00] <fabbione> Kamion: thanks dude
[05:03] <keescook> morning!
[05:08] <Keybuk> Kamion: and how is Mr Andreas?
[05:09] <jdong> Keybuk: you're on TB, right?
[05:10] <Keybuk> yes
[05:10] <jdong> I've been recently considering becoming MOTU more and more... I've found myself poking MOTU's too much to do backports-related work
[05:10] <jdong> I was wondering as a TB member, what would it take to convince you that I am MOTU material :)
[05:11] <Keybuk> I didn't realise you weren't already
[05:11] <Kamion> Keybuk: seems fine. my throat hurts from talking all day now, though :)
[05:11] <Keybuk> Kamion: I believe I'm to have him on Monday
[05:11] <rubikcube> hi, where does ubuntu (dapper) load the PATH from? /etc/environment ?
[05:11] <jdong> Keybuk: on the original backports meeting, ogra kept on pushing for me to be MOTU, but it was agreed that backports/MOTU were orthogonal, and that was the end of that
[05:11] <fabbione> Kamion: thanks for approving..
[05:12] <Keybuk> jdong: I can only speak for myself, but I can't think of any immediate concerns; you've had sufficient exposure to our procedures, and even to packaging, to be considered
[05:12] <Keybuk> jdong: obviously you'll need to answer the usual questions about what you want to do in universe, etc.
[05:12] <jdong> ok
[05:13] <jdong> perhaps I'll put myself on the next TB then....
[05:13] <jdong> Keybuk: who are the other TB's again?
[05:13] <Keybuk> next TB is tuesday
[05:13] <Keybuk> mdz, mjg59 and sabdfl (though I think he's forgotten <g>)
[05:13] <jdong> ok
[05:14] <jdong> I think from the group, you'd be the one most familiar with me...
[05:14] <Keybuk> indeed
[05:15] <jdong> the thing is, I've not really done all that much of MOTU work... I have contributed a few patches against acidrip/ktorrent recently, as well as researching an x264 UVFe
[05:15] <jdong> so there's not all that many MOTU's who can vouch for my abilities...
[05:15] <Keybuk> it's what you plan to do, and your ability to do it, that will count
[05:16] <jdong> virtually the only thing that I need to do in Universe is loosen tightened build-deps when they're not needed in universe but needed in backports
[05:16] <jdong> I've mostly been poking MOTU's for that, but they're getting annoyed and often ignoring me :D
[05:16] <crimsun> s/ignoring/resource-constrained/g
[05:18] <jdong> crimsun: I am using ignoring affectionately :)
[05:18] <jdong> I know how busy you guys all are, and you have your own agendas, etc
[05:18] <jdong> which is why I'd like to be a bit more independent and less of a maintenance burden for others
[05:20] <highvoltage> jdong: I don't know you but it sounds like you are too hard on yourself
[05:21] <jdong> highvoltage: sometimes I am very demanding on myself, and I never like to say anything that might overestimate my abilities....
[05:21] <jdong> that's one of my flaws...
[05:28] <jdong> Kamion: thanks for your response on the ntfs thing
[05:28] <Kamion> only four months later
[05:29] <jdong> Kamion: I know that we have a lot of customized code on the package, but are there future plans (edgy is certainly not a target) for a newer gparted?
[05:29] <Kamion> jdong: I hope that in edgy+1 I'll be able to stop using it in the installer
[05:29] <Kamion> so people who care can do what they like ;)
[05:30] <jdong> Kamion: ntfsresize's FAQ asserts that Ubuntu's version has some known partition table corrupting bugs in certain instances....
[05:30] <Kamion> jdong: does it say Ubuntu dapper or edgy or anything more specific?
[05:30] <jdong> which sounds slightly concerning, though I've yet to follow up
[05:30] <Kamion> because edgy's version is a good deal newer than dapper's
[05:30] <Kamion> we're still a bit behind upstream, but I didn't know there was anything all that drastic
[05:30] <jdong> Kamion: I believe it deals with dapper's
[05:31] <jdong> Kamion: they seem to preach by that new version of gparted being featured on the gparted livecd
[05:31] <Kamion> are they purely going by version numbers?
[05:31] <Kamion> because I backported an NTFS fix to gparted before dapper release
[05:31] <jdong> they might be
[05:31] <jdong> as I said, I didn't really follow up on it
[05:31] <Kamion> fair enough
[05:32] <Kamion> if you do find out that there's a problem, I'd certainly be willing to propose a stable update
[05:32] <jdong> mmkay
[05:32] <jdong> is there a set date of when a 6.06.2 release would be made?
[05:33] <Kamion> not at the moment
[05:33] <Kamion> it's not even certain that there will be one, although neither is it certain that there won't
[05:33] <jdong> ok
[05:33] <jono> hi guys
[05:33] <highvoltage> hi jono
[05:34] <jono> do we know if the ubuntu book excepts are staying in Edgy?
[05:34] <sladen> afternoon jono, how's the jet lag?
[05:34] <jdong> aren't there some ubiquity bugs on 6.06.1 though?
[05:34] <jono> hey highvoltage pitti
[05:34] <jono> sladen, fly back today :)
[05:34] <Kamion> jono: they've already been changed to links to a website
[05:34] <Kamion> jdong: well, yes, but there are ubiquity bugs in edgy too ...
[05:34] <Kamion> 6.06.1 is a LOT better than 6.06, but I agree more could be done
[05:34] <jdong> :)
[05:35] <jdong> I've generally had great luck with 6.06.1
[05:35] <jono> Kamion, ok cool, I will let the publisher know
[05:35] <Kamion> I'm not aware of any regressions in 6.06.1 though
[05:35] <jono> Kamion, is this the final decision?
[05:35] <Kamion> which would be the really scary thing
[05:35] <Kamion> jono: I think so - we took it for CD space reasons, and it was discussed on ubuntu-devel and cleared with Matt and Mark
[05:36] <Kamion> jono: if there are good arguments to the contrary, we'd listen, though - it's not necessarily a closed subject
[05:36] <jdong> Kamion: btw, do _you_ know who's supposed to handle gnome-power-manager?
[05:36] <jono> Kamion, ok cool, fine with me :)
[05:36] <mjg59> jdong: Nobody
[05:36] <sladen> jdong: various people, what's your issue
[05:36] <jono> Kamion, just need to know what was decided to let Prentice Hall know
[05:36] <jono> thanks :)
[05:36] <jdong> sladen: I've found the culprit to the logout dialog regression....
[05:36] <jdong> bug 57582?
[05:36] <Ubugtu> Malone bug 57582 in Tilix "It`s not possible to dist-upgrade" [Critical,Confirmed]  http://launchpad.net/bugs/57582
[05:36] <jdong> no
[05:36] <jdong> bug 57872
[05:36] <sladen> jdong: fantastic, bug #57582
[05:36] <Ubugtu> Malone bug 57872 in gnome-power "regression: pressing power button no longer brings up logout dialog" [Unknown,Unconfirmed]  http://launchpad.net/bugs/57872
[05:37] <jdong> it's that first hunk in debian/patches/56-disable-session-save-on-shutdown.patch
[05:37] <jdong> sladen: I think that  gnome_client_request_save() request was mistaken for something that would save the session
[05:37] <jdong> while from what I understand/researched it merely brings up a login dialog
[05:37] <jdong> logout*
[05:38] <jdong> the second hunk is what saves the session without telling the user
[05:38] <jdong> was just wondering if you guys can double-check my findings and fix that annoying bug :D
[05:40] <sladen> jdong: what we want is session-closing, but no reference to session saving (they probably wanted hibernate instead)
[05:41] <jdong> sladen: right. patch 56's first hunk is definitely incorrect. it takes out the only action in that else if branch
[05:42] <jdong> sladen: from all the researching I've done, that gnome_client call is the way to bring up the logoff dialog
[05:42] <sladen> jdong: righto
[05:43] <jdong> sladen: the second hunk, I am not so sure on. That call might actually save the session :D
[05:43] <Kamion> hah, 20+ ubiquity bugs fixed
[05:43] <Kamion> I think that's a perfectly good excuse to go out for a bit
[05:43] <jdong> sladen: in which case, we want to preserve that 2nd hunk
[05:43] <jdong> Kamion: how many more to go? ;-)
[05:44] <jdong> (jk, take a well deserved break)
[05:44] <Kamion> oh, only about 400. but that's one of the two major remaining classes of undiagnosed bugs, so I feel a lot better
[05:45] <Keybuk> I do wish ubuntu wouldn't display the 3D screensavers in vmware ;)
[05:45] <jdong> Keybuk: yeah, I was gonna come and yell at the vmware image creators for not thinking that one through!
[05:46] <jdong> Keybuk: oh yeah, wishlist, edgy eft vmware images should include the vmmouse package
[05:46] <jdong> and its xorg.conf should use it
[05:47] <Keybuk> there are "vmware images" ?
[05:47] <jdong> Keybuk: yeah, on cdimage.ubuntu.com
[05:47] <Keybuk> shiny
[05:47] <jdong> certainly shiny
[05:47] <jdong> but they also display 3d screen savers :D
[05:47] <Keybuk> I just boot the CDs in it
[05:47] <jdong> that works too :)
[05:47] <jdong> though you need to hand it more RAM than I'd like to
[05:48] <Keybuk> *shrug*
[05:48] <Keybuk> my usual thing is download all the cd images, and boot three at a time
[05:48] <jdong> random question, what does it take to enable this DT_GNU_HASH thing
[05:48] <elmo> Kamion: you were saying the other day that you thought root raid installs might be fucked - do you know for sure yet, and/or is it already fixed?
[05:48] <Keybuk> elmo: fabbione fixed it
[05:48] <elmo> ok
[05:48] <Keybuk> assuming it was the "they won't boot" problem
[05:49] <sladen> Keybuk: that's easy enough to fix, extend laptop-detect with a  --or-is-vmware  option and get the gnome-screensaver setup to use that parameter aswell
[05:49] <jdong> I just tried FC6 yesterday, and it's really... alarming... when it runs faster in vmware on my sempron than ubuntu on my dual core
[05:49] <jdong> and apparently that's dt_gnu_hash at work
[05:50] <elmo> Keybuk: yes
[05:50] <Keybuk> oh, that was kinda kooky
[05:50] <Keybuk> was doing an upgrade test
[05:50] <Keybuk> and the background image changed underneath during the upgrade
[05:50] <jdong> lol
[05:50] <jdong> the in-place upgrade really needs a few warnings
[05:51] <jdong> :)
[05:51] <jdong> namely, crashing your panel by adding an applet in the middle of the upgrade isn't recommended
[05:51] <jdong> or, your tooltips might change into gibberish as we change your fonts
[05:51] <jdong> or, firefox might begin speaking XML to you....
[05:54] <fabbione> elmo: it should be fixed. at least on my 3 test machines works
[05:55] <elmo> fabbione: cool, thanks
[05:55] <fabbione> elmo: if you find a problem, please let me know ASAP and we can see why
[05:56] <elmo> fabbione: we've only tested with edgy beta, if you say you've fixed it since then and it works for you,I'm happy to believe you
[05:56] <sabdfl> Keybuk: that's really "full confidence in the rest of the team" ;-)
[05:57] <fabbione> elmo: yes it was fixed after beta.. a bit hackish but it should do.
[05:57] <fabbione> elmo: basically once mdadm is installed and mdadm.conf is generated, we copy the conf in the initramfs to have md RAID UUID info and wait for it to appear (via mdadm --scan)
[05:58] <Keybuk> sabdfl: hmm?
[05:58] <fabbione> elmo: once the raid is available (or raids) then the boot goes further.
[05:58] <_ion> dholbach: Please see bug 64372.
[05:58] <Ubugtu> Malone bug 64372 in loudmouth "Crashes when connecting to server that requires STARTTLS" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64372
[05:58] <jdong> Keybuk: I think sabdfl wants to say s/Keybuk/elmo
[05:58] <fabbione> elmo: no attempts to check how many raid devices are available when we run it because you migth start in degraded mode.
[05:58] <elmo> fabbione: cool, thanks
[05:59] <fabbione> elmo: it's the only way to handle the situations in which devices appear after the first mdadm run. There is also a 3 minutes timeout for super huge storage systems that takes ages to make 300 devices to show up
[05:59] <fabbione> elmo: always welcome..
[06:02] <fabbione> mvo: i will be back later for when mdz is around
[06:03] <Kamion> elmo: it was a partitioner problem I thought I'd heard of, not a boot problem; but I admit I didn't look at it very closely since I was doing other things at the time
[06:04] <sabdfl> Keybuk: re TB
[06:04] <Keybuk> sabdfl: can you remember the last time you attended one? :p
[06:05] <sabdfl> oh, i just remember the really feisty ones ;-)
[06:08] <Keybuk> it was at UBZ, a year ago, wasn't it? :)
[06:08] <sabdfl> you exaggerate
[06:08] <sabdfl> that was only 11 months ago
[06:12] <Zdra_> Does someone knows where to fill upstream bugs for libnotify ? I just reported this bug for the ubuntu package but I think it should go upstream: https://launchpad.net/distros/ubuntu/+source/libnotify/+bug/64382
[06:12] <Ubugtu> Malone bug 64382 in libnotify ""attach-icon" property doesn't exists" [Undecided,Unconfirmed]
[06:28] <trappist> Zdra_: upstream for libnotify seems to be at chipx86.com, which seems to be down atm
[06:34] <dholbach> Zdra_: mvo in #ubuntu-desktop just looks at it
[06:35] <dholbach> Zdra_: galago-project.org is the upstream page - they have trac set up
[06:38] <Zdra_> dholbach: ok thanks... this website seems down ... :(
[06:39] <dholbach> yeah :/
[06:51] <_ion> dholbach: Did you see the bug report?
[06:52] <dholbach> _ion: about libnotify?
[06:52] <_ion> < _ion> dholbach: Please see bug 64372.
[06:52] <Ubugtu> Malone bug 64372 in loudmouth "Crashes when connecting to server that requires STARTTLS" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64372
[06:52] <dholbach> _ion: I get around 700 bug mails a day :-)
[06:52] <_ion> dholbach: Hehe.
[06:52] <dholbach> _ion: looking at it now
[06:53] <dholbach> _ion: we should subscribe the telepathy team to loudmouth bugs
[06:54] <dholbach> _ion: I'll forward it and apply the patch
[06:54] <kristog> dholbach: thank you :)
[06:54] <dholbach> _ion: thanks a lot for working on this: you ROCK!
[06:54] <_ion> dholbach: Thanks.
[06:57] <_ion> :-)
[07:04] <dholbach> _ion: http://developer.imendio.com/issues/browse/LM-62
[07:06] <_ion> Thanks.
[07:07] <dholbach> good to have you on the team
[07:17] <HiddenWolf> gnomefreak: when they release duke-nukem-forever. ;)
[07:17] <gnomefreak> ;)
[07:22] <highvoltage> hehe. I didn't expect that :)
[07:22] <gnomefreak> oops
[07:22] <gnomefreak> thats why you dont get hugged nick completion gets HiddenWolf
[07:23] <HiddenWolf> ;)
[07:24] <gnomefreak> theres a python 2.6 in repos already?
[07:25] <gnomefreak>  Warning: 'with' will become a reserved keyword in Python 2.6
[07:25] <gnomefreak> a little soon to be thinking about 2.6 IMHO
[08:04] <o_cee> is Till Kamppeter around?
[08:12] <_ion> dholbach: https://launchpad.net/distros/ubuntu/+source/cohoba/+bug/64398
[08:12] <Ubugtu> Malone bug 64398 in cohoba "Sends wrong type to telepathy-gabble" [Undecided,Unconfirmed]
[08:13] <_ion> dholbach: No patch yet. I'm too tired to concentrate at the moment. Perhaps i'll be able to fix that during the weekend, unless someone else fixes it first. :-)
[08:13] <dholbach> _ion: you should probably ping the guys in #telepathy about it - maybe they're working on something already.
[08:15] <o_cee> Steffen Joeris around?
[08:21] <infinity> For those who don't read mailing lists, soyuz will be offline for a fair chunk while we're upgrading drescher and rebuilding apt-ftparchive caches.
[08:22] <infinity> https://lists.ubuntu.com/archives/ubuntu-devel/2006-October/021519.html
[08:24] <sivang> infinity: this is to prepare to edgy+1 ?
[08:24] <infinity> sivang: No, read the mail.
[08:25] <sivang> infinity: right, /me crawls back to his hole
[08:32] <geser> could someone target bug 52803 to be fixed in edgy? (if it qualifies of course)
[08:32] <Ubugtu> Malone bug 52803 in gsfonts-x11 "insufficient dependency on xfonts-utils" [High,Confirmed]  http://launchpad.net/bugs/52803
[08:32] <highvoltage> you know you're tired when you stare at a usplash screenshot and wait for it to finish booting.
[08:33] <infinity> highvoltage: Was it full screen?
[08:33] <o_cee> anyone know anything about the foo2zjs drivers? Bug #6017
[08:33] <Ubugtu> Malone bug 6017 in dapper-backports "Update to latest package to make HP LaserJet 1020 work" [Undecided,Unconfirmed]  http://launchpad.net/bugs/6017
[08:33] <infinity> highvoltage: If not, wow.  Go to bed.
[08:33] <highvoltage> no, it was in a web browser
[08:33] <infinity> highvoltage: harsh.
[08:33] <_ion> How is it possible to take a screenshot of usplash?
[08:33] <highvoltage> goodnight!
[08:34] <_ion> 'ght.
[08:34] <highvoltage> _ion: you can boot from it in qemu, but there are many ways
[08:34] <_ion> Ah.
[09:16] <zul> iwj: ping
[09:30] <fabbione> mvo, mdz: ping?
[09:30] <mvo> fabbione: pong
[09:30] <iwj> zul: Hi.
[09:31] <iwj> Is this about my edit to XenOnEdgy ?
[09:32] <iwj> I have a working automatic domU constructor now.
[09:33] <mdz> fabbione: pong
[09:34] <fabbione> mdz: i think we should talk one minute about 63680
[09:34] <fabbione> mdz: do you have time now before mvo and i call the night?
[09:34] <mdz> fabbione: quickly
[09:34] <mdz> before my phone rings again
[09:35] <fabbione> mdz: well we would like to find a solution for that problem... and mvo has something already boiling around...
[09:35] <mdz> fabbione: messing around with apt's problem resolver in the last weeks of release is not OK
[09:35] <mdz> do you have another idea?
[09:35] <fabbione> mdz: that's not our suggestion
[09:35] <mvo> mdz: exactly, I was more thinking about a text-mode based dist-upgrader
[09:35] <fabbione> mvo: was thinking of a text version of the upgrader
[09:35] <mdz> that's worse
[09:35] <mvo> mdz: it would just be a different frontend to the upgrader
[09:36] <mvo> oh?
[09:36] <mdz> we're not adding features now
[09:36] <mdz> what other options do we have?
[09:37] <mvo> for the python-foo stuff, none AFAICS. only to document it in the release notes
[09:37] <fabbione> mvo: what's the other option for apt to think that it must upgrade ?
[09:37] <fabbione> for upstart at least.. but well we ship python stuff also on server CD
[09:37] <mvo> I think the upstart thing could be fixed
[09:37] <mvo> in apt by using the "essential" flag from the candidate version
[09:38] <fabbione> mvo: how dangerous is that?
[09:38] <mdz> it would need to be fixed in dapper apt
[09:38] <mvo> I can dig into the python-foo stuff again, but I have not that much hope
[09:38] <mvo> right
[09:38] <mvo> that makes matter worse
[09:38] <fabbione> other options?
[09:39] <mdz> dummy packages
[09:39] <mdz> that's the only other thing I can think of
[09:39] <fabbione> mvo: would that work?
[09:39] <mdz> it would work but it sucks
[09:39] <mvo> ++
[09:39] <fabbione> mdz: i agree that it sucks..
[09:40] <mdz> it may suck more than having to run apt-get install
[09:40] <mvo> we could provide a simple python-apt fixup script, but that would suck too
[09:41] <mvo> edgy+1 :)
[09:41] <fabbione> hmmm
[09:41] <_ion> Yeah, that would be cool.
[09:42] <fabbione> i think adding a Provides: to upstart won't help shit
[09:42] <mvo> the code for this is (in a basic form) in my repository already
[09:43] <fabbione> mvo: not for edgy.. mdz has already blacklisted that option
[09:43] <mvo> sure
[09:44] <fabbione> if we introduce the meta-packages.. are we guaranteed that it will work?
[09:44] <fabbione> and what meta packages do we need to create?
[09:44] <mdz> yes, we need it, but a) it is way too late, and b) it doesn't solve the problem
[09:44] <mdz> users who do their upgrades with apt know how to deal with held back packages
[09:45] <mdz> I agree that it sucks, but it has been sucking for months and now it is too late
[09:45] <fabbione> mdz: it has been sucking for months due to the Break: thingy and i did swallow it as "it has to be done that way"
[09:45] <fabbione> but afaik the break thing has been reverted
[09:46] <mdz> what does this have to do with breaks?
[09:46] <fabbione> the 2 steps apt update
[09:46] <mdz> this is a normal file conflict not a break
[09:46] <mdz> oh, you mean upstart
[09:46] <fabbione> yeps i know..
[09:46] <fabbione> yeah
[09:46] <iwj> Why not Replaces ?
[09:46] <fabbione> Replaces: sysvinit
[09:46] <fabbione> it does
[09:46] <mvo> so it will come down to putting it into the release notes
[09:46] <fabbione> apt seems to hate upstart
[09:46] <mdz> see the bug report; the trouble is due to essentialness
[09:47] <fabbione> mvo: it just loves it in a different way :)
[09:47] <madduck> are you guys fighting the problem that sysvinit is/was essential and now APT complains when replacing it with upstart?
[09:47] <mvo> exactly :)
[09:47] <mdz> fabbione: creating empty python2.x-foo in edgy and removing the conflicts would fix it, yes
[09:47] <mvo> madduck: yes
[09:47] <mdz> madduck: not complains exactly, just needs to be told twice
[09:48] <fabbione> what was the issue of making upstart Essential ?
[09:48] <fabbione> because it was for a while and then reverted?
[09:48] <madduck> mdz: ah, none of the "Yes, I know what I am doing" stuff?
[09:49] <fabbione> madduck: please read the bug report
[09:49] <madduck> 63680?
[09:49] <fabbione> yes
[09:50] <madduck> is there a shortcut to the bug report? like https://launchpad.net/63680 ?
[09:50] <fabbione>  /bugs/$bugnum
[09:50] <madduck> thx
[09:51] <fabbione> mvo: i am ok with whatever solution you think is best and won't destroy upgrades to edgy+1
[09:51] <fabbione> mvo: we have only 2 options
[09:51] <fabbione> - release note
[09:51] <madduck> fabbione: so the gist is that you want to fall back to the upgrader no matter what?
[09:51] <fabbione> - dummy packages
[09:51] <fabbione> - anything else?
[09:51] <madduck> .oO(debian will take the dummy package approach...)
[09:52] <fabbione> madduck: no i want to be able to dist upgrade dapper -> edgy with apt-get..
[09:52] <madduck> fabbione: good.
[09:52] <fabbione> i don't want the dist-upgrader (generally speaking)
[09:52] <mvo> fabbione: I can't think of anything right now. but I will ponder some more to come up with something
[09:52] <mvo> madduck: what problem did you fought in debian?
[09:52] <fabbione> mvo: ok sounds like a plan.. i will be around tomorrow and a bit more fresh than i am now
[09:52] <madduck> mvo: that sysvinit is essential and thus apt won't replace it.
[09:52] <madduck> mvo: apt-get install file-rc on any debian machine if you want to experience the effect
[09:53] <fabbione> mdz: can we have tomorrow to think about other possible alternatives and mail you?
[09:53] <madduck> fabbione: please put me on CC.
[09:53] <madduck><EMAIL_ADDRESS>[09:54] <fabbione> madduck: subscribe to the bug. that's mostlikely where we will store the info
[09:54] <fabbione> mail as in add stuff to the bug
[09:54] <madduck> k
[09:54] <fabbione> mvo: would that work for you?
[09:54] <mvo> fabbione: absolutely
[09:55] <fabbione> mvo: ok let's adjourn sometimes tomorrow when we are more fresh
[09:55] <fabbione> mdz: cheers.. we will let you know by tomorrow
[09:55] <mvo> fabbione, mdz: thanks!
[10:01] <Kamion> geser: done
[10:04] <geser> Kamion: thanks
[10:19] <madduck> mvo: maybe you could just fix #169241 ? :)
[10:21] <dholbach> madduck: let poor mvo go to bed :-)
[10:21] <madduck> dholbach: no way. :)
[10:22] <madduck> fine...
[10:23] <gnomefreak> i see kamion been busy ;)
[10:27] <LaserJock> bddebian: ping?
[10:31] <Kamion> hmm, how about I upload a non-broken version of ubiquity before leaving for the weekend
[10:32] <Kamion> looks like my filesystem-mounting code wasn't quite as well-tested as I thought
[10:54] <gnomefreak> tfheen: you have a minute. you closed a bug i wanted to ask you about why
[10:55] <bddebian> LaserJock: Yo, sorry
[11:15] <Ubugtu> Malone bug 57872 in gnome-power "regression: pressing power button no longer brings up logout dialog" [Unknown,Unconfirmed]  http://launchpad.net/bugs/57872
[11:21] <gnomefreak> jdong: looking at it. do you happen to know if apport reports freezes?
[11:21] <jdong> gnomefreak: AFAIK it only reports crashes (i.e. segfault)
[11:21] <jdong> gnomefreak: what does that have to do with the bug?
[11:21] <jdong> there's no "freeze" involved
[11:22] <gnomefreak> nothing but i needed an answer to it
[11:22] <gnomefreak> still looking at bug
[11:22] <jdong> the reason it doesn't work is very simple... the functionality was removed by patch 56
[11:22] <jdong> (kind of humorous, actually)
[11:22] <gnomefreak> trying to figure out how to get a log of a freeze
[11:22] <gnomefreak> jdong: this is fixed in edgy is it not?
[11:22] <jdong> gnomefreak: not fixed in edgy
[11:22] <jdong> it is an edgy regression
[11:22] <jdong> and it's been getting the cold shoulder
[11:23] <tfheen> gnomefreak: sure
[11:23] <jdong> even though I've now fully identified the culprit and commented in the ticket
[11:23] <gnomefreak> so has my samba man page error that was sent upstream
[11:23] <jdong> I'd expect a high priority bug to get more attention than that
[11:24] <gnomefreak> tfheen: the bug i marked as casper (cant think of bug number atm) but should casper ask you to upgrade on livecd? since those upgrades may affect the install?
[11:24] <tfheen> gnomefreak: no, why should it?
[11:25] <Kamion> gnomefreak: there's a ubiquity bug already about having it auto-upgrade itself, but that sort of UI belongs to ubiquity IMHO not casper
[11:25] <gnomefreak> tfheen: the guy upgraded (the livecd) before installing it and he ended up with a borked system. now this could have been due to the upgrade itself but i can see how the upgrade than install would affect outcome
[11:25] <Kamion> (you don't want to spend time upgrading from the network in the middle of booting up
[11:25] <Kamion> )
[11:25] <gnomefreak> ah ok ty
[11:26] <gnomefreak> this guy is pissed cause the bug was closed
[11:26] <Kamion> gnomefreak: was this 6.06?
[11:26] <Kamion> as opposed to 6.06.1?
[11:26] <tfheen> gnomefreak: the shipped desktop CD hopefully won't have any updates available, so upgrading is kinda moot.
[11:26] <gnomefreak> he didnt say if it was point release or not
[11:26] <Kamion> there was a known bug in dapper's ubiquity that it wasn't pointing apt at the target system properly
[11:26] <Kamion> so upgrading the live session could confuse it
[11:26] <Kamion> that's fixed in 6.06.1
[11:27] <Kamion> bug 47859
[11:27] <Ubugtu> Malone bug 47859 in ubiquity "crashes if some packages on live fs are unconfigured" [High,Fix released]  http://launchpad.net/bugs/47859
[11:27] <gnomefreak> ok ty ill dig up the bug and let him know
[11:27] <Kamion> (the description in the title is not complete; all sorts of weirdness can happen due to apt pointing at the wrong /var/lib/dpkg/status)
[11:27] <tfheen> upgrading your desktop cd could very well leave you with an inconsistent system which could crash and burn.  There's a reason why I disable the update notifier.
[11:28] <tfheen> if upgrading works and fixes something for you: great, but I'm not sure we want to make it supported.
[11:28] <gnomefreak> he also filed 4-5 bugs in one :(
[11:28] <Kamion> tfheen: ew, you're fixing the blue-on-black text on live CD shutdown, right?
[11:28] <tfheen> Kamion: it should be fixed, agreed.
[11:28] <Kamion> well dodged :-)
[11:28] <tfheen> Kamion: can you file a bug on usplash (if there's none already) and target it for 6.10?
[11:29] <LaserJock> Kamion: is there any plan on intel mac support in Ubquity for Edgy?
[11:29] <Kamion> LaserJock: no, sorry
[11:30] <LaserJock> ok, just wondering
[11:30] <tfheen> Kamion: I talked briefly with mjg59 about it earlier today and he pointed me in roughly the right direction, but I haven't fixed it yet, no.
[11:30] <LaserJock> my iMac is feels so lonely without Ubuntu ;-)
[11:30] <Kamion> I think I've barely scraped fixing up ordinary mac support ;)
[11:31] <Kamion> tfheen: is it the theme, or usplash itself?
[11:31] <tfheen> Kamion: I'm not sure, I think it's in usplash itself.
[11:31] <tfheen> 13:59 < mjg59> tfheen: Because usplash_put_part is broken
[11:31] <tfheen> 14:00 < mjg59> tfheen: Which I don't entirely understand, given that I'm pretty sure I just cut and paste the same code from usplash_put and it works fine there
[11:32] <gnomefreak> tfheen: bug im talking about is bug 63645 but i will take care of it ty Kamion and tfheen
[11:32] <Ubugtu> Malone bug 63645 in casper "Error in update manager" [Low,Rejected]  http://launchpad.net/bugs/63645
[11:32] <tfheen> is what he told me.
[11:32] <tfheen> gnomefreak: oh, the bug with lots of bug reports in it, well I did tell him to file separate bugs for his issues.
[11:32] <Kamion> tfheen: that's bug 64171
[11:32] <Ubugtu> Malone bug 64171 in usplash "Colors look bad " [Medium,Confirmed]  http://launchpad.net/bugs/64171
[11:32] <gnomefreak> he said he did but i have yet seen them
[11:32] <Kamion> it's targeted to ubuntu-6.10 already
[11:32] <tfheen> gnomefreak: some people seem to think that it's better to file one big report rather than a couple small ones, for some reason.  It isn't.
[11:33] <tfheen> Kamion: ok, it wasn't this morning
[11:33] <Kamion> gnomefreak: he says he's running edgy, not dapper, so it's not the above problem
[11:33] <gnomefreak> Kamion: and tfheen im sorry this is 6.10 livecd that told him to upgrade before installing
[11:34] <tfheen> gnomefreak: the desktop CD has the upgrade notifier disabled, so how he's "told" to upgrade I have no idea.
[11:35] <gnomefreak> tfheen: i dont know either i wasnt sure if it was supposed to be a bug in casper or ubiquity
[11:35] <Kamion> gnomefreak: his installer bug is some weirdo grub-installer crash that I won't pretend to understand, probably very hardware-specific
[11:35] <Kamion> but he's already filed that separately
[11:36] <gnomefreak> i told him to try install without upgrade first cause i wanted to see if it had anything to do with upgrading first
[11:36] <gnomefreak> but he didnt
[11:37] <funman> i'm having some problems with the installer of today's live cd
[11:38] <funman> i try for the 3rd time, and i'll give you details
[11:40] <Kamion> funman: is it complaining about execv() only taking string arguments, or something along those lines?
[11:40] <funman> yep
[11:40] <Kamion> funman: yeah, saw that myself, fixed in ubiquity 1.1.29
[11:40] <funman> is there a patch i can use ?
[11:40] <Kamion> hmm, give me a minute
[11:42] <Kamion> funman: apply http://people.ubuntu.com/~cjwatson/tmp/ubiquity-r1639.patch to /usr/share/ubiquity/install.py
[11:42] <funman> looks simple :/
[11:44] <funman> plus, keyboard configurations aren't auto selected using the language setting
[11:44] <Kamion> yeah, I know about that too, but it's a bit harder to fix
[11:44] <funman> nor they are translated
[11:44] <Kamion> not-translated won't be fixed for edgy I'm afraid, sorry
[11:44] <funman> it's a large amount of data
[11:44] <Kamion> we switched to a totally new keyboard configuration backend, which is better in almost all respects, except that it has no translation support for the layout or variant names
[11:45] <funman> why not ask the translation teams ?
[11:45] <Kamion> we'll just have to take that hit for edgy and fix it next time round
[11:45] <Kamion> no *support*
[11:45] <Kamion> not no translations
[11:45] <funman> hmm ok
[11:45] <Kamion> it's unfortunate, but there you go
[11:45] <Kamion> not having the old console keymap nightmare is worth it
[11:45] <funman> :)
[11:46] <Kamion> if it had been for dapper, it would have been a different story
[11:46] <funman> where is the code for keyboard selection ?
[11:47] <Kamion> the keyboard thing is bug 60067; I've targeted it at ubuntu-6.10
[11:47] <Ubugtu> Malone bug 60067 in ubiquity "Keyboard default choice should follows geographic localisation" [Wishlist,Confirmed]  http://launchpad.net/bugs/60067
[11:47] <Kamion> funman: primarily in console-setup
[11:47] <Kamion> it's a bit messy, it's a conflict between the use of console-setup on a normal system and its use in ubiquity
[11:48] <Kamion> on a normal system, you want to go with what 'locale' says, but in ubiquity, that's not accurate and you need to grab the installer question
[11:48] <Kamion> but switching the detection order round doesn't work either because normal systems may have debian-installer/locale in their debconf database but the value may be out of date
[11:49] <Kamion> so I'm still pondering the right approach
[11:51] <Kamion> there's one possible really gross approach - create /usr/lib/ubiquity/compat/locale which actually fetches the locale to use from debconf
[11:54] <funman> i'm not used to debconf
[11:55] <Kamion> well, it's just a database plus a simple protocol plus a few frontends for user interaction
[11:56] <Kamion> in this case it's only its database part that's relevant - the installer sticks stuff like the selected locale in that database and expects other bits of the installer to retrieve it from there later on
[11:59] <funman> i'm just viewing your page on launchpad
[11:59] <funman> you work a lot! are you employed by Canonical ?
[12:00] <tfheen> the "confirmed email address<EMAIL_ADDRESS>kinda gives him away, eh?
[12:01] <funman> well i didn't read all details ^^
[12:02] <funman> hum i can't see it
[12:02] <Kamion> yes, I am
[12:02] <funman> wouldn't launchpad show these details if the user is seeing _his_ page ?
[12:03] <Kamion> although maintaining a package that has a dialog that encourages people to file bug reports does rather boost my karma slightly artificially ;-)
[12:03] <Kamion> I'm not sure I'd recommend that approach though
[12:04] <funman> my page is still visible :(
[12:05] <funman> i know they plan to implement a "Delete all my infos" button but they have a lot of work to do before
[12:05] <Kamion> there may be some spam harvesting protection on the e-mail addresses
[12:05] <Kamion> I don't know the details
[12:07] <funman> hmm i when i plugged the alimentation of the hard disk, it smelled like grilled pig
[12:07] <funman> i think the disk didn't like :/
[12:07] <funman> *pouf* computer shutdown


[03:24] <spring> how do i find out what xbuntu version im on
[03:24] <Unit193> cat /etc/os-release
[03:24] <spring> ok
[10:37] <xubuntu> hi
[10:40] <diogenes_Vx15> xubuntu: hi
[10:41] <xubuntu> im trying Xubuntu first time
[10:41] <diogenes_Vx15> xubuntu: great
[10:42] <xubuntu> i have no expierience with linux
[10:44] <diogenes_Vx15> xubuntu: we can do our best to help you out.
[10:51] <xubuntu> thank you
[10:51] <xubuntu> what is this chat? in this chat we communicate with every distro?
[10:52] <diogenes_Vx15> xubuntu: this chat is to provide assistance for Xubuntu users only.
[12:38] <installation_fai> Progress bar shows zero progress for 20 minutes
[12:38] <installation_fai> Is it fair to assume that the installation failed?
[12:39] <installation_fai> Last message before clicking the link is: "Finished Cleanup of Temporary Directories"
[13:11] <xubuntu72i> Can you help me understand why my installation is stuck with no feedback for 30 mins?
[13:11] <xubuntu72i> Is there a way for me to open a terminal and diagnose?
[13:11] <xubuntu72i> Are there credentials I can use to login in another tty?
[18:45] <mcmini> bsr


[12:17] <sephger> Hello, Sorry if this is not the right location to ask but I'm a little concerned about the new Thunderbird Version... right now I can't use 78 because of some Enigmail problems. Do you know how long until the default ubuntu packages contain 78 instead of 68?