[12:44] <Caesar> mdz: ping?
[01:15] <mneptok> Caesar: it may be tough finding Canonical folks on IRC during Ubuntu Live.
[03:33] <nixternal> anyone else having issues with the 'notification-daemon' after the gtk+ updates today?
[08:24] <LaserJock> anybody know of a wiki page/doc that describes how the lang packs work?
[08:24] <LaserJock> or translation in Main in general?
[08:26] <Mithrandir> they're stripped out of the package at build time and shipped alongside the deb instead.  That then goes into rosetta which can export langpacks.
[08:26] <LaserJock> ok, that was my general understanding
[08:27] <LaserJock> that about as much as I know
[08:27] <LaserJock> I'm trying to figure out why some people are reporting that tuxpaint doesn't use the translated files
[08:28] <LaserJock> so I'm trying to work my way backwards
[08:28] <Mithrandir> does it try to open the files itself?  They're stored in a different directory and glibc is patched to use this other directory too.
[08:28] <Chipzz> I don't think that has much to do with how they're created
[08:28] <Chipzz> did you check if they are up-to-date / in the right place?
[08:29] <Chipzz> and if tuxpaint uses the correct translation domain?
[08:29] <LaserJock> well, I see on LP that they are getting translated
[08:29] <Chipzz> yes
[08:29] <LaserJock> hmm
[08:29] <LaserJock> let me check the domain
[08:29] <Chipzz> but packages get rolled only every so often
[08:30] <Chipzz> so you may need to wait until translations hit the debs, and until these hit the archives
[08:30] <LaserJock> well, this bug has been since dapper
[08:30] <LaserJock> the domain should be the source package name, right? not the binary package
[08:31] <Chipzz> well since a lot of translations actually do get used
[08:31] <Chipzz> it's most likely not something wrong in the langpacks ;)
[08:31] <LaserJock> no, I'm guessing not
[08:31] <Chipzz> I think the domain is unrelated to the package name
[08:32] <Chipzz> rather, it's how gettext gets initialised
[08:32] <Chipzz> (from how I understand gettext)
[08:32] <LaserJock> hmm, I thought the domain in the .desktop told it what package the .pot belongs to
[08:32] <Chipzz> hrrrm
[08:32] <Chipzz> form as far as I understand gettext
[08:33] <Mithrandir> LaserJock: that's just for translating the .desktop file.
[08:33] <Chipzz> you do something along the lines of init_gettext('foo');
[08:33] <Chipzz> where foo is the basename of the .po file
[08:33] <Chipzz> (init_gettext is a made-up function)
[08:34] <LaserJock> Mithrandir: ah, ok
[08:35] <Chipzz> LaserJock: this is php, but you get the idea: http://www.phpdig.net/ref/rn26.html
[08:35] <Chipzz> bindtextdomain ('greetings', './translations');
[08:35] <Chipzz> textdomain ('greetings');
[08:36] <Chipzz> http://www.phpdig.net/ref/rn26re450.html
[08:43] <LaserJock> hmm, so I need to figure out how tuxpaint is looking for translations
[08:44] <Chipzz> well
[08:44] <Chipzz> before you dive into the code
[08:44] <Chipzz> you could try stracing it, and see what files it tries to open ;)
[08:45] <Chipzz> strace ftw ;P
[08:45] <LaserJock> oh, good idea
[08:47] <LaserJock> Chipzz: would I need to use something other than en_US to test it do you think?
[08:48] <Chipzz> I'd think so ;)
[08:48] <LaserJock> hmm, maybe en_GB would work
[08:48] <Chipzz> I have the german language pack installed for testing ;)
[08:52] <LaserJock> Chipzz: would this be it? open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES", O_RDONLY)
[08:52] <Chipzz> no
[08:52] <Chipzz> something ending in .po I think
[08:53] <LaserJock> oh nifty, pitti is up :-)
[08:53] <pitti> Good morning everyone
[08:53] <pitti> shall I walk away again RSN? :-)
[08:55] <mvo> if anyone is here with a dapper system or a dapper VM, could you please install/test http://people.ubuntu.com/~mvo/tmp/opera_9.22-20070716.6dapper1_i386.deb
[08:56] <LaserJock> pitti: I'm trying to figure out a translation problem
[08:59] <pitti> mvo: I'll try with ia32-libs in my amd64 vm
[09:02] <mvo> pitti: thanks!
[09:03] <LaserJock> ok, so a package doesn't need to install a .pot for it to get picked up, right?
[09:05] <pitti> LaserJock: right; the build needs to create an up-to-date .pot, but .pot files are never installed into .debs
[09:08] <saispo> anyone know, which soft create this default route "default dev eth0  scope link  metric 1000" (i use eth1)
[09:10] <pitti> saispo: avahi-autoipd, I figure
[09:10] <pitti> saispo: it goes through eth1:avahi0, not eth1, I figure?
[09:10] <saispo> yes
[09:10] <saispo> it's possible to disable this ?
[09:10] <pitti> saispo: sure it is, but why would you want to?
[09:10] <pitti> does it hurt?
[09:10] <saispo> yes, with strongswan
[09:10] <jdong> that's what she said?
[09:10] <pitti> (you can just uninstall avahi-autoipd)
[09:11] <saispo> strongswan don't want two default routes
[09:11] <pitti> saispo: but it's metric 1000 only, so it should hardly matter?
[09:11] <pitti> saispo: or does strongswan use even lower-prio routes?
[09:11] <saispo> pitti: yes but if i uninstant it, kubuntu-desktop is removed, i think avahi-autoipd is used for something :)
[09:12] <saispo> s/uninstant/uninstall/
[09:12] <pitti> Riddell: ^ ah, that should be a recommends for Kubuntu, too, I think
[09:12] <pitti> oh, it isn't in Ubuntu either, it shuold be
[09:13] <saispo> pitti: avahi-autoipd is not in a default ubuntu ?
[09:13] <pitti> saispo: it is, I meant it should be a Recommends:, not a Depends:
[09:13] <LaserJock> will LANG= work to change the locale on a CLI when starting a program? or is LC_ALL better?
[09:14] <saispo> pitti: will open a bug for Kubuntu :)
[09:14] <pitti> LaserJock: depends; usually LANG= works, since by default Ubuntu only sets LANG and LANGUAGE, not LC_*
[09:14] <pitti> LaserJock: with LC_ALL=C it'll always work
[09:15] <LaserJock> well, I'm trying to debug a translation problem
[09:15] <saispo> pitti: thanks :)
[09:15] <LaserJock> which is off course fun for me the uni-lingual American ;-)
[09:16] <Mithrandir> LaserJock: pft, it's not hard until you have to use the desktop in with a foreign character set, such as japanese or korean.
[09:17] <LaserJock> heh, I bet
[09:17] <Mithrandir> "does this glyph mean yes or no?"
[09:20] <LaserJock> what is "/usr/share/locale-langpack/en/" for?
[09:20] <pitti> LaserJock: English translations
[09:21] <LaserJock> hmm, generic ones? I mean I see en_US, en_GB, etc.
[09:21] <pitti> LaserJock: although it is common practice, C is not required to be English :)
[09:21] <LaserJock> so I wonder what just en is
[09:21] <Mithrandir> it's generic english
[09:21] <pitti> so I doubt that there's actually a lot of stuff in it
[09:22] <pitti> I've actually seen software which used French as C
[09:22] <Mithrandir> that must be hard, given that C is ASCII
[09:23] <LaserJock> hmm, I just installed the de lang pack, just to be cool
[09:24] <LaserJock> now de has a lot but de_DE doesn't have so much
[09:24] <pitti> LaserJock: that's the way it's intended
[09:24] <pitti> LaserJock: the bulk is usually kept in just the generic po files, and the country specific ones contain just the exceptions
[09:25] <pitti> LaserJock: de_CH and de_AT have 90%/95% of the strings in common with de_DE, I figure
[09:25] <pitti> so it would just be unnecessary translation work and duplication
[09:25] <LaserJock> hmm, what country uses de_AT
[09:26] <azeem> austria
[09:27] <LaserJock> ahhh
[09:28] <LaserJock> ok, well I tried LANG=en_GB and LANG=de_DE and both times strace said tuxpaint is looking for en_US .mo files
[09:28] <pitti> LaserJock: try setting LANGUAGE=
[09:28] <pitti> LaserJock: GTK programs prefer $LANGUAGE
[09:29] <LaserJock> oh wow
[09:30] <LaserJock> so tuxpaint has tuxpaint itself and tuxpaint-stamps
[09:30] <LaserJock> with LANG= tuxpaint is still in en but the stamps are in de
[09:30] <LaserJock> with LANGUAGE= tuxpain is in de but the stamps are in en
[09:31] <LaserJock> pitti: is ^^ normal?
[09:32] <pitti> LaserJock: heh, looks like -stamps doesn't use GTK
[09:32] <ajmitch> hi pitti, LaserJock
[09:33] <pitti> hey ajmitch
[09:33] <LaserJock> pitti: so would that be a problem for a normal user? is both LANG and LANGUAGE normally set?
[09:33] <LaserJock> hi ajmitch
[09:33] <pitti> LaserJock: yes
[09:34] <pitti> LaserJock: i. e. both is set normally
[09:34] <LaserJock> pitti: danke ;-)
[09:35] <pitti> LaserJock: gern geschehen
[09:35] <pitti> bonjour, Monsieur seb128
[09:35] <mvo_> seb128: good morning
[09:47] <seb128_> re
[09:47] <seb128_> pitti: I was saying that we can update to dbus 1.1 now
[09:48] <pitti> seb128_: \o/
[09:48] <pitti> seb128_: dbus-perl is good now? already uploaded or shall I merge that as well?
[09:48] <seb128_> pitti: there is a contributor debdiff available for the dbus update I think
[09:49] <seb128_> pitti: a fixed version has been uploaded yesterday, I'm going to sync it now
[09:54] <seb128_> pitti: hum, "sync tool currently has some weird bugs"? like what?
[09:56] <pitti> seb128_: oh, that was sync-source.py (the LP version)
[09:56] <pitti> seb128_: but it should be fixed now
[09:56] <seb128_> k
[09:56] <pitti> seb128_: can you please use sync-source.py instead of sync-source and see how it goes?
[09:57] <pitti> seb128_: it worked for me yesterday, cprov did some in-place fixes
[09:57] <seb128_> pitti: k, sure
[09:57] <seb128_> pitti: should the agg in syncs be flushed?
[09:57] <pitti> seb128_: hm, please delete it for now, i don't know about the status
[09:58] <seb128_> k
[09:58] <pitti> (that was my test package yesterday)
[09:58] <seb128_> has the dpkg-source version been updated?
[09:59] <pitti> seb128: not sure, but I doubt it
[09:59] <seb128> k, so it likely still have an issue with "+"
[10:03] <pitti> seb128: is bug 84007 fixed in gutsy already?
[10:03] <ubotu> Launchpad bug 84007 in gnome-media "Cannot edit audio profiles without closing the list" [Medium,Fix committed]  https://launchpad.net/bugs/84007
[10:03] <seb128> pitti: no
[10:05] <pitti> $ gcc-4.2 --version
[10:05] <pitti> gcc-4.2: No such file or directory
[10:05] <doko> ?
[10:06] <pitti> oh, I see
[10:06] <pitti> that points to ccache, sorry
[10:08] <pitti> seb128: I commented that bug, as well as bug 112955
[10:08] <ubotu> Launchpad bug 112955 in vino "vino (vnc) keyboard mapping problem" [High,In progress]  https://launchpad.net/bugs/112955
[10:08] <seb128> pitti: thanks
[10:08] <seb128> looking
[10:12] <doko> seb128: the sparc failures are related to a wrong(?) glib2.0 header file, libgnomecanvas did fail again
[10:12] <seb128> doko: I'll have a look
[10:26] <pitti> Hobbsee!
[10:28] <Hobbsee> pitti!
[10:28] <Hobbsee> zomg, shirish crack.
[10:28] <seb128> hello Hobbsee
[10:29] <Hobbsee> more to the point, *more* shirish crack
[10:29] <asisak> Where can you see that, Hobbsee?
[10:30] <Hobbsee> asisak: ubuntu-devel-discuss mailing list
[10:32] <Hobbsee> every time i see things with shirish in them, i want to gouge out my eyes.  unfortunately, i cant just block anything with his email in it, as i still get people's replies to him, and if i remove them, i probably miss valid content.
[10:32] <Hobbsee> asisak: about packages to build binaries from sources.
[10:32] <Hobbsee> (from within apt)
[10:32] <ajmitch> surely it's not *that* bad
[10:33] <Hobbsee> ajmitch: well, it's not crack.  it's more just blatant idiocy, and talking out the back of his head
[10:33] <Hobbsee> ajmitch: if he had *any* clue about development of ubuntu, and debian packaging, he wouldnt have written that mail.
[10:34] <Hobbsee> ajmitch: because apparently ubuntu accepts sources that dont build binaries, so you can install this package, to build said binaries for ubuntu.  or something.
[10:34] <ajmitch> aha
[10:35] <ajmitch> since we make things fail to build, just for fun & an exercise for the user, right?
[10:36] <Hobbsee> exactly
[10:36] <ajmitch> asisak: bitter rage? :)
[10:36] <pitti> "Just a little taste of Gentoo"
[10:37] <asisak> but all of them depend on gtk I guess
[10:37] <Hobbsee> ajmitch: what i *really* dont get though, is that he's a self-declared new user, and a self-declared idiot, yet he regularly spouts off absolute rubbish to multiple mailing lists, bug reports, etc...and apparently thinks he's helping?
[10:37] <Hobbsee> he is *not* helping as it's almost always absolute crap that someone will take time to reply to, just to tell him how wrong he is.  ubuntu niceness, and all.
[10:37] <ajmitch> Hobbsee: some people are like that, you have to let it pass & hopefully educate them, if possible
[10:38] <Hobbsee> ajmitch: education fails.  although, it works *slightly* better when you educate him, while paying him out at the same time.
[10:39] <ajmitch> even the famous Hobbsee was new once
[10:39] <ajmitch> though I recall you being awfully shy & not wanting to break anything :)
[10:39] <Hobbsee> ajmitch: this is indeed true, but i at least shut up and watched what others did, so as not to make a bloody fool of myself at every possible opportunity
[10:40] <Hobbsee> i'm not having a go at the newness - far from it.  it's the fact that he constantly expresses his idiocy, without a thought about whether his thoughts are logical and correct, or not
[10:42] <Hobbsee> ajmitch: does this mean that you think i do want to break everything now?  :P
[10:42] <seb128> asisak: what error do you get?
[10:42] <ajmitch> Hobbsee: you're far less afraid to
[10:42] <coNP> seb128: only the sparc build error
[10:43] <coNP> that is a gtk >= dep error
[10:43] <ajmitch> Hobbsee: I remember how long it took to convince you to start merging stuff
[10:43] <Hobbsee> heh.  and you and StevenK teasing me, not letting me leave until id' done one in front of you.
[10:43] <ajmitch> :)
[10:44] <seb128> coNP: ah, k, I'm on this one ;)
[10:44] <coNP_> cool, seb128
[10:52] <Riddell> pitti: should avahi-autoipd be changed to recommends in the seeds?
[10:52] <pitti> Riddell: that would make sense IMHO
[10:53] <pitti> Riddell: I'll do the same for Ubuntu
[10:53] <Riddell> pitti: what about libnss-mdns?
[10:53] <pitti> Riddell: the same, I think
[10:53] <pitti> Riddell: shall I do the change in Ubuntu and you merge it?
[10:53] <pitti> that's a bit easier for future seed changes with merges
[10:53] <Riddell> pitti: ok
[10:53] <Riddell> yes
[10:54] <pitti> Riddell: committed
[11:48] <iwj> doko: Is `gcj-4.2: Internal error: Killed (program jc1)' another symptom of the amd64 Java damage or is it something else ?
[11:50] <doko> iwj: jc1, not ecj1? didn't see this yet. appears to be a problem with glibc-2.6 on amd64
[11:50] <iwj> I c&p'd that message, so yes.
[11:50] <iwj> OK, I'll file a bug then with a full transcript.
[11:51] <iwj> It might not be today, as I have a backlog of 81 of these autopkgtest ftbfs's to eyeball and report and I'm trying to get some other work done too.
[11:55] <seb128> pitti: bug #84007
[11:55] <ubotu> Launchpad bug 84007 in gnome-media "Cannot edit audio profiles without closing the list" [Undecided,In progress]  https://launchpad.net/bugs/84007
[11:55] <seb128> pitti: "whereas feisty has 2.18.1-0ubuntu1", were did you get this version?
[11:55] <seb128> gnome-media | 2.18.0-0ubuntu1 |        feisty | source, amd64, i386, ia64, powerpc, sparc
[11:55] <seb128> that's from madison
[11:57] <pitti> seb128: hm, weird, I used rmadison
[11:57] <pitti> seb128: oh, gnome-media
[11:57] <pitti> seb128: I madison'ed vino
[11:57] <seb128> well, there was one on vino and one on gnome-media
[11:57] <seb128> k
[11:57] <pitti> *headdesk*
[11:58] <seb128> so the version is correct ;)
[11:58] <seb128> thanks
[11:58] <pitti> seb128: sorry then :)
[11:58] <seb128> np
[11:59] <pitti> seb128: bug updated
[11:59] <pitti> seb128: so, gutsy and feisty-proposed at the same time are fine, but I won't copy it to -updates before it's fixed and tested in gutsy
[12:00] <seb128> ok
[12:02] <pitti> seb128: so I see a bunch of syncs from you, but not libdbus-perl?
[12:03] <seb128> pitti: no, it's not on the mirror yet, I'll dget and do it by hand now
[12:04] <pitti> mmm dget; that's news to me, thanks for the hint
[12:04] <lool> There's a libnet-dbus-perl NMU in Debian unstable pending installation
[12:04] <seb128> lool: that's what we are speaking about
[12:05] <lool> Ok; sorry
[12:05] <seb128> nothing to be sorry about, thanks for the information ;)
[12:05] <lool> Will you switch to dbus 1.1.1 afterwards?
[12:05] <seb128> yes
[12:05] <lool> Cool
[12:09] <seb128> pitti: there is a marge patch on launchpad
[12:10] <seb128> (in case you didn't notice)
[12:10] <pitti> seb128: I saw, just looking at it
[12:10] <seb128> k
[12:10] <seb128> libnet-dbus-perl synced
[12:11] <pitti> ah-haaaa
[12:11] <seb128> ah?
[12:11] <pitti> seb128: in feisty, hal was started by the dbus script
[12:11] <seb128> right
[12:11] <pitti> now it has its own init script at prio 24
[12:11] <pitti> but gdm is at 13
[12:11] <seb128> ah
[12:12] <seb128> gnome-session is starting faster then?
[12:12] <pitti> I think the correct answer is to move hal's init script before gdm
[12:12] <pitti> bit tricky, S12dbus and S13gdm
[12:12] <pitti> S12hal would work due to asciibetical order, though
[12:12] <pitti> but 12.5 would be better :)
[12:12] <cjwatson> BASIC disease
[12:13] <pitti> yeah :/
[12:13] <cjwatson> d-i did a BASIC-style renumbering exercise a couple of months ago on its installer-menu-item numbers
[12:14] <cjwatson> we just multiplied them all by 100, so should be enough room for a while yet
[12:14] <pitti> init script prio migration is painful, but I think we have to do it
[12:14] <cjwatson> I think S12hal would be OK here
[12:14] <cjwatson> ish
[12:14] <cjwatson> there's a distressing amount of pressure on the 10-20 range
[12:15] <cjwatson> I think it was a mistake to have the default be 20 originally
[12:15] <cjwatson> (rather than 50)
[12:15] <giskard> morning
[12:16] <cjwatson> unfeasible to change now, of course :(
[12:17] <pitti> well, fractionals look terribly ugly, but it'd be a last resort
[12:17] <pitti> fortunately it's "D"bus and not "X"bus or so :)
[12:18] <pitti> elkbuntu, Hobbsee: bug 127913 FYI (I think you saw that, but I didn't find a bug report yet)
[12:18] <ubotu> Launchpad bug 127913 in hal "hal starts too late" [High,In progress]  https://launchpad.net/bugs/127913
[12:32] <elkbuntu> pitti, yeah, i must have forgotten to report it, sorry for that. testing stuff in the high wee hours isnt always smart :
[12:32] <elkbuntu> pitti, would it also be why sometimes my networking hasnt started properly?
[12:33] <pitti> elkbuntu: it's possible
[12:35] <pitti> seb128: ah, with new dbus network-admin is almost empty
[12:36] <seb128> "almost"?
[12:36] <seb128> do you have the new perl package?
[12:36] <seb128> I mean libnet-dbus-perl
[12:36] <pitti> seb128: no, I'm going to wait with the upload until it's available and I confirmed it to fix the issue
[12:36] <seb128> k
[12:37] <pitti> yeah, s/almost// :)
[12:44] <Hobbsee> https://bugs.launchpad.net/ubuntu/+bug/127915 ...what?
[12:44] <ubotu> Launchpad bug 127915 in Ubuntu "c2f87d89633a6ea26a02b23d298543d" [Undecided,New] 
[12:44] <pitti> Hobbsee: I think this is a hwdb identifier
[12:45] <Hobbsee> pitti: i'd guess so, but why has the guy filed it in a bug, saying "no sound"?
[12:45] <pitti> maybe he really doesn't have no sound? :)
[12:45] <Hobbsee> i realise that... :P
[12:45] <Hobbsee> i'm just wondering how on earth the guy expects the sound to be fixed, just like that.
[12:46] <Fujitsu> Does the hwdb data go anywhere but /dev/null at the moment?
[12:46] <cjwatson> yes, it lands somewhere on rookery and we can do statistical analysis on it
[12:47] <cjwatson> certainly not anywhere near as useful as it should be though
[12:47] <cjwatson> no sound> cf. bug 123126 which I just happened to be looking at
[12:47] <ubotu> Launchpad bug 123126 in linux-source-2.6.20 "After kernel update to 2.6.20-16 on Acer Extensa 4014 I lost sound" [Undecided,New]  https://launchpad.net/bugs/123126
[01:19] <Hobbsee> oh fricking....
[01:19] <Hobbsee> calc: what'd you do?
[01:37] <elmo> mjg59: ping
[01:42] <pitti> seb128: I grabbed the new libnet-dbus-perl from accepted, works great
[01:42] <seb128> pitti: rock on ;)
[01:43] <Nafallo> pitti: hello :-)
[01:43] <pitti> hello Nafallo
[01:43] <Nafallo> pitti: might want to approve bacula in dapper-proposed :-)
[01:46] <Nafallo> hi Keybuk :-)
[01:47] <Keybuk> http://people.ubuntu.com/~scott/theme.png
[01:48] <Keybuk> err, reload that
[01:49] <Hobbsee> heya Keybuk!
[02:01] <agoliveira> amitk: ping?
[02:02] <amitk> agoliveira: pong
[02:03] <agoliveira> amitk, Hi. I noticed that the kernel on tribe 3 uses a very old version of the asus-acpi module. Do you know why?
[02:03] <agoliveira> amitk, delay that.
[02:03] <agoliveira> Hold on
[02:05] <agoliveira> amitk, My mistake. Actually, I wanted to use asus-laptop and not asus_acpi. It's ok, just that the asus-laptop, in my opinion, should be the default and not asus_acpi.
[02:07] <amitk> agoliveira: if there is a good reason to switch, make a case and we shall do it.
[02:08] <agoliveira> amitk, asus-laptop (http://acpi4asus.sourceforge.net/) is already in the kernel and is far more complete than the default asus_acpi.
[02:08] <agoliveira> Without, I can't, for instance, switch to external monitors.
[02:09] <agoliveira> or control some fancy leds that models like the G series have.
[02:09] <agoliveira> but, of course, the external monitor problem is the worse.
[02:10] <amitk> agliveira: any missing features that you know of in asus-laptop that are present in asus-acpi?
[02:11] <agoliveira> amitk, none that I'm aware of. It don't see any problem removing it on my Asus G1 and replacing it by asus-laptop.
[02:12] <zul_> agoliveira: is this the led thing?
[02:13] <agoliveira> zul_, the leds work with the asus-laptop but the biggest problem is not being able to switch to an external monitor without it.
[02:14] <zul_> agoliveira: its a usb quirk thing i think, i remember seeing it on the linux-usb-devel mailing list
[02:15] <GyrosGeier> I use asus_acpi in Debian's 2.6.21, and I can switch just fine
[02:15] <GyrosGeier> (A series laptop)
[02:15] <agoliveira> zul_. BTW, I also already can control the OLED display as well. Me and a friend are writting a driver for it.
[02:16] <GyrosGeier> it doesn't do any good because the native resolution couldn't be handled by anything I had ever connected.
[02:18] <agoliveira> GyrosGeier: Right now I'm working with an external 20" LCD running at 1658x1024, the same native resolution od the notebook, LCD. I didn't have any problems at all with that.
[02:18] <agoliveira> s/1658/1680
[02:18] <GyrosGeier> agoliveira, cool
[02:18] <agoliveira> sorry I meant 1680x1050
[02:19] <GyrosGeier> the A series turns the LCD black if you use a non-widescreen resolution
[02:19] <agoliveira> GyrosGeier: This external LCD is widescreen connected to DVI so I can't say.
[02:23] <agoliveira> amitk, btw, is the patch to load a custom DSDT already in the gutsy kernel?
[02:23] <amitk> agoliveira: the CVS version that supports 2.6.22 is far ahead of the in-kernel version
[02:23] <amitk> agoliveira: yes.. I pushed it in yesterday
[02:25] <pitti> meh, nautilus crashes all over the place since latest dist-upgrade today
[02:26] <agoliveira> amitk: Weird... the cvs version shows 0.41 while the in-kernel shows 0.42...
[02:27] <Hobbsee> pitti: you didnt really *want* nautilus, did you?
[02:28] <pitti> Hobbsee: occasionally I even use it, just to get used to GUIs a bit more :)
[02:28] <Hobbsee> haha
[02:28] <Hobbsee> poor pitti, happy with his console.
[02:31] <thom> consoles are the future. this GUI stuff will be seen as the fad it is!
[02:31] <Hobbsee> :P
[02:32] <Kmos> no console, no future :)
[02:32] <Hobbsee> no question
[02:32] <Kmos> bug 127931
[02:32] <ubotu> Launchpad bug 127931 in f-spot "f-spot.exe crashed with SIGSEGV" [Undecided,New]  https://launchpad.net/bugs/127931
[02:32] <Kmos> .exe? lol
[02:32] <Hobbsee> just *only* consoles would get slightly dull though
[02:33] <Hobbsee> Kmos: there are a fair few like that.
[02:33] <StevenK> It's mono
[02:33] <asisak> Kmos: .net has exe
[02:33] <calc> Hobbsee: huh?
[02:33] <Kmos> yeah.. mono is like ... (very bad word)
[02:33] <Kmos> lol
[02:33] <calc> Hobbsee: you asked what did i do?
[02:34] <Hobbsee> calc: yes.  ooo is broken again.
[02:34] <calc> Hobbsee: i didn't do anything at all
[02:34] <Hobbsee> calc: doesnt start
[02:34] <calc> Hobbsee: there hasn't been a new upload since last week
[02:34] <calc> Hobbsee: so someone broke something else in that case
[02:34] <Hobbsee> well, find them, and yell at them :)
[02:34] <Hobbsee> (process:17234): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.13.7/gobject/gtype.c:2242: initialization assertion failed, use IA__g_type_init() prior to this function
[02:34] <Hobbsee> (process:17234): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
[02:34] <Hobbsee> (process:17234): Gdk-CRITICAL **: gdk_screen_get_font_options: assertion `GDK_IS_SCREEN (screen)' failed
[02:35] <Hobbsee> is what i seem to get, from a console
[02:35] <Kmos> http://arstechnica.com/news.ars/post/20070723-ars-at-ubuntu-live-mark-shuttleworths-keynote.html
[02:35] <Hobbsee> and it sitting there with the splash screen
[02:35] <Kmos> gtk is broken as seb128 said
[02:35] <calc> Hobbsee: see what Kmos just said
[02:35] <amitk> agoliveira: nevermind, the cvs is identical to the in-kernel version. I was looking under drivers/acpi. But it is under drivers/misc
[02:35] <seb128> hum
[02:36] <seb128> Kmos: did I say that?
[02:36] <Kmos> seb128: didn't you?
[02:36] <seb128> the error mentionned to Hobbsee is new to me
[02:36] <Hobbsee> i thought he was talking about gtk being broken on sparc.
[02:36] <seb128> doesn't look like the same issue than the nautilus crasher
[02:36] <seb128> there is a nautilus crasher
[02:36] <Kmos> 12:41 <seb128> gtk+ didn't build on sparc due to a glib bug
[02:36] <seb128> and a sparc build issue due to glib
[02:36] <Kmos> only at sparc?
[02:36] <Kmos> =)
[02:36] <seb128> right, that's a build and installability issue
[02:36] <asisak> yea, and this breaks a lot of packages that depend on glib
[02:37] <asisak> (only on sparc)
[02:37] <seb128> the error Hobbsee is mentionning is something else
[02:37] <asisak> Hobbsee: how did you do this?
[02:37] <Hobbsee> sarah@LongPointyStick:~$ ooffice -calc
[02:37] <amitk> agoliveira: nevermind, the cvs is identical to the in-kernel version. I was looking under drivers/acpi. But it is under drivers/misc
[02:38] <Hobbsee> someone else mentioned ooo not opening either, but i dont remember who
[02:38] <agoliveira> amitk: Ah, so I'm not that crazy ;)
[02:38] <seb128> Hobbsee: crashes the same way here
[02:38] <Hobbsee> seb128: yay!  let's both blame calc then :P
[02:38] <calc> there are new glib, gtk, glibc so maybe something will break :)
[02:38] <asisak> calc works as well
[02:38] <asisak> I mean oocalc
[02:38] <asisak> :)
[02:38] <agoliveira> amitk: You told me that the DSDT patch went to the kernel yesterday so it's 2.6.22-9?
[02:39] <Hobbsee> calc: sure, but we'll blame you anyway.
[02:39] <calc> whatever it is it is unlikely to be ooo's fault since it worked until seb updated glib/gtk
[02:39] <seb128> Hobbsee: downgrading to GTK 2.11.5 make it work, I tend to blame GTK
[02:39] <amitk> agoliveira: yes. Tribe 4 should have it
[02:39] <Hobbsee> seb128: great.
[02:40] <Hobbsee> seb128: seriously, just get rid of gtk...
[02:40] <agoliveira> amitk: So we are not getting a kernel update meanwhile?
[02:40] <seb128> Hobbsee: what about getting ride of you? ;)
[02:40] <StevenK> And go back to Athena?
[02:40] <calc> yea for athena! :)
[02:40] <seb128> s/ride/rid
[02:40] <Hobbsee> seb128: i'm sure you wouldnt want to get rid of me...
[02:40] <Kmos> seb128: hehe
[02:40] <amitk> agoliveira: we might...
[02:40] <Hobbsee> would you?
[02:40] <calc> and fvwm for window manager
[02:40] <seb128> Hobbsee: no I wouldn't ;)
[02:40] <Hobbsee> oh good
[02:41] <Kmos> StevenK: that's a monster kill :D
[02:41] <calc> heh
[02:41] <Kmos> calc: not calling you a monster :-)
[02:41] <Kmos> hehe
[02:41] <StevenK> seb128: Who else would deal all of KDEs bugs, er, I mean features. :-P
[02:41] <amitk> calc: you are spoilt. Nothing beats TWM
[02:41] <StevenK> deal with, even
[02:41] <calc> amitk: yuck
[02:41] <agoliveira> amitk: hmmm... can you point me to (or send me) the patch? I will apply myself so. It's anoying having to manually switch to the external monitor manually everytime.
[02:42] <Kmos> Get ride of kubuntu, like pat do with gnome for slackware :)
[02:42] <Hobbsee>  /kb kmos
[02:42] <amitk> agoliveira: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=summary
[02:42] <Kmos> Hobbsee: :P
[02:42] <Riddell> !CoC | Kmos
[02:42] <ubotu> Kmos: The Ubuntu Code of Conduct to which we ask all Ubuntu users to adhere can be found at http://www.ubuntu.com/community/conduct/
[02:43] <StevenK> Kmos: I don't exactly trust a man whos idea of a package system is one that isn't.
[02:43] <amitk> agoliveira: git clone git://kernel.ubuntu.com/ubuntu/ubuntu-gutsy.git should get you the latest kernel
[02:43] <Hobbsee> Riddell: i think seb128 needs to be thrown out into the snow or something, next UDS.
[02:43] <Kmos> Riddell: i'm just kidding
[02:43] <calc> StevenK: it worked well in 1995 when heavy package systems would have killed systems
[02:43] <agoliveira> amitk: Thanks
[02:43] <elmo> Riddell: the CoC is not a stick to beat anyone with who expresses any negative view on kubuntu, please stop using it as such
[02:43] <calc> StevenK: trying to use dpkg/dselect on a pentium 90 with 16mb of ram is not pretty
[02:44] <Kmos> calc: oh my god
[02:44] <StevenK> calc: It's useable, just slow. rpm is much worse
[02:44] <calc> StevenK: i'm not sure that statement is actually true, iirc it swapped like hell even ~ 5 years ago the last time i tried it on my old box
[02:45] <calc> i think it used a multiple of 16mb at the time, not sure how it has been tuned since then
[02:45] <calc> but it definitely wasn't a pretty sight
[02:46] <calc> Kmos: i started out with slackware 2.2 and linux 1.2.4 (from what i recall) debian was around then but i didn't notice it on my infomagic cd's at the time
[02:46] <agoliveira> amitk: BTW, one more thing, the current kernel wrongly attaches an USB device present in some Asus notebooks (id 0b05:1726) to usbhid. Actually, there is no kernel driver for it. What can I do to help fix this?
[02:46] <Kmos> calc: i started with rh8..
[02:46] <Kmos> never tried slack
[02:46] <ScottK> Hobbsee: Is there an issue that needs dealing with?
[02:47] <Kmos> after rh, i used ubuntu until now.. and i don't think in change
[02:47] <calc> Kmos: not much point to try slackware by that point
[02:47] <StevenK> Hobbsee: We need backports-manager like restricted-manager!
[02:47] <amitk> agoliveira: file a bug
[02:47] <Hobbsee> ScottK: just the amount of crack that goes thru, and the bugs
[02:47] <Kmos> i like to read slack changelogs :D are funny..
[02:47] <Kmos> lol
[02:47] <calc> Kmos: i have the old original redhat release with rpp files, heh
[02:47] <zul> agoliveira: i have a fix for that in my git tree already
[02:47] <Kmos> calc: that's for museum
[02:47] <Kmos> :)
[02:47] <Kmos> lol
[02:47] <agoliveira> amitk: I was about to :) I was wondering about what kind of information one might need.
[02:47] <calc> Kmos: yep
[02:47] <agoliveira> zul: Cool
[02:48] <ScottK> Hobbsee: OK.  If it was a specific bug, I might look into it.  I'll note for the record that (AFAIK) none of my backports have been particularly crackish.
[02:48] <StevenK> calc: Surely that disc has started fossilising?
[02:48] <Kmos> hehe
[02:48] <calc> Hobbsee: another data point, ooffice -calc works for me after updating gutsy
[02:48] <amitk> zul: is a quirk fix?
[02:48] <zul> agoliveira: but please file a bug first
[02:48] <zul> amitk: yes
[02:48] <StevenK> Wanting to fix clamav is fairly crack worthy. :-P
[02:48] <calc> Hobbsee: i haven't restarted gnome but it still works right now anyway
[02:48] <Kmos> back later guys.. nice work :)
[02:48] <calc> StevenK: heh probably so
[02:48] <Hobbsee> ScottK: havent seen anything specific in the past few days
[02:49] <Hobbsee> just a bug that came in reminded me
[02:49] <ScottK> OK.
[02:49] <amitk> agoliveira: just the output of 'lsusb' and pointer to specific device
[02:49] <Hobbsee> calc: right
[02:49] <agoliveira> amitk: Ok, will do it.
[02:49] <agoliveira> Thanks
[02:50] <TheMuso> c/
[02:50] <TheMuso> ugh kvm
[02:50] <calc> Hobbsee: after restarting gnome it still works, interesting bug
[02:51] <calc> gar!
[02:51] <calc> metacity lost its snap to window feature?
[02:51] <calc> now it only can snap to borders of the desktop
[02:51] <calc> seb128: any idea about that issue?
[02:51] <StevenK> calc: It isn't using compiz?
[02:52] <seb128> calc: you are using compiz, aren't you?
[02:52] <calc> StevenK: it appears my system is using metacity still
[02:52] <seb128> so no, no idea
[02:52] <seb128> metacity didn't change recently
[02:52] <calc> hmm odd then
[02:52] <seb128> it works fine for me and nobody else mentioned it
[02:52] <amitk> zul: are you planning to request a pull with other stuff soon?
[02:52] <calc> maybe i should clean my dotdirs out
[02:52] <zul> amitk: yes tomororw morning
[02:52] <calc> seb128: it appears its somewhat more narrow bug, i can't snap a window to a window below it on the screen
[02:53] <seb128> calc: metacity doesn't do snapping though, only edge resistancy
[02:53] <amitk> zul: cool. Then it will go in for the next release
[02:53] <calc> i mean the shift+click
[02:53] <calc> i mean the shift+click
[02:53] <zul> amitk: yeppers
[02:53] <calc> er
[02:53] <calc> gar my enter keeps getting in the way
[02:53] <calc> i mean the shift+click+drag
[02:53] <seb128> ah, still work fine for me
[02:53] <calc> i have two gnome terminal windows on my desktop
[02:54] <calc> one in upper left and one in lower left
[02:54] <calc> if i try to drag the top one down it obscures the bottom one
[02:54] <calc> but if i drag the bottom one up it snaps to properly
[02:54] <calc> but it compiz is what should be used i can try to determine why its not on my box
[02:55] <seb128> compiz is used on new installations only
[02:55] <calc> when dragging the bottom one down it snaps all the way to the bottom bar in gnome not to the top of the other terminal
[02:55] <seb128> otherwise you have to enable it in the appearance dialog
[02:56] <calc> it doesn't work
[02:56] <calc> errors out
[02:56] <calc> i'm on nvidia binary driver
[02:57] <calc> is that a known issue?
[02:58] <agoliveira> zul, amitk, done. Let me know if you need anything else. BTW, I have userland code that actually drives this OLED display. If you want to make it a kernel driver, let me know.
[03:08] <seb128> calc: nv or nvidia?
[03:08] <seb128> ah, binary
[03:09] <seb128> should work I think
[03:09] <seb128> mvo_ knows better
[03:11] <mvo_> calc: can you please put the content of .xsession-errors to a pastebin?
[03:12] <Hobbsee> mvo_!
[03:12] <mvo_> hey Hobbsee
[03:27] <Kano> hi, when will be amd64 current fixed?
[03:27] <Kano> sudo -i, id does not work
[03:27] <Hobbsee> "when it's fixed"
[03:28] <Hobbsee> Kano: bug number?
[03:28] <Mithrandir> Kano: works fine for me
[03:28] <Kano> Mithrandir: kubuntu amd64 current not
[03:28] <pitti> Kano: what does it do for you?
[03:28] <Kano> segfault
[03:28] <pitti> $ sudo -i
[03:28] <pitti> root@donald:~# id
[03:28] <pitti> uid=0(root) gid=0(root) Gruppen=0(root)
[03:28] <Mithrandir> Kano: there's no difference between those for ubuntu and kubuntu.
[03:28] <pitti> Kano: oh, wait
[03:28] <sbalneav> Hey all, currently looking at squashing Bug #107518.  What would be a "good" way to determine if a given filesystem is "dirty"?
[03:28] <ubotu> Launchpad bug 107518 in ltspfs "auto filesystem mounting can cause hideous data loss" [Medium,Confirmed]  https://launchpad.net/bugs/107518
[03:28] <pitti> Kano: does 'id' segfault as normal user, too?
[03:29] <Kano> id -> Illegal instruction -> core dump
[03:29] <Kano> yes
[03:29] <Riddell> Kano: does the md5sum match that in the package?
[03:29] <pitti> Kano: on the last live CD we had file system corruption which often affected /usr/bin/id
[03:29] <Kano> Riddell: of course
[03:29] <pitti> $ md5sum /usr/bin/id
[03:29] <pitti> b95e1a28e650a12f2d0ec9dd34aab6ab  /usr/bin/id
[03:29] <pitti> Kano: ^ for you?
[03:30] <Kano> c1...
[03:30] <pitti> Kano: I heard many people for whom /usr/bin/id was a fragment of XML, or an MPEG or such stuff
[03:30] <pitti> Kano: please try 'apt-get install --reinstall coreutils' (from the network source)
[03:31] <pitti> Kano: just FYI, it's most likely bug 126964
[03:31] <ubotu> Launchpad bug 126964 in linux-source-2.6.22 "gutsy livefs causes random hangs or modprobe crashes" [Critical,New]  https://launchpad.net/bugs/126964
[03:31] <Kano> hmm that worked
[03:32] <pitti> oh, thanks for verifying
[03:32] <Kano> how about switching to aufs
[03:32] <pitti> Kano: pkl already fixed the bug, when we'll get a new kernel upload it should be history
[03:33] <Kano> how to add 2 little id patches to next kernel?
[03:33] <Kano> i dislike to patch is every time
[03:34] <pitti> Kano: 'every time'?
[03:34] <Kano> i have a script to recompile it for etch, but maybe i would base new kanotix directly on gutsy.
[03:34] <Kano> and i NEED those patches
[03:35] <Kano> http://kanotix.com/files/kernel/kernel-update-pack/source/
[03:35] <Kano> the 2 patches
[03:35] <Kano> very small, just adding ids
[03:37] <pitti> Kano: looks sensible; please file them as bugs against linux-source-2.6.20
[03:37] <Kano> the via patch is for the intel via ids of the well known via southbridge bug
[03:38] <Kano> the other supports the card within the name of the patch
[03:38] <Kano> patches are for .22 too
[03:40] <Kano> is it known that the textmode has no german layout only kde when booted with language option
[03:41] <Riddell> Kano: it's not clear what you mean
[03:41] <Riddell> Kano: are you saying linux console is in US keyboard layout while X is using german?
[03:41] <Kano> when you press ctrl-alt-f1
[03:41] <pitti> s/te$/ge/
[03:42] <Kano> i use live cds for testing my gfx install scripts
[03:42] <seb128> we should find a way to ban the automatix use ;)
[03:42] <Nafallo> seb128: please do :-)
[03:42] <Kano> of course i know us keyboard layout,but i would prefer german as my keyboard is german...
[03:43] <Mithrandir> seb128: make update-manager and synaptic refuse to touch the system if automatix has ever been installed.
[03:43] <Mithrandir> or libc fail to install
[03:43] <Hobbsee> Mithrandir: that's already the plan, isnt it?
[03:43] <Nafallo> Mithrandir: that would break Jennys box ;-)
[03:43] <pitti> Mithrandir: I think I should disable apport reports if automatix is in apt sources
[03:43] <pitti> (I'm serious)
[03:43] <Nafallo> Mithrandir: but then I think I cleaned out the whole damn mess...
[03:43] <pitti> it just creates clutter
[03:43] <Hobbsee> pitti: so's Mithrandir :)
[03:43] <Hobbsee> pitti: cant see why you arent alraedy, tbh
[03:43] <Mithrandir> Nafallo: *shrug*; reinstall then.  Or edit the dpkg status file.
[03:43] <pitti> can someone tell me how to detect it?
[03:44] <pitti> it's just grep -v on apt sources, I figure?
[03:44] <Mithrandir> pitti: if dpkg -s automatix shows it?
[03:44] <Kano> who can show me how these kubuntu current images are built?
[03:44] <pitti> Mithrandir: ah, there's a proper package? last time I saw it I thought it boiled down to an apt source
[03:44] <Kano> the live ones
[03:44] <Mithrandir> pitti: I think it's a proper package now, yes.
[03:44] <Hobbsee> pitti: you could check the status file too, to see if it was ever installed.
[03:45] <Nafallo> Mithrandir: I extracted the damn sources through the deb since upstream refused to give me the source in a easier way and read through to be able to revert what it did :-P
[03:45] <pitti> Mithrandir: great use case for my 'general package hooks' :)
[03:45] <Mithrandir> pitti: haha. :-)
[03:45] <pitti> actually designed for apparmor, but would be great for automatix as well
[03:45] <Kano> btw. i have even more sugestions.... if you like i write em in a textfile
[03:46] <pitti> Kano: https://help.ubuntu.com/community/LiveCDCustomization
[03:46] <Kano> my questions is not about modifing, it is to build from scatch
[03:47] <Kano> i want a clean build
[03:47] <pitti> "  Michael Dell, Founder and CEO of Dell Inc., uses Automatix2 on his home computer"
[03:48] <Nafallo> pitti: can't you reinstall Ubuntu automagically upon detection? ;-)
[03:48] <Kano> is there any possiblity to get newer fuse-utils than in sid
[03:48] <evand> hilarity: http://www.getautomatix.com/wiki/index.php?title=FAQ#Does_Automatix2_break_Ubuntu_upgrades.3F
[03:48] <Kano> 2.6.5 is faulty
[03:48] <Kano> 2.7.0 is ok
[03:49] <Kano> when used with uuids in fstab for ntfs-3g
[03:49] <pitti> http://www.getautomatix.com/wiki/index.php?title=Installation -> ah, so that package is automatix2 now; I guess I'll check for both
[03:50] <Kano> i heard that fuse 2.7.x will not enter sid until the other is in lenny, that can take ages
[03:51] <pitti> Kano: we can update it in Ubuntu only, if it's important
[03:51] <stdin> heh "Ubuntu has been notorious for breaking xserver packages several times" <- once != several times
[03:51] <pitti> Hobbsee: in what way?
[03:51] <Kano> well i use it a while for my with etch backports, works fine
[03:52] <pitti> Kano: you should coordinate that with ogra, though, since he's our heaviest fuse user
[03:52] <Kano> i am a heavy ntfs-3g user ;)
[03:52] <Kano> speed is really nice
[03:52] <pitti> Kano: right
[03:52] <pitti> Kano: I meant, ogra needs it for ltsp and such
[03:52] <Hobbsee> pitti: about whether it's good or not
[03:52] <pitti> Kano: maybe you can send him some test packages, and if they work for ltsp, we'll upload it?
[03:52] <Kano> i would prefer that kde could use it
[03:53] <Kano> my packages are too simple, just exchanged 2.65 with 2.70, not worth to think about... maybe you want other changes?
[03:54] <sbalneav> I'd have to check and see if the newer fuse works with the ltsp stuff, but I have no objection to moving forward.
[03:54] <Riddell> Kano: where did you set the keyboard layout?
[03:54] <sbalneav> I'm upstream for the ltsp side of things so if something needs to be done for a newer fuse, it's easy.
[03:54] <pitti> Kano: right, it's mainly to get it verified with the ltsp guys that 2.7 doesn't break anything (or get the necessary fixes into ltsp)
[03:54] <pitti> hey sbalneav
[03:54] <sbalneav> Hey pitti!
[03:55] <Kano> Riddell: well on feisty i think it worked. used the language selection
[03:55] <pitti> Kano: we are still well before upstream version freeze, so getting it in now is no problem
[03:55] <Kano> http://kanotix.com/files/thorhammer/updates/
[03:55] <evand> We should really document the cases where automatix breaks the world and put them somewhere centralized so we can point to it when they start spreading FUD again
[03:56] <Kano> these are mainly newer packages than in sid
[03:56] <Kano> maybe except the discover-data, this is a bit specific
[03:56] <ScottK> evand: I'd say pointing to the line where it sigkills dpgk should be sufficient evidence (with a proper explanation) of why it should not be used.
[03:57] <Kano> not that many packages
[03:57] <Hobbsee> evand: ScottK stick the source package somewhere, etc.
[03:57] <Hobbsee> including the part about the sigkill of dpkg
[03:58] <ScottK> evand: You don't actually need a source package (and they don't provide it) you can just unpack the .deb.
[03:58] <Kano> 915res has one added id for intel g33 (needed for vesa basically only but it worked...)
[03:59] <Nafallo> ScottK: I tried to ask them why they didn't provide that :-)
[03:59] <Hobbsee> ScottK: evand but they would just whinge about how that's defamation, etc, most likely, and that the ubuntu devs dont try to work with them
[03:59] <Nafallo> ScottK: apperently it's to hard for them to dput _source.changes to their archive ;-)
[03:59] <Hobbsee> actually, that X thing probably relates to people who install the binary drivers via automatix, which then get hosed every kernel update
[04:00] <Kano> Riddell: did you patch your k3b also with the old code for verify? i added it to my package
[04:00] <ScottK> jdong had said something about talking to them a while ago.
[04:00] <ScottK> jdong: Did you get anywhere with that?
[04:01] <jdong> ScottK: no, it stalled after a forum council meeting
[04:01] <evand> Hobbsee: we could also document past attempts of trying to encourage them to create a team that tests the upgrade path using automatix, if need be
[04:01] <Riddell> Kano: I'm not sure, I've lost track of k3b patches since other people seem to be maintaining it.  you can check with apt-get source k3b
[04:01] <Hobbsee> ScottK: he likely got very abused, etc, about how all the MOTUs are crap, etc
[04:01] <jdong> ScottK: and to be honest I don't think it's going to go anywhere.... :(
[04:01] <Hobbsee> evand: they wont listen.
[04:01] <jdong> ScottK: we're getting walked all over by Arnav at the forums.
[04:01] <elkbuntu> Nafallo, for a brief time they even had a compiled python file or something in their package
[04:01] <Hobbsee> evand: you'd have to go purely by technical merit, or lack of it
[04:01] <Kano> Riddell: from changelog i dont think so. i extracted the needed patches from websvn
[04:01] <cjwatson> Kano: the livecd-rootfs package is used to build the live filesystem
[04:01] <Hobbsee> evand: hell, they dont even seem to care that they're installing binaries which they cant see the source for
[04:02] <Kano> cjwatson: thanks
[04:02] <Riddell> Kano: oh if it's in upstream we'll get it when we package 1.0.3
[04:02] <Kano> maybe add it... otherwise cd is ejected but not verified
[04:02] <cjwatson> Kano: was your console keyboard layout issue with feisty or gutsy? (there were two known relevant bugs in feisty)
[04:02] <Kano> yes it is in upstream. but do you like to wait for 1.0.3 ;)
[04:02] <Kano> gutsy
[04:02] <cjwatson> interesting
[04:03] <Kano> i am testing currently only
[04:03] <ScottK> jdong: As we discussed before, if they would respect the packaging system, then I don't think we'd say bad things.
[04:04] <ScottK> jdong: And feel free to tell them you're welcome for fixing the clamav bug they whined about on their web page with no help from them.
[04:04] <Kano> cjwatson: i want more features in live mode, like possible execution of scripts, more cheatcodes and such things
[04:05] <cjwatson> there's a bug on casper about providing more hooks; feel free to file additional bugs for specific items
[04:06] <Kano> i think gutsy could get pretty good when those little things are fixed
[04:06] <elkbuntu> dear nautilus. please stop restarting, it is awfully counterproductive. love elky
[04:06] <cjwatson> wow, this live CD is buggered
[04:06] <cjwatson> booting in vmware, and all commands hang
[04:07] <Kano> how is packaging the avm drivers?
[04:07] <pitti>     if apport.packaging.get_version('automatix') or \
[04:07] <pitti>         apport.packaging.get_version('automatix2'):
[04:07] <pitti>         report['UnsupportableReason']  = 'You have installed automatix on your \
[04:07] <pitti> system. This is known to cause a lot of instability, thus problem reports \
[04:07] <pitti> will not be sent to the Ubuntu developers.'
[04:07] <elkbuntu> cjwatson, do file /var/usr/id
[04:07] <pitti> Hobbsee: that should teach them :)
[04:07] <Kano> have got ideas for those too
[04:07] <coNP> elkbuntu: did you get seb128's update?
[04:07] <elkbuntu> errr... /var/lib/id
[04:07] <cjwatson> elkbuntu: YM /usr/bin/id? (won't help as no external commands return)
[04:07] <elkbuntu> coNP, dunno
[04:07] <Hobbsee> pitti: i'd let them file it direct to the automatix bugtracker :P
[04:07] <pitti> cjwatson: did you try pkl_'s test CD?
[04:07] <seb128> I doubt it has built yet
[04:07] <seb128> use the spatial mode as a workaround :p
[04:07] <elkbuntu> cjwatson, yeah. im muddled tonight. it's a damn mpeg last i checked a livecd :
[04:07] <Hobbsee> pitti: and you should also mentoin that said instability does not occur on an ubuntu system
[04:08] <cjwatson> pitti: no. did the bug in question affect vmware?
[04:08] <coNP> why I only can get source 0ubuntu1.dsc?
[04:08] <pitti> cjwatson: I never observed it in vmware, but there's no specific reason why it should not affect it
[04:08] <elkbuntu> nautilus needs to un-break so i can string paths together
[04:09] <seb128> elkbuntu: use spatial for an hour
[04:09] <cjwatson> ah, there we go, happier on a second boot
[04:09] <cjwatson> Kano: as I thought, running 'sudo setupcon' after boot fixes the console layout
[04:09] <cjwatson> very weird, I was sure I'd fixed that damn bug
[04:10] <Kano> cjwatson: fine, please start it by default
[04:11] <Kano> but why are umlauts in white and the rest is light gray?
[04:11] <cjwatson> Kano: it *is* started. it's a bug that reverts it later.
[04:11] <cjwatson> if it were that easy it'd be fixed already :P
[04:11] <cjwatson> I'm looking at it
[04:12] <Kano> i build live cds since a few years, i know some things about em ;)
[04:12] <cjwatson> but not about console-setup, apparently ;-)
[04:13] <cjwatson> it has some messy initramfs interactions
[04:13] <cjwatson> should have a massive "you are not expected to understand this" sign above it
[04:13] <cjwatson> ah, could just be that the keyboard layout isn't munged early enough
[04:14] <cjwatson> this'll be messy
[04:16] <cjwatson> the basic problem is that you cannot reliably set the keymap once usplash has started; and you can't really do it reliably after it finishes either because X is about to snarf the console
[04:16] <cjwatson> so you have to set it really really early
[04:19] <Kano> cjwatson: there most be something else wrong, pos1, end does not work
[04:20] <elkbuntu> coNP, as for your question, it seems that no, i do not have the nautilus update, or if i do, it didnt work for me
[04:27] <Kano> cjwatson: livecd-rootfs has an example but the build-$s-live dirs are missing
[04:27] <Kano> the example is pretty useless without
[04:29] <gnomefreak> spatial mode is default for nautilus isnt it?
[04:30] <gnomefreak> if so using spatial mode is closing unexpectedly, how can that be used as a workaround
[04:31] <seb128> gnomefreak: no, not in Ubuntu
[04:31] <seb128> gnomefreak: spatial is the mode without decoration, path bar, sidebar
[04:31] <gnomefreak> ah i went to help and it said it was ok ill see if i can chage it
[04:32] <cjwatson> Kano: they're just standard debootstrapped chroots with the livecd-rootfs package installed, AFAIK
[04:32] <seb128> go to preferences and unset the "always use browser windows"
[04:32] <gnomefreak> ah ok ty
[04:32] <seb128> or whatever it's called in english ;)
[04:32] <cjwatson> Kano: "pos1" == home key?
[04:32] <Kano> cjwatson: yes
[04:32] <cjwatson> Kano: likely all part of the same bug
[04:33] <Kano> i think so
[04:33] <Kano> but i executed your command
[04:33] <cjwatson> ah
[04:33] <cjwatson> well, home works for me
[04:36] <Kano> cjwatson: why is the ramdrive fixed to 1 gb?
[04:37] <cjwatson> Kano: it's not; it's the kernel default of half your memory size
[04:37] <Kano> hmm
[04:47] <zul> someone mention my name?
[04:47] <Hobbsee> zul: the arrest warrant.
[04:47] <zul> wohoo..
[04:50] <wwoods> pitti: ping
[04:51] <pitti> hey wwoods
[04:51] <wwoods> pitti: so we're sending some patches upstream that change coredump-to-pipe behavior to work like it does in your kernel
[04:52] <pitti> wwoods: oh, with the environment variables or with fixed macro handling?
[04:52] <wwoods> see http://lkml.org/lkml/2007/7/19/521 and http://lkml.org/lkml/2007/7/22/128
[04:52] <pitti> wwoods: awesome, thanks a lot!
[04:52] <cjwatson> Kano: ok, so I think I have a horrible hack which will fix the default keymap. at least sometimes.
[04:52] <wwoods> those two patches ignore coredump rlim for pipes
[04:52] <cjwatson> can't guarantee the font will be right mind you, but it's correct for German at least
[04:52] <wwoods> the patch to handle argv[]  for core_pattern is coming later this week
[04:53] <wwoods> and there's a new format specifier - %c - which expands to the actual core rlim
[04:53] <wwoods> so probably we'll call apport with --real-rlim %c
[04:53] <wwoods> get everything else from the headers.. and bob's yer uncle
[04:54] <Kano> cjwatson: will livecd.sh use it?
[04:54] <pitti> wwoods: ah, right
[04:54] <pitti> wwoods: too bad that the macro patch is still necessary then, just for %c
[04:54] <mathiaz> pitti: I've been working on bug 121441
[04:54] <ubotu> Launchpad bug 121441 in mysql-dfsg-5.0 "Mysql man pages are non-free" [Unknown,Fix released]  https://launchpad.net/bugs/121441
[04:54] <mathiaz> pitti: and created a mysql-doc package.
[04:54] <cjwatson> Kano: what's livecd.sh got to do with it? it's in caspe
[04:54] <cjwatson> r
[04:54] <pitti> wwoods: but I figure it would be convenient to have macros work properly for other usages of pipe-in-core_pattern
[04:54] <mathiaz> pitti: should I upload it to revu ?
[04:54] <wwoods> pitti: it's the Right Thing To Do anyway
[04:54] <pitti> mathiaz: hi
[04:55] <wwoods> so yeah
[04:55] <Kano> cjwatson: sure, but is it in the repository
[04:55] <wwoods> it's not the simplest patch, but it's the most correct/useful
[04:55] <pitti> mathiaz: I don't have a revu account yet, I prefer direct feedback, but if you want to use revu, go ahead
[04:55] <Kano> i think it works with a chroot envrionment
[04:55] <pitti> wwoods: I agree
[04:55] <wwoods> anyway your patch will still work but I'll probably be patching apport in my branch for that
[04:55] <cjwatson> Kano: I don't understand your question?
[04:55] <cjwatson> is what in the repository?
[04:56] <Kano> well is it already in the repository your modified casper version
[04:56] <wwoods> oh - I've also got the beginnings of a turbogears-based crashdb in my branch, but I don't think we'll use that for the initial fedora release
[04:56] <mathiaz> pitti: well. I think it should go in restricted - so I'm not sure if revu is the best place to upload
[04:56] <mathiaz> pitti: I can upload it to p.u.c
[04:56] <cjwatson> Kano: no, I haven't quite uploaded it yet, but will do
[04:56] <mathiaz> pitti: and you can have a look at it ?
[04:56] <Kano> otherwise the created live cds would not use it
[04:56] <pitti> mathiaz: WFM
[04:56] <cjwatson> Kano: yes yes I know how to drive the Ubuntu live CD creation process
[04:57] <mathiaz> pitti: ok. I'll do this then. Thks.
[04:57] <cjwatson> I wrote fair chunks of it ;)
[04:57] <pitti> wwoods: once this is adopted upstream, I'm sure that we will replace our patches with upstream's
[04:57] <pitti> wwoods: and I'll just change apport trunk to work with it
[04:57] <pitti> wwoods: I see no need to support more than one method
[04:57] <pitti> wwoods: and your ELF extraction code is really nifty!
[04:58] <Kano> basically the package selection seems pretty easy in that file...
[04:58] <wwoods> pitti: cool! yeah, I agree, except for having older branches that support older kernels
[04:58] <wwoods> not sure which linus kernel this will make it into but I'll keep you posted
[04:59] <wwoods> I think it's going into andrew morton's tree?
[04:59] <pitti> wwoods: as it is in trunk right now, it should automatically read from ELF if CORE_SIGNAL etc. is not specified
[05:00] <Kano> i think i can change it to my needs...
[05:00] <pitti> wwoods: I shuold really revive preloadlib/ and make it behave like the change you propose, then we have the test suite and can fix it in advance
[05:01] <pitti> wwoods: oh, I think we'll pull it as soon as it lands in upstream git
[05:02] <wwoods> pitti: right, I saw that, good stuff
[05:02] <wwoods> preloadlib/ ?
[05:02] <pitti> wwoods: it's a small LD_PRELOAD library that simulates the kernel behaviour
[05:02] <pitti> wwoods: when I wrote the very first line of apport I used this as a very first means to intercept crashes at all
[05:03] <pitti> wwoods: just look at it, it installs a signal handler and calls apport with the same environment than the kernel would
[05:04] <Kano> cjwatson: what was tocd?
[05:04] <pitti> wwoods: later I used it to create a reference implementation of the new environment var passing approach, so that I could write the tests and apport implementation without waiting for the kernel implementation
[05:04] <wwoods> ahhh
[05:04] <cjwatson> Kano: http://www.theopencd.org/
[05:04] <cjwatson> we did a live CD component for that for a while
[05:05] <pitti> wwoods: if you stop apport (i. e. standard core_pattern), './test-apport lib' will use this
[05:05] <Kano> i see your code, maybe i adopt that for kanotix...
[05:05] <Kano> looks easy to add new packages that way
[05:06] <Kano> but i see nothing that would be like a sortlist
[05:07] <Kano> ok i see it... you fetch em from the web
[05:07] <Kano> but as usual every url is down
[05:12] <pitti> back in 15 minutes
[05:31] <calc> yea i'll clean out .xsession-errors and restart
[05:32] <calc> seb128: nvidia
[05:34] <calc> mvo__: a clean xsession-errors is 4.6KB
[05:34] <cjwatson> Kano: ok, casper uploaded with keymap fix, give it a few hours to build and publish and stuff
[05:35] <calc> mvo__: its mostly evolution alarm stuff though
[05:37] <mvo__> calc: it should contain something from compiz as well, please send me the log
[05:37] <calc> mvo: oh i see you want to compiz error part, i'll do a clean compiz xsession-error log then
[05:37] <calc> s/to/the/
[05:37] <mvo> calc: thanks
[05:38] <calc> brb
[05:40] <calc> mvo: interesting i see the issue, will put it on pastebin though
[05:42] <calc> mvo: http://pastebin.com/de07cbb2
[05:45] <mvo> calc: that is interessting, do you use a dual-head setup?
[05:45] <calc> yes
[05:45] <calc> two 23" 1920x1200 displays
[05:46] <mvo> impressive
[05:46] <calc> gears seems to work accelerated (i think) > 900fps anyway
[05:46] <calc> unless that is normal for no hw accel
[05:47] <calc> so does randr not work for dual head or something else is wrong?
[05:47] <desrt> randr works rather well for dual-head...
[05:47] <desrt> it's the mechanism by which  multiple heads are supported :p
[05:47] <mvo> calc: could you please put you /var/log/Xorg.0.log somewhere?
[05:48] <calc> desrt: you sure you aren't confused with xinerama? :)
[05:48] <calc> mvo: ok
[05:49] <mvo> calc: you do not do anything fancy like "    Option	"RandR" "off"	in ServerFlags ;) ?
[05:50] <calc> i don't recall doing that
[05:50] <calc> i'll put both of the files on a server and look at them as well
[05:50] <mvo> calc: thanks
[05:52] <calc> http://cheney.ws/debug/
[05:53] <calc> the config might look a bit strange because i was using info from a nvidia example to setup dual head
[05:54] <calc> i might need to do enable some other things as well (maybe?)
[05:56] <calc> mvo: see above ^
[05:57] <mvo> calc: thanks, I guess "xdpyinfo | grep RANDR" is empty for you?
[05:58] <calc> mvo: yes
[05:58] <mvo> calc: that seems to be what compiz is complainging about, but it is strange given that you explicitely enable RandR in your server flags
[05:58] <calc> mvo: i think that was some fragment from nvidia driver configurator
[05:58] <calc> mvo: should i remove some of that stuff and add others?
[05:59] <mvo> calc: libxrandr2 is installed and up-to-date?
[05:59] <calc> yes 2:1.2.1-1
[06:00] <mvo> eh... could you please try disabling xinerama ?
[06:01] <calc> ok, brb
[06:01] <mvo> calc: sorry, but those seem to be incompatible these days
[06:04] <calc> mvo: so the default window manager doesn't work with dual head?
[06:04] <manchicken_> Is anybody following the new issues with OO.o in gutsy?
[06:04] <manchicken_> ca
[06:04] <calc> mvo: or just not on nvidia?
[06:04] <manchicken_> calc: I hear you're the person to talk to ping on this.
[06:04] <calc> manchicken_: which issue is it?
[06:05] <calc> manchicken_: from what i hear someone broke something in gtk recently, but i can't reproduce the issue locally
[06:05] <manchicken_> calc: ooo, with any program, when I start it I get nothing but a splash screen and a maxed out CPU.
[06:05] <calc> manchicken_: thats probably the broken "gtk" issue but i am not certain since i can't reproduce it here
[06:06] <manchicken_> Okay... there's a new version of GTK that I believe just came out, too.
[06:06] <calc> manchicken_: yes which is what broke ooo
[06:06] <calc> manchicken_: at least from what i have been told by other people
[06:06] <manchicken_> Naw, there's one that came out after that, too.
[06:06] <calc> oh interesting
[06:07] <manchicken_> It was broke, so I tried an update, which brought libgtk2.0-0 (2.11.6-1ubuntu1) on here.
[06:07] <mvo> calc: just not with xinerama
[06:07] <manchicken_> It's still broken after that update.
[06:07] <manchicken_> calc: I wonder if it was one of the many gcj updates.
[06:07] <calc> mvo: is there a way to do dual head without duplication of gnome bars without xinerama?
[06:08] <calc> mvo: after turning off xinerama i still have dual head working but i have two application and task bars
[06:08] <calc> mvo: oh nm i have them but i can't get to the other head at all from what i can tell
[06:09] <calc> mvo: it seems once i started up compiz i can't get to the other head
[06:09] <calc> mvo: at least by dragging apps over there anyway
[06:10] <Kano> cjwatson: what tool do you use to create the iso?
[06:10] <calc> and compiz snap to feature doesn't seem to work or is different from metacity
[06:10] <Kano> the rootfs is created
[06:11] <cjwatson> Kano: http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ plus checkouts of the bits mentioned in configs/devel once you've checked that out
[06:11] <calc> i don't need eye candy, i just need a working system, seems compiz isn't nearly ready for use for dual head
[06:11] <cjwatson> (http://people.ubuntu.com/~cjwatson/update-config may help)
[06:12] <mvo> calc: but compiz works now on both heads?
[06:12] <cjwatson> it's a bit all over the place because it's grown from code that just built the alternate ISO
[06:12] <calc> mvo: not sure i couldn't easily get to the second head it was completely separate
[06:12] <calc> mvo: i can try again if needed
[06:14] <mvo> calc: you should be able to a single desktop with randr1.2, but I don't know if nvidia supports this yet
[06:14] <calc> mvo: no it doesn't work
[06:14] <calc> mvo: without xinerama the second head has no window manager at all
[06:14] <calc> mvo: and trying to enable it on it has crashed compiz entirely
[06:15] <calc> mvo: so no compiz on either head right now
[06:15] <geser> pitti: Hi, can you give-back linuxdcpp, ardour, aqsis?
[06:15] <calc> mvo: in fact no window manager at all it didn't fall back to anything either (not sure if it should have)
[06:15] <calc> i still have the compiz effects but no window manager
[06:16] <calc> mvo: i think i am getting compiz effects on both heads
[06:17] <pitti> re
[06:17] <Amaranth> calc: then you have a WM
[06:17] <Amaranth> calc: that would mean you have no decorator
[06:17] <calc> mvo: disabled and reenabled got the decorator on the primary head but not secondary
[06:17] <Kano> cjwatson: is it a mod of live-package?
[06:17] <calc> Amaranth: ah sorry about that, yes i have no decorator
[06:17] <Amaranth> calc: multiscreen?
[06:17] <calc> Amaranth: yes
[06:18] <calc> Amaranth: mvo and I are looking into compiz dual head issue on my box
[06:18] <Amaranth> not regular dual head, multiscreen is something different
[06:18] <calc> Amaranth: it apparently dislikes xinerama and without it does weird stuff
[06:18] <cjwatson> Kano: no
[06:18] <cjwatson> Kano: live-package postdates the stuff we did
[06:18] <pitti> geser: done
[06:18] <Amaranth> calc: can you move windows between the monitors?
[06:19] <calc> Amaranth: not with xinerama disabled
[06:19] <Amaranth> so you're using multiscreen
[06:19] <Amaranth> you need to start a decorator on the second screen
[06:19] <calc> Amaranth: yes, that is what mvo requested
[06:19] <Amaranth> open a terminal over there or something and run gtk-window-decorator from it
[06:20] <Amaranth> you have two panels, two desktops, etc, right?
[06:20] <calc> Amaranth: i'm just testing out things for mvo, i have no desire to use multiscreen past just testing
[06:20] <mvo> Amaranth: it all started to figure what the problem is. and it seems the problem is xinerama , with it, compiz does not want to start (no RandR anymore)
[06:20] <Amaranth> mvo: right
[06:20] <iwj> doko: oo.o 2.2.1 seems to need more than 1GB of RAM to build.  I think this is a bug.  Do you agree ?
[06:20] <Amaranth> don't use xinerama, randr handles this stuff now
[06:20] <calc> so why doesn't RandR support Xinerama yet?
[06:20] <calc> Amaranth: how do i get non multiscreen multi head?
[06:21] <Amaranth> randr has it's own xinerama-like hints for the WM
[06:21] <mvo> Amaranth: can nvidia do randr1.2 yet?
[06:21] <doko> iwj: amd64?
[06:21] <Amaranth> i dunno, actually
[06:21] <iwj> doko: t
[06:21] <calc> lol
[06:21] <Amaranth> i don't have two monitors
[06:21] <iwj> doko: g++ -Wreturn-type -fmessage......tables.cxx // virtual memory exhausted: Cannot allocate memory
[06:21] <doko> iwj: that might be the gij prblem
[06:21] <doko> ohh
[06:22] <calc> every place i have worked in the past several years has had multihead for all developers
[06:22] <doko> iwj: I never used less than 2gb
[06:22] <Amaranth> calc: tell nvidia to fix their crappy drivers :)
[06:23] <calc> Amaranth: RandR 1.2 is like 5 months old at most
[06:23] <iwj> doko: But is it a bug if you can't build it in 1 ?
[06:23] <calc> Amaranth: its a case of linux changing fast more than a nvidia issue
[06:23] <iwj> What is textenc/tables.cxx anyway ?
[06:23] <doko> iwj: please ask our OOo maintainer ;-P
[06:23] <doko> he's listening ;)
[06:24] <Amaranth> calc: except randr 1.2 was designed with input from nvidia
[06:24] <calc> Amaranth: nvidia might support it already but if they do no one knows how to set it up since randr 1.2 is brand new
[06:24] <Amaranth> they knew it was coming for over a year before it came out
[06:24] <calc> Amaranth: oh LOL
[06:25] <Amaranth> calc: i dunno, i think there are a couple GUIs floating around that do randr stuff for you
[06:25] <Amaranth> actually i thought mvo was working on one
[06:25] <iwj> calc: Are you ? :-)
[06:25] <mvo> Amaranth: *cough* ... time ... *cough*
[06:25] <Amaranth> hehe
[06:25] <calc> iwj: scrolling up, i was talking about randr issues
[06:25] <iwj> Sorry to interrupt ...
[06:25] <Kano> cjwatson: update-config takes ages for debian-cd 1/4. is that normal?
[06:26] <cjwatson> calc: ooo should probably take priority, though ;-)
[06:26] <cjwatson> Kano: it's just calling bzr *shrug*
[06:26] <iwj> cjwatson: This a build failure in test.
[06:26] <iwj> But I suspect that if it's running out of RAM in g++ when given 1Gb on some file called `tables' it's possible that a small change might make the builds go much faster ...
[06:27] <calc> cjwatson: sorry i was reading my highlighting so didn't even notice iwj question until he mentioned my nick
[06:27] <Kano> cjwatson: i would say just the last package build in a repo would be more easy, but ok...
[06:27] <cjwatson> Kano: not my problem, take it up with the bzr people
[06:28] <cjwatson> Kano: I don't really care anyway, it's just slow for initial checkout over http
[06:29] <iwj> calc: Full log at http://autopkgtest.ubuntu.com/autopkgtest-output/gutsy/openoffice.org/
[06:29] <Kano> i thought ubuntu server are faster. at least the one with the isoimages was
[06:29] <cjwatson> Kano: bzr-over-http isn't all that quick sometimes
[06:29] <Amaranth> calc: https://launchpad.net/urandr
[06:29] <cjwatson> Kano: (also if you think about it you might come to the conclusion that cdimage/releases.ubuntu.com receives ever-so-slightly more resources than people.ubuntu.com)
[06:30] <Kano> cjwatson: maybe suggest a higher bandwidth *g*
[06:31] <cjwatson> Kano: I don't care and I don't think you should either. it's initial checkout only. please stop bugging me about it.
[06:31] <Kano> ok
[06:31] <calc> iwj: i may be looking the wrong area of log but it looks like it is working on java files when it runs out of memory there
[06:32] <calc> iwj: am i looking in the wrong file?
[06:33] <iwj> calc: Err, the log in the URL I just gave you and the log in my email do not correspond at all.
[06:33] <iwj> calc: Let me try to figure out what's going on.
[06:33] <calc> iwj: fun stuff, let me know when you have it sorted
[06:34] <iwj> OK, the log in the email is just out of date and the java problem is current.
[06:34] <calc> ok
[06:34] <iwj> The log in my email is from when it had only 256Mb.
[06:34] <iwj> Sorry to bother you.
[06:34] <calc> iwj: oh ok no problem
[06:34] <calc> iwj: doko mentioned something about gij having memory issues which might be what is showing up in this log
[06:34] <iwj> Yes.
[06:35] <iwj> I've discussed that with doko already.
[06:35] <calc> ok
[06:35] <calc> iwj: what is autopkgtest btw?
[06:36] <iwj> Automatic testing thing.
[06:36] <iwj> Err, duh.
[06:36] <iwj> It can run tests you put in your source package.
[06:36] <calc> Amaranth: that page has a dead link to the software
[06:36] <calc> iwj: oh ok :)
[06:36] <iwj> Also, it has the ability to build things (since tests might need a built tree).
[06:36] <iwj> And when the builds fail it mails me.
[06:36] <Amaranth> calc: that page has a link to a bzr branch hosted on launchpad
[06:37] <calc> Amaranth: ah
[06:38] <calc> btw ooo 2.2.1 should build in 1gb physical ram
[06:38] <calc> i have done that on my laptop many times
[06:46] <Kano> cjwatson: bzr-builddeb does not work with bzr 0.18?
[06:47] <cjwatson> Kano: I have no idea
[06:47] <Kano> well depends are that way
[06:47] <iwj> IWBNI the timeout on this IRC server were a bit longer than 0.000000001 nanoseconds.
[06:47] <cjwatson> Kano: file a bug
[06:48] <Amaranth> is bazaar.launchpad.net down or am i just having weird problems?
[06:51] <calc> http://us.download.nvidia.com/XFree86/Linux-x86/100.14.11/README/chapter-14.html
[06:52] <calc> mvo: ^
[06:52] <calc> mvo: so its a lack of randr not glx that is the issue?
[06:53] <calc> maybe i need to use twinview to get it all working
[07:01] <cjwatson> iwj: FYI I've fixed (well, worked around) your exponential growth of menu.lst upstream by making os-prober ignore the (on /dev/blah) entries. It's not at all ideal and there's still more that could be done but it's a reasonably economical workaround.
[07:23] <Kano> cjwatson: do i see it right, that you upload a rootfs and a cronjob creates the iso images then
[07:25] <cjwatson> Kano: the way it's set up, the same cron job actually triggers the rootfs build first, but yes that's roughly right
[07:26] <Kano> i see no exec of livecd.sh
[07:27] <Kano> seems to be a bit tricky to rewrite the iso generation to be executed with one command without that infrastructure
[07:28] <Kano> also usually you dont need to do that much...
[07:29] <cjwatson> Kano: it's done indirectly and you won't see the exact setup as deployed there, but it calls through to BuildLiveCD
[07:29] <cjwatson> Kano: it can't be done as one command because the CDs are all built on a single machine and obviously the livefses have to be built on one machine per architecture
[07:30] <Kano> i c, for amd64+i386 it would be possible however
[07:30] <Kano> but where are the subdirs of BuildLiveCD
[07:31] <cjwatson> I'm sure it's possible but it's not worth it
[07:31] <LucidFox> Archive admins, please move https://launchpad.net/ubuntu/+source/videotrans/1.6.0-0ubuntu1 from universe to multiverse
[07:31] <LucidFox> it build-depends on multiverse packages and thus fails to build
[07:31] <cjwatson> Kano: I already explained that
[07:31] <cjwatson> Kano: 15:32 <cjwatson> Kano: they're just standard debootstrapped chroots with the livecd-rootfs package installed, AFAIK
[07:31] <Kano> hmm
[07:32] <cjwatson> it's obviously silly to have those in the package
[07:32] <Kano> ok
[07:32] <Kano> i guess i write just a differnt code around the rootfs generation
[07:34] <Kano> have to think about it...
[07:34] <Kano> bbl
[07:38] <pitti> wwoods: FYI, I fixed the preload library now, tests pass (./test-apport lib)
[07:38] <wwoods> oh cool!
[07:38] <pitti> wwoods: so I can now play around with dropping $CORE_SIGNAL etc.
[07:39] <pitti> wwoods: oh, hmm; naturally, gdb generated core dumps do *not* have a signal in their cores
[07:48] <dholbach> siretart: can we make it so that bzr-builddeb is installable with bzr 0.18-1?
[07:48] <mvo_> calc: I don't think that is the issue, http://lists.freedesktop.org/archives/xorg/2007-June/025145.html indicates that xinerma disables randr
[07:49] <mjg59> elmo: Hi
[08:00] <wwoods> pitti: why are you using gdb to generate core dumps?
[08:01] <pitti> wwoods: what else should I use?
[08:01] <pitti> wwoods: and, even if there is a more efficient program, how would it help to poke a signal number into the core dump?
[08:10] <wwoods> pitti: I just do kill -SEGV $pid
[08:10] <wwoods> heh
[08:10] <wwoods> get a real, live core dump
[08:10] <wwoods> usually from the commandline I do: sleep 5 & sleep 1 ; kill -SEGV %1
[08:11] <pitti> wwoods: ah, from the kernel, right; but that doesn't work too well when I want to call apport from a preloaded library, or do you see a good way to do that?
[08:12] <pitti> wwoods: the idea of that library is to emulate the kernel behaviour and be a reference implementation, so I wouldn't like to bet on kernel behaviour
[08:12] <pitti> wwoods: also, the test suite exercises different ulimits (including zero)
[08:21] <wwoods> oh, um. not sure. I'll ask around though. I'm wary of emulating kernel crash dumps, though. seems like just using normal corefiles would be better
[08:22] <wwoods> even if you're generating them on purpose
[08:23] <asisak> re phanatic
[08:31] <pitti> thekorn: here?
[08:32] <thekorn> pitti: yes
[08:33] <pitti> thekorn: I played with set_status(), but it doesn't seem to work for me
[08:33] <pitti> b = Bug('124354', cookie_file='/home/martin/txt/lp-apport.cookie')
[08:33] <pitti> b.set_status(importance='Medium')
[08:33] <pitti> thekorn: is that supposed to work like this? the bug is still 'undecided'
[08:34] <pitti> thekorn: b.importance is now 'Medium', but I guess set_status() just set that member variable internally
[08:34] <pitti> thekorn: ^ ah, yes, it does
[08:36] <thekorn> pitti: it should work, the problem are bugs with many tasks
[08:36] <pitti> thekorn: right, in that case I'd need to specify one, but that bug only has one
[08:36] <thekorn> but there is a solution in my gsoc branch
[08:36] <thekorn> k
[08:36] <pitti>          full_sourcepackage+'.importance': self.importance,
[08:36] <pitti>          full_sourcepackage+'.importance-empty-marker': '1',
[08:37] <pitti> thekorn: what does that empty-marker?
[08:37] <pitti> ... do?
[08:37] <thekorn> i realy don't know, but without this it does not work
[08:38] <Kmos> 1 == undecided ?
[08:39] <pitti> {'ubuntu_apport.status': 'Fix Committed', 'ubuntu_apport.importance-empty-marker': '1', 'ubuntu_apport.importance': 'Medium', 'FORM_SUBMIT': '1', 'ubuntu_apport.sourcepackagename': 'apport', 'ubuntu_apport.status-empty-marker': '1', 'ubuntu_apport.comment_on_change': ''}
[08:39] <pitti> thekorn: this is the args dictionary; it looks pretty reasonable
[08:39] <pitti> thekorn: it figured out the source package, task, status, etc.
[08:43] <thekorn> pitti: what features of py-lp-bugs does apport use? add comments/attachments, set tags, set status, get list of bugs
[08:46] <pitti> get description, download attachments, add comment, add attachment, delete attachment, add subscriber, get bug list (by tag), get status, set/get duplicate #, add/remove tags
[08:46] <pitti> thekorn: and now I wanted to use set_status() to make bdmurray happy (bug 106379)
[08:46] <ubotu> Launchpad bug 106379 in apport "retracer should set importance of bugs" [Wishlist,Confirmed]  https://launchpad.net/bugs/106379
[08:48] <bdmurray> heh
[08:50] <bdmurray> thekorn: Is bughelper aware of assignment?
[08:50] <thekorn> pitti: ah, that's once again a cokkie problem
[08:50] <thekorn> cookie
[08:51] <pitti> thekorn: I added a p-lp-bugs task to bug 106379
[08:51] <ubotu> Launchpad bug 106379 in apport "retracer should set importance of bugs" [Wishlist,Confirmed]  https://launchpad.net/bugs/106379
[08:52] <pitti> thekorn: oh, it doesn't call self._setup_cookie()
[08:53] <pitti> thekorn: hmm, I added that, but it still doesn't work
[08:54] <pitti> thekorn: oh, forget that, it already does call it (/me blind)
[08:54] <pitti> bbl
[09:07] <Kmos> ./topic Ubuntu BugSquad | http://wiki.ubuntu.com/BugSquad | https://launchpad.net/distros/ubuntu/+bugs | Documentation: http://wiki.ubuntu.com/HelpingWithBugs | If you have been triaging bugs for a while, please apply to https://launchpad.net/people/ubuntu-qa/ - http://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad - Tomorrow is HUG DAY!
[09:07] <Kmos> :)
[09:07] <Kmos> wrong channel
[09:08] <Kmos> ups
[09:15] <thekorn> pitti: is the user with this cookie allowed to change the status of the bug?
[09:17] <thekorn> it works for me with a valid cookie-file
[09:28] <geser> pitti, Mithrandir: please give-back haskell-configfile. Thanks.
[09:37] <geser> pitti, Mithrandir: please give-back haskell-hsh. Thanks.
[09:43] <pitti> thekorn: oh, that might be a point
[09:43] <LaserJock> after a package has been excepted through NEW does it take a while to get it into the build queue?
[09:43] <LaserJock> *accepted
[09:44] <pitti> LaserJock: binary NEW: about an hour, source NEW: needs manual review, thus arbitrarily long
[09:44] <pitti> bdmurray: could you please add apport to ubuntu-qa? it's only the bot user
[09:44] <LaserJock> pitti: well, I mean the about of time between when a package is accepted through source NEW and when the binaries get built
[09:45] <pitti> geser (CC: Mithrandir): done
[09:45] <pitti> LaserJock: no, there's no human delay
[09:45] <pitti> LaserJock: and you'll see the binaries in the new queue
[09:45] <LaserJock> hmm
[09:45] <pitti> LaserJock: unless they FTBFS, of course
[09:46] <LaserJock> pitti: edubuntu-addon-meta was accepted through source NEW 40 minutes ago but there are no builds
[09:46] <LaserJock> not even anything in the queue, that I can see
[09:46] <pitti> LaserJock: ah; just give it some time then
[09:47] <LaserJock> pitti: ok, that's all I needed to know ;-)
[09:48] <pitti> thekorn: confirmed; sorry for the trouble then
[09:49] <bdmurray> pitti: done
[09:49] <pitti> bdmurray: yay, thanks
[10:52] <kmon> Hi. I would like to know if there's any plan in gutsy with regards to intel-mac's
[10:53] <kmon> I would like to help testing.
[10:53] <ogra> kmon, so just grab an image and test ;)
[10:53] <kmon> I've already installed tribe 3
[10:53] <kmon> and filed bugs
[10:53] <kmon> :)
[10:54] <ogra> what else would you want to do ?
[10:55] <ogra> (afaik)
[10:55] <kmon> that's my main concern, really
[10:55] <ogra> ah
[10:55] <ogra> now it makes sense :)
[10:55] <kmon> the bootprocess on a mac-intel with linux only is a pita
[10:55] <geser> cjwatson: gutsy has no -lowlatency versions of the kernel anymore and linux-backports-modules-2.6.22 is now stuck in depwait
[10:57] <kmon> ogra: thanks
[10:57] <evand> kmon: if you mean native EFI booting, no there are no such plans for Gutsy.
[10:58] <evand> at least none that I am aware of.
[10:58] <kmon> grub-efi package doesn't work?
[10:59] <evand> kmon: well, we don't use grub2 yet.
[11:00] <kmon> anyone knows when grub2 will replace legacy grub?
[11:01] <kmon> I think debian is going to do it for lenny...
[11:01] <kmon> but i could be wrong
[11:02] <LaserJock> kmon: well, considering when lenny is likely to be released, we have a while ;-)
[11:02] <kmon> yes, I know...
[11:03] <evand> kmon: https://blueprints.launchpad.net/ubuntu/+spec/grub2 , I'd guess at Gutsy+1, but it would be stab in the dark.
[11:03] <kmon> I hate laptops
[11:04] <kmon> ok, thanks LaserJock
[11:06] <ogra> evand, well, gutsy+1 being LTS makes that unlikely ...
[11:06] <evand> ah, good point
[11:06] <ogra> i doubt we will do stuff that could be risky in any way in gutsy+1
[11:06] <evand> lets just leave it at "sometime in the future" then
[11:07] <ogra> heh :)
[11:07] <kmon> it's a shame
[11:24] <agoliveira> kmon: I used to hate them too but I bought one beefed enough to use as a desktop and now I'm enjoying the silence :)
[11:25] <agoliveira> (with external keyboard and 20" LCD)
[11:26] <kmon> I bought this mac so I didn't buy another pc with windows (to contribute to bug#1 ;)
[11:26] <kmon> I did it before the dell deal, obiously
[11:27] <kmon> obviously
[11:39] <kmon> bye
[12:07] <cjwatson> geser: thanks, will fix