[12:36] <kozz> Kamion: thanks man
[03:23] <bluefoxicy> Ancient Debian lore once supplied black magic in the form of Sawfish or IceWM
[03:24] <bluefoxicy> Masters of this magic could use a menu option to switch between Gnome, KDE, Sawfish, IceWM, and Fluxbox without killing the programs in their session.
[03:24] <bluefoxicy> And it was good.
[03:39] <zul_> uh...ok
[03:44] <caravena> Hello, I'm finding in http://cvs.gnome.org/viewcvs/gnome-system-tools/ the glade.in of gnome-system-log. I do not find it.  Somebody knows as it is the file? 
[06:12] <robertj> any ideas on how xrandr could be improved so as not to set unsupported refresh modes? I plugged in a new monitor, edited xorg.conf, and after logging into gdm, xrandr helpfully set my old (and unsupported) res
[06:31] <bluefoxicy> doko:  ping
[06:34] <bluefoxicy> Fine I'll just stay up until pitti /joins
[06:36] <bluefoxicy> heh
[07:51] <bluefoxicy> this is not working
[08:11] <dholbach> good morning
[08:11] <jdub> morning dholbach 
[08:12] <dholbach> how's it going?
[08:13] <jdub> teh rad
[08:14] <dholbach> if i didn't know better, i'd guess you're trying to learn a new language ;)
[08:26] <simira> good morning *yawns*
[08:30] <Nafallo> morning simira :-)
[08:37] <fabbione> morning
[08:37] <Hobbsee> hi fabbione!  how goes it?
[08:37] <dholbach> hellas fabbione
[08:37] <fabbione> dholbach: do you have any idea what package is causing severe redrawing issues in edgy?
[08:37] <dholbach> fabbione: what do you mean?
[08:37] <fabbione> Hobbsee: pretty much ok i would say.. the baby is sleeping like an angel
[08:37] <fabbione> dholbach: sec.. let me take a screenshot
[08:38] <dholbach> fabbione: which video driver?
[08:38] <fabbione> dholbach: nv
[08:38] <fabbione> dholbach: it's not a video driver problem. It started before i did reboot the machine
[08:38] <Hobbsee> fabbione: yay :)
[08:38] <fabbione> and i was still using the old driver
[08:39] <fabbione> dholbach: it smells like cairo/pango or some gtk
[08:39] <dholbach> fabbione: i only know of the ati breakage and themes looking broken because they were not built with gtk 2.10 yet - but now we should have rebuilt all of them
[08:40] <dholbach> but let's wait for your screenshot
[08:40] <fabbione> http://people.ubuntu.com/~fabbione/corrupt.jpg
[08:40] <fabbione> notice URL missing and buttons without names etc.
[08:40] <fabbione> if i pass the mouse on top, they show up
[08:40] <dholbach> ah, text gone missing
[08:41] <dholbach> we had a bug about that
[08:41] <dholbach> need to dig it out
[08:41] <fabbione> dholbach: it happens on all gtk apps
[08:41] <fabbione> or something..
[08:41] <fabbione> xterm works :)
[08:41] <fabbione> but basically i can't do anything with my machine atm
[08:41] <dholbach> fabbione: do you have any idea about bug 50778? somebody in gnome land pinged me about it
[08:41] <Ubugtu> Malone bug 50778 in Ubuntu "Installer (partitioner) fails on Sun T2000 rev. 2" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50778
[08:42] <fabbione> dholbach: i wish i could read it :)
[08:42] <fabbione> dholbach: i can't read the text in FF
[08:42] <Nafallo> fabbione: w3m? :-)
[08:43] <dholbach> fabbione: and you're completely updated? because i saw that "text gone missing" bug a week ago or something
[08:43] <fabbione> dholbach: i don't have that hw.. so i have no clue. My t2000 is v1
[08:43] <dholbach> fabbione: :-/
[08:43] <fabbione> dholbach: i updated yesterday afternoon
[08:43] <dholbach> ok
[08:43] <fabbione> updating again now...
[08:43] <fabbione> just for the sake of it
[08:44] <dholbach> no, that shouldn't be it :/
[08:46] <fabbione> dholbach: nope... doesn't help
[08:46] <fabbione> dholbach: what was the package at fault for that text gone missing?
[08:46] <dholbach> i'm trying to find it in malone
[08:53] <dholbach> fabbione: I can only find bug 52445 - which is something else - I'll ask Sb once he's here - atm you could try if a different theme fixes the issue for you
[08:53] <Ubugtu> Malone bug 52445 in libcairo "after upgrade the gtk library, when using someof fonts, display is missing." [Medium,Fix released]  http://launchpad.net/bugs/52445
[08:54] <fabbione> hmmm cairo....
[08:54] <fabbione> i could also try to downgrade that
[08:55] <Burgundavia> fabbione: could we get a logging bot in #ubuntu-laptop?
[08:55] <fabbione> hey marilize 
[08:55] <marilize> Burgundavia: hey mr Burger
[08:55] <fabbione> Burgundavia: not without my workstation. Please file a bug and i will do when i am back from paternity leave.
[08:55] <Burgundavia> fabbione: sure
[08:56] <Burgundavia> marilize: 'ello
[08:57] <fabbione> dholbach: different theme makes no diff
[08:57] <dholbach> hrm :-/
[08:57] <fabbione> or am i supposed to logout/login again?
[08:57] <dholbach> no
[08:58] <dholbach> heya pitti
[08:58] <pitti> Good morning
[08:59] <fabbione> Burgundavia: make sure the bug is assigned to me
[08:59] <fabbione> dholbach: it's not libcairo either
[08:59] <Burgundavia> fabbione: nope, going to assign it to Mark ;)
[09:00] <dholbach> fabbione: did you have gtk 2.10 before? i mean - did you dist-upgrade regularly?
[09:00] <fabbione> dholbach: no i did skip the last week 100% and upgraded only yesterday
[09:00] <fabbione> dholbach: have been kind of busy :)
[09:00] <dholbach> yeah, can imagine :)
[09:00] <fabbione> i can try to downgrade gtk
[09:01] <dholbach> no no no
[09:01] <dholbach> there's too much stuff depending on it already :)
[09:01] <sivang> morning
[09:01] <dholbach> and that shouldn't be it, you must have had 2.10 before
[09:02] <fabbione> dholbach: well it downgrades fine...
[09:02] <fabbione> let me try
[09:02] <dholbach> i mean to < 2.10
[09:02] <dholbach> but i wouldn't try that
[09:02] <fabbione> doesn't help either
[09:02] <fabbione> it's a bit better
[09:03] <dholbach> afaik that was something else - you have ubuntu-desktop installed?
[09:03] <fabbione> ubuntu-desktop is already the newest version.
[09:03] <dholbach> does firefox say something if you start it from the terminal? any fancy error messages?
[09:03] <fabbione> nop
[09:04] <dholbach> hrm
[09:04] <fabbione> dholbach: i used FF but it's also xchat and other apps
[09:08] <fabbione> gonna try something
[09:08] <fabbione> brb
[09:10] <fabbione> dholbach: it's Xorg bug
[09:10] <fabbione> actually nvidia
[09:10] <dholbach> uh
[09:11] <dholbach> strange, i run 'nv' here myself
[09:11] <fabbione> nv or nvidia?
[09:11] <dholbach> nv
[09:11] <fabbione> yeah nv works
[09:11] <fabbione> nvidia doesn't
[09:11] <dholbach> ahhhh
[09:11] <dholbach> screw nvidia!
[09:11] <fabbione> the problem is that nv doesn't support multihead
[09:11] <fabbione> screw nv*
[09:12] <crimsun> fabbione: some people have 'worked around' it by using Xgl; I believe amaranth and ajmitch have experience
[09:12] <Nafallo> fabbione: I'm sure they would take patches ;-)
[09:12] <fabbione> dholbach: can you check if l-r-m has been updated since xorg-server ABI breakage?
[09:12] <fabbione> crimsun: that's probably because Xgl is still using the old ABI and it doesn't support multihead properly.
[09:13] <fabbione> Nafallo: i did send them patches.. they are in some unknown queue in bugzilla.
[09:13] <dholbach> fabbione: Jul 15, so I think not
[09:14] <Nafallo> fabbione: oh :-/. but then you have nv doing multihead locally? :-)
[09:16] <fabbione>  /ignore Nafallo*!*@* all
[09:16] <fabbione> feh
[09:16] <fabbione> ;)
[09:16] <Nafallo> :-P
[09:16] <fabbione> dholbach: i had that feeling
[09:20] <dholbach> heya mvo
[09:20] <Hobbsee> hi mvo 
[09:21] <simira> Nafallo :)
[09:21] <simira> dholbach :)
[09:21] <dholbach> hi simira :-)
[09:21] <Hobbsee> simira!  hello!
[09:22] <simira> hi Hobbsee 
[09:22] <simira> hmm...
[09:22] <simira> mvo: I suspect update-manager is stuck again. There can't have been no updates for a week, really?
[09:24] <mvo> hello Hobbsee, simira :)
[09:25] <mvo> simira: does it help if you manually click on the "check" button?
[09:27] <pitti> Riddell: I committed your latest cdbs update to bzr; btw, there was no FTBFS, it just never built (the buildds have been on manual for quite some days)
[09:27] <Hobbsee> hiya pitti 
[09:28] <pitti> Hey Hobbsee 
[09:28] <Hobbsee> pitti: which mailing list was the main uploads stuff on?  i still dont seem to have recieved email about that.  nor anything else from that list in a few days, come to think of it.
[09:28] <infinity> pitti: Err, the buildds haven't been on manual.
[09:28] <pitti> infinity: hm, you told so yesterday, didn't you?
[09:28] <pitti> infinity: '.. keep the buildds free for dapper-updates' or so?
[09:28] <infinity> pitti: Not unless I did it in my sleep.
[09:28] <infinity> pitti: Oh, that was just "not doing any mass give-backs".
[09:28] <pitti> ah, I see
[09:29] <infinity> pitti: But new uploads were being built just fine.
[09:29] <pitti> ok, then they are just lagging behind
[09:29] <infinity> They certainly shouldn't be.
[09:29] <pitti> sorry for the confusion then
[09:29] <infinity> http://librarian.launchpad.net/3801011/buildlog_ubuntu-edgy-i386.cdbs_0.4.44ubuntu4_FAILEDTOBUILD.txt.gz
[09:29] <pitti> https://launchpad.net/distros/ubuntu/+source/cdbs/0.4.44ubuntu4 <= not built for two days
[09:30] <pitti>  edgy i386   Needs building
[09:30] <infinity> It failed.  The only reason it's needs-build again is because I just did a mass give-back.
[09:30] <pitti> aaah
[09:35] <bluefoxicy> oh wtf.  -D_FORTIFY_SOURCE=1 A) does absolutely nothing without a -O level; B) acts exactly like -D_FORTIFY_SOURCE=2
[09:36] <bluefoxicy> pitti:  Is gcc modifying code going to be a problem for Edgy+1 or is it worth trying to get a look into using -D_FORTIFY_SOURCE when the time comes?
[09:36] <pitti> bluefoxicy: is fortify upstream by now?
[09:36] <bluefoxicy> pitti:  it's in Ubuntu if that's what you mean.
[09:37] <pitti> bluefoxicy: sure, can't hurt to do some research about it and play with it
[09:37] <bluefoxicy> bluefox@icebox:/tmp/x$ gcc -O -D_FORTIFY_SOURCE=1 test.c -o test
[09:37] <bluefoxicy> test.c:13: warning: call to __builtin___strcpy_chk will always overflow destination buffer
[09:37] <bluefoxicy> ^^^ except it turns strcpy() etc etc into __builtin___strcpy_chk()
[09:37] <pitti> bluefoxicy: requires some evaluation of the performance hit, of course
[09:37] <bluefoxicy> pitti: I can throw nbench at it but I don't think it'll do any good
[09:38] <infinity> pitti: We still care about performance?  This is news.
[09:38] <bluefoxicy> this is a case of "a few cycles on certain functions" and there's not good benchmarks for hitting these
[09:38] <bluefoxicy> besides you can't quantify how often "certain functions" are being executed; it winds up being THEORETICAL_MAXIMUM / 1000000
[09:38] <pitti> bluefoxicy: I don't mean 'measuring how many cycles the new functions waste', but rather 'will it make a noticeable difference'
[09:39] <pitti> in overall system performance
[09:39] <infinity> Java, mono, sandboxes, secure compilers...
[09:39] <bluefoxicy> pitti:  in overall system performance I'm rather certain it doesn't.  Throw Fedora Core 5 on your box and see if you notice (yes FC5 is all FORTIFY_SOURCE and -fstack-protector)
[09:39] <pitti> true
[09:41] <bluefoxicy> heh, maybe I could get some quantity if I could make oprofile behave.
[09:42] <bluefoxicy> I wanted to prove PIE doesn't cause a significant overall performance detriment; Theo de Raadt kept insisting it does and I wanted to prove I knew better than him *ego ego ego*
[09:43] <bluefoxicy> so I got oprofile working and measured what was happening in libraries vs in main executables.   It takes 1% more CPU to run PIE on i386; Xorg spends 5% of its time in the main executable (overall 0.05% more CPU used); while everything else uses less than 0.02% of its time in the main executable.  Total system impact 8% * 1% == 0.08%
[09:43] <bluefoxicy> infinity:  this is the impact of "secure compilers" mind you ;)
[09:44] <bluefoxicy> pitti:  oprofile is supposed to be able to track individual symbols; I may be able to do a system-wide quantification of strcpy(), memcpy(), strncpy(), strcat(), etc etc.  Count the calls, CPU percentages, do the math, and find the exact performance impact\
[09:45] <pitti> bluefoxicy: well, don't overdo it, but some field research can't hurt :)
[09:45] <bluefoxicy> I overdid it last time
[09:45] <bluefoxicy> left oprofile on, its data file grew to several gigabytes and my disk filled.
[09:45] <bluefoxicy> :)
[09:45] <bluefoxicy> problem is I have no idea how to get it to track symbols, and how to make the output useful.  I can try but if it bites me again no guarantees
[09:46] <bluefoxicy> anyway it's 4am I need sleep.
[09:53] <simira> mvo: it seems so
[10:07] <pitti> infinity: weird; cdbs' tests all work in a clean pbuilder here
[10:08] <pitti> infinity: and on my amd64 desktop, they almost all fail since automake uses INSTALL_PROGRAM_ENV for 'install -c' which is empty at the point of installation
[10:08] <pitti> so, neither reproduces the buildd situation
[10:09] <infinity> pitti: Sweet.  Want me to reproduce and investigate?
[10:09] <pitti> infinity: if you can reproduce it locally, sure
[10:09] <infinity> I'm sure I can.
[10:09] <pitti> I'll spend some time figuring out the autoconf mess
[10:16] <pitti> tsk, this can't *possibly* work...
[10:17] <pitti> make INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)' install
[10:17] <pitti> $(INSTALL_PROGRAM_ENV) $(binPROGRAMS_INSTALL) $$p $(DESTDIR)$(bindir)/$$f
[10:17] <pitti> it's clear that $(INSTALL_PROGRAM_ENV) will generate an empty string, so that 'install -c' is not called, but how on earth is that generated?
[10:21] <infinity> pitti: I get the same failure as the buildds.  Surprise, surprise.
[10:21] <pitti> infinity: can you pleasea run the test by hand and see what breaks?
[10:21] <infinity> How does one invoke them by hand?
[10:21] <pitti> cd test
[10:22] <pitti> ./autotools-1.sh
[10:22] <mvo> Kamion: can you please sync scim-thai from debian? its NEW and not yet in edgy but important for the thai people
[10:22] <pitti> or whichever test breaks
[10:22] <infinity> pitti: By hand, it works.
[10:22] <infinity> Oh, wait.  No.
[10:22] <infinity> False alarm, I'm seeing two different things.
[10:23] <infinity> What's this tar broken pipe all about?
[10:23] <pitti> infinity: I see it everywhere in edgy when building packages
[10:23] <pitti> (not only with cdbs)
[10:24] <infinity> Erm, right.  That test appears to pass, but claims a failure.  Changed output or something?
[10:24] <pitti> infinity: pkg-create-dbgsym?
[10:24] <pitti> infinity: since debhelper-2 tests -dbg creation
[10:25] <infinity> dpkg -c $WORKDIR/../cdbs-testsuite-dbg_0.1_*.deb | grep -q /usr/lib/debug/usr/bin/main || return_fai
[10:25] <infinity> l
[10:25] <infinity> Yeah, that clearly fails.
[10:25] <infinity> (edgy)adconrad@cthulhu:~/cdbs/cdbs-0.4.44ubuntu4/test$ dpkg-deb -c workdir/cdbs-testsuite-dbg_0.1_*.deb
[10:25] <infinity> drwxr-xr-x root/root         0 2006-08-07 08:23 ./
[10:25] <infinity> drwxr-xr-x root/root         0 2006-08-07 08:23 ./usr/
[10:25] <infinity> drwxr-xr-x root/root         0 2006-08-07 08:23 ./usr/share/
[10:25] <infinity> drwxr-xr-x root/root         0 2006-08-07 08:23 ./usr/share/doc/
[10:25] <infinity> drwxr-xr-x root/root         0 2006-08-07 08:23 ./usr/share/doc/cdbs-testsuite-dbg/
[10:25] <infinity> -rw-r--r-- root/root        94 2006-08-07 08:23 ./usr/share/doc/cdbs-testsuite-dbg/copyright
[10:25] <infinity> -rw-r--r-- root/root       160 2006-08-07 08:23 ./usr/share/doc/cdbs-testsuite-dbg/changelog.gz
[10:25] <infinity> The package is empty.
[10:26] <pitti> ok, I'm quite sure it's due to pkg-create-dbgsym; I'll take over then
[10:26] <infinity> Except, it shouldn't be doing anything, cause it's told not to mangle.
[10:26] <infinity> dh_strip debug symbol extraction: not doing anything since NO_PKG_MANGLE is given
[10:27] <infinity> Does it not quite do "nothing", as one would hope? :)
[10:27] <pitti> if you see that, then it is followed by exit 0...
[10:28] <infinity> Oh, it is exiting instead of doing the -dbg stuff that dh_strip would normally do, perhaps?
[10:29] <infinity> ie: It's doing a bit too much nothing? :)
[10:29] <pitti> *headdesk*
[10:29] <pitti> of course you are right
[10:29] <pitti> silly me
[10:29] <pitti> infinity: that means the recent packages haven't get stripped at all, I'm afraid
[10:30] <pitti> infinity: oh, no, just the NO_MANGLE ones
[10:30] <infinity> Right, just NO_MANGLE.
[10:30] <infinity> Which is just some test suites, and some d-i stuff.
[10:30] <infinity> And not a whole lot else, afair.
[10:30] <pitti> yep, the rest of exits generate FTBFS
[10:35] <pitti> Kamion: hm, I don't get sound with the current dapper ppc/alternate install; did you see this as well? (snd-powermac was not loaded)
[10:37] <pitti> Kamion: the module is not in /etc/modules; I don't have the previous installation any more, but I'm pretty sure it must be added there
[10:43] <pitti> Kamion: (bug 55479 filed)
[10:43] <Ubugtu> Malone bug 55479 in debian-installer "no sound with dapper point release candidate powerpc" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55479
[10:46] <mvo> Kamion: can you also please sync thaixfonts from debian? this is also not available yet in edgy
[10:49] <pitti> infinity: ok, new pkg-create-dbgsym uploaded, confirmed that cdbs works fine with that
[11:01] <pitti> I go offline for some parallel 6.06.1 candidate test installs
[11:25] <sabdfl> BenC, Kamion: OOPS with current dapper kernel inserting PCMCIA card reader with compactflash card
[11:33] <pygi> sivang, poke poke
[11:33] <sivang> pygi: hi
[11:33] <pygi> hi, you have time sivang ?
[11:34] <sivang> pygi: answering in PM
[11:47] <ogra> Kamion, i have a minor regression in the dapper installer here ... i cant switch consoles anymore ...
[11:47] <ogra> (d-i that is)
[11:53] <Kamion> mvo: please file bugs and subscribe ubuntu-archive - I'm on holiday for the next two weeks
[11:54] <Kamion> ogra: worked perfectly well for me - does it stop working at some point in the installer?
[11:54] <dholbach> Kamion: Have some nice holidays!
[11:54] <Kamion> thanks - just around low-level today to do the point release
[11:55] <ogra> Kamion, i just wanted to check the chrot buildlogs for ltsp and noticed it... no idea if it worked before, i'll check with the next test
[11:55] <Kamion> sabdfl: does original dapper oops too?
[11:55] <sabdfl> Kamion: quite possibly
[11:55] <sabdfl> it did with a different cflash card, yes
[11:55] <sabdfl> mdz has that one for testing
[11:55] <Kamion> ok, thanks
[11:55] <lifeless> doko: is edgy going to do the python transition ?
[11:55] <lifeless> or +1 ?
[11:55] <Kamion> lifeless: edgy mostly already has
[11:56] <lifeless> oh, awesome
[11:56] <lifeless> so I can package a new thing with python-central ?
[11:56] <Kamion> yes, please do
[11:56] <lifeless> yippee
[11:56] <Kamion> I've generally been rejecting or complaining about things in NEW that don't follow the new python policy
[11:56] <Kamion> because we're going to need it to be in place when python2.5 arrives
[11:57] <doko> lifeless: yes, and test with 2.5 as well ;)
[11:57] <lifeless> all my packages have been updated in debian, courtesy of the nice NMU storm
[11:57] <lifeless> mmm, maybe not all, but close to
[12:03] <mvo> Kamion: ok, have a nice vacation!
[12:09] <Fujitsu> infinity, are you around?
[12:11] <Kamion> hmm, 55479 is potentially an interesting regression
[12:12] <Kamion> I can see why that *might* have regressed
[12:12] <ogra> bug 55479
[12:12] <Ubugtu> Malone bug 55479 in debian-installer "no sound with dapper point release candidate powerpc" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55479
[12:12] <Kamion> I made some register-module changes for sparc
[12:12] <ogra> i can confirm/reject in 10 mins :) ppc test is nearly through
[12:13] <Kamion> don't reject
[12:13] <ogra> nah ...
[12:13] <Kamion> deny if you like :)
[12:13] <ogra> :)
[12:13] <ogra> wron vocabulary ;)
[12:13] <ogra> *wrong as well
[12:13] <Kamion> pitti: 11:11 < Kamion> hmm, 55479 is potentially an interesting regression
[12:13] <Kamion> 11:12 < Kamion> I can see why that *might* have regressed
[12:13] <Kamion> 11:12 < Kamion> I made some register-module changes for sparc
[12:14] <pitti> Kamion: thanks for the heads-up
[12:14] <Kamion> OH
[12:14] <Kamion> if [ "$ADD_TO_INITRD" = 1 ] ; then
[12:14] <Kamion>         QUEUEFILE=$QUEUE/$MODULE.load
[12:14] <Kamion> else
[12:14] <Kamion>         QUEUEFILE=$QUEUE/$MODULE.initrd
[12:14] <Kamion> fi
[12:14] <Kamion> spot the logic error
[12:15] <Riddell> pitti: cdbs looks failed to me https://launchpad.net/distros/ubuntu/edgy/+source/cdbs/0.4.44ubuntu4
[12:15] <Kamion> we need to rebuild alternate install CDs for that - I'll fix
[12:15] <Kamion> oh, shit, and I think we need to rebuild live CDs too :(
[12:15] <Kamion> ubiquity uses register-module
[12:16] <Kamion> we don't need a full retest of live CDs though, just boot-and-install one option
[12:16] <Fujitsu> Ouch.
[12:17] <Kamion> pitti: thanks for your eagle eyes
[12:17] <pitti> Riddell: I figured it out with infinity, it was due to pkg-create-dbgsym
[12:17] <pitti> Riddell: I fixed that, once it's in the archive, cdbs just needs a give-back
[12:18] <Riddell> thanks pitti 
[12:19] <Chipzz> just wondering... is anything happening with grumpy?
[12:19] <Chipzz> or is that just a draft?
[12:20] <pygi> raphink, hey hey
[12:21] <raphink> hi pygi
[12:23] <Kamion> oh, wait
[12:23] <Kamion> we don't need to rebuild ubiquity - I never updated it to the broken version of debian-installer-utils
[12:23] <Kamion> yay
[12:24] <Kamion> pitti: also, sparc will thank you - I think that's why Dave Miller's install test failed
[12:25] <Kamion> I was too tired to notice why at the time, I guess
[12:25] <Kamion> Fujitsu: please don't assign ubuntu-archive to bugs
[12:25] <Kamion> Fujitsu: by a quirk of malone, doing that takes it *off* the list we normally look at
[12:25] <Kamion> Fujitsu: having ubuntu-archive subscribed is quite sufficient
[12:26] <Fujitsu> Kamion, sorry. I forgot I was meant to subscribe, not assign.
[12:26] <Kamion> np, fixed
[12:26] <Fujitsu> Thanks.
[12:41] <ajmitch> fabbione: your text problem is a definite nvidia driver problem that is known - apparantly some of the changes in the x.org 7.1 ABI was in the glyph ABI
[12:49] <Kamion> ogra: have you or your team tested any of the Edubuntu live CDs for dapper.1? Testing/Current
[12:49] <ogra> not yet ... working on it 
[12:49] <Kamion> ogra: the Edubuntu install CDs will need to be rebuilt due to 55479, but it's probably reasonable to test them anyway; the delta for the fix is very small
[12:49] <ogra> i'm nearly done with the istal CD tests so far
[12:49] <Kamion> ok
[12:50] <ogra> live is going a lot faster here ... :)
[12:50] <ogra> 20mins vs. >1h
[01:03] <pitti> infinity: pkg-create-dbgsym 0.7 is in the archive; can you please give-back cdbs?
[01:04] <ogra> does the sync commandline tool trigger the same kind of syncing as umount does ?
[01:04] <ogra> or is that different ? 
[01:05] <ogra> i.e. could i force a sync on a vfat filesystem through calling sync ? 
[01:05] <pitti> ogra: unmount only syncs the device, sync syncs *all* buffers (on all devices)
[01:05] <ogra> pitti, yep, thats something i grokked already ...
[01:05] <pitti> sync vfat seems to work
[01:05] <ogra> the question is if i can trick a vfat device to have the contents in sync 
[01:05] <ogra> cool
[01:06] <pitti> ogra: you can remount readonly to be safe
[01:06] <pitti> ogra: with just 'sync' there might always be processes which still write to it
[01:06] <ogra> no i cant if it just unlug a device ;)
[01:06] <ogra> *unplug
[01:07] <ogra> i'm trying to implement ltspfs without all the lbus communication, since its not really needed ... ltspfs unmounts if there is no rw traffic, but doesnt show its unmounted to the user .... i want to replace that functionallity through a sync call
[01:08] <pitti> Kamion: I guess you will trigger new dapper/alternate images soon?
[01:08] <ogra> (calling sync instead of mount/umount all the time)
[01:13] <pitti> Kamion: so we deliberately ship 6.06.1 with OO.o 2.0.2 now?
[01:15] <bbrazil> ogra: you want the 'sync' mount option
[01:16] <pitti> bbrazil: no, he doesn't really
[01:16] <pitti> sync mount option sucks performance-wise
[01:16] <bbrazil> yes, but it would appear to be what he asked for
[01:18] <pitti> the 'flush' option would be appropriate here as well (http://www.ussg.iu.edu/hypermail/linux/kernel/0512.3/0050.html)
[01:25] <ogra> bbrazil, sync mount doesnt work with vfat devices due to a kernel regression afak
[01:25] <ogra> i dont really care about performance though
[01:25] <pitti> ogra: sync works, but not perfectly, and it's not a regressions
[01:25] <pitti> s/s$//
[01:26] <ogra> oh, ok
[01:26] <ogra> what does "not perfectly" mean ? 
[01:26] <pitti> ogra: the problem is that we do not speak about factor 2 here - we speak about factor 10 to 100, and that does make a difference :(
[01:26] <pitti> ogra: it seems that a small amount of the writeback cache is not synced even with the 'sync' option
[01:26] <ogra> ah, k
[01:27] <pitti> ogra: i. e. if you mount sync, write a large file, then unmounting still writes stuff on the media
[01:27] <pitti> ogra: but it's only a tiny bit, much less than the 'one-minute writeback phase' with async
[01:27] <ogra> thats bad ... i need to be able to just rip out the device with as little dataloss as possible
[01:28] <ogra> (preferably with none at all ;) )
[01:28] <pitti> ogra: then you can really only use the sync option and live with a really sucking performance (not even to mention the drastically increased hard drive wearout)
[01:28] <pitti> ogra: why can't you unmount properly?
[01:28] <ogra> pitti, because i have no access to the actual machine ...
[01:29] <ogra> the trick the ltsp guys use it to cache the content on the client side and to unmount on the server side if theere was no activity for 5 seconds
[01:30] <ogra> so for the user the system pretends its stil mounted which in fact it isnt on the thin client 
[01:30] <ogra> s/which/while/
[01:30] <ogra> as soon as a new access happens, the device gets mounted again
[01:30] <Kamion> pitti: trigger> yes, but not until I've rebuilt debian-installer against the fixed debian-installer-utils
[01:30] <Kamion> pitti: OOo> yes, 2.0.3 had some regressions
[01:31] <ogra> argh
[01:31] <pitti> ogra: hm, why are you so concerned about unmounting file systems on the server? or do you mean 'file systems on the client side', like usb sticks?
[01:31] <ogra> gnome-settins-daemon spills an error on the dapper update cd ....
[01:31] <ogra> and the desktop doesnt come up at all ... :/
[01:32] <ogra> pitti, yeah
[01:32] <pitti> funny, I had this as well, until I noticed that I accidentially burned the edgy CD :)
[01:32] <ogra> (the ltspfs "server" runs on the thin client :) )
[01:32] <pitti> ah
[01:33] <ogra> in the ltsp they have a complicated reoimplementation of dbus i'd like to avoid completely ...
[01:33] <ogra> which does that mount/umount stuff 
[01:33] <pitti> ok, back to CD testing. bbl
[01:33] <ogra> in ubuntu i can just mount/umount -l from udev scripts ... no need for extra complication
[01:35] <ogra> hmm, i didnt burn the edgy CD ...
[01:36] <ogra> console says 6.06.1
[01:36] <ogra> and lsb_release agrees
[01:36] <ogra> hmm, .xsession-errors is full of alsa errors ...
[01:45] <ogra> Kamion, seems i have no loopback device over here on 6.06.1
[01:46] <ogra> argh
[01:46] <ogra> ok, its the old bug with wireless devices where no essid was set...
[01:55] <ogra> gnome-settings daemon doesnt work on th eliveCD either :(
[01:56] <ogra> seb128, dholbach, did you test the new dapper packages ?
[01:56] <seb128> ogra: for what?
[01:57] <ogra> gnome-settings-daemon doesnt start on any of my 6.06.1 CDs here
[01:57] <ogra> neither live nor install
[01:57] <seb128> ogra: dapper-updates didn't get a new gnome-control-center for 7 weeks or something like that
[01:57] <Kamion> can somebody else confirm/deny that?
[01:57] <seb128> I've no issue on my dapper installation
[01:58] <Kamion> and please clarify whether that's just a single architecture or all architectures
[01:58] <seb128> but I didn't try 6.06.1 CDs (yet)
[01:58] <Kamion> I didn't notice any errors from gnome-settings-daemon in my tests
[01:58] <ogra> seb128, "Moniker has unknown moniker prefix"
[01:58] <seb128> ogra: is that ltsp?
[01:58] <ogra> no
[01:58] <seb128> ah
[01:58] <Kamion> and I have tested on all architectures
[01:58] <ogra> the regular CDs
[01:58] <seb128> that's the "clock is not correctly set" bug
[01:58] <ogra> *sigh* 
[01:58] <ogra> ok
[01:58] <Kamion> oh, ibook thinks it's 1904? that would explain it
[01:59] <ogra> right i'm in 1904 again
[01:59] <seb128> that's not a regression
[01:59] <seb128> that bug is here for ages now
[01:59] <ogra> Kamion, sorry for the adrenaline ...
[02:00] <ogra> seb128, yes, but i didnt think of looking for exactly that one ...
[02:00] <seb128> hehe
[02:00] <ogra> after i tricked myself with the missing essid again already :)
[02:03] <Kamion> ogra: no worries
[02:03] <Kamion> damn, missed the publisher with debian-installr
[02:03] <Kamion> +e
[02:20] <Kamion> happy to debug why given /var/log/partman
[02:21] <pitti_live> Kamion: chinstrap:~pitti/partman
[02:22] <pitti_live> Kamion: I tried 'small swap + big ext3', 'small swap + big vfat', and on powerpc the additional mandatory bootstrap partition
[02:24] <pitti_live> Kamion: ah, now it seems to work with vfat on powerpc
[02:25] <Kamion> powerpc doesn't have the same annoying partition table limitations
[02:25] <fabbione> ajmitch: so it seems
[02:26] <ajmitch> fabbione: only reliable workaround is to disable RenderAccel, which doesn't seem to impact performance
[02:26] <pitti_live> Kamion: right, but with just one swap and one ext3, autoresize should be possible on amd64, too? ISTR that I used this configuration earlier, but TBH I'm always a bit confused about autoresize
[02:27] <fabbione> ajmitch: or switch to nv :)
[02:27] <Spads> zul: ping
[02:27] <zul> Spads: just got up :)
[02:28] <Kamion> pitti_live: it's trying, but libparted is saying that that partition isn't resizable
[02:28] <Kamion> perhaps it's dirty?
[02:28] <ajmitch> fabbione: if only it were that easy, for us that use dualhead or more :)
[02:28] <Spads> zul: haha, you EST?
[02:28] <ajmitch> morning zul 
[02:28] <zul> yep
[02:28] <Kamion> if you search for resize_use_free in the partman log and look down a bit, you'll find this (excerpted) for your swap partition:
[02:28] <pitti_live> Kamion: I created the partitions, rebooted, mkfs.ext3, and then started ubiquity (without another reboot)
[02:28] <Kamion> parted_server: Read command: GET_RESIZE_RANGE
[02:29] <Kamion> parted_server: OUT: 4096 1110380544 1110380544
[02:29] <Kamion> and this for your ext3 partition:
[02:29] <Kamion> parted_server: Read command: GET_RESIZE_RANGE
[02:29] <Kamion> parted_server: OUT:
[02:30] <pitti_live> ok, so maybe I should have rebooted another time
[02:30] <Spads> I suppose EDT now
[02:30] <Kamion> in fact, that happens when ped_file_system_open() fails
[02:30] <Kamion> or rather, probe succeeds but open returns NULL
[02:30] <Kamion> you may find a complaint in syslog about it or something?
[02:31] <Hobbsee> Kamion: sorry to be a pain, but when is the knot 2 planned for release?
[02:31] <Kamion> it could be a geometry problem
[02:31] <Kamion> Hobbsee: I'm now on holiday and only here to do the dapper point release, so I don't expect I'll be doing it after all
[02:32] <Kamion> Hobbsee: mdz/infinity are the people from the release team who're around this week
[02:32] <Hobbsee> Kamion: ah okay.  enjoy your holiday :)
[02:32] <Hobbsee> Kamion: fair enough
[02:32] <pitti_live> Kamion: /lib/partman/recipes.sh: line 31: local: `-': not a valid identifier
[02:32] <pitti_live> /lib/partman/recipes.sh: line 114: local: `-': not a valid identifier
[02:32] <Kamion> pitti_live: parted hasn't changed since dapper, so it seems unlikely to be a regression
[02:32] <pitti_live> Kamion: ^ this is unrelated?
[02:32] <Kamion> pitti_live: that's known and harmless
[02:32] <pitti_live> Kamion: right, I don't think it's a regression either
[02:32] <pitti_live> I just wanted to test all combinations
[02:33] <pitti_live> but it works on i386 and powerpc, so I think it should work here, too
[02:33] <Kamion> at least, I *think* it's harmless - it's a difference between busybox sh and bash
[02:33] <Kamion> pretty certain that that couldn't possibly affect resize_use_free, though
[02:34] <pitti_live> Kamion: with the current test matrix, what's your feeling with the ubuntu coverage?
[02:34] <Kamion> it doesn't cause partman-auto to crash, but it is possible that it could cause incorrect semantics; however IIRC I looked into it and decided it was OK
[02:34] <fabbione> ajmitch: that did the trick
[02:35] <Kamion> pitti_live: I think it's sufficient now (thanks for doing OEM!); we'll just need a quick retest with the respun alternate/server CDs
[02:35] <pitti_live> Kamion: I'll test amd64/oem, but I don't want to waste too much time with testing all possible combinations of (normal,oem,server) x (auto-resize, erase, custom)
[02:35] <Kamion> pitti_live: I wouldn't worry about it
[02:35] <Kamion> literally three lines in oem have changed
[02:35] <Kamion> and those are architecture-independent
[02:35] <pitti_live> ok, so I could spare the time?
[02:36] <Kamion> the partitioner has also not changed
[02:36] <Kamion> yeah, I don't think it's productive to retest things we know haven't changed
[02:36] <pitti_live> ok, then I just test this amd64/desktop/erase and finish the ppc/desktop/resize and call it a testing day
[02:37] <Kamion> sounds good; but if I could persuade you to test the rebuilt powerpc/alternate when that's done, I would appreciate it
[02:37] <Kamion> since you discovered the bug
[02:37] <pitti_live> oh, sure
[02:37] <pitti_live> then I can already reinstall my desktop box with edgy
[02:38] <pitti_live> ok, rebooting, brb
[02:52] <Riddell> rodarvus: any plans to fix the xinit install problem?
[02:52] <Riddell> I'm not sure if Xsession man page should be in xinit or xorg
[02:53] <rodarvus> Riddell, yes, I'm working on it right now
[02:54] <rodarvus> (strangely it didn't happend on my local test build)
[02:54] <Riddell> it'll leave you to it then :)
[02:54] <Riddell> I'm getting it on my chroots
[03:28] <tepsipakki> what is the correct prosedure to propose a package for dapper-updates? I know how to request a backport
[03:30] <Kamion> subscribe ubuntu-release to some appropriate bug report
[03:31] <tepsipakki> kamion: thanks
[03:31] <tepsipakki> I was thinking of nfs-utils, but maybe it has changed too much for -updates..
[03:34] <Kamion> -updates should be patches addressing individual bugs, not complete backports of packages
[03:35] <tepsipakki> so backports it is, then ;)
[03:35] <Kamion> if you can isolate patches that fix particular problems, those can certainly be considered for -updates
[03:39] <tepsipakki> ok I'll try and see. nfs-utils was practically unmaintained for a year, but it has progressed a lot since (and a vast number of debian bugs closed)
[03:39] <tepsipakki> so isolating patches might be difficult
[03:39] <Chipzz> could we include nfs-common in the default install btw?
[03:40] <Chipzz> nfs mounts do not work without it
[03:42] <rodarvus> thats most interesting: our old 'xinit' had an old debian/xsession directory, containing stuff which was later moved to x11-common
[03:42] <rodarvus> but (for unknown reasons) these files apparently weren't present on old version of xinit
[03:43] <rodarvus> when I updated xinit last week (only a minor upstream release with fixes to startx.c), these files were picked up and packaged during the build process
[03:45] <rodarvus> anyhow
[03:45] <rodarvus> Riddell, xinit is uploaded, thanks
[03:45] <Riddell> rodarvus: you rock
[03:55] <rodarvus> Kamion, whats the current situation for uploads to dapper-updates?
[03:55] <rodarvus> I mean, can I upload a (non-security) update of xorg-server?
[04:00] <bddebian> Howdy
[04:01] <raphink> hi
[04:01] <raphink> where can I find infos about the way seeds work?
[04:01] <raphink> in ubuntu
[04:09] <janimo> raphink: some info is at https://wiki.ubuntu.com/SeedManagement
[04:09] <raphink> thanks janimo :)
[04:21] <sivang> anyone has idea what happend to emacs's fonts with edgy?
[04:44] <ogra> Kamion, apart from the known stuff on ppc are all eubuntu install CDs good
[04:44] <ogra> *edubuntu
[04:47] <janimo> Kamion: Xubuntu desktop CD 20060806.1 good as well
[04:55] <ogra> with a burner app
[04:55] <ogra> and a CD writer device :)
[04:55] <Nafallo> rightclick -> burn? :-P
[04:56] <ThunderStruck> ogra: it will only allow me to burn as root. cdrecord permissions cant be changed (so it said in k3b) i tried with k3b gnomebaker and natilus
[04:56] <ogra> strange are you in the right groups for the device ? 
[04:56] <ogra> works flawless here with nautilus
[04:56] <ThunderStruck> should be but hold on let me check
[04:57] <ThunderStruck> im in the cdrom group
[05:00] <pitti> ThunderStruck: I have the same effect in current edgy; the dapper version works flawlessly
[05:00] <pitti> ThunderStruck: this is on my list of 'things to check out'
[05:01] <ThunderStruck> ok ty pitti  so its edgy not me
[05:01] <pitti> ThunderStruck: right, it's a long-standing upstream bug
[05:01] <ThunderStruck> ok cool ty
[05:01] <ogra> pitti, i just saw bug buddy again, wasnt your bug tool supposed to override that ? 
[05:02] <pitti> ogra: no, it won't/can't
[05:02] <ogra> ah, k
[05:02] <ogra> so we'll stay with bug buddy for all gnome apps ? 
[05:02] <pitti> ogra: if we want to use apport for everything, we have to remove bug-buggy
[05:02] <hussam> I just found this. https://lists.ubuntu.com/archives/edgy-changes/2006-August/003472.html
[05:02] <pitti> bug-buddy, even :)
[05:02] <pitti> ogra: no, probably we'll remove it
[05:02] <hussam> will there be a openoffice 2.0.3 update for dapper?
[05:02] <ogra> ah, cool
[05:10] <mdke> hushave a look on the -devel list about OOo packages for dapper
[05:10] <mdke> ah, damn he has left
[05:15] <Kamion> rodarvus: you can upload it, but (unless you argue persuasively) I'd prefer not to accept it until after the point release is done
[05:16] <Kamion> ogra: great, thanks
[05:16] <Kamion> ogra: can you mark your tests on Testing/Current please?
[05:16] <Kamion> janimo: great, thanks
[05:18] <pitti> argh, setting up edgy is such a PITA :/
[05:19] <tepsipakki> kamion: is #55509 too late for 6.06.1?
[05:19] <tepsipakki> bug 55509
[05:19] <Ubugtu> Malone bug 55509 in apt-setup "dapper: if multiverse is enabled, add it also to security" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55509
[05:19] <Kamion> tepsipakki: yes, I think so
[05:19] <rodarvus> Kamion, don't worry, I'll upload it later, then - thanks!
[05:20] <tepsipakki> Kamion: ok, np
[05:20] <Kamion> it can go in edgy, but doesn't seem enough of a showstopper to hold the boat back on 6.06.1 now
[05:20] <tepsipakki> of course not
[05:24] <pitti> Kamion: I need to leave soon for supermarket/dinner/Taekwondo; do you plan to generate new alternates today? If so, I will test this tonight, otherwise I won't bother getting to my computer again after sports
[05:26] <Kamion> pitti: yes, I do, but I need to wait for the end of the publisher run currently in progress
[05:34] <pitti> ok, cu later
[06:04] <Zdra> is it possible to have .deb files of builded packages that hasn't yet be published ? for example this package on i386: https://launchpad.net/distros/ubuntu/edgy/+source/cohoba/0.0.2-0ubuntu1
[06:13] <Kamion> Zdra: no, sorry
[06:14] <Kamion> Zdra: I've processed cohoba through the NEW queue now though, so it should be on the mirrors in about an hour and a half
[06:15] <Kamion> dholbach: please make cohoba conform to the new python policy
[06:15] <Zdra> Kamion: ok thanks
[06:16] <dholbach> Kamion: will do
[06:23] <azeem> will Ubuntu have a presence at the Systems expo in Munich this fall?
[06:40] <co1> rodarvus the xinit patch unfortunately donsn't work, Xseesion.options.5.gz is also in x11-common. Can you reopen that bug?
[06:42] <rodarvus> co1, I don't have Xsession.options.5.gz on x11-common, what version of this package do you have?
[06:43] <co1> rodarvus:  xinit (1.0.2-0ubuntu2)
[06:43] <rodarvus> co1, I mean, version of x11-common
[06:44] <rodarvus> rodarvus@wakko:~/canonical/code/merges/seven-dot-one/xorg-server/xorg-server-1.1.1/debian/patches$ dpkg -s x11-common | grep ^Version
[06:44] <rodarvus> Version: 1:7.0.22ubuntu7
[06:44] <rodarvus> rodarvus@wakko:~/canonical/code/merges/seven-dot-one/xorg-server/xorg-server-1.1.1/debian/patches$ dpkg -S Xsession.options.5.gz
[06:44] <rodarvus> xinit: /usr/share/man/man5/Xsession.options.5.gz
[06:44] <rodarvus> rodarvus@wakko:~/canonical/code/merges/seven-dot-one/xorg-server/xorg-server-1.1.1/debian/patches$
[06:45] <dholbach> Kamion: fixed it
[06:45] <Kamion> dholbach: thanks
[06:45] <dholbach> Kamion: thank YOU
[06:47] <co1> rodarvus: x11-common..22ubuntu7
[06:48] <rodarvus> co1, please paste in a /msg window the contents of "dpkg -L x11-common"
[06:49] <rodarvus> also dpkg -s x11-common
[06:52] <rodarvus> co1, I think I found it, thanks
[06:55] <co1> rodarvus: sorry i'am a little bit lame :-(, did you need more informations?
[06:57] <rodarvus> no, actually you are correct. I have just uploaded xinit_1.0.2-0ubuntu3
[06:58] <rodarvus> I still wonder why my version of x11-common hasn't these manpages installed
[06:58] <rodarvus> I also wonder why our old xinit packages wasn't installing the manpages (the rules to install them are on the package)
[06:59] <rodarvus> my changes to xinit were only a new upstream release, I didn't touched the debian/ infrastructure
[07:02] <Kamion> argh, I've been building edgy images, not dapper ones
[07:02] <Kamion> sigh
[07:04] <LaserJock> how does ubiquity know what to install? does it use the seeds?
[07:06] <jdub> LaserJock: ubiquity installs the livecd image, and the removes stuff :-)
[07:06] <LaserJock> hmm
[07:06] <LaserJock> via filesystem.manifest-desktop ?
[07:07] <Kamion> yes
[07:08] <Kamion> removes ((filesystem.manifest - filesystem.manifest.desktop) - anything-explicitly-kept)
[07:08] <Kamion> where anything-explicitly-kept includes stuff like language packs for the selected language
[07:08] <Kamion> also removes kernels that aren't for your subarchitecture (not relevant on i386, but is relevant on powerpc)
[07:09] <LaserJock> Kamion: thanks
[07:09] <Kamion> filesystem.manifest-desktop is basically just some dpkg-query invocation just after the desktop is installed
[07:10] <Kamion> and before the live seed is installed
[07:10] <LaserJock> interesting
[07:13] <Kamion> the hardest bit's the python-apt code to do the removal with progress and stuff, really. the logic is very simple.
[07:14] <Kamion> see scripts/install.py:remove_extras() in the ubiquity source
[07:14] <Kamion> pitti: Ubuntu alternate 20060807.1 ready for testing; others are on their way
[07:35] <desrt> pitti; hello, goodbye, hello, goodbye
[07:36] <mvo> iwj: I think we can close bug #19834, we have freetype 2.2.1 now in edgy that should be ABI compatiable with 2.1.7. if you don't mind I will close it
[07:36] <Ubugtu> Malone bug 19834 in freetype "gworkspace.app: Loader error when launching GWorkspace" [Unknown,Fix released]  http://launchpad.net/bugs/19834
[08:58] <dholbach> good night everybody
[09:23] <Surak> Hello
[09:24] <Surak> I have a strange bug. The machines containing a intel integrated graphics won't boot if there's a nvidia agp card plugged on. It's bug #55104
[09:24] <Ubugtu> Malone bug 55104 in linux-image-amd64-generic "panic/lock/restart on dapper-amd64 if there's intel integrated video AND a nvidia card at the same time" [Untriaged,Confirmed]  http://launchpad.net/bugs/55104
[09:26] <Surak> One solution would be to detect the presence of both hardware and blacklist the intel_agp module. But at the time you can do this, the hard drive is still mounted as read-only. So what could be done? Anyone?
[09:29] <mjg59> You can do mount / -o rw,remount
[09:34] <Surak> This bug prevents these kind of machines from booting. To prevent creating another script at boot, a solution is to blacklist intel_agp always. This would make 3d on machines without the nvidia useless. What would the best thing to do?
[09:34] <mjg59> Fix the nvidia driver
[09:35] <Surak> so the best thing is to send the bug upstream? This is happening with stock dapper & edgy live cds.
[09:36] <mjg59> It sounds entirely like an nvidia bug
[09:36] <mjg59> And, sadly, we don't have the source code to fix it
[09:38] <Surak> I didn't know that live cds were being shipped with nvidia's closed source module.
[09:39] <msikma> Hi guys
[09:39] <msikma> I'm a participant of the Ubuntu art team and was wondering if there are any developers here willing to volunteer to help us out with some UI building.
[09:40] <msikma> (Not right now, but in the near future.)
[09:40] <msikma> We've got some nice stuff going down, but it's more useful actually being usable in the system as opposed to just being an uploaded PNG. :)
[09:43] <Surak> mjg59: ain't the nvidia modules on live cds the gpl ones? The package which it belongs is the linux-image-amd64-generic
[09:43] <mjg59> saispo: Which nvidia modules?
[09:43] <mjg59> Erm
[09:43] <mjg59> Surak: Which nvidia modules?
[09:44] <Kamion> Surak: linux-image-amd64-generic is just a metapackage with no content, by the way, which is why I reassigned to linux-source-2.6.15. Please file Dapper kernel bugs on the latter in future so that they actually get seen by the right people
[09:45] <Surak> Kamion: this is still a bug on today's edgy. Should I post it twice?
[09:45] <Kamion> (linux-image-amd64-generic -> linux-meta source package which is no more useful)
[09:46] <Kamion> Surak: I think the kernel people are capable of shifting patches around for themselves
[09:46] <mjg59> Surak: There are no gpled nvidia modules that would be loaded in this situation
[09:46] <Kamion> Surak: but if you want, open a new task on linux-source-2.6.17, not a new bug; you do this by selecting "Also affects: Distribution ..." on the bug page
[09:47] <rodarvus> mvo, note that freetype 2.2.1 is API compatible with 2.1.7 only to a point (if you use only public headers)
[09:47] <Kamion> Surak: oh, and furthermore, if it's the nvidia kernel driver, then that's actually linux-restricted-modules-2.6.{15,17}
[09:47] <rodarvus> I also believe these changes made it ABI incompatible with 2.1.7 (again, if you use non public headers)
[09:48] <Kamion> rodarvus: I think one of the problems was that functions were public in 2.1.7 that shouldn't have been
[09:48] <Kamion> at least that was my understanding after trawling through some massive bug report on the subject
[09:49] <rodarvus> Kamion, indeed, they shouldn't be public
[09:49] <Surak> mjg59: I don't know what nvidia stuff is loaded at livecd's boot. What I noticed is blacklisting intel_agp makes the machines work. As it locks quite early without it, I don't know which nvidia module could be the culprit.
[09:49] <rodarvus> but many projects used these functions: X, OpenOffice.org, pango (?), etc
[09:49] <Kamion> if blacklisting intel_agp makes it work, why is it an nvidia bug not an intel_agp bug?
[09:50] <Surak> I didn't say it is.
[09:50] <rodarvus> mjg59, Kamion: I might be wrong but couldn't this be a bug in X pci detection?
[09:50] <mjg59> Kamion: Because the nvidia driver likes poking with AGP registers even when there's already a driver bound to it
[09:51] <mvo> rodarvus: you refer to the gworkspace.app bugreport? at least that particular problem seems to be fixed in edgy with the debian merge
[09:51] <mjg59> I guess the alternative is that intel_agp is broken on 64-bit and explodes when the nvidia driver tries to initialise it
[09:51] <rodarvus> I'll upload a new version of xorg-server in a few hours (as soon as I finish test-building it locally), which has a fix for X pci detection
[09:51] <mjg59> But you'd expect that to happen with the intel graphics as well, then
[09:52] <rodarvus> mvo, no, I only meant to talk about freetype abi itself :)
[09:52] <rodarvus> (actually, I didn't even read this bug)
[09:52] <mvo> rodarvus: heh :) ok
[09:52] <mjg59> Ok.
[09:53] <mjg59> Now that i386 is using vesa for the usplash stuff, loading vga16fb on boot is probably unhelpful.
[09:53] <mjg59> How would people feel about me removing that?
[09:53] <crimsun> go for it
[09:56] <Surak> mgj59: what could be done then? If we can't fix the driver, disabling it (or nvidia_agp) is the thing to do. But how to make this become a default behavior for this specific hardware combination?
[09:57] <mjg59> Surak: nvidia_agp isn't for nvidia cards. It's for nvidia motherboards.
[09:57] <mjg59> It won't be getting loaded here.
[09:58] <Surak> sorry, I mean intel_agp
[09:58] <Surak> typo
[09:58] <mjg59> By default, the nvidia driver isn't used or loaded
[09:59] <mjg59> So it's not a problem on a cleanly installed system
[09:59] <mjg59> (Assuming that the behaviour is as described in the bug)
[10:00] <Surak> Then it's not the nvidia module the culprit.
[10:00] <mjg59> Ok
[10:00] <Surak> I'm talking about the live cds - dapper and edgy, unmodified.
[10:00] <mjg59> That needs noting in the report, then
[10:00] <mjg59> Kamion: We only use nv on the live CDEs, right?
[10:01] <Surak> I could make the machine to boot by installing it on hard drive without the nvidia board, and then blacklisting intel_agp before inserting the card.
[10:02] <Kamion> mjg59: we install the restricted modules as well, though AFAIK not nvidia-glx. I imagine it's up to the kernel's modaliases what gets loaded
[10:02] <mjg59> I don't /believe/ the nvidia module has modaliases
[10:02] <mjg59> Let me check
[10:03] <mjg59> Oh, hrm.
[10:03] <mjg59> Maybe it does. That sucks.
[10:07] <Nafallo> infinity: ping :-)
[10:09] <Nafallo> infinity: unping
[10:09] <Nafallo> gnight :-=
[10:09] <Nafallo> :-)
[10:09] <Surak> unping? :-)
[10:10] <Lure> if build failed due to dependancy (like kdeutils due to xinit: https://launchpad.net/+builds/+build/235022), will it get rebuilt automatically now that fixed xinit is in archives or does somebody need to request build again?
[10:11] <Lure> s/dependancy/dependacy failing to install in chroot/
[10:11] <Kamion> Lure: if it failed as opposed to going into dep-wait, which it did, then it needs to be manually retried
[10:11] <Kamion> Lure: however, infinity's going to do a mass give-back once the dapper point release is done
[10:11] <Kamion> Lure: so I wouldn't worry about manually requesting one
[10:12] <Lure> Kamion: ok, thanks
[10:27] <mjg59> rodarvus: Hm. We're going to have to add the Alps patches back to xserver-xorg-input-synaptics
[10:27] <mjg59> I'll look at bringing them up to date
[10:27] <rodarvus> mjg59, appreciated!
[10:27] <rodarvus> I couldn't find where they were created from
[10:27] <mjg59> I wrote them
[10:28] <rodarvus> mjg59, oh, nice
[10:28] <rodarvus> mjg59, thanks!
[10:44] <pitti> Hi again
[10:46] <pitti> Kamion: downloading new ppc alternate now and testing
[10:50] <seb128> pitti: morning :p
[10:52] <pitti> hey seb128
[10:53] <shogobg> Hello all
[10:54] <seb128> pitti: still testing CDs for the dapper updatE?
[10:55] <mvo> hi pitti
[10:55] <pitti> seb128: yes, I was waiting for the updated alternate ones to test the powerpc sound regression fix
[10:55] <seb128> hey mvo :)
[10:55] <pitti> and it wasn't available when I left for taekwondo
[10:56] <seb128> ah, k
[10:56] <pitti> moin mvo
[10:56] <mvo> pitti: I'm testing my update-notifier modifications right now but I can't make apport write crash reports right now
[10:56] <pitti> mvo: echo hallo | sudo tee /var/crash/foo.crash? :)
[10:56] <pitti> mvo: and some chmod/chown, of course
[10:56] <pitti> keescook: ping
[10:57] <mvo> pitti: I wrote some mini-segfault application, but for some reasons those crashes are not recoreded
[10:58] <pitti> mvo: why not just 'cat' in one shell, and 'killall -SEGV cat' in another?
[10:59] <pitti> mvo: the reason is that I ignore crashes from executables which do not belong into a package
[10:59] <mvo> pitti: aha, ok
[10:59] <mvo> nice!
[10:59] <pitti> mvo: so that we do not get millions of reports that we aren't responsible for :)
[10:59] <mvo> makes sense :)
[11:00] <pitti> ... and the titan gloves :)
[11:45] <keescook> pitti: pong
[11:48] <jono> hi folks
[11:57] <HarrySprocket> hello
[11:57] <Surak> hello
[11:59] <HarrySprocket> is this where ubuntu is created?
[12:00] <Surak> here is where people discuss it. which probably is a 'yes' to you :-)
[12:02] <Surak> it is not a tech support channel, tough.
[12:04] <HarrySprocket> I'm banned from #ubuntu want to be unbanned lol
[12:06] <Surak> Unfortunately, I don't think this is the channel to discuss this.