[00:01] <Kmos> http://linux-foundation.org/weblogs/openvoices/linus-torvalds-part-i/
[00:02] <hunger> Running htop I see ~70 console-kit-daemons running... I guess that is due to htop not noticing multithreading. Isen't that a bit excessive?
[00:05] <tjaalton> slangasek: actually, there's need for one more upload.. openchrome lacks a patch to extract pci-ids in a text file, but fortunately the patch for via applies and works..
[00:15] <slangasek> tjaalton: ok.  at least it's now installable, so we can move ahead with test images :)
[00:15] <tjaalton> sure
[00:16] <tjaalton> I can put it on hold until tomorrow if needed?
[00:18] <slangasek> as long as that's the only change you're making, it doesn't sound like it would disrupt anything, and it would certainly help get better feedback from openchrome users on the alpha
[00:18] <slangasek> so please go ahead
[00:18] <tjaalton> ok, thanks
[01:54] <Sefram> why is the Gusty installer CD olny working with the pnpacpi=off option as a boot parameter on my machine?
[01:54] <Sefram> any ideas?
[01:55] <Sefram> without pnpacpi=off i get an error about 8139cp is not right for my RTL-8139C PCI network card and that i should use 8139too instead??
[01:55] <Burgundavia> Sefram: no idea, but file a bug
[01:56] <cjwatson> ... on the kernel (linux-source-2.6.22 package)
[01:57] <Sefram> what have i to regard while installing when it works only with pnpacpi=off??
[02:00] <Sefram> i got the tip from here: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/22575   seems to be an address ressoure conflict in pci address space...
[02:00] <ubotu> Launchpad bug 22575 in linux-source-2.6.15 "ISAPNP grabbing I/O region reserved for PCI device on 2.6.12  (regression from 2.6.10)" [Medium,Confirmed]
[02:01] <Sefram> Ubotu: smarty lol
[02:01] <ubotu> Sorry, I don't know anything about smarty lol - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[02:08] <calc> Hobbsee: does chrootwait go away automatically?
[02:09] <Hobbsee> calc: not necessarily
[02:10] <calc> Hobbsee: hmm can you fixup openoffice.org to retry, i think the reason it failed was due to the archive being updated when it tried to build
[02:11] <calc> unless something really did break the chroot's due to unauthenticated debs?
[02:12] <Hobbsee> calc: given back
[02:12] <calc> ok
[02:13] <calc> Hobbsee: thanks :)
[02:13]  * Hobbsee wonders what the chroot problem actually is
[02:18] <slangasek> I wouldn't be surprised if it was just a case of the mirror being in an inconsistent state due to having to futz around with the rsyncing and so forth
[02:32] <bddebian> slangasek: Hey, I have a new asc upstream in games SVN if you'd rather upload that? :)
[03:24] <_MMA_> Does the package gdm 2.20.2-1ubuntu2 include the changes from upstreams 2.20.3 release?
[03:40] <alephant> Please forgive my being slightly off-topic: How are updates to packages indicated to apt?  Is there a datastream which sez "foo-1.2 upgraded to foo-1.3"?  Or does apt simply compare the most-recent copy of the package as indicated by Packages.bz to the locally-installed package?
[04:44] <slangasek> bddebian: mutter mumble if someone would fix paragui then we could upload asc to Debian and sync it...
[04:49] <bddebian> slangasek: What's up with paragui?
[04:50] <slangasek> bddebian: it ships a .la file that has references to a crapload of other .la's that it doesn't depend on
[04:52] <bddebian> Ah the SDL "team" :)
[04:52] <slangasek> bddebian: and indeed, the asc upload FTBFS on all archs because of this, so sure, I'll take a new upstream that I can sync after
[04:52] <bddebian> Hmm, 2.0.1 didn't FTBFS on unstable for me
[04:54] <bddebian> asc 2.0.1 that is
[04:55] <slangasek> the build failures are entirely paragui's fault
[04:55] <slangasek> well - no, the latest one is my fault, because I didn't verify first that directfb-dev still ships a.la
[04:56] <StevenK> Which it doesn't
[04:58] <slangasek> yes, which is why things Broke
[05:01] <emgent> launchpad died
[05:02] <slangasek> bddebian: so where's this asc package that needs sponsorin'?
[05:02]  * bddebian does another build of asc out of curiosity
[05:02] <bddebian> slangasek: I just removed it from mentors
[05:05] <bddebian> Damnit, now it's puking trying to pull in libbz2-dev
[05:08] <bddebian> I have another issue while my pbuilder updates.  I've built a new stormbaancoureur.  However, one file (engine.tga) is rendered from a 3D model that the author purchased.  He claims he has copyright but is that possible?
[05:10] <bddebian> F**k, is libbz2-dev broken now too?
[05:11] <lifeless> bddebian: its possible and there is no way to tell; have him assert the appproporiate copyright statement and you're good
[05:12] <slangasek> bddebian: it wouldn't ftbfs on unstable because the paragui binaries in unstable were built against a good libsdl, and the ones in hardy were built against a bad libsdl
[05:13] <slangasek> libbz2-dev... broken how?
[05:13] <slangasek> installed cleanly for me
[05:13] <bddebian> uninstallable in my sid pbuilder
[05:14] <StevenK> The libsdl in Hardy is bad?
[05:17] <slangasek> not anymore
[05:17] <slangasek> all about the Timing!
[05:18] <bddebian> libparagui is in universe still?
[05:19] <slangasek> it should be somewhere else?
[05:20] <bddebian> Hmm, and 1.0 or 1.1? :)
[05:21] <slangasek> well, 1.0 is the one it's been building against, beyond that I have no idea
[05:21] <bddebian> I wonder if 2.0.1 would build against 1.1
[05:25] <bddebian> Gah wtf, libbz2-dev installs fine if I pbuilder-login
[05:31] <LaserJock> hmm, should the topic be changed for the Alpha 3 freeze?
[05:32] <bddebian> E: Failed to fetch http://ftp.debian.org/debian/pool/main/b/bzip2/libbz2-dev_1.0.4-1_i386.deb: 404 Not Found
[05:32] <bddebian> E: Unable to correct for unavailable packages
[05:32] <bddebian> gaaahh
[05:33] <slangasek> LaserJock: yes, thanks :)
[05:35] <emgent> keescook, ping
[05:35] <LaserJock> slangasek: np ;-)
[05:35] <keescook> emgent: pong
[05:36] <emgent> keescook, wordpress diff 2.1 is ready
[05:36] <keescook> emgent: cool, make a bug report for it and get it attached.  nice work.  :)
[05:37] <emgent> ok thanks :)
[05:39] <slangasek> bddebian: libparagui1.0 fixed, so where did asc go after it was removed from mentors?
[05:39] <bddebian> slangasek: I'm throwing it back on mentors as I type
[05:40] <bddebian> I can't test build in on unstable though for whatever the fsck is going on with my pbuilder. (I switched the build-deps to libparagui1.1)
[05:41] <slangasek> I'm... less likely to sponsor a package with library changes that haven't been tested
[05:41] <bddebian> Well I wanted to test it but I can't build it.  I can switch it back if we want to get it in
[05:45] <slangasek> switching it back would be good if you want me to look at sponsoring it; otherwise I can just get the already-uploaded asc given back on the buildds to take care of the bug I was after
[05:47] <bddebian> Let me switch it back.  I've been trying to get this in forever
[05:49] <bddebian> pabs3: !?
[05:49] <pabs3> hi bddebian :)
[05:50] <bddebian> Man, I can't hide anywhere anymore :)
[05:50]  * pabs3 was wondering who to contact about patches.ubuntu.com
[05:50] <pabs3> :)
[05:51] <bddebian> pabs3: lifeless suggested we might get away with the engine.tga thing in stormbaancoureur if he provides copyright.  Would you disagree?
[05:52] <pabs3> that'd be offtopic here, perhaps #debian-games is better?
[05:53] <pabs3> about patches.ubuntu.com, would it be possible to remove changelog-only patches? for eg http://patches.ubuntu.com/s/synfig/synfig_0.61.07-1build1.patch
[05:54] <bddebian> Oh, build1 versions aren't really patches, just rebuilds
[05:56] <pabs3> yeah, but they do show up on packages.qa.d.o, which can be annoying when I go to check for a patch and find it only bumps the changelog
[05:56] <bddebian> Ah yes, makes sense
[06:01] <bddebian> slangasek: http://mentors.debian.net/debian/pool/main/a/asc/asc_2.0.1.0-1.dsc
[06:22] <slangasek> bddebian: downloading gradually
[06:23] <bddebian> NP, I gotta get my old arse to bed anyhow
[06:48] <sam__> can any one guide me in streaming??
[06:50] <calc> how do i search for a file in hardy?
[06:50] <calc> there are still no contents files?
[06:51] <calc> i'm getting this error: /usr/include/mono-1.0/mono/metadata/threads.h:17:41: error: mono/metadata/threads-types.h: No such file or directory
[06:51] <calc> and need to know where that file is
[06:52] <sam__>  i am getting RTSP/1.0 461 Unsupported Transport from rtsp server ..?????
[06:52]  * calc wonders if libmono-dev is just fscking buggy
[07:00] <calc> yep mono is a just buggy
[07:01] <calc> pochu: ping
[07:01] <calc> pochu: bug 181422
[07:01] <ubotu> Launchpad bug 181422 in mono "thread-types.h is missing" [High,New] https://launchpad.net/bugs/181422
[07:10] <dholbach> good morning
[07:11] <sam__> i guess no one wanna help me ... ok..
[07:15] <torkel> sam__: wrong channel for that kind of question, try #ubuntu
[07:16] <pitti> Good morning
[07:29] <emgent> pitti, good morning :P
[07:44] <pitti> hi emgent!
[08:53] <hunger> The hardy gcc gets an ICE when building kdeedu her.
[09:16] <viviersf> is there anywhere i can get a list of all packages are used for the live cd ?
[09:16] <pochu> calc: pong, looking
[09:17] <evand> viviersf: http://cdimage.ubuntu.com/daily-live/current/hardy-desktop-i386.manifest
[09:19] <viviersf> evand, the manifest is ubuntu-desktop + live cd components
[09:19] <pitti> calc: OO.o FTBFS> "mcs not found" -> missign build dep?
[09:19] <viviersf> evand, i need a list of just the stuff thats extra, i can do it manually, i just want to see an easy way
[09:20] <pitti> viviersf: you can look at the 'ship-live' seed, but that does not include dependencies which are pulled in by those and which are not needed by ubuntu-desktop
[09:21] <viviersf> pitti, cool, is that a package ?
[09:22] <pitti> http://codebrowse.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.hardy/files
[09:23] <viviersf> thanks pitti, that will do
[09:27] <geser> good morning
[09:29] <seb128> hey geser
[09:30] <pitti> hi geser
[09:36] <coyctecm> hey guys :)
[09:38] <geser> Hi seb128, pitti
[09:57] <pochu> calc: I'm merging mono 1.2.6+dfsg-5 from Debian which fixes this (in -4):
[09:57] <pochu>    * debian/patches/fix_threads.h.dpatch:
[09:57] <pochu>      + Don't include threads-type.h in threads.h and moved functions to the
[09:57] <pochu>        correct header, fixes compiling of OpenOffice.org's Mono bridge.
[09:57] <pochu>        (taken from upstream SVN revision 91687 + 91817)
[09:59] <seb128> pitti: do you know if there is any hardy language pack upload scheduled?
[09:59] <pitti> seb128: the guys are working on it, but I haven't heard a concrete deadline
[09:59] <pitti> carlos: ?
[10:00] <carlos> pitti: let me check it with jeroen...
[10:00] <seb128> I'm wondering if we will ever have a cycle where rosetta is ready and language packs uploaded early ;-)
[10:00] <seb128> apport is all broken here for weeks now and I was waiting for translation updates before investigating
[10:02] <pitti> seb128: oh? what's wrong with apport?
[10:02] <carlos> seb128, pitti: danilo is working on a small problem that affects Slovenian translations since long time ago and that requires to be fixed before opening Hardy
[10:03] <Tonio_> hi there
[10:03] <seb128> pitti: http://people.ubuntu.com/~seb128/Capture-apport-gtk.png
[10:03] <Tonio_> is there someone here familiar with gcj/ecj packages except doko ?
[10:03] <carlos> seb128, pitti: He expects to get a script run later today that should fix the data so we are ready to start with imports
[10:03] <seb128> pitti: basically the text is invalid utf8
[10:04] <seb128> carlos: ok, thanks
[10:04] <pitti> seb128: ah, you mean the translations are broken? ok, since it works just fine here
[10:04] <seb128> carlos: happy new year btw
[10:04] <seb128> pitti: well, I was wondering if that's the translations or the code but was waiting on a language pack update before investigating
[10:04] <carlos> seb128: same for you, did you enjoy your vacations? :-)
[10:04] <seb128> carlos: yes, was nice to spend some time away from the computer ;-)
[10:05] <carlos> :-D
[10:05] <seb128> carlos: how was your honeymoon?
[10:05] <carlos> seb128: 'short'
[10:05]  * carlos hides
[10:05] <seb128> ahahah, good one ;-)
[10:05] <carlos> the only problem was when we went to Paris, we moved from 30 degrees to -2 degrees....
[10:05] <seb128> you have been lazy enough, fix rosetta now!
[10:05] <seb128> cold is better, isn't it? ;-)
[10:06] <carlos> seb128: not yet, next month, this month I'm not working in translations :-)
[10:06] <carlos> seb128: not really ;-)
[10:06] <pitti> carlos: reminds me about my transition from vacation in Nice to distro sprint in Oslo (25 -> -12 degrees)
[10:06] <carlos> wow
[10:06] <carlos> that's even worse
[10:07] <pitti> the guys at the airport to Nice wondered why I brought thick sweaters, gloves, scarf, etc :)
[10:07] <Fujitsu> Going from Australian summer (it was 42 the day I left) to -4 is quite bad, I find.
[10:27] <soren> Hm... Rhythmbox core dumps after 10.6-10.7 seconds. Every time. Very annoying.
[10:27] <seb128> soren: backtrace?
[10:27] <Fujitsu> soren: Regardless of what you've told it to do beforehand?
[10:27] <soren> Fujitsu: Yup.
[10:28] <soren> Fujitsu: Regardless of whether or not it's playing anything, too.
[10:28] <soren> seb128: I'll report it with apport in a bit.
[10:28] <seb128> good
[10:29] <Fujitsu> It works fine for me, though at one stage I did make it segfault on start every time by disabling Cover Art.
[10:29] <Fujitsu> soren: The time is seemingly arbitrary and uniform?
[10:30] <soren> Fujitsu: Yup.
[10:31] <soren> Fujitsu: Minimum observed: 0m10.652s, maximum observed: 0m10.702s.
[10:31] <soren> Fujitsu: I've done it ~10 times.
[10:31] <seb128> soren: maybe it's shocking on a file and is consistent on how long it needs to reach it
[10:32] <soren> seb128: Could be. However, with 4 GB of RAM and a not too impressive music collection, I doubt it could take as much as 10 seconds to go through it.
[10:32] <seb128> RAM doesn't really matter there
[10:32] <seb128> that's rather IOs
[10:32] <soren> seb128: WEll, if everything is cached, it does.
[10:32] <soren> ..and it is. My hard drive is idling.
[10:32] <seb128> it needs to go through the library to know if it changed
[10:32] <soren> *drives
[10:33] <seb128> weird
[10:33] <Fujitsu> soren: strace isn't useful?
[10:33] <seb128> send the bug using apport that will give us some idea about the crash ;-)
[10:33] <soren> seb128: I'm trying... It's something like /usr/share/apport/apport-gtk -c /var/crash/_usr_bin_rhythmbox.1000.crash, isn't it?
[10:34] <soren> seb128: Ah, it's just taking forever to upload, probably.
[10:34] <seb128> soren: double click on the crash in nautilus
[10:35] <seb128> soren: you should get the apport window about the crash before having it sending anything
[10:36] <pitti> seb128: apport -c will do the same, so that's fine
[10:36] <pitti> (double click is just more comfortable :) )
[10:36] <soren> seb128: It tells me I should have an up-to-date system before doing anything. I'd better obey.
[10:37] <soren> pitti: Well, except that you have to fire up nautilus and all that jazz first.
[10:37] <soren> pitti: If you happen to have nautilus open in /var/crash anyway, then yes :)
[10:37] <seb128> having a parameter to not require the uptodate system would be nice
[10:38] <seb128> I often have whatever package which doesn't matter for the backtrace not uptodate
[10:58] <pochu> calc: mono merge ready, but I'll have to wait for slomo to come back unless some else wants to volunteer :)
[11:12] <geser> pitti: should pkg_create_dbgsym honour the -X option from dh_strip?
[11:13] <geser> see bug #180364
[11:13] <ubotu> Launchpad bug 180364 in ocamlnet "ocamlrpcgen no longer works on Gutsy. Probably a wrongly stripped binary" [Undecided,New] https://launchpad.net/bugs/180364
[11:13] <pitti> geser: I don't think so, why?
[11:13] <pitti> pkg_create_dbgsym does not strip anything off the original binaries
[11:14] <geser> have you then an explanation for this bug?
[11:15] <pitti> geser: not really; I think it should be tested with a local build of ocaml, both with and without pkg-create-dbgsym installed
[11:15] <geser> in my pbuilder debian/tmp/usr/bin/ocamlrpcgen works as intended but the one from debian/libocaml-ocaml-bin (or the deb) doesn't
[11:15] <pitti> ah
[11:15] <pitti> geser: does your pbuilder have pkg-create-dbgsym installed?
[11:16] <geser> when I set NO_PKG_MANGLE or add -Nlibocaml-ocaml-bin to the dh_strip call the one from debian/libocamlnet-ocaml-bin works too
[11:16] <pitti> the only thing p-c-d does to the original binary is adding the .gnu.debuglink section so that gdb can find the separate symbol files
[11:16] <geser> pitti: it has
[11:16] <pitti> aha, then it seems it is the culprit
[11:19] <geser> so adding -Nlibocaml-ocaml-bin to the dh_strip call the right fix?
[11:19] <pitti> no, that just sounds like a workaround
[11:19] <pitti> if it works correctly without p-c-d, we should fix the latter
[11:23] <geser> I checked now where the binary breaks. Adding .gnu_debuglink breaks it.
[11:24] <pitti> ugh
[11:24] <pitti> but.. that's just an innocent extra elf section... *whine*
[11:24] <pitti> geser: ok, does 'file <original binary>' say anything special?
[11:25] <pitti> geser: or even better, can you tell that it must not be touched from the readelf -h output?
[11:25] <geser> ocamlrpcgen.working: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
[11:25] <pitti> ok, that's not useful then
[11:26] <pitti> or an 'ocaml_bytecode' section in objdump -x or so?
[11:28] <pitti> geser: I added a p-c-d task to this bug (the ocaml task is for the no-change rebuild then) and added this question
[11:32] <geser> pitti: objcopy -R .gnu_debuglink ocamlrpcgen seems to be enough to break it
[11:33] <pitti> geser: ok, so we must not do that then
[11:33] <pitti> geser: I think the best fix is to make p-c-d not touch the binary at all if it has ocaml bytecode
[11:33] <pitti> so I just need to get a good test for that
[11:34] <pitti> something objdump -x binary | grep -q '\.ocaml_bytecode' like
[11:37] <geser> pitti: http://members.ping.de/~mb/tmp/objdump.output
[11:38] <soren> seb128: The rhythmbox bug was already reported by pochu: bug 179205
[11:38] <ubotu> Bug 179205 on http://launchpad.net/bugs/179205 is private
[11:38] <pitti> geser: thanks; I think I'll go with caml_release_bytecode
[11:39] <pitti> geser: just for final verification: objdump -x binary | grep -qw caml_release_bytecode
[11:39] <pitti> ?
[11:39] <seb128> soren: alright, and it has been fixed upstream already apparently
[11:40] <soren> seb128: Orly?
[11:40] <seb128> soren: ?
[11:40] <soren> "orly" = "oh, really"
[11:40] <soren> :)
[11:40] <seb128> soren: look at the upstream task on the bug
[11:40] <seb128> ah, ok
[11:40] <pitti> geser: is objdump -t enough?
[11:41] <soren> seb128: Oh, upstream bug of the duped lp bug. Right.
[11:42] <seb128> soren: no, of the non dupped bug (the one which is Fix Commited)
[11:42] <seb128> but right ;-)
[11:42] <geser> pitti: objdump -t ocamlrpcgen | grep -qw caml_release_bytecode exits with 0
[11:42] <soren> seb128: Er.. Um.. Yes, you seem to be right :)
[11:42] <pitti> geser: cool, thanks
[11:43] <soren> seb128: Do you intend to upload a fix or should I do it?
[11:43] <seb128> soren: you are welcome to do it since you can test the fix ;-)
[11:43] <soren> seb128: Will do. It's not in bzr or anything, is it?
[11:44] <seb128> soren: no, just grab the patch from svn, copy to debian/patches and upload
[11:44] <soren> seb128: Alright.
[11:44] <seb128> soren: http://svn.gnome.org/viewvc/ is handy to get diffs for GNOME modules
[11:48] <pitti> anyone running Kubuntu here? does "x-terminal-emulator -e dpkg -l" work, i. e. runs dpkg -l in a new terminal?
[11:49] <pitti> I'm not sure whether the KDE alternative of x-terminal-emulator correctly recognizes -e
[11:49] <pitti> xterm and gnome-terminal do
[11:51] <geser> pitti: is it intended that "objcopy -R foobar binary" modifies the binary even if the section doesn't exist? because the filesize changes from 1248876 to 269652
[11:51] <pitti> geser: I'm not sure whether it's intended, but I noticed that a thing like that gets rid of a lot of cruft
[11:51] <soren> seb128: Oh, I used the bzr import from launchpad instead. Thanks, though.
[11:52] <pitti> at least it has done that for years
[11:55] <\sh> pitti: konsole does know about -e
[11:55] <\sh> pitti:  -e <command>              Execute 'command' instead of shell
[11:55] <pochu> calc: do you need mono for alpha-3?
[11:56] <pitti> \sh: so if you do "x-terminal-emulator -e dpkg -l" it opens a Konsole window with dpkg -l output?
[11:56] <pitti> and closes it again when it's finished?)
[11:57] <\sh> pitti: well, running gnome right now so I'm on gnome-terminal, but "konsole -e dpkg -l" works like a charm
[11:57] <\sh> pitti: kde3 that is
[11:57] <Riddell> pitti: works for me
[11:57] <pitti> Riddell, \sh: great, thank you
[11:59] <\sh> mvo: pingeling...did you hear about my fatal experience when dist-upgrading from dapper to gutsy via edgy/feisty?
[12:10] <geser> pitti: thinking about the pkg_create_dbgsym bug again: does it make sense to want to add a .gnu_debuglink for binaries which aren't going to be stripped?
[12:12] <pitti> geser: not really, no
[12:13] <geser> what about passing the -X option from dh_strip to pkg_create_dbgsym to not add those links for the listed binaries as they are stripped anyway later?
[12:14] <geser> this would fix it for the ocaml problem and any further binaries which don't like to be stripped
[12:15] <geser> argh, there is a not missing in the first sentence: as they aren't stripped anyway later
[12:15] <pitti> geser: that would work, yes; we already have a flag $nodebuglink which is passed to pkg_create_dbgsym but it only gets enabled if dh_strip builds a -dbg package on its own
[12:15] <pitti> we could extend this to pass down a "don't touch" blacklist
[12:19] <mvo> \sh: no, did you file a bug?
[12:19] <jsgotangco> mvo!
[12:19] <mvo> \sh: I would be very interessted in the logs
[12:19] <mvo> hey jsgotangco
[12:23] <ogra> hmm, tasksel fails on the current daily ... known fact ?
[12:23] <ogra> ah, missing language-pack-en
[12:25] <ogra> hmm
[12:25] <\sh> mvo: there are no logs...but evms is the bug
[12:26] <ogra> weird, langauge-pack-en in on the CD
[12:26] <ogra> *is
[12:26] <ogra> i wonder why its not found
[12:26] <\sh> mvo: we used a root server from strato, dapper lts installation...and evms is installed by default, but it wasn't running...after upgrading from dapper to edgy to feisty to gutsy, our two swap spaces were not there anymore, but locked by a process, which you don't see even with lsof...
[12:27] <\sh> mvo: I was fighting with it several hours, till soren told me to remove evms from the system...after that it worked...
[12:27]  * Fujitsu got that on a number of systems, and thought the distupgrader was meant to handle that.
[12:27] <\sh> mvo: evms on dapper is still being enabled by /etc/init.d/ and now it's got enabled with udev I think...so we need to check what happens with dapper -> hardy directly...
[12:29] <mvo> \sh: could you send me the logs please (if you used the release-upgrader) - it should automatically remove evms on feisty->gutsy
[12:29] <mvo> \sh: logs in /var/log/dist-upgrade/*
[12:30] <\sh> mvo: I didn't ;) I used apt-get dist-upgrade
[12:30] <mvo> \sh: aha, ok :)
[12:30] <\sh> mvo: but I think many people dealing with debian/ubuntu on servers will not use release-upgrader ,-)
[12:32] <mvo> \sh: we have a text-frontend!
[12:32] <torkel> \sh: probably depends on if they know about it or are using apt-get dist-upgrade because they allways had
[12:32] <\sh> torkel: that's what I meant
[12:32] <mvo> \sh: I'm not a expert on the evms stuff, but afack we can not just unconditionally remove it
[12:33] <mvo> \sh: we definitely need to release note it
[12:33]  * mvo wonders if we have a expert on evms
[12:33] <Tonio_> anyone has an idea where I can download https://edge.launchpad.net/ubuntu/+source/gcj-4.2/4.2-20070707-1ubuntu2 please ?
[12:33]  * Mithrandir hides from mvo 
[12:33] <\sh> mvo: if we can determine if it was in use on dapper or not .. it could help...
[12:33] <Fujitsu> mvo: Release noting and perhaps modifying Dapper's apt to screech if somebody tries to do it directly...
[12:33]  * mvo catches Mithrandir
[12:33] <Tonio_> links are dead and since now the package build-depends on itself, this version is the only one I can use to build the package on feisty
[12:33]  * Mithrandir plays dead
[12:34] <\sh> mvo: if evms is being enabled by some magic variable in /etc/default/evms or something ... we could use this info during the update
[12:35] <mvo> \sh: the release upgrader does that, it checks if evms is in use by looking into /proc/mounts and if not, removes it
[12:35] <\sh> Fujitsu: well, as canonical explained, that dist-upgrades from lts to lts is working without any problem...it's likely to happen
[12:35]  * ogra tickles Mithrandir 
[12:35]  * Fujitsu stabs Mithrandir to make sure he isn't just playing dead.
[12:35] <mvo> but I don't know the details, why evms causes this trouble if it is not used
[12:35] <\sh> mvo: no other way possible outside dist-upgrader? some magic in udev to determine the state of evms?
[12:36] <mvo> Mithrandir: is there some bugreport about this to figure what the probelm is ?
[12:36] <mvo> \sh: I think if we could solve it at a package level instead of working around it in the release-upgrader, that would be the best course of action
[12:36] <Mithrandir> mvo: the problem is evms tries to grab all discs and partitions whether they're evms volumes or not.
[12:37] <geser> Tonio_: LP still has the debs; click on the package you need, open the "Published as" portlet, select the architecture you need, download the deb
[12:37] <Fujitsu> And causes much confusion when one tries to work out why only the non-LVM /boot partition won't mount.
[12:38] <Tonio_> geser: sure but I need to build this on feisty
[12:38] <Tonio_> geser: that's why I really need the source package...
[12:38] <Fujitsu> Tonio_: The broken links are a bug I filed a couple of weeks back.
[12:38]  * Fujitsu grabs links.
[12:40] <\sh> mvo, Mithrandir: I'll file a bug against emvs...(but I'm not sure if it's a bug in evms) but I wonder why evms is being used when it wasn't running at all...
[12:41] <soren> Tonio_: Eh?
[12:41] <soren> Tonio_: The source is right there on the page you linked to?
[12:42] <persia> soren: librarian doesn't have those files :(
[12:42] <Tonio_> Fujitsu: AHHHHHHHHHH, great
[12:42] <Fujitsu> persia: Librarian does have those files. kiko's code is dodgy when the packages aren't published anywhere.
[12:43] <persia> Err.  Right.  s/:($/At that location./
[12:43] <soren> persia: Oh, right.
[12:43] <soren> #  Removed from disk  on 2007-07-21.
[12:43] <Mithrandir> \sh: it's being run from the initramfs
[12:43] <Fujitsu> soren: The files are still in Librarian, just not on drescher.
[12:44] <soren> Fujitsu: You're probably right.
[12:44] <\sh> Mithrandir: hmm...more difficult
[12:47]  * soren lunches
[12:50] <geser> Tonio_: http://mirror.linux.org.mt/mirror/ubuntu/pool/main/g/gcj-4.2/gcj-4.2_4.2-20070707-1ubuntu2.dsc
[12:51] <Tonio_> geser: thanks a lot !
[13:22] <bigon> could someone makes a give-back for gossip (with libloudmouth1-dev >=1.3.3-1)
[13:23] <Mithrandir> bigon: given-back
[13:25] <geser> Mithrandir: is it safe to ask for give-backs of the packages in CHROOTWAIT?
[13:29] <Mithrandir> geser: in general, they should be given-back automatically.  Any in particular?
[13:29] <\sh> mvo / Mithrandir: bug #181491 for the evms problem
[13:29] <ubotu> Launchpad bug 181491 in evms "dapper -> edgy -> feisty -> gutsy update fails " [Undecided,New] https://launchpad.net/bugs/181491
[13:29] <geser> Mithrandir: if they are given-back automatically then I can wait
[13:38] <bigon> Mithrandir: thx
[13:54] <pitti> mvo: if I have an apt.Cache() object, is there a fast method to update it after I installed a package? (for .isInstalled) or do I need to regenerate it from scratch?
[13:57] <mvo> pitti: cache.open() should do
[13:59] <pitti> mvo: hm, that seems to take as long as generating a new apt.Cache()
[13:59] <pitti> I used c.open(None)
[14:01] <mvo> pitti: it needs to generate the binary cache after a install, it should be possible to speed it up a bit (for installs), I can look into that. you may consider showing some progress informration if that is a UI issue
[14:01] <pitti> mvo: ok; no, please don't spend any effort on this, I was just curious
[14:02] <mvo> pitti: ok :) I may still, I got a interessted idea that I would like to test
[14:12] <calc> pochu: yea there was more wrong with OOo that I uploaded than just the missing header but I ran into that while fixing it on my box
[14:13] <calc> pochu: i think it is probably too late for alpha-3 at this point :\
[14:16] <cjwatson> calc: right now, openoffice.org is uninstallable in hardy; we can't release alpha-3 with it like that
[14:16] <cjwatson> it needs to be fixed
[14:16] <cjwatson> (one way or another)
[14:18] <pitti> good morning calc
[14:19] <azeem> did Ubuntu officially evaluate the Liberation Fonts license?
[14:19] <azeem> mjg59: ^^ do you know, maybe?
[14:19] <mjg59> Not to the best of my knowledge
[14:20] <mjg59> My recollection is that it's free but GPL incompatible
[14:20] <azeem> I heard today OOo upstream added the fonts recently
[14:20] <azeem> mjg59: well, fonts don't need to be GPL compatible, do they?
[14:20] <mjg59> Only if embedded in GPLed works
[14:20] <mjg59> So, not generally
[14:20] <azeem> I had a chat with aj about it earlier, as the debian-legal thread last May immediately got hijacked by nutcases
[14:21] <calc> cjwatson: ok i can do the mono merge then upload new OOo that I have on my box
[14:21] <azeem> so there's two exceptions, one is the official FSF-recommended font exception
[14:21] <azeem> the other is some sort of anti-tivoization restriction it seems
[14:21] <cjwatson> calc: what are the changes in the new OOo?
[14:21] <mjg59> Yeah, I told the people involved I wasn't really happy with describing an additional restriction as an exception
[14:22] <mjg59> But, still
[14:22] <calc> cjwatson: very few changes mostly to deal with the way mono was split over the holidays, mono was broken over the holidays as well see bug 181422
[14:22] <ubotu> Launchpad bug 181422 in mono "thread-types.h is missing" [High,In progress] https://launchpad.net/bugs/181422
[14:22] <calc> pochu: ping
[14:22] <calc> seems pochu didn't include his merge work for mono on the bug report :\
[14:22] <azeem> mjg59: and then there is the strange IP discaimer plus "Title to the Software and any component, or to any copy, modification, or merged portion shall remain with [Red Hat]"
[14:23] <mjg59> I don't have a freedom issue with that (others might)
[14:23] <mjg59> But it's still weird and potentially unenforceable
[14:23] <mjg59> Unless it simply means "We are still copyright holders, even if you modify it", in which case, that's kind of obvious
[14:24] <broonie> But then lawyers often like pointing out the obvious.
[14:24] <calc> pochu: i need the merge where is it
[14:25] <calc> well he seems to not be here right now so i can look into remerging mono from debian
[14:25] <geser> calc: try http://emilio.pozuelo.org/~deb/mono_1.2.6+dfsg-5ubuntu1.dsc
[14:26] <calc> geser: ah great :)
[14:26] <geser> that one he asked slomo to sponsor
[14:26] <azeem> mjg59: if I read this right, they own the copyright of the changes I make, even if I don't distribute them; is that something Ubuntu thinks is alright?
[14:27] <cjwatson> calc: ok, thanks
[14:27] <ogra> cjwatson, pkgsel seems broken as well atm
[14:27] <cjwatson> ogra: what's up with it? I hadn't heard
[14:28] <ogra> i had a file not found with it ... let me reproduce (my virtualbox just crashed and took the kept error with it, somethig about pre-pkgsel.d being empty)
[14:29] <cjwatson> hmm, sounds plausible
[14:29] <calc> pochu: nevermind geser gave me the url above to sponsor :)
[14:30] <mjg59> azeem: The QPL has similar issues, but I'm not sure that's what it means
[14:30] <mjg59> azeem: It may well just be "Red Hat are still a copyright holder even if you modify it"
[14:31] <mjg59> But clarification might be nice - RH legal are friendly people, IME
[14:31] <cjwatson> ogra: odd that that would be a fatal error (rather than just syslog noise), though
[14:31] <ogra> i had a proper red screen ...
[14:31] <ogra> install stopped
[14:32] <ogra> i'm in base-install gimme 10 min
[14:32] <azeem> mjg59: do you know a good contact address for that, by chance?
[14:32] <azeem> mjg59: (I thought the QPL was an issue and was mostly ignored cause all important code is bi/tri-licensed to sane licenses)
[14:33] <mjg59> azeem: We still ship QPL-only code
[14:33] <cjwatson> ogra: I'm rsyncing a current image, but it'll be a while
[14:33] <azeem> ok
[14:33] <ogra> i'll get you the syslog
[14:33] <mjg59> azeem: Indeed, we *have* to ship Qt under the QPL as well - otherwise only GPL-compatible code can link against it
[14:33] <ogra> its easily reproducable
[14:33] <azeem> hrm, right
[14:34] <mjg59> (debian-legal seem to conveniently ignore this)
[14:34] <azeem> however, the QPL doesn't claim to be the GPL+exceptions
[14:34] <azeem> oh well
[14:35] <azeem> mjg59: anyway, thanks
[14:35] <mjg59> No problem
[14:45] <cjwatson> ogra: can I get syslog?
[14:45] <cjwatson> my rsync is at 49%, so this is probably faster
[14:45] <ogra> cjwatson, http://paste.ubuntu-nl.org/51357/
[14:45] <ogra> copying the full log to p.u.c
[14:47] <cjwatson> ogra: the tasksel failure is the real problem, I think
[14:47] <ogra> cjwatson, http://people.ubuntu.com/~ogra/syslog
[14:47] <ogra> (sorry, german)
[14:47] <cjwatson> tjaalton mentioned the same error yesterday on netboot but we didn't get into it
[14:47] <cjwatson> German is fine
[14:48] <ogra> to me it looks more like the language pack triggers it though
[14:48] <cjwatson> nah
[14:48] <cjwatson> well, probably isn't helping, but being unable to find the standard task is the real blow-up I think
[14:49] <cjwatson> the log ordering is a bit screwed but so it goes
[14:49] <cjwatson> de.archive's Task headers look ok
[14:49] <cjwatson> I wonder if the CD is screwed
[14:50] <hunger> Is there a known bug wrt. creating users? I used useradd to create one and then used it to log into gnome and all I got was a white screen.
[14:50] <ogra> i added the ltsp-client-builder udeb to the installer seed could it be that this broke anything (i didnt do anything additionally but adding it)
[14:50] <cjwatson> hunger: you should use adduser, for starters
[14:51] <cjwatson> ogra: shouldn't think so, it hasn't run yet
[14:51] <ogra> right
[14:51] <hunger> cjwatson: Aehm... right that is what I used:-)
[14:51] <ogra> its run right after pkgsel
[14:52] <ogra> (and needs preseeding to actually run)
[14:53] <hunger> cjwatson: It would be cool if only one of useradd and adduser would get installed:-)
[14:54] <cjwatson> hunger: since adduser uses useradd internally, I don't think that's likely
[14:55] <azeem> move useradd to libexec!
[14:55] <cjwatson> azeem: GNUisance ;-)
[14:56] <hunger> cjwatson: Well, it is not the user creation process that gives me a white screen:-)
[14:57] <cjwatson> right, my guess is that it only works if you're in some group or other - but that would certainly be a bug
[14:57] <cjwatson> check .xsession-errors
[14:57] <ogra> audio is a good guess i bet
[14:57] <hunger> cjwatson: I testet this by deleting all the major config files of an existing user: Now I get a white screen there, too.
[14:57] <pochu> calc: great. will you sponsor it for me? I pinged slomo about it, so if you are going to upload it let him know so you don't duplicate work :)
[14:58] <hunger> kde starts fine by the way.
[15:01] <tjaalton> pitti: I'll test the new cupsys for dapper
[15:02] <pitti> tjaalton: oh, great! thanks
[15:02] <cjwatson> ogra: ok, that's really weird, the CD's Packages file looks fine too
[15:02] <cjwatson> I wonder if this is an apt bug
[15:03] <ogra> i have the machine still here (snapshotted now)
[15:05] <cjwatson> can you chroot into /target and run 'apt-get install standard~'?
[15:05] <ogra> couldnt find package standard~
[15:05] <cjwatson> ogra: err, sorry, I mean standard^
[15:06] <ogra> ah :)
[15:06] <ogra> couldnt find package standard^
[15:06] <ogra> err
[15:06] <ogra> s/package/task
[15:07] <pochu> cjwatson: ok to upload mono 1.2.6+dfsg-5ubuntu1? (currently we have -1ubuntu1). It fixes an issue with the OOo build.
[15:08] <cjwatson> pochu: yes
[15:08] <cjwatson> ogra: does 'apt-cache show apparmor | grep Task:' show anything?
[15:09] <ogra> unable to locate package apparmor...
[15:09] <ogra> no packages found ...
[15:09] <pochu> cjwatson: thanks
[15:10] <pochu> calc: slomo will take care of the mono upload.
[15:10] <cjwatson> ogra: ...
[15:10] <ogra> looks like it doesnt find anything beyond the bootstrapped packages that are installed
[15:10] <cjwatson> my head hurts, need more coffee
[15:11] <ogra> hmm
[15:12] <cjwatson> so certainly pkgsel arranges for only the sources added by base-installer to be used at that point
[15:12] <cjwatson> (to avoid expensive downloads)
[15:12] <ogra> i cant see the cdrom if i'm chrooted
[15:12] <cjwatson> but base-installer seems to be doing the right thing, so I'm a little puzzled
[15:12] <cjwatson> oh
[15:12] <mvo> pitti: I filed bug #181518 so that we can do dapper->hardy upgrades (small patch to update-manager). this means that we need to attack the dbus restart problem soonish (before this version of u-m is accepted into dapper-proposed)
[15:12] <ubotu> Launchpad bug 181518 in update-manager "check of LTS dist upgrades" [Undecided,New] https://launchpad.net/bugs/181518
[15:12] <ogra> hmm, i can but it doesnt appear mounted
[15:13] <ogra> apt-get update moans
[15:13] <cjwatson> ogra: good call, I see the problem now
[15:13] <ogra> i see stuff in /cdrom though
[15:13] <cjwatson> it's an artifact of fjp's work to make multi-CD installs work
[15:13] <ogra> ah
[15:13] <cjwatson> and muggins here got the ordering a bit wrong when merging
[15:14] <cjwatson> I'll figure out how it's supposed to work and fix it - thanks!
[15:14] <ogra> :)
[15:19] <pitti> mvo: oh, right, that
[15:21]  * calc got mono uploaded
[15:21] <seb128> calc: <pochu> calc: slomo will take care of the mono upload.
[15:22] <calc> pochu: sorry i didn't see that since i was working on the upload, did he already do it? i needed it for the OOo i have to do in the next few minutes
[15:23] <slomo> calc: there were some things that needed changes... well, let's fix it with next upload then, nothing critical
[15:23] <calc> slomo: oh sorry about that :(
[15:25]  * calc is now doing the OOo test build with new mono
[15:37] <pitti> pochu: please use debuild -v <previous ubuntu version> when merging
[15:39] <pochu> pitti: acked (slomo just told me that :)
[15:39]  * pitti hugs pochu
[15:50]  * pochu hugs pitti back :)
[16:04] <siretart> asac: are we going to stay with network-manager 0.6.5 for hardy, or do we want to go for 0.7.x? I'm asking because I'm curious to know what to do about wpasupplicant
[16:04] <siretart> read: merge the 0.6.x branch from debian, or stay with 0.5 for hardy
[16:04] <tjaalton> I've heard that 0.7 supports modems, so n-m support for 3G would be way cool
[16:08] <asac> siretart: not sure ... we should probably start to implement the debian plugin for the system-settings and publish a preview version to get an idea about its suitability for a LTS release.
[16:08] <sladen> n-m that /worked/ would be "way cool"
[16:09] <sladen> or rather, could cope with situations where the PC is not in a state == first boot
[16:12] <seb128> what bug is that one?
[16:14] <siretart> asac: I see. well, FYI, the plan for debian is to keep tracking the 0.6 branch of wpasupplicant. need to ask mbiebl about nm
[16:15] <pitti> lool: I think our remaining avahi change (http://merges.ubuntu.com/a/avahi/avahi_0.6.22-2ubuntu1.patch) is equally relevant for Debian; WDYT, can it be merged?
[16:15] <asac> siretart: debian should ship the right nm + wpasupplicant combinatino as well imo.
[16:16] <asac> siretart: but most likely 0.7 will be ready in time for next debian stable release
[16:16] <siretart> asac: I'd assume so, right. however I haven't heard complaints from the nm maintainers there
[16:19]  * pitti looks at http://launchpadlibrarian.net/11226590/apt-show-versions_0.12ubuntu1.debdiff
[16:20] <pitti> is it just me who thinks that maintaining debian/ubuntu-patches is more effort and error-prone than just using MoM? at least for such trivial merges?
[16:21] <siretart> pitti: I think such patches are best kept in either launchpad or the debian bts
[16:22] <pitti> siretart: well, it's a patch that doesn't apply to Debian
[16:22] <pitti> but it's so trivial and obvious, and MoM does it just fine, so I think it's just unnecessary overheade
[16:22] <pitti> s/e$//
[16:22] <siretart> It might not apply, but having it around would not hurt there
[16:22] <siretart> right
[16:23] <pitti> warp10: anyway, sponsored; thanks
[16:47] <kkubasik> hey, has anyone been having problems with cairo and firefox?
[16:47] <kkubasik> http://pastebin.com/m211fcc81
[16:51] <tjaalton> could someone translate from Spanish to English: "il file con la lista dei file del pacchetto `xserver-xorg-core' contiene un filename vuoto"
[16:51] <jpatrick> that's italian
[16:51] <tjaalton> oh :)
[16:51] <tjaalton> damn me
[16:51] <jpatrick> if it was spanish, I would have gladly helped you :)
[16:52] <tjaalton> heh
[16:52] <tjaalton> I should've known
[16:55] <pitti> "the rows with the list of the rows of the package ` xserver-xorg-core' contain a filename empty" -- hmm
[16:56] <tjaalton> it's bug 181530, and doesn't make sense to me
[16:56] <ubotu> Launchpad bug 181530 in xkbset "package xkbset None [modified: /var/lib/dpkg/info/xkbset.list] failed to install/upgrade: il file con la lista dei file del pacchetto `xserver-xorg-core' contiene un filename vuoto" [Undecided,New] https://launchpad.net/bugs/181530
[16:56] <tjaalton> at least there is no file conflict
[16:57] <pitti> tjaalton: maybe the /var/lib/dpkg/info/xkbset.list is empty?
[16:57] <tjaalton> disk full?
[16:58] <pitti> possibly
[16:58] <warp10> pitti: sorry for late response, was away. I tought it was trivial and obvious indeed, but maybe it could be useful someway, so I updated it :)
[16:59] <pitti> msgid "files list file for package `%.250s' contains empty filename"
[16:59] <pitti> tjaalton: ^ grabbed from italian dpkg.po
[17:00]  * pitti pats his unpacked langpack tree for grepping for translations
[17:00] <slangasek> pitti: "the row" is "la fila", not "il file" :)
[17:01] <seb128> pitti: can you look in this unpack tree if the french apport translation is valid utf8? ;-)
[17:01] <pitti> slangasek: good morning
[17:01] <slangasek> morning
[17:01] <pitti> slangasek: that was just babelfish; my own Italian is a magnitude worse :)
[17:01] <pitti> seb128: rookery:/srv/language-packs.ubuntu.com/gutsy-proposed/sources-base/
[17:02] <seb128> pitti: danke
[17:02] <pitti> seb128: I can look for you in a bit, off to dinner
[17:02]  * seb128 learns every day thanks to pitti ;-)
[17:02] <seb128> pitti: no, I'll manage, thanks
[17:02] <seb128> *hug*
[17:03] <slangasek> pitti: no, I think your own italian would only be a magnitude slower, I don't think it's possible to be a magnitude worse ;)
[17:04] <_MMA_> seb128: Does the package gdm 2.20.2-1ubuntu2 (hardy)  include the changes from upstreams 2.20.3 release?
[17:05] <tjaalton> pitti: thanks, weird
[17:05] <seb128> _MMA_: no, but I'll upload 2.20.3 after the freeze
[17:05] <seb128> _MMA_: why?
[17:06] <_MMA_> Ahh... Killer. Im looking to see that bug where you can set the background color go away.
[17:06] <seb128> _MMA_: it's supposed to be fixed in 2.20.3
[17:06] <seb128> _MMA_: it can probably wait an extra day ;-)
[17:07] <_MMA_> Oh sure. Just a visual eye-sore when Ubuntu Studio has it set to black but it comes up light brown.
[17:17] <hunger> Is there a way to not start compiz? I think my white-screen-when-using-gnome problem is compiz related.
[17:19] <ogra> hunger set /desktop/gnome/applications/window_manager/current and default to metacity
[17:19] <ogra> (gconf keys)
[17:20] <hunger> ogra: Thanks!
[17:21]  * hunger wonders where the config file with those keys is hidden.
[17:21] <hunger> Sorry, I'm a kde person:-)
[17:35] <hunger> That indeed helps. I can log back into gnome again.
[17:42] <sladen> full disk?
[17:45]  * pitti hugs seb128 back
[18:00] <pochu> will the hardy cds ship any translation packages? specifically the spanish ones?
[18:01] <seb128> pochu: depending of the CD space
[18:02] <seb128> pochu: not easy to say now
[18:02] <pochu> Right. And do you know whether Gutsy shipped any?
[18:02] <seb128> gutsy shipped some, dunno the exact list, cjwatson or pitti most likely know
[18:03] <pochu> maybe the ones in http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.gutsy/live ?
[18:03] <seb128> pochu: right
[18:04] <pochu> thank you seb128
[18:04] <seb128> you are welcome
[18:11] <pitti> asac: the history substring search in ffox3 is the best thing since slice bread!
[18:14] <seb128> maybe I should give firefox3 a try just to see what it looks like ;-)
[18:14] <asac> yeah ;) ... I agree that it rocks!
[18:15] <cjwatson> it's nice, except that if your mouse happens to be hovering over the area occupied by the substring search results pop-down, it's impossible to type just the substring and not select whatever it was that the mouse is hovering over
[18:15] <cjwatson> i.e. pressing Enter in the URL bar prefers to select the thing being hovered over by the mouse rather than whatever you typed in the URL bar
[18:16] <asac> good catch. haven't noticed before
[18:18] <cjwatson> do you want a bug?
[18:18]  * cjwatson blinks at bug 180525
[18:18] <ubotu> Launchpad bug 180525 in firefox-3.0 "firefox-3.0 pornlib resizes images into works of abstract art" [Undecided,New] https://launchpad.net/bugs/180525
[18:19] <slangasek> "oh, /cubic/ interpolation, I thought you said /cubist/ interpolation"
[18:21] <asac> cjwatson: yes, please open a bug
[18:22] <asac> didn't find an upstream duplicate on first attempt, but will have to check again later. bugzilla is sometimes hard to use :/
[18:22] <seb128> bugzilla rocks ;-)
[18:29] <cjwatson> asac: OK, I hope bug 181575 is a comprehensible description. I found it quite hard to describe clearly
[18:29] <ubotu> Launchpad bug 181575 in firefox-3.0 "pressing Enter in URL bar selects mouse hover target in substring-search pop-down" [Undecided,New] https://launchpad.net/bugs/181575
[18:29]  * asac looking
[18:30] <asac> cjwatson: thats fine. thanks
[19:07] <slangasek> tjaalton: is there any chance that your latest openchrome changes could have negatively affected a Radeon chip?
[19:08] <slangasek> tjaalton: Riddell is reporting (informally) that alpha3 X is screwed up on this chip: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 330M/340M/350M
[19:10] <tjaalton> slangasek: Xorg.0.log would help
[19:11] <tjaalton> sounds strange enough :)
[19:11] <slangasek> yeah
[19:11] <slangasek> will have to wait for Riddell to resurface then, I guess
[19:12] <slangasek> what little other information there is is here: http://iso.qa.ubuntu.com/qatracker/result/1210/50
[19:12] <slangasek> bryce: unless you happen to have access to something with that chipset and could verify?
[19:13] <bryce> heya
[19:13] <bryce> hmm, I just have one ATI based system
[19:13] <tjaalton> there are reports that ati 6.7.197 has had regressions
[19:13] <bryce> wait, no two.
[19:14] <bryce> I think one is an R350, lemme check
[19:14] <tjaalton> you lucky b.. :)
[19:14] <bryce> my fiance is thankfully tolerant of my computeraholic issues
[19:16] <bryce>  Radeon R350 [Radeon 9800 Pro]
[19:17] <bryce> unfortunately this system isn't on Hardy
[19:17] <seb128> 01:00.1 Display controller: ATI Technologies Inc RV350 AP [Radeon 9600] (Secondary)
[19:17] <seb128> that's my desktop and it's running hardy
[19:18] <seb128> 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon 9600] (prog-if 00 [VGA controller])
[19:18] <seb128> and it works fine with the current ati driver
[19:19] <tjaalton> riddell has a laptop apparently
[19:20] <tjaalton> slangasek: there's a newer driver on wiki.u.c/XorgOnTheEdge
[19:20] <bryce> is there a LP# for riddell's bug?
[19:21] <tjaalton> I would've noticed it :)
[19:25] <bryce> my other -ati is X600
[19:30] <claude> stgraber: ping
[19:31] <claude> stgraber: stop talking, please
[19:33] <stgraber> claude: :)
[19:44] <slangasek> bryce: no LP#, no; he seems to have taken off ill before he could get to that point
[19:45] <slangasek> the problem was reported with the LiveCD; I suppose that shouldn't make a difference, but
[19:46] <bryce> ok, I'll cut a CD and give it a go
[20:09] <sabdfl> Riddell: thanks for taking care of the geoip sync
[20:10] <tjaalton> bryce, slangasek: the ati bug is likely bug 180343
[20:10] <ubotu> Launchpad bug 180343 in xserver-xorg-video-ati "ATI driver update causes Display Corruption" [Undecided,New] https://launchpad.net/bugs/180343
[20:10] <bryce> thanks
[20:11] <slangasek> tjaalton: great, thanks
[20:11] <slangasek> Riddell: ^^
[20:11] <bryce> (cd's about halfway burned; will test it after lunch.  bbiab)
[20:17] <tjaalton> bryce: I'll ask alex about that bug
[20:26] <tjaalton> bryce: ok, I'll compile git master, and ask people to test that
[20:48] <bryce> booting, bbiaw
[21:04] <tjaalton> slangasek: new driver attached to the bug, waiting for test results
[21:06] <slangasek> tjaalton: cheers
[21:08] <bryce> slangasek: kubuntu booted up just fine on my R350
[21:08] <bryce> I did find one issue though, but it's unrelated
[21:09] <bryce> so perhaps the issue Riddell ran into was specific to his R350M?
[21:10] <Riddell> sabdfl: welcome
[21:10] <Riddell> bryce: wouldn't surprise me, this laptop is full of odd hardware bits
[21:10] <tjaalton> bryce: actually that's RS200M
[21:10] <tjaalton> Riddell: please try the driver from bug 180343
[21:10] <ubotu> Launchpad bug 180343 in xserver-xorg-video-ati "ATI driver update causes Display Corruption on Radeon IGP 330M/340M/350 " [High,Confirmed] https://launchpad.net/bugs/180343
[21:13] <bryce> Riddell, slangasek:  I ran into this issue when trying to access the monitor config admin tool:  http://people.ubuntu.com/~bryce/tmp/snapshot1.png
[21:13] <Riddell> tjaalton: the radeon_drv.so file attached there seems to work ok
[21:13] <tjaalton> wohoo!
[21:13] <bryce> :-)
[21:13] <slangasek> bryce: hrm, curious
[21:14] <Riddell> bryce: yeah, known issue, I've not had a chance to look at it
[21:14] <bryce> okie
[21:14] <bryce> yeah, figured as much
[21:37] <tjaalton> ok, I've got the commit that fixes this ati issue ()
[21:37] <tjaalton> RADEON: Make sure all old IGP chips have HasSingleDac set
[21:37] <tjaalton> duh
[22:19] <tjaalton> slangasek: should I roll an update with that patch?
[22:22] <slangasek> tjaalton: sounds good.  Not sure I'll reroll images for it, but if it lands in good time, it'd be nice to have
[22:23] <tjaalton> ok
[22:24] <slangasek> and if it doesn't land, and least we've got good info to put in the release notes :)
[22:24] <tjaalton> yeah :)
[23:00] <phomes> is there a reason for that gnome-games is stuck at 2.20.1 for gutsy? (and 2.20.0.1 for hardy btw) We are getting a ton of crasher reports that should be fixed from these old versions