[12:04] <Pygi> _ion: you should remove that "isn't signed, bla, bla" as well ;)
[12:04] <Pygi> but I'll do it
[12:08] <Pygi> thanks _ion
[12:08] <Pygi> we've done some changes to the repo, so I am testing now
[12:15] <sivang> oi, OOP code component re-use in python is SO sweet!
[12:15] <Pygi> sivang: hehe ;)
[12:16] <sivang> Pygi: is rather amazing,
[12:16] <Pygi> sivang: I am aware of that ^_^
[12:16] <sivang> Pygi: working on home user backup, I am not working on uprestore (the resoration module) as it shares most of the GUI characteristics with upbackup, I just based it's class on the backup one, and 80% if the work is already done :)
[12:17] <sivang> s/not//
[12:17] <sivang> Pygi: so I get all the media device detection code and population, user details detection for free, integrated into the gui.
[12:18] <sivang> I used dyaminc (getattr) method and attribute allocation and designed the module sin advance like this, like the jewish saying goes "He who bothered on friday night will see joy on sat" :-D
[12:18] <Pygi> sivang: joy :-)
[12:19] <sivang> completely. :-) /me goes back to hacking
[12:19] <Pygi> ;)
[12:19] <Pygi> I am hacking as well
[12:19] <Pygi> the repository ;)
[12:19] <sivang> Pygi: hehe, uploading new l-r-m ?
[12:19] <sivang> Pygi: with _ion's changes in?
[12:20] <Pygi> sivang: bah, we already have that in ... we just finished polishing all the packages
[12:20] <sivang> (I saw the bits of wifi discussions with mjg59 and _ion )
[12:20] <Pygi> packages were bloated, and not really usefull ;)
[12:20] <sivang> Pygi: which chipset / devices are now supported?
[12:20] <sivang> Pygi: (you touched only the wifi stuff?)
[12:20] <Pygi> sivang: please see the ubuntu-devel ^_^
[12:21] <sivang> eh, okay..sorry
[12:21] <Pygi> np at all ^_^
[12:21] <sivang> Pygi: are you already approved for main ? I don't recall I saw you on the CC/TB for that one.
[12:21] <Seveas> _ion, ping
[12:21] <_ion> seveas: Pong.
[12:22] <Seveas> _ion, Errhttp://kubuntu.no-ip.org dapper/main nm-applet 0.6.1-0ubuntu1
[12:22] <Seveas>   404 Not Found
[12:22] <Pygi> sivang: nop, we never actually got to that part ^_^ we have time
[12:22] <Pygi> Seveas: yup, I know
[12:22] <_ion> seveas: Yeah, Pygi is working on the new repository.
[12:22] <Pygi> Seveas: please read the -devel mailing list, and follow thingies
[12:22] <Seveas> k
[12:22] <Pygi> sivang: when is next CC/TB?
[12:23] <sivang> Pygi: Me neither, but I'm getting there I think, first get approved for universe.
[12:23] <sivang> Pygi: 28 Mar 20:00
[12:23] <sivang>           UTC: Technical Board
[12:23] <Seveas> Pygi, when will the repo be ready?
[12:24] <Pygi> Seveas: repos are ready now .... they are signed now, so you need to import the key
[12:24] <Pygi> sivang: thanks ... do I need to write somewhere that I am going to attend it, etc? ;)
[12:24] <Seveas> Pygi, I still get 404
[12:24] <Pygi> Seveas: followed the wiki?
[12:24] <Seveas> yeah 
[12:25] <_ion> W: GPG error: http://kubuntu.no-ip.org dapper Release: The following signatures were invalid: BADSIG C80644C88A303107 Anthony Mercatante <tonio@ubuntu.com>
[12:25] <Seveas> W: GPG error: http://kubuntu.no-ip.org dapper Release: The following signatures were invalid: BADSIG C80644C88A303107 Anthony Mercatante <tonio@ubuntu.com>
[12:25] <Seveas> rofl
[12:25] <Seveas> Pygi, fix the Release.gpg
[12:25] <sivang> Pygi: no, just to show up. 
[12:25] <Pygi> sivang: kk, and there I ask for it?
[12:25] <sivang> Pygi: make sure you apply for MOTU through launchpad, or main 
[12:25] <Pygi> sivang: ah, ok
[12:25] <_ion> pygi: Make whatever updates the repository update the signature as well. :-)
[12:26] <Tonio_> hi
[12:26] <_ion> Hi
[12:26] <Tonio_> is there a problem with the repo ?
[12:26] <Tonio_> Seveas: ?
[12:26] <Seveas> Tonio_, Pygi broke it - lart him
[12:26] <_ion> Apparently Release.gpg isn't updated.
[12:26] <Pygi> yup, I have it again
[12:26] <Pygi> W: GPG error: http://kubuntu.no-ip.org dapper Release: The following signatures were invalid: BADSIG C80644C88A303107 Anthony Mercatante <tonio@ubuntu.com>
[12:26] <Pygi> W: You may want to run apt-get update to correct these problems
[12:26] <Pygi> Tonio_: you need to stop that automatic scanning I would say
[12:26] <Tonio_> grmpf......
[12:27] <Seveas> Pygi, have you looked at falcon to build a repo? Makes it dead easy ;)
[12:27] <Pygi> or make it auto update
[12:27] <Tonio_> Pygi: yes, unfortunately
[12:27] <_ion> I haven't tried falcon, but reprepro makes it dead easy as well. :-)
[12:27] <Pygi> Tonio_: just make the key auto updates itself
[12:27] <Tonio_> we have to generate Release.gpg each time..........
[12:27] <Tonio_> damn........
[12:27] <Seveas> well, apparently it's not as easy :D
[12:27] <Pygi> Seveas: I have, but I didn't found the source
[12:27] <Tonio_> Pygi: really, is that gpg key needed ?
[12:27] <Tonio_> it creates so many problems
[12:27] <Pygi> Tonio_: yes, it is needed  ^_ ^
[12:27] <_ion> tonio: Yes. :-)
[12:27] <Tonio_> what for ?
[12:27] <Pygi> just make it generate the key
[12:27] <sivang> does anybody know how I can have another user on the system allowed to use X, using xhost ?
[12:27] <Pygi> Tonio_: for authentification
[12:28] <Seveas> xhost +
[12:28] <Tonio_> Pygi: impossible, I have to type my password each time :)
[12:28] <sivang> Seveas: + and nothing afterwards?
[12:28] <Tonio_> can't be automatic
[12:28] <_ion> tonio: Nope, use gpg-agent.
[12:28] <Seveas> sivang, after you finished: xhost -
[12:28] <sivang> Seveas: thank you
[12:28] <Pygi> Tonio_: then just make that the script doesnt work... we'll run it manually when needed
[12:28] <_ion> tonio: keychain makes it easy.
[12:28] <Seveas> xhost + sets it WIDE open
[12:28] <Tonio_> _ion: will check
[12:28] <Pygi> Seveas: where can I find more info on that falcon of urs? ^_^
[12:29] <Seveas> Pygi, kaarsemaker.net/software or dimply my wikipage
[12:29] <_ion> Insert the proper keychain lines to ~/.xinitrc and ~/.yourshellrc, and it starts ssh-agent and gpg-agent automatically and configures your environment.
[12:31] <Tonio_> should be working now
[12:32] <_ion> tonio: Yeah, thanks.
[12:32] <Seveas> Do you want to continue [Y/n] ? y
[12:32] <Seveas> Errhttp://kubuntu.no-ip.org dapper/main libnm-util-0 0.6.1-0ubuntu1
[12:32] <Seveas>   404 Not Found
[12:32] <Seveas> still not working...
[12:32] <Pygi> Seveas: we're on it
[12:32] <_ion> Oh.
[12:33] <Seveas> Pygi, Tonio_ said it works, well it doesn't ;)
[12:33] <Tonio_> hu ????
[12:33] <Tonio_> Seveas: works here
[12:33] <Pygi> Tonio_: tried fetching something?
[12:34] <Pygi> works here as well
[12:34] <Seveas> Tonio_, try apt-get install network-manager
[12:34] <Pygi> Seveas: ???
[12:34] <Tonio_> Seveas: it is okay
[12:35] <Pygi> Tonio_: I can't fetch files :-/
[12:35] <Seveas> Tonio_, it's not working - all files give 404 errors
[12:35] <Tonio_> grmpf
[12:35] <Seveas> Failed to fetch http://kubuntu.no-ip.org/kubuntu/dists/dapper/main/main/binary-i386/libnm-util-0_0.6.1-0ubuntu1_i386.deb  404 Not Found
[12:35] <Seveas> Failed to fetch http://kubuntu.no-ip.org/kubuntu/dists/dapper/main/main/binary-i386/network-manager_0.6.1-0ubuntu1_i386.deb  404 Not Found
[12:35] <Seveas> Failed to fetch http://kubuntu.no-ip.org/kubuntu/dists/dapper/main/main/binary-i386/nm-applet_0.6.1-0ubuntu1_i386.deb  404 Not Found
[12:35] <Tonio_> this authentication drives me nuts
[12:35] <Tonio_> it was working before
[12:35] <_ion> "main/main"
[12:35] <Seveas> seriously, switch to falcon for your repoing needs ;)

[12:36] <_ion> Yeah, i'd suggest the same. :-)
[12:36] <Tonio_> Seveas: it is not going to be widely used
[12:36] <Tonio_> ;)
[12:36] <Pygi> Seveas: we will...let's just make it workin' for now
[12:37] <Pygi> Tonio_: perhaps something in configuration?
[12:37] <Tonio_> should be working now
[12:37] <Tonio_> at least works for me
[12:37] <Tonio_> yes config was somehow wrong
[12:37] <Seveas> yep, works
[12:37] <Pygi> great
[12:38] <Pygi> Tonio_: later today (at least for me) we'll look into using falcon
[12:38] <Pygi> and why doesn't the kubuntu-devel list allows links in a post?
[12:38] <Tonio_> Pygi: this isn't a dedicated webserver for this
[12:38] <Pygi> joy
[12:38] <Seveas> cool
[12:38] <Seveas> my connection survived an NM restart :D
[12:38] <Tonio_> i'm hosting many different thigs on it, so I don't wan to install too many stuff :)
[12:39] <Seveas> Tonio_, falcon is a small script, with very little dependencies
[12:39] <Tonio_> just need to automate that release.gpg generation
[12:39] <Pygi> Tonio_: ah,k, we can just leave it as is
[12:39] <Tonio_> Seveas: okay, I'll have a look then
[12:39] <Seveas> Tonio_, and it does gpg-signing for you ;)
[12:39] <_ion> You don't need to install falcon to the web server, you can use it your local machine and make it upload stuff to the public repo.
[12:39] <Pygi> Tonio_: perhaps we can work later today on that?
[12:39] <Tonio_> Seveas: I need to test what _ion said
[12:40] <Seveas> _ion is right, you don't even need it on your server
[12:40] <Pygi> lol, already mad users are yelling at me
[12:40] <Pygi> 'cause the repo doesn't work
[12:40] <Tonio_> it isn't oficial for the moment :)
[12:40] <_ion> That's how i managed my repo. I had reprepro installed to my desktop machine.
[12:40] <Tonio_> Pygi: should be okay now no ?
[12:40] <Pygi> Tonio_: yup, works now...but I got 5 mails from users to which it didn't work
[12:41] <Tonio_> Pygi: :(
[12:41] <Pygi> that was before we modified the repo tho
[12:42] <Pygi> already compliments ^_^
[12:42] <Pygi> Tonio_, _ion, me: let's apply for MOTU's now
[12:43] <Seveas> Pygi, you'll need to be a member first
[12:43] <Tonio_> yep :)
[12:43] <Pygi> Seveas: oh, and what do I do to become that?
[12:43] <Tonio_> Pygi: I already am a MOTU :)
[12:43] <Pygi> Tonio_: great, but me isn't even a member ;)
[12:43] <Seveas> Pygi, sustained and significant contribution to ubuntu for at least 2 months
[12:43] <Tonio_> you have to apply :)
[12:43] <Pygi> Seveas: bah, I have contributed to ubuntu for a lot time
[12:44] <Seveas> wiki.ubuntu.com/NewMemberHowto
[12:44] <Pygi> Seveas: at least you know I did ^_^
[12:44] <Seveas> Pygi, actually I don't 
[12:44] <Pygi> I am also along with ivoks, founder of ubuntu-hr
[12:44] <Pygi> ;)
[12:44] <Seveas> just follow the NewMemberHowto then
[12:44] <Pygi> Seveas: bah, ok, then don't know :P
[12:45] <Tonio_> Seveas: thanks for the info, didn't knew this
[12:45] <Pygi> Seveas: hm, ok, thx, and when is this CC meeting?
[12:45] <Seveas> Tonio_, it's not very well known and still pre-1.0
[12:45] <Tonio_> Seveas: that's why :)
[12:45] <Seveas> Pygi, not yet decided, somewhere the coming week
[12:45] <Pygi> hm, ok, thank you very much ^_^
[12:46] <Tonio_> I must say I didn't understood _ion's technique to perform the autosigning :)
[12:46] <Seveas> Tonio_, I'm hoping to release 0.9.9 this week and 1.0 soon
[12:46] <ajmitch> Pygi: and how much packaging work have you done to go for MOTU?
[12:46] <Tonio_> Seveas: your developpment ?
[12:46] <Seveas> yep
[12:46] <Tonio_> cool :)
[12:46] <Pygi> ajmitch: not much ^_^
[12:46] <Seveas> that's why I know it so well ;)
[12:46] <Pygi> ajmitch: just this thingies we worked on right now ^_^
[12:46] <Tonio_> Seveas: which language ?
[12:46] <Seveas> python
[12:46] <Tonio_> k
[12:47] <ajmitch> Pygi: ah, then you've got a bit to do
[12:47] <_ion> pygi: I don't think i will apply for a MOTU right now  i don't really have a lot of energy to do stuff, as i've been ill for a long time. I only packaged n-m 0.6 to scratch my own itch.
[12:47] <Pygi> ajmitch: It doesn't matter actually... I don't even have to be a member ... I can contribute just like this as well ;)
[12:47] <Seveas> Pygi, that's the correct spirit - just contribute 
[12:48] <Pygi> ajmitch: if I contributed this, I believe I can contribute even more, without being a member, so ... ^_^
[12:48] <Pygi> Seveas: ^_^
[12:49] <Pygi> ajmitch: the only reason I wanted to apply for MOTU, was to be able to request inclusion of n-m into main
[12:49] <Pygi> if it gets properly tested, and works
[12:50] <ajmitch> good luck with that
[12:50] <Pygi> bah, I'll just bother Tonio_ to do that for me ;)
[12:51] <_ion> Heh, the fact that n-m 0.5 was moved to main might be a bad thing, because it would probably have been easier to get 0.6 to Dapper universe.
[12:51] <Pygi> _ion: yup, true ...
[12:51] <Pygi> much easier
[12:52] <Tonio_> _ion: true, but the good thing is that we now a bit more time for this
[12:52] <Seveas> tomorrow I'll do the first EAP/TTLS test 
[12:53] <Pygi> Seveas: thx seveas... please direct issues, etc. to the -devel list at appropriate thread
[12:55] <Seveas> no way, I'll just flame you ;)
[12:55] <Pygi> Seveas: ok, that's fine as well ;)
[12:59] <infinity> Seveas: Is/was it you who ran the *-changes RSS feeds?
[12:59] <Seveas> infinity, is
[01:00] <Seveas> is it broken again?
[01:00] <infinity> Seveas: None of them have updated for me for a couple of days.
[01:01] <Seveas> last on dapper-changes is 23:25 UTC
[01:01] <infinity> mkvtoolnix_1.6.5-4build1 is the last thing I see on dapper-changes.
[01:01] <infinity> Which is clearly not true.
[01:01] <Seveas> I see efibootmgr
[01:01] <Seveas> aren't you looking upside down?
[01:02] <infinity> No, I was looking the right direction, liferea just seemed to be "stuck", I guess.
[01:02] <infinity> Deleting and recreating it fixed it.
[01:02] <infinity> Weird.
[01:02] <Seveas> weird indeed
[01:03] <Seveas> did you restart liferea in the past days?
[01:03] <Seveas> I've seen liferea being stuck, restarting the thing fixed that
[01:03] <_ion> Straw > liferea. ;-)
[01:03] <Pygi> is there anyone here that would be willing to build 64bit packages for us?
[01:03] <Seveas> sure, if you give me a 64bit machine ;)
[01:04] <Pygi> Seveas: agreed ... wanna come and get it ?  ^_^
[01:04] <Seveas> hehe
[01:04] <Pygi> we're currently building ppc packages
[01:04] <Pygi> and we have 32 bit packages
[01:04] <Pygi> only 64 bit remains ^_^
[01:04] <Pygi> we will take over the world ^_^
[01:05] <Seveas> LOL
[01:05] <ajmitch> Pygi: do you have source packages available?
[01:05] <raphink> Pygi: are you building ppc packages?
[01:05] <_ion> Not until we have m68k packages!
[01:05] <Pygi> ajmitch: yes ;-)
[01:05] <_ion> ajmitch: Yes.
[01:05] <Pygi> raphink: nop, not me, but they are being builded, and should be there ^_^
[01:05] <raphink> Pygi: what are you building them with?
[01:05] <ajmitch> attack of the smilies in here today..
[01:05] <raphink> Pygi: well I am the one who is to build them
[01:05] <Tonio_> Seveas: Iwas reading and I can find docs to autoconnect using ssh and nopassword
[01:05] <raphink> and I'm not currently doing it
[01:05] <_ion> Get:2 http://kubuntu.no-ip.org dapper/main network-manager 0.6.1-0ubuntu1 (tar) [1026kB] 
[01:06] <Pygi> raphink: aha, ok then ^_^
[01:06] <Tonio_> Seveas: but nothing relative to scripting and automating pg signing
[01:06] <raphink> so unless you are volunteering to do the work, I don't know how you can say "we" are doing it ;)
[01:06] <Tonio_> Seveas: would you have a wikipage or doc for this ?
[01:06] <Pygi> raphink: O joy ^_^
[01:06] <Seveas> Tonio_, I use a passwordless key for the repo - it's safer to use gpg-agent though
[01:06] <_ion> It's easy enough with gpg-agent, and _much_ more secure.
[01:07] <Tonio_> Seveas: okay, but that means I will have to change the key, and now many people are using the repo, thant's not possible
[01:07] <Seveas> yeah
[01:07] <Seveas> Tonio_, no, you can remove the password from a key 
[01:07] <Pygi> Tonio_: it's fine for now
[01:08] <doko> infinity: OOo starts on ia64, but not, if you install openoffice.org-gnome
[01:08] <Tonio_> Pygi: except if I have to updateit manually every day.......
[01:08] <Pygi> Tonio_: yes, I am aware of that ...
[01:08] <Pygi> Tonio_: we'll change that later today ...
[01:09] <Tonio_> Seveas: it is my main private key that I use to sign :)
[01:09] <Tonio_> Seveas: I don't use several keys generally :)
[01:09] <infinity> doko: Interesting.
[01:10] <infinity> doko: Missing some libs for -gnome, or just generally broken?
[01:10] <Seveas> hehe
[01:10] <Tonio_> Seveas: so removing the password is just........ weired :)
[01:10] <Seveas> quite
[01:10] <Tonio_> well, I'll do manually (grmpf.......)
[01:11] <doko> infinity: no, missing libs would mean that it cannot start on amd64 either
[01:11] <raphink> ok we're about to build the packages for ppc :p
[01:11] <raphink> hehe
[01:11] <doko> infinity: I had to test over ssh X forwarding in a chroot, so maybe lamont or iwj can check this out locally
[01:12] <infinity> doko: Well, a fair point, but ia32-libs is different between the two arches, so I didn't know if that was perhaps true for ia32-libs-gtk and other stuff as well.
[01:12] <infinity> doko: Yeah, I don't have a local ia64 either, I was just trying to get it installable, so others could test if it was useable.
[01:17] <ajmitch> ugh, Build-Depends: @cdbs@
[01:18] <_ion> ajmitch: Ugh?
[01:19] <ajmitch> _ion: at least it's not updated on every build
[01:19] <ajmitch> hi stratus 
[01:19] <_ion> ajmitch: Of course not.
[01:19] <_ion> ajmitch: Whenever it's updated manually, the resulting debian/control is inspected.
[01:20] <stratus> ajmitch, hey fine?
[01:20] <ajmitch> _ion: so you basically replaced all the packaging for nm?
[01:20] <_ion> ajmitch: Pretty much, and then ported the patches from the old version.
[01:21] <Seveas> why did you change the build system?
[01:22] <_ion> cdbs makes writing and maintaining debian/rules a lot easier.
[01:23] <Seveas> writing one by hand is just as simple 
[01:26] <_ion> http://johan.kiviniemi.name/tmp/nm-5-rules  http://johan.kiviniemi.name/tmp/nm-6-rules
[01:29] <Seveas> I find the first one easier to understand
[01:29] <Seveas> and definitely easier to write
[01:31] <_ion> I think it's quite redundant for every single debian source package have the same generic functionality copied to their debian/rules.
[01:33] <mjg59> _ion: Yes, that 2K of gzippable content is a nightmare for the archive
[01:35] <_ion> Yeah, and for my Commodore 64.
[01:38] <mjg59> _ion: More seriously - changing the build system makes it less likely that your packages will be merged in
[01:41] <Robot101> or in general, changing anything thats not relevant to your real issue is always bad
[01:41] <Robot101> like editing whitespace in a file when you're submitting a bugfix
[02:19] <LaserJock> mjg59: First upload to be built on an Apple running Ubuntu <-- sounds promising :-)
[02:20] <Amaranth> mjg59: hey, i build things on an Apple running Ubuntu all the time
[02:20] <Amaranth> :P
[02:21] <LaserJock> lol
[02:21] <LaserJock> I haven't :(
[02:22] <paulproteus|lapt> What package do I use to report a bug against the Ubuntu website?
[02:23] <Amaranth> hmm
[02:23] <Amaranth> i don't think there is one
[02:25] <mjg59> Amaranth: That's an i386/ia64-only package...
[02:25] <Amaranth> hehe, i know
[02:25] <LaserJock> paulproteus|lapt: I'd probably email webmaster@ubuntulinux.org
[02:27] <LaserJock> mjg59: you've got a mini, right?
[02:27] <mjg59> LaserJock: And an imac, but yeah
[02:27] <LaserJock> mjg59: oh, ok. I was just wondering about the video on the iMac
[02:27] <mjg59> Supported (unaccelerated)
[02:27] <LaserJock> sweet
[02:28] <LaserJock> I remember when they first came out that somebody said that the video wouldn't be supported
[02:28] <LaserJock> and even though I'm CLI most of the time. I'd like to at least burn my eyes out with orange every once in a while ;-)
[02:41] <jdong> is the livecd installer (Dapper) supposed to do custom partitioning?
[02:41] <jdong> just an FYI, it locks on me when I try to
[02:41] <Amaranth> it's still not done
[02:42] <Amaranth> right now afaik it only does "wipe the drive"
[02:42] <jdong> oh, nvm, it did work
[02:42] <jdong> just the embedded gparted's "Are you sure" dialog got backgrounded
[02:42] <jdong> metacity bug, or just forgot to set modal?
[02:42] <jdong> and speaking of that, recently metacity has been loving to background things for no reason :)
[02:47] <jdong> yeah, Amaranth, definitely espresso is still immature
[02:47] <jdong> I'm sure glad it gets some extra time 
[03:12] <infinity> _ion: The new linux-source will require a new LRM for the bumped ABI, yes, but that's a moot point since linux-source doesn't build right now anyway. :)
[03:13] <_ion> infinity: Yep. Hehe.
[03:14] <paulproteus|lapt> Oh that's why gaim was using all my CPU....
[03:31] <stub> Launchpad will be going down for scheduled maintenance in 30 mins. Estimated downtime is up to 3 hours. Wikis will be in read only mode during this time.
[03:33] <psusi> so is there someone in charge of fixing xserver regressions since breezy now that Daniels is gone?
[03:33] <seth> what happened to daniels anyway
[03:33] <seth> if it is not a touchy subject
[03:34] <infinity> seth: Erm, he doesn't work for Canonical anymore?
[03:34] <seth> right, just wasn't sure where he went
[03:34] <psusi> someone said he changed jobs... doesn't work at canonical anymore
[03:34] <psusi> said something about getting a job at a cell phone company
[03:34] <Amaranth> yep
[03:34] <HrdwrBoB> yes, he works at a company ending in okia
[03:34] <seth> i see, thanks :)
[03:34] <Amaranth> hehe
[03:35] <psusi> I've had a bug lodged for a few months now about a regression since breezy where x now thinks that microsoft intellimice have 11 buttons instead of only 9
[03:35] <psusi> I'd had to see dapper released with a silly regression like that but... who's job is that now?
[03:35] <infinity> No one's a fulltime X maintainer right now.
[03:35] <psusi> he reassigned the bug to nobody
[03:36] <infinity> Fabio and I are attempting to tackle some of the bug list in the next little while as theoretical "team leads" of the X SWAT Team, but not sure how far we'll get.
[03:36] <psusi> ahhh
[03:36] <infinity> psusi: The bugs should be assigned to the team.  x-swat in LP, I think.
[03:36] <Amaranth> X is really a full tiem job
[03:36] <Amaranth> time
[03:36] <infinity> (search for "swat" in the search box, should find it)
[03:36] <psusi> ok... I'll assign it to x-swat then
[03:37] <infinity> Amaranth: Unfortunately, yes, but we're spread a bit thin.  Community involvement would be VERY appreciated.
[03:39] <LaserJock> tritium: 
[03:39] <LaserJock> hi
[03:39] <tritium> hi LaserJock!
[03:40] <psusi> I wish I knew more about how X works so I could fix it... but I don't, and I'm working on some kernel fixes and other things persuant to PacketCD and HardwareFakeRaid specs
[03:40] <tritium> hmm, was hoping today's language-selector wouldn't give "could not open display" runtime errors, like yesterday's did...
[03:41] <psusi> by the way.... git is a kick ass version control system ;)
[03:42] <infinity> Except when your branch wedges itself, yes.
[03:42] <psusi> wedges itself?
[03:43] <infinity> Oh, when halfway through a merge, it decides to just give up trying, and you're stuck with the leftovers.
[03:43] <infinity> Acestry can get complex to the point where it just decides it doesn't want to try anymore.
[03:43] <infinity> It's happened to me 2 or 3 times now.
[03:43] <psusi> if you don't want to manually resolve the conflicts, then just git-reset --hard
[03:44] <infinity> I'm not talking conflicts.
[03:44] <psusi> it's just saying it thinks you need to intervene a bit... fix up the files and commit
[03:44] <infinity> I'm talking ancestry tracing falling over hard, with painful errors and reasonably corrupt branches.
[03:45] <psusi> hrm.... weird...
[03:45] <psusi> I thought I had screwed things up like that a few times... but I usually just fix it by cat .git/refs/heads/origin > .git/refs/heads/master
[03:46] <infinity> Yeah, intuitive. :)
[03:46] <psusi> then I found git-reset --hard ;)
[03:58] <stub> Is that an alias to rm?
[04:02] <holycow> what is the name of the ubuntu notify applet?
[04:03] <Amaranth> holycow: what?
[04:04] <holycow> the ubuntu notify applet .. what is the name of that package? i need to remove it
[04:05] <holycow> bah, called update-notifier heh
[04:31] <msg43> Hi
[04:31] <msg43> I hopeing someone can tell me how ubuntu suspends the machine such as what program or kernel patch is used.
[04:33] <G0SUB> msg43: it just does `echo mem > /sys/pwer/state`
[04:33] <Lathiat> It's not a kernel patch, its a standard part of the kernel
[04:33] <msg43> G0SUB, are you serious?
[04:33] <G0SUB> `echo mem > /sys/power/state`
[04:33] <msg43> its that simple
[04:34] <Lathiat> the actual suspending does a bit more work
[04:34] <G0SUB> msg43: yes
[04:34] <Lathiat> to make sure everythings in a good state to suspend etc
[04:34] <Lathiat> btu thast the crux of it
[04:34] <Lathiat> see /etc/acpi/sleep.sh iirc
[04:35] <tritium> msg43: and configure acpi-support as I described in #ubuntu
[04:36] <msg43_> well is there anythign I can do to get my video back?
[04:37] <msg43> as when I do that I completely go blinded
[04:37] <G0SUB> msg43: your ACPI is broken most probably
[04:37] <G0SUB> msg43: which laptop is it?
[04:37] <msg43> heh it a desktop
[04:38] <G0SUB> hmm
[04:38] <Lathiat> are you using the nvidia or ati (fglrx) binary drivers?
[04:38] <G0SUB> msg43: is the ACPI standards compliant?
[04:38] <msg43> I believe so
[04:39] <msg43> its a k8mm-v voard
[04:40] <msg43> hhmm no idea?
[05:07] <G0SUB> jdub_: ping
[05:23] <fabbione> morning
[05:23] <YukiCuss> Afternoon.
[06:16] <YokoZar> Is there a place in the filesystem hierarchy that's supposed to be world-writable AND persistant (eg: not /tmp)
[06:16] <nictuku> yes /var/tmp
[06:16] <YokoZar> That's not temporary?
[06:17] <nictuku> it's not deleted on boot, if that's what you're asking
[06:17] <YokoZar> I was just thinking about Wine.  A few users expressed interest in storing Windows applications system-wide, so different users could run them without having different installations in their home directories
[06:18] <YokoZar> A sort of system-wide virtual Windows drive for Wine.  But somehow putting it in /var/tmp jives me the wrong way
[06:18] <crimsun> /var/lib/wine/ ?
[06:19] <YokoZar> crimsun: And make that world-writable?
[06:19] <crimsun> that would be Bad.
[06:19] <nictuku> Bad.
[06:19] <nictuku> less bad if you use the sticky bit, though
[06:20] <YokoZar> Well, it's sort of a given that any Wine-user could hose the shared Wine installation, heh
[06:20] <nictuku> chmod +t
[06:20] <YokoZar> Make a Wine group would be good
[06:21] <nictuku> yes, you would have more control
[06:22] <nictuku> that's more like a spool directory to me, though
[06:22] <nictuku> hmm or not hehe
[06:23] <YokoZar> Making it sticky might break some things (Windows apps tend to want to write to their own program files folder a lot...and My documents)
[06:23] <YokoZar> overwrite, rather
[07:32] <pitti> Good morning
[07:33] <zakame> hello pitti
[07:38] <pitti> hi zakame 
[07:41] <desrt> pitti; SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu1
[07:41] <pitti> desrt: hey
[07:42] <pitti> desrt: what's that about?
[07:42] <desrt> pitti; why do we advertise our exact version number in a way that makes it extremely easy to scan for possible known vulns in particular versions?
[07:42] <pitti> desrt: ah, you mean the ID string at negotiation
[07:43] <desrt> pitti; yes.
[07:43] <pitti> no idea TBH
[07:43] <desrt> pitti; why not send as little information as possible to not violate protocol
[07:43] <desrt> probably something like SSH-2.0-foo
[07:43] <desrt> k.  i'll file a bug then
[07:44] <infinity> desrt: It's a catch-22, we've had administrators tell us that it's valuable to have as much info as possible, so they can run scans on their networks without logging in (or having to have accounts)
[07:44] <infinity> And the bug has been filed.  Repeatedly.  Over several years.
[07:44] <desrt> then i won't :)
[07:45] <desrt> just seems really foolish to announce on connect the equiv of "these exploits will work on me...."
[07:45] <fabbione> desrt: it would work anyway..
[07:45] <desrt> since anyone scanning probably has a list of version#->exploits
[07:45] <fabbione> security trough obscurity is almost pointless
[07:45] <desrt> fabbione; not if the exploits require any degree of effort
[07:45] <pitti> desrt: what would keep them from just trying?
[07:45] <fabbione> desrt: if they really want to open it, they will just try
[07:45] <desrt> pitti; opening a tcp connection and looking is very fast
[07:45] <infinity> desrt: In theory, that's scary, in practice, I've never seen a worm that actually does version number checks, they all just bang you with exploits until one works.
[07:45] <desrt> pitti; trying to exploit a flaw may take much longer
[07:46] <fabbione> desrt: not really...
[07:46] <desrt> pitti; if i know anything about why people get hax0red these days it's because of scanning
[07:46] <desrt> nobody targets _you_.  they just scan...
[07:46] <fabbione> desrt: not true either
[07:46] <infinity> Yes, they scan ports, again, I've never seen anyone target based on version.
[07:46] <G0SUB> fabbione: ++
[07:47] <desrt> muh.
[07:47] <infinity> (And they definitely scan known ports, since I've seen two machines on a network with identical versions of the same software, one on a standard port, one non-standard, and the non-standard one was left alone)
[07:47] <infinity> But none of this will keep someone out who really WANTS in.
[07:47] <desrt> i guess my argument is basically "there's no good reason to have the info there and a good reason (even if it is small) not to"
[07:47] <infinity> However, the odds of kiddies building version support into tools designed to attempt to penetrate thousand of machines seems ridiculous.
[07:47] <pitti> infinity: same for me; I moved ssh to another port to avoid brute force scans (which I had to endure for about a week)
[07:48] <desrt> infinity; this is just my point... nobody really WANTS in anymore
[07:48] <infinity> It's like worrying that spammers will add X-Debbugs headers to their mail, cause they really want to spam the Debian BTS, when they just want to spam SOMEONE.
[07:48] <desrt> infinity; people want to collect the most shell accounts in the least time
[07:48] <infinity> desrt: Right, and the road to "most shell in least time" isn't targetting specific versions, it's hammering everything you have at everyone.
[07:49] <desrt> eh
[07:49] <desrt> if i had a sploit that took manual intervention to properly use i'd run a version scanner to get me a list of all hosts that were vulnerable
[07:49] <infinity> Why go to effort of researching who has what vulns and coding that in your scan tool when you can just attack every port 22 you can find?
[07:49] <desrt> then i'd attack them
[07:50] <infinity> If you have an exploit that requires manual intervention, you're already beyond the average script kiddies, mind.
[07:50] <fabbione> infinity: desrt is a kernel hacker.. he can't be as good as a script kiddie...
[07:50] <desrt> it isn't about script kiddies
[07:51] <infinity> desrt: Of course it is.  You're discussing mass scanning, automation, this isn't about anyone with talent. :)
[07:51] <desrt> infinity; i'm talking about spammers, etc
[07:51] <na7e> anyone here who is decent with gimp wanna make a usplash image for me, possibly for an upcoming offshoot of ubuntu?
[07:51] <desrt> infinity; people with real reasons to control machines on other people's networks
[07:51] <infinity> (Okay, people with talent will occasionally write the tools, but not use them.  And when writing a tool for mass dissemination, you're not going to hardcode applicatoin version numbers for stuff that has a 10 minute life on the internet before people upgrade)
[07:51] <fabbione> na7e: you want to try and ask in #ubuntu-artwork
[07:51] <na7e> ahhhh, thanks :)
[07:51] <desrt> infinity; people upgrade?  heh.
[07:52] <infinity> desrt: It's my experience that "spammers" and "kiddies" fit the same category, as far as how they get in. :)
[07:52] <desrt> infinity; this is the _entire_ point
[07:52] <desrt> infinity; finding the people who _haven't_ upgraded (a lot of them, i assure you) and focusing your efforts there
[07:52] <desrt> infinity; ok.  quite possibly true.
[07:53] <infinity> desrt: Anyhow, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=130876 and its many merged bugs.
[07:53] <Ubugtu> Debian bug 130876 in ssh "Subject: ssh: -5 discloses too much infomation to an attacker" [Critical,Open]  
[07:53] <infinity> Ubugtu's not that bright...
[07:54] <infinity> That bug is wishlist, not critical.  Oh well.
[07:54] <infinity> (It was filed critical, which I guess is the confusion)
[07:54] <desrt> debbugs is actually less usable than launchpad :)
[07:55] <desrt> although, you sort of get the impression that it wasn't designed to be used with a webbrowser as much as an email client
[07:55] <infinity> Not in my experience..
[07:55] <infinity> It's designed to be READ with a web browser, which works very well.
[07:55] <infinity> It can't be manipulated with one, which is fine by me.
[07:56] <desrt> all the 'download as mbox' links are a bit of a tip-off
[07:56] <infinity> At least the bug lists are readable, and not limited to 3 per page for fear of query timeouts. :)
[07:57] <infinity> desrt: Oh, a fair point is made in one comment on this bug...
[07:58] <desrt> what is that?
[07:58] <infinity> desrt: If you're running 3.4pl1 (and that's known to have a root hole, say), people with version scanners will attack you ANYWAY.  The addition of -3debian4.1 or something doesn't make you MORE vulnerable. :)
[07:58] <desrt> i'm advocating the removal of all version information
[07:59] <infinity> 3.4pl1 PLUS PATCHES!  That one's totally more hackworthy than plan upstream 3.4pl1
[07:59] <desrt> not just debian stuff
[07:59] <infinity> That breaks protocol.
[07:59] <desrt> not if you replace it with crap
[07:59] <infinity> (You can LIE about the version, but you can't remove it)
[07:59] <desrt> ssh-2.0-fake0.0
[07:59] <desrt> of course, for the first little while it becomes known that only ubuntu identifies themselves as "fake0.0"
[07:59] <desrt> :p
.. There's a patch in the bug I aimed you at.  Revise it to allow faking the version, and see if Kamion thinks it's not a hideous idea.  I'm assuming he still won't like it unless upstream's all over the idea.
[08:00] <desrt> upstream doesn't like the idea
[08:00] <infinity> (The patch currently is for minimising version infO)
[08:00] <infinity> I know upstream doesn't like the idea.
[08:00] <desrt> another email here says that they have workarounds coded in the client to deal with certain server versions
[08:00] <infinity> Yes, they do.
[08:01] <infinity> Clients and servers both have workarounds to deal with each others' brokennes..
[08:01] <infinity> ness...
[08:01] <desrt> in that case, reporting bad info is worse than no info at all
[08:01] <desrt> since it might enable bad workarounds
[08:01] <desrt> bah
[08:01] <desrt> forget i mentioned it :)
[08:01] <desrt> this issue seems quite entrenched
[08:04] <infinity> Very. ;)
[08:05] <Mithrandir> iirc, Kamion is generally quite reluctant to take patches to ssh that upstream doesn't like.
[08:17] <Burgundavia> Mithrandir, espresso bugs. Worth confirming and triaging or are you and Kamion on them?
[08:21] <Mithrandir> Burgundavia: bugs or missing features?  https://wiki.ubuntu.com/UbuntuExpress/ToDo has a bunch of stuff we know is outstanding so if the problem is listed there it's probably just as good to comment on the bug saying "This is already on the todo"
[08:39] <Burgundavia> Mithrandir, actual bugs, like https://launchpad.net/distros/ubuntu/+source/espresso/+bug/34922/
[08:40] <Ubugtu> Malone bug 34922 in espresso espresso-frontend-gtk "changing the mount point device combobox adds new fields" [Normal,Unconfirmed]  
[09:01] <dholbach> good morning
[09:06] <simira> it's morning, at least
[09:09] <simira> gruff
[09:14] <Mithrandir> mdz: I never received a response about the new xkeyboard-config?
[09:19] <Tm_T> Seveas: whoa, somehow I can't send any messages to #ubuntu+1
[09:36] <sivang> morning all!
[09:36] <hunger> is language-selector known to fail on upgrade?
[09:37] <highvoltage> morning, sivang 
[09:37] <Fjodor> 'morning
[09:37] <sivang> hey highvoltage , 'sup?
[09:37] <highvoltage> sivang: rebuilding asterisk server. you?
[09:38] <sivang> highvoltage: nice, as a debian package? (I'm still hacking on hub)
[09:38] <highvoltage> sivang: nope, as in, an actual server that runs asterisk :)
[09:40] <sivang> highvoltage: ah :) very cool. My cousin uses asterisk as a de-facto standard solution in his consultancy bussiness in NYC.
[09:41] <highvoltage> nice
[09:41] <sivang> highvoltage: I pushed him into implementing Ubuntu as desktop and server for almost every purpose :)
[09:42] <Fjodor> pitti: Sorry I sent you a mail about glibc. Seveas told me it should go to Jeff Bailey. You were just the first I talked to...
[09:42] <pitti> Fjodor: no worries, I forwarded it to Jeff
[09:42] <pitti> hi sivang 
[09:42] <pitti> Fjodor: thanks for the patch
[09:43] <sivang> err,
[09:43] <sivang> :)
[09:43] <highvoltage> sivang: we use ubuntu for our asterisk server, it worked nicely, but it was still running warty, so we decided to just give it a re-install
[09:43] <sivang> (and everybody else for that matter)
[09:43] <sivang> pitti: did you get my bug spam? ;-)
[09:44] <Fjodor> Ah, ok. I subsequently made some changes (much helped by Seveas), and uploaded it to be fetched from my university account. Hope he does that rather than using the one I initially sent you
[09:44] <Fjodor> And np. It is all in my own best interest :-)
[09:44] <pitti> sivang: yes, will look at it ASAP
[09:45] <sivang> pitti: yay!
[10:12] <pitti> sivang: patch looks fine
[10:13] <pitti> sivang: I'll add the bug number to the changelog, test, and upload
[10:16] <pitti> meh, my vim is broken - is that just me?
[10:16] <pitti> it just hangs at the console at start
[10:17] <infinity> Works for me...
[10:18] <pitti> meh, debsign too
[10:21] <pitti> ah, better
[10:22] <sivang> pitti: /me does the happy dance :)
[10:23] <pitti> sivang: thanks for taking care of that bug; dooglus is right, we probably have hundreds of simple-to-fix bugs lurking around which aren't assigned to anybody
[10:25] <sivang> pitti: I've set a goal for myself after HUB and in between, to go over all of his bug which mostly have very good and ready patches, and prepare debdiffs for. Ofcourse until I get approved for main, I will rely on a sponser to get them in :)
[10:25] <pitti> sivang: it'll already help to just verify bugs and assign them to the most appropriate main uploader
[10:26] <sivang> pitti: yes, but as you can see doko took a look at it but it somehow got stuck. So I give my help wherever it's applicable, and well, I could use the packaging / fixing experience :)
[10:27] <pitti> infinity: can you please try something? view /etc/init.d/mountall.sh (assuming that this invokes vi); does vi hang afterwards?
[10:27] <dholbach> pitti: not for me
[10:28] <sivang> pitti: which version of vim you have?
[10:28] <pitti> odd, I reproduced it two times now, and only a reboot seems to fix it; WTF??
[10:28] <pitti> sivang: dapper latest
[10:28] <pitti> 1:6.4-006+2ubuntu1
[10:28] <sivang> same here, doesn't hang
[10:31] <infinity> pitti: Can't break it here.
[10:31] <pitti> hm, the problem seems to be that programs started from the console can't connect to the X socket any more
[10:31] <pitti> infinity: thanks for testing, though
[10:32] <pitti> arrgh, /me slaps his forehead
[10:32] <pitti> mountall.sh cleans /tmp and wipes the X socket
[10:35] <infinity> Y'know, I was going to upload to fix mountall at some point too.
[10:35] <infinity> I guess I'm not the only person it bugs. :)
[10:36] <pitti> sivang: uploaded, thank you
[10:38] <Kamion> desrt: infinity is quite right, faking the version is a hideously bad idea and there *is* a good reason to have the version information in there, i.e. it's been repeatedly requested by network administrators
[10:39] <Kamion> the version information wasn't added for fun - originally, it was requested by Cambridge University's Unix network admins who were trying to do friendly probing across all the ssh servers in the university so that they could advise people of vulnerable installations
[10:39] <Kamion> I have never seen an argument against the version information that's better than the argument for it.
[10:42] <Kamion> no :)
[10:45] <pitti> would it be wrong to set a new default option ('dev.cdrom.lock=0') directly in /etc/sysctl.conf in the procps package? so far it has only comments
[10:46] <Keybuk> what does that one do?
[10:46] <Keybuk> (the sysctl)
[10:46] <pitti> Keybuk: it avoids locking the CD-ROM drive, so that you can eject them using the eject button
[10:46] <pitti> bug 17764
[10:47] <Ubugtu> Malone bug 17764 in eject "Ejecting mounted CDs using eject button on drive" [Wishlist,Fix released]  http://launchpad.net/bugs/17764
[10:47] <Keybuk> is that a kernel thing, or does it appear when you load modules?
[10:47] <pitti> Keybuk: no idea, it's in /proc/sys/dev/cdrom
[10:48] <Keybuk> try it, and reboot; and see whether the sysctl is still set
[10:48] <pitti> yep, that's what I was about to do
[10:48] <pitti> (just booting with init=/bin/bash)
[10:50] <fabbione> dholbach: what's the name of the gnome package that sets up keyboards?
[10:51] <dholbach> fabbione: gnome-control-center?
[10:51] <fabbione> dholbach: ok.. do you have any opinion on #31524 ?
[10:51] <fabbione> it looks everything other than an X bug
[10:51] <dholbach> bug 31524
[10:51] <Ubugtu> Malone bug 31524 in libxkbfile "character problem in turkish Q keyboard " [Normal,Unconfirmed]  http://launchpad.net/bugs/31524
[10:53] <dholbach> fabbione: it could be both... he should add the information the dialog asks him for *GAR*GAR*
[10:53] <Kamion> doko: any chance you could get jline to not need kaffe?
[10:53] <fabbione> dholbach: ok can you please ask him so?
[10:53] <Kamion> I assume it needs to be java-gcj-compat-ised
[10:53] <dholbach> fabbione: done
[10:55] <fabbione> dholbach: thanks
[11:01] <infinity> pitti: Setting sysctls globally is a Bad Idea, as it leads to machines having conniption fits on computers without that hardware or those drivers (see the buildds and their anger over warty setting stuff on powerpc that elmo's kernels couldn't do)
[11:02] <pitti> infinity: agreed, that's why I wonder about the correct place
[11:02] <pitti> infinity: maybe the default should just be changed in the kernel
[11:03] <infinity> pitti: That does seem more sensible, if it's a default we want our desktop users to have,
[11:03] <sivang> pitti: thanks for the upload :)
[11:04] <pitti> infinity: I get many complaints about the ejct button not working, and it generally works well (I just need to automatically unmount the device after its ejection)
[11:05] <infinity> pitti: Yeah, then I say we just change it in the kernel directly.
[11:05] <pitti> infinity: it even works right now, unmounting /cdrom after ejection is merely cosmetical
[11:06] <pitti> Keybuk, infinity: alternatively, could we set this in an udev rule for cd-rom devices?
[11:07] <pitti> it would avoid having to modify the kernel
[11:09] <Keybuk> pitti: I don't see why a udev rule is any good
[11:09] <Keybuk> setting it in sysctl.conf is better than a udev rule
[11:09] <Keybuk> it's easier to find to disable, for one
[11:10] <carlos> pitti: hi, did you see my bug about blender?
[11:10] <pitti> carlos: I'm not yet through my bugs inbox
[11:10] <carlos> ok
[11:10] <Keybuk> also, more pointedly, a udev rule would reset the sysctl every time a cd rom drive was "detected"
[11:11] <Keybuk> which would annoy anyone who kept turning it off again by hand
[11:11] <carlos> pitti: the blender guys want to do a kind of translation day but we don't have Dapper's version imported becuase the fix you did for breezy to regenerate the .pot file was lost with dapper
[11:11] <pitti> carlos: huh? someone dropped it?
[11:12] <infinity> pitti: I'd change the default in the kernel, and add a commented-out entry in sysctl.conf telling people how to change it back.
[11:12] <infinity> pitti: But that's just me.
[11:13] <pitti> ok, I'll ask BenC about it, it sounds good to me at least
[11:18] <doko> Kamion: looking ...
[11:26] <doko> Kamion: jline done
[11:27] <Kamion> thanks, should make the world installable again I think
[11:35] <doko> pitti, Kamion: looking at CD sizes, we maybe want to remove openoffice.org-thesaurus-en-us from language-support-en again ...
[11:35] <doko> - 5MB
[11:48] <Kamion> any gtk/pygtk experts around? I need to create a multi-column list, which is conceptually just one column of data but which is displayed as multiple columns just in order to make better use of horizontal screen space
[11:49] <Kamion> ideally I'd be able to specify the preferred size / aspect ratio of the resulting view
[11:50] <Kamion> as far as I can see GtkTreeView doesn't offer this natively, although it might be possible to build it out of the various building blocks provided ...
[11:51] <Keybuk> a multi-column list would suggest GtkTreeView
[11:51] <Kamion> see my previous comment
[11:51] <Keybuk> which has the most evil API that satan ever spawned
[11:51] <Keybuk> I'm not sure what you mean by "doesn't offer this natively" though
[11:51] <seb128> GtkTreeView is to make different columns in a same table
[11:51] <seb128> not different tables placed side by side for the same model
[11:52] <Kamion> GtkTreeView's existing column interface is designed for rows of data which each have several attributes presented as columns
[11:52] <Keybuk> not necessarily
[11:52] <Kamion> it's not designed to dynamically rewrap a single-column list of data into columns
[11:52] <Keybuk> you can present the same attribute in multiple columns different ways
[11:52] <Kamion> Keybuk: if you know how, then that is my question
[11:52] <seb128> Kamion: I don't know any way to do what you want to do, I guess you will have to split the model and make different TreeView for every model or something like that
[11:53] <Keybuk> Kamion: if you want to do what I think you want to do, then I know how
[11:53] <Keybuk> but you're not being clear enough
[11:53] <Kamion> seb128: ouch
[11:53] <Kamion> Keybuk: example: list of languages in espresso
[11:53] <Kamion> it's very long
[11:53] <Keybuk> oh, I see what you mean
[11:53] <Keybuk> that's evil
[11:53] <Kamion> displaying it in a single column makes poor use of horizontal screen space
[11:53] <seb128> Keybuk: he wants to do | column1 || column1 next items || column 1 ....|
[11:53] <Kamion> I want to wrap this column vertically, newspaper-style
[11:54] <Keybuk> yeah, I understand now
[11:54] <Keybuk> no, you can't do that easilyt
[11:54] <Kamion> can I retain a gtk expert to write a widget to do it for me?
[11:55] <Kamion> it looks to me as if the various pieces of the treeview interface are separated enough that one could write a replacement for just GtkTreeViewColumn or something that would source all the data from a single list
[11:55] <Kamion> maybe not GtkTreeViewColumn, I don't know exactly
[11:57] <Kamion> lots of treeviews as seb128 suggests *might* be possible but it seems to me that trying to make that scroll neatly would be difficult, and making it keyboard-navigable would also be awkward
[11:57] <seb128> Kamion: maybe mvo has some good idea for that, but afaik there is no easy way to do what you are looking for :/
[11:57] <Keybuk> yeah, scrolling and navigation would be the bitch
[11:58] <Keybuk> also working out how many columns you had room for, and responding to resizes
[11:58] <Kamion> because normal behaviour for horizontally-scrolled tables in UIs I've seen is to make the scrolling jump from cell to cell horizontally, not pan smoothly across
[11:59] <Kamion> seb128: right, not necessarily expecting there to be an easy way, but this is for espresso and I think it's one of the "please get a gtk expert to handle this" items that mdz wants me to get others to take care of
[11:59] <Kamion> I saw a reference to some WrapBox widgets in GIMP which somebody claimed might help
[12:00] <Keybuk> yeah, was just reading that one
[12:02] <Keybuk> that has an aspect-ratio propery too
[12:02] <Keybuk> GtkHWrapBox and GtkVWrapBox are the non-abstracts
[12:03] <Kamion> I haven't checked - can you select individual columns in a normal treeview?
[12:03] <Kamion> I thought you could only select whole rows
[12:18] <cmvo> pitti: Hi! I've been referred to you about a possible security update for flashplayer-mozilla and flashplugin-nonfree for breezy and hoary.
[12:19] <doko> Kamion: need a main inclusion report for jline?
[12:19] <pitti> hi cmvo
[12:20] <pitti> cmvo: hm, there has been a recent update for flashplugin-nonfree, is that a different issue?
[12:20] <Cassidy> there is UVF for this package
[12:20] <pitti> cmvo: anyway, I'd gladly do updates if anyone (you?) provide me with tested debdiffs :)
[12:20] <Cassidy> https://launchpad.net/malone/bugs/35425
[12:20] <Ubugtu> Malone bug 35425 in flashplugin-nonfree "UVF exception 7.0.61 -> 7.0.63.1" [Normal,Confirmed]  
[12:20] <cmvo> pitti: Adobe has released a security update for the flash player. See http://www.macromedia.com/devnet/security/security_zone/apsb06-03.html
[12:21] <pitti> cmvo: ah, I remember reading that on bugtraq, right
[12:22] <Kamion> doko: yes please
[12:22] <cmvo> pitti: I don't know if the linux version is vulnerable. But it would be nice to have the newest version.
[12:24] <Keybuk> hmm
[12:24] <Cassidy> and i think than Breezy and Hoary packages are also broken (https://launchpad.net/distros/ubuntu/+source/flashplugin-nonfree/+bug/29214)
[12:24] <Ubugtu> Malone bug 29214 in flashplugin-nonfree "package is falulty in downloading the binary" [Major,In progress]  
[12:24] <pitti> cmvo: hm, before updating the version in breezy there should be regression tests and a verification that it is indeed vulnerable
[12:24] <Keybuk> gtkwrapbox does weird things
[12:24] <G0SUB> is it possible to put in new language packs of Firefox into Dapper?
[12:24] <pitti> G0SUB: there are updates?
[12:24] <pitti> G0SUB: from upstream?
[12:24] <G0SUB> pitti: no, new languages ... not in upstream yet
[12:25] <pitti> G0SUB: ah; yes, sure, if someone tosses me an xpi, I can include it
[12:25] <G0SUB> pitti: do I need to file a bug?
[12:25] <pitti> G0SUB: you can if you want; would be nice to have references and not forget about it
[12:25] <G0SUB> pitti: I will do that rightaway :)
[12:25] <pitti> G0SUB: assign it to me (martin.pitt@ubuntu.com) please
[12:25] <G0SUB> thanks a lot
[12:25] <pitti> cool, thanks
[12:25] <G0SUB> okay
[12:26] <Kamion> Keybuk: if you could take this on for the espresso GTK frontend language and keyboard selection widgets, I'd be very grateful
[12:27] <cmvo> pitti: I could test on hoary and breezy in addition to dapper. But I don't know if Adobe will confirm if the linux version is vulnerable.
[12:27] <Keybuk> the box thing seems to be what gimp uses for its toolbar palette
[12:27] <Keybuk> so you'd get that behaviour
[12:30] <cmvo> pitti: Lots of work for something non-free, but some users I support need it for a few webpages.
[12:31] <pitti> cmvo: I guess the package has no source, so we can either take the new upstream version, or not fix it at all?
[12:34] <cmvo> pitti: flashplugin-nonfree is an installer, there should be source. But I don't think it gets the newest version automatically.
[12:35] <pitti> slomo_: ^ any idea about that one? IIRC it was you who proposed the last update, right?
[12:36] <Kamion> Keybuk: that seems OK, if it works for text too
[12:36] <Keybuk> Kamion: what's the GTK frontend written in?
[12:36] <cmvo> pitti: It seems it doesn't, according to bug #35425 in lauchpad.
[12:36] <Ubugtu> Malone bug 35425 in flashplugin-nonfree "UVF exception 7.0.61 -> 7.0.63.1" [Normal,Confirmed]  http://launchpad.net/bugs/35425
[12:36] <Kamion> Keybuk: hmm, would need to give it scrollbars though
[12:36] <Kamion> Keybuk: python
[12:36] <Kamion> and glade
[12:36] <Kamion> I do already have a C widget in there though
[12:36] <Keybuk> I'm not sure wrapbox is appropriate
[12:36] <Keybuk> it's not scrollable
[12:36] <Keybuk> is damned slow
[12:36] <Kamion> ah, ok
[12:37] <Keybuk> and there's no easy way to make all the contained buttons the same size, fwict
[12:37] <Kamion> the C widget's for the timezone map, I added python bindings
[12:37] <pitti> sjoerd: ping
[12:37] <sjoerd> pitti: pong
[12:38] <pitti> sjoerd: it seems that we need to run gen-libgphoto-hal-fdi during hal's package build (or even better, at postinst time), right?
[12:38] <Keybuk> Kamion: http://people.ubuntu.com/~scott/wrapbox.tgz
[12:38] <pitti> sjoerd: otherwise non-PTP cameras won't be detected by g-v-m
[12:38] <Keybuk> (unpack in a dir, make, ./gtkwrapbox-test) -- that demos what that would do
[12:39] <doko> pitti: please review https://wiki.ubuntu.com/MainInclusionReportJline
[12:39] <StevenK> NEVets1
[12:39] <StevenK> Oh crap
[12:39] <siretart> rootpw ;)
[12:39] <StevenK> No so much
[12:39] <Kamion> Keybuk: ew, definitely don't want it to be buttons for each language
[12:39] <StevenK> Er, not
[12:39] <G0SUB> pitti:  Bug #35704
[12:39] <sjoerd> pitti: best solution would be for libgphoto2 to include the fdi for hal
[12:39] <Ubugtu> Malone bug 35704 in firefox "Locale for Bengali-India (bn_IN) is not available" [Normal,In progress]  http://launchpad.net/bugs/35704
[12:40] <Keybuk> Kamion: indeed; not sure this widget is appropriate
[12:40] <Kamion> the presentation of a normal treeview with cellrenderertext is appropriate, it just needs to be multi-column ...
[12:40] <pitti> G0SUB: thanks
[12:40] <pitti> doko: queued
[12:40] <G0SUB> pitti: my pleasure :)
[12:40] <sjoerd> pitti: i talked to the libgphoto maintainer about this once and he thought it was a good idea, but it stayed at that i gues..
[12:40] <Keybuk> Kamion: yeah, the bitch there is deciding how to scroll it :)
[12:41] <Keybuk> I guess horizontally is "canon"
[12:41] <pitti> sjoerd: ok, doing it this way around would probably work, too
[12:41] <pitti> sjoerd: so we just need to ship that tool in hald
[12:41] <pitti> s/hald/hal package/
[12:42] <sjoerd> pitti: would be better if the scripts was in the debian pcakge for libgphoto2.. no need to have it on your system or have the buildd's install hal to build libgphoto
[12:42] <Kamion> Keybuk: horizontal is fine and what Mark asked for
[12:43] <sjoerd> pitti: the script is trivial and doesn't really change..
[12:43] <pitti> sjoerd: true that
[12:43] <pitti> sjoerd: alright, thanks for your feedback
[12:43] <sjoerd> pitti: np, thanks for reminding me of the issue ;)
[12:46] <Keybuk> GOD DAMN CDBS TO HELL
[12:46] <Keybuk> quest gtk+2.0-2.8.16% debian/rules extract
[12:46] <Keybuk> debian/rules:6: /usr/share/gnome-pkg-tools/1/rules/uploaders.mk: No such file or directory
[12:47] <Keybuk> I HATE YOU
[12:47] <Kamion> Keybuk: no, you can't have the source, why did you ask?
[12:47] <Keybuk> apparently I need to install exim4 just to FUCKING UNPACK a source package!
[12:47] <dholbach> Keybuk: gtk+2.0 doesnt use cdbs
[12:48] <Keybuk> dholbach: well, whatever it uses should be burned
[12:48] <pitti> Keybuk: missing dependency on gnome-pkg-tools?
[12:49] <pitti> Keybuk: or, rather, you don't have it installed?
[12:49] <seb128> Keybuk: it uses DBS, so stop ranting about CDBS now :p
[12:50] <pitti> he should rather rant about packages which modify debian/control :)
[12:50] <seb128> Keybuk: and how does that make you installed exim4?
[12:52] <Keybuk> pitti: packages should be able to be unpacked with just build-essential
[12:52] <Keybuk> I should not need the entire list of build-deps just to read the damned source
[12:52] <pitti> Keybuk: I fully agree :)
[12:52] <Keybuk> seb128: gnome-pkg-tools -> svn-buildpackage-> exim4
[12:52] <Kinnison> svn-buildpackage needs exim4?!?!?!?!
[12:53] <pitti> I guess that was just an exaggeration
[12:53] <Kinnison> for added emphasis
[12:53] <Tm_T> :p
[12:53] <Keybuk> Kinnison: yes, because subversion-tools depends on a mail-transport-agent
[12:53] <Tm_T> I'm very frustrated
[12:53] <Tm_T> I don't get pypanel to work in my dapper
[12:54] <Keybuk> because it contains one script (out of a hundred) that uses /usr/sbin/sendmail
[12:54] <Kinnison> odd
[12:54] <Keybuk> Kinnison: you don't have the recommends installed then
[12:54] <Kinnison> god no
[12:54] <pitti> Keybuk: svn-buildpackage is only a Recommends
[12:55] <Keybuk>           The `Recommends' field should list packages that would be found
[12:55] <Keybuk>           together with this one in all but unusual installations.
[12:55] <Keybuk> suggests me to me that Recommends should be installed by default
[12:55] <pitti> so that should be a Suggests: rather
[12:55] <Kinnison> I don't install recommends because most packages put stuff in recommends which should be in suggests
[12:55] <Keybuk> it's still a minor issue compared to the "packages should only use build-essential to unpack themselves "one :)
[12:56] <Kinnison> Keybuk: get Wig&Pen sorted and I'm sure we can work toward that
[12:56] <Keybuk> Kinnison: what's that got to do with me?
[12:56] <Keybuk> that's a dpkg issue
[12:56] <Kinnison> Keybuk: you're whinging
[12:56] <Kinnison> Keybuk: s'your itch
[12:56] <pitti> Keybuk: debian/control mangling is usually in the clean rule; where else could it live?
[12:57] <Keybuk> it's an itch of every sensible and right-thinking person in the free world
[12:57] <Keybuk> damnig
[12:57] <Keybuk> mvo: please do
[12:58] <Keybuk> if people get Recommends by default, they'd stop abusing it
[12:58] <Keybuk> (Mr. I abuse package fields regularly) :p
[12:58] <mvo> seb128: sorry, but that's the way forward
[12:58] <seb128> that's not true :p
[12:58] <seb128> mvo: sure, you want to make a mess for dapper just do it
[12:58] <mvo> seb128: I may consider adding --no-recommends ;)
[12:58] <seb128> mvo: I think we should take a cycle to clean Recommends before doing that
[12:58] <mvo> seb128: dude, not dapper
[12:58] <Treenaks> mvo: 99% of Recommends: are crap now
[12:59] <Keybuk> Kamion: ok, so modifying the GtkTreeView code is a non-starter
[12:59] <Mithrandir> seb128: did we or didn't we get an UVF exception for xkeyboard-config?  It appears mdz has disappeared off the face of the earth.
[12:59] <Keybuk> the code is as bad as the API
[12:59] <mvo> Treenaks: agreed. the only way to fix this is to make them installed by default 
[12:59] <seb128> mvo: oh, your TODO goes after dapper .... I can find you some dapper items if you want :p
[12:59] <mvo> seb128: I already start crying when looking on my todo list, don't make it worse
[01:00] <seb128> Mithrandir: I think he didn't reply to your ping from friday ...
[01:00] <Keybuk> Kamion: what do you want each cell to look like?
[01:01] <seb128> Mithrandir: better to wait before uploading imho
[01:03] <pitti> mvo: hm, what would make a Recommends different from a Depends then? only that you can uninstall it again?
[01:03] <seb128> pitti: yeah, I think that's the goal. Stuff that should be installed by default because most user need them but than a poweruser may want to uninstall
[01:04] <seb128> pitti: like libgnomevfs2-extra (smb:)
[01:04] <mvo> pitti: exactly this
[01:04] <Keybuk> pitti: Recommends is supposed to be an optional dependency
[01:05] <Keybuk> "you should really have this, but the world won't end without it"
[01:05] <Keybuk> "kittens may die, but not the mother"
[01:05] <Keybuk> etc.
[01:05] <Keybuk> whereas Suggests is "no kittens will be harmed if you don't install this"
[01:06] <Kinnison> We have 'Enhances' yes? Do we have 'Enhanced-By' or similar?
[01:06] <Keybuk> Kinnison: that would be Suggests
[01:06] <Keybuk> Enhances is the opposite of Suggests
[01:06] <Keybuk> A Enhances B ~= B Suggests A
[01:07] <Kinnison> To me, Suggests is stronger than Enhanced-By, but that's probably just my interpretation of the english
[01:07] <Kinnison> Esp. if Recommends is "Depends which can be uninstalled without breaking the world"
[01:08] <Keybuk> they both indicate a relationship that should not be followed by default
[01:08] <Keybuk> from a package manager point of view, what would be the difference between Enhanced-By and Suggests?
[01:09] <Keybuk> Depends = (follow, unbreakable); Recommends = (follow); Suggests = ()
[01:09] <Keybuk> Enhances = (), just the other way around
[01:09] <Kinnison> from a package manager PoV, they're equivalent
[01:09] <Kinnison> I'm thinking from a user PoV
[01:10] <Kinnison> give me a minute or two
[01:10] <Treenaks> You could have external entities creating packages that 'Enhances:' something (but the package can't Suggests: those, because they're external)
[01:11] <Treenaks> And you might be warned if you deinstall the package that gets enhanced but not the enhancers
[01:11] <Kinnison> I think the difference is. Suggests are something which the package will use if it finds them and Enhanced-By are things which might be useful to have around which aren't directly related
[01:11] <Kinnison> But I'm not 100% on that yet
[01:13] <Kinnison> Keybuk: Nope, I agree, nothing I can think of from a use-case PoV needs Suggests/Enhanced-By to be split into separate fields because each use-case I come up with the result is that either would do. You're right.
[01:17] <Kamion> Keybuk: each cell should look like a cell in the existing espresso language/keyboard selection widgets
[01:17] <Keybuk> I don't know what those look like, do you have a screenshot?
[01:18] <Kamion> Treenaks: that was indeed the original rationale for enhances
[01:19] <Kamion> Keybuk: http://people.ubuntu.com/~cjwatson/tmp/espresso-sideimage-keyboard.png is an old screenshot which happens to show it
[01:21] <slomo_> pitti: flashplugin-nonfree? no idea and i didn't propose the last update ;)
[01:22] <pitti> slomo_: ok, thanks :)
[01:24] <Keybuk> it'd probably be easiest to modify the old GtkList widget into doing the right thing
[01:25] <Keybuk> but then seb128 would have "you're using a deprecated widget!" kittens
[01:27] <Kamion> is there any way at all to do it using the hooks that pygtk provides for constructing custom treemodels and the like?
[01:27] <Kamion> I'd much rather the widget be in python if at all possible
[01:27] <Keybuk> I have no idea
[01:27] <Keybuk> I know more about botany than I do about pygtk
[01:28] <Keybuk> from what I know of the treeview widget, I doubt it
[01:28] <Keybuk> each column is a widget in its own right
[01:29] <Keybuk> the entire column (each row, the spacers, etc.) are all drawn by the same cell renderer widget
[01:29] <Keybuk> you'd have to have a treeview that when reaching the end of the vertical allocation, created a new column, and assigned the items to that
[01:30] <Keybuk> and that's just not supported by the model/view interface it uses
[01:30] <Keybuk> we're pretty much in "write a custom widget from scratch" territory I think
[01:31] <Mithrandir> you want something like the horrible, horrible cups printer manufacturer widget?
[01:31] <Keybuk> Mithrandir: ooh, where can I see that?
[01:32] <fabbione> ogra: ping?
[01:32] <Keybuk> Mithrandir: the cups "Add a printer" thing here uses the standard widget fwict
[01:32] <ogra> fabbione, pong
[01:32] <Kamion> Keybuk: the alternative, I suppose, is just to hardcode a bunch of columns in the calling code, given that the interface is pretty much fixed-size
[01:33] <Kamion> but that would break different font selections (e.g. accessibility) so is probably a non-starter
[01:33] <Keybuk> Mithrandir: it's just a single column list of models
[01:33] <Keybuk> tbh, I'd just use one column :)
[01:34] <Mithrandir> Keybuk: no, the manufacturer list
[01:34] <Keybuk> Mithrandir: that's a drop-down here, not a list
[01:34] <Kamion> Keybuk: Mark explicitly asked me to stop doing that
[01:34] <Mithrandir> yes, and it's a horrible 3xN matrix.
[01:34] <Kamion> and I can see his point, the current UI is nasty
[01:34] <Keybuk> Kamion: yes, well, Mark isn't very good at user interface design
[01:35] <Kamion> Keybuk: in this case he's absolutely right
[01:35] <Keybuk> inventing a custom widget that behaves exactly the opposite to every other widget on the system is wrong
[01:35] <Kamion> if you fire up espresso and look at the language page, it *sucks*
[01:35] <Keybuk> Mithrandir: hmm, I see what you mean; they've just used a popup menu
[01:35] <Kamion> there's a huge pile of empty vertical space that there's no easy way to fill
[01:35] <Kamion> er, empty horizontal space
[01:36] <Keybuk> why not use the empty horizontal space to display an image of the keyboard layout currently highlighted?
[01:36] <Kamion> works for keyboard, what do you do for language?
[01:36] <Keybuk> in fact, almost exactly like the GNOME one does currently :)
[01:36] <Kamion> I'm not convinced that the GNOME one is the epitome of usability
[01:37] <Keybuk> no, the treeview on the left is too small
[01:37] <Keybuk> but having an image of the keyboard is damned useful, you can just scroll with the arrows and match it up
[01:37] <Mithrandir> Keybuk: no, we can't do that.  We have no idea what the keyboard looks like.
[01:37] <Kamion> it forces you to scroll a great deal, and to know what your keyboard layout is called in order to have a hope of scrolling to roughly the right place
[01:37] <Kamion> oh yeah, plus what Mithrandir said due to the limitations of how we're handling keyboards in espresso at the moment
[01:37] <Kamion> (remember that the GNOME keyboard layout widget has the luxury of only having to select X keymaps)
[01:37] <Keybuk> *shrug* I still think it's better than inventing a sideways widget
[01:38] <Mithrandir> we're really forcing d-i to do stuff that it wasn't near being designed to do.
[01:38] <Kamion> that's not particularly the problem, and that can be fixed after dapper once we move to cxkb or whatever
[01:42] <Kamion> Mithrandir: how close are you to something we can merge for keyboard selection?
[01:42] <Kamion> Kinnison: are you still launchpadding this week?
[01:42] <Mithrandir> Kamion: tomorrow, I hope.  The Korean stuff works now, I'm just waiting for mdz to get around to approving my UVF exception request.
[01:45] <Kamion> ok, thanks
[01:45] <Kinnison> Kamion: No, I'm currently catching up on everything for distro
[01:46] <Kinnison> Kamion: So if you have stuff for me for espresso, then go ahead, otherwise I believe I have the de-tabbing and stage X of Y to implement in espresso
[01:46] <fabbione> so i just figured that we have an xterm package that sucks
[01:46] <Kinnison> and other than that, ca. 75 mails from launchpad about bugs in g-p-m etc
[01:46] <fabbione> the worst part is that the orig is native
[01:46] <fabbione> what was the trick to switch it have to orig.tar.gz?
[01:47] <Kamion> Kinnison: right, the breadcrumbs thing was what I was thinking of
[01:47] <Kamion> fabbione: stick the .orig.tar.gz in .., rebuild with -sa
[01:48] <fabbione> Kamion: isn't LP going to hate me for that?=
[01:48] <Kinnison> Kamion: I'll do that before I get to the g-p-m mails then
[01:48] <Kinnison> fabbione: Ensure it's a newer version too
[01:48] <Kinnison> fabbione: then it should be fine
[01:48] <Kamion> fabbione: why would it?
[01:48] <fabbione> Kinnison: newer as in upstream or debian/ubuntu?
[01:48] <Kinnison> the latter
[01:48] <fabbione> Kinnison: ok
[01:48] <fabbione> Kamion: dunno.. i never had to do it before
[01:48] <Kamion> "foo.tar.gz" != "foo.orig.tar.gz", which is all that matters
[01:48] <Kinnison> Kamion: because LP is a grouchy complaining crotchety youngling
[01:49] <Kamion> if the filenames clashed, then there would be a problem, but they don't
[01:49] <fabbione> ok
[01:49] <fabbione> thanks
[01:54] <carlos> doko: hi, around?
[01:54] <doko> carlos: yes
[01:55] <carlos> doko: I have ooo-unused and ooo-help translation domains on dapper for OpenOffice
[01:56] <carlos> doko: the others are already imported for dapper, what should I do with those two?
[01:56] <carlos> import? ignore?
[01:57] <doko> carlos: we did talk about ooo-help, that will be splitted
[01:58] <doko> -unknown: I can't see that ooo-unknown is still generated
[01:58] <carlos> doko: i Know, that's why I'm asking, just to confirm that I should ignore that import, right?
[01:59] <carlos> doko: so I can ignore the unused, ok
[02:00] <carlos> lunch time
[02:00] <carlos> later
[02:00] <doko> carlos: don't start your talks before lunch ;-P
[02:02] <carlos> doko: Is there anything elso to talk? I think I got the info I needed :-P
[02:02] <carlos> doko: btw, thanks :-D
[02:03] <doko> carlos: yes, ignore me^Wthem :-D
[02:05] <Keybuk> Kamion: really doesn't look like it's easy to modify gtktreeview into doing the right thing
[02:05] <Keybuk> the trouble is that there's no way to find out that you've reached the bottom and need to wrap back to the top
[02:05] <Keybuk> *and* be scrollable
[02:14] <fabbione> dholbach, seb128: /usr/share/menu/xterm
[02:14] <fabbione>  <- is this the correct location?
[02:15] <dholbach> fabbione: for what? a debian style menu entry?
[02:15] <dholbach> fabbione: if you want a gnome menu entry, you want /usr/share/applications/something.desktop
[02:16] <fabbione> dholbach: that's from debian 
[02:16] <fabbione> so i guess it's fine there
[02:17] <fabbione> thanks
[02:17] <seb128> fabbione: that one will give you a Debian menu item
[02:17] <fabbione> seb128: thanks
[02:17] <fabbione> i am ok with that
[02:19] <mdz> Mithrandir: I have no mail in my inbox from you
[02:20] <Mithrandir> mdz: no, because I asked you about it on Friday and then you went silent.
[02:20] <Mithrandir> mdz: the diff isn't very useful since we have something resembling upstream's 0.7 as our 0.6
[02:21] <mdz> Mithrandir: IRC messages over the weekend are not reliably received; sometimes I do actually leave home
[02:21] <mdz> email is best for that sort of thing
[02:22] <mdz> come to think of it, I wasn't even logged into IRC on Friday; I was still in transit
[02:23] <Mithrandir> mdz: you said something at 11:15 UTC at least.  I asked you about 30 minutes later.
[02:23] <Mithrandir> mdz: anyway, sure, you'll get mail next time.
[02:23] <mdz> Mithrandir: I left at 11:30 to go to Heathrow
[02:24] <Mithrandir> mdz: the upstream NEWS file just says: "Maintenance release. Bugfixes. Updated/new translations. Updated/new layouts. Massive patch from Sun Microsystems incorporated.".  seb128 and I have been running the new version for a few days without ill effects.
[02:25] <seb128> and according to daniels that should be ok
[02:25] <Mithrandir> mdz: the most important bug it fixes is 21595 which (as you can see) half the world is subscribed to.
[02:27] <mdz> Mithrandir: the patch we have in breezy was supposed to fix that as well, but it's unclear to me whether it actually did
[02:30] <Mithrandir> mdz: it appears not to.
[02:30] <Mithrandir> mdz: also, it apparently fixes a crasher in gnome-settings-daemon.
[02:30] <Mithrandir> seb128: ^^ is that correct?
[02:31] <mdz> Mithrandir: I talked with seb about 0.8 last week and I think we should try it, but sooner rather than later
[02:31] <mdz> Mithrandir: and with an explicit call for testing
[02:32] <Mithrandir> mdz: sure, I have the upload lined up already.  It also adds Korean support, so we just need to fix some minor faff in Xorg and scim-hangul; then Korean keyboards will work correctly out of the box.
[02:32] <Mithrandir> mdz: I was just waiting for a go from you.
[02:32] <mdz> Mithrandir: go
[02:34] <Mithrandir> uploaded.
[02:34] <Mithrandir> (and thanks)
[02:34] <seb128> Mithrandir: yeah, correct
[02:35] <Mithrandir> seb128: can you send out a call for testing of 0.8?
[02:38] <Kamion> mdz: did you get round to talking with kiko/elmo about the status of the sync tool?
[02:38] <Kamion> if it's working, I'd like to try it out by syncing in bcm43xx-fwcutter
[02:38] <mdz> Kamion: I did talk with kiko but did not reconcile what he told me with elmo yet
[02:38] <seb128> Mithrandir: hum, keyboard is basically something used by everybody 
[02:38] <mdz> elmo: ?
[02:38] <seb128> what call for testing?
[02:38] <seb128> "let we know if your keyboard is broken"?
[02:39] <seb128> I think people will complain about it without any invitation :p
[02:40] <Kamion> "let us know if your keyboard never used to work but now does", perhaps ...
[02:40] <pitti> seb128: how should they type the answer email? :-P
[02:40] <pitti> seb128: (if it's broken)
[02:41] <seb128> selecting chars with the mouse from gucharmap and copying them?:)
[02:42] <Mithrandir> pitti: they should manage when I've gotten korean keyboards to work without knowing korean
[02:48] <fabbione> hmm not too bad
[02:48] <fabbione> from 200 to 183 bugs in one day of X work
[02:54] <Kamion> mdz: kiko is incorrect
[02:54] <Kamion> mdz: maybe some bits of it work, but /srv/launchpad.net/codelines/current/scripts/sync-source.py definitely doesn't
[02:55] <Kamion> oh, hmm, I need LPCONFIG=ftpmaster
[02:55] <Kamion> still fails though
[02:55] <Kamion> psycopg.OperationalError: FATAL:  Ident authentication failed for user "ro"
[02:55] <Kamion> ; used connection string 'dbname=launchpad_prod user=ro host=jubany.ubuntu.com'
[02:56] <mdz> Kamion: seems like deployment problems rather than incompleteness so far
[02:56] <mdz> kiko should be awake
[02:59] <fabbione> hey mdz
[03:00] <mdz> good morning
[03:02] <lemsx1> good morning
[03:12] <Robot101> # and caaan you feeel the love tonight...
[03:12] <jsgotangco> errr
[03:13] <zakame> oooh
[03:16] <mdz> jdub: fridge calendar needs updating for the new release schedule
[03:16] <aquarius> Will a package that has recently gone into Debian unstable make it into Dapper? I don't know when the next sync-with-Debian is, or whether there's one before the release.
[03:17] <Kamion> aquarius: not in general before release, although we can make specific exceptions
[03:18] <aquarius> Kamion: ah, OK. Is a recent unstable Debian package likely to work in Dapper? It's gccxml.
[03:19] <Keybuk> wow, what a hack
[03:19] <Keybuk> cute, but eeeevil
[03:20] <Kamion> doko: opinion on gccxml?
[03:22] <doko> Kamion: for main???
[03:22] <doko> no, that's based on gcc-3.2.something
[03:22] <Kamion> doko: no, to sync from Debian
[03:23] <doko> universe, why not
[03:23] <aquarius> doko: the Debian package is based on a CVS gccxml, which works with gcc 4.0.
[03:23] <fabbione> Kamion: could you be so kind to tell me why ubuntu-desktop is still not installable on sparc? infinity and I fixed the powermanagement-interface this morning, but i can see there might be more around...
[03:23] <fabbione> Kamion: i would do it myself.. but -ENOSPARC for a couple of days
[03:23] <aquarius> (or so the ITP and surrounding mails say)
[03:24] <doko> aquarius: they do write that, but looking into the source, before it went into debian, it had the 3.2 version strings.
[03:24] <Kamion> fabbione: difficult to say without just trying apt-get install, I'm afraid
[03:24] <fabbione> Kamion: ok :/
[03:24] <Kamion> britney isn't particularly big on extra debugging output
[03:24] <aquarius> doko: ah -- I'm happy to bow to your wisdom on this. I want to use it for wrapping a C library with Python, and I didn't want to compile it myself if it's going to appear in Dapper tomorrow. :)
[03:25] <fabbione> i don't know why i had the feeling we had a tool to catch that...
[03:25] <Kamion> fabbione: uninstallable gnome-power-manager seems like a possibility
[03:27] <fabbione> Kamion: that should have been sorted with new powermanagement.. but i will look.. thanks mucho
[03:31] <Kamion> mdz: remember the talk at the UI sprint about wanting the language and keyboard selectors to be horizontally-scrolling tabular lists?
[03:33] <Kamion> mdz: we've been looking at that today, and it's more difficult than expected; getting the right scrolling, keyboard navigation, placement depending on fonts etc. semantics isn't possible with anything GTK gives us at the moment
[03:33] <Kamion> mdz: Keybuk estimates ballpark 2-3 days to write the widget; do we want it enough to have him spend that time?
[03:34] <mdz> Kamion: I'm not sure what you mean by horizontally-scrolling tabular lists
[03:34] <Kamion> mdz: having the list of languages etc. be vertically wrapped, newspaper-style
[03:35] <Kamion> oh, you weren't there on Friday
[03:35] <mdz> no
[03:35] <Kamion> the language and keyboard selectors are currently simple vertical lists
[03:35] <mdz> can you give me an example of something similar in another program?
[03:35] <Kamion> the problem with this is that it makes very poor use of screen space, and you end up with big empty spaces in the dialog
[03:35] <Keybuk> there is nothing similar in another program
[03:36] <Keybuk> the "closest" thing is the "Add Printer" "Manufacturer" drop-down ... like that, but as a horizontally-scrolling list box
[03:36] <mdz> oh, I see
[03:36] <mdz> you are talking about a multi-column layout
[03:36] <Kamion> sabdfl asked for this to be changed so that it wraps vertically, a bit like say the entries on the Windows start menu
[03:36] <Kamion> well, at least the start menu circa Windows 95 ;-)
[03:36] <Kamion> and you then scroll left/right in case not all the languages fit
[03:37] <mdz> right, I think I understand now
[03:37] <Kamion> that would allow the widget to take up more of the screen, and increase the chance that your language is immediately visible
[03:37] <mdz> since the request came from sabdfl, the question would be how badly he wants it
[03:37] <mdz> I don't think I can speak to that
[03:37] <Kamion> sabdfl: see the above discussion?
[03:37] <sabdfl> mdz: i'm watching
[03:37] <sabdfl> the discussion
[03:38] <sabdfl> don't have time to fix gtk on this one
[03:38] <sabdfl> so lets go with a smaller list and find a way to lay it out so it looks reasonable
[03:38] <sabdfl> this bits us in a couple of places
[03:38] <sabdfl> maybe ddlb?
[03:38] <Kamion> ddlb?
[03:38] <Keybuk> ddlb?
[03:38] <sabdfl> drop-down list box
[03:38] <sabdfl> i think that's what the mac os uses for, say, lists of countries
[03:39] <Kamion> drop-down felt pretty unpleasant to me when I tried it
[03:39] <Kamion> oem-config uses that
[03:39] <Kamion> also, since the espresso window is fixed-size based on the largest of any of its pages, that would leave even more empty space on the screen
[03:39] <sabdfl> yeah, it's not right, but it has the advantage that it can use more of the screen when it's in use
[03:39] <Kamion> you'd have a tiny drop-down widget sitting in the middle of it :)
[03:39] <mdz> sabdfl: yes, that's what the OS X installer uses
[03:40] <sabdfl> i'm wondering if we can't combine that question with other questions
[03:40] <sabdfl> so we get more efficient use of space
[03:40] <Kamion> not at all easily, I'm afraid
[03:40] <sabdfl> but you sort of need that done before you can do anything
[03:40] <mdz> right
[03:40] <sabdfl> there is the space where people will type to confirm their keybord is set correctly
[03:40] <na7e> howdy sabdfl
[03:40] <sabdfl> hi na7e
[03:40] <Kamion> in order to do that we'd have to have multiple debconf backends running at once, which is sort of direly painful
[03:41] <sabdfl> sounds excruciating
[03:41] <sabdfl> pass on that then :-)
[03:41] <sabdfl> Kamion: this should not be a blocker for the next round, just do what works, we will prettify later
[03:41] <sabdfl> how is it coming along based on ui sprint feedback?
[03:41] <Kamion> although, er, well, maybe in theory, beginblock/endblock could help - but I think that's post-dapper
[03:41] <sabdfl> is this the last issue on your list?
[03:42] <Kamion> no, it's the hardest remaining thing outside partitioning
[03:42] <Kamion> progress is pretty good again now, I just lost a lot of time last week to the breezy installer vulnerability
[03:42] <Kamion> got the disk selector in this morning
[03:44] <Kamion> localisation basically works, and I have a nearly-full Portuguese translation to test with now
[03:45] <sabdfl> does gtk not give you a cell view, like a spreadsheet?
[03:46] <Kamion> Kinnison: while I remember, there's some badness in gparted at the moment; the ok-to-apply dialog never appears
[03:46] <Kamion> sabdfl: not that any of us can see - that would be ideal
[03:46] <Kamion> perhaps there's something thievable in gnumeric
[03:46] <na7e> would be nice if gtk did
[03:47] <Kinnison> Kamion: Urgh
[03:47] <Kinnison> Kamion: it's supposed to
[03:47] <Kamion> ta
[03:47] <sabdfl> no reason not to embed a spreadsheet in the installer :-)
[03:47] <Kinnison> it'll add intelligence to the mix
[03:48] <Mithrandir> Kinnison: and you'll only be able to install with an irish accent? :-)
[03:48] <Kinnison> Mithrandir: no, but it'll karate-kick you if you make a wrong choice
[03:48] <sabdfl> kiko, jamesh are saying there's a gtk table
[03:49] <na7e> i was thinking something completely different, hrm
[03:50] <Kamion> is gtk.Table really appropriate? I normally use it for laying out widgets in the same way I'd use a vbox/hbox
[03:50] <Kamion> with gtk.Table you'd still have to implement keyboard navigation, I'd expect
[03:50] <Kamion> and it would not be able to automatically reflow columns based on the available size
[03:51] <Kamion> tables are for very fixed layout, which this isn't really
[03:51] <jamesh> Kamion: do you have a web page or mockup of what you are after?
[03:51] <Kamion> jamesh: no, but think newspaper columns
[03:51] <Kamion> only with each line on each column being a choice from a liststore
[03:52] <Kamion> when it runs out of vertical space, it should wrap the list onto the next column and carry on
[03:52] <Kamion> if it runs out of horizontal space, it should scroll
[03:53] <jamesh> Kamion: I don't think there is a ready made widget that'll do all of that
[03:53] <Kamion> that was indeed the general opinion. how hard would it be to write one?
[03:54] <jamesh> using a list store as a backend?
[03:54] <jamesh> probably hard
[03:55] <Kamion> doesn't have to be a list store
[03:55] <Kamion> I have a big list of strings
[03:56] <jamesh> there is a GtkWrapBox widget in gimp that does some of what you want
[03:56] <jamesh> it acts like a GtkBox but wraps when it runs out of space
[03:56] <Kamion> Keybuk looked at that but seemed to think the result was poor
[03:56] <jamesh> it has size allocation issues though
[04:11] <Keybuk> jamesh: the allocation issues were a bit of a problem; and also the fact it's not scrollable
[04:11] <Keybuk> so Colin would have to make sure the list of languages/keyboard layouts fit on one page
[04:12] <Keybuk> and then there's the question of what exactly you pack *into* the box; buttons not being that great
[04:15] <sabdfl> Kamion: http://www.sicem.biz/personal/lgs/projects/gtkgrid/view_screenshots
[04:15] <sabdfl> http://www.sicem.biz/personal/lgs/projects/gtkgrid/view_project
[04:15] <sabdfl> kiko says "this may not work today"
[04:15] <Keybuk> sabdfl: that looks like an ordinary GtkTreeView?
[04:16] <sabdfl> no, it's a GtkGrid
[04:16] <Kamion> sabdfl: looks like that doesn't actually wrap vertically, since cells are falling off the bottom and there's a vertical scrollbar
[04:16] <Keybuk> but I can't see what it's doing that GtkTreeView doesn't do
[04:16] <Kamion> which isn't what we want
[04:16] <sabdfl> kamion: we know in advance what language/keybd to put in what cell
[04:16] <Kamion> sorry, I guess I wasn't quite with-it when I said that a spreadsheet-style cell grid would be perfect - the requirement to wrap vertically makes it very different from a spreadsheet
[04:17] <sabdfl> we don't need it to figure that out dynamically
[04:17] <Kamion> sabdfl: but we don't know the font size
[04:17] <Kamion> which will be completely different if you're running with accessibility support turned on
[04:17] <Kamion> we can't just hardcode the vertical wrapping
[04:17] <sabdfl> we can say its a fixed number of vertical cells
[04:17] <Kamion> but it isn't
[04:17] <sabdfl> ok
[04:17] <Kamion> we can't figure this out in espresso
[04:17] <Kamion> we need the widget to do it based on its preferred size
[04:17] <Kamion> or available size, something like that
[04:17] <sabdfl> ok, np, keep going with select box or ddlb
[04:18] <Keybuk> and we can't figure out the height of the TreeView/Grid because the way GTK+ works with scrolling is to pack it inside a different widget that scrolls around
[04:19] <Kamion> Keybuk: could you have a look at turning the current widgets into drop-downs, and see how they look?
[04:20] <Kamion> since you said on Thursday that you wanted to help :)
[04:20] <Keybuk> this afternoon I'm going to try and get n-m up
[04:20] <Keybuk> then tomorrow I'll bug you how to get started on d-i :)
[04:20] <jamesh> Keybuk: when I talked with Owen about GtkWrapBox a few years back, the idea about how to handle size allocation sanely was to make the widget handle its own scrolling (set_scroll_adjustments(), etc)
[04:20] <Kamion> righto
[04:20] <Keybuk> I imagine I need some kind of test environment
[04:20] <Kamion> for espresso, I normally just download and boot a current live CD, rsync the source tree over from my laptop, build it on the live CD, install it, run it
[04:21] <Kamion> it's fairly easy to get going with that way, actually easier than d-i
[04:21] <Keybuk> ok
[04:25] <Mithrandir> as long as you don't need to run it through the whole process, just working in a normal system is fine
[04:40] <Kinnison> I don't have enough RAM to do the liveCD trick most of the time
[04:40] <Kinnison> have to rsync .debs
[04:50] <mdz> Kinnison: which livecd trick?
[04:50] <Kinnison>  mdz the build-deps and rsync-the-source trick kamion does
[04:51] <mdz> its build-deps are fairly modest, no?
[04:52] <Kinnison> the evo stuff weighs down
[04:52] <Kinnison> and tmpfs only ever uses half ram
[04:52] <Kinnison> so it gets a bit full
[04:52] <Kinnison> :-)
[04:54] <Kamion> mdz: the live CD doesn't have build-essential preinstalled so all that has to go into RAM
[04:54] <mdz> Kamion: I forgot it had C bits in it
[05:07] <mvo> why does busybox-initramfs conflicts with every other busybox in the archive?
[05:10] <mdz> fabbione: why do we even build powermanagement-interface on sparc?
[05:11] <mdz> fabbione: ubuntu-meta automatically excludes packages which do not exist on the target arch
[05:11] <Robot101> ghrgh
[05:11] <fabbione> mdz: because LP doesn't understand Not-For-US or PAS and it gets automaticlly builded. The problem is that we don't support Task: per arch and one of the pkgs in the game is arch: all = you lose
[05:12] <mdz> fabbione: LP understands Architecture:
[05:12] <fabbione> mdz: it doesn't understand PAS or NFU
[05:12] <fabbione> so it gets to build gnome-power-manager
[05:12] <fabbione> and powermanagement-interface
[05:12] <fabbione> and it messes up
[05:12] <mdz> fabbione: I don't see why we need those in this case; we should be able to use  Architecture:
[05:13] <fabbione> mdz: it doens't work.. infinity and Ihave been there already.. once in breezy in which i had to ask elmo to rm -rf sparc binaries and now to solve it the LP way..
[05:13] <mdz> fabbione: can you explain to me why?  I don't understand
[05:14] <fabbione> mdz: because we don't support Task per architecture and one of the packages in the game is arch: all
[05:14] <fabbione> mdz: so it ends up to be Task: ubuntu-desktop and pulls in stuff that is not installable on sparc
[05:14] <fabbione> mdz: so we need to stub that package.. more or less what's done on ppc
[05:14] <mdz> which package?
[05:14] <fabbione> powermanagement-interface
[05:14] <fabbione> at least it's one of them.. in breezy there were two
[05:15] <mdz> pmi has an implementation for ppc which uses pbbuttonsd, no?
[05:15] <mjg59> Yes
[05:15] <fabbione> mdz: i said similar to ppc
[05:15] <mdz> powermanagement-interface is not arch: all
[05:15] <mjg59> mdz: Well, which replaces pbbuttonsd
[05:15] <fabbione> mdz: on x86/x86_64/ia64 Depends: acpi-$something
[05:15] <fabbione> mdz: that does not exists on sparc
[05:15] <fabbione> mdz: since that package gets builded, and can't be excluded, we need to stub it
[05:15] <mdz> fabbione: yes, but we don't  try to install _i386.deb on sparc either :-)
[05:16] <fabbione> mdz: i did ask infinity NOT to build it
[05:16] <fabbione> and he said that it cannot be avoided
[05:16] <mdz> Architecture: i386 powerpc amd64 etc. should stop it from being built on sparc
[05:16] <fabbione> so it lands in the Task: stuff
[05:16] <fabbione> mdz: apparently it doesn't work that way.. i was told and i have to trust..
[05:17] <fabbione> the same situation in breezy had to be fixed "manually" the hard way
[05:17] <Kinnison> mdz: I think I got told off for obeying the Architecture files
[05:17] <Kinnison> erm s/files/lines/
[05:17] <Kinnison> It might need a P-a-s entry
[05:17] <mdz> Kinnison: the build will fail anyway if Architecture: doesn't match
[05:17] <mdz> no?
[05:17] <fabbione> and P-a-s seems to be half broken
[05:17] <mdz> doesn't sbuild check that?
[05:17] <mdz> this certainly used to be the case pre-soyuz
[05:17] <Kinnison> mdz: I thought sbuild ignored it too
[05:17] <xhaker> i just installed dapper on a friends laptop, X failed to start "No Screen". i figured it out: the laptop has 2 graphic cards, the s3 was being detected, but the ati is the active one. it was wierd though, my laptop as 2 gfx card too, one is an intel the other ati too
[05:18] <Kinnison> mdz: It's possible sbuild checks it
[05:18] <mdz> fabbione: in breezy, a package with Architecture: i386 would not build on sparc.  it would be attempted but would fail
[05:18] <xhaker> im going to see if similar reports exist on malone
[05:18] <mdz> it resulted in build logs which looked like this:
[05:18] <mdz> Fetched 10.5kB in 0s (0B/s)
[05:18] <mdz> Download complete and in download only mode
[05:18] <mdz> : powerpc not in arch list: i386 amd64 -- skipping
[05:19] <fabbione> mdz: and perhaps it still works in LP.. i don't know.. i am not an LP buildd admin and i was told that it is partially broken.. hence i report what i am told..
[05:33] <fabbione> Kinnison: why do you depend directly on acpi-support for g-p-m ?
[05:33] <fabbione> Kinnison: powermanagement-interface will do that for you
[05:33] <fabbione> and you already depend on it
[05:36] <Kinnison> fabbione: I imagine because I was thinking about explicit deps when I did the acpi whitelist support
[05:37] <Kinnison> fabbione: I'll fix that in my next upload
[05:37] <fabbione> Kinnison: thanks, that would be awesome
[05:38] <fabbione> Kinnison: if you want to keep the direct depends, can you please do so that sparc and hppa will have no acpi-support Depends ?
[05:38] <Kinnison> fabbione: argh, of course
[05:38] <fabbione> Kinnison: otherwise just let powermanagement-interface do it for you
[05:38] <Kinnison> fabbione: Sorry
[05:39] <fabbione> Kinnison: no problem.. i was just puzzled when today i couldn't install desktop :)
[05:39] <fabbione> Kinnison: i was aware only of pmi with that problem
[05:41] <Kinnison> lots of stuff going into g-p-m soon
[05:41] <fabbione> Kinnison: thanks a lot
[05:41] <na7e> do you guys know a way to associate a task with a package?  is the only way in the control file?
[05:42] <fabbione> na7e: that usually involves to sacrifice a few goats to the ftp-masters together with a jar of gold and one of whisky
[05:42] <na7e> fabbione, now where did i put that whiskey
[05:42] <Kinnison> fabbione: can you file a bug on g-p-m so I remember
[05:42] <fabbione> Kinnison: sure...
[05:43] <Kinnison> fabbione: I'm currently up to my ears in gtkmm reminding myself of how this patch for gparted works
[05:43] <fabbione> Kinnison: do you want me to just kill the Depends for you?
[05:43] <fabbione> Kinnison: and you take over after?
[05:43] <Kinnison> fabbione: No 'cos I have a non-uploaded version here
[05:43] <fabbione> ok
[05:43] <Kinnison> somewhere
[05:43] <fabbione> sure
[05:43] <Kinnison> just file the bug so I have something to close
[05:43] <Kinnison> it'll make me feel more important
[05:44] <sivang> heh
[05:45] <fabbione> Kinnison: i can give you a few X bugs if you want..
[05:45] <fabbione> Kinnison: #35735
[05:47] <Kinnison> fabbione: I've got enough bugs without X too
[05:47] <maswan> If I store 10000 dapper isos in a tape library, do I win something? ;)
[05:47] <seb128> fabbione: looks like a normal daily desktop count :p
[05:47] <Kinnison> still s'less than earlier
[05:48] <fabbione> seb128: yeah right.. but desktop bugs < X bugs
[05:48] <Amaranth> yay, x fixes :)
[05:48] <fabbione> Kinnison: 76 emails.. or 76 bugs?
[05:48] <seb128> fabbione: I would not bet on that
[05:48] <fabbione> my bug inbox was about 650 this morning
[05:48] <Kinnison> fabbione: Dunno 'til I go read, I'd guess somewhere between the two
[05:48] <fabbione> seb128: do you want to swap for a while?
[05:49] <seb128> fabbione: that would be a loose loose, you don't know GNOME and I don't know xorg
[05:50] <fabbione> seb128: i think it's a win to win instead.. we both get to learn something new :)
[05:50] <Amaranth> but it'd be funny ;)
[05:50] <seb128> fabbione: but https://launchpad.net/people/desktop-bugs/+subscribedbugs == 2566 bugs atm
[05:51] <seb128> fabbione: I don't discuss xorg gets load of bugs too, but don't denigrate desktop load :p
[05:51] <Gwynn> but if you both learn something new that the other knows allready wouldn that spell r e d u n d a n c y ?
[05:51] <fabbione> seb128: Linux was right.. gnome sucks :P
[05:51] <seb128> :)
[05:51] <fabbione> Linus even ;)
[05:52] <fabbione> ok enough troll for seb128 today :)
[05:52] <fabbione> seb128: we have 1:10 ratio... 
[05:53] <seb128> fabbione: yeah, let's back to work ;)
[05:53] <bddebian> heh
[05:56] <fabbione> seb128: :)))
[05:58] <HiddenWolf> fabbione: bug sabdfl to write something like gnome's bugzilla weekly bug summary :)
[06:00] <fabbione> HiddenWolf: hmm i would prefer graphs to show peaks of bugs and when/why they get squashed
[06:00] <G0SUB> pitti: ping
[06:01] <HiddenWolf> fabbione: right you are
[06:01] <fabbione> they can give a really good overview of what happens when/why and how to optimize it for the next release
[06:01] <fabbione> i did something like that for Debian BTS once... but i lost interest in getting it in place once i started to fight with the admins
[06:21] <pitti> G0SUB: pong
[06:21] <G0SUB> pitti: there is a language Hindi for which I could get only the translated file tree ... can you make the XPI yourself please ?
[06:22] <pitti> G0SUB: hm, not sure
[06:22] <G0SUB> hmm
[06:22] <pitti> G0SUB: it requires some metadata
[06:22] <G0SUB> everything that's required is there
[06:22] <G0SUB> just that it's not zipped up 
[06:22] <pitti> oh, if it has the manifest and install.rdf, I can certainly zip it myself :)
[06:22] <G0SUB> the doc is here http://www.mozilla.org/projects/l10n/mlp_packaging.html
[06:25] <G0SUB> pitti: hmm, it seems they are not there ... I will get back to you with the XPI ... you won't need to handle that pain
[06:40] <pitti> Keybuk: is there a way to explicitly state in a preinst that a package drops a conffile? so that it doesn't count as owned by that package any more?
[06:43] <Keybuk> remove it, should work
[06:44] <pitti> Keybuk: hm, it's actually migrated from postgresql-common to postgresql-client-common, so I can't fully remove it
[06:44] <pitti> but during the upgrade it's actually removed
[06:44] <pitti> debian bug 357910
[06:44] <Ubugtu> Debian bug 357910 in postgresql-common "Subject: Unable to upgrade: conflict between postgresql-common and" [Important,Open]  http://bugs.debian.org/357910
[06:45] <pitti> Keybuk: i. e. p-client-common's preinst either rm or mv it, and p-client-common's postinst moves it back (with the standard conffile moving recipe)
[06:46] <Keybuk> and this doesn't work?
[06:46] <pitti> Keybuk: no, see the bug
[06:47] <pitti> Keybuk: dpkg complains even although the file isn't there any more (just in dpkg's database, of course, but not on disk)
[06:47] <pitti> Keybuk: my current solution is to Replace: all versions of postgresql-common
[06:47] <pitti> Keybuk: before it was Replaces: p-common (<< 45)
[06:49] <pitti> Keybuk: 357909 has a more complete log, btw
[06:50] <Keybuk> don't you mean <= 45 ?
[06:50] <pitti> Keybuk: 45 was the first version which introduced the package split
[06:51] <pitti> Keybuk: but the versioned Replaces is wrong anyway, I guess, since people might upgrade from 44 to 49 or so
[06:51] <pitti> Keybuk: so if p-common is already updated before p-client-common, it doesn't apply any more
[06:51] <Keybuk> oh right
[06:51] <Keybuk> and iwj's conffile patch breaks it?
[06:51] <pitti> the versioned conflict shoudl be fine
[06:52] <Keybuk> versioned replaces
[06:52] <pitti> Keybuk: no idea which patch is to blame; I just verified it on dapper and sid
[06:52] <Keybuk> dpkg largely ignores versioned conflicts
[06:52] <Keybuk> does it work in sarge?
[06:52] <Diziet> Hello.  My ears are burning.
[06:52] <pitti> Keybuk: I can try that; it's a bit hard (production system), but should work
[06:52] <Keybuk> just grab the dpkg from sarge and install it
[06:52] <pitti> Hi Diziet 
[06:53] <Keybuk> or from breezy, actually
[06:53] <Keybuk> that's more up to date
[06:53] <pitti> Keybuk: ah, good idea
[06:54] <Diziet> What's all this about a `standard conffile moving recipe' ?  Is this some other hideous workaround for a dpkg bug ?
[06:54] <Diziet> It's nearly always a mistake to mess with a conffile in a maintainer script.
[06:54] <pitti> no, it's a hideous workaround for a hideous situation
[06:54] <Diziet> What hideous situation ?  Conffiles should move from package to package just fine (assuming an appropriate Replaces, just like you need for any file movement).
[06:55] <pitti> Diziet: moving a conffile to anouther package is not really something dpkg supports, so preinst/postinst have to make sure that it'll happen without dpkg conffile questions
[06:55] <Keybuk> Diziet: that broke with the "obsolete" patch, afaict
[06:55] <Diziet> Did it ?  Not in my tests.
[06:55] <Diziet> If it broke we should fix it dammit.
[06:55] <Keybuk> I've seen several bug reports with a conffile still being claimed by a later version of a package and causing an overwrite error with the package that Replaces it
[06:55] <Diziet> If someone can produce a test case that doesn't involve maintscript fiddling then I'll fix it.
[06:55] <pitti> Keybuk: ok, so I get the same breakage with breezy's dpkg
[06:56] <Keybuk> pitti: then I don't understand your bug
[06:56] <Keybuk> if package A has not got the conffile, and package B has it
[06:56] <Keybuk> then you won't get that overwrite error
[06:56] <pitti> well, I understand *part* of the bug
[06:56] <Keybuk> so either you're lying, and both A and B have the file, or something else is going on
[06:56] <Keybuk> dpkg: error processing /var/cache/apt/archives/postgresql-client-common_46_all.deb (--unpack):
[06:56] <Keybuk>  trying to overwrite `/etc/postgresql-common/user_clusters', which is also in package postgresql-common
[06:56] <Keybuk> that means that postgresql-common has that conffile
[06:57] <Keybuk> and postgresql-client-common *does not* Replaces it
[06:57] <pitti> Keybuk: version 44 of p-common has, but not 45+
[06:57] <Diziet> Maybe I should volunteer to fix all of these kinds of bugs.
[06:57] <Keybuk> ok, prove it; give me the Conffiles: bit from status :)
[06:57] <Diziet> pitti: I think what Keybuk means is that dpkg thinks the package still has it even though the new .deb doesn't.
[06:57] <pitti> right
[06:58] <Diziet> Would you like me to fix this problem for you ?  I can do it tomorrow.  (No time left today - I have to go in 15m0
[06:58] <pitti> so, my /v/l/dpkg/status still shows p-common Version 44
[06:58] <Keybuk> Diziet: that shouldn't matter, postgresql-client-common Replaces it
[06:58] <pitti> which of course has the file
[06:58] <pitti> however, the file is not in the system any more (it was rm'ed)
[06:58] <Diziet> Why was it rm'd ?
[06:58] <pitti> Diziet: in p-client-common's preinst
[06:59] <Diziet> Why, not what by.
[06:59] <Diziet> I'm quite serious.  If you can tell me how to reproduce this bug I can fix it.
[06:59] <pitti> Diziet: I'm still trying to understand whether it's entirely my fault, or partly mine and partly dpkg's
[07:00] <pitti> so, let me explain step by step, unless I annoy you
[07:00] <Diziet> Sure, that's fine.
[07:00] <pitti> A := postgresql-common, B := postgresql-client-common
[07:00] <pitti> A 44 has the conffile, A 45 and 46 not
[07:00] <pitti> B Conflicts:/Replaces: A << 45
[07:01] <pitti> (version 45 introduced the package split, and the conffile needs to move from A to B
[07:01] <pitti> now, A 44 is installed, and I dist-upgrade to 46
[07:01] <Diziet> You mean B 46 C/R A << 45 ?
[07:01] <pitti> right
[07:02] <pitti> so, this part of my bug is a bit clear: if A gets upgraded first, then the Replaces << 45 doesn't apply any more
[07:02] <pitti> so what happens is:
[07:02] <Diziet> Right.  And the conffile gets put into the weirdo orphan state.
[07:02] <Diziet> That's what my patch was for.
[07:02] <pitti> first, B's preinst removes the conffile, since it's unchanged
[07:02] <Diziet> (I'm assuming your maintscripts don't do anything.)
[07:02] <Diziet> Why?????
[07:03] <Diziet> Why would you mess with a conffile in the preinst ?
[07:03] <pitti> Diziet: it's part of the recipe
[07:03] <Diziet> Where did you get this recipe ?
[07:03] <pitti> Diziet: for the case that it has been modified
[07:03] <pitti> Diziet: from www.dpkg.org
[07:03] <pitti> Diziet: anyway, I think it doesn't really matter here
[07:03] <desrt> hm.  the new dapper livecd format is much nicer
[07:03] <pitti> so then dpkg tries to unpack A 46, but that fails due to the conflict
[07:04] <pitti> although version 46 doesn't ship that conffile any more
[07:04] <Diziet> I think dpkg is right here and your maintscript is wrong.
[07:04] <Diziet> BICBW.
[07:04] <Diziet> www.dpkg.org is down so I can't even add a note to the page saying `iwj hates this'.
[07:04] <pitti> so, I see the combination of two different bugs/issues:
[07:04] <Diziet> Have you tried it without any `recipies' in the maintscripts ?
[07:05] <pitti> - dpkg still considers the conffile owned by A, even though the deb doesn't ship it; I know that there are reasons for that, though
[07:05] <Diziet> A is removed but not purged at this point.
[07:05] <pitti>  - my Replaces: is wrong, since it's versioned
[07:05] <pitti> or, rather, it doesn't work here
[07:05] <pitti> an unversioned replaces: works fine
[07:05] <Diziet> Oh, I /see/.
[07:06] <pitti> so, dpkg doesn't take into account that B replaces A << 45 if I upgrade A from 44 to 46
[07:06] <pitti> I mean, I'm not against adding an unversioned Replaces:
[07:06] <pitti> but it feels a bit ugly to me
[07:06] <Diziet> No, you probably shouldn't do that.
[07:07] <Diziet> I see the problem now.
[07:07] <Diziet> I think this is indeed a dpkg bug.
[07:07] <Burgwork> sabdfl, ping
[07:08] <Diziet> I think the right answer is for orphan conffiles never to cause conflicts.
[07:08] <lifeless> the sab is in deep discussion here
[07:08] <Diziet> But I'll sleep on it and play with it tomorrow.
[07:08] <Diziet> All of these .debs are in the Ubuntu archive ?  (Or were ?)
[07:08] <pitti> Diziet: great; I can provide you with some minimal test debs if you need
[07:09] <pitti> Diziet: Debian currently
[07:09] <Diziet> Debian.  OK, NP.
[07:09] <pitti> Diziet: they are tiny, I can send them to you if you want
[07:09] <Diziet> Yes, please.
[07:09] <pitti> Diziet: I can also strip them down to remove all the maintscripts stuff
[07:09] <Diziet> No, no, I can do that.
[07:09] <pitti> Diziet: ah, to answer this question:
[07:09] <Diziet> But send me the `source' if it's not just dpkg -x :-).
[07:09] <pitti> Diziet: if the conffile is modified, then we need the magic to avoid a dpkg conffile question
[07:10] <Diziet> Yes, dpkg is supposed to do that.  That's what the orphan conffile thing is for.
[07:10] <Diziet> (I can't remember whether that patch made it into breezy.  I suspect not.)
[07:11] <pitti_> yay my network, sorry
 Diziet: otherwise, installing B on top of an orphaned modified conffile from A would trigger a question
[07:12] <Diziet> Is the conffile shipped in B different from the one in A ?
[07:12] <Diziet> Err.  To me `modified conffile' means one locally modified by the admin.
[07:12] <Diziet> NB that removing it with `rm' (like in your preinst) counts as modifying it.
[07:13] <pitti> Diziet: the default file didn't change
[07:13] <pitti> Diziet: right, admin modified
[07:14] <pitti> Diziet: but the recipe works just equally well if the file changed between A and B
[07:14] <Diziet> Right.  Then the orphan conffile stuff is supposed to work.
[07:14] <Diziet> As you can tell, I don't believe in this `recipe'.
[07:15] <lifeless> if you need him urgently I can ping him, but if it can wait I suggest email
[07:15] <lifeless> ing 
[07:15] <Diziet> Anyway, I have to go or I'll be late for my dinner.
[07:15] <Diziet> Mail me those files and if you say anything else here I'll see it tomorrow morning.  I'll look into it and write you up a diagnosis :-).
[07:16] <ogra> seb128, ping
[07:16] <pitti> Diziet: thanks a million
[07:16] <pitti> and enjoy your dinner
[07:17] <Diziet> pitti: NP, I enjoy this kind of thing really :-).  Willdo.  TTFN
[07:18] <seb128> ogra: pong but I've to go for ~1.5 hour soon
[07:18] <ogra> seb128, just a short question
[07:19] <ogra> gdm depends on ubuntu-artwork, could you make that ubuntu-artwork | edubuntu-artwork ?
[07:19] <seb128> sure
[07:19] <ogra> i want to jget rid of the ubuntu-artwork package from the edubuntu Cd
[07:19] <ogra> thanks :)
[07:19] <seb128> np
[07:19] <ogra> go !
[07:19] <ogra> :)
[07:19] <lamont> Keybuk: why on earth would anyone install recommends by default?  if the package needs it for operation, then it's a depends, not a recommends... :0)
[07:24] <lamont> seb128: stupid question for you....
[07:24] <lamont> my screen lock button doesn't work on dapper.
[07:24] <ogra> lamont, do you have gnome-screensaver installed ? it works here 
[07:24] <seb128> lamont: does the menu item work? or the session dialog button?
[07:25] <lamont> mind you, historically, I had to pull up the screensaver preferences so that it would complain that the lock daemon was "not running and did I want to start it" before I could lock on breezy... so I think it might be session defaults
[07:25] <lamont> seb128: either one
[07:25] <lamont> applet button on the panel, and pull down menu item
[07:25] <seb128> k, seems to be the screensaver not running
[07:25] <lamont> ii  gnome-screensa 2.14.0-0ubuntu a screen saver and locker
[07:25] <lamont> seb128: right
[07:25] <seb128> deal with ogra about it :)
[07:25] <seb128> I've to run for now
[07:25] <lamont> and the new shiny dapper screensaver doesn't notice that it's not running...
[07:25] <seb128> bbl
[07:26] <lamont> seb128: np. thanks
[07:26] <lamont> ogra: so what do I change where to cause gnome-screensaver to actually launch?
[07:26] <lamont> (and no, "rm -rf .gnome*" is not an option.
[07:27] <ogra> normally its started by default from the session ... 
[07:27] <ogra> probably the gconf key isnt set ... let me find it
[07:30] <lamont> ogra: it hasn't normally been started for my session since somewhere before breezy release... :-(
[07:31] <ogra> lamont, look with gconf-editor if /apps/gnome_settings_daemon/screensaver/start_screensaver is true
[07:32] <lamont> wee... X-over-ssh.
[07:32] <ogra> gconftool-2 --get /apps/gnome_settings_daemon/screensaver/start_screensaver
[07:33] <ogra> :)
[07:33] <lamont> false.
[07:33] <ogra> ah
[07:33] <lamont> I guess I want to set it to true, eh?
[07:33] <ogra> thats it
[07:34] <ogra> yup
[07:34] <lamont> --set ... = true?
[07:34] <ogra> it will default to gnome-screensaver if its installed 
[07:34] <ogra> gconftool-2 --set /apps/gnome_settings_daemon/screensaver/start_screensaver --type bool true
[07:35] <lamont> thanks
[07:43] <tenco> is it possible to run beagled without the --debug option?
[08:02] <_ion> Good morning.
[08:04] <Lure> _ion: hi
[08:04] <_ion> Hi
[08:05] <Lure> _ion: have your read mbiebl (debian maintainer) response to NM annoncement on ubuntu-devel?
[08:06] <neuralis> BenC: ping
[08:06] <xhaker> does sources.list accept smb shares ?
[08:06] <_ion> lure: Yep, i agree with him.
[08:07] <neuralis> xhaker: not unless they're mounted. that's a question for #ubuntu, though.
[08:07] <_ion> lure: I should have noticed the versioning stupidity in the libnl package i downloaded. :-\
[08:08] <Lure> _ion: are you already working on that?
[08:08] <Lure> _ion: I have checked mentioned svn, but I do not see that they rename applets :-(
[08:10] <_ion> lure: I hadn't had time to work on that yet, but i will. I also guess pygi's going to help with that as soon as he gets online.
[08:11] <Lure> _ion: btw, Tonio_ is also working on cleanup of packages - maybe check with him too
[08:11] <_ion> Right, i'll /msg him.
[08:11] <hunger> _ion: I think NM has trouble with /etc/network/interfaces.
[08:12] <_ion> #define trouble \
[08:12] <hunger> _ion: From what I understand it expects "inet dhcp" on a different line than "iface whatever".
[08:13] <hunger> _ion: Unfortunately that is not possible as ifup/ifdown do not understand that syntax then.
[08:13] <_ion> Hmm. I thought i tested the patch, but perhaps i was careless.
[08:13] <_ion> I'll check it.
[08:13] <hunger> _ion: If you have no auto whatever but a "iface whatever inet dhcp" then NM gets a dbus error...
[08:16] <hunger> _ion: At least that seems to be the problem on my system. I removed the iface lines for now (no more ifup/ifdown), and NM works fine now.
[08:16] <_ion> Ok. Thanks for the report.
[08:19] <doko> dholbach, seb128, mvo: who's knowing the atk modules a bit?
[08:20] <dholbach> doko: I doubt we have an expert for them :)
[08:20] <dholbach> doko: what are you looking for?
[08:21] <doko> dholbach: #35747
[08:21] <dholbach> bug 35747
[08:21] <Ubugtu> Malone bug 35747 in openoffice.org "OOo crashes with gnome accessability enabled" [Major,Unconfirmed]  http://launchpad.net/bugs/35747
[08:23] <mvo> doko: it makes synaptic as well
[08:23] <mvo> crash that is
[08:24] <dholbach> same/similar backtrace?
[08:25] <dholbach> mvo: ^
[08:28] <mvo> dholbach: I look into it in a bit
[08:28] <dholbach> mvo: thanks
[08:32] <dholbach> doko: can you give it another try with libatk1.0-dbg libglib2.0-0-dbg libgtk2.0-0-dbg installed? is this most recent dapper? 
[08:32] <dholbach> doko: libgail-dbg too
[08:47] <Mez> wtf?
[08:47] <Mez> dpkg is missing on my system ?
[08:47] <LaserJock> that's not good
[08:48] <Mez> sudo: dkpg: command not found
[08:48] <Mez> oh, it's just not in my path
[08:48] <Mez> it's there if i sudo -i
[08:51] <xhaker> Mez: pre flight 3 install?
[08:51] <Mez> xhaker, I've been using dapper since it was opened for uploads
[08:51] <dholbach> Mez: dkpg -> dpkg
[08:52] <Mez> dholbach, o_O how could i not notice that ;)
[08:52] <xhaker> Mez: libpam-something broke path for some people, if the error is not the typo it may be that
[08:52] <Mez> dholbach, lol - nah - i've just woken up - tis probably why
[08:55] <Treenaks> dholbach: alias dkpg=dpkg
[08:55] <Treenaks> :P
[08:55] <dholbach> Treenaks: I don't need it, thanks ;)
[08:56] <Treenaks> Mez then
[08:57] <LaserJock> or maybe dkpg=`echo "wake up!!!"`
[08:58] <Treenaks> LaserJock: apt-get install sl
[08:59] <ogra> LaserJock, add a bunch of \a to the echo :)
[08:59] <_mvo_> is it normal that rsvg-convert from bootchart takes >800mb of my memory? and runs for ages?
[08:59] <Treenaks> ogra: sl rocks, if you mistype 'ls' a lot
[09:00] <ogra> heh
[09:00] <LaserJock> Treenaks: interesting. and sometimes I wonder why Universe has so many packages ;-)
[09:00] <Treenaks> LaserJock: it's the Debian thing :)
[09:04] <doko> dholbach: what further information do you expect from the trace back? It's some recursion, which apparently eats up the stack
[09:05] <dholbach> doko: it'd be nice to have the arguments of the functions
[09:05] <dholbach> doko: that was on i386, right?
[09:06] <doko> dholbach: yes
[09:06] <dholbach> brb
[09:09] <zyga> did dholbach leave already?
[09:09] <LaserJock> zyga: he said he would brb
[09:09] <Amaranth> right before you joined
[09:09] <zyga> oh, great :-)
[09:10] <zyga> I keep missing the developers I know ever since I got my new job
[09:11] <LaserJock> you'll just have to get to know some more developers so you can spread out the TZs ;-)
[09:12] <zyga> hehe true :)
[09:12] <zyga> dholbach: hello
[09:12] <zyga> dholbach: did you get my message yesterday?
[09:12] <dholbach> yep
[09:13] <dholbach> zyga: could you follow up on the MOTU UVF exception bug for it?
[09:13] <zyga> dholbach: yes but before I do I'd like to ask you about something
[09:13] <zyga> I wanted to fix i18n bug that was basically missing ngettext but I ran into a problem I don't know how to solve
[09:14] <dholbach> zyga: you should file a bug on ontv, the upstream developer will follow up, he reads those bugs too
[09:14] <zyga> it basically reduces to the fact that I need a more generic ngettext that accepts a vector of msgid's and a vector of numbers to produce the correct result
[09:14] <dholbach> zyga: if not, you can subscribe him as well (johan@svedberg.com)
[09:14] <zyga> I already have an email for him with a diff and the description of my changes :-)
[09:15] <zyga> I didn't know he reads ubuntu bug reports
[09:15] <dholbach> yeah, he's great to work with
[09:15] <dholbach> doko: it works for me :/
[09:15] <dholbach> doko: nothing funny at all :/
[09:16] <zyga> dholbach: what should I do with this ngettext problem? there is really no way to implement this correctly using current ngettext+gettext
[09:17] <dholbach> zyga: I suppose you better talk to him... as he knows the code better than I do
[09:18] <zyga> dholbach: does he come to irc, ever?
[09:18] <doko> dholbach: even if you press some of the buttons in the help?
[09:18] <dholbach> doko: yes, nothing funny at all
[09:18] <doko> did you turn the speech on?
[09:18] <dholbach> zyga: I think I met him on irc, but I can't remember his ircnick
[09:18] <zyga> okay
[09:18] <zyga> I'll mail him
[09:18] <dholbach> cool
[09:19] <doko> strange, because a user reported that as well ...
[09:24] <zyga> dholbach: mail away, I'll get my patch up and running and look at UVF exception procedure
[09:35] <Robot101> 20:34 <rlaager> Well, if I had a vmware-packager package that would take a vmware tarball and make a vmware-VERSION.deb out of it, do you think I could get said vmware-packager into Debian/Ubuntu?
[09:44] <Burgwork> sabdfl, unping, dapper press release is what I was pinging you about
[09:45] <dotwaffle> tsk, annoying the dictator with trivialities such as that, tsk!
[09:51] <Burgwork> dotwaffle, actually I was offering to help write bits, etc.
[09:52] <dotwaffle> ah right, excuse me =)
[09:58] <Pygi> _ion: you there?
[09:59] <_ion> pygi: Hi! Nice to see you.
[10:00] <_ion> pygi: Did you see Michael Biebl's reply to the announcement at the u-devel list?
[10:00] <Pygi> _ion: the one about debian, changin' names and such?
[10:00] <_ion> pygi: Yep.
[10:00] <Pygi> _ion: yup, I did ...
[10:01] <Pygi> perhaps we should rebuild & rename packages
[10:01] <sabdfl> gotcha, thanks Burgwork
[10:01] <_ion> First we should fix the versioning stupidity in libnl (i wonder why i didn't notice it immediately...), and i also agree with renaming the packages to be similar.
[10:02] <_ion> pygi: I sent you an email, btw.
[10:02] <Pygi> _ion: k, will look into the mail now
[10:03] <Pygi> _ion: you sure you sent to the right mail?
[10:03] <dholbach> night guys
[10:03] <Pygi> night dholbach
[10:03] <Pygi> dholbach: ah, yes ... I saw the patch
[10:03] <_ion> To: Mario ani <mario.danic@gmail.com>
[10:03] <dholbach> Pygi: hm?
[10:04] <Pygi> dholbach: you said night ... I said night as well ^_^
[10:04] <Pygi> _ion: right,  it's that patch, isn't it?
[10:04] <_ion> Yep.
[10:04] <dholbach> "patch"?
[10:05] <Pygi> dholbach: for n-m packages ^_^
[10:05] <seb128> Pygi: I think <Pygi> dholbach: ah, yes ... I saw the patch was not for dholbach
[10:05] <Kamion> BenC: FYI, you need to add nic-firmware to the various package-list files as well as adding nic-firmware files under debian/d-i/$ARCH/firmware/
[10:05] <mjg59> BenC: Also, sky2 still seems to be missing from the nic modules udeb
[10:05] <Kamion> BenC: (the nic-firmware binaries didn't actually get built for hppa/ia64/sparc)
[10:05] <Pygi> seb128: you'r right  ^_^ wrong typing
[10:05] <Kamion> yeah, that bug is still outstanding, keep getting reports of it ...
[10:06] <_ion> pygi: Also the /etc/network/interfaces parsing seems to be somewhat buggy. I'll look at it.
[10:06] <Pygi> _ion: k, I'll try to look at that background scanning in -ng
[10:06] <BenC> Kamion: ok
[10:08] <_ion> pygi: Do you agree with the patch i sent? I think cdbs is a superior build system, but if reverting back to the 0.5.1 build system makes it more probable that the package is accepted, we should do that.
[10:08] <Pygi> _ion: yup, agreed
[10:09] <Kamion> will somebody do l-r-m and linux-meta? (note, in general you can upload l-r-m without waiting for the kernel to build, since it'll dep-wait; faster that way)
[10:09] <Kamion> (linux-meta doesn't dep-wait at present, although infinity suggested hacking it about a bit to do so ...)
[10:10] <_ion> pygi: Oh, the repository suddenly seems not to be signed anymore. :-(
[10:11] <Pygi> _ion: yes, I do know that
[10:11] <Pygi> _ion: it's because it was causing a lot of trouble ... we'll move to falcon someday perhaps ^_^ (Tonio_ is, that is ;) )
[10:12] <Pygi> _ion: we will need new patched l-r-m packages as well, won't we?
[10:13] <_ion> pygi: The new kernel doesn't seem to be out just yet.
[10:14] <Pygi> _ion: yup, I know ...
[10:16] <BenC> mjg59, Kamion: I think I have nic-firmware fixed, and sky2 added to shared/nic-modules
[10:18] <Kamion> _ion: it's in the accepted queue, will be visible in a little over an hour; I didn't quite make it before the current publisher run
[10:20] <_ion> Ok.
[10:20] <Kamion> slomo_: any progress on that GPL exception for gtkpod-aac?
[10:20] <mjg59> BenC: Rock, thanks
[10:21] <slomo_> Kamion: nope... got no answer from the author yet... on the other side gtkpod-aac only links to libmp4 which shouldn't contain patented stuff as it's only for reading and writing the mp4 container format
[10:23] <ivoks> tollef?
[10:25] <tepsipakki> slomo, kamion: what's the issue with gtkpod-aac? (i'm the packager)
[10:25] <Kamion> tepsipakki: it's GPL, but as I understand it it links to code that can't be distributed under the terms of the GPL
[10:26] <Kamion> note the GPL's admonition that if you cannot abide by a patent licence while distributing under the terms of the GPL, then you may not distribute it at all
[10:26] <Kamion> if there is no patent issue with stuff that gtkpod-aac links to, then that's fine, but then why is it in multiverse?
[10:26] <tepsipakki> Kamion: d'oh
[10:26] <Kamion> I assumed that if it was in multiverse, then there was a reason for it to be there
[10:27] <slomo_> Kamion: libmp4 is in multiverse because it's source package (faad2) is in mutliverse
[10:27] <Kamion> oh, but libmp4 itself is free?
[10:27] <slomo_> Kamion: and faad2 also builds libfaad2 which could break some patents
[10:27] <Kamion> sheesh, that's awkward
[10:27] <Kamion> really libmp4 ought to be in universe then but that causes closure issues
[10:28] <Kamion> ok, if libmp4 itself doesn't violate patents then I'll process gtkpod-aac binaries and stop bothering you+upstream :)
[10:28] <slomo_> Kamion: should be free... i see no reason why anybody could patent such stuff... but as one can patent everything today i'm not sure
[10:28] <tepsipakki> oh, by the way.. there's a new version of gtkpod, and it is only a bugfix release :)
[10:29] <slomo_> Kamion: only libfaad2 contains definitely patented code
[10:31] <lucas> what's the status of package removals ? who can process them currently ?
[10:40] <whiprush> hey _ion I am about to post a story about the n-m packages, where are users supposed to report bugs?
[10:42] <Kamion> lucas: I can. What's the problem?
[10:47] <crimsun> Kamion: please remove flashplayer-mozilla, as it contains a binary of the plugin (illegal distribution), and it is obsoleted by flashplugin-nonfree
[10:47] <_ion> whiprush: For example by email (debian % johan,kiviniemi,name) or on IRC (_ion at Freenode or Pygi at Freenode). We don't have anything more sophisticated.
[10:48] <whiprush> ok
[10:48] <whiprush> that thread ok also?
[10:48] <Seveas> (*#&^$&*#$(@*& madwifi HATEHATEHATE
[10:48] <Pygi> _ion: what I did this time? ;)
[10:48] <_ion> whiprush: Yes, i follow it.
[10:48] <whiprush> ok
[10:48] <_ion> pygi: :-)
[10:48] <Pygi> _ion: thread? what one?
[10:48] <_ion> pygi: The ubuntuforums thread.
[10:48] <Seveas> Pygi, _ion: I will no longer test NM: madwifi is giving me the creeps. Sorry.
[10:49] <Pygi> Seveas: yup, agreed ... I am looking into helping you
[10:49] <Pygi> Seveas: I'll maybe give it a shoot at porting -ng background scanning to -old
[10:49] <Seveas> and my office network (802.1x EAP/TTLS +wep) won't work with NM, already sent a mail to the NM list
[10:49] <_ion> pygi: Actually there seems to be two threads about the package now. :-)
[10:49] <Pygi> _ion: yup, I saw ;)
[10:50] <lucas> Kamion: could you please remove ruby-gnuplot and sync libgnuplot-ruby (which is in Debian, but not in Ubuntu yet) ?
[10:50] <Lure> _ion: yes, there are two - I have linked to both in wiki
[10:50] <lucas> ruby-gnuplot is uninstallable and very old, while libgnuplot-ruby is the most recent version of the same lib.
[10:50] <lucas> (ruby-gnuplot was a apt-get.org package)
[10:53] <Kamion> crimsun: done
[10:53] <crimsun> Kamion: thanks!
[10:53] <Kamion> lucas: I can't do syncs (yet); are you sure you still want me to do the removal?
[10:54] <lucas> yes, remove it anyway. If I upload libgnuplot-ruby with *build1, are chances high that it will be approved some day ? :-)
[10:54] <lucas> (it will have to go through NEW)
[10:55] <LaserJock> Kamion: yeah, I'd like to get ruby-gnuplot removed. It isn't useful in its current state
[10:55] <Kamion> lucas: NEW is a whole six items long right now
[10:56] <lucas> I'll take my chances I think
[10:56] <Kamion> lucas: ruby-gnuplot removed
[10:57] <lucas> thx
[10:57] <LaserJock> Kamion: ahh, thanks. That has been bugging me for a while ;-)
[11:00] <_ion> pygi: I'll update this file every once in a while. http://johan.kiviniemi.name/ubuntu/nm-bugs
[11:01] <Pygi> _ion: agreed
[11:02] <Pygi> _ion: I really hope we'll be able to port from -ng to -old
[11:02] <Pygi> otherwise, it's all a mess, big mess
[11:02] <_ion> Yep.
[11:17] <Seveas> sivang_, I regularly listen to muse 
[11:17] <sivang_> Seveas: heh :)
[11:17] <_ion> Muse the sequencer?
[11:18] <sivang_> nahh, muse my host which I do irc from. It doesn't let me connect anymore.
[11:18] <_ion> I tested it a long time ago, but i have a hw sequencer. :-)
[11:18] <sivang_> has anyone seen sladen ?
[11:18] <_ion> Oh.
[11:18] <sivang_> or daf
[11:18] <sivang_> ?
[11:19] <sivang_> _ion: you're sequencing on linux?
[11:20] <_ion> sivang: I prefer not to use a computer at all for making music. I have a hardware sequencer.
[11:21] <joelbryan> digital signals sucks for music, the best is vacuum tube amplifiers.
[11:21] <_ion> joelbryan: Amen to that.
[11:22] <joelbryan> there's nothing compare to analog music
[11:23] <joelbryan> vacuum tube amp + 90dB speakers = euphoria
[11:27] <_ion> Sigh, seems like i can't concentrate at all today.
[11:27] <_ion> I'll look at that interfaces bug later.
[11:28] <Gwynn> joelbryan: mount the speakers (slabs of paper you wag around) into marble slabs, resonance of the boxes = bad, remove all furniture, for starters
[11:29] <HrdwrBoB> Then blind yourself because seeing will corrupt your hearing
[11:29] <_ion> Furniture is good, it removes echo. :-)
[11:29] <HrdwrBoB> _ion: not if you have a custom built listening room
[11:29] <HrdwrBoB> .. anyway, wildly OT
[11:29] <_ion> How many of us have a custom built listening room? ;-)
[11:30] <_ion> (I wouldn't mind one for sure. )
[11:30] <Gwynn> furniture = bad, 90 degrees angles = bad, curtains = good, cover the walls with curtains
[11:31] <sladen> sivang_: I got a message from jonathan about 10minutes ago that something is "up" with muse
[11:32] <sivang_> sladen: yeah, for me as well. I see my nick sivang up which is irssi running on muse under screen, but I get connection refused port 22 when trying to connect there.
[11:32] <sivang_> sladen: I'm currently using another host to irc
[11:34] <sladen> sivang_: try that.  Thanks to the wonders of virtual machines, I've just restarted sshd
[11:36] <sivang_> sladen: virtual machine? is it a virtual machine? :)
[11:36] <sivang_> yay!
[11:36] <sivang_> works
[11:37] <sladen> sivang_: abstraction machines from the hardware is wonderful thing.
[11:37] <sladen> abstracting...
[11:37] <sivang> I see
[11:37] <sivang> sladen: what are you  using there to do that? is it somekind of blades clustering?
[11:38] <HrdwrBoB> sladen: well.. out of band access is a wonderful thing
[11:38] <joelbryan> bug #34886
[11:38] <Ubugtu> Malone bug 34886 in Ubuntu "displays too many drives" [Normal,Unconfirmed]  http://launchpad.net/bugs/34886
[11:38] <trappist> fabbione: thanks for /etc/rc.local!
[11:39] <sladen> sivang: vserver
[11:39] <joelbryan> #28447
[11:39] <sivang> sladen: VMWare / Xen ?
[11:40] <joelbryan> bug #28447
[11:40] <Ubugtu> Malone bug 28447 in sysvinit initscripts "[PATCH]  two simple errors in /etc/init.d/mountall.sh" [Normal,Fix released]  http://launchpad.net/bugs/28447
[11:40] <sladen> sivang: no.  "vserver"
[11:41] <sladen> joelbryan: are you randomly pasting numbers in the channel?
[11:42] <sivang> sladen: ah, I see now. a nice debian based project.
[11:47] <Kamion> sivang: did you ever see my comment about your breezy-updates culmus upload being incorrect?
[11:49] <sivang> Kamion: no, sorry. WHat had gone wrong there? 
[11:49] <Kamion> sivang: this is the breezy->dapper diff:
[11:49] <Kamion> -FONTDIR=$(DEB_DIR)/usr/X11R6/lib/X11/fonts/Type1
[11:49] <Kamion> +FONTDIR=$(DEB_DIR)/usr/share/X11/fonts/Type1
[11:49] <Kamion> sivang: this is the breezy->breezy-updates diff:
[11:49] <Kamion> -FONTDIR=$(DEB_DIR)/usr/X11R6/lib/X11/fonts/Type1
[11:49] <Kamion> +FONTDIR=$(DEB_DIR)/usr/share/X11/fonts/
[11:49] <Kamion> you have a missing Type1 in the change for breezy-updates
[11:50] <sivang> yes, I see that now. sorry, I wonder how I overlooked that. Would you like me to prepare updated source diff?
[11:50] <Kamion> sivang: yes please, just upload it when you're ready
[11:50] <Kamion> I'll reject -2ubuntu1
[11:50] <Kamion> you should probably upload the fix as -2ubuntu2
[11:50] <sivang> (I acutally tested both of them on repsective systems, and didn't see the fonts missing)
[11:51] <sivang> Kamion: okay, will do.
[11:52] <sivang> Kamion: have you noticed that only, or has people filed reports about their fonts not working?
[11:53] <Kamion> I noticed it when reviewing the diff for -updates
[11:54] <sivang> Kamion: okay, thanks alot, I just feared it already went in the repo.
[11:56] <Kamion> no, breezy-updates uploads are manually approved
[11:56] <Kamion> I was going through the queue
[12:01] <jvw> hrmz, someone should get Mark Shuttleworth to reply to the fake mail sent to debian-devel minutes ago, I guess...
[12:02] <azeem> I don't think that's needed