[01:39] <sfllaw> bddebian: Hi.  :)
[01:47] <tseng> hi sfllaw, welcome to ubuntu land
[01:48] <sfllaw> tseng: Thanks.
[01:48] <sfllaw> I'm Simon.
[01:48] <sfllaw> I don't think we've met before.
[01:49] <sfllaw> Or if we have, I've forgotten.
[01:49] <tseng> < Brandon
[01:49] <sfllaw> I have a terrible memory.
[01:49] <Kamion> nomed: at present there are one or two, but they're bugs
[01:49] <tseng> you just touched a beagle bug earlier, thats me
[01:49] <sfllaw> Ah.
[01:49] <tseng> i only know you from your blog, otherwise
[01:50] <Kamion> bmonty: we have a tool that tells us about binary packages that aren't built from source, and I run it periodically and act on it; no need for bug reports in that case
[01:51] <sfllaw> tseng: That's very cool.  Just reading your weblog now.
[01:52] <bmonty> Kamion: ok, I already submitted two bugs...I'll mark them as rejected
[01:52] <nomed> Kamion, hardcoded ubuntu username ?
[01:53] <nomed> Kamion, Mithrandir will know that for sure .. maybe you're interested too
[01:53] <nomed> bug #42118
[01:53] <Ubugtu> Malone bug 42118 in casper "allow custom HOST,USERNAME" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/42118
[01:54] <Kamion> nomed: no as it happens if you're talking about ubiquity I know it for sure
[01:54] <Kamion> nomed: but they're bugs and I'll fix them soon
[01:55] <nomed> Kamion, i was not talking about ubiquity directly ..
[01:55] <Kamion> nomed: yes you certainly were
[01:55] <Kamion> 18:21 < nomed> is there any part of ubiquity where the username is hardcoded ?
[01:55] <nomed> but if casper could allow different username and host 
[01:55] <nomed> then it could affect ubiquity too ..
[01:55] <nomed> Kamion, yes :)
[01:56] <nomed> but the bug has been reported in casper
[01:56] <nomed> that's what i meant :)
[01:56] <nomed> need to go now
[01:56] <nomed> cu all
[02:01] <Kamion> zul_: grr re bug 42020
[02:01] <Ubugtu> Malone bug 42020 in grub-installer "installer: grub password included as cleartext in menu.lst" [Major,Confirmed]  http://launchpad.net/bugs/42020
[02:01] <zul_> uh...yeah?
[02:01] <Kamion> I'm getting really fed up with having to go over my mail with a fine tooth-comb to make sure people aren't rejecting my bugs
[02:02] <Kamion> see my comments
[02:02] <zul_> sorry..
[02:02] <Kamion> after I've confirmed a bug on one of my packages, I really would appreciate people not rejecting it
[02:02] <zul_> it wont happen again
[02:02] <Kamion> thank you
[02:02] <mjg59> Kamion: Is there a mechanism for seeing who confirmed a bug?
[02:03] <Kamion> mjg59: link labelled "activity log" in the top left portlet
[02:04] <mjg59> Ah, ok
[02:04] <mjg59> Helpful
[02:04] <\sh> oh fck..now I see mjg59 and it gives me the punch in my face...
[02:05] <\sh> mjg59: the keys on the toshiba are not working anymore, but hibernating from script e.g. is working...
[02:05] <mjg59> \sh: Can you be a bit more precise than "not working"?
[02:06] <mjg59> All of the hotkeys, or just sleep/hibernate? Are they generating events in /var/log/acpid ?
[02:06] <\sh> mjg59: yes :) 
[02:06] <\sh> mjg59: the events are generated, hibernatebtn.sh is executed, but the real action in hibernate.sh is not 
[02:07] <\sh> mjg59: all buttons....(tested under kubuntu)
[02:08] <mjg59> Oh, right
[02:08] <mjg59> It's probably KDE being broken, then
[02:08] <\sh> hum? 
[02:09] <Kamion> zul_: sorry, I know it's mostly not you, just a build-up of apparently massive interest in my bugs over the last couple of weeks
[02:09] <\sh> don't tell me, that kde is fighting against shellscripts and acpi_fakekey?
[02:09] <mjg59> \sh: Something needs to catch the key event and trigger hibernation
[02:09] <mjg59> I'd guess klaptopdaemon or kpowersave or whatever it is this week
[02:11] <\sh> mjg59: so the fakekey event from acpi_fakekey is not catched properly from kde...because something important is not working...Hope I find a solution in the next three days...it's really painfull presenting kubuntu at linuxtag without a working laptop integration 
[02:12] <mjg59> \sh: I don't have time to do any KDE work
[02:12] <mjg59> But something needs to catch KEY_SUSPEND (linux keycode 205, not sure what the X keycode is) and trigger hibernate
[02:12] <\sh> mjg59: I don't blame you...:) 
[02:12] <mjg59> Ditto for KEY_SLEEP (linux keycode 142) and trigger sleep
[02:13] <mjg59> Or alternatively listen for HAL events that send BUTTONPRESSED HIBERNATE or BUTTONPRESSED SLEEP
[02:13] <mjg59> (or something like that)
[02:13] <Harti> https://launchpad.net/distros/ubuntu/+source/firefox/+bug/42151
[02:13] <Ubugtu> Malone bug 42151 in firefox "firefox-1.5.0.2 crashes on flash" [Normal,Unconfirmed]  
[02:20] <nix4me> the site in that bug works fine on my debian box with 1.5.0.2
[02:24] <mdke> seems to work here too, ubuntu
[02:26] <jmg> whats the correct way to file a bug requesting sync to something in debian unstable? if it isnt in universe and previously hasnt been in sid
[02:27] <crimsun> jmg: usually you'd follow the procedure for syncs on wiki/DeveloperResources, but it's not useful at this stage. When Eft opens, it'll be synced from Sid.
[02:27] <jmg> crimsun: ah, automagically
[02:28] <Harti> it a sound-prob. i have changed the "none" in /etc/firefox/firefoxrc to "aoss". when i change back to "none", then works firefox
[02:29] <jmg> crimsun: Want to take a nother crack at my alsa issue? :)
[02:29] <crimsun> Harti: the value aoss is not supported and will not work unless you have alsa-oss (universe) installed
[02:30] <Harti> but with "none" i have no multiple sounds (beep-media-player and flash-sound on websites)
[02:30] <crimsun> Harti: please address this with me in #ubuntu
[02:36] <bddebian> sfllaw: I's been a workin' massa :)
[02:38] <bddebian> sfllaw: Though apparently not to Kamion's standards :-(
[02:39] <crimsun> I've attached a debdiff to bug #41367, compiled it, and verified it fixes the reported issue if a developer with main upload privileges has time to take a peek.
[02:39] <Ubugtu> Malone bug 41367 in alsa-lib "dmix consumes 100% CPU with 32-bit userspace on 64-bit kernel" [Normal,Fix committed]  http://launchpad.net/bugs/41367
[02:43] <jmg> gah
[03:00] <sladen> crimsun: ooh, excellent!
[03:16] <bddebian> Damnit, where did everyone go?
[03:20] <LaserJock> I'm here bddebian 
[03:21] <bddebian> Heya LaserJock
[03:24] <robertj> bug #42110
[03:24] <Ubugtu> Malone bug 42110 in samba "home directories should be writable by default" [Normal,Unconfirmed]  http://launchpad.net/bugs/42110
[03:24] <robertj> hrmm, still unconfirmed :(
[03:29] <jmg> uhh
[03:30] <jmg> robertj: i wouldnt want my home exported readwrite by default
[05:07] <jmg> So what normally happens when upstream folds a package?
[05:09] <sfllaw> jmg: Folds?
[05:10] <jmg> sfllaw: folds up some smaller packages into a bigger one
[05:10] <jmg> opposite of split
[05:10] <sfllaw> Combined?
[05:10] <jmg> er well not really
[05:10] <jmg> yeah
[05:10] <sfllaw> You can choose to keep the package separation, but generate them from one source.
[05:10] <sfllaw> Or you can merge everything into one package, and have Provides: and Replaces: for the old ones.
[05:11] <jmg> No provision to have different controlfiles for derivatives is there?
[05:11] <sfllaw> I'm confused by your question.
[05:11] <sfllaw> Could you give an example?
[05:12] <jmg> no it doesnt matter, i thought of how to do it - with a dpatch
[05:13] <jmg> poningru: that s a cool quit :)
[05:13] <poningru> :)
[05:13] <poningru> thanks
[05:13] <poningru> got it from a friend
[05:13] <poningru> waay long ago
[05:13] <sfllaw> Man, everyone who understood that was way too geeky.  :)
[05:14] <jmg> sfllaw: I was wondering if it were possible to have a different debian/rules file for debian than to ubuntu, or to add specific functionality to the makefile that is active only if building for ubuntu
[05:15] <jmg> poningru: reminds me of mtg
[05:15] <sfllaw> jmg: But there _are_ separate files for Debian and Ubuntu.
[05:15] <sfllaw> Ubuntu forks off all of its packages.
[05:16] <bddebian> Since when?
[05:16] <sfllaw> Ubuntu adds little patches here and there, no?
[05:16] <sfllaw> At the very least, they bump the changelog.
[05:16] <bddebian> Not always
[05:17] <bddebian> Not for direct syncs afaik
[05:18] <sfllaw> OK.  libgtkspell0 is one of those.
[05:19] <sfllaw> But out of the archive, this is very rare.
[05:19] <sfllaw> Only 575 binary packages are like this.
[05:41] <Lathiat> Does anyone know the bug # where gdm doesnt get focus on dual head setups?
[05:41] <Lathiat> i cant seem to find it
[05:42] <Lathiat> but im sure i saw one before
[05:55] <robitaille> maybe bug 28712 ?
[05:55] <Ubugtu> Malone bug 28712 in gdm "gdm loses focus when mouse pointer is outside window (when initially started)" [Unknown,Unknown]  http://launchpad.net/bugs/28712
[05:57] <Lathiat> indeed
[06:35] <darius_> Can anyone reproduce a failure when executing winecfg and clicking on the Audio tab in Dapper beta 2?
[06:42] <robitaille> darius_:  what do you mean by failure?  a crash of the application?  I tried, and it allowed me to select an audio driver for wine
[06:49] <darius_> robitaille: yes, the app crashes with: *** glibc detected *** free(): invalid pointer: 0x7c06cf70 ***
[06:49] <darius_> I guess this is a wine bug - audio w/ wine used to work with this system :/
[06:50] <darius_> in 5.10
[06:51] <robitaille> maybe related to bug 42169
[06:51] <Ubugtu> Malone bug 42169 in wine "winecfg dies when clicking the "Audio" tab" [Normal,Unconfirmed]  http://launchpad.net/bugs/42169
[06:51] <darius_> yeah
[09:28] <Tonio_> hello
[12:14] <tsdgeos> hi
[12:15] <tsdgeos> anyone i can ping to update http://popcon.ubuntu.com/ ?  webmaster@ubuntu.com ignored my mail :-/
[12:26] <Kamion> tsdgeos: Mithrandir has been working on that
[12:34] <coz_> morning all
[12:34] <coz_> after hving the error; dev sda1 does not exist , last week we decided to wait until this mornign to run the updates
[12:35] <coz_> after having done that, on the same machines that ran daper well until a week ago , we did the updates again this time with a different error,
[12:35] <coz_> ALERT! /dev/mapper/Ubuntu-root does not exist
[12:36] <mdke> coz_: sounds like you've hit a bug. see https://launchpad.net/distros/ubuntu/+bugs
[12:36] <coz_> mdke, mm ok thanks I will fo there and check
[12:39] <Fjodor> Since it's rather quiet in here, I'll dare a question. Could the xkb symbol table be borked for dk? I only have Danish chars in gnome apps, and xev gives "XLookupString gives 0 bytes:" for presses on "oslash"
[12:41] <tsdgeos> Mithrandir: any update on the state of the popcon page?
[01:16] <ProN00b> why are new apps not in the multiverse repo ?
[01:16] <mdke> ProN00b: it depends on the license as to which repository applications are in.
[01:17] <ProN00b> would i find a app that has just been released for the first time in the breezy (current release) repos ?
[01:18] <mdke> ProN00b: breezy was released 6 months ago, so anything released more recently than about 7 or 8 months is unlikely to be there.
[01:19] <ProN00b> so a running release never gets new apps ?
[01:20] <dsas> ProN00b: Nope, you only get new apps when you upgrade to the next release 
[01:20] <ProN00b> why ?
[01:20] <mdke> ProN00b: that's correct.
[01:21] <ProN00b> i mean if they don't break anything and just work with the system they could at least by in multiverse
[01:21] <mdke> as I said, multiverse is defined by the licenses of the applications in it
[01:21] <mdke> releases are frozen shortly before release for stability reasons.
[01:21] <ProN00b> yeah, but new apps ?
[01:22] <mdke> yes, especially new apps
[01:24] <ProN00b> hmm, so ubuntu is carrying on the debian philosophy of never having the new stuff (tm)
[01:24] <Riddell> ProN00b: new stuff is in the development release
[01:24] <Riddell> you'll find every other distribution is the same
[01:24] <highvoltage> ProN00b: that statement is a bit unfounded
[01:24] <Riddell> s/release/version/
[01:24] <mdke> ProN00b: if you want to troll, go elsewhere please. The Ubuntu release team can't possibly develop two distributions simultaneously.
[01:25] <Riddell> actually there is backports if you want that
[01:25] <ProN00b> Riddell, how can i get that development release ?
[01:25] <mjg59> Kamion: There's still the problem that the partition discovery stuff tries mounting partitions in the installer in order to identify them
[01:25] <highvoltage> ProN00b: please take this to #ubuntu
[01:57] <_ion> Setting up bzr-doc (0.8~200604291148-0ubuntu1) ...
[01:57] <_ion> cannot create dhelp file '/usr/share/doc/bzr/html/.dhelp': No such file or directory
[02:02] <hunger> Any idea how I can stop the gpg-agent on logout again?
[02:02] <hunger> It is started in /etc/X11/Xsession.d (two times?) but never stopped.
[02:08] <sladen> hunger: does this help? http://lists.gnupg.org/pipermail/gnupg-devel/2005-January/021763.html
[02:08] <sladen> hunger: it should probably be a wider bug, can you file one please
[02:09] <hunger> sladen: Such hackery works, but since gpg-agent is started by default it should get stopped by default as well.
[02:09] <dsas> sladen, hunger: I think there is already a bug open for stopping gpg-agent on logout. 
[02:10] <hunger> dsas: Yes, there is.
[02:10] <\sh> since when is gpg agent started as default ?
[02:11] <hunger> There should be some generic way to run scripts on Xserver exit that works for *buntu:-(
[02:11] <hunger> \sh: gnupg adds two startup scripts to /etc/X11/Xsession.d.
[02:12] <hunger> \sh: Does that since before breezy.
[02:12] <hunger> \sh: s/gnupg/gnupg-agent/
[02:12] <tseng> ii  gnupg          1.4.2.2-1ubunt GNU privacy guard - a free PGP replacement
[02:12] <tseng> oh
[02:12] <\sh> hunger: I'm on the latest dapper upgrades...and there is no gpg-agent start script in Xsession.d because gpg-agent isn't in the default seed somehow...or do I miss something?
[02:12] <tseng> that explains it
[02:13] <hunger> \sh: I guess so, gnupg-agent is in universe.
[02:13] <\sh> hunger: so, there is no default :)
[02:14] <hunger> \sh: but still something like /etc/X11/Xsession.d for stop scripcs would make sense.
[02:14] <\sh> hunger: that's why kmail has problems to decrypt gpg mime mails :(
[02:15] <hunger> \sh: I guess that is why I have gnupg-agent installed;-)
[02:15] <\sh> hunger: to be frank, I don't like the agent stuff actually, neither ssh-agent nor gpg-agent...I don't like the idea, that my passphrase is somewhere in my ram :)
[02:16] <hunger> \sh: I agree.
[02:16] <hunger> \sh: But that the passphrase is in RAM and stays there even after a user logs out is even worse:-(
[02:17] <\sh> hunger: that's why I don't use gpg-agent :) and that's why I have to decrypt my gpg mime mails manually, until the kmail devs are solving this issue the "right way" (tm)
[02:17] <tseng> what difference does it make if you are logged in with something in memory, or logged out
[02:17] <tseng> linux isnt a single user system
[02:17] <tseng> if you dont trust the box, dont trust it when you are sitting there
[02:17] <hunger> \sh: plus it occasionally breaks my pam-mount, so my HDD stays mounted unencrypted longer then necessary.
[02:18] <\sh> tseng: it has something to do with "lazyness" and "humanity" ;)
[02:19] <hunger> tseng: I trust the box... I accept that my passphrase stays in memory when it makes things easier for me (== when I can actually use the data == when logged in).
[02:19] <hunger> tseng: I just hate to keep it there longer then necessary.
[02:19] <tseng> then you dont trust it
[02:20] <tseng> it doesnt matter much to me, it just seems a strange argument
[02:21] <hunger> tseng: Well, it is somewhat similar to not wanting daemons to run with root privs longer then necessary to set up their stuff.
[02:22] <tseng> daemons are remotely accessible
[02:22] <\sh> as long as you use your machine as single user machine, everything is fine, but when you have 2 3 4 5 user on this machine, those agents suck
[02:22] <hunger> Anyway: All I am saying is that it would be nice to have something like /etc/X11/Xsession.d to stop stuff after a user logs out oxf X.
[02:46] <bddebian> Hello
[02:47] <blaamann> elmo Znarl : The no.archive.ubuntu.com three is somewhat borked. E.g http://no.archive.ubuntu.com/ubuntu/dists/breezy-updates/main/binary-i386/Packages.gz is not there
[02:48] <Znarl> blaamann : OK, I'll fix this.  Thanks for letting me know.
[02:49] <blaamann> Znarl: We just talked about it in ubuntu-no and didn't know who to contact, but \sh told us that you might help us. Thanks!
[02:51] <Znarl> blaamann : I am the right person to contact.  I've pointed no.archive at the archive.ubuntu.com and I will email the admin of the mirror.
[02:54] <\sh> see, another problem solved :) closing bug ;)
[02:54] <blaamann> Znarl: Thanks again, and I will now leave you guys alone :-)
[02:57] <bddebian> Kamion: you around?
[03:04] <bddebian> Kamion: OK, since I can't seem to catch you.  I apologize for subscribing ubuntu-archive to some of those bugs.  However, when I ask questions either in here or -motu, many times I don't get answers and even though you say 'upload whatever you want', I like to get at least a second opinion.
[03:04] <bddebian> Though you notice, I usually do have a solution posted in the bug even though you say I don't.
[03:26] <opi> morning
[03:28] <bddebian> Hello opi
[03:43] <bddebian> Anyone know how I can get this damn enigmail-locale-ru removed?? http://paste.ubuntu-nl.org/13143
[03:46] <sladen> bddebian: you could use some  dpkg --force  evilness
[03:47] <bddebian> sladen: I've tried some.  Any suggestions?
[03:47] <bddebian> Heya Gloubiboulga
[03:47] <sladen> bddebian: or look at /var/lib/dpkg/info/enigmail-locale-ru.prerm  and working out why it is failing  and then file a bug
[03:49] <sladen> bddebian: upload stuff, just like Unix, people will tell you if something could be improved and gnerally be quiet if you do something correctly :)
[03:49] <sladen> bddebian: (and you and I don't learn unless we screw up first)
[03:50] <\sh> sladen: you screw packages? no way :)
[03:51] <bddebian> sladen: Well aren't we supposed to be a 'community'? :-)
[03:51] <bddebian> I've already been chastized for a few of my uploads :-)
[03:53] <bddebian> sladen: That worked, thanks man!
[03:55] <sladen> bddebian: it's probably quite distressing because don't tend to give positive praise, just chastize when something needs fixing, so it may seem like you're always being nagged...
[03:55] <Gloubiboulga> hey bddebian 
[04:00] <bddebian> sladen: I don't mind being 'corrected' ;-), but I freakin' despise being ignored considering the amount of work that I try to do
[04:00] <\sh> bddebian: sourcepackage?
[04:01] <bddebian> \sh: For which?
[04:02] <\sh> bddebian: with the problem of this mozilla-locale stuff
[04:03] <bddebian> \sh: All of those on unmet deps :-)  I think most of them probably need morgued?
[04:03] <truz24> Do I have to uninstall my old kernels to get them off of /boot/grub/menu.lst ?
[04:04] <truz24> I tried removing them manually but automagic puts them back :-)
[04:04] <\sh> what the heck is automagic?
[04:05] <\sh> bddebian: I think this mozilla-thunderbird-locale-tr and this other package can be removed...
[04:09] <bmonty> bddebian: they need to be removed, not morgued
[04:09] <bddebian> bmonty: Yeah, yeah, whatever ;-P
[04:09] <bmonty> :)
[04:10] <bddebian> I don't know how you can be any more removed than sent to the morgue ;-P
[04:10] <bddebian> Heya zakame
[04:10] <bmonty> bddebian: that is going to be a lot of bug reports for the archive team to get those locale packages out of the archive
[04:10] <\sh> morgue is a special archive....
[04:11] <\sh> while removing means: go away forever in actual dapper archives :)
[04:11] <bddebian> \sh: I know, I'm being literal :)
[04:11] <zakame> hi all
[04:11] <zakame> hi bddebian
[04:12] <bmonty> actually, can we really remove the enigmail-locale packages, I think I remember looking in to that and the current versions of enigmail still need them
[04:16] <\sh> hmm....>=1.5 << 1.5.0 it looks really funny to me, or I'm more into decimal calculation then dpkg ;)
[04:19] <bddebian> Yeah, that's hokey
[04:19] <\sh> that source pkg engimail :_
[04:40] <Chipzz> \sh: bzzzzzrrrrrt ;)
[04:40] <Chipzz> \sh: ssh-agent stores *the key* in ram, not the passphrase
[04:40] <Chipzz> ;)
[04:41] <\sh> Chipzz: yes :) but gpg-agent does not store the key in ram :)
[04:41] <\sh> Chipzz: what I wanted to say is that I don't like it 
[04:41] <Chipzz> uhu
[04:41] <Chipzz> maybe someone should rewrite gpg-agent to work more like ssh-agent?
[04:41] <Chipzz> or wouldn't that make a difference for you?
[04:42] <\sh> how should that work? putting the unlocked key into ram? 
[04:42] <Chipzz> uhu
[04:42] <Chipzz> but actually I have no clue about gpg, so I may be talking non-sense
[04:42] <\sh> Chipzz: it won't make a difference to me, I like more the manual approach to enter my passphrase every time :)
[04:42] <bmonty> just because the key is only stored in ram doesn't mean it isn't written to the disk
[04:42] <\sh> ram means physical memory and swap memory
[04:42] <Chipzz> bmonty: you mean swapped out?
[04:43] <bmonty> Chipzz: yes
[04:43] <Chipzz> actually I think it's a non-issue
[04:43] <Chipzz> if a user can gain root privs, or if you don't trust root
[04:44] <Chipzz> then he can just as well install a keylogger or a rootkit
[04:44] <mjr> it's not a non-issue if your box is stolen or confiscated
[04:44] <Chipzz> if your box is confiscated they need to power-cycle it
[04:44] <Chipzz> in which case the key will be gone
[04:45] <bmonty> Chipzz: if the key or password was in swap it probably still exists after a power cycle
[04:45] <mjr> except if it's written in swap
[04:45] <Chipzz> bmonty: then use encrypted swap?
[04:45] <mjr> though, the paranoid among us have encry... right
[04:45] <Chipzz> and if your laptop is stolen, you'ld better have a good screensaver which asks you for your password
[04:46] <bmonty> Chipzz: encrypting swap is a possible solution
[04:46] <\sh> to be more precise: if you are using your box as a single user machine, all is fine...but if the box is used by more then one person, those things can be security issue...if the people using this box don't know
[04:46] <Chipzz> if you don't, then this discussion is moot anyway
[04:46] <Chipzz> bmonty: it all depends on how paranoia you are, and how much you have to hide
[04:48] <\sh> someone who is working from home and is connecting to a network in his company should always be paranoid :)
[04:48] <Chipzz> but for 99% of our users, this basically *is* a non-issue
[04:48] <\sh> Chipzz: but gpg-agent is an issue, because without it kmail doesn't work properly regarding decrypting mime gpg mails
[04:49] <\sh> but that's more a kmail issue ;)
[04:49] <Chipzz> kmail should not rely on the agent then ;)
[04:49] <\sh> Chipzz: tell that the kde devs :)
[04:49] <bmonty> Chipzz: I disagree that this is a non-issue, but to each his own :)
[04:50] <Chipzz> bmonty: then you're more security-minded than I am ;)
[04:50] <Chipzz> bmonty: for me, it may be an issue for my fileserver with illegal movies on it... but for the other boxes I have, it isn't
[04:51] <Chipzz> you have to place this in its context
[04:51] <\sh> I hope amu is testing this gpg smartcard stuff on ubuntu/kubuntu, if this works I'll buy one of those smartcards and reader :)
[04:51] <Chipzz> would the ibm fingerprint stuff be usable for such things btw?
[04:51] <_ion> Talking of gpg-agent, i wish the script mentioned in bug #41870 were added to the keychain package.
[04:51] <Ubugtu> Malone bug 41870 in keychain "Starting keychain from /etc/X11/Xsession.d" [Normal,Unconfirmed]  http://launchpad.net/bugs/41870
[04:51] <bmonty> Chipzz: why does it have to be in relation to illegal files...how about your financial info?
[04:52] <bmonty> Chipzz: I've read that the security from the IBM fingerprint readers is laughable
[04:52] <Chipzz> bmonty: because for a large portion of users actually encrypting their fs'es, I'ld figure it is?
[04:53] <Chipzz> and for your financial transactions, you'ld have the bank to worry about anyway ;)
[04:57] <zakame> heya Nafallo!
[04:57] <Nafallo> hi there zakame :-)
[04:58] <zakame> what's up?
[05:16] <kmon> Hi
[05:17] <kmon> The release section in the wiki should explictly say warty is no longer supported
[05:18] <zakame> kmon: I think that will be changed soon
[05:18] <kmon> zakame: ok
[05:24] <Kamion> \sh: there's no such thing as a morgue in launchpad, so the term means even less than it used to
[05:24] <Kamion> bddebian: you seem to be referring a bug to us and giving multiple options normally, not just one
[05:25] <Kamion> bddebian: the problem is that once you subscribe ubuntu-archive to a bug, a malone bug means that we can never unsubscribe from it again
[05:25] <Kamion> bddebian: so it stays on our to-do list, which means our to-do list just got a lot harder to manage
[05:26] <Mithrandir> Kamion: it sounds like a bug that there's no way to unsub groups, though.
[05:26] <Kamion> bddebian: it's fine to refer a bug to us saying "please remove foo" or "please sync foo" or whatever - that's fine - and I'm sorry you're having trouble getting feedback, but escalating to ubuntu-archive isn't the way to solve that problem
[05:26] <Kamion> Mithrandir: it is - there's a bug filed, severity critical
[05:26] <Kamion> but still, the archive team is not a helpdesk
[05:29] <Kamion> also, could all you guys quit sending bugs to ubuntu-archive that all have the same subject line? :-) ("[UNMETDEPS]  xsim has unmet dependencies")
[05:34] <Kamion> aha, syncs should be fixed early next week, you'll be pleased to know
[05:35] <zakame> Kamion: yay! \o/
[06:43] <mgalvin> Seveas: ping?
[06:49] <welshbyte> Kamion: regarding bug #41865, should bugs that have that exact backtrace only with a different KeyError be marked as dupes?
[06:49] <Ubugtu> Malone bug 41865 in ubiquity "kde-ui's get_disk_choices looks at wrong choice list" [Major,Fix committed]  http://launchpad.net/bugs/41865
[07:20] <bddebian2> Kamion: No worries.  I'm trying to close the ones I stuck to ubuntu-archive anyway.  What is the proper method to escalate something?  I know I'm a PITA but I am trying to get stuff done also.  It's not like we have a person to go to is there?  Maybe Daniel H.?
[07:21] <bddebian> Kamion: Oh and as for the subject line, that wasn't my doing :-)
[07:27] <crimsun> _ion: that would require keychain being promoted to main.
[07:27] <_ion> crimsun: Why?
[07:28] <crimsun> _ion: it's pretty useless if it's not in main. It doesn't necessarily make sense to have hooks for stuff that doesn't exist in main.
[07:29] <_ion> crimsun: The Xsession.d script would not be there if keychain isn't installed. The script would be in the keychain package.
[07:30] <crimsun> _ion: why not use the method recommended by keychain's author(s)?
[07:30] <crimsun> (oh, it's filed against keychain, not X.org. misparse.)
[07:31] <_ion> crimsun: How does that differ from what keychain's authors intend?
[07:33] <crimsun> _ion: do upstream docs recommend using Xsession?
[07:33] <bddebian> Kamion: Oh yeah, and one more whine.  My @ubuntu.com e-mail still fails? :-(
[07:34] <crimsun> bddebian: that should be addressed to cprov in #launchpad
[07:35] <bddebian> crimsun: Oh really?  OK
[07:35] <bddebian> What's our stance on python2.2?  While I am ripping python2.1 out of pychecker, should I remove 2.2 as well?
[07:36] <crimsun> (I thought you were discussing that with doko?)
[07:37] <bddebian> crimsun: He basically said go ahead for 2.1 but I just thought about 2.2
[07:37] <_ion> crimsun: The intention of keychain is to use already running instances of {ssh,gpg}-agent, or start new ones if they aren't running. Also, when the session ends, they are left running (unless the user configures it otherwise). So all of your X or shell sessions are able to use the same instances of the agents. Xsession.d would be a very good place to start keychain from.
[07:40] <crimsun> _ion: so is the intention to remove the need for the user to edit his/her login file(s)?
[07:40] <crimsun> (89keychain doesn't properly handle -csh, btw)
[07:43] <_ion> crimsun: The admin can add similar lines to the shell's /etc/*profile as well. That way the users are able to use keychain simply by creating ~/.keychainrc
[07:43] <_ion> crimsun: Xsession is a sh script, not a csh script.
[07:44] <crimsun> _ion: no, I'm speaking of KEYCHAINENV="$HOME/.keychain/$(hostname)-csh"
[07:44] <_ion> crimsun: $KEYCHAINENV is only used by 89keychain.
[07:45] <_ion> crimsun: It's not exported.
[07:45] <crimsun> _ion: you're missing me entirely.
[07:45] <crimsun>  * Initializing /home/crimsun/.keychain/garnish-csh file...
[07:46] <_ion> crimsun: All due respect, but i think you're missing me entirely. :-)
[07:47] <_ion> crimsun: ~/.keychain/foo-csh contains exactly the same thing as ~/.keychain/foo-sh, just in different syntax.
[07:48] <_ion> crimsun: Xsession.d/89keychain doesn't need to care about the -csh one because it's being sourced by /bin/sh
[07:48] <crimsun> _ion: does Xsession explicitly use /bin/bash then?
[07:48] <Coyctecm> http://www.fsf.org/blogs/community/rms-ati-protest.html
[07:49] <Coyctecm> :D
[07:49] <_ion> % head -n 1 /etc/X11/Xsession
[07:49] <_ion> #!/bin/sh
[07:49] <crimsun> and if /bin/sh is not symlinked to /bin/bash ?
[07:50] <_ion> crimsun: It should be sufficient to expect that /bin/sh is symlinked to a sh compatible shell.
[07:51] <_ion> If a user symlinks /bin/sh to /usr/games/quake2, Xsession(5) being broken is her smallest problem.
[07:52] <crimsun> I'd feel more comfortable considering 89keychain if it at least handled -csh
[07:53] <Mithrandir> if /bin/sh is symlinked to a non-posix-sh, you don't have a posix (and thereby not a UNIX) system.
[07:53] <_ion> crimsun: Handled it _how_?
[07:53] <_ion> How should a sh script handle a csh script?
[07:53] <crimsun> _ion: the question is whether it's only important that hostname-sh exists
[07:54] <crimsun> if so, then there's no problem at all
[07:54] <_ion> crimsun: Yes, it's only important that foo-sh exists.
[07:55] <_ion> Everything in /etc/X11/Xsession.d is written in sh syntax. If it weren't, it would be broken.
[08:34] <kagou> slomo_: around ?!
[08:34] <slomo_> kagou: yes
[08:38] <sivang> re all
[08:38] <sivang> hey slomo_ :)
[08:38] <slomo_> hi sivang :)
[08:39] <sivang> slomo_: when will you be able for a new upload? :-)
[08:39] <slomo_> sivang: what about now? ;)
[08:39] <sivang> slomo_: I'm working on some more improvements
[08:39] <sivang> slomo_: cool, but I;m not finished yet ...:-/
[08:39] <slomo_> sivang: i'll be here for the next 3 hours probably
[08:39] <kagou> slomo_: can i assign #35792 to you ?
[08:39] <sivang> slomo_: okay, coo, what are you working on?
[08:40] <kagou> Bug #35792:
[08:40] <Ubugtu> Malone bug 35792 in gdesklets "gdesklets shell fails on first run" [Normal,In progress]  http://launchpad.net/bugs/35792
[08:40] <slomo_> kagou: yes, but change the error message too please :)
[08:49] <kagou> slomo_: Bug #35792 is for you. I hope that my second package patch is ok now ;)
[08:49] <Ubugtu> Malone bug 35792 in gdesklets "gdesklets shell fails on first run" [Normal,In progress]  http://launchpad.net/bugs/35792
[08:51] <slomo_> kagou: thanks... uploaded :)
[08:51] <kagou> your welcome
[09:10] <shawn_home> hrm, why do we use H.J Lu's binutils and not the official GNU binutils? there's no need to use his anymore.
[09:11] <shawn_home> its infact discouraged by linux kernel developers as well 
[09:35] <Seveas> mgalvin, pong
[09:37] <shawn_home> anyone have a reason as to why we use them?
[09:38] <Mithrandir> shawn_home: probably because there's no reason not to and it's what we get from Debian?
[09:38] <shawn_home> !!!
[09:39] <Mithrandir> shawn_home: also, iirc, we use a somewhat patched cvs snapshot of binutils, so I'm not sure your claim that we're using H. J. Lu's binutils.
[09:39] <shawn_home> not according to debian: binutils (2.16.1cvs20060413-1)
[09:39] <shawn_home> GNU ld version 2.16.91 20060118 Debian GNU/Linux is dapper
[09:39] <Mithrandir> yes, and?  Why do you claim that it's not the "official" binutils?
[09:40] <shawn_home> there is no .91 package in ftp.gnu.org 
[09:40] <shawn_home> but there is in: http://www.kernel.org/pub/linux/devel/binutils/
[09:43] <Mithrandir> yes, and if you read release.binutils-2.16.91.0.1 in that directory it says that it's the beta release.
[09:43] <shawn_home> ok,i stand corrected, the gcc people tell me thats not the other one
[09:45] <shawn_home> if it has 2 extra .x.x it's HJL's 
[09:45] <shawn_home> if it doesn't its GNU official
[09:45] <kbrooks> Hey everyone.
[09:45] <shawn_home> I was worried since HJL's binutils is rediculed by people, so we're ok
[09:45] <kbrooks> XiXaQ: state your feature request :-)
[09:46] <mgalvin> Seveas: i added a comment to Bug #41957 on my reason for filling it... please take a peek when you have time, thnx
[09:46] <Ubugtu> Malone bug 41957 in fam "fam tries to remove ubuntu-desktop" [Normal,Rejected]  http://launchpad.net/bugs/41957
[09:46] <Seveas> mgalvin, removing would be best imho
[09:47] <mgalvin> +1
[09:47] <XiXaQ> I'd like to have a cd-checker-feature in the ubuntu installation. I've had alot of problems (possibly) because of a faulty installation medium. I had to install windows again, download another copy, check it again, before I can resume installation of ubuntu. If I had known that there was something wrong with the cd, then I could simply reboot in windows, get a new one and try again.
[09:48] <mjg59> XiXaQ: There is
[09:48] <XiXaQ> mjg59?
[09:48] <mjg59> XiXaQ: You can select it from Dapper's boot menu
[09:48] <XiXaQ> mjg59, right, I was talking about 5.10.
[09:48] <XiXaQ> great.
[09:49] <XiXaQ> another request: a simple IRC client with a connection to an installation support group. and possibly a small text-based web client.
[09:51] <Mithrandir> XiXaQ: it's in breezy too, but not discoverable.  Select "back" from one of the prompts and you should get to the main menu.
[09:51] <Mithrandir> XiXaQ: from there, select "check cd-rom integrity"
[09:53] <XiXaQ> ah.
[09:54] <XiXaQ> I'm downloading Dapper now. If I'm able to run that in live versjon, then I should be able to install it too, right?
[09:55] <Mithrandir> XiXaQ: yes, and there's a live installer there too.
[09:55] <Mithrandir> XiXaQ: those questions are more appropriate for #ubuntu or possibly #ubuntu-no, though.
[09:56] <XiXaQ> right.
[10:20] <Riddell> welshbyte: yes, most likely
[10:41] <highvoltage> hi, is there a way i can test a preseed file before burning a cd?
[11:17] <lifeless> morning
[11:17] <Burgundavia> salut lifeless
[11:17] <ubijtsa> highvoltage: you can do a netinstall and pull the preseed that way perhaps?
[11:18] <highvoltage> ubijtsa: that's actually a good idea. thanks, i'll do that.
[11:18] <ubijtsa> highvoltage: np :)