[12:11] <lamont> grumble.  for my next trick, purging libx11-6 and everything that needs it.
[12:12] <Amaranth> what replaced it?
[12:12] <lamont> Amaranth: nothing... trying to get a working x/gnome again
[12:13] <Amaranth> ah
[12:13] <lamont> step 2 will be to install ubuntu-desktop :-)
[12:13] <Amaranth> yeah, libx11-6 is a good idea
[12:13] <Amaranth> i usually do libgtk2.0-0 and xserver-xorg-core
[12:13] <Amaranth> but yours would do it in one package :)
[12:13] <lamont> I'll probably make another pass
[12:36] <Tonio_> hi everyone
[12:36] <Tonio_> I have a little question concerning soyuz
[12:36] <Tonio_> I need to provide a little change to a package already waiting in the NEW queue
[12:37] <Tonio_> can I simply overwrite by reuploading ? or does this require manual action by Kamion or someone else ?
[12:39] <Amaranth> upload with a new ubuntuX version
[12:42] <Tonio_> Amaranth: isn't that a problem if NEW package is 0ubuntu2 ?
[12:42] <Amaranth> i don't think so, as long as your next upload is 0ubuntu3
[12:43] <Tonio_> okay
[12:43] <Tonio_> Amaranth: thanks
[12:56] <lamont> Tonio_: once you upload a package with a given version and it's in soyuz anywhere, you're pretty much stuck with uploading a later version number before it will let you play
[12:57] <Tonio_> lamont: so you suggest me to wait and then reupload the package with modifications named to 0ubuntu2
[12:57] <Tonio_> .
[12:57] <Tonio_> ?
[12:57] <lamont> no
[12:57] <lamont> I was saying that if you already uploaded -0ubuntu2, an want to make changes to it, then you get to upload something with a newer version number (e.g., -0ubuntu3
[12:57] <lamont> )
[12:58] <Tonio_> okay :) so I need to upload version 0ubuntu2
[12:58] <Tonio_> thanks for the info :)
[12:59] <lamont> I though tyou said -0ubuntu2 was already uploaded and sitting in NEW?
[01:05] <lamont> well... that's a different error...
[01:05] <lamont> "GDM could not write to your authorization file.  This could mean that you are out of disk space, or that your home directory could not be opened for writing.  In any case, [you're screwed] ."
[01:06] <Tonio_> lamont: 0ubuntu1 is in NEW actually, so I will upload 0ubuntu2 as you said
[01:06] <lamont> ah, ok
[01:09] <j^> lamont still trying to log in? last message is saw, X was looking for /etc/X11/xserver/SecurityPolicy in /etc/xserver/SecurityPolicy
[01:11] <xTina> Is anyone around who admins launchpad (i.e. the actual machine / web server)?
[01:12] <lamont> prolly not
[01:12] <lamont> brb
[01:16] <lamont> xTina: the admins of that box are in .uk, which makes it about midnight their time.
[01:16] <xTina> lamont: hey, that's about an hour earlier than here :P
[01:17] <lamont> ENOSEB.  sigh
[01:17] <lamont> heh
[01:17] <lamont> the real question is what did you need one of them for?
[01:18] <lamont> but now I'm afraid to log out of the machine at home... :-(
[01:19] <xTina> To check if the reason for bug https://launchpad.net/products/launchpad/+bug/6659 might not be an actual launchpad bug but just caused by the fact that mod_ssl's SSLVerifyClient is set to anything but "none". But I can as well just add to that bug report, I'm just lazy since I just turned off my Linux box before getting that idea and that's the box that contains the browsers that are not affected by this bug ;)
[01:19] <Ubugtu> Malone bug 6659 in launchpad "Launchpad requests user certificate from Safari, MSIE/Windows, MSIE/Mac" [Major,Confirmed]
[01:20] <xTina> Hm. Camino is working :)
[01:20] <xTina> neat
[01:20] <lamont> probably best in the bug - since that's not actually somethign that the admin would change without it going through the LP team, I expect...
[01:21] <xTina> I don't know how independent launchpad is from a specific mod_ssl config ... so I guess you're right.
[01:25] <lamont> anyway, time to flee
[01:53] <dAndy> can anyone tell me where the sky2 module might live: re bug #32591 ?
[01:53] <Ubugtu> Malone bug 32591 in linux-source-2.6.15 "Network card not detected during setup, but available after installation" [Normal,Fix released]  http://launchpad.net/bugs/32591
[01:54] <mjg59> dAndy: ?
[01:55] <dAndy> mjg59: yes?
[01:55] <mjg59> dAndy: I don't understand the question
[01:56] <dAndy> benc said in the bug that a fix was released, but as far as I can see, the sky2 module is still not in the mini.iso, I figured I could rebuild the mini.iso, but I cant find the udeb that includes that kernel module
[01:58] <mjg59> dAndy: I believe that there is currently no udeb that includes that kernel module
[01:59] <mjg59> It's possible that it's been fixed in the git tree, but not pushed out yet
[01:59] <dAndy> ah ok, that would be why I cant find it, thanks
[01:59] <mjg59> Yeah, it's in git
[02:00] <dAndy> so Kamion just needs to grab it and add it to the installer?
[02:01] <mjg59> Well, it'll probably need another kernel binary upload
[02:02] <mjg59> Which ought to happen before too long - there's a pile of queued fixes
[02:06] <dAndy> alright thanks alot for the help, I will wait a bit longer :)
[03:02] <childe> Why did they removed all the quick-search bookmarks in Firefox?
[03:03] <childe> Yesterday I upgraded to the latest Dapper, and in the new Firefox I can't use quick search anymore
[03:12] <infinity> childe: They're still there in mine.
[03:12] <mjg59> I think I've fixed hibernate
[03:12] <infinity> childe: Are you sure you're not suffering from "firefox has broken chrome because I upgraded it but haven't closed/killed all running instances yet"?
[03:13] <mroth> mjg59: what bug is that being tracked on?
[03:14] <mroth> sladen: around?
[03:14] <ifr> Sorry but I've tried the other rooms to no avail with a KERNEL CONFIG QUESTION:  I'm trying to make one patch to an otherwise ducky kernel.  I downloaded the source tree for the kernel.  BEFORE I do make oldconfig should I apply the patch by doing patch -p0 < patch-name.patch in the source directory of the kernel I'm compiling? Thanks
[03:16] <childe> infinity: !!!
[03:16] <childe> infinity: Stupid me...then, how can I get them back?
[03:16] <ifr> No one?
[03:16] <infinity> childe: Log out, or reboot, or anything else that's pretty much guaranteed to kill every single running firefox instnace.
[03:17] <mjg59> mroth: About 10 zillion different ones
[03:17] <mjg59> mroth: Hw much RAM do you have?
[03:17] <mroth> heh
[03:17] <childe> infinity: Then, remove the .mozilla directory and run Firefox?
[03:17] <infinity> mjg59: Oh, is part of this the "I have too much RAM, and people think that breaks swsusp" thing?
[03:17] <mjg59> infinity: Yes
[03:18] <mroth> mjg59: uh.. in which machine?  my thinkpad has 1GB, my HP has 1GB, my vaio has 512MB, and my desktop has 2GB
[03:18] <infinity> mjg59: Cause I've had off again on again luck between breezy and dapper with my 2GB Thinkpad.
[03:18] <mjg59> infinity: I've just sent a patch to Ben that works for me
[03:18] <ifr> Can anyone suggest a better chat room where I can get that compiling question answered?
[03:18] <mjg59> Test machine worked fine with 0.5GB, broke with 1GB and now works fine again (with 1GB)
[03:19] <infinity> mjg59: Rock.  Does it apply cleanly to -19.29, or does it rely on some other changes in git?
[03:20] <infinity> mjg59: If the former, pass it my way and I'll build myself a test kernel (unless you have a -686 test image I can play with?) and deliver you some results.
[03:20] <mjg59> infinity: Should apply cleanly. Hang on
[03:21] <mjg59> infinity: http://www.codon.org.uk/~mjg59/tmp/swsusp.diff
[03:21] <ifr> I just don't get why no one will even answer...
[03:22] <Amaranth> sorry
[03:22] <infinity> ifr: Because this isn't a help channel, please read the topic.
[03:22] <ajmitch> afternoon
[03:22] <bddebian> Heya ajmitch
[03:22] <Chipzz> ajmitch: no, good nighty ;)
[03:22] <Chipzz> s/y//
[03:23] <childe> c
[03:23] <infinity> mjg59: That's some patch.
[03:23] <LaserJock> ifr: I'd just try it and see
[03:23] <ifr> Thanks infinity
[03:23] <ifr> Thanks LaserJock.
[03:24] <infinity> mjg59: What happens if there just plain isn't enough swap space to DTRT, no matter how hard you try to free up RAM while suspending?
[03:24] <infinity> mjg59: Does it return a useful "nu uh!" of some sort?
[03:25] <childe> infinity: I closed all the Firefox instances then re-installed it, but still no quick search
[03:25] <mjg59> The echo gets ENOMEM
[03:25] <mjg59> We should probably really catch that and pass it back up, but, well.
[03:25] <infinity> childe: Whacky.  File a bug, I guess.
[03:26] <childe> infinity: So the new version of Firefox doesn't have quick search by default?
[03:26] <Chipzz> childe: did you try on a clean user?
[03:26] <infinity> mjg59: Passing it back up could make things friendly... Could have a nice dialog that says "You don't have enoug swap space to do this; Try closing some applications before trying again" or some such.
[03:27] <Chipzz> s/on/with/
[03:27] <childe> Chipzz: Haven't tried that. Let me try
[03:30] <childe> Chipzz: Nope, fresh user doesn't work.
[03:32] <childe> And there is no quick search in /usr/lib/firefox/defaults/profile/bookmarks.html
[03:33] <infinity> childe: Again, I recommend filing a bug.  If it disappeared from the default profile template, it was probably a mistake, since I don't spot any mention of it in the changelog.
[03:34] <childe> infinity: I've filed this as #36941 on launchpad :-)
[03:35] <infinity> (Hint:, if you say bug #36941, ubugtu may wake up and tell us something about it)
[03:35] <Ubugtu> Malone bug 36941 in firefox "No Quick Search Bookmarks" [Normal,Unconfirmed]  http://launchpad.net/bugs/36941
[03:35] <infinity> Looks good to me.  Now you get to sit back and wait for iwj to fix it. :)
[03:36] <childe> infinity: No problem :-) I can use Opera instead.
[03:44] <jjesse> mako: ping
[03:51] <lakin> mjg59: what's the approximate time frame for that patch to hit the dapper archives? (so I can't remember to test it?)
[03:54] <mjg59> lakin: No idea
[03:54] <mjg59> Probably within the next week
[03:54] <lakin> k.  that's close enough.  Sometime at the end of the week I'll test hibernation again. :)
[03:55] <infinity> mjg59: What's the magic invocation to build just one kernel flavour again?
[04:02] <TheMuso> c
[04:02] <jjesse> is the help docs not installed by default for openoffice.org in dapper?
[04:03] <infinity> jjesse: Do you have language-support-en installed?
[04:04] <jjesse> infinity: need to check
[04:05] <jjesse> nope not installed
[04:07] <infinity> That would be why you have no help.  Not sure if the installer is meant to install that, or if it just isn't there by default..
[04:07] <desrt> cool factoid about the swap partitions
[04:08] <jjesse> shouldn't it be installed by default?
[04:32] <infinity> Kamion: Is there a valid reason for pcmcia-cs still being in *-desktop?
[04:41] <Kamion> infinity: yes, (a) bluez-pcmcia-support, (b) we still need it for some cards
[04:41] <Kamion> anything that needs CIS firmware needs pcmcia-cs
[04:41] <Kamion> jjesse: it's installed by default, yes
[04:42] <Kamion> check /var/log/installer/ to start investigating why it didn't get installed for you. One possible reason would be that it was uninstallable on the media you used for installation.
[04:43] <Kamion> Riddell: somehow, you didn't push that branch correctly (you seem to have pushed the working copy, but not .bzr) which means 'bzr merge' says "Nothing to do" for me
[04:44] <ToadZzZztool> before I go to bed, what about an UVF exception for lintian 1.23.16? :) I've got a patch to nearly adapt it to ubuntu (needs a little more work though)
[04:44] <infinity> Speaking of UVF...
[04:45] <infinity> Kamion: You probably won't touch this one with a 20 foot pole, but I need a UVF exception + permission for a mass rebuild to fix up ABI breakage in MySQL 5.0.. :/
[04:45] <Kamion> can you send mail?
[04:45] <infinity> Kamion: (Debian/Ubuntu had versioned symbols, and had pushed a patch upstream... Upstream finally decided to accept the patch, but named their symbol versoin differently... Boom)
[04:46] <infinity> Yeah, I can mail you/mdz.  I think it's pretty critical that we remain ABI compatible with Etch and upstream.
[04:46] <Kamion> ToadZzZztool: UVF exceptions are by mail, not IRC
[04:46] <Kamion> I'm too sleepy to process them now
[04:46] <Kamion> ToadZzZztool: is forward-porting the current patch not sufficient?
[04:48] <ToadZzZztool> Kamion: the patch is mainly about removing nmu checks and better handling ubuntu targets
[04:48] <ToadZzZztool> for the moment...
[04:48] <Kamion> ToadZzZztool: that sounds like a forward-port of the current patch
[04:52] <ToadZzZztool> Kamion: the patch I've made adds a -D/--debian switch to lintian, jvw said it could be included to Debian lintian as a no-op switch
[04:53] <ToadZzZztool> since I'm quite new to Ubuntu/Debian dev' I don't know what to do now :)
[04:55] <mxpxpod> ogra_ibook: ping
[04:58] <ToadZzZztool> good night devs', I'll be back tomorrow ;)
[04:58] <Kamion> ToadZzZztool: !
[04:58] <ToadZzZztool> Kamion: ?
[04:59] <Kamion> I'm not sure I like the idea of a command-line option for that
[04:59] <Kamion> (speaking as one of the other upstream lintian maintainers, although a less-active one ...)
[04:59] <Kamion> I don't really see why it's inappropriate to just patch the thing for Ubuntu normally the way we've been doing
[05:00] <ToadZzZztool> well, that's exactly what I'd like to hear/read :)
[05:00] <ToadZzZztool> I didn't have real feedback before
[05:01] <infinity> The idea of a --distro={ubuntu,debian,xandros,foo,bar,baz} switch that subtly changes some tests doesn't sound too horrible (defaulting to using the dist reported by `lsb_release -is`)
[05:01] <infinity> Would mean I could run lintian on Debian packages in my Ubuntu base system (and vice versa)...
[05:02] <Kamion> right, certainly a more general pick-a-distro flag would be better than a pick-Debian flag
[05:02] <Kamion> lintian already has a somewhat misnamed --dist option to pick the suite, though (for the lintian lab, I think)
[05:02] <infinity> That would be oddly confusing, yes. :)
[05:02] <Kamion> so that would be awkward to cram in
[05:03] <Kamion> we'd have to rename --dist and leave it a while to avoid breaking back-compat
[05:04] <Kamion> so for dapper I'd say we just keep patching lintian as normal
[05:04] <ToadZzZztool> well, since dholbach patched lintian to handle breezy, dapper and so on directly in the source, I didn't pay attention to --dist :/
[05:05] <Kamion> the patch we have is unrelated to --dist
[05:05] <Kamion> --dist is for when you're scanning a whole archive, like lintian.debian.org
[05:07] <Kamion> bah, dholbach threw away the older changelog when he merged
[05:07] <ToadZzZztool> :)
[05:07] <Kamion> I actually did that patch originally
[05:08] <Kamion> for hoary
[05:09] <ToadZzZztool> now, I really should go to bed, I feel like I'm saying nonsense and missing some important things
[05:09] <ToadZzZztool> good night everybody
[05:09] <Kamion> you seem to be doing OK
[05:09] <Kamion> night
[05:09] <ToadZzZztool> thanks Kamion
[05:11] <infinity> Kamion: Now that wpasupplicant no longer wants to pull in QT4, is there anything else pending its promotion to main?
[05:12] <infinity> Kamion: (perhaps the "WTF is it in the minimal seed" question, but that can be sorted after it's promoted..)
[05:12] <infinity> Kamion: Would be nice to get NM 0.6 building and tested in Flight-6.
[05:13] <infinity> Kamion: Same with beagle and gmime2.1 to get the new nautilus happy again.
[05:14] <Kamion> infinity: waiting for main inclusion reports
[05:14] <infinity> Kamion: Did they not all get some?
[05:14] <Kamion> for both wpasupplicant and gmime2.1 (both have reports, but not approved yet)
[05:14] <infinity> Ahh.
[05:15] <Kamion> the wpasupplicant seed question needs to be sorted first so that it doesn't immediately get sucked onto everyone's systems if we don't want it to be
[05:15] <infinity> Fair.
[05:15] <Kamion> Tonio_: when you're uploading a package that's in NEW, *please* bump the version; it makes life much less difficult for me when trying to compare the things
[05:16] <Kamion> Tonio_: IMHO launchpad should have rejected your second upload
[05:17] <Kamion> (you uploaded kmplayer <IP_ADDRESS>+0.9.2-pre3-0ubuntu1 twice)
[05:19] <LaserJock> Kamion: weird he said earlier he was going to bump it
[05:19] <Kamion> yeah, I saw that, but he didn't
[07:50] <infinity> mjg59: You win.  Hibernate works on my machine now.
[07:51] <infinity> mjg59: Of course, I have some goofy video corruption going on post-resume, but that's probably not your fault.
[07:58] <siretart> morning
[08:00] <ajmitch> morning siretart
[08:19] <fabbione> BenC: can you please pull from david before you upload?
[08:23] <pitti> Good morning
[08:23] <ajmitch> morning pitti
[08:35] <lbm> nm 0.6.1 doesn't seem to be build
[08:36] <lbm> can't even find build logs
[08:36] <infinity> It's dep-wait right now.
[08:36] <lbm> oh, internal marking in soyuz?
[08:37] <infinity> Build logs, however, aren't so hard to find.
[08:37] <infinity> https://launchpad.net/distros/ubuntu/+source/network-manager/0.6.1-0ubuntu1
[08:38] <lbm> well, i looked at http://people.ubuntu.com/~lamont/buildLogs/n/network-manager/, but these are the before-soyuz logs obviously
[08:38] <infinity> Yes.
[08:42] <lbm> infinity: do you know when wpasupplicant will be promoted to main?
[08:43] <infinity> lbm: It's still pending approval.
[08:43] <infinity> pitti: ^^^
[08:44] <lbm> infinity: :)
[08:44] <infinity> pitti: What's the story with wpasupplicant, gmime2.1 and beagle?
[08:45] <fabbione> am i right if a pci-x card can't be mounted on standard pci slots?
[08:46] <infinity> Not without pushing REALLY HARD.
[08:46] <lbm> :)
[08:46] <infinity> They should have mismatched keys.
[08:46] <pitti> infinity: wpasupplicant and beagle themselves are approved
[08:46] <infinity> pitti: wpasupplicant claimed not to be.
[08:46] <pitti> infinity: there might be some missing dependencies; I don't remember gmime
[08:47] <infinity> pitti: wpasupplicant is in the "needs work" category still.
[08:47] <fabbione> infinity: ok :))
[08:47] <pitti> infinity: oops, yes, I did a quick code review, it was ok
[08:47] <infinity> pitti: And gmime2.1 is a dependency of beagle.
[08:50] <pitti> infinity: any idea why n-m needs wpasupplicant as a *build* dependency?
[08:50] <infinity> pitti: I suspect it doesn't at all, on the other hand, this was a handy way to make sure 0.6 didn't get into main before wpasupplicant did. :)
[08:51] <pitti> infinity: but it's perfectly usable without wpasupplicant, so if the build dep can be dropped, it shuold be done IMHO
[08:51] <infinity> pitti: Oh, agreed, and Keybuk will be appropriately whipped.
[08:59] <jamesh> pitti: ping?
[08:59] <pitti> infinity: alright, I reviewed/approved gmime2.1
[09:00] <pitti> hey james, how are you?
[09:00] <jamesh> pitti: good.  I ran into a problem that made postgres uninstallable on dapper
[09:01] <jamesh> I also found the cause, so it should be pretty easy to fix: https://launchpad.net/distros/ubuntu/+source/postgresql-common/+bug/36921
[09:01] <Ubugtu> Malone bug 36921 in postgresql-common "postgresql fails to install" [Normal,Unconfirmed]
[09:02] <jamesh> doing s/6.04/6.06/ in /usr/share/postgresql-common/supported-versions fixes the post-install scripts, adjusting for the new version number for dapper
[09:02] <pitti> jamesh: argh, yes
[09:02] <pitti> jamesh: I didn't think of that when I saw the change
[09:03] <pitti> jamesh: yep, will fix now; thanks for the report
[09:03] <jamesh> pitti: as I said in the bug, the other problem is that the error message seems to be eaten by either debconf, dpkg or apt-get
[09:03] <jamesh> so it isn't obvious why it failed
[09:03] <pitti> jamesh: I'll send them to stderr instead, so that you can see them
[09:04] <pitti> jamesh: and I'll also let it default to just the latest version for an unknown release to prevent such hard failures
[09:06] <jamesh> pitti: I don't know if it would cause any problems on non-Ubuntu systems, but using "lsb_release -cs" rather than "lsb_release -rs" might improve reliability
[09:06] <jamesh> the release codename stayed as "dapper" while the version number changed
[09:07] <pitti> so far I believed in our regular release cycle :)
[09:13] <mdke> is the release number agreed on 6.06 now, or 6-06?
[09:13] <infinity> I'm hoping for 6.06... I find the latter rather ugly.
[09:13] <mdke> so not confirmed yet?
[09:13] <infinity> Not sure.
[09:13] <mdke> ok
[09:24] <jamesh> mdke: "lsb_release -r"and Launchpad both say 6.06
[09:24] <mdke> there was some suggestion of changing to 6-06
[09:28] <pitti> jamesh: fixed version uploaded, thank you
[09:28] <jamesh> pitti: thanks!
[09:28] <pitti> hey mvo
[09:29] <desrt> so is edgy getting pushed back too?
[09:29] <desrt> or will it be a 4-month release cycle?
[09:30] <mvo> hey pitti!
[09:52] <pitti> Mithrandir: would I disturb your revision control if I uploaded a new casper? I'd like to add sth. like '[ "$(uname -m)" = powerpc ]  && manual_add_modules snd_powermac || true' to debian/casper.initramfs-hooks
[09:52] <pitti> Mithrandir: bug 27862, btw
[09:52] <Ubugtu> Malone bug 27862 in casper "sound does not work any more on ppc live CD" [Normal,Confirmed]  http://launchpad.net/bugs/27862
[09:52] <tepsipakki> dapper+1 might have integrated some of the fedora stateless linux work, if there is interest? https://www.redhat.com/archives/fedora-devel-list/2006-March/msg01223.html
[09:53] <Mithrandir> pitti: the .bzr directory is in the source.  Feel free to upload, but also please put the branch somewhere so I can just do merge on my next upload.
[09:53] <Mithrandir> bzr should be able to do something like bzr merge distro://ubuntu/dapper/casper
[09:53] <Mithrandir> (and then fetch the source and merge that)
[09:53] <pitti> Mithrandir: hct :)
[09:54] <pitti> Mithrandir: anyway, it's not utterly urgent, so if you prefer to just add that like to your branch, that's fine for me
[09:54] <Mithrandir> pitti: sure, I can do that.
[09:54] <pitti> would be much less overhead
[09:54] <Mithrandir> true. :-)
[09:54] <pitti> Mithrandir: ok, great :)
[09:54] <Mithrandir> I just haven't done a casper upload since the bug was filed and have been lazy.
[09:54] <Mithrandir> now I'm off to test the live cd to see if my udev fix fixes the problem
[09:55] <pitti> Mithrandir: btw, does that look sane? it's the only platform specific module loading so far in that file
[09:56] <infinity> pitti: initramfs hooks have access to $ARCH
[09:57] <pitti> oh, cool
[09:57] <infinity> Which apparently Tollef doesn't use. :)
[09:58] <infinity> Oh, the one place he doesn't use it is commented out.
[09:58] <lifeless> moin moin
[09:58] <pitti> hey lifeless
[09:58] <pitti> hi seb128
[09:59] <Mithrandir> infinity: and is not in a hook
[09:59] <seb128> Hi pitti
[09:59] <infinity> pitti: Anyhow, check {scripts/init-premount/thermal,hooks/thermal} in /usr/share/initramfs-tools for ARCH.
[09:59] <infinity> Mithrandir: You have it at runtime too.
[09:59] <infinity> Oh, and it's DPKG_ARCH.  My bad.
[09:59] <infinity> (Good thing I told you to look)
[10:00] <pitti> so that would be easier than checking uname -m for powerpc and powerpc64
[10:00] <infinity> pitti: ^^^
[10:00] <infinity> pitti: Or, for powerpc, powerpc64, ppc, ppc64, yeah.
[10:00] <infinity> pitti: powerpc was the reason I did it.
[10:01] <Mithrandir> pitti: hmm, you don't need it in the initramfs, do you?  Can't I just stuff it in /etc/modules?
[10:01] <pitti> Mithrandir: sure, that'll work as well
[10:02] <pitti> Mithrandir: I just didn't find any reference to /etc/modules (I don't know the casper package at all)
[10:02] <infinity> Does snd_powermac need to be manually loaded?  Ick.
[10:02] <pitti> infinity: yes, it doesn't have udev support
[10:02] <pitti> it's this 'ADB' bus or so
[10:02] <pitti> no usb/pci/sth. sane
[10:03] <infinity> Yeah, my PowerMac is ADB.  It's also headless, though, so I've never cared about sound on it.
[10:03] <Kagou> hi
[10:13] <Mithrandir> would anybody be very sad if the live cd stopped ejecting the cd and just rebooted instead?  It interacts badly with splashdown.
[10:13] <Mithrandir> (this is bug 34537, btw)
[10:13] <Ubugtu> Malone bug 34537 in casper "On livecd shutdown, cd ejects and usplash does nothing" [Normal,Confirmed]  http://launchpad.net/bugs/34537
[10:14] <Mithrandir> I think it's less important to eject the cd now that we have "boot from first hard disk"
[10:17] <Seveas> Mithrandir, is boot from first harddisk the default?
[10:17] <Mithrandir> no
[10:17] <infinity> Mithrandir: The bad interaction wit splashdown is my bug, not yours.  I need to get usplash to stop getting killed (so people get a nice "It's safe to reboot" message)
[10:17] <Mithrandir> infinity: no, it's not.  casper has a down-script which ejects the cd and says "please remove the cd and press enter to continue"
[10:17] <Mithrandir> obviously, the user never sees that.
[10:18] <infinity> Mithrandir: Right, and it should be able to say that through usplash... But it can't, because usplash has been killed by init. :)
[10:18] <infinity> No reason that can't be fixed.
[10:18] <infinity> 9And it needs to be fixed for the installed system anyway)
[10:18] <Mithrandir> infinity: no, it hasn't at that point.  It will relativetly after, though.  And usplash doesn't have a "wait for keypress" thingy yet.
[10:18] <infinity> s/9/\(/
[10:19] <Kamion> Mithrandir: that makes sense to me, and ejecting has never been all that reliable anyway
[10:19] <Mithrandir> relativetly quickly, even.
[10:19] <infinity> usplash doesn't need a wait for keypress thingee.  You usplash_write, then read.
[10:19] <infinity> Keystrokes are passed to the underlying shell.
[10:19] <Mithrandir> ok
[10:19] <infinity> (Which is why you can happily Ctrl-C and Ctrl-Alt-Del during boot)
[10:20] <infinity> But none of this impacts your decision to eject or not.
[10:20] <Kamion> hmm, as Tollef points out it doesn't work so well on powerpc
[10:20] <Kamion> and powerpc is where you actually need software eject in many cases
[10:20] <infinity> Just saying that the usplash behaviour isn't a good excuse to change things. :)
[10:20] <Kamion> the user may not be *able* to get the CD out without a paperclip
[10:20] <Mithrandir> I could eject and not wait, but that will cause users to complain about the cd drive closing over their fingers.
[10:21] <Kamion> so I'll reverse my position - I think we should fix the usplash bug but keep ejecting
[10:21] <infinity> Easy enough.
[10:21] <infinity> Thogh, would it be possible to wait for input BEFORE you eject, too? :)
[10:22] <Mithrandir> "press enter and I will eject cd" (ejects cd) "press enter to continue rebooting".
[10:22] <infinity> Yeah, it feels icky...
[10:22] <Mithrandir> I'm wondering if we should just always eject on ppc and not on i386/amd64, since those have "boot from hard drive" in the menu.
[10:23] <Kamion> and you have to wait after ejecting, too, because some machines reboot pretty quickly and suck the CD tray back in as you're trying to get the disk out
[10:23] <Kamion> which can lead to broken CDs and/or bruised fingers
[10:24] <Mithrandir> sure, but change the behaviour from "always eject" to "eject on ppc"?
[10:25] <Kamion> hmm, unsure, I'm not so keen on radically different behaviour on different architectures, but your call
[10:25] <Mithrandir> it'd solve the "ram drive door into case" use case that infinity has too.
[10:25] <Mithrandir> since I don't think there are macs with those kinds of cases?
[10:26] <Mithrandir> (yes, we have really small use cases like somebody having such a case on a pegasos or something, but those are uncommon enough that I won't special-case it)
[10:26] <Kamion> I was going to say, yes, my Pegasos has that kind of case
[10:31] <Mithrandir> I don't see how I can accomodate that without making the UI suck for everybody, though.
[10:31] <Mithrandir> (and I think cases with doors are an abomination :)
[10:34] <childe> I don't know if this is a bug
[10:34] <childe> When I start the gnome-terminal, it's 80x24. After I created a new tab then close the new tab, it changed to 80x25
[10:35] <childe> It will get larger and larger if I repeat this steps
[10:36] <childe> Does this worth a bug report?
[10:37] <Kamion> sounds like it, yes, if there isn't already one reported
[10:37] <robitaille> https://launchpad.net/distros/ubuntu/+source/gnome-terminal/+bug/35342
[10:37] <Ubugtu> Malone bug 35342 in gnome-terminal "Geometry size of the terminal window increases (dapper)" [Unknown,Unconfirmed]
[10:37] <mjg59> infinity: Hurrah
[10:38] <childe> Nice
[10:39] <robitaille> I like that bug...the really poor man's way of resizing a terminal :)
[10:40] <mantiena-baltix> Hi all
[10:40] <sivang> morning all
[10:42] <mantiena-baltix> it seems daily dapper doesn't start since Friday (Mar 24). Should I report a bug ?
[10:43] <mantiena-baltix> I'm about live cd
[10:44] <Kamion> known, should've been fixed yesterday by Tollef's udev change
[10:45] <hunger> Hmmm... beagle takes lots of space! Is there a way to reduce that?
[10:45] <hunger> I.e. by having a global index for shared stuff in addition to the privat one?
[10:46] <mantiena-baltix> Kamion, thanks for info, yesterdays live CD still not starts, but I can try todays if you think, that todays live CD should start
[10:46] <Kamion> yesterday's was before the fix
[10:46] <Kamion> today's should be better, but I haven't tested yet
[10:47] <mantiena-baltix> OK, so I will download and test - it's not hard for me ;)
[10:47] <Mithrandir> today's works.
[10:47] <Kamion> good
[10:47] <Mithrandir> at least, it works for me.
[10:48] <Mithrandir> apart from the unionfs bug.
[10:48] <mantiena-baltix> Mithrandir, what unionfs bug ?
[10:49] <Mithrandir> mantiena-baltix: /sbin becomes mode 0700 when the initramfs moves a file about
[10:50] <mantiena-baltix> Mithrandir, will this bug cause some problems during live CD startup ?
[10:50] <Mithrandir> mantiena-baltix: no, not really.  It'll just cause the live cd to behave a little bit erratically since /sbin is then mode 0700
[10:55] <mantiena-baltix> Btw, I think Live-CD should have one more entry in startup menu, for booting in sort of "safe" mode :) Now there are lots of problems when booting on various laptops, especially with new AMD Turion CPU's
[10:55] <mantiena-baltix> should I report a bug about this ?
[10:56] <mjg59> mantiena-baltix: What do you mean by "problems", and what would this safe mode do?
[10:56] <mantiena-baltix> main problem is, that Live CD doesn't start at all :)
[10:57] <Kamion> safe modes are usually bogus, they're often unsafe on hardware different from what the safe mode designer was using
[10:57] <mantiena-baltix> second problem is, that clock is running 2x faster, and because of this Music/Video and games looks very funny, but are unplayable :)
[10:57] <Kamion> surely a better bug report would be "please fix the live CD on AMD Turion CPUs" :-P
[10:57] <mjg59> mantiena-baltix: That'll be fixed in the next kernel upload
[10:58] <mantiena-baltix> mjg59, problems with 2x clock speed will be fixed in the next kernel upload ?
[10:58] <mjg59> Yes
[11:01] <siretart> what part of gnome handles hotkeys and starts programs? I'd like to reassign bug 20939 to the correct package
[11:01] <Ubugtu> Malone bug 20939 in evolution "evolution doesn't use seahorse-agent when started by hotkey instead of gnome-panel or shell" [Normal,Needs info]  http://launchpad.net/bugs/20939
[11:01] <infinity> mjg59: Oh, there's talk on the -users list of a newer powernowd (available in sid) being required for proper behavior on Core Duo and some Athlon X2 CPUs...
[11:01] <Kamion> oh yes, I have a pending UVF exception request for that
[11:01] <Kamion> any second opinions on it?
[11:01] <mjg59> infinity: Yes - I thought someone had already asked oh what he said
[11:02] <mjg59> Kamion: Given the number of dual core systems shipping, we probably want it
[11:02] <Kamion> have folks tried it out on non-dual-core systems?
[11:02] <infinity> Kamion: No new bugs in Debian yet, and it's been cooking there for a week.
[11:02] <sivang> pitti: ping
[11:03] <pitti> hey sivang
[11:03] <sivang> hey martin!
[11:03] <sivang> I'll PM you
[11:03] <infinity> Kamion: I could give it a spin on my single-core Centrino laptop.
[11:04] <mjg59> infinity: Did the initramfs-tools issue ever get sorted? (The one where an upgrde from breezy stamps all over RESUME=)
[11:05] <infinity> mjg59: The upgrade has been preserving RESUME= since Feb 17, according to the changelog.
[11:05] <mjg59> infinity: Excellent
[11:05] <Kamion> mjg59: it's a configuration file now, and we suck RESUME= out of the old conffile on upgrade before trashing it
[11:06] <infinity> mjg59: And it even works right.  Just dist-upgraded a friend's machine earlier today, no conffile prompt, RESUME properly set.
[11:06] <infinity> \o/
[11:06] <infinity> (Hideous hack, though)
[11:06] <mjg59> Yay!
[11:07] <Mithrandir> infinity: how can I tell the kernel (or init) to reboot?  From the initramfs.
[11:07] <infinity> Good question.  I'm not that familiar with klibc's init.
[11:08] <mjg59> infinity: On the other hand, failed resumes currently seem to trash swap - I'm sure we used to mkswap that?
[11:09] <jordi> mjg59: wow dude
[11:09] <infinity> mjg59: My failed resume didn't trash the swap..
[11:09] <jordi> when I went to bed last night you were already talking about suspending and swap :)
[11:09] <mjg59> infinity: Hm. Maybe it's just if RESUME= isn't set
[11:09] <infinity> mjg59: That's possible.
[11:09] <hendry> are there some Ubuntu tools to diff an Ubuntu package with Debian's SID package of the same name?
[11:09] <mjg59> If there's no RESUME, we currently suspend but then refuse to resume (and they end up with no swap)
[11:10] <infinity> mjg59: Special...
[11:15] <infinity> mjg59: We could start fiddling with the possibility of autodetecting the resume partition...
[11:15] <mjg59> infinity: Mm
[11:15] <infinity> mjg59: But that's always struck me as a bit dangeours.
[11:15] <mjg59> Yes
[11:15] <infinity> Dangerous, too.
[11:15] <Mithrandir> infinity: oh, it's a syscall, apparently.
[11:16] <infinity> Then again, "I just lost my resume data because I dual-boot two hibernated OSs" probably isn't as ciritcal as some may want you to believe.
[11:16] <infinity> No worse than a power outage.
[11:17] <infinity> (And if you are the sort that wants to dual-boot two hibernated OSs, you can manually set resume= ..)
[11:18] <infinity> Seems a crazy corner case to worry about, and not necessarily worth worrying about, when autodetection of resume data would be a win for everyone else...
[11:18] <mjg59> infinity: Yeah
[11:18] <jordi> carlos: got my mail re: the Debian GNOME thing? If you replioed, I missed it with the outage.
[11:19] <Kamion> infinity: if we do that, it would be nice to make sure that the installer sets it up safely (as in, won't trash another hibernated OS) if it can
[11:19] <infinity> mjg59: Alternately, in the "hey, that's a sketchy idea" department, do we have some unused space hiding in a superblock of the root filesystem where we could encode the location of the resume partition when we hibernate?
[11:19] <mjg59> infinity: Ngh.
[11:20] <carlos> jordi: not yet, but the answer is yes, you can remove me
[11:20] <mjg59> infinity: That would probably depend on the filesystem...
[11:20] <infinity> mjg59: Well, it would tie the root to the resume, which is really what we want here.
[11:20] <jordi> carlos: ok
[11:20] <jordi> carlos: don't reply then :P
[11:20] <mjg59> infinity: What we /really/ want is for grub to check for a file and then automatically append that to the kernel command line
[11:20] <infinity> mjg59: Yeah, or that.
[11:20] <mjg59> That would be great
[11:21] <mjg59> Get on it
[11:21] <mjg59> I'm sure we could find all sorts of other uses, too
[11:21] <infinity> mjg59: There's nothing stopping me from mounting the root FS to poke around it, of course.
[11:21] <infinity> mjg59: So it doesn't have to be grub at all.  I could just mount /, poke at a file that knows what the resume parititon is, then carry on.
[11:21] <mjg59> infinity: Uh. Yes there is.
[11:21] <mjg59> You'll replay the journal and then the FS will explode
[11:21] <carlos> jordi: ok
[11:22] <infinity> mjg59: Oh, poo.  Even if I mount it ro?
[11:22] <mjg59> Yes
[11:22] <mjg59> grub doesn't replay journals, so it's safe to do it there
[11:22] <mjg59> Also xfs and jfs
[11:22] <mjg59> jfs refuses to mount until it's been fscked
[11:24] <infinity> mjg59: I don't dig grub-only solutions either, though.
[11:24] <Mithrandir> mjg59: that should be easy enough to do.
[11:24] <infinity> I suppose we could start chaning initrds, and have hibernate create a tiny one with nothing but the resume config file.
[11:24] <mjg59> infinity: Yeah, just dump another cpio file on the end
[11:25] <Mithrandir> you could just continue doing that.
[11:25] <mantiena-baltix> Kamion, when I'm talkin about "sort of safe mode", then I mean standart live CD mode with some parameters, like noapic nolapic
[11:25] <Mithrandir> so your initramfs would grow forever (by about 1 or 2 blocks per hibernate)
[11:25] <mjg59> infinity: that would also let us pass a list of block numbers for suspending to swapfiles
[11:25] <infinity> Mithrandir: That sounds..  (I'm talking not only AMD Turion case)
[11:28] <mantiena-baltix> btw, does dapper livecd use swap partition if there are suspend data inside ?
[11:28] <Kamion> mantiena-baltix: that actively breaks machines other than yours
[11:28] <Kamion> mantiena-baltix: so no, that's not a "safe mode"
[11:28] <Kamion> if your machine needs the APIC to do interrupt routing, turning it off will make it a SAD panda
[11:31] <mantiena-baltix> Kamion, I'm not wanna to make "safe mode" as default
[11:31] <TheMuso> c/
[11:31] <Kamion> mantiena-baltix: I don't want to have a combinatorial explosion of "safe mode" boot options for all the different sets of boot options people might need
[11:32] <mantiena-baltix> Kamion, btw, this is not my machine - previous week I went to computer shop and was dissapointed, because Ubuntu Live CD didn't started on majority of new laptops :(
[11:32] <Treenaks> mantiena-baltix: dapper or breezy live CD?
[11:32] <Kamion> "noapic nolapic" breaks some machines. Other machines need different parameters. The correct solution is *not* to add more and more boot options, but to fix the damn problems
[11:33] <mantiena-baltix> Kamion, but it seems we can't fix these problems, because of new hardware
[11:33] <Kamion> mantiena-baltix: we can't psychically determine which boot options are going to be necessary on new hardware in the future
[11:34] <Kamion> picking one that happens to be needed on some hardware now is not an option
[11:36] <mantiena-baltix> sorry, my child is crying now :(
[11:41] <mjg59> mantiena-baltix: We can fix most of these problems
[11:43] <hunger> When will NM finally work with interfaces set to dhcp in /etc/network/interfaces?
[11:44] <hunger> Having to comment stuff out there is somewhat annoying... as it breaks the interfaces for non-NM use (i.e. when doing system recovery).
[11:46] <infinity> hunger: It's meant to work with interfaces that are set to DHCP *and* auto, afair.
[11:46] <hunger> infinity: For me NM stopps responding whenever it seen "iface whatever inet dhcp" in a line.
[11:47] <infinity> hunger: With the packages in the archive, or with the 0.6 packages that people have been tossing around?
[11:47] <hunger> infinity: and it should not work on auto interfaces at all: Those are meant to be up and stay up.
[11:47] <hunger> infinity: The stuff in the archive.
[11:57] <siretart> hunger: I think the policy was that nm should ignore interfaces handled by ifupdown, because they solve  fundamentally different use cases
[11:58] <siretart> hunger: btw, we had yesterday some discussion at our regulars table about xen. do you know if the xen kernel patch would/should apply cleanly to the ubuntu kernel?
[12:00] <hunger> siretart: it won't.
[12:00] <siretart> :(
[12:01] <doko_> Kamion, Mithrandir: shutdown/reboot on the live CD doesn't work. which package should be used for reports?
[12:01] <Mithrandir> doko_: "doesn't work" is not an error message.
[12:01] <hunger> siretart: At least it did not when last time I tried. I gave up on it for the time being since I couldn't get a full-featured xen-kernel of a version close to ubuntu's to compile properly at all.
[12:02] <siretart> hunger: I'm curious, where can I find out about the status for inclusion into the mainline kernel of xen?
[12:02] <hunger> siretart: NM should ignore "auto" interfaces IMHO.
[12:02] <hunger> siretart: Those without the auto flag should be handled by NM IMHO.
[12:02] <doko_> Mithrandir: that was not my question, but anyway, it hangs after displaying "Stopping kernel log daemon" and ejecting the CD
[12:03] <hunger> siretart: There is a mercurial repository for the merge work.
[12:03] <siretart> hunger: I rather think that NM should ignore any interfaces listed in /etc/network/interfaces. It makes no sence to ifup an interface which is already handled by NM
[12:03] <hunger> siretart: No!
[12:03] <Mithrandir> doko_: don't file a bug, it's already filed and we discussed how to fix it a few hours ago
[12:04] <Kamion> doko_: on the live CD, don't expect anyone to be able to even tell you which package to use unless you describe the bug properly ...
[12:04] <hunger> siretart: Start up in single user mode and you will be happy to have ifup.
[12:04] <Kamion> there are too many packages involved for that
[12:04] <hunger> siretart: When going singleuser you usually do not have the time to figure out network settings:-)
[12:05] <hunger> but then since ubuntu does not have single user mode anyway... you might be right:-)
[12:05] <siretart> hunger: isn't dbus (+ ancestors) started in single user mode as well?
[12:05] <hunger> siretart: It definitly should not.
[12:05] <siretart> hunger: why?
[12:05] <hunger> siretart: possible that it is, but it shouldn't.
[12:05] <siretart> again, why? I think it should.
[12:06] <hunger> siretart: Because it does not help to have that stuff meddle with a system that is disfunctional.
[12:06] <hunger> siretart: dbus is one of the really few things not started in rcS.d
[12:07] <siretart> so your rationale is that single user mode should be some sort of 'failsafe' startup mode. Even then I think you could start dbus easily with /etc/init.d/dbus start, which will start NM as well
[12:07] <siretart> hunger: the fact that NM cannot be configured without an x-session is a lack of a seriously required feature.
[12:07] <hunger> siretart: You can... but it won't work when i.e. /usr is not there.
[12:08] <hunger> siretart: When going single-user the system usually is in a very bad state after all.
[12:08] <siretart> so mount it then :) - seriously, if your system is so broken that it cannot mount even usr/, you should be able to configure your interfaces with /sbin/ip as well
[12:09] <hunger> siretart: Keeping the "requirements" low is essential then. Some stuff might just be broken.
[12:09] <hunger> siretart: I can.
[12:09] <siretart> hunger: NM has very high requirements. better don't use this in environments like you describe
[12:09] <hunger> siretart: But when a system breaks I have enough werries getting it runnig again.
[12:09] <Kamion> is there a way to use a different cellrenderer for each row in a GtkTreeView?
[12:10] <hunger> siretart: I can not use the extra trouble to set up interfaces at that time.
[12:10] <Kamion> I need to do this because each cell is in a different language, so (AFAIK) I need to set the language on each cellrenderer to get proper rendering for RTL languages
[12:11] <Kinnison> Kamion: if you can know if the language is RTL, you could insert the unicode RTL character into the display name?
[12:11] <Kamion> not without a sucky big table
[12:11] <hunger> siretart: Ever had a customer breathing down your neck when trying to fix their "mission-critical" infrastructure?
[12:11] <hunger> siretart: Ever tried to find out the IP of the box at such a time?
[12:11] <Kinnison> Kamion: the cellrenderer is at liberty to add other controls to the cell, yes?
[12:11] <Kamion> I'd rather just let pango figure it out if possible
[12:12] <Kamion> Kinnison: can you elaborate?
[12:12] <Kinnison> Kamion: IIRC a treeview can have any gtk widgets you want in the cells
[12:12] <Mithrandir> infinity: hmm, casper-md5check doesn't seem to be able to get anything back when doing a getchar().
[12:12] <Kinnison> Kamion: so couldn't you set the language on a gtklabel you put in the cell?
[12:12] <siretart> hunger: again, I don't consider NM mature enough for such environments (yet).
[12:12] <hunger> siretart: OK, usually such a box has no gui (and no NM), but you know how customers are...
[12:13] <siretart> hunger: there are design issues like this..
[12:13] <Kinnison> Kamion: it's a couple of years since I last played with treeviews though. I can look if you want
[12:13] <Kamion> Kinnison: oh, er, I guess. The CellRenderer interface is data => gtk.gdk.Drawable though so that sounds complicated
[12:13] <hunger> siretart: Yes. At the moment it is not. But the decissions made now will carry on in the debs for a long time.
[12:13] <Kinnison> Kamion: urgh, sounds like pygtk is being helpful for you
[12:13] <Mithrandir> infinity: but if I switch to tty1 and press a key, it reboots.
[12:13] <Mithrandir> (as it should)
[12:14] <Kamion> Kinnison: you can if you like; basically I want to make the language selection box look right
[12:14] <seb128> carlos: you are right, it used normal spaces for it ....
[12:14] <hunger> siretart: "Nichts haelt laenger als ein Provisorium" :-)
[12:15] <Kinnison> Kamion: give me a few minutes to familiarise myself with treeviews again
[12:15] <siretart> hunger: I'm not sure if they are installed by default at all, but even if they are, I think implementation makes sure that the user HAS to comment their interfaces out in order to use it with NM
[12:15] <siretart> hunger: :)
[12:16] <hunger> siretart: NM is happy with the interfaces removed...
[12:17] <carlos> seb128: that's bad...
[12:17] <hunger> siretart: And the "old" NM used the interfaces file to grab default values from (i.e. static IP or dhcp) or so I was told.
[12:17] <carlos> seb128: that means that we need to do something special as we do with tabs (\t)
[12:17] <hunger> siretart: That no longer works since NM chokes on the file.
[12:18] <carlos> seb128: what do you think?
[12:19] <hunger> siretart: and whatever you say: choking on a valid configuration line is a bug.
[12:19] <seb128> carlos: I think rosetta should make the difference between spaces and unbreakable spaces clear somewhat, using a special glyph for it or something
[12:19] <hunger> siretart: It might interpret it, it might ignore it, but it may never stop its job.
[12:19] <seb128> carlos: but dunno what you can technically do
[12:20] <carlos> seb128: that's what I'm suggesting
[12:20] <infinity> Mithrandir: Oh, fun
[12:20] <Mithrandir> infinity: should/will the initramfs behave differently than the regular boot here?
[12:20] <seb128> carlos: so that's a good suggestion imho
[12:21] <carlos> seb128: the problem is that it only appears with the translation, or is there any way to automatically detect when a normal space in an english strings should appear as a unbreakable spaces?
[12:21] <infinity> Mithrandir: On an installed system, the whole boot process tends to happen on tty8 (though I now question the sanity of that, and have half a mind to just move it over to tty1), so keystrokes pass through just fine, since usplash and init are all happily on the same tty.
[12:21] <hunger> siretart: The xen linux merge repository (mercurial) is here: http://xenbits.xensource.com/ext/linux-2.6-merge.hg
[12:21] <infinity> Mithrandir: There's a fair chance that anything runinng in the initramfs is bound to tty1, and it's not until we exec the real init that we end up on tty8, or something equally cute.
[12:22] <seb128> carlos: that's described by the feature request I sent :p
[12:22] <infinity> mjg59: Was there ever a sane and rational explanation for running usplash on tty8?
[12:22] <carlos> seb128: did you file it again?
[12:22] <seb128> carlos: used before ";:!? " chars and after "".
[12:22] <Mithrandir> infinity: yeah, I guess.  Should I just do an open on /dev/tty8 and try to read from that instead?
[12:22] <mjg59> infinity: So people could press alt+f1 to get rid of it
[12:22] <seb128> carlos: dude, I gave you the URI to the bug on the other chan
[12:22] <mjg59> (Not that that really seems to work, but still)
[12:23] <carlos> seb128: do you know the languages that use unbreakable spaces? (other than french)
[12:23] <seb128> no
[12:23] <infinity> mjg59: Sure, but Alt-F2 would get rid of it too.
[12:23] <carlos> seb128: to the new bug?... I missed it... sorry :-(
[12:23] <infinity> mjg59: Oh, but not if you only have one VC at that point.  I see.  Is that a use case that actually matters? :)
[12:23] <seb128> carlos: np :)
[12:24] <infinity> Mithrandir: That would probably work, but is hackish, and is encoding a bit much about usplash in your app (so if I move usplash to another VC, you break)
[12:24] <infinity> mjg59: All the complaints about "usplash times out and I'm stuck on tty8 and don't know what to do!" and other oddities would vanish if we didn't do the VC switch.
[12:25] <mjg59> infinity: I think that ought to be fixed by making sure it changes back to vt1 on timeout...
[12:25] <infinity> mjg59: Well, if it times out, it's meant to switch back, but put some other "icky stuff happened" in there.
[12:25] <Kinnison> Kamion: If you had a pangolayout would that help?
[12:25] <mjg59> infinity: I'm more thinking of the "If you want to see messages, press this" use case
[12:26] <infinity> mjg59: The fact that tty8 has no shell, no login banner, and utter confusion for anyone who sees it means that dumping people there by accident EVER seems bad.
[12:26] <mjg59> I guess that could just cause usplash to exit instead
[12:26] <mjg59> So, uh.
[12:26] <Kinnison> Kamion: then again, even gtk_paint_layout needs a widget, never mind
[12:26] <infinity> mjg59: Well, pressing alt-f1 won't get you meesages anyway, since the boot seems to be happily running on tty8 at that point.
[12:26] <siretart> hunger: thanks
[12:27] <carlos> seb128: http://en.wikipedia.org/wiki/Non-breaking_space
[12:27] <carlos> seb128: seems like we should be using also for other languages....
[12:28] <carlos> althought French is the only one with fixed rules that we can do automatically
[12:28] <seb128> nice :)
[12:28] <seb128> yeah
[12:28] <Mithrandir> infinity: casper-md5check knows a bit too much about usplash already, though.
[12:28] <infinity> Mithrandir: Yeah, I know. :/
[12:29] <Mithrandir> but as long as it's a single other app, it's not too bad.  If there was a plethora, we'd need to make a library or something
[12:29] <infinity> Mithrandir: Anyhow, for other reasons (as discussed above), I've been considering moving usplash to tty1 anyway, so if that makes it work, yay.
[12:29] <Kinnison> Kamion: aha, got it
[12:29] <Mithrandir> I'd assume it fixes it.
[12:30] <Mithrandir> infinity: is that a trivial change?
[12:30] <infinity> Mithrandir: Easy enough to test, remove the "-c" from usplash's command line in the initramfs script.
[12:30] <Kinnison> Kamion: you need a cell-data-function to set the language for the GtkCellRendererText before each cell is rendered
[12:30] <Mithrandir> infinity: excellent, thanks
[12:31] <Kinnison> Kamion: http://scentric.net/tutorial/sec-treeview-col-celldatafunc.html may help
[12:31] <Kamion> Kinnison: ah, cheers
[12:33] <Kinnison> Kamion: I *knew* there was something to do what you needed :-)
[12:33] <Kinnison> Kamion: I was on the verge of writing a replacement for GtkCellRendererText but then I realised what you needed :_)
[12:33] <Kamion> I'll have a go at that after coffee, then
[12:34] <Kamion> then I really need to get onto apt-setup work
[12:35] <Kamion> doko_: oh, so what you're saying in #36973 is that it doesn't say "What language do you speak?" or whatever anywhere?
[12:36] <Kamion> I understand then - I thought you meant that the selector box contents were empty or something
[12:42] <jvw> Kamion: the lintian lab stuff is quite annoyingly fragile etc anyway, I'd rather get rid of that and replace it with something decent then keeping that alive :-/
[12:42] <hunger> My screen freezes when switching virtual desktops. Is that a known problem?
[12:43] <hunger> The windows still refresh, but the switching gets stuck for up to several secounds.
[12:44] <hunger> Could that be the kernel starving the X server? I read on LWN that such a problem was fixed recently.
[12:44] <sladen> mjg59 / infinity: switching back to tty1 and a login prompt was in the original spec/requirements
[12:45] <sladen> infinity: probably better to keep the original log messages on tty1
[12:45] <doko_> Kamion: yes, it's a minor thing
[12:49] <infinity> sladen: Sure, but the way it is now (and has been since it was implemented), the log messages are on tty8.
[12:58] <Mithrandir> infinity: losing -c fixes it.
[01:12] <sladen> Kamion: when's the next Flight due out?
[01:14] <Kamion> sladen: Wednesday, I believe; Mithrandir will be doing it
[01:15] <Kamion> sladen: it's better to just set the source package to the empty string than to set it to ubuntu-meta, if it's a general problem with the distribution
[01:15] <Mithrandir> sladen: tomorrow, yes.
[01:17] <sladen> Kamion: oops sorry, it's specifically ubuntu-minimal
[01:18] <Kamion> no it's not
[01:18] <Kamion> surely?
[01:18] <Kamion> is it really a flaw with the dependencies of the ubuntu-minimal binary package?
[01:18] <Kamion> oh, sorry, so it is ... that acpi-support thing
[01:18] <Kamion> ok, never mind me then
[01:20] <sladen> Kamion: yeah, it's actually dependant on a policy decision that I don't know the answer of;  eg.  should power-management work on machines without a desktop installed.  Eg. how minimal is minimal.
[01:23] <Mithrandir> oh, roxxors.
[01:23] <Mithrandir> 29203 fixed.
[01:26] <doko_> pitti: are you working on #24999?
[01:27] <pitti> bug 24999
[01:28] <pitti> doko_: I hope that I can find some time for doing priting bug triage, but not right now
[01:28] <pitti> and I'm lost with hplip stuff anyway
[01:31] <doko_> pitti: should I assign it to me?
[01:32] <pitti> doko_: that would make me (and even more the people who suffer from this) very happy :)
[01:50] <ogra> Mithrandir, the current edubuntu i386 live stops booting with: "+ set - thermal udev" and hangs there
[01:50] <Kamion> ogra: should be fixed next rebuild
[01:50] <ogra> oki
[01:51] <ogra> i guess thats on all livecds then ...
[01:54] <infinity> Mithrandir: Great, then I'll poke at some usplash changes in the next day or two, including dropping the VT switch.  It's been responsible for all sorts of workarounds elsehwere too.
[01:55] <Mithrandir> infinity: if you manage to fix the "usplash is killed by init" bug too, I'll love you forever.
[01:55] <Mithrandir> (almost)
[01:55] <infinity> Mithrandir: That'll be included in the same round of "looking at usplash bugs".
[01:55] <Mithrandir> thanks
[01:56] <Mithrandir> infinity: do you have a bug about it or should I reassign the casper one?
[01:56] <infinity> Reassign away.  Not sure if I have any open bugs as reminders.
[01:56] <Mithrandir> done
[01:58] <ogra> urgh
[01:58] <ogra> the install CD stops at the keymap selector ...
[01:59] <Kamion> also fixed yesterday
[01:59] <Kamion> you can work around it by selecting the test option first
[02:00] <Mithrandir> I'll be offline for an hour or so, I have to return the Korean keyboard to the embassy.  I'll have my phone with me if anything urgent pops up.
[02:00] <Kamion> ogra: you sure these are really today's images?
[02:00] <ogra> Kamion, nope, keeps me in an ednless loop
[02:00] <Kamion> 20060328
[02:00] <sladen> ogra: given a URL like http://hwdb.ubuntu.com/?xml=835a2d0b2d075ce4051a553f1211537a  how do I get the raw information?
[02:01] <ogra> Kamion, my rsync finished 10min ago :)
[02:01] <Kamion> ogra: because I'm *sure* we fixed these issues. please investigate?
[02:01] <ogra> sladen, wget  http://hwdb.ubuntu.com/835a2d0b2d075ce4051a553f1211537a.xml.bz2
[02:02] <ogra> Kamion,
[02:02] <ogra> ogra@edubuntu:/media/usbdisk/isos/edubuntu$ ls -l
[02:02] <ogra> total 4188776
[02:02] <ogra> -rw-rw-r-- 1 ogra ogra 723585024 Mar 28 01:47 dapper-install-amd64.iso
[02:02] <ogra> -rw-rw-r-- 1 ogra ogra 722837504 Mar 28 01:49 dapper-install-i386.iso
[02:02] <ogra> -rw-rw-r-- 1 ogra ogra 711081984 Mar 28 01:52 dapper-install-powerpc.iso
[02:02] <ogra> -rw-rw-r-- 1 ogra ogra 714768384 Mar 28 02:00 dapper-live-amd64.iso
[02:02] <ogra> -rw-rw-r-- 1 ogra ogra 717029376 Mar 28 02:01 dapper-live-i386.iso
[02:02] <ogra> -rw-rw-r-- 1 ogra ogra 695783424 Mar 28 02:02 dapper-live-powerpc.iso
[02:02] <ogra> definately tonights images
[02:03] <Kamion> please investigate, then
[02:03] <ogra> yep
[02:13] <nyu> hi
[02:13] <nyu> is dapper the equivalent of debian sid?
[02:14] <nyu> or is there a bleeding edge somewhere else
[02:16] <Treenaks> We have no edges that bleed more than dapper's edge (in Ubuntu, currently)
[02:16] <nyu> besides, debian debootstrap only seems to support breezy and older.  is "ln -s breezy dapper" known to work?
[02:16] <nyu> (in /usr/lib/debootstrap/scripts
[02:16] <nyu> )
[02:16] <nyu> Treenaks: ah ok
[02:16] <nyu> i'd like to setup a chroot rather than installing the full thing
[02:18] <ogra> Kamion, the version of kbd-chooser seems right (kbd-chooser_1.23ubuntu9)
[02:18] <ogra> and i dont see any special stuff in /var/log/syslog ... :/
[02:23] <infinity> nyu: You're better off just installing the dapper debootstrap on Debian.
[02:24] <infinity> nyu: It's an arch:all package, there's no reason it shouldn't work.
[02:24] <ogra> (or instrall breezy and upgrade ;) )
[02:25] <ogra> *install
[02:26] <Kamion> nyu: the dapper script isn't quite the same as the breezy script
[02:26] <Kamion> -      base="apt binutils cpio cpp cpp-4.0 dpkg-dev g++ g++-4.0 gcc gcc-4.0 gcc-4.0-base ${LIBC6}-dev libdb4.2 libgdbm3 libstdc++6 libstdc++6-4.0-dev linux-kernel-headers make patch perl perl-modules"
[02:26] <Kamion> +      base="apt binutils cpio cpp cpp-4.0 dpkg-dev g++ g++-4.0 gcc gcc-4.0 ${LIBC6}-dev libgdbm3 libstdc++6 libstdc++6-4.0-dev linux-kernel-headers make patch perl perl-modules"
[02:26] <Kamion> -    echo >"$TARGET/var/lib/dpkg/available"
[02:26] <Kamion> +    : >"$TARGET/var/lib/dpkg/available"
[02:26] <Lure> mjg59: any progress on HP laptop (1GMB RAM) hibernate issue with -19?
[02:27] <infinity> Lure: Looks like he has a patch that fixes it (tested here on my Thinkpad with 2GB of RAM with good results), and it should be in the nexr kernel upload.
[02:27] <nyu> Kamion: ah, i thought the package selection was dynamic (Priority: required filter)
[02:27] <HiddenWolf> infinity: a laptop with 2gb ram?
[02:27] <infinity> Lure: Are you using a -686 kernel?
[02:27] <infinity> HiddenWolf: Yes, I like RAM.
[02:27] <HiddenWolf> infinity: wtf!
[02:27] <Kamion> nyu: it is, but the segment above is for the buildd variant
[02:27] <nyu> infinity: ok will try that if this one fails
[02:27] <Lure> infinity: great - I use 386 currently
[02:28] <Kamion> nyu: we haven't made that part dynamic yet due to lack of archive support
[02:28] <ogra> ahh
[02:28] <ogra> hmm
[02:28] <nyu> Kamion: ok no problem, i want the normal variant
[02:28] <infinity> Lure: Oh, nevermind then.  I was just going to toss you the test kernel I built, that's all.  But I only built the 686 flavour.
[02:29] <infinity> Kamion: What do we have against using "build-essential" in the buildd variant again?
[02:29] <Lure> infinity: I can upgrade to 686 - where can I get the package (I would really like this fix in Flight6)
[02:29] <Kamion> infinity: it's not actually what we want?
[02:29] <infinity> Kamion: Most people will want it there anyway (to catch updates to build-essential when they upgrade their chroot)
[02:29] <Kamion> oh, I suppose we could *include* it, but it's not sufficient on its own
[02:29] <Kamion> because debootstrap shouldn't depend on --resolve-deps
[02:29] <infinity> Kamion: Oh, yeah, I suppose not.
[02:30] <Kamion> infinity: file me a bug, I'll look at it
[02:30] <Lure> infinity: is it supposed to fix also DF5 install CD hand in usplash (or is this unrelated)?
[02:30] <infinity> But then I assumed whoeever maintains debootstrap had their reasons. :)
[02:31] <infinity> Lure: Err, no idea what bug you're referring to now..
[02:32] <Lure> infinity: https://launchpad.net/bugs/34592
[02:32] <ogra> Kamion, hmm
[02:32] <ogra> Kamion, there are no german keymaps at all ...
[02:33] <ogra> funnily the rest seems to be there
[02:33] <Kamion> ogra: er, no idea about that, sorry
[02:33] <Lure> infinity: and hibernate is this: https://launchpad.net/bugs/34587
[02:33] <ogra> Kamion, err, sorry, i shouldnt look for german in qwerty :)
[02:34] <infinity> Lure: Ahh, well, since that can't possibly be a kernel bug (it's in the bootloader, before the kernel is even touched), I'm afraid this test kernel won't fix it.
[02:34] <ogra> Kamion, but using en_US seems to work flawless
[02:35] <Lure> infinity: ok, so only hibernate - where can I get your fixed 686 version (just to confirm)
[02:35] <Kamion> ogra: kbd-chooser is working fine for me on today's Ubuntu image
[02:35] <infinity> Lure: Uploading it now...
[02:36] <ogra> Kamion, it doesnt for me using french, german or spanish.... but en_US works
[02:36] <Kamion> ogra: what did you select in the bootloader (just so that I can try to duplicate this)?
[02:37] <Kamion> ah, yes, German fails for me too
[02:37] <ogra> try french
[02:37] <infinity> Lure: http://people.ubuntu.com/~adconrad/linux-image-2.6.15-19-686_2.6.15-19.29_i386.deb
[02:37] <Kamion> presumably it'll fail the same way German does, so I won't bother for now
[02:37] <ogra> hmm, now spanish works here :/
[02:37] <ogra> thats really strange
[02:39] <Kamion> it's invaluable for d-i debugging
[02:40] <ogra> yes, but vi always forget that you can use it as bootoption :)
[02:41] <Treenaks> ogra: 'vi'? not 'I'?
[02:41] <Lure> infinity: thanks - downloaded - will report back...
[02:41] <ogra> Treenaks, :P
[02:42] <janimo> do you know if more fine grained upload rights vs uni/main are on LP roadmap?
[02:43] <infinity> janimo: So people can be given rights to a specific set of packages, etc?
[02:43] <janimo> like say people who can touch xfce packages only (expressed as a list for examole)
[02:43] <janimo> infinity: yes
[02:43] <infinity> janimo: I think it's been discussed, but I don't think it's urgent enough to happen right away (we still have a lot of real bugs to squash before going back to feature implementation)
[02:44] <janimo> infinity: good to hear that it's been discussed
[02:44] <janimo> at least
[02:45] <infinity> Finer-grained ACLs have been discussed all over the place, so derivates that are hosted in the Ubuntu archive (like Kubuntu and Xubuntu) can have some control over build retries, CD triggers, and other scary things, but all of this will take some time to think about how to do securely and in a fashion that won't upset the current flow.
[02:46] <infinity> janimo: (eg: If giving derviatives the ability to retry builds or trigger CDs led to someone retrying a build over and over again that crashed buildds, I'd be miffed)
[02:46] <infinity> janimo: So, yeah.  Derivative ACLs.  On the table.  Nowhere near out of the discussion stage. :)
[02:47] <janimo> infinity: ok. I don;t grok the big picture of the LP/soyuz infrastructure, so I was thinking maybe upload is separate enough of the rest of the platform to be tackled independently
[02:48] <janimo> but I understand it is a lot of work so for now I am happy with the answer
[02:48] <infinity> janimo: Well, it could be tackled seperately, but the whole thing needs to be discussed anyway (and is perhaps best dealt with as a logical unit), so... <shrug>
[02:48] <Kamion> ogra: oh, I think I see it; some bits of kbd-chooser think that the loadkeys_wrapper function is an int, while others think it's a void
[02:48] <janimo> it's just that there is a possibility of one or two xfce uploader sidekicks, now when xfce is almost in main :)
[02:48] <Kamion> easy fix
[02:49] <infinity> janimo: For now, the goal is still "make the Ubuntu main uploaders as happy with soyuz as they were with dak", which is still going to require some more bugfixing and optimising, so I suspect "new features that dak never had" will have to wait until after dapper's release.
[02:49] <nyu> Kamion: is localechooser going to be synced with debian?  I got fixes merged in 1.06 that i'd like in ubuntu too
[02:49] <Kamion> nyu: unlikely at this point, although I can backport individual fixes. Catalan, right?
[02:49] <nyu> Kamion: erm, sorry, I mean I sent fixes to deb BTS that are to be merged soon
[02:49] <janimo> infinity: I did not even dream of this being done for dapper ;)
[02:50] <nyu> Kamion: yeah.  it's a one-liner
[02:50] <infinity> janimo: Nothing wrong with you acting as a sponsor (which also means you can verify the correctness of the uploads) for those people.
[02:50] <Kamion> nyu: OK, added to my to-do list
[02:50] <nyu> Kamion: want me to file a bug or something?
[02:50] <janimo> infinity: sure that's how we'll continue
[02:50] <Kamion> nyu: if you like, yeah
[02:50] <ogra> Kamion, oh, how did you find that ... even with DEBCONF_DEBUG set my syslog looks ok (apart from the kbd-chooser failed message)
[02:50] <nyu> Kamion: ok thank you
[02:50] <infinity> janimo: In general, I prefer to see lots of sponsorship (if it also means mentoring and verification), rather than more and more people in the keyring who may or may not be fully up to speed.
[02:50] <nyu> Kamion: it is alright to file bugs referring to debian BTS for details, or duplicating the info / patch is needed?
[02:51] <janimo> infinity: yes the person I am talking about has quite some sponsored uploads already
[02:51] <janimo> I try convincing him to become a MOTU at least
[02:51] <infinity> janimo: Never hurts to have more. :)
[02:51] <Kamion> ogra: looked through the debconf trace, figured out that it was probably the run of kbd-chooser-apply from kbd-chooser.postinst at fault; edited /var/lib/dpkg/info/kbd-chooser.postinst to stick a sleep in there to confirm this; then eyeballed the code
[02:52] <ogra> ah, k ... so i didnt dig deep enough
[02:52] <infinity> janimo: Lots of us spent months (or even years) being sponsored in Debian before we could upload directly.  While this annoys some people, I found it was very educational to get shot down and told off on a regular basis by people more informed than I.
[02:52] <Kamion> nyu: file a bug with a brief summary, then use the "Link to Other Bug Tracker" option down the right-hand side of the page
[02:52] <nyu> Kamion: ah, nice. ok
[02:53] <infinity> janimo: (And now I do the telling off, and the circle is complete... Isn't that thpethial?) :)
[02:53] <janimo> I suppose :)
[02:53] <Kamion> ogra: also I was made suspicious by the reported exit code of 147, which is normally "killed by SIGSTOP"; since that's implausible here, I reckoned it must be a random exit code, and void/int confusion is a classic cause for that
[02:54] <janimo> aha silvester lisping
[02:54] <ogra> ah, k, so also a matter of experience :)
[02:54] <nyu> !seen jbailey?
[02:54] <nyu> ~seen jbailey
[02:55] <ogra> nyu, no bot
[02:55] <nyu> oh :)
[02:55] <nyu> any human can tell me if Jeff comes here sometimes?
[02:55] <ogra> yup, he does
[02:55] <nyu> okie
[02:57] <nyu> just in case someone likes to know: debian debootstrap can handle dapper fine with a "ln -s breezy /usr/lib/debootstrap/scripts/dapper"
[02:58] <Kamion> hopefully we can get a dapper script into Debian debootstrap reasonably soon
[02:58] <Kamion> aj's been helpful in the past
[03:03] <mjg59> Lutany: Should be fixed in the next kernel relese
[03:04] <nyu> jordi: there?
[03:04] <nyu> jordi: ca_FR and ca_AD in ubuntu locales need a sync, there are some improvements/bugfixes that went into debian but are not in your version
[03:05] <nyu> jordi: notable, ca_FR@euro and ca_AD@euro shouldn't exist, and it'd be nice to have ca_IT as well
[03:05] <nyu> *notably
[03:06] <jordi> they should be synced entirely
[03:06] <nyu> that's fine
[03:06] <mjg59> Ugh.
[03:06] <nyu> jordi: do we keep your name in there?  i don't really care
[03:06] <jordi> shrug
[03:06] <mjg59> Lutany: Sorry, wrong person
[03:06] <jordi> as you wish
[03:06] <nyu> well, since this isn't in glibc upstream yet i suppose it doesn't matter
[03:07] <nyu> when it's added it'll superceed it
[03:07] <nyu> is it a problem for ubuntu to remove these @euro variants?  they should have never been created in first place
[03:08] <nyu> because upstream will not accept them
[03:09] <jordi> I don't think
[03:10] <jordi> nyu: re: names, I guess you can keep both. Put me in the maintainer field if you like. I want to submit a patch for ca_ES too, it's way too large.
[03:10] <jordi> I need to submit ast_ES as well
[03:11] <nyu> why the 3-letter variant, conflict?
[05:22] (Sirex2/#ubuntu-devel) is this the corrent place to ask if there's plans to revent the 64bit ubuntu's 32bit library handleing to 32bit-> /lib 64bit ->/lib64 like other distros ? and/or why it is how it is currently ?
[05:25] <Yagisan> Sirex2: Ubuntu has a pure 64bit system. Other distros are hybrid 32bit/64bit
[05:25] <Yagisan> Sirex2: Why go backwards ?
[05:25] <jordi> Riddell: ping
[05:26] <Sirex2> er... because some of my programs are 32bit ?
[05:26] <jordi> Riddell: there's a request to import katapult translations into the *product*. Is this correct? Is rosetta the place where katapult translations are meant to be kept?
[05:27] <Sirex2> i mean, is it possible to take the nice pure 64 bit system, and make it a 32bit hybrid without that chroot nightmare ?
[05:27] <Yagisan> Sirex2: chroot ? ia32-libs-* ? file a bug on the program for non-portability ? I usually do 1 and 3 myself
[05:27] <Yagisan> Sirex2: chroots are very simple things
[05:27] <Sirex2> well, one example program i use is secondlife which is closed source and 32bit.
[05:28] <Kamion> Sirex2: there are plans to implement multiarch so that using 32-bit programs on an amd64 installation is less painful, yes
[05:28] <Riddell> jordi: was that Mez?  he's the "upstream" admin for katapult but it's maintained only for kubuntu at the moment so it wouldn't surprise me if he requested translations on rosetta
[05:28] <Kamion> but it will take some time to do.
[05:28] <Yagisan> Sirex2: usually ia32-libs-* is all you need for those
[05:28] <jordi> yes
[05:28] <Yagisan> Sirex2: works for doom3 for me eg
[05:28] <jordi> Riddell: can you set the Rosetta flag on, if it's official?
[05:29] <Riddell> jordi: how do I do that?
[05:29] <Kamion> Riddell: could you please tell bzr your real name? it's really weird to be merging from "Ubuntu LiveCD user"
[05:29] <Sirex2> ill check it out. i prob have already, but im under win32 atm so need a reboot
[05:29] <jordi> Riddell: Define launchpad usage, in the product pages
[05:30] <jordi> Kamion: heh
[05:30] <jordi> Riddell: katapult imported
[05:31] <Kamion> Riddell: also, please write a debian/changelog entry; you know better than I what you did
[05:32] <Riddell> jordi: do I hvae to do that or can Mez?
[05:32] <Riddell> Kamion: ok
[05:32] <Kamion> janimo: in fact, you *shouldn't* cut out packages which are in universe. The seeds express the desired state, not necessarily the current state
[05:32] <janimo> Kamion,ok
[05:32] <Kamion> Riddell: (let me know when you have, and I'll merge that lot)
[05:35] <jordi> Riddell: you're in the team who owns the product
[05:35] <jordi> I guess you can
[05:38] <Kamion> Riddell: what version of espresso-kbd-chooser did you have installed?
[05:39] <Kamion> looks like an old one, from the line numbers
[05:41] <Kamion> Riddell: yeah, in fact you have espresso-keyboard-setup installed, which is dead and superseded by espresso-kbd-chooser, which actually works now
[05:41] <Riddell> ah hah
[05:45] <doko_> Riddell: what are these KDE system: URLs?, can these be replaces by file:// ?
[05:46] <seb128> Kinnison: Daaaaaaaaniiiieel
[05:46] <Kinnison> seb128: yah?
[05:46] <seb128> Kinnison: https://launchpad.net/distros/ubuntu/+source/metacity/+bug/36497
 giftnudel: looks like the problem is caused by debian/patches/010-transience-for-plugs.patch, well at least metacity works fine here w/o that patch applied
[05:46] <seb128>  lapo lakin
[05:46] <seb128> ups, extra line copied too :p
[05:46] <seb128> Kinnison: please fix you crasher patch :)
[05:47] <Kinnison> seb128: ooh did I break it?
[05:47] <seb128> whoever did debian/patches/010-transience-for-plugs.patch
[05:47] <seb128> that's you?
[05:47] <Kinnison> yep that's me
[05:48] <ogra> phew ... wasnt me :)
[05:48] <seb128> thank you
[05:49] <Kamion> tepsipakki: I've applied your apt-setup local repository patch upstream, BTW
[05:52] <Riddell> doko: nasty troublesome things, KDE should translate them to file:/ but doesn't seem to always do so
[05:54] <seb128> Kinnison:
 seb128: I can reproduce it in galeon (closing the window that spawned a 'what app do you want to open this file with' dialogue)
[05:55] <Kinnison> seb128: thanks
[05:55] <seb128> Kinnison: galeon upstream gets the crash too which the case described
[05:56] <herzi_x41> seb128: ping
[05:56] <seb128> herzi_x41: pong
[05:57] <herzi_x41> seb128: can you include the patch from http://bugzilla.gnome.org/show_bug.cgi?id=336254 into the GTK+ package, please? It's a simple two-liner
[05:58] <seb128> herzi_x41: are you in a hurry? ie: is that a "today would be nice", or with next upload works fine for oyu?
[05:58] <herzi_x41> with the next upload would be fine
[05:58] <herzi_x41> it's just annoying warnings while developing for me
[05:59] <seb128> ok, will do
[05:59] <herzi_x41> thanks a lot
[06:02] <Riddell> Kamion: you can merge now
[06:02] <Riddell> I'm assuming I can't change that "ubuntu live CD" commit very easily
[06:02] <Kamion> nah, just leave that
[06:03] <jordi> Kamion: hmm. When was the last time you pulled translations from d-i svn?
[06:03] <jordi> Kamion: Catalan seems to be a bit outdated. Does that make sense?
[06:04] <Kamion> jordi: UVF
[06:04] <jordi> Kamion: makes sense.
[06:04] <Kamion> I've selectively pulled newer versions of certain packages
[06:04] <Kamion> but only where it isn't a large amount of work to do so
[06:04] <jordi> Kamion: ok, I pointed translators at seppy's webpages in case they want to pull the lates.
[06:04] <jordi> +t
[06:04] <Kamion> jordi: bear in mind that I only routinely pull translations from Rosetta for Ubuntu-specific strings
[06:05] <Kinnison> seb128: okay I can reproduce the crash, I'll try and fix it
[06:05] <Kamion> jordi: it causes me far too much work to pull everything, I'm afraid
[06:05] <seb128> Kinnison: cool
[06:05] <jordi> Kamion: yeah. Well, if it happens, great, if not, oh well.
[06:05] <jordi> Kamion: Catalan had 200 missing strings
[06:09] <Kamion> jordi: a fair number of those would have been in espresso, I'm guessing?
[06:10] <nyu> Kamion: i think he's gone already
[06:10] <Kamion> Riddell: righto, merged, thanks
[06:11] <jordi> Kamion: I'll tell you in a min...
[06:12] <nyu> jordi: eps.  i get 403
[06:12] <nyu> erm, 401
[06:12] <doko> Riddell: how? system:/home/foo -> file:///home/foo? (system: -> file:// ?)
[06:13] <Riddell> doko: yes, KDE should do that before it launches the app, but doesn't seem to for some reason, I need to look into it
[06:13] <doko> Riddell: ok, I'll add a workaround for now
[06:41] <Kinnison> seb128: that should do it
[06:42] <seb128> Kinnison: fixed?
[06:42] <Kinnison> seb128: yep, uploaded
[06:42] <seb128> you rock :)
[06:42] <Kinnison> seb128: well, it corrects it on my machine
[06:42] <seb128> feel free to close the bug
[06:43] <HiddenWolf> Can anyone tell me if the behavior of volume keys was recently changed?
[06:44] <seb128> it was not
[07:01] <kmon> Hello. I can't play dvd's on dapper (kubuntu) amd64 anymore. I could a few days ago. Is this a known bug?
[07:01] <Riddell> kmon: using what program?
[07:01] <kmon> kaffeine
[07:01] <Riddell> does it work in xine?
[07:02] <Riddell> kaffeine hasn't changed recently, don't think xine has either
[07:02] <kmon> I don't have xine installed (only libs)
[07:03] <kmon> I think it's related to a recent hal
[07:04] <kmon> but i'm guessing, really
[07:04] <kmon> audio cd's play fine though
[07:05] <j^> seb128 looked at switching the default password char from * to ?
[07:06] <mvo> Kamion: is there anything else you need for apt and the installer beside the fix for the "0s remaining" when apt repots it's progress? I'm preparing a new upload now
[07:06] <kmon> ....
[07:08] <Kamion> mvo: "Downloading" => "Retrieving" would be nice
[07:09] <Kamion> can't immediately find a bug about it, although I'm sure somebody filed one
[07:09] <mvo> Kamion: ok, done
[07:09] <Kamion> basically it says "Downloading" even when it's retrieving files from the CD
[07:09] <Kamion> thanks
[07:10] <seb128> j^: built a package with the change but didn't try it yet, it's on my list, any hurry?
[07:12] <j^> seb128 not hurry just wanted to know, i guess some apps will needs fixing. those using glade, since glade right now defaults to add default values to the glade file, so they have it set to *
[07:12] <j^> the more time to find those the better
[07:20] <j^> on my system i can find 225 glade files that set <property name="invisible_char" translatable="yes">*</property>
[07:21] <Kamion> I maintain one of those; should I be removing that property, or changing it, or what?
[07:21] <j^> since its set to the default it should be removed
[07:21] <j^> that way one can change the system default
[07:22] <Kamion> but if I edit the file with glade again (which I will), won't glade put it right back?
[07:23] <j^> i filed a bug about that and its a general glade bug that it puts default values into the glade files
[07:23] <Kamion> I don't want to have to edit the file by hand every time I edit it with glade, and I don't want to get all my contributing developers to do the same
[07:23] <j^> but since one should use gazpacho anyway...
[07:23] <Kamion> glade doesn't always write out default values ...
[07:24] <Kamion> gazpacho would be that thing that used to crash all the time on me so people told me to use glade, right? :)
[07:24] <j^> its gnome bug #335702
[07:24] <Ubugtu> Gnome bug 335702 in general "Don't output default values in .glade files" [Normal,Unconfirmed]  http://bugs.gnome.org/show_bug.cgi?id=335702
[07:25] <j^> Kamion its better these days...
[07:25] <Kamion> well, I'm not switching over at this point in the lifecycle of my application
[07:27] <j^> possibly one can strip it in with a make/make install hook
[07:29] <Riddell> is there something stopping packages entering the archives?
[07:31] <Kamion> Riddell: any package in particular?
[07:33] <Riddell> kerry and network-manager 0.6
[07:35] <Kamion> Riddell: NEW queue
[07:35] <Kamion> Riddell: and I asked you to pass on a message about kerry a while back
[07:35] <Kamion> 15:48 < Kamion> Riddell: can you pass this on to whoever's packaging kerry? the binaries in the NEW queue contain this file:
[07:35] <Kamion> 15:48 < Kamion> -rwxr-xr-x root/root       104 2006-02-27 14:00:53 ./usr/shutdown/beagled-shutdown.sh
[07:35] <Kamion> 15:48 < Kamion> that needs to be moved somewhere FHS-compliant
[07:36] <Kamion> I haven't checked over network-manager yet; the binaries only hit NEW less than two hours ago
[07:36] <Riddell> I must be confusing source NEW with binary NEW
[07:36] <Riddell> kerry is being worked on
[07:37] <Tonio_> Riddell: means we can now revu network-manager-kde ;)
[07:37] <Tonio_> Riddell: I'll ping lure for latest source package from suse
[07:37] <j^> network-manager should not works as long as wpasupplicant is in universe
[07:37] <Kamion> right, they're both in binary NEW
[07:37] <Kamion> j^: which it isn't
[07:37] <Kamion> I promoted that this morning
[07:37] <Lure> Tonio_: what do you need?
[07:37] <Tonio_> Lure: the *promissed* tarball from the suse guy
[07:38] <Kamion> Riddell: normally I wave binaries through NEW pretty quickly but I tend to stall them if they violate the FHS or some such
[07:38] <Tonio_> to update knetworkmanager on revu and get it revu now it shouldn't ftbfs anymore
[07:38] <Lure> Tonio_: I have sent you in e-mail, but anyway I have the patch to build too
[07:38] <Lure> Just running now
[07:38] <Tonio_> Lure: checking, sorry, I'm just back home :)
[07:39] <Lure> Tonio_: I can upload my source package to your system - I just did not remove dialUp (I may just add kppp instead)
[07:39] <Tonio_> Lure: updating the package
[07:39] <Tonio_> Lure: want to use kppp finaly ? nm-applet doesn't have any ppp feature anyway
[07:40] <Kamion> I've accepted network-manager binaries now
[07:40] <Lure> Tonio_: not yet, but debian team is interested to get this addressed to (mbiebl)
[07:40] <Tonio_> Lure: okay
[07:40] <Lure> Tonio_: but we can drop for now, and return back later (to reduce expectations)
[07:41] <Lure> Tonio_: do I upload my source package or do you need just patch?
[07:41] <Tonio_> Lure: hum......... I can do them, butif you already did :) just send me
[07:42] <Tonio_> Lure: I checked, and including kpp ability isn't just a link, there is a complte conection reading and launching management to perform...... that's not just a little patch :)
[07:42] <Lure> Tonio_: ok, will forward port noDIalUp patch too
[07:42] <Lure> btw, should we move to #kubuntu-devel ;-)
[07:43] <Tonio_> Lure: thanks :)
[07:43] <Tonio_> Lure: agree ;)
[08:20] <mroth> sladen: ping
[08:24] <_ion> Wow, the network-manager build-deps are still broken?
[08:26] <jjesse> mako: ping again, did you get my email?
[08:26] <sladen> mroth: just ask the question!
[08:28] <neuralis> jjesse: he's been really bad about responding to e-mail lately, i imagine he's horribly busy
[08:28] <Lure> _ion: dependancy was resolved, now it does not build (one patch should be droped)
[08:28] <Burgwork> neuralis, jjesse mako is always busy and always bad to get a hold off
[08:28] <Burgwork> jjesse, is it in regards to the book?
[08:29] <jjesse> Burgwork: yup i'm waiting to hear back from jono and mako on things deb and it alked about
[08:29] <Burgwork> ah
[08:29] <jjesse> just more changes to the Kubuntu chapter
[08:30] <sladen> mjg59: can you ask kiko to merge/delete http://launchpad.net/people/old  which seems to be a ghost alter-ego of you
[08:30] <sladen> mroth: ping
[08:30] <kiko> mjg59, yo
[08:30] <mroth> sladen: wanted to ask you re: hotkey-setup automatically modprobing uinput and nvram, and loading /usr/sbin/thinkpad on boot.  is this "to be implemented", or is it a bug it is currently not happening on my thinkpad? (want to know whether to file it)
[08:31] <Lure> _ion: Riddell uploaded fixed version (dropped 20_xxx.patch) and now it builds
[08:32] <Lure> _ion: see: https://launchpad.net/+builds/+build/180455
[08:33] <sladen> mroth: /me presses the volume-up key and notices that it isn't working.  hmmm
[08:35] <sladen> mroth: doesn't seem to work over hibernate.  I'll pop some options into /etc/acpi/resume.d/
[08:35] <sladen> mroth: it /should/ be working otherwise
[08:35] <mroth> sladen: doesnt get loaded on boot for me
[08:36] <mroth> nvram and uinput are not loaded, and thinkpad-keys is not executed   (if i do them all manually, it all works)
[08:36] <sladen> mroth: naach.
[08:36] <mroth> I don't know what 'naach' means, but it doesnt sound like a happy noise ;-/
[08:39] <sladen> mroth: can you paste me  $ sudo sh -x /etc/init.d/hotkey-setup start 2>&1 | tail   privately
[08:42] <mroth> sladen: yes, but not until later--the machine is at home and I'm at work currently, sorry
[08:43] <mroth> knew i should have brought it today, heh
[08:46] <sladen> mroth: yup, if it's easier, file a bug and I'll catch it later.  Yes it /should/ be working... :)
[08:47] <mroth> sladen: ok.  hotkey-setup is the correct package, yes?
[08:49] <sladen> mroth: yes
[08:54] <mako> jjesse: which one?
[08:55] <mako> Burgwork, jjesse: i'm a bit behind on book related mail.. i've got a list of priorities i'm working through (from deb) that included finishig ch06, a revision on ch01, and then a list of other things
[08:58] <Burgwork> mako, ok
[09:00] <mako> so i'm proceeding through things, and email about the book, in that order :)
[09:01] <jjesse> mako: thanks for letting me know, deb was just asking if you responded to my email i sent you and jono
[09:45] <mdz> doko: what happened to the progress bar in the OOo splash?
[09:55] <mdz> Kamion,sabdfl,mjg59: TB
[09:56] <elmo> sabdfl has gone to dinner with mbp, I doubt you'll get him
[09:56] <mdz> does anyone have mjg59's number?
[09:57] <Treenaks> 59! *hides*
[09:57] <elmo> he's around, I think?
[09:59] <mjg59> mdz: Yup
[10:00] <zyga> hey ubuntueros
[10:22] <Pygi> pitti: around?
[10:22] <Pygi> _ion: ping
[10:23] <Seveas> Pygi, please please switch to NM 0.6.2
[10:23] <Pygi> Seveas: that's what I wanted to discuss, thank you very much  ^_^
[10:24] <Seveas> hehe, rock
[10:24] <Seveas> it has the patch I was talking about previously
[10:24] <Pygi> Seveas: now, awake pitti and -
[10:24] <Pygi> _ion, preety please
[10:24] <swat_> hi guys, got a problem with libnl/libnl-pre6
[10:25] <danimo> moin
[10:25] <trappist> is there some kind of utf smileys not supported by my locale?
[10:26] <Pygi> Seveas: I suppose n-m 0.6.2 won't help you to get network running at ur work?
[10:27] <Seveas> yes it will!
[10:27] <Pygi> Seveas: hm, fine ;)
[10:27] <Pygi> I shall discuss it with pitti and ion ;)
[10:28] <Seveas> fwiw: 0.6.2 is mostly a bug-fix release with a few new features.
[10:28] <Pygi> Seveas: are we capable of doing good work on QA for 0.6.2 in such a lill' time? :-/
[10:28] <Seveas> not less than for .1
[10:28] <Lure> Seveas: +1
[10:29] <Pygi> hm, ok ^_^
[10:29] <Lure> not sure if we need to wait for Keybuk to be back...
[10:29] <Seveas> yes you should - he's the NM god ;)
[10:29] <Lure> or can pitti or somebody else make decision on this
[10:30] <pitti> Pygi, _ion: re
[10:30] <pitti> I couldn't even look at 0.6.1, since it didn't build anywhere
[10:30] <Pygi> pitti: built now
[10:30] <pitti> but this should be mainly Keybuk's and mdz's call
[10:31] <Pygi> pitti: ah,k, I'll ping them then ;)
[10:31] <Pygi> joy, I am constantly pinging someone ;)
[10:31] <Pygi> mdz: around perhaps? ;)
[10:32] <Lure> Pygi - the n-m submarine sonar guy ;-)
[10:32] <Pygi> Lure: hehe ^_^
[10:32] <Pygi> It would be great if we could include 0.6.2 now when it's out ;)
[10:33] <Pygi> Seveas: should be no reason why we wouldn't be allowed to do that, since it's not such a big change from .1, no?
[10:33] <Lure> Pygi: we are in UVF - therefore it requires UVF exception as anything else
[10:33] <seb128> Pygi: usually update request are documented, like changelog since previous version, NEWS entry, rational
[10:34] <seb128> Pygi: you can't expect people to agree without nowing what the changes are
[10:34] <Pygi> seb128: yes, agreed ^_^ changes are: lots of bugfixes, and support for dynamic WEP ;)
[10:35] <seb128> Pygi: what I said, ChangLog since previous version, NEWS entry and rationnal make easy for somebody to have a look and confirm what you say
[10:35] <Pygi> seb128: who do I ping this time to ask if it can be updated if we make pacakges?
[10:35] <Pygi> hm,kk
[10:35] <Treenaks> Pygi: are there any APs that do dynamic WEP?
[10:36] <seb128> Pygi: UVF requests are for Kamion and mdz usually
[10:36] <Pygi> seb128: thanks, now I need to ping even more people ^_^
[10:36] <Pygi> Treenaks: Not sure ^_^
[10:37] <Lure> Treenaks: used often in corporate environment (Seveas needs it for example)
[10:37] <seb128> Pygi: talking to Keybug and mdz seems to be right for nm
[10:37] <Seveas> Keybug...
[10:37] <Seveas> nice typo :
[10:37] <Pygi> seb128: Keybuk ;)
[10:37] <seb128> Pygi: just prepare what I said, changelog and rationnal
[10:37] <Pygi> lol :-P
[10:37] <Treenaks> Lure: Seveas needs WPA and/or 802.1x afaik :)
[10:37] <Pygi> seb128: k, will look into it ;)
[10:38] <Seveas> Treenaks, dynamic wep == 802.1x
[10:38] <Lure> exactly
[10:38] <Treenaks> Seveas: uhr... sure?!
[10:38] <Seveas> Treenaks, nm needs a gui redesign to support all wpa/802.1x/EAP options completely
[10:38] <Seveas> they hacked in this bit for now after I complained about it not being supported ;)
[10:40] <Seveas> Treenaks, actually 802.1x is more than that, but what w_s calls 802.1x is now supported in n_m
[10:42] <Pygi> k, found the changes for 0.6.2 ;)
[10:42] <Pygi> joy ;)
[10:52] <j^> Pygi 0.6.2 patch for debian bug #36871
[10:52] <Ubugtu> Error: I tried to send you an empty message.
[10:52] <Pygi> j^: will look now
[10:53] <Pygi> j^:  link perhaps?
[10:53] <j^> not debian bug Ubugtu its an ubuntu bug  #36871 for the debian dir
[10:53] <j^> https://launchpad.net/distros/ubuntu/+source/network-manager/+bug/36871
[10:53] <Ubugtu> Malone bug 36871 in network-manager "NetworkManager 0.6.2 released" [Normal,Unconfirmed]
[10:53] <Pygi> k, will look
[10:54] <j^> other than that change to the ubuntu backend all patches still apply cleanly
[10:54] <Pygi> j^: perhaps, but does this patch contains code for applet as well?
[10:55] <j^> and i use it here for some time now. with the hostap patches though (malone bug 36708)
[10:55] <Ubugtu> Malone bug 36708 in network-manager "[PATCH]  wpa_supplicant needs to know about hostap driver" [Normal,Unconfirmed]  http://launchpad.net/bugs/36708
[10:55] <j^> Pygi code for applet?
[10:56] <Pygi> j^: ah, nvm
[10:56] <Pygi> lemme checkout the patch
[10:56] <Pygi> j^: is this entire patch to bring .1 to .2???
[10:56] <KaiL> network-manager, wpasupplicant and friends are a bit buggy, or?
[10:57] <j^> Pygi replace .orig and you can use the debian dir from .1 yes
[10:58] <j^> to make hostap work there is also a need to blacklist orinoco_pci(malone bug 36718)
[10:58] <Ubugtu> Malone bug 36718 in module-init-tools "blacklist orinoco_pci" [Normal,Unconfirmed]  http://launchpad.net/bugs/36718
[10:59] <Pygi> j^: will look into it
[10:59] <j^> KaiL once it works it ok, but in general the wireless drivers tend to be outdated
[10:59] <j^> many solved problems on there own.
[10:59] <j^> nm tries to bring that together now, which in some cases takes quite a long time.
[10:59] <KaiL> j^, well, I just found 3 bugs - and that only in an WEP-WLAN
[11:00] <Pygi> KaiL: please fill bugs if they are not duplicates, and gimme bug number
[11:00] <KaiL> Pygi, 37067 and 39069
[11:00] <Pygi> j^: more n-m bugs ?
[11:00] <j^> KaiL which version are yu using?
[11:00] <Pygi> bug 37067
[11:00] <Ubugtu> Malone bug 37067 in network-manager "wpasupplicant required, not recommened" [Normal,Unconfirmed]  http://launchpad.net/bugs/37067
[11:00] <Pygi> bug 39069
[11:01] <j^> Pygi sure
[11:01] <KaiL> bug 37069
[11:01] <Ubugtu> Malone bug 37069 in network-manager "network-manager doesn't set WLAN-Config at all" [Normal,Unconfirmed]  http://launchpad.net/bugs/37069
[11:01] <KaiL> :)
[11:01] <KaiL> sorry
[11:01] <j^> bug 36777 and 36710
[11:01] <Ubugtu> Malone bug 36777 in network-manager "[PATCH]  silence wpa_supplicant messages in syslog " [Normal,Unconfirmed]  http://launchpad.net/bugs/36777
[11:01] <Seveas> KaiL, wpa_supplicant changed a bit, you may need to edit your configuration
[11:02] <KaiL> Seveas, should that be done automatically while installing it?
[11:02] <Pygi> KaiL: bug 37067 is deprecated... it is recommended
[11:02] <Ubugtu> Malone bug 37067 in network-manager "wpasupplicant required, not recommened" [Normal,Unconfirmed]  http://launchpad.net/bugs/37067
[11:02] <Seveas> KaiL, that is a bug - explained on the bugtracker or the -devel list
[11:02] <KaiL> Pygi, tried to use network-manager 0.6 for a WEP-LAN without?
[11:02] <Seveas> someone prematurely uploaded an unfinished version of wpa_supplicant
[11:03] <j^> nm 0.6 depends on wpasupplicant, that should be changed
[11:03] <KaiL> Seveas, you mean, a version, which talks more than every woman can? ;)
[11:03] <Pygi> j^: nm has wpasupplicant as recommended
[11:03] <j^> Pygi thats what i say it has to be in Depends:
[11:04] <Pygi> j^: no, not really ... it was there, and we decided to move it ^_^
[11:04] <j^> why, it breaks silently without it
[11:04] <KaiL> Pygi, it's even required for WEP, which isn't obvious
[11:04] <Pygi> KaiL: Not really sure it's needed for WEP :-/
[11:04] <j^> as long as recomended packages are not installed by defaul
[11:04] <j^> Pygi it is,
[11:05] <Pygi> Seveas: can you confirm that wpasupplicant is needed for WEP?
[11:05] <KaiL> Pygi, at least the connection-try stops very soon without
[11:05] <Seveas> Pygi, I cannot, nor can I deny
[11:05] <mdz> Pygi: keybuk returns Thursday
[11:05] <KaiL> not, that it works much better with (as you can see in the other bug...)
[11:06] <j^> Pygi read the code, it uses wpasupplicant to connect WEP networks
[11:06] <j^> it even uses wepsupplicant to scan for networks
[11:06] <Pygi> mdz: k, can you help?
[11:06] <Pygi> j^: hm...
[11:07] <KaiL> Pygi, did you get the query with the third bug number?
[11:07] <Pygi> KaiL, j^: please post me all bug numbers related to new N-M in a private message, so I can confirm it
[11:07] <Pygi> KaiL: yes, will look now
[11:07] <j^> Pygi why dont you just look at https://launchpad.net/distros/ubuntu/+source/network-manager/+bugs
[11:07] <Lure> Pygi: just subcribe to network-manager package and you will get all of them
[11:08] <Pygi> K, just did
[11:08] <j^> or to sort by date https://launchpad.net/distros/ubuntu/+source/network-manager/+bugs?orderby=-datecreated
[11:08] <Pygi> KaiL: private message please ;)
[11:08] <pitti> Pygi: https://launchpad.net/people/<yourid>/+packagebugs is very helpful, too
[11:08] <Pygi> o pitti is alive ;)
[11:09] <KaiL> Pygi, how privat?
[11:09] <Pygi> KaiL: bah, nvm
[11:10] <Pygi> pitti: can you confirm that we need wpasupplicant for WEP?
[11:11] <pitti> Pygi: no idea, but I doubt it; nm 0.5.1 didn't need it
[11:11] <Pygi> pitti: this is 0.6 branch :-/ A lot could have been changed :-/
[11:11] <tseng> what does wpasupplicant have to do with wep?
[11:11] <ogra> they both start with W ?
[11:11] <tseng> thats about it.
[11:11] <j^> pitti 0.5 did not need it 0.6 does
[11:12] <j^> the backend in 0.6 is quite diffrent
[11:14] <Pygi> I am currently looking at all n-m bugs
[11:24] <ThomS> hi, does anyone know of a bug involving firefox and evolution repeatedly opening spontaneously?
[11:25] <Seveas> ThomS, voodoo!
[11:26] <mario_> this is so weird  :-/
[11:27] <KaiL> ...and network-manager 0.6 should take care, that the (renamed) nm-applet get's updated too imho
[11:28] <ThomS> Seveas: Haha it must be, I've tried rebooting etc, they just keep opening really quickly for a bout 7 instances at random times, its making my system unusable
[11:28] <Pygi> huh, how should this be explained?
[11:28] <Pygi> bug 32817
[11:28] <Ubugtu> Malone bug 32817 in network-manager nm-applet "nm-applet takes over cd drive?" [Normal,Unconfirmed]  http://launchpad.net/bugs/32817
[11:29] <Pygi> somebody was drunk? :--
[11:29] <Pygi> :-/
[11:30] <KaiL> he started nm-applet from a shell in /media/cdrom? ;:)
[11:31] <j^> anyway 0.6 does not restart, so he should reopen it if it happens again
[11:31] <Pygi> KaiL: I think I'll reject this :-S
[11:31] <Pygi> or need more info :-/
[11:31] <Pygi> bah
[11:32] <KaiL> ask, if he ever could reproduce it ;)
[11:32] <Pygi> this bug is so weird ;)
[11:35] <Pygi> bug 35225
[11:35] <Ubugtu> Malone bug 35225 in network-manager "Wireless WEP connection ask for password when the network goes down and returns" [Normal,Unconfirmed]  http://launchpad.net/bugs/35225
[11:35] <Pygi> known behaviour of N-M ... anyone have more info?
[11:36] <KaiL> had that here too, but I thought, it only didn't save the key, as the connection fails..
[11:36] <j^> if it does its more a problem with gnome-password-manager
[11:36] <LaserJock> mdz: do I need to get a FF exception for a bug fix NEW package for multiverse?
[11:37] <KaiL> interesting, I have different icons for cable-network here - most systems show just 2 computers, only one system (installed yesterday from flight 5) shows something like an rj45-plug
[11:39] <KaiL> slightly off-topic: do we have a problem to power off APM-only computers, or is that my crappy hardware?
[11:43] <Pygi> joy, so much bugs to check out
[11:47] <Pygi> ok, a lot of bugs solved
[11:47] <Pygi> j^: around?
[11:47] <KaiL> personal Todo: accept, that this PCMCIA-WLAN-Card IS dead
[11:48] <j^> KaiL pcmcia is broken in dapper
[11:48] <j^> it only works if you put the card in the slot before booting up
[11:48] <j^> Pygi pong
[11:49] <KaiL> ah, that explains something
[11:49] <Pygi> j^:  can you provide proper patch to bug 36777
[11:49] <Ubugtu> Malone bug 36777 in network-manager "[PATCH]  silence wpa_supplicant messages in syslog " [Normal,Unconfirmed]  http://launchpad.net/bugs/36777
[11:49] <KaiL> and after the system is up, the card already overheaded (bug in the card), so no chance to try it on my WLAN - bad
[11:51] <KaiL> j^, uhm, wait - a 54MBit card should be PC-Card, or? And so should still work?
[11:52] <j^> Pygi thats fixed in 0.6.2
[11:52] <Pygi> j^: k, will reject
[11:52] <Pygi> hm, will not :-/
[11:52] <Pygi> we don't have 0.6.2 yet
[11:53] <j^> In Progress is fine
[11:53] <KaiL> Pygi, to make it even more complicate, that's more of less my "friend"...
[11:53] <Pygi> KaiL: hm :-/
[11:55] <Pygi> KaiL, j^: please look up unconfirmed bugs, and see if you can confirm
[11:55] <Pygi> thanks
[11:55] <Pygi> https://launchpad.net/distros/ubuntu/+source/network-manager/+bugs
[11:55] <Pygi> I'll sleep for a few secs, and I'll be back ;)
[11:58] <swat_> anyone else got this problem with libnl
[11:58] <Pygi> swat_: what one?
[11:59] <swat_> well it refuses to install
[11:59] <Pygi> :-P
[11:59] <swat_> which means networkmanager doesn't work
[11:59] <Pygi> networkmanager does work :-/
[11:59] <Pygi> what error do you get?
[11:59] <KaiL> bug 34458 - I guess, it he misses ndis
[11:59] <Ubugtu> Malone bug 34458 in network-manager "Netgear WG511 v2 not supported on Flight 5 Live CD" [Normal,Unconfirmed]  http://launchpad.net/bugs/34458
[12:01] <Pygi> KaiL: set as "Need more info" and ask him to provide you with what you need
[12:01] <KaiL> esp. something to know, which hardware that really is - netgear is known to change their chips quite fast
[12:02] <Pygi> KaiL: ah