[12:02] <siretart> Seveas: right. thats the bit that needs further testing
[12:03] <Seveas> ok, so I'll be offline a bit longer to test both (I'll reboot)
[12:06] <Lure> siretart: tried new package - NM 0.6.1 still works with it ;-)
[12:07] <siretart> Lure: that would have surprised me, because the only changes where in the startup script, which nm doesn't use anyway :)
[12:07] <Keybuk> siretart: what's the wpa-conf thing supposed to *do*
[12:08] <seb128> $  nm -D --demangle /usr/lib/firefox/libxpcom_core.so | grep 'nsAString_internal()'
[12:08] <seb128> 00087522 T nsAString_internal::~nsAString_internal()
[12:08] <seb128> 000874ea T nsAString_internal::~nsAString_internal()
[12:08] <Lure> siretart: where is new TYPE= field documented?
[12:08] <seb128> does anybody knows if that's normal?
[12:08] <siretart> Keybuk: it basically chooses which of the 3 modes is going to be used
[12:08] <seb128> how can the same symbol be defined twice?
[12:08] <Keybuk> siretart: except it only switches between two of them, no?
[12:08] <siretart> seb128: perhaps a versioned symbol?
[12:09] <siretart> Keybuk: yes, mode 3 is independent from ifupdown
[12:09] <seb128> why would versionning make it defined twice?
[12:11] <siretart> Keybuk: for nm, I think you wouldn't want to touch any wpasupplicant configuration at all. mode 1 is nice if you want to hack up gnome-system-admin or something.
[12:11] <siretart> well, okay, the user could shoot himself in the foot by activating the supplicant there and trying to use nm
[12:12] <siretart> in this case you would have 2 supplicants running compating after the interface. but hey..
[12:13] <Seveas> siretart, it's very broken 
[12:13] <siretart> fuck 
[12:13] <Seveas> link mode doesn't work at all due to syntax errors, and the stop action makes lsb_logging complain about integer argument required
[12:13] <HrdwrBoB> the whole thing is utterly broken :/
[12:13] <Seveas>  * Stopping wpa_supplicant...
[12:13] <Seveas> /etc/lsb-base-logging.sh: line 96: [: done.: integer expression expected
[12:13] <Seveas> /etc/lsb-base-logging.sh: line 116: [: done.: integer expression expected
[12:13] <Seveas>    ...fail!
[12:13] <Seveas> /etc/lsb-base-logging.sh: line 122: return: done.: numeric argument required
[12:13] <Seveas> invoke-rc.d: initscript wpasupplicant, action "stop" failed.
[12:14] <siretart> argl, I didn't upload my latest deb
[12:14] <siretart> sorry
[12:14] <seb128> doko: around?
[12:14] <siretart> will upgrade my wlan here to wpa tomorrow and to extensively testing
[12:14] <doko> seb128: for you?
[12:15] <seb128> doko: no, just for a question :p
[12:15] <seb128> doko: 
[12:15] <doko> ;)
[12:15] <Seveas> siretart, could you please upload the latest so it won't break ^_^
[12:15] <seb128> $  nm -D --demangle /usr/lib/firefox/libxpcom_core.so | grep 'nsAString_internal()'
[12:15] <seb128> 00087522 T nsAString_internal::~nsAString_internal()
[12:15] <seb128> 000874ea T nsAString_internal::~nsAString_internal()
[12:15] <seb128> doko: is that something normal or buggish?
[12:15] <siretart> Seveas: on my way
[12:15] <seb128> doko: same symbol defined twice
[12:16] <doko> seb128: in the same object file?
[12:16] <seb128> doko: cf the command
[12:16] <seb128> doko: that's a nm -D --demangle on /usr/lib/firefox/libxpcom_core.so
[12:18] <doko> hmm, can't see these in the mozilla libs 
[12:20] <doko> nm -D --demangle /usr/lib/firefox/libxpcom.so|grep  nsAString_internal doesn't show anything
[12:20] <doko> which architecture is this?
[12:21] <seb128> i386
[12:21] <siretart> Seveas: ok, the syntax foo should be fixed now
[12:21] <Seveas> dennis@mirage:~$ nm -D --demangle /usr/lib/firefox/libxpcom.so | grep  ns
[12:21] <Seveas> 0000168c T NS_GetFrozenFunctions
[12:21] <seb128> doko: you made a typoe
[12:21] <Seveas> siretart, gracias
[12:21] <seb128> doko: _core.so
[12:21] <seb128> doko: wrong file
[12:21] <seb128> Seveas: same
[12:21] <Seveas> gotcha
[12:23] <Seveas> seb128, there are more doubles 
[12:24] <Seveas> Installing new version of config file /etc/init.d/wpasupplicant ...
[12:24] <seb128> Seveas: the question is if that's normal to get dups, the number is an another one :p
[12:24] <Seveas> since when is an init script a config file?
[12:25] <Seveas> (I might go offline, testing siretarts madness :))
[12:25] <siretart> Seveas: everything below /etc/ is a conffile by default in recent debhelper versions
[12:25] <seb128> Seveas: why shouldn't your init changes be respected? :)
[12:28] <doko> hmm, strange, and none is a weak symbol
[12:29] <doko> and mozilla-dev doesn't have this symbol at all
[12:32] <Seveaz> siretart, other than my network (either router or card) going bananas if I do the ifupdown dance to often too fast (which sadly is normal) it works like a charm in both link and daemon mode
[12:33] <Keybuk> hmm
[12:33] <Keybuk> wpa still working with madwifi for me
[12:34] <siretart> Seveas: right, I noticed that as well
[12:34] <siretart> ok. so didn't have that much crack. thanks for testing
[12:34] <Seveas> siretart, but this has always been the case so it's not new to this version
[12:34] <Seveas> somehow the GROUP_HANDSHAKE is failing
[12:35] <siretart> Seveas: at the testplace, I noticed that authentication took a veeery long time :/
[12:35] <seb128> doko: that's a --demangle 
[12:36] <seb128> doko: thanks to jbailey which made me try without it :p
[12:36] <Seveas> siretart, actually, it seemed to be much quicker here 
[12:36] <seb128> doko: that's a --demangle bug I mean
[12:38] <siretart> well, one independent tester says its okay. Keybuk: shall I upload to dapper to get broader testing?
[12:39] <Keybuk> siretart: I've uploaded already
[12:39] <siretart> oh. ok
[12:40] <Keybuk> will probably upset the universe users, of course
[12:40] <Keybuk> but it's "fit for main" now imo
[12:40] <siretart> :)
[12:40] <siretart> so gmane seems to have a significant lag for dapper-changes. good to know
[12:41] <Keybuk> not realluy
[12:41] <siretart> ah, there it is
[12:41] <Keybuk> I don't know when mails go to the -changes list
[12:42] <siretart> wpasupplicant in /sbin?!
[12:42] <Keybuk> sure
[12:42] <Keybuk> otherwise how you going to mount your NFS /usr over a WPA network? :p
[12:42] <siretart> why not directly in early userspace :p 
[12:42] <Keybuk> more pointedly, wpa_supplicant is started by ifup, which is started by udev
[12:43] <Keybuk> all of which are before /usr is available
[12:43] <Keybuk> so our policy is that anything related must be in /sbin
[12:43] <HrdwrBoB> anyone using NFS /usr on a wireless machine is inviting danger anyway
[12:43] <siretart> so you could nfsroot it via wpasecured network :)
[12:43] <HrdwrBoB> but still a fair point
[12:43] <Keybuk> HrdwrBoB: actually, that's a reasonably far-out use case
[12:43] <Keybuk> the real problem would be anyone with /usr on a different filesystem wouldn't get their network device brought up :p
[12:44] <siretart> Keybuk: do you think it would be reasonable for debian as well to have them in /sbin rather than /usr/sbin?
[12:45] <Keybuk> yes; your experimental packages already had that change, btw
[12:45] <Keybuk> I just double-honoured it
[12:45] <siretart> right, but it isn't uploaded yet, after all
[12:45] <Keybuk> though the Debian boot sequence is rather different from ours
[12:46] <siretart> ok
[12:46] <Keybuk> I also changed the pre-up script slightly; wpa-conf didn't make much sense to me, so I made it just start wpa_supplicant if *any* wpa-* option was given
[12:46] <Keybuk> as that kinda implies the mode
[12:46] <siretart> ok
[12:46] <Keybuk> I foresaw a hundred "you forgot to also put 'wpa-conf managed' in there too" bugs
[12:46] <Keybuk> or "I put 'wpa-conf Managed' and it didn't work" bugs
[12:47] <siretart> hm. I see
[12:47] <Keybuk> will see how it goes
[12:47] <siretart> lets see how our users react on this. 
[12:47] <Keybuk> aye
[12:47] <Keybuk> I like it anyway, it's exactly how I'd've written it
[12:47] <siretart> :)
[12:48] <Keybuk> and it does feel natural
[12:48] <Keybuk> auto eth1
[12:48] <Keybuk> iface eth1 inet dhcp
[12:48] <Keybuk>     wpa-driver madwifi
[12:48] <Keybuk>     wpa-ssid linksys
[12:48] <Keybuk>     wpa-psk blahblahblah
[12:48] <siretart> what I don't like about the current solution is that everything is horribly case sensitive and you got NO debugging aid at all
[12:49] <siretart> but well, we'll see how much that will bite future bug submitters
[12:49] <Keybuk> I would hope most people editing config files are aware that UNIX is generally case sensitive
[12:50] <Keybuk> ie. you can't put "IFACE" in that file for a start <g>
[12:52] <siretart> for my internet cafe, this is a real world example:
[12:52] <siretart> iface ath0 inet dhcp
[12:52] <siretart>   wpa-key-mgmt WPA-EAP
[12:52] <siretart>   wpa-eap PEAP
[12:52] <siretart>   wpa-identity rt
[12:52] <siretart>   wpa-password foobar
[12:53] <siretart> (plus the obvious wpa-driver and essid stuff) - especially that part with key-mgmt and eap having to be UPPERCASE has bitten me
[12:53] <Keybuk> I don't really understand wpa enough to know the difference between psk and password
[12:53] <Keybuk> what is it?
[12:54] <siretart> there are over a dozen variants of doing wpa. the easy ones are called wpa-psk. you can do that with TKIP (wpa1) or RSN(using aes, sometimes called wpa2)
[12:54] <siretart> the more interesting ones are called nowadays 'wpa-enterprise' this involves authentication agains radius servers
[12:55] <siretart> in that setup, we have a freeradius server authenticating against a mysql database
[12:55] <xhaker> siretart, the ones you got a user/password to get in?
[12:55] <siretart> xhaker: sorry?
[12:55] <Keybuk> ah, and thus the identity/password pair?
[12:56] <xhaker> wpa-enterprise.. uses certs and user/password authentication
[12:56] <xhaker> right?
[12:56] <siretart> Keybuk: right. these credentials are presented to the radius server, which itself consults something else
[12:56] <siretart> xhaker: right
[12:56] <siretart> Keybuk: more advanced setups use a PKI infrastructure and x509 certificates
[12:57] <j^> will this madness be wired to network-admin?
[12:57] <siretart> again using freeradius, which happens to hand out crypto/key material suitable for commen nas implementations around
[12:57] <xhaker> tried that at my university today.. it wouldn't allow me to login though.. the AP's are there.. but i guess they haven't that connected to something yet
[12:58] <siretart> j^: well, it shouldn't be hard, now that we have wpasupplicant with ifupdown integration in dapper :)
[12:58] <siretart> j^: but we are after feature freeze after all
[12:59] <j^> siretart it took a year to get WEP right in network-admin so i guess by that time NetworkAdmin should be all you need
[12:59] <siretart> j^: wep and this one look quite similar. when I find some time, perhaps I can hack on a patch for that
[01:08] <Robot101> hnnrgh
[01:08] <Robot101> who is responsible for CUPS in dapper?
[01:09] <Keybuk> pitti
[01:09] <Robot101> yay for a) adding manufacturer autodetection from the USB info
[01:09] <Robot101> and b) moving half the useful HP printer drivers into a pseudo-manufacturer called HP (HPLIP)
[01:09] <Robot101> meaning that it detects that I have a HP Deskjet 5740 and forwards me straight to a list where my printer does not appear
[01:10] <Robot101> *sigh*
[01:11] <Robot101> Excellent communicateur  l'humour ravageur, les confrences de Jeff Waugh sont clbres pour la quantit d'interjections que l'on peut y trouver :  Rock 'n' roll ,  Awesome! Awesome! .
[01:11] <Robot101> awesome.
[01:12] <Robot101> now it's cone into an infinite loop
[01:12] <Robot101> select(1024, [0 1 6 7 8 9] , [7] , NULL, {1, 0}) = 1 (out [7] , left {1, 0})
[01:12] <Robot101> time(NULL)                              = 1143159140
[01:14] <Seveas> Robot101, ranting won't help - filing a bug will
[01:15] <Robot101> I will look at it more closely tomorrow, but I'm too tired now to file a useful one... I just wanted to print something
[01:22] <Robot101> https://launchpad.net/distros/ubuntu/+source/cupsys/+bug/33545
[01:22] <Ubugtu> Malone bug 33545 in cupsys "cupsd hangs when HP printer is added with web interface" [Normal,Unconfirmed]  
[01:22] <Robot101> it seems to be that
[01:42] <raphink> anyone with a powerbook having problem to suspend to ram ?
[01:46] <hyperactivecrond> can we _not_ make ubotu join #debian-bots?
[01:46] <hyperactivecrond> idk it seems that we're too conforming if we make him /join #debian... ubugtu and ubuntulog dont
[02:13] <wasabi_> Is ubuntu not supposed ot mount usbfs?
[02:16] <desrt> wasabi_; see /dev/bus/usb/...
[02:18] <wasabi_> Oh it's just in a different location.
[02:18] <wasabi_> Hmm.
[02:19] <wasabi_> Hmm. Possibilty of mounting it in both places for legacy apps, perhaps?
[02:19] <wasabi_> /proc/bus/usb, etc.
[02:23] <Keybuk> legacy apps won't work because the permissions will be wrong
[02:23] <Keybuk> so no real point mounting it
[02:23] <Keybuk> better to get the apps fixed
[02:24] <wasabi_> hmm.
[02:24] <wasabi_> Sure, if all those apps are open source. ;)
[02:24] <wasabi_> no biggy to do it manually, thx. ;)
[02:25] <Gwynn> mako: are you available for a talk?
[02:27] <Keybuk> /dev/bus/usb != /proc/bus/usb
[02:27] <Keybuk> /dev/bus/usb contains device nodes created and managed by udev using events from the usb_device subsystem
[02:27] <Keybuk> /proc/bus/usb is a hacky kernel pseudo-filesystem
[02:28] <Keybuk> you can always mount it if you need it, but you'll need to chmod/chown things
[02:37] <Keybuk> siretart: ping?
[02:38] <Keybuk> _ion: ping?
[02:38] <_ion> keybuk: pong
[02:38] <Keybuk> _ion: I may be just being stupid here ... but how does nm-applet request a WPA key? :)
[02:38] <Keybuk> it says in the log that "NO valid key exists New key needed" and just sits there for a bit before giving up
[02:39] <_ion> I haven't looked at how n-m does WPA stuff _at all_. :-) I don't have a WPA network.
[02:39] <_ion> My machine is connected only via a wired network.
[02:41] <ajmitch> for me, it just came up with a dialog to enter the key
[02:41] <ajmitch> & then it just worked :)
[02:41] <Keybuk> weird
[02:41] <Keybuk> it came up with a dialog on the 11th attempt
[02:41] <Keybuk> and now always does
[02:41] <Keybuk> freeeeaky
[02:42] <Keybuk> oh
[02:42] <Keybuk> no
[02:42] <Keybuk> "took too long"
[02:42] <Keybuk> HAH
[02:42] <j^> Keybuk there is some issue with old passwords saved in the keyring
[02:44] <Keybuk> I do dislike how there's no way for gnome-keyring to have a "yeah, always let nm-applet have access"
[02:47] <Keybuk> libnotify-WARNING **: Received unknown action default
[02:47] <Keybuk> NOBODY EXPECTS THE DEFAULT ACTION!
[02:47] <j^> Keybuk absolutly there should be a keyring that is opened than logging in
[02:48] <j^> gnome bug 326925
[02:48] <Ubugtu> Gnome bug 326925 in general "need for a keyring that is unlocked than logging in" [Normal,Unconfirmed]  http://bugs.gnome.org/show_bug.cgi?id=326925
[02:49] <Keybuk> clearly I am Mr Stupid
[02:49] <Keybuk> because I cannot get NM and WPA to play nice
[02:49] <Keybuk> I put in my WPA key, it associates and disassociates for a while
[02:49] <Keybuk> then gives up
[02:50] <j^> which driver?
[02:50] <Keybuk> madwifi
[02:51] <j^> hm, latest kernel + the patch that is in the unofficial NM should work
[02:51] <j^> dont have one though
[02:51] <Keybuk> indeed
[02:51] <Keybuk> it works if I run wpa_supplicant myself
[02:51] <Keybuk> it's just NM's WPA puppetry
[02:52] <tseng> hm, is radeon oss broken for everyone?
[02:53] <j^> https://www.redhat.com/archives/fedora-test-list/2006-March/msg00555.html
[02:53] <j^> Are you using madwifi drivers, of the madwifi-ng drivers?
[02:53] <j^> wpa_supplicant must be compiled for one or the other, and right now its
[02:53] <j^> compiled for madwifi-ng.
[02:53] <Keybuk> madwifi drivers
[03:20] <Keybuk> WEP works at least
[03:20] <Keybuk> Mar 24 02:19:52 quest cupsd: Unable to open log file "/var/log/cups/error_log" - Permission denied
[03:20] <Keybuk> my gods, cups is having a spasm
[03:28] <wasabi_> I like how you say "gods."
[03:29] <_ion> Battlestar Galactica. :-)
[03:29] <Keybuk> too much Terry Pratchett, I suspect
[03:53] <Burgundavia> ok _ion, Pygi, you are gods among men. I salut you for your NM work
[03:54] <desrt> Keybuk; did you say wpa nm?
[03:58] <Keybuk> desrt: I said wpa-doesn't-work-for-me nm
[03:58] <Keybuk> but yesx
[03:58] <Keybuk> is in the archive
[03:58] <desrt> patiently too
[04:00] <Keybuk> ok, so I have Chicken, Asparagus, Sweetcorn and Pasta
[04:00] <Keybuk> maybe I shouldn't cook at 3am
[04:01] <desrt> uh
[04:01] <desrt> if you have some alfrado sauce then that's one hell of a meal
[04:01] <Amaranth> do you have any cream of chicken?
[04:01] <Amaranth> or that
[04:01] <Amaranth> i was going for the ghetto version :)
[04:02] <desrt> pasta+whitesauce+asparagus+chicken is practically meant to be
[04:03] <Keybuk> I'm avoiding the sauce for experimental purposes
[04:03] <Keybuk> and I-don't-have-any-in purposes
[04:03] <Keybuk> Amaranth: that's what I'm having; added herbs and oil to make a meal
[04:03] <Keybuk> actually tastes rather scrummy
[04:03] <Amaranth> Keybuk: cream of chicken?
[04:04] <desrt> ok.  so seriously
[04:04] <desrt> what's nfs that's not nfs?
[04:04] <desrt> all of these lustre/afs/whatever filesystems are way overkill
[04:04] <mjg59> desrt: The only simple, transparent Unix networking file system is nfs
[04:05] <desrt> damnit
[04:05] <desrt> this is really an area that needs improvement!
[04:05] <mjg59> If you don't like nfs, then what you choose depends on what you're trying to do
[04:05] <mjg59> Firstly, what's up with nfs?
[04:05] <desrt> i want to mount a bunch of user homedirectories on a bunch of machines in a reasonably trusted environment
[04:05] <mjg59> Easiest alternative is cifs
[04:05] <desrt> samba?
[04:05] <mjg59> Per-user auth, unix semantics
[04:05] <mjg59> Yeah
[04:06] <desrt> per-user auth is out of the question
[04:06] <mjg59> Why?
[04:06] <desrt> i want it to always be there
[04:06] <desrt> not just when people log in
[04:06] <mjg59> Ah.
[04:06] <mjg59> Then nfs is the answer
[04:06] <desrt> blah
[04:06] <mjg59> (seriously)
[04:06] <mjg59> What's inadequate about nfs?
[04:06] <desrt> i guess i'd better figure out how to effectively firewall it then
[04:06] <desrt> the nfs server is semi-outward-facing
[04:06] <mjg59> If all else fails, do nfs over VPN
[04:07] <mjg59> Or move to nfs4
[04:07] <desrt> mjg59; all the machines share ethernet
[04:07] <mjg59> Yeah. You can do a VPN over that, surely?
[04:07] <mjg59> If you're mounting stuff, you have to trust each of those machines
[04:07] <desrt> oh.  i see what you're saying
[04:07] <desrt> i don't need this much security
[04:07] <mjg59> But you don't have to trust the ethernet
[04:08] <mjg59> Just firewall out access to the portmapper and mountd
[04:08] <desrt> i'm really just worried about effectively firewalling the 1000 (occasionally semi-randomly assigned) ports it opens
[04:08] <mjg59> Though nfs (in theory) can turn up on any port, in practice it's always the same one
[04:08] <desrt> portmapper is infuriating
[04:08] <desrt> it has this -i open that totally fails to work in a useful way
[04:08] <desrt> -i 127.0.0.1 -i 172.20.1.1
[04:09] <desrt> you might expect this to do something sane... but it actually just binds to the last interface you give
[04:09] <desrt> making it impossible to have it bound to 127.0.0.1 (required for services to register) and a specific external interface at the same time without binding to INADDR_ANY
[04:09] <mjg59> iptables -A INPUT -s 0.0.0.0/0 --dport 111 -j DENY
[04:10] <desrt> i've already done this
[04:10] <mjg59> Or just use tcpwrappers
[04:10] <mjg59> (Since if you can't trust that, we're all doomed anyway)
[04:11] <desrt> i have listeners also on tcp/2049, 965, 3306, 953, 41115, 924, udp/2049, 32772, 32784, 918, 921, 1194, 962, 67
[04:11] <mjg59> That's fun
[04:11] <desrt> and i think that some of these are from portmap/nfs/whatever
[04:11] <desrt> :p
[04:11] <mjg59> What's bound to them?
[04:11] <mjg59> (lsof -i FTW)
[04:11] <desrt> netstat -p :)
[04:11] <mjg59> Well, or that
[04:11] <mjg59> You should have rpc.mountd and rpc.statd (possibly rpc.lockd)
[04:11] <desrt> mostly rpc.mountd and rpc.statd
[04:12] <mjg59> Again, easiest is just to tcpwrappers them out
[04:12] <desrt> i've already done that too
[04:12] <mjg59> Sounds pretty secure, then
[04:12] <desrt> muh.  guess i'm fine
[04:12] <mjg59> Seriously, if tcpwrappers is broken, so is so much of the internet that they won't be hitting you first
[04:13] <desrt> i imagine it'd be pretty hard to exploit tcpwrappers
[04:13] <mjg59> Yeah
[04:13] <mjg59> It's pretty simple code, and it's been checked a lot
[04:13] <desrt> not to mention it doesn't listen to them at all
[04:13] <desrt> it's just like "you?  hmm. no."
[04:15] <mjg59> Wow. Aspirin is, like, the best thing ever
[04:15] <desrt> ah.  interesting.  the kernel is listening on 0.0.0.0:2049 tcp and udp.  this is what bothers me most :)
[04:15] <desrt> this seems to be static though.. it's listed in /etc/services as 'nfs'
[04:16] <mjg59> I generally forget that these things actually work
[04:16] <mjg59> Oh, wait. That sounds quite bad.
[04:17] <desrt> don't worry.  we know you're just a pill swallower
[04:40] <Amaranth> real aspirin is worthless
[04:40] <Amaranth> you need 2000 mg of ibuprofen
[04:51] <Keybuk> Amaranth: some people don't react to ibuprofen
[04:51] <Keybuk> some do
[04:51] <Keybuk> depends whether the complaint is due to inflammation as well
[04:51] <Amaranth> hydracodone (sp?) then? :)
[04:54] <LaserJock> hmm, for my wife asprin works but ibuprofen doesn't do anything
[05:01] <mhz> TheMuso: ping
[05:01] <mhz> TheMuso: thx for the email
[05:29] <LaserJock> is there some recommendation about using "dfsg" in either the package name or version for package that have non-free parts removed?
[05:32] <fabbione> morning guys
[05:32] <G0SUB> LaserJock: it's mostly appended to the version IIRC
[05:41] <nictuku> fabbione, hi
[05:41] <fabbione> hi
[05:46] <minghua> G0SUB: make would be an exception (the source package is make-dfsg)
[05:46] <G0SUB> minghua: the gfdl issue?
[05:47] <G0SUB> minghua: has the make package been updated yet? IIRC no
[05:48] <minghua> G0SUB: you are right.  but it's make-dfsg in debian already
[05:48] <G0SUB> okay, great
[06:08] <greebo> Can some canonical person please tell warthogs that Jeff (jdub) has been offline since 3am, and the fault has been logged with Telstra (very few Canonical people in Sydney at the moment so he couldn't call them)
[06:08] <fabbione> greebo: thanks
[06:08] <fabbione> <-will do
[06:08] <greebo> fabbione, thankyou
[06:09] <fabbione> greebo: done
[06:09] <fabbione> he can go back to sleep now ;)
[06:10] <greebo> fabbione, heh, he will have dinner in a few hours, no sleeping just yet ;)
[06:11] <fabbione> greebo: afternoon nap? :)
[06:11] <greebo> heh :) siesta is always an option!
[06:11] <fabbione> seee...
[08:00] <janimo> Lathiat: ping
[08:01] <sladen> mjg59: ACPI on HP/Compaqs seem to have broken.  This should be handled internally in the DSDT---did a interpreter change or similar?
[08:02] <pitti> Good morning
[08:07] <Lathiat> janimo: pong
[08:07] <janimo> Lathiat: what is the status of avahi in dapper?
[08:07] <janimo> I see zeroconf spec was deferred
[08:07] <Lathiat> janimo: spec delayed, avahi was put in main, not installed by default
[08:07] <Lathiat> no gui for configuring it
[08:07] <Lathiat> that'l be done as part of zeroconf in dapper+1
[08:08] <janimo> Lathiat: so how can one try it out now?
[08:08] <Lathiat> janimo: apt-get install avahi-daemon
[08:08] <janimo> can nautilus use it to discover samba shares for example?
[08:08] <janimo> Lathiat: I have it installed just wondering how to test it best
[08:08] <janimo> since I am entirely new to it
[08:08] <janimo> gnome app seem to all link to avahi
[08:09] <janimo> so I suppose even if there's no gui one can use it somehow
[08:10] <janimo> is the reason for spec delay incompleteness of avahi in some way?
[08:10] <janimo> Lathiat: so I am interested mostly in the client part now
[08:40] <mdke> what's the correct way to enable flash in firefox on dapper? We refer to an absent package in the documentation at the moment
[08:41] <mdke> (flashplayer-mozilla, which seems to have disappeared from multiverse)
[08:41] <Lathiat> i can see it
[08:41] <Lathiat> ?
[08:43] <mdke> hmm
[08:43] <mdke> Lathiat, http://article.gmane.org/gmane.linux.ubuntu.doc/5220
[08:44] <Seveas> mdke, flashplugin-nonfree?
[08:44] <mdke> Seveas, right, that's what the poster says in that post, except he says it doesn't work
[08:45] <Seveas> wffm - but it downloads things from an external server which of course is unreliable
[08:45] <mdke> Seveas, it works for you?
[08:46] <Seveas> worked a few weeks ago - didn't try since
[08:46] <mdke> I'll have a go
[08:51] <mdke> doesn't work
[08:52] <mdke> if anyone knows how to get flash support, please highlight me, and we'll add it to the documentation
[08:57] <robitaille> mdke: download the tar file from macromedia web site, untar it, copy the two files to your plugins directory in .mozilla.  Not really user friendly, and use the CLI, but it works :)
[08:57] <mdke> we'll fall back to that if there isn't a package, I guess
[08:58] <robitaille> someone could probably write a small script, including scraping from the macromedia web site the link to the latest tar file available.
[08:58] <jsgotangco> its already a script
[08:58] <jsgotangco> its not even a complicated script
[08:58] <infinity> Or we could get explicit permission from Macromedia to redistribute in multiverse.
[08:59] <jsgotangco> yeah
[08:59] <infinity> (which we used to do without permission)
[08:59] <mdke> ah, hence the package disappearing
[08:59] <infinity> Having installer packages that break a few months after release is always teh suck.
[08:59] <robitaille> or someone could resync with the latest DEbian package.  I thought there was request on the motu list about this
[08:59] <mdke> so what does the flashplugin-nonfree package do?
[08:59] <infinity> robitaille: Yes, but that doesn't solve anything in the long term, just for now.
[08:59] <mdke> that's in the archive
[08:59] <robitaille> would solve the security issue with the older flash we try to ship in all the ubuntu version since Warty
[09:00] <infinity> mdke: flashplugin-nonfree is an "installer package" that downloads from macromedia and installs.
[09:00] <robitaille> infinity:  long term is to hope that a free solution will work correctly for joe user
[09:00] <infinity> mdke: flashplayer-mozilla was a package that actually shipped the biaries from our archive (so didn't rely on their website not breaking)
[09:00] <mdke> ok
[09:01] <infinity> robitaille: That's longer term.  I'm talking "for the dapper cycle", since we're not going to go slipping new Flash player (free or not) into dapper after it releases.
[09:01] <mdke> i tried installing it from within firefox, that failed too
[09:01] <mdke> lots of people will try that, because you only notice its absence when you get those "Missing Plugin" boxes
[09:01] <robitaille> mdke:  that should work...it worked for me a few weeks back.
[09:01] <infinity> How does it fail when you install it from firefox?
[09:02] <jsgotangco> it downloads but doesn't install
[09:02] <infinity> Fun.
[09:02] <mdke> infinity, i don't know. It downloads for a while, gives me a license agreement, then says "Installation failed"
[09:02] <robitaille> infinity:  for dapper, what's wrong with the latest DEbian package?
[09:02] <infinity> robitaille: That it will stop working a month after we release?
[09:02] <robitaille> then put the next version in dapper-update
[09:03] <mdke> it only lasts a month?
[09:03] <infinity> mdke: No, that's a hypothetical.  As in "they could move the files on their website in a month"
[09:03] <infinity> Installer packages are notoriously unreliable and unsuitable for stable releases, IMO.
[09:03] <mdke> oh, that's an installer thing too
[09:03] <robitaille> 6.0.25 worked for quite a while...it's only semi recently that things started to break.
[09:04] <mdke> infinity, i think the website uses a generic filename though, rather than a version number in the filename, so it might not break
[09:04] <infinity> And Macromedia /does/ hand out redistribution licenses like they're candy, so I'm not sure why no one's emailed them for one (which we could then apply to put flashplayer-mozilla back in multiverse)
[09:04] <mdke> but still, the website itself might break
[09:04] <Pygi> _ion: around?
[09:05] <mdke> infinity, do you fancy pinging someone official to mail them?
[09:05] <robitaille> on the other side, we are talking about a multiverse package.  it breaks, it breaks; nobody is promising anything to anyone.  But it would be nice if it worked for at least JUne 2006 :)
[09:05] <infinity> Well, I still have breezy's flashplayer-mozilla installed.  Didn't even notice it had been removed. :)
[09:05] <infinity> That works fine.
[09:05] <mdke> me too
[09:06] <infinity> Oddly enough, my name's the last one on the changelog too.
[09:06] <infinity> Hrm.
[09:06] <infinity> Could explain why I have it installed. :)
[09:06] <mdke> then you get to fix it!
[09:06] <minghua> hehe
[09:07] <mdke> i saw that rule somewhere
[09:07] <infinity> Anyhow, I could mail them as an Ubuntu community representative, and if getting a license on behalf of Ubuntu doesn't cut it for them, can see if they're interested in granting a distribution license to Canonical instead.
[09:07] <mdke> sounds great
[09:07] <infinity> mdke: Yeah, I'm exempt from the rule, since I upload EVERYONE's packages. :)
[09:08] <mdke> infinity, no, that just means you get to fix everything
[09:08] <infinity> If I suffered from touched-it-last maintenance, I'd maintain the whole dist by now.
[09:08] <mdke> :)
[09:08] <Mithrandir> infinity: you don't?
[09:08] <infinity> Mithrandir: Shh.  I'm trying to put a happy spin on things and pretend for a moment that my life doesn't suck.
[09:23] <infinity> sladen: Around?
[09:24] <Pygi> Keybuk: here?
[09:25] <sladen> infinity: yup
[09:26] <JaneW> sladen: ping
[09:26] <sladen> JaneW: pong
[09:26] <JaneW> sladen: did you receive my laptop testing team mail? 9I think you were one of the ones that got mail-bombed with the message - sorry about that)
[09:27] <JaneW> sladen: I have to check in with all testers to make sure that they are still actively testing and on track
[09:27] <sladen> JaneW: yup, I queried you on IRC about the multiple copies.  I'll just answer the first one if you want:)
[09:28] <JaneW> sladen: again I am sorry, the messages refused to send, and I was creating a new one and then everything suddenly went - it was stupid
[09:28] <sladen> JaneW: I got one, and then there was a second one CC'ed to me, mjg59, corey
[09:28] <JaneW> sladen: yes one response with suffice ;)
[09:28] <JaneW> unless you want to get me back ;)
[09:28] <sladen> :)
[09:28] <JaneW> with=will
[09:29] <JaneW> siretart: ping
[09:29] <siretart> JaneW: pong
[09:29] <JaneW> Lathiat: ping
[09:29] <infinity> sladen: https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-i810/+bug/31499
[09:29] <JaneW> siretart: what I said to sladen...did you receive my laptop testing team mail? (sorry if you got mail-bombed with the message)
[09:29] <siretart> JaneW: yes, I received your message
[09:29] <Ubugtu> Malone bug 31499 in xserver-xorg-driver-i810 "no dri with xorg 7.0 on Dapper" [Normal,Needs info]  
[09:30] <infinity> sladen: The last comment on that bug is pretty convinced you just broke DRI for him with your mesa upload.
[09:30] <Lathiat> JaneW: pong
[09:30] <siretart> JaneW: I'm still testing the laptop, but my wiki is at flight-4, due to my last exam this week. I'll get it updated to flight-5 asap. 
[09:30] <sladen> Ubugtu: why are you not providing clickable URLs anymore
[09:30] <JaneW> Lathiat: did you receive my laptop testing team mail? (sorry if you got mail-bombed with the message)
[09:30] <JaneW> siretart: ok great thanks
[09:31] <Mithrandir> siretart: flight-6 is on Wednesday, you know, so you better get rolling. ;-)
[09:31] <siretart> JaneW: the laptop is in general fine, there are issues with suspend to ram, and some hotkeys, but nothing serious
[09:31] <Lathiat> nope sorry
[09:31] <JaneW> siretart: we were just concerned that some people might have stoped testing altogether
[09:31] <simira> Mithrandir: don't work so fast! I can't keep up!
[09:31] <JaneW> siretart: I'll list you as compliant
[09:31] <infinity> sladen: It was responding to a clickable URL I pasted two lines up. :)
[09:31] <siretart> JaneW: no, I didn't stop at all. I needed to pause for some weeks for my exam
[09:31] <Lathiat> JaneW: i havent actually
[09:31] <Lathiat> JaneW: whered you send it?
[09:31] <siretart> Mithrandir: thanks for notice :)
[09:32] <JaneW> Lathiat: I will check and resend...
[09:32] <Lathiat> also yeh i havent been updating the wiki, i do test it tho :)
[09:32] <Lathiat> if thats what your wondering
[09:32] <Lathiat> i should update it
[09:33] <JaneW> Lathiat: It went to lathiat@bur.st
[09:33] <sladen> infinity: funky, ta.  That set (kernel, mesa, -driver-i810, discover1-data) were basically adding additional PCI IDs
[09:34] <Lathiat> from?
[09:35] <Lathiat> resend?
[09:35] <JaneW> Lathiat: done - you may have spam filtered it... ;)
[09:35] <Lathiat> i got that one
[09:36] <Lathiat> JaneW: i'll do a wiki update this weekend
[09:36] <JaneW> Lathiat: ty :)
[09:36] <Lathiat> no real issues with my laptop a-t-m tho, other than the bug reports im already participating in
[09:36] <Lathiat> e.g. the synaptics/alps bug
[09:37] <JaneW> does anyone know Niall Sheridan ?
[09:37] <JaneW> him and kokey are the only 2 unaccounted for now.
[09:37] <JaneW> koke I mean (kokey is another guy)
[09:41] <sladen> JaneW: don't you have their details on file from when you posted the machines out?
[09:42] <JaneW> sladen: well I didn;t post the machines out...
[09:42] <JaneW> sladen: I dstarted with the wiki table and now I have Claire's list
[09:42] <JaneW> sladen: so I do have an e-mail address for him, but he hasn't responded
[09:47] <dholbach> good morning
[09:47] <hunger> Do we really need ifrename in the resume scripts now that udev does that anyway?
[09:48] <Pygi> mornin' dholbach
[09:48] <dholbach> heya Pygi
[09:49] <seb128> fabbione: do you have a patch of that change you did to glib? Debian could use the same change probably?
[09:49] <fabbione> seb128: uh no.. it's just a change in debian/rules
[09:50] <seb128> hum, k, I'll debdiff both so
[09:50] <seb128> or diff both rather :)
[09:50] <fabbione> just diff debian/rules
[09:50] <fabbione> it's a 3/4 lines changes
[09:50] <seb128> k
[09:50] <seb128> do you know if -mcpu=v9 should be used on Debian sparc too?
[09:51] <fabbione> seb128: it's an optimizations for sparc64 processors
[09:51] <seb128> that package used to have no diff and be syncable, I would like to keep it that way if possible :p
[09:51] <fabbione> afaik it breaks on sparc32
[09:51] <fabbione> that debian does support
[09:51] <seb128> :(
[09:52] <dholbach> seb128: couldn't you do a test on   lsb_release -is   in debian/rules?
[09:52] <Pygi> infinity: around?
[09:53] <seb128> dholbach: Debian has no lsb installed by default, but we could Build-Depends on it maybe
[09:53] <dholbach> yeah
[09:53] <seb128> dholbach: I would rather have a try on the arch than on lsb
[09:54] <dholbach> seb128: sure.. that'd be better
[09:55] <Pygi> who can tell me why is n-m missing libn-dev atleast for ppc (we didn't had amd64 builds) when in our test repo we have that package? :-/
[09:55] <Pygi> https://launchpad.net/distros/ubuntu/+builds?build_state=depwait
[09:56] <fabbione> later
[09:56] <simira> morning fabbione 
[09:56] <fabbione> hi simira
[09:57] <simira> How's your better half?
[09:57] <fabbione> simira: she is getting better...
[09:57] <fabbione> and you?
[09:58] <simira> fabbione: fine, enjoying the spring approaching.
[09:58] <fabbione> eheeh good
[09:58] <fabbione> ok i am back to the rack
[09:58] <fabbione> for real
[09:58] <simira> enjoy
[09:59] <slomo_> Pygi: libnl is not in main yet
[09:59] <Pygi> slomo_: hm, ok, thanks for taking time to answer ^_^
[10:01] <infinity> seb128: I used lsb_release for a few packages to keep them syncable.  Works well.
[10:01] <slomo_> Pygi: but it's approved... so talk to Kamion about it maybe :)
[10:01] <seb128> infinity: yeah, that's an idea :)
[10:01] <infinity> seb128: And we definitely don't want to build with -mcpu=v9 on Debian/sparc
[10:01] <seb128> slomo_: do you have an idea why some people still have that totem-xine issue?
[10:02] <slomo_> seb128: the crash, the mem usage or the slow logo?
[10:02] <seb128> slomo_: the xerror, which is the same issue that the slow logo afaik
[10:03] <seb128> seems to be "ask for too much ressource and trigger an xerror due to that" crash
[10:03] <slomo_> seb128: hmm... would be useful to have the complete output of totem-xine in that case
[10:03] <infinity> fabbione: If you wanted to build with world with v9, why didn't you have doko change the GCC default to v9 instead of v8?
[10:04] <infinity> fabbione: I can also override it in gcc-opt, or a varienty of other things to prevent seb from having an ugly diff in his package. :)
[10:07] <fabbione> infinity: becayse we don't want that for dapper
[10:08] <fabbione> infinity: dapper is v8 by default and that's good enough
[10:08] <fabbione> infinity: some pkgs require extra tuning.. and to avoid to introduce a global regressions point, we just change the few we need
[10:08] <seb128> does that tuning makes a real difference?
[10:08] <fabbione> seb128: yes
[10:09] <fabbione> like changing from v7 to v8 in gcc made gcc about 25% faster
[10:09] <fabbione> but we know there are no regression from v7 to v8
[10:09] <fabbione> we don't know the same to v9
[10:10] <fabbione> so isolated changes are easy to spot than changing the default
[10:10] <fabbione> seb128: you will be able to drop the change in dapper+1 if we get enough testing on v9 by default
[10:10] <seb128> k, I guess I'll be near to 0 GNOME packages syncable on Debian without change soon :p
[10:12] <seb128> Kamion, mdz: could any of you approve or refuse the libcairo UVF exception? There is a CVE on cairo fixed by that version, so either way we need to patch or update
[10:13] <fabbione> bbl
[10:14] <infinity> fabbione: Yeah, but I still could have overridden just the one package in gcc-opt, that's all I'm saying. :)
[10:22] <Kamion> Pygi: I'm doing my morning archive maintenance now, so main promotions are next on the list
[10:22] <Kamion> seb128: ... and UVF exceptions are after that, being harder ;)
[10:23] <Kamion> have to do these things in order of coffee intake
[10:23] <Pygi> Kamion: thanks ^_^
[10:24] <seb128> Kamion: hehe :)
[10:25] <seb128> Mithrandir: hi.  you working on some xkeyboard-config changes atm? Just to know if I can upload an another fix for the ralt stuff
[10:25] <Pygi> Kamion: will we get wpasupplicant in main as well?
[10:26] <Mithrandir> seb128: I have no changes pending now.
[10:26] <Mithrandir> seb128: I uploaded the fix from svu on lp yesterday, is it more than that?
[10:26] <seb128> Mithrandir: ok, I'll upload it so. FYI the change is http://webcvs.freedesktop.org/xlibs/xkbdesc/symbols/group?r1=1.7&r2=1.8
[10:26] <Kamion> Pygi: it's in the queue, but not reviewed yet
[10:27] <Kamion> and it pulls in qt4, which seems to have gone unnoticed
[10:27] <Kamion> Pygi: I don't actually really make the review decision, pitti does that
[10:27] <Kamion> I just act on decisions he makes (and make a few "obvious" ones myself)
[10:27] <Mithrandir> seb128: go ahead.
[10:27] <seb128> Mithrandir: that fixes the issue on my box and my altgr is still working as modifier on normal config so seems to work fine :)
[10:27] <seb128> Mithrandir: ok, doing that now
[10:27] <lifeless> mjg59: there is no process called evdev 
[10:28] <slomo_> Kamion: hm, the libnl inclusion report says that it's approved by pitti
[10:28] <dholbach> lifeless: a loaded module called evdev?
[10:28] <Kamion> slomo_: that would be why I promoted it five minutes ago :-P
[10:28] <Kamion> slomo_: Pygi asked me about wpasupplicant, not libnl
[10:28] <lifeless> dholbach: is evdev a kernel module ?
[10:28] <Pygi> Kamion: yes, I know...we removed that dependency in our test repo I believe... ok, I'll poke pitti
[10:29] <Kamion> well, most recently
[10:29] <slomo_> Kamion: oh... ok, sorry for the noise ;)
[10:29] <Pygi> Kamion: nah, I about libnl and libnl-dev ;)
[10:29] <seb128> $ sudo lsmod | grep evdev
[10:29] <seb128> evdev                  10432  1
[10:29] <seb128> but that's an xorg.conf option too
[10:29] <Kamion> Pygi: might have changed actually, the anastacia report I was looking at predates the NEW processing I did on the most recent wpasupplicant binaries 20 minutes ago
[10:29] <lifeless> ah yes
[10:29] <lifeless> mjg59:  - yes, evdev 10176 2
[10:29] <Pygi> Kamion: ah,kk
[10:30] <seb128> but I know using evdev with xorg makes gnome-settings-daemon go away
[10:30] <lifeless> interesting
[10:30] <Kamion> seb128: since mdz was already talking with you about cairo, I'd prefer to leave that to him
[10:30] <Kamion> usually works best if we don't both pile in on something
[10:30] <lifeless> I didn't explicitly ask for it ever
[10:31] <seb128> Kamion: yeah, do you know if he's likely to be around today?
[10:31] <seb128> he was not to the distro team meeting yesterday neither replied to the mail so ...
[10:33] <Kamion> seb128: oh, actually, StaffCalendar says he's on holiday now; ok, I'll look at it
[10:33] <seb128> Kamion: thank you
[10:34] <pitti> Pygi: I accepted wpasupplicant yesterdsy
[10:34] <Pygi> pitti: k, great
[10:34] <pitti> Pygi: oh, can you make wpasupplicant optional in nm
[10:34] <pitti> Pygi: ?
[10:34] <pitti> Pygi: i. e. detect it at runtime?
[10:34] <Kamion> pitti: it was still in the not-ready section of the inclusion queue
[10:35] <pitti> Kamion: yes, because it wasn't seeded/germinated yesterday night
[10:35] <Pygi> Kamion: yes, that's why I told that...
[10:35] <pitti> Pygi: I'm not 100% happy about having it in main, but if we can't avoid it...
[10:35] <pitti> it seems sane enough at least
[10:36] <Kamion> pitti: no, it wasn't even in that section, it was in "reviewed packages that need work before approval"
[10:36] <Kamion> still is
[10:36] <pitti> Kamion: oops, my fault then
[10:36] <Pygi> pitti: we can't really avoid it when N-M needs it for WPA jobs
[10:36] <Kamion> pitti: I routinely look in the "reviewed and approved, but not ready to promote" section anyway
[10:36] <pitti> Pygi: I meant, will n-m work without wpasupplicant?
[10:36] <Pygi> pitti: yes, ofcourse ...
[10:37] <Kamion> pitti: I wonder if it's still worth keeping that separate from "ready to promote"
[10:37] <Kamion> because the ftpmaster has to sanity-check against anastacia *anyway*
[10:37] <pitti> Kamion: if you don't need it, then let's just merge them
[10:37] <Pygi> pitti: it'll work, but no WPA will be available
[10:37] <pitti> Pygi: that sounds indeed good
[10:37] <pitti> Pygi: so what about Recommends: or Suggests: instead of Depends:?
[10:37] <Kamion> pitti: mdz might have liked it I guess, but it seems like excess paper-shuffling to me
[10:37] <slomo_> Pygi: and no WEP afaik? doesn't it use wpa_supplicant for WEP?
[10:38] <Kamion> I've never found it valuable
[10:38] <Pygi> slomo_: yes, no wep as well ;)
[10:38] <pitti> Kamion: fine for me
[10:38] <Pygi> pitti: I would go for recommended ...
[10:38] <Pygi> pitti: what do you say?
[10:39] <pitti> Pygi: the definition of 'Suggests' seems to match more closely IMHO, but I don't know how many people actually need WPA
[10:39] <slomo_> pitti: i would say that nm is almost useless without wpa_supplicant... no sane wireless network has no encryption at all (it's required also for WEP)
[10:39] <pitti> slomo_: hm?
[10:39] <Pygi> pitti: wpasupplicant is also needed for WEP
[10:39] <pitti> slomo_: I'm in a city-wide WLAN that has no encryption at all - what for?
[10:40] <pitti> slomo_: the only thing that WEP/WPA provides is access control to the WLAN, AFAICS
[10:40] <hunger> pitti: Lucky you... I never ever was able to use an unencrypted WLAN.
[10:40] <pitti> slomo_: but in big networks that seems to work poorly, that's why they use something different here
[10:41] <Pygi> pitti: yes, but do we really want it to make *that irrelevant* to put in 'Suggests'
[10:41] <infinity> Pygi: Err, why would it be required for WEP?... it never was before.
[10:41] <slomo_> pitti: ok, but i for one was never in a wlan that had no encryption ;) and i think every private wlan has (or should have) encryption...
[10:41] <pitti> slomo_: why?
[10:41] <Pygi> infinity: uh, k , sorry :-/
[10:41] <Pygi> it isn't required for WEP, just WPA
[10:42] <Pygi> pitti: hm, I guess we can go with 'Suggests' then
[10:42] <pitti> Pygi: http://www.de.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
[10:42] <infinity> I's recommend Recommends, personally.
[10:42] <infinity> Since WPA is a pretty big feature of NM.
[10:42] <pitti> infinity: well, WFM, but for Recommends we need it in main
[10:43] <slomo_> pitti: do you want your neighbour or somebody else use your network? :) but anyway, i'm fine with recommends
[10:43] <hunger> Pygi: Are you sure NM does not use wpasupplicant for both? It would be natural to do so IMHO.
[10:43] <slomo_> pitti: we have many packages in main that recommend something outside of main afaik
[10:43] <pitti> slomo_: alright
[10:43] <infinity> pitti: Is it too sketchy/broken for supported?
[10:43] <Pygi> hunger: as infinity sad, WEP can be used without wpasupplicant
[10:43] <Pygi> infinity: not really, but the question is do we want to support it for 3 years in its current state
[10:43] <pitti> infinity: it seems sane now, but given that wlan change their encryption method like people change their socks, I have a dizzy feeling about supporting it for 3 years
[10:44] <hunger> Pygi: Hmmm... gnome developers seem to like redundant code:-)
[10:44] <Pygi> pitti: and what about "Enhances" ?
[10:44] <Treenaks> pitti: WLAN encryption is stnadardized now
[10:44] <pitti> Pygi: that's not yet really supported, and Enahnces is just a reverse Suggests
[10:44] <Treenaks> pitti: (WPA2 is an implementation of 802.11i afaik)
[10:44] <infinity> Pygi: You can put Enchances in the control file if you want, but no tools actually support it.
[10:45] <Treenaks> pitti: (which is a standard)
[10:45] <Pygi> infinity: oh, joy ...
[10:45] <pitti> infinity: 'Enchants:'? :)
[10:45] <infinity> pitti: Erm, yeah. I can type.  Really.
[10:46] <Pygi> pitti, infinity: so the real question is do we really want wpasupplicant in main ... given that it's not so good as it should be, do we really think we can/want to support it for 3 years? :-/
[10:46] <hunger> pitti: Even if there is a new WLAN encryption in 3 years time, then the situation will probably be like WEP/WPA at the moment. I doubt that WPA will change in itself.
[10:46] <pitti> hunger: I agree, it'll just be obsolete
[10:47] <hunger> pitti: Yes, like WEP is nowadays. Still you want to support that?
[10:47] <pitti> I think the most important question is: is there an upstream behind it which is likely to stay around for a while?
[10:48] <Kagou> hi
[10:48] <Pygi> pitti: behind wpasupplicant 0.4.8? hardly...they are now working on new 0.5 brach, which is labeled as experimental development build
[10:48] <infinity> That is the real question, yes, since WPA should eventually get rolled into wireless-tools, I expect.
[10:48] <hunger> Maybe someone "offical" could ask them?
[10:49] <infinity> No need to be official to ask such questions.
[10:49] <infinity> Oh boy, another banshee upload.
[10:49] <hunger> infinity: Well, the answer might differ depending on whether it is asked by famous-distribution-head-honcho or by joe-random-user;-)
[10:50] <infinity> hunger: No, if you're asking how long upstream plans to stick around and support software, the answer is always the same.
[10:50] <slomo_> infinity: sorry :( maybe we can finally find the package that breaks the world and fix it this time?
[10:50] <infinity> hunger: No one's going to commit to supporting their crap for 3 years just because they like me.
[10:50] <infinity> slomo_: I need to find the time to figure it out.  I can't reproduce it reliably, so it's a bit of a pain to nail down.
[10:50] <hunger> infinity: Yes... I guess something like "nope, we play with the cool stuff" :-|
[10:51] <infinity> slomo_: If I had to guess, I'd blame either mdadm or udev, since no other package build-deps on those (why does yours?)
[10:52] <ogra> ARGH
[10:52] <Pygi> pitti: it is higly unlikely that they will continue backporting fixes from 0.5 branch to 0.4.8 as they consider 0.5 to be too much experimental...and we are using "our own" patches on wpasupplicant 
[10:52] <HrdwrBoB> where "experimental" = works
[10:53] <slomo_> infinity: good question... where do the b-d exactly come from?
[10:53] <Pygi> yes, that is true HrdwrBoB, but do you really want to support that? :-/
[10:53] <infinity> slomo_: Let me hunt that down for you.
[10:53] <hunger> ogra: Xgl is experimental, so that is to be expected.
[10:53] <Pygi> HrdwrBoB: and no, it doesn't work for anyone
[10:53] <ajmitch> hunger: yes, but the frustration of getting many, many bug reports like that.. :)
[10:54] <hunger> ogra: Plus xgl does not support direct rendering by apps which is probably what the gl screensaver is doing.
[10:54] <ogra> hunger, yes, but is the workload that crap puts on me also to be expected ? 
[10:54] <ogra> damned
[10:54] <infinity> slomo_: libnjb5 depends on "udev | hotplug" ... That's obviously just plain wrong.
[10:54] <Pygi> ogra: just tell them them to stop reporting such bugs ^
[10:54] <Pygi> not that they will listen, but...
[10:54] <ogra> exactly 
[10:54] <infinity> slomo_: You should change that to a Suggest, perhaps.
[10:54] <ogra> *sigh*
[10:54] <hunger> ajmitch: Is that at all surprising?
[10:54] <infinity> slomo_: (or remove it completely, since an Ubuntu system without udev is pretty rare)
[10:55] <slomo_> infinity: sure, will do... but don't ask me why it depends on those :)
[10:55] <Pygi> pitti: so, what we will do? :-/
[10:56] <pitti> Pygi: well, it seems I'm overturned by the large number of people who need WPA :)
[10:56] <pitti> Pygi: really, I'm fine with putting it into main if it helps many people
[10:57] <pitti> Pygi: but please make it a Recommends: nevertheless, so that it can be uninstalled
[10:57] <slomo_> infinity: hm, was added by the debian maintainer in the last version we synced... anyway, let's move it to suggests
[10:57] <hunger> pitti: I need WPA, but I do not need it in main.
[10:57] <infinity> slomo_: Yeah, I saw the Debian changelog.  He changes the "hotplug" depends to "udev | hotplug"... Changing one to the other is correct, but it should never have been a Depends in the first place. :)
[10:58] <pitti> hunger: but you know what wpasupplicant is, presumably :)
[10:58] <hunger> pitti: I'll probably switch to dapper+1 as soon as the archives are opened for that;-)
[10:58] <slomo_> infinity: ok, uploaded :) can you delay banshee until this is built?
[10:58] <Pygi> pitti: I don't think having wpasupplicant in restricted for example, is bad...people who need it, will just install it
[10:58] <infinity> slomo_: And it would appear that's what's pulling in mdadm as well (through a lovely udev -> initramfs-tools -> mdadm dependency chain), though that won't happen anymore with the latest initramfs-tools.
[10:58] <hunger> pitti: I am using it for a long time now...
[10:58] <pitti> so either we say 'yes, we want WPA', then we need to commit to that and put it into ship, or we say 'sucks to be you' and entirely leave it in universe
[10:58] <infinity> slomo_: Not easily.  I'll just clean up if it breaks.  No big deal.
[10:59] <Pygi> pitti: why not restricted?
[10:59] <pitti> but if it's really that important, then it rather sounds like we shoould do (a)
[10:59] <infinity> slomo_: And we can see on your NEXT banshee upload if that fixes the issue. :)
[10:59] <hunger> Pygi: Is wpasupplicant restricted?
[10:59] <pitti> Pygi: what should that be good for? isn't it free software?
[10:59] <Pygi> pitti: we did the the same with madwifi -ng (puted) it into restricted
[10:59] <Pygi> pitti: ah, yes, it is..
[10:59] <pitti> Pygi: or does it violate patents of any kind?
[10:59] <Pygi> nop
[10:59] <slomo_> infinity: hehe... i think the next one could take a bit longer this time ;)
[10:59] <Pygi> hm, ok, I guess we'll just have to make it recommend :-/
[10:59] <pitti> Pygi: we have to support restricted as well as main
[11:00] <infinity> slomo_: Note that it's the weekend for me already, so I'm trying to avoid anything that smells too much like work. :)
[11:00] <Pygi> pitti: yes, I know...hm, if we put it into universe it's unlikely it will ever get fixes, patches, etc :-/
[11:00] <pitti> infinity: wanna bet how long you can resist? :)
[11:00] <infinity> pitti: I'll be strong.  I promise. :)
[11:00] <pitti> infinity: use the force :)
[11:01] <Pygi> pitti: if it's up to universe or main, I say we go for the main ... and make sure we apply proper patches if/when needed
[11:01] <Pygi> pitti: and make wpasupplicant "Recommended" of N-M
[11:02] <hunger> Pygi: If it is a recommend, then it will not work out of the box. Then it can go into universe as well IMHO.
[11:02] <Pygi> hunger: bah, do we erally want to make it "Depend"??
[11:02] <Pygi> really*
[11:03] <hunger> Pygi: if you don't then a normal user won't be able to set up a wpa connection without help.
[11:03] <infinity> hunger: All high level package managers will install Recommended packages by default.
[11:03] <hunger> Pygi: wpasupplicant can then just as well go into universe.
[11:03] <Pygi> pitti: thoughts?
[11:03] <hunger> infinity: They do?
[11:04] <infinity> hunger: If we're not putting NM in -desktop (we're not), then the only way users will install it is manually.
[11:04] <hunger> infinity: I never used one.
[11:04] <Pygi> hunger: no, it universe it's less likely to get proper support
[11:04] <pitti> Pygi: recommends, and putting it into ship should DTRT, shoudln't it?
[11:04] <infinity> hunger: And if you're assuming "stupid users", you assume they use "stupid user package management", which will always pull in recommends by default.
[11:04] <pitti> infinity: aptitude won't install recommends if they are in ship?
[11:04] <hunger> infinity: Oh, then why move it into main at all?
[11:04] <infinity> pitti: Oh, if it's a ship/supported split, and all you have is the CD, then it won't work, yes.
[11:05] <infinity> pitti: We'd need to explicitely seed wpasupplicant to ship to make the CD corner case work.
[11:05] <pitti> infinity: I mean, if both n-m and wpasupplicant are in ship, then I don't see a problem with recommends
[11:05] <infinity> pitti: Right.
[11:05] <pitti> infinity: yes, that's what I was up to
[11:05] <Pygi> pitti: yes, agreed...
[11:05] <Lure> WPA is becoming mainstream and I think it makes sense it is always installed with NM (=depends)
[11:05] <Pygi>  Lure: bah, you haven't been following all..
[11:06] <hunger> Oh, I'll just shut up. You will do the right thing anyway.
[11:06] <ogra> fabbione, ping
[11:06] <Pygi> hunger: nah, just say your opinion
[11:06] <fabbione> ogra: pong
[11:06] <infinity> Lure: Nah, Debian packaging is as much about choice as anything else.  If WPA isn't a REQUIRED feature of NM (and it's not), it's best as a Recommends (if "most" people want it) or a Suggests (if "some" people want it)
[11:06] <Pygi> pitti: do we have place on CD for wpasupplicant?
[11:06] <ogra> bug #34584
[11:06] <Ubugtu> Malone bug 34584 in gnome-screensaver xserver-xorg-driver-ati "screensaver flicker ati" [Normal,Confirmed]  http://launchpad.net/bugs/34584
[11:06] <pitti> Pygi: the default answer is always 'no' :)
[11:07] <Pygi> pitti: I got the impression that it's "no" ;)
[11:07] <fabbione> ogra: yes?
[11:07] <Treenaks> Pygi: Unless you go back in time and invent bigger CDs, that is
[11:07] <pitti> Size: 231746
[11:07] <Pygi> pitti: ah, I knew it... but can we squeeze it in? ;)
[11:07] <hunger> Pygi: I am for both in desktop and thus main or both in universe (but maybe on the CD).
[11:07] <ogra> fabbione, intrestingly i can neither reproduce it on my amd64 lappie with nvidia card (amd64/i386) nor on my ibook ati ..
[11:07] <pitti> well, that doesn't look too  bad
[11:07] <Lure> infinity: if recommends means that you will get it with NM, then I think this is the right mode
[11:07] <infinity> Yeah, 200~250k, depending on arch.
[11:07] <infinity> That's a biggish package, but not horrible.
[11:07] <ogra> fabbione, the flickering seems to appear only with certain ati cards
[11:07] <fabbione> ogra: well they say that it is gnome-screensaver.. because it works with xscreen saver
[11:07] <infinity> Lure: Recommends means that if you use high-level package management (aptitude, synaptic, etc), you'll get it by default, yes.
[11:08] <hunger> Pygi: But then... if you got wlan you usually got broadband as well and can damn well grab the stuff of the net.
[11:08] <Pygi> pitti: as far as I can tell, wpasupplicant is not that big ... so squeeze it? ;)
[11:08] <fabbione> ogra: and i recalled some gnome-screensaver flickering issues
[11:08] <ogra> fabbione, and its reproducable in xscreensaver if you switch the visual for the screensaver from GL to default
[11:08] <Pygi> hunger: yes, but if it is in main, and we ship n-m, it'll be good to have it on the cd
[11:08] <Mithrandir> fabbione: I'm grabbing the xorg lock
[11:08] <Lure> BTW, what is Debian doing - depend or recommend?
[11:08] <pitti> Pygi: yeah, yeah, you folks should just say that we don't need langpacks :)
[11:08] <mvo> Lure: synaptic has a option for this (in preferences) 
[11:08] <fabbione> Mithrandir: sure
[11:08] <Pygi> pitti: nah, we need langpacks ;)
[11:08] <pitti> Pygi: (nm, we'll squeeze it in, I suppose)
[11:08] <infinity> Lure: Debian would almost certainly go with Recommends or Suggests, given that they're completely splitting the package to make it modular.
[11:08] <fabbione> ogra: ok.. you can reassign it back if you want
[11:08] <ogra> fabbione, so my question is, can it be related to the ati driver and the handling of visuals there ?
[11:09] <Pygi> pitti: yes, about nm ... but wpasupplicant...
[11:09] <infinity> Lure: They're splitting out all the VPN/PPTP stuff, etc.  Specifically so people can pick and choose.
[11:09] <hunger> Pygi: I do not think that it makes sense to have one but not the other.
[11:09] <pitti> Pygi: sorry, nm == nevermind 
[11:09] <fabbione> ogra: yes it could
[11:09] <ogra> hmm,k
[11:09] <Pygi> pitti: ah, ok ;) great :-D
[11:09] <ogra> its one of my little nightmare bugs :)
[11:09] <Kamion> pitti: somebody appears to have put wpasupplicant into the minimal seed, BTW, in case you hadn't noticed
[11:09] <simira> ogra: the flickering screensaver? Is that yours?
[11:09] <Lure> infinity: OK - I am all for recommend with your great explaination
[11:09] <Lure> ;-)
[11:09] <pitti> Kamion: minimal??? *gulp*
[11:10] <Pygi> pitti: I'll need to poke keybuk to make it recommended I belive, as I have no more powers over the package (or do I?), as Scott is official maintainer now
[11:10] <ogra> simira, yes
[11:10] <Kamion> pitti: I won't promote it until that's been decided on properly
[11:10] <pitti> Pygi: you have as long as it's still in universe
[11:10] <pitti> Kamion: it seems that after this discussion, ship seems to be the right place
[11:10] <Pygi> pitti: it has been promoted to main
[11:10] <Pygi> Kamion: shipping, making wpasupplicant recommeded
[11:10] <pitti> Kamion: I assume the plan is still to put n-m into ship?
[11:11] <Lure> infinity: you should, unless you have unsupported card (or badly behaving one like madwifi)
[11:11] <infinity> Lure: well, it's just about testing here.  I don't care about the security aspect.  I only have WEP enabled for testing purposes too.
[11:11] <infinity> Lure: I normally just run with MAC filters.  If people want to sniff my traffic or spoof a MAC, they're welcome to it.
[11:12] <Lure> infinity: ;-)
[11:12] <infinity> Lure: Anything I do that's "private" is encrypted in other ways anyway (ssh, pgp, etc)
[11:14] <Pygi> pitti: k, so we've settled that ^_^
[11:14] <pitti> yes, I think so
[11:14] <Pygi> anything else to settle regarding n-m? 
[11:14] <hunger> Pygi: knetworkmanager?
[11:15] <Pygi> hunger: we are still to see what is going to happen with knetworkmanager ... I  hope we can get it into main, but ...
[11:15] <Pygi> hunger: so KDE people can have it :-/
[11:17] <Pygi> pitti: how should we go with knetworkmanager? first inclusion into universe, then promotion to main?
[11:17] <Lure> hunger: knetworkmanager is waiting for NM-dev packages in order to be able to build it with VPN
[11:17] <pitti> Pygi: yes, please
[11:17] <Lure> hunger: then we need to get FF exception (as kNM was not in Dapper yet!)
[11:17] <Pygi> pitti: but I suppose we won't be able to ship that on kubuntu cd? 
[11:17] <pitti> Pygi: why not?
[11:18] <Pygi> pitti: well, the default "no" for place on cd ;)
[11:18] <Lure> Pygi: why not - kNM is simple code that could be accepted to main
[11:18] <Lure> Pygi: NM was the hard part
[11:18] <pitti> Pygi: right, that requires a beer or two for Riddell 
[11:18] <Pygi> pitti: told you ^_^
[11:18] <Pygi> Lure: no, the cd is full ... it is always full ^_^
[11:19] <Pygi> pitti: considering that we need to put wpasupplicant also on kubuntu cd :-/
[11:19] <pitti> the question is never whether we have space for something new -- it's always 'what do we kick in favor of this one?'
[11:19] <dholbach> Kamion: thanks for the UVF approval
[11:19] <Lure> Pygi: Kubuntu CD will have plenty of space if Ooo is replaced with KOffice (just joking ;-))
[11:19] <Pygi> Lure: joy
[11:19] <Pygi> pitti: yes, but we can't really kick something important :-/
[11:19] <Pygi> pitti: and what are we to kick from ubuntu cd because of wpasupplicant? :-/
[11:20] <pitti> Pygi: that's where the beer and Riddel come into play
[11:20] <pitti> and Riddell, too
[11:20] <Pygi> pitti: hm, ok, I guess you will talk to him ... or should I?
[11:21] <pitti> Pygi: I think you'd do better, I don't have a strong motivation for wpasupplicant :)
[11:21] <pitti> Pygi: and seb128 always hits me so hard if I say a K-word
[11:21] <Pygi> pitti: bah, me neither actually, but a lot of people want it ;)
[11:21] <Pygi> pitti: lol ;)
[11:21] <Pygi> pitti: what? Kubuntu? ;)
[11:21] <Lure> pitti: why would Riddell need to drop something for wpasupplicant - it is needed for Ubuntu
[11:22] <pitti> seb128: HE SAID IT! HE SAID IT!!!
[11:22] <Pygi> Lure: NO PLACE
[11:22] <Pygi> seb128: what? ;)
[11:22] <Lure> Riddell just need to find something for space for knetworkmanager...
[11:22] <Pygi> Lure: bah, leave it to me... I'll talk to him ^_^
[11:23] <Pygi> Lure: you just make sure Knetworkmanager hits the universe
[11:23] <ajmitch> simple, just put gnome on the cd instead
[11:23] <Pygi> pitti: why is the Kubuntu so important? ;)
[11:23] <Pygi> s/Kubuntu/Kubuntu word
[11:23] <seb128> pitti: what? That I'll kick you if you use a k-word? :p
[11:23] <pitti> Pygi: nevermind
[11:23] <Pygi> pitti: ah, ok :-/
[11:23] <pitti> Pygi: just bitching
[11:31] <siretart> oh, there is already a main inclusion report for wpasupplicant.. interesting..
[11:31] <mdke> sladen, volume hotkeys working nicely on my thinkpad, except the mute button mutes and doesn't remute. can I put that on the tpb bug, or shall I file a separate one? if a separate one, is it gnome related, or hotkey-setup related?
[11:31] <mdke> s/remute/unmute
[11:32] <Pygi> siretart: heh
[11:35] <sladen> mdke: the mute key never unmutes on thinkpads.  You press up/down to unmute
[11:35] <mdke> sladen, are you sure? I could have sworn I've always used it like that.
[11:36] <sladen> mdke: it's hotkey-setup, but it follows the design of the hardware (it's how ThinkPads have worked for since RMS had a PDP-11 in at his nursery school)
[11:36] <mdke> ok
[11:36] <seb128> Kamion: thank you for the libcairo UVF approval. Should I send ChangeLog with it instead of NEWS only next time?
[11:36] <infinity> mdke: On my thinkpad, mute's always been a one-way thing.
[11:37] <mdke> infinity, well, given that you have the same as me...
[11:37] <infinity> mdke: T43?
[11:37] <mdke> :)
[11:37] <mdke> yes
[11:37] <infinity> Yeah.  It's never un-muted. :)
[11:37] <infinity> Volume up to unmute.
[11:37] <mdke> ah ok
[11:37] <mdke> the gnome mute dialogue is incredibly confusing
[11:37] <sladen> mdke: how so?
[11:38] <seb128> mdke: you would like a striked speaker icon?
[11:38] <sladen> mdke: would it be better if it showed the volume level at zero when muted?
[11:38] <mdke> it doesn't have the red cross in it which the applet has, so it looks like it's telling you it's not muted
[11:38] <mdke> seb128, that's exactly what I'd like :)
[11:38] <sladen> seb128: I like the one at the moment.  What about the current icon with a small [x]  in the corner
[11:38] <seb128> mdke: there is some bugs and dup about it
[11:39] <mdke> seb128, cool. is it too late for gnome to fix it?
[11:39] <seb128> sladen: I'm fine with current one, but if somebody wants to send a patch using a different icon and if it looks nice I'm fine to use the patch
[11:39] <Kamion> Pygi: what makes you say that wpasupplicant has been promoted to main? (it hasn't)
[11:39] <Kamion> pitti: n-m ship> yes
[11:39] <seb128> mdke: probably for that cycle, UI freeze
[11:39] <mdke> hmm
[11:40] <Pygi> Kamion: yes, it still isn't in main ... but it will be  ^_^
[11:40] <mdke> seb128, in that case, a good alternative would be for it to show the volume level as zero, as sladen suggests. I think the best would be to use the same icon as for the applet though
[11:40] <seb128> we can change the icon
[11:40] <seb128> I might have a look on it later
[11:40] <Kamion> seb128: in general, yes, especially when mdz asks you for it (which I guess you missed) ;-)
[11:40] <seb128> all those are small details
[11:40] <Kamion> seb128: send NEWS as well if available, since it's usually a useful summary
[11:41] <mdke> seb128, that would be great
[11:41] <seb128> but we have a long list of small details, so not easy to take everything
[11:41] <Kamion> seb128: unfortunately NEWS in this case was not very useful really
[11:41] <seb128> Kamion: oh, he did? Oh, I took the question about 1.0.3
[11:42] <seb128> Kamion: I had a look on the ChangeLog before asking for the UVF but I was not sure if that was something too verbose to send or not. Noted for next one :)
[11:43] <infinity> Kamion: Do you know if there's been any movement on making the queue tool less hideously confusing?
[11:43] <Pygi> pitti: around?
[11:43] <infinity> Kamion: I did a binary NEW of libsvn-javahl/sparc earlier today, and was amazed at the hoops I had to jump through to figure out what was new, what priority it should be, etc, etc.
[11:43] <pitti> Pygi: yes
[11:43] <sladen> mdke: btw, when you press volume up, are the steps smaller than volume down?
[11:43] <Pygi> pitti: just talked to Riddell, he says we can squeeze it in 
[11:43] <mdke> sladen, yes
[11:44] <Pygi> pitti: altought I did somethin' silly first ;) lemme quote it for you...
[11:44] <Pygi> pitti: "Pygi first pays Riddell a bear or two then talks to him"
[11:44] <pitti> lol
[11:44] <Pygi> lol ;)
[11:44] <pitti> Pygi: most of the Ubuntu folks prefer a pony, btw
[11:45] <Pygi> pitti: lol ^_^
[11:45] <seb128> sladen: might be a feature
[11:45] <seb128> the steps not beeing the same both way
[11:45] <seb128> it allow you to move quite quickly one way
[11:45] <mdke> sladen, i quite like it, assuming that is the actual behaviour :)
[11:45] <seb128> and then to adjust
[11:45] <mdke> it's nice to move down quicker
[11:45] <infinity> sladen: I view that as a feature, since you often want it "quieter NOW, dear god!", but you want control when going up.
[11:46] <sladen> infinity: it's probably one of those real-world UI improvements that just never got done because normal users couldn't accept it
[11:47] <Pygi> _ion: bah ;)
[11:51] <Kamion> infinity: I keep bugging cprov, but he seems to think that coding style improvements are more important
[11:52] <Tm_T> _ion: 7join #animal-perversions eh?
[11:53] <_ion> tm_t: http://johan.kiviniemi.name/tmp/giraffe_licks_squirrel 
[11:56] <infinity> Kamion: Ahh.  Well, he's on VAC (marriage/honeymoon) now, so I guess we deal with what we have for a while.
[11:57] <pitti> infinity: oh, cprov is not there?
[11:57] <simira> who is cprov?
[11:57] <pitti> simira: our Soyuz god
[11:57] <infinity> pitti: He's either just leaving the sprint now/soon, or has already left.
[11:57] <pitti> ah, thanks
[11:58] <infinity> pitti: He gets married this weekend, so was cutting it a bit close. :)
[11:58] <simira> must be something going..
[11:59] <mwright1night> Is the Firefox maintainer about,  check out this bug: It affects all users outside of the USA...  https://launchpad.net/distros/ubuntu/+source/firefox/+bug/10910
[11:59] <Ubugtu> Malone bug 10910 in firefox mozilla-firefox "Default page size for printing is letter" [Normal,Unconfirmed]  
[12:00] <Kamion> infinity: wow, didn't know he was getting hitched
[12:00] <mwright1night> Default paper size is letter, AND the setting can't be changed in any way (only on a per print basis)
[12:00] <Kamion> infinity: bug 30933, incidentally
[12:00] <Ubugtu> Malone bug 30933 in launchpad-upload-and-queue "queue should show me which binaries are new" [Wishlist,Confirmed]  http://launchpad.net/bugs/30933
[12:00] <infinity> mwright1night: It's not pulling it from /etc/papersize, is it?
[12:00] <Kamion> (if you want to subscribe)
[12:01] <mwright1night> nup
[12:01] <infinity> Kamion: Thanks, done.
[12:01] <Kamion> infinity: also, that's weird, because I NEWed libsvn-javahl on the other architectures. It must have hit NEW at the point when the binaries I processed were in accepted, which seems to be where the race happens
[12:01] <infinity> mwright1night: So, that's correctly set to a4?
[12:01] <Tm_T> _ion: nam
[12:01] <Kamion> (empirically)
[12:01] <mwright1night> yep
[12:01] <infinity> Kamion: Yeah, all of soyuz appears to race on accepted.
[12:01] <mwright1night> This is an upstream bug, however in my terminal server environment is its in the top 4 worst bugs for end users
[12:01] <infinity> Kamion: (hence yesterday's fiasco)
[12:01] <Kamion> yeah
[12:02] <infinity> mwright1night: I don't suppose you can find it in upstream's bugzilla?
[12:02] <infinity> mwright1night: (No, I'm not the firefox dude, but I'd still be interested in adding more info to the bug)
[12:03] <mwright1night> yer I can
[12:03] <mwright1night> and the redhat bug
[12:03] <infinity> mwright1night: Excellent.
[12:03] <infinity> mwright1night: Hook 'em all up to the LP bug. :)
[12:03] <mwright1night> give me a minute, I upgraded my redhat server to FC5 where I keep my mail, FreeNX broke and now I cant' get my email
[12:04] <infinity> Oh, I didn't even look at the bug...
[12:04] <infinity> This is ancient, and has the mozilla bug in it already.
[12:04] <mwright1night> let me check if that's the right mozilla bug though
[12:04] <mwright1night> i'll confirm
[12:04] <mwright1night> I think it is
[12:05] <mwright1night> something needs to be done about it, I Had to replace 4 printers, to buy ones that had A4/letter auto override just to accomodate that
[12:05] <mwright1night> costs our not for profit organisation 15k AUD
[12:09] <mwright1night> so do you think it's an important bug?
[12:09] <mwright1night> to get resolved
[12:11] <mwright1night> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133658
[12:13] <infinity> mwright1night: You may want to bring iwj's attention to the bug.  It shouldn't actually take much patching to shoehorn the feature in there, assuming the mozilla suite only does paper size selection in one fairly isolated are in the codebase.
[12:14] <mwright1night> yes that is the correct upstream bug number, one of the distros needs to fix it then send it upstream, cause they don't care to fix it
[12:14] <mwright1night> if not geeks start to use this software, this is the kind of thing that makes the user experience really frustrating
[12:18] <infinity> Oh, fun.  network-manager build-deps on wpasupplicant, I didn't notice that.  So the promotion needs to happen regardless.
[12:22] <_ion> infinity: It shouldn't build-dep on wpasupplicant.
[12:23] <mwright1night> infinity: who is iwj?
[12:24] <ogra> mwright1night, Diziet
[12:24] <ogra> our firefox hero
[12:26] <_ion> From the package i have here: Build-Depends: automake1.9, debhelper (>= 4.1.0), patchutils (>= 0.2.25), intltool, libtool, libiw-dev (>= 27+28pre9), libdbus-glib-1-dev (>= 0.60), libglib2.0-dev, libhal-dev (>= 0.5.0), libgtk2.0-dev, libglade2-dev, libgconf2-dev, libgnome-keyring-dev, libnotify-dev (>= 0.3.0), libnl-dev, libgcrypt11-dev, libpanel-applet2-dev, libgnomeui-dev
[12:29] <mwright1night> ok I left him a proivate msage
[12:34] <infinity> _ion: keybuk's package clearly build-deps on it, cause my buildds all dep-waited the package. :)
[12:34] <infinity> And my regexes are never wrong!
[12:34] <_ion> Interesting.
[12:35] <_ion> Is keybuk's source package available from somewhere? I'd like to diff my source to it.
[12:35] <infinity> _ion: Yeah, the source should be in the archive.
[12:35] <infinity> Build-Depends: debhelper (>= 4.0.0), gnome-common, intltool, libgnome-keyring-dev, libdbus-glib-1-dev (>= 0.60), libiw-dev(>= 27+28pre9), libhal-dev, libgnomeui-dev, libpanel-applet2-dev, libglade2-dev, libgconf2-dev, docbook-to-man, libnl-dev, wpasupplicant
[12:36] <stub> Launchpad is going down in 25 minutes for updates. Downtime will be approx. 10 minutes. Wikis will be in read only mode during this time.
[12:38] <_ion> infinity: Seems like those dependencies were copied from some completely different package.
[12:38] <_ion> infinity: That package doesn't use e.g. docbook-to-man.
[12:38] <infinity> _ion: Probably.  He didn't use your package, just used some of your patches/changes, afaik.
[12:39] <_ion> infinity: I think one should be able to remove dockbook-to-man and wpasupplicant from the Build-Depends line without any problems.
[12:39] <infinity> The only thing in there is my WEP key... And the password protecting the WEP key is more secure than the key itself.
[12:40] <infinity> Which seems pointless.
[12:40] <_ion> :-)
[12:40] <infinity> I don't dig having to log in twice (effectively).
[12:40] <infinity> That's my only gripe with NM, really.
[12:41] <infinity> (Well, my only major gripe... Lots of minor ones)
[12:45] <infinity> Kinnison: Bah, like anyone reads the topic anyway.
[12:45] <infinity> Kinnison: (Guess how many broken initrds I get sent to me)
[12:45] <ogra> thats probably because they simply arent broken ?
[12:45] <ogra> :)
[12:46] <infinity> Nice theory, but I get enough complaints.
[12:46] <infinity> And I say "did you save me a copy, like the topic asks for?"
[12:46] <infinity> And they go "Oh, no, I didn't see that, I just dpkg-reconfigured and it works now"
[12:46] <infinity> And I die a little inside.
[12:47] <KaiL_> infinity, that's life - and the same effect, you can see in EVERY web-forum. There you'll read hundreds of complains, that something important doesn't work. But how many bugs marked "critical" exist?
[12:48] <ogra> evil users !
[12:48] <infinity> I'd love it if someone would go through the Ubuntu forums and try to file some bugs on behalf of people with weird problems.
[12:48] <ogra> letting you die ..
[12:48] <infinity> But it's not something I have the time for.
[12:49] <KaiL_> infinity, forget it - 99% of those problems are PEBKAC
[12:49] <infinity> The ubuntu-users mailing list is full of "this is horribly broken and must be fixed before release!!" stuff too, but no one on the list ever seems to suggest that the users in question should file a bug.
[12:49] <KaiL_> and the last 1% is so bad described, that you can't find out, what he means
[12:49] <infinity> KaiL_: Sure, many are, but some aren't.  And the non-problems still get lost, because we don't read the forums, cause we just plain don't have the time.
[12:50] <infinity> err, non-PEBKAC problems, that is.
[12:50] <KaiL_> so just fix those bugs, which find the way into LP :)
[12:50] <mdke> a bug filing team...
[12:50] <KaiL_> like the ~15 I reported last week (of which at least 5 are from crying friends..)
[01:32] <sivang> hrm, since last update *last night) my panles are complete mess, no ALT-TAB, and no workspace switching, any ideea ? :)
[01:32] <sivang> panles , even
[01:36] <Treenaks> panels, too :P
[01:43] <sivang> Treenaks: what's the idea ? :)
[01:43] <Treenaks> no idea
[01:43] <Treenaks> still works fine for me
[01:44] <sivang> what about keyboard setup, do you have ALT-TAB and ALT-F2 working as expected?
[01:44] <Treenaks> yes
[01:44] <Treenaks> (I updated last night, too)
[01:44] <Kamion> infinity: hmm, queue output just changed somewhat, I have a suspicion some of our problems may be answered
[01:48] <Kamion> at least, I see a star there, that might maybe disappear when a binary is already overridden, or something
[01:48] <Kamion> no examples of binary-new to check with at the moment, though
[01:48] <Kinnison> Kamion: have you done vim-ruby already?
[01:48] <infinity> Yeah, I see...
[01:48] <infinity> vim was ages ago.
[01:49] <Kinnison> well it was worth a thought
[01:49] <infinity> I could do a gratuitous upload and reject it. :)
[01:49] <Kamion> I've been trying to keep new pretty clear of late
[01:50] <infinity> I noticed that.
[01:51] <infinity> What's the deal on the ifolder/libflaim business in there?
[01:51] <infinity> Also, uhm, why is the newest not at the bottom anymore?
[01:51] <infinity> That seemed intuitive and Correct to me.
[01:52] <infinity> Kamion: Did you request that the queue sorting get inverted, or is this a bug?
[01:53] <Kamion> I didn't request it; presumably somebody thought it was a good idea ...
[01:53] <Kamion> I dunno, I can see arguments either way
[01:53] <infinity> Seems entirely backwards, since it's a CLI tool, you want the more recent stuff closer to your prompt.
[01:53] <infinity> I'd think.
[01:53] <Kamion> you could argue that older queue items ought not to be forgotten
[01:53] <Kamion> although on balance I did prefer the older order
[01:53] <infinity> They won't be forgotten, once you clear out the ones you really care about at the bottom. :)
[01:54] <Kamion> infinity: ifolder/libflaim are pending an e-mail conversation with Mez that I need to get back to
[01:54] <infinity> Ahh, check.
[01:54] <Kamion> infinity: it's a bit harder when you're dealing with a queue 70-odd items long, which it was when I first started poking at the Soyuz queue
[01:54] <infinity> Kinda hard to tell with so few things in the queue.
[01:54] <Kamion> 'queue -R breezy -Q unapproved info \*' is inverted, so I think it's consistent
[01:55] <infinity> Check.
[01:59] <mvo> Kamion: you want some discussion about debconf/gnome and the upgrade tool? what is your preferred time for this?
[02:07] <mvo> Riddell: I uploaded new app-install-data, it should be more complete now (fixed some bugs). I checked various kde apps and the icons are extracted so adept_installer should find them
[02:08] <Riddell> mvo: great, thanks, will take a look
[02:09] <mvo> Riddell: most kde icons seems to be xpm, no idea if that is good or bad (or dosn't matter)
[02:09] <mvo> Riddell: oh, and it's pretty big :)
[02:09] <Riddell> mvo: no kde icons are xpm
[02:10] <TheMuso> Mithrandir: ping
[02:10] <Kamion> mvo: now's fine, just want to know what the problem is
[02:10] <Mithrandir> TheMuso: pong
[02:10] <mvo> Kamion: i'm about to leave for lunch
[02:11] <Kamion> fine, after lunch is good too
[02:12] <Kamion> I'm here all day, thankyou, etc.
[02:12] <TheMuso> Mithrandir: http://www.themuso.id.au/ubuntu/casper -- An update to the accessibility script. Not much was trimmed, as most of the settings that are set in the profiles are not otherwise desired by other users if that makes sense. :)
[02:13] <TheMuso> Just passed a patch to dholbach to move important settings into the necessary packages.
[02:16] <_mvo_> Riddell: sure? http://paste.ubuntu-nl.org/10718 shows some in kreversi
[02:17] <_mvo_> Kamion: maybe after lunch? I'm about to leave for lunch
[02:17] <Kamion> _mvo_: fine
[02:19] <Riddell> mvo: the debian packages do still have some xpm icons, but the KDE icons are all PNG.  kreversi has hi128-app-kreversi.png ./usr/share/icons/hicolor/128x128/apps/kreversi.png
[02:22] <_mvo_> Riddell: hm, the extractor is not smart enough to decide which on to pick then and he preferes standard locations (/usr/share/pixmaps)
[02:23] <Riddell> /usr/share/pixmaps is obsolete, /usr/share/icons is the standard
[02:58] <ogra> seb128, thanks ! :)
[02:59] <seb128> ogra: you're welcome
[03:21] <mdke> sladen, the chap for whom the thinkpad hotkeys don't work on bug #341 says that he uses xfce, could this be the difference?
[03:21] <Ubugtu> Malone bug 341 in Ubuntu "tpb doesn't work" [Normal,Fix released]  http://launchpad.net/bugs/341
[03:31] <mjg59> mdke: xfce doesn't do visualisation of volume controls, I suspect
[03:34] <mdke> mjg59, i suspect so too. so it's a choice between using tpb (works with any desktop), and hotkey-setup (works with GNOME only)?
[03:34] <mjg59> Or xfce getting its act together
[03:34] <mjg59> tpb is not an acceptable general answer
[03:35] <mjg59> Any user who can use tpb can render the system unbootable
[03:35] <mdke> mjg59, i suppose there isn't any possibility of the hotkey-setup solution becoming desktop independent?
[03:36] <mjg59> It /is/ desktop independent
[03:36] <mjg59> It sends standard keycodes
[03:36] <siretart> mdke: you just need to configure your desktop to react on those keycodes
[03:36] <siretart> mdke: therefore hotkey-setup integrates more nicely than tpb
[03:37] <mdke> i see. well I'm happy anyway, because I use gnome :)
[03:39] <jsgotangco> too bad for others though
[03:40] <mjg59> (Well, they could, I don't know, fix the desktops...)
[03:40] <mdke> well, they haven't lost anything, because their desktop *never* did have visualisation of volume control
[03:41] <siretart> gnarf. stupid acx111 not being able to do wpa on their own :(
[03:42] <mdke> siretart, what acx111 have you got?
[03:43] <siretart> mdke: I'll look
[03:47] <siretart> mdke: Texas Instruments ACX100 PCI adapter
[03:47] <siretart> this is my brother's machine :/
[03:47] <mdke> i've got one of those. siretart, did it work out of the box?
[03:48] <mdke> although I think there are lots, with different firmware
[03:51] <mdke> seb128, do you know whether gnome-sudo has been replaced by another command in dapper?
[03:51] <Treenaks> gksudo?
[03:52] <mdke> could be
[03:53] <ogra> ogra@edubuntu:~$ apt-cache search gnome-sudo
[03:53] <ogra> gksu - graphical frontend to su
[03:53] <ogra> :)
[03:53] <mvo> Kamion: I think I found the cause of the debconf/gnome fontend problem, my bad
[03:54] <siretart> mdke: WEP worked for me out of the box, yes
[03:54] <mdke> ogra, it seems to have disappeared from gksu between breezy and dapper
[03:54] <mdke> siretart, cool
[03:54] <siretart> mdke: now I switched my home network to wpa, but now I read this: http://acx100.sourceforge.net/wiki/WPA
[03:54] <seb128> mdke: did we have a such command once?
[03:54] <mdke> seb128, in breezy
[03:54] <seb128> are you sure?
[03:54] <ogra> ogra@edubuntu:~$ apt-cache show gksu|grep Provides:
[03:54] <ogra> Provides: gnome-sudo
[03:55] <mdke> seb128, yeah, I'm on breezy now
[03:55] <siretart> hm. seem that I have to fiddle with ndiswrapper :(
[03:55] <seb128> mdke: dpkg -S `which gnome-sudo`
[03:55] <mdke> siretart, WEP has only supported for about 6 months :)
[03:55] <seb128> ogra: Provides is for packages not command
[03:55] <ogra> seb128, i know
[03:55] <mdke> seb128, gksu: /usr/bin/gnome-sudo
[03:55] <seb128> mdke: ls -l /usr/bin/gnome-sudo ?
[03:56] <seb128> (maybe it used to ship a compatibility command)
[03:56] <ogra> but there was a package called gnome-sudo once that provided /usr/bin/gnome-sudo
[03:56] <mdke> seb128, -rwxr-xr-x  1 root root 32 2005-10-18 06:09 /usr/bin/gnome-sudo
[03:56] <seb128> mdke: cat /usr/bin/gnome-sudo
[03:56] <siretart> mdke: I'd rather say for a couple of GB of traffic
[03:56] <mdke> seb128, yes, it's gksudo :)
[03:56] <mdke> thanks
[03:56] <seb128> that's weird that you ever suggested that one
[03:57] <seb128> we use gksu for everything since warty :)
[03:57] <seb128> gksu or gksudo
[03:57] <mdke> we inherited it from the unofficial ubuntuguide, I think
[03:57] <ogra> but there was a gnome-sudo package pre warty
[03:57] <mdke> I'll update it
[03:57] <mjg59> siretart: That's the normal state of WPA support
[03:57] <seb128> ogra: that's not the point, stop arguing on that
[03:57] <mjg59> siretart: We do it all in userspace
[03:57] <ogra> i guess it got merged for backwards compatibility
[03:57] <seb128> mdke: thank you
[03:58] <seb128> ogra: we are not discussing why it got merged, but why people were still using a stuff deprecated for ages now
[03:58] <ogra> ah
[03:58] <mdke> seb128, thanks
[03:58] <ogra> sorry then 
[03:58] <siretart> mjg59: err, right, but the kernel has to provide some extensions for wpa support. 
[03:59] <mjg59> siretart: Yes. And they claim that the acx driver does
[03:59] <siretart> mjg59: who claims that?
[03:59] <siretart> http://acx100.sourceforge.net/wiki/WPA claims that you need ndiswrapper for that :(
[03:59] <mjg59> http://acx100.sourceforge.net/wiki/WPA implies that the necessary wireless extensions are in the driver (though untested)
[04:00] <siretart> mjg59: if that means that wpasupplicant needs another driver backend, than thats not written (yet)
[04:00] <Treenaks> siretart: they're unifying WPA upstream
[04:01] <Treenaks> siretart: into the 'standard' wireless extensions
[04:01] <siretart> Treenaks: they tell driver developers to implement WE19, I know
[04:01] <Treenaks> siretart: so you don't need 600 backend modules for wpasupplicant anymore
[04:01] <mjg59> siretart: No, it doesn't mean that
[04:01] <siretart> Treenaks: AFAIK only ipw2200 (and perhaps ipw2100) implement that sufficiently :(
[04:01] <mdke> seb128, by the way, should a tip on how to open files as root in nautilus even be in the guide, in your opinion? does it carry security problems?
[04:01] <Treenaks> siretart: and prism54
[04:02] <mjg59> It's actually pretty trivial to add the support
[04:02] <siretart> mjg59: I just tried breezy/acx100.ko with wpasupplicant_0.4.8 - no luck with any driver backends
[04:03] <mjg59> siretart: The only one which would have any chance of working is wext. If that doesn't work, it's a failing in the driver and we can fix that
[04:03] <siretart> Treenaks: I'd be happy if madwifi and acx would implement WE19 soon. but I don't see that happen in short time
[04:03] <Treenaks> siretart: Why not?
[04:03] <siretart> Treenaks: madwifi upstream doesn't consider WE19 important
[04:03] <mjg59> madwifi is probably harder due to it being made out of string
[04:03] <siretart> mjg59: so I shall try upgrading to dapper and see if wext works there?
[04:04] <siretart> I intended to do that tomorrow anyway
[04:04] <mjg59> siretart: It's worth a go. If it still doesn't work, then file a bug.
[04:05] <siretart> mjg59: ok. will do
[04:08] <infinity> madwifi upstream actually seems to have become more receptive to WEXT in the last week or two.
[04:08] <infinity> They've been asking for specs and pointers on how to support the current API.
[04:09] <infinity> (Which will most likely just end up as wrapper around their own interface for now, but that's fine)
[04:09] <Treenaks> infinity: wow.. madwifi devs, listening to demands?
[04:10] <mdke> what do other people think? is it a bad idea to document a nautilus script which permits you to open files as root from the file manager? if so, what are the hazards, perhaps we can include an appropriate warning
[04:11] <neuralis> mdke: what's the use case?
[04:11] <mdke> neuralis, browse to /etc, right click fstab, select Scripts -> Open as root
[04:11] <mdke> for example
[04:12] <neuralis> mdke: it should say 'open as administator', but other than that, there's no real hazard. you're not doing anything that a user can't already do via sudo.
[04:12] <neuralis> mdke: no such action should exist for 'execute', though. that'd be evil.
[04:13] <mdke> it uses gnome-open
[04:13] <mdke> good point on the s/root/administrator
[04:14] <mdke> neuralis, does gnome-open execute stuff?
[04:15] <neuralis> mdke: let me check.
[04:16] <siretart> infinity: do they plan that wrapper for madwifi-ng only or for madwifi-old as well?
[04:16] <neuralis> mdke: "Error showing url: There is no default action associated with this location."
[04:16] <neuralis> mdke: that's for a binary, so it appears not.
[04:17] <mdke> neuralis, ok, I'll include a health warning anyway
[04:18] <neuralis> mdke: another warning on top of gksudo asking for the root password seems a bit overbearing.
[04:19] <mdke> neuralis, just a warning in the documentation, not in the script
[04:19] <neuralis> mdke: ah, okay.
[04:19] <infinity> siretart: Only -ng, the -old branch hasn't had a commit for a very long time, it's just there so people have something to use while -ng is broken.
[04:20] <siretart> I see
[04:25] <seb128> mdke: I don't think that explaining people how to do that if they want to do it is an issue, no
[04:25] <mako> Gwynn: yes.. i'm available
[04:28] <mdke> seb128, cool. thanks
[04:36] <Kamion> mvo: oh, ok, cool, what was it? I asked partly because I know there was a libglib-perl/libgtk-perl issue at one point in dapper, but it should be fixed now
[04:38] <mvo> Kamion: hm, i'm still investigating. it looks like a issue with the environment and the XAUTHORITY
[04:41] <Riddell> infinity: kdenetwork is not compiling on those platforms because it can't find /var/run/utmp, any idea where utmp might have gone?
[04:42] <infinity> Not required to be there?
[04:42] <infinity> It's not in my chroots either, hence why I could reproduce it.
[04:43] <infinity> And I didn't do anything fancy to "clean" my local chroots.
[05:00] <doko> pitti: please can you move the locale-gen calls from the -pack into the -support packages?
[05:01] <pitti> doko: hm, not move, but I can additionally do them in -support
[05:03] <mvo> is the live-cd of today working? it drops me into a busybox here
[05:03] <doko> pitti: fine with me
[05:03] <infinity> pitti: How do you propose I get ubuntu-live installable on hppa?... Should I just unseed langsupport-* from hppa/live, or can you think of something more clever?
[05:04] <infinity> pitti: (Due to langsupprt depending on openoffice packs which depend on openoffice..)
[05:04] <pitti> infinity: which packages are uninstallable in particular?
[05:04] <pitti> ah
[05:04] <pitti> infinity: as a quick fix, unseeding certainly works
[05:04] <pitti> infinity: alternatively I change the dependencies to be [i386 powerpc amd64]  or so
[05:05] <infinity> Alternately, it might work if the openoffice packs didn't depend on openoffice, but that only works if they can install with it (can they?)
[05:05] <Kamion> infinity: that indicates that netboot will probably be broken though
[05:05] <Kamion> I'd almost rather we didn't paper over that ...
[05:05] <infinity> pitti: If they're arch:all packages, you can't do that.  You can't use [arch]  in depends, only build-deps.
[05:05] <pitti> infinity: oops, right
[05:05] <Kamion> oh, live, I guess netboot doesn't matter
[05:06] <pitti> infinity: hm, once upon a time, the ooo langpacks depended on openoffice.org | language-support-XX
[05:06] <pitti> doko: ^ that's not the case any more?
[05:06] <infinity> doko: Do the openoffice packs have to depend on openoffice, or is that just there to get the version right?  (which could be done with a set of conflicts instead)
[05:07] <infinity> I think that's the only real thing blocking me from turning on livecds for hppa again...
[05:08] <infinity> So, if we can sort it somehow, that would be awesome.
[05:08] <infinity> Even if it means tying up an i386 buildd for another 12 hours on an OOo-l10n build. :)
[05:09] <doko> infinity: parse error ...
[05:11] <infinity> Err, wait.  The deps are correct?
[05:12] <infinity> Let me hop in a chroot so I can argue with this britney output. :)
[05:14] <infinity> Ah-ha.
[05:15] <infinity> doko / pitti: It's not the langpacks, it's the thesaurus... openoffice.org-thesaurus-en-us depends on openoffice.org-core, and you've added the thesaurus to language-support-en.
[05:18] <pitti> infinity: hm, then maybe the same alternative dependency should be applied to the thesauri?
[05:19] <infinity> doko: Same with openoffice.org-hyphenation-de, it requires openoffice to be installed.
[05:19] <infinity> Yeah, I expect the thesauri and heyphenation packages should get the same treatment the langpacks got.
[05:21] <infinity> Luckily, none of them require an OOo-l10n rebuild.
[05:21] <infinity> The thesauruses and hyphenation stuff all come from a bunch of smaller packages...
[05:21] <doko> infinity: ok
[05:22] <infinity> doko: You okay with applying that hack to those?
[05:22] <doko> sure
[05:22] <infinity> They don't break without OOo installed, I hope?  (ie: postinsts fail, etc)
[05:23] <pitti> at least for the similar firefox hack I had to add an if [ -x ... ]  to the postinst/prerm
[05:23] <infinity> Does firefox still use evil update-chrome stuff?
[05:23] <pitti> infinity: nope
[05:27] <Diziet> infinity: I give up.  Which package do I have to dpkg -i to reproduce https://launchpad.net/distros/ubuntu/+source/defoma/+bug/6614 ?
[05:27] <Ubugtu> Malone bug 6614 in gs-common "Use of uninitialized value in print at /var/lib/defoma/scripts/gs.defoma line 108" [Normal,Confirmed]  
[05:27] <ogra> Diziet, all font packages ? 
[05:27] <ogra> Diziet, i see it on every flight install for every font package
[05:28] <Diziet> I just installed (eg) gsfonts-x11_0.17ubuntu3_all.deb ttf-arabeyes_1.1-4_all.deb x-ttcidfont-conf_20ubuntu1_all.deb and a couple of others.
[05:28] <Diziet> I see   Can't exec "locale": No such file or directory at /usr/share/perl5/Debconf/Encoding.pm line 16.
[05:28] <Diziet> Use of uninitialized value in scalar chomp at /usr/share/perl5/Debconf/Encoding.pm line 17.
[05:28] <Diziet> But that's something different.
[05:28] <ogra> yeah
[05:28] <ogra> strange
[05:29] <infinity> Diziet: Grab an ISO and do a fresh test install?  I'm pretty sure the bug didn't just recently go away.
[05:29] <ogra> i'm 100% sure it was there in flight 5
[05:30] <Diziet> test install> I was hoping for a shortcut :-).  Fair enough.
[05:30] <Diziet> Do I have to select CJK or something ?
[05:31] <ogra> it happens for me in either english (uk/us doesnt matter) or german installs
[05:31] <infinity> Diziet: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325598 tries to explain why it may only happen on initial install.
[05:31] <Ubugtu> Debian bug 325598 in gs-common "Subject: gs-common: uninitialized value in print in /var/lib/defoma/scripts/gs.defoma" [Normal,Open]  
[05:31] <Diziet> Ooo.
[05:32] <infinity> Diziet: (note that the Debian bugs are linked in a portlet on the side of the Malone bug)
[05:32] <Diziet> Oh, so they are.  I always ignore all of that clutter ...
[05:33] <infinity> Yeah, that particular feature could be made more prominent.  I'd never look for it if I didn't already know there were linked bugs.
[05:33] <ogra> at least it moved to the left and you can actually click it :)
[05:35] <infinity> Oh, look.  hoary-updates appears to work.  Snazzy.
[05:56] <j^> seb128 you said you might accept a patch for the osd volume icons, i attched one to use the stock icons from the current theme to launchpad 20302
[05:56] <seb128> j^: thank you, I'll have a look on that later :)
[05:58] <mdke> j^, rock! hope that gets in
[06:02] <pitti> Mithrandir, Kamion: yay, this is the first time I went through the espresso steps without any bug :) (on ppc)
[06:02] <pitti> good work!
[06:03] <pitti> ... says pitti and finds the last step crashing
[06:03] <seb128> lol
[06:09] <mvo> Kamion: woah, that took ages, the reason for the debconf problem in the upgrade tools seems to be a bug in gksudo that made the XAUTHORITY file (gksudo makes a private copy) cleaned up too early so the gnome frontend wasn't able to initiallize
[06:09] <mvo> pitti: what image did you used? I had no luck with the current daily
[06:09] <pitti> mvo: today's ppc daily
[06:17] <pitti> mvo: oh, I used the live image, not the install (I'm Kamion's worst nightmare wrt. espresso testing)
[06:19] <Diziet> ogra/infinity: Well, I had a Flight 1 CD.  After installation /var/log/installer/messages has no complaints about gs.defoma.
[06:21] <Diziet> Ah!  I've reproduced it by reinstalling gs-common.
[06:24] <sladen> mdke: oh, *xubuntu*... righto.  *ponder, ponder*
[06:30] <Lure> sladen: seen you mentioned broken ACPI for HP/Compaq - is this what broke hibernate on my HP nw8240
[06:34] <sladen> Lure: maybe, when did it break for you?  We might be able to track down the kernel-change/etc that did it
[06:35] <Lure> kernel -18, I suppose - see bug 34617
[06:35] <Ubugtu> Malone bug 34617 in linux-source-2.6.15 linux-image-2.6.15-18-386 "hibernate broken on HP nw8240 with 2.6.15-18" [Normal,Unconfirmed]  http://launchpad.net/bugs/34617
[06:36] <Lure> I also had problems with daily install (not sure if related) - bug 34586
[06:36] <Ubugtu> Malone bug 34586 in Ubuntu "Kubuntu Dapper 20060312 cannot install on HP nw8240" [Major,Needs info]  http://launchpad.net/bugs/34586
[06:36] <Lure> I downloading Kubuntu Flight5 now to see if I can install
[06:42] <Kamion> pitti: hmm, talk about a non-informative traceback :(
[06:43] <Kamion> I suppose it might be fixed by the various changes in that area I've been doing today, but sadly I can't say for sure
[06:43] <suck> hi.how are u?
[06:46] <mjg59> sladen: Why did you just mark 34617 a dupe of 34586?
[06:47] <JasonF> I just found a horrible regression in Xorg 8 that you guys might want to be aware of. I filed an ubuntu bug here https://launchpad.net/distros/ubuntu/+source/xorg/+bug/36461 and the fdo bug is here 
[06:47] <Ubugtu> Malone bug 36461 in xorg "XOrg 8 dualhead regression" [Normal,Unconfirmed]  
[06:47] <JasonF> https://bugs.freedesktop.org/show_bug.cgi?id=2597
[06:47] <Ubugtu> Freedesktop bug 2597 in Server/general "Dual Head broken" [Major,Reopened]  
[06:47] <sladen> mjg59: because the root-cause is the same.  ACPI being bust on HP's...
[06:48] <infinity> JasonF: Xorg 8?
[06:48] <infinity> JasonF: We're only shipping 7.0.. :)
[06:48] <mjg59> sladen: Firstly, it's not - I have a 6220 here (same platform) that's working fine
[06:48] <mjg59> sladen: Secondly, hibernation doesn't use any ACPI
[06:48] <JasonF> er
[06:49] <JasonF> infinity: version may be wrong, but the bug is in the version you ship, heh
[06:53] <Diziet> defoma is completely insane inside !
[06:54] <Robot101> its hardly sensible outside either... :)
[06:54] <infinity> Diziet: No shit. :)
[06:54] <ogra> lol
[06:57] <carlos> Riddell: hi, so, are you going to upload a kde-i18n-* update today?
[07:05] <sladen> mjg59: what's the best soft-keys daemon to suggest to the Xubuntu lot so that soft volume-keys work for them?
[07:05] <mjg59> sladen: No idea, I'm afraid
[07:05] <mjg59> acme, perhaps?
[07:20] <ogra> bcm43xx-fwcutter :)
[07:23] <Kamion> been meaning to do that for a while
[07:23] <ogra> i just compiled it myself again today and podered to do it ... pitti as well :)
[07:46] <doko> mvo: ping
[07:51] <mvo> doko: pong
[07:54] <Lure> just released xserver-xorg_7.0.0-0ubuntu24_all.deb seems to have bug in preconfigure script:
[07:54] <Lure>  /tmp/xserver-xorg.config.122781: line 957: syntax error near unexpected token `esac'
[07:57] <KaiL_> somebody killed lists.ubuntu.com?
[07:58] <Burgwork> KaiL_, appears all of ubuntu.com is down
[07:58] <KaiL_> at least the package server just came back to life ;)
[07:59] <KaiL_> ...or not..
[07:59] <KaiL_> they need ages to connect, but then everything works
[07:59] <doko> mvo: did you look at the font in multiverse (moved it to universe)?
[08:00] <mvo> doko: ttf-gentium? or some other font(s)?
[08:00] <doko> yes
[08:01] <mvo> doko: I'm in contact with the upstream person, it seems to be good quality, especially for printing
[08:01] <mvo> doko: why? 
[08:01] <mvo> doko: it will be part of ubuntu-desktop soon, it covers a big unicode range
[08:01] <doko> mvo: cool, just for preparing OOo ...
[08:02] <mvo> doko: what kind of stuff needs to be prepared?
[08:02] <mvo> doko: I'll add something to fontconfig for gentium too
[08:02] <doko> mvo: default font selection for docs, etc
[08:02] <mvo> ah, ok
[08:15] <lemsx1> /var/lib/dpkg/tmp.ci/config: line 957: syntax error near unexpected token `esac'dpkg: error processing /var/cache/apt/archives/xserver-xorg_7.0.0-0ubuntu24_all.deb (--unpack):
[08:15] <lemsx1>  subprocess pre-installation script returned error exit status 2
[08:35] <dholbach> have a nice evening
[08:35] <bddebian> GNight dholbach
[08:35] <dholbach> night bddebian
[08:37] <LaserJock> cya dholbach 
[08:37] <dholbach> bye guys :)
[08:44] <zyga> anyone? xserver-xorg has a syntax error in postinst script
[08:44] <slomo_> zyga: was fixed some seconds ago by infinity 
[08:44] <zyga> 7.0.0-0ubuntu23
[08:44] <zyga> oh
[08:44] <zyga> thnx
[08:44] <slomo_> zenrox: -0ubuntu25
[08:45] <zyga> hum I got -0ubuntu24
[08:45] <Kamion> dude, stuff takes a while to build.
[08:45] <zyga> Kamion: right, I'm sorry
[08:47] <sladen> is Release signing bust?  Has a warning about every package now being untrusted
[08:49] <infinity> Kamion: Two people filed it in Malone too.
[08:49] <zyga> Kamion: I ought to have checked the bugtracker 
[08:50] <infinity> Kamion: And a fantastic blind-leading-the-blind thread on the forums.  "Did you try 'apt-get install xserver-xorg' instead of 'apt-get dist-upgrade'?... Does that work any better?"
[08:51] <infinity> "Yes, that magically puts bash in 'ignore typos' mode..."
[08:51] <mdke> i would have thought that these small bugs are sometimes more easily fixed by someone reading the typo on irc and fixing it, rather than having to bother opening/closing bugs
[08:51] <mdke> i spose someone will always open the bug tho
[08:52] <Kamion> which means that every developer reading IRC has to go "ooh, I wonder if somebody's fixed this yet", download the source packages etc., before realising that it's already fixed
[08:52] <infinity> mdke: I fixed it because I spotted someone popping on IRC and pasting it... Of course, I got the bug in my INBOX about 2 minutes AFTER I fixed it, so that would have worked just as well.
[08:52] <Kamion> bugs are good for tracking what's happened *as well* as the problem. :)
[08:53] <mdke> Kamion, not every developer, just infinity
[08:53] <zyga> OTOH fixing bugs this way gives you developer connection :-)
[08:53] <Kamion> mdke: how do you know?
[08:53] <infinity> mdke: No, I'm sure I'm not the only one who saw the report, went to look at -changes, saw no recent upload fixing it, then went to fix it.
[08:54] <Kamion> I can prove you're wrong because I did the above ...
[08:54] <infinity> mdke: The fact that my upload was ther first in just proves I have a local mirror and I type quickly.
[08:54] <mdke> was just a joke
[08:54] <mdke> remember what you said earlier about last-touched-it maintenance
[08:54] <infinity> TILM for that bug passes to Mithrandir, but I don't think he's around right now.
[08:55] <Kamion> I think the above is *why* infinity suffers from TILM so badly. :) (or would, if he let himself)
[08:55] <mdke>  [08:08:01]  < infinity> If I suffered from touched-it-last maintenance, I'd maintain the whole dist by now.
[08:58] <infinity> I suppose others are working, while I'm just idling at 7am and pretending to sleep. :)
[09:00] <mdke> night
[09:01] <KaiL> hmm, scrollkeeper-update produces an error...
[09:01] <KaiL> /usr/share/omf/serverguide/serverguide-C.omf:23: parser error : Entity 'distro-rev' not defined
[09:01] <KaiL>     <description>This document is a Ubuntu &distro-rev; Server Guide. It
[09:01] <KaiL> strange: this only happenes here (?!?), not on my laptop
[09:01] <mdke> KaiL, can you file a bug on ubuntu-docs please
[09:02] <mdke> oh actually, don't bother
[09:02] <mdke> i know it
[09:02] <KaiL> mdke, I'd like to find at least a second system for that - I had some hd-issues here recently
[09:02] <mdke> KaiL, no, i see the bug
[09:03] <KaiL> even better
[09:04] <mdke> KaiL, nice catch, thanks
[09:05] <KaiL> well, it results in having no help here :/
[09:05] <mdke> oh crap
[09:05] <zyga> oh, this reminds me of something
[09:05] <KaiL> uhm...
[09:05] <KaiL> that wasn't all :/
[09:05] <zyga> there are lots of references to undefined variables or something similar during deforma script runs
[09:05] <mdke> KaiL, paste them
[09:06] <KaiL> no more errors on scrollkeeper-update
[09:06] <KaiL> but yelp stays empty
[09:06] <mdke> KaiL, but the guy who does ubuntu-docs uploads isn't around so the fix i've done won't get uploaded until monday
[09:06] <KaiL> any other script/app needed to be run to get yelp back to work?
[09:07] <mdke> no, scrollkeeper-update
[09:07] <mdke> sorry about that, I'll try and make sure that gets tested before each upload in the future
[09:08] <mdke> if you want to fix it, edit the file and remove the &distro-rev; expression
[09:08] <KaiL> I/O warning : failed to load external entity "Cannot write to log file: /var/log/scrollkeeper.log : Permission denied"
[09:08] <KaiL> that's what I did, so scrollkeeper-update runs
[09:09] <KaiL> but yelp starts with this
[09:09] <mdke> do sudo scrollkeeper-rebuilddb
[09:10] <KaiL> I/O warning : failed to load external entity "/usr/share/ubuntu-docs/common/authors/ubuntu-documentation-project.xml"
[09:10] <KaiL> three times - but works
[09:11] <mdke> ok, I'll fix that too
[09:12] <KaiL> is this rebould-db automatically run from time to time? would be nice, if it runs at least once on the update
[09:13] <mdke> monthly
[09:13] <mdke> but it runs when you install ubuntu-docs too, I think
[09:14] <KaiL> doesn't look like - neigher that nor the normal scrollkeeper-update
[09:14] <KaiL> rebuild-db takes VERY lonk on slow computers :/
[09:23] <KaiL> now I guess, we have the next bug :)
[09:25] <KaiL> on one laptop here, I only ran scrollkeeper-rebuilddb, and did NOT fix the &distro-rev; before... and now yelp works
[09:25] <KaiL> looks like rebuilddb is never run
[09:26] <mdke> it's in cron.monthly, I think
[09:26] <sobersabre> guys. I have heard of 'breezy security issue'. 
[09:27] <sobersabre> that /var/log/installer/cde<something> contains initial passwords... I couldn't verify it.
[09:27] <Amaranth> it's fixed in the latest isos
[09:27] <mdke> sobersabre, that was fixed a while ago
[09:27] <Amaranth> not fixed on any shipit cds though
[09:28] <setuid> Seems the dapper kernels get Palm devices completely wrong at connect time, for the first time ever (I'm the pilot-link maintainer, and this is the first time in hundreds of thousands of connection attempts from thousands of users, that I've ever seen this) 
[09:28] <Amaranth> but as soon as you install you'll be notified of security updates and one of those is the fix
[09:28] <sobersabre> ok, but I used not the latest breezy when installed it. and I should've been hit... but I haven't... I didn't enable root on install or something...
[09:28] <KaiL> mdke, looks ok there - but isn't run after OS installation?
[09:29] <mdke> KaiL, i dunno, it's run when it has to be I suppose
[09:29] <Amaranth> sobersabre: As I said, if you have security updates installed the problem is fixed.
[09:29] <sobersabre> you mean one of the updates cleaned up the mess ?
[09:29] <Amaranth> yes
[09:29] <sobersabre> how do you do something like this in a deb ? write arbitrary script and package it as a deb ?
[09:30] <KaiL> mdke, well, at least, if you installed with flight4, you need to wait one month to have yelp running then :/
[09:30] <sobersabre> it needs not to exist afterwards...
[09:30] <mdke> KaiL, that's why we try to fix bugs before releasing
[09:30] <sobersabre> so you somehow need to remove it then...
[09:31] <KaiL> sobersabre, updated tool, which doesn't produce this error again AND remove that problem :)
[09:31] <sobersabre> KaiL the problem was that some installer remain contained the cleartext data.
[09:31] <sobersabre> so ... what does your sentence state  ? 
[09:32] <mdke> sobersabre, ok, relax please. It's fixed, let's move on.
[09:32] <sobersabre> OK... I need to rtfm about packaging... mdke you could use that too ;-)
[09:33] <sobersabre> oh! I came for other purpose.
[09:34] <sobersabre> I have a C q. can somebody maybe tell me: can I write something like #ifdef (X && Y) ?
[09:37] <infinity> Not if you want portable code.
[09:37] <infinity> #ifdef X
[09:37] <infinity> #ifdef Y
[09:37] <infinity> do stuff
[09:38] <bddebian>  Or #if defined(x) && defined(y) I think
[09:38] <infinity> #endif
[09:38] <infinity> #endif
[09:38] <sobersabre> I got that from ##c now.. thanks! :)
[09:38] <Amaranth> what compilers work/don't work with #ifdef (X && Y)?
[09:38] <sobersabre> Amaranth gcc -ansi -pedantic doesn't
[09:38] <sobersabre> :)
[09:38] <sobersabre> byebye
[09:38] <Amaranth> ahh
[10:04] <nysosym> hi there :)
[10:05] <nysosym> is a changelog for every day updates available?
[10:39] <chris_> !seen \sh
[10:40] <chris_> anyone know anything about \sh?
[10:41] <neuralis> chris_: he was on planet recently, things didn't sound very well
[10:41] <Burgwork> neuralis, how goes life for you?
[10:42] <chris_> neuralis: well, i read his blog.. i'm confused.. i worry about him ;\
[10:43] <chris_> do you know anything more?
[10:43] <neuralis> Burgwork: been pretty ill for about two weeks, but well otherwise. 10 days of vacations starting today.
[10:43] <neuralis> Burgwork: you?
[10:44] <Burgwork> pretty good. Made my first sale yesterday, which is a major event (6 months of work, paying off)
[10:44] <neuralis> chris_: unfortunately, no. i hope he's alright, though.
[10:44] <neuralis> Burgwork: congrats, mate
[10:44] <chris_> okay, I still hope, that we hear some from him..
[10:45] <chris_> will still read the blog
[10:45] <chris_> thx and bye
[10:45] <Burgwork> neuralis, sometimes I wish I worked in a place that had more frequent sales
[10:46] <neuralis> Burgwork: i can understand that. it's exactly the same with working on all long projects -- frequent microsuccesses (milestones, etc) make everyone a lot happier
[10:48] <Burgwork> neuralis, what about you? you haven't been around here very much
[10:50] <neuralis> Burgwork: i've been extremely busy with research, some work on the personal genome project (http://pgen.us) and recently one laptop per child
[10:52] <Burgwork> what are you doing for olpc?
[10:54] <neuralis> Burgwork: pushing python :) 
[10:55] <neuralis> Burgwork: more seriously, advising them on some of the system management aspects
[10:55] <Lure> Pygi: no Keybuk
[10:55] <Pygi> Lure: ah,kk
[11:03] <ptlo> oo, neuralis :)
[11:04] <neuralis> ptlo: long time no talk, still haven't gotten around to replying to your mail
[11:10] <KaiL> *grbel*
[11:11] <KaiL> *extrem doof guck*
[11:13] <KaiL> hmm, nu geht wieder alles
[11:13] <KaiL> auch gut
[11:14] <KaiL> ups, wrong window :)
[11:16] <CarlFK> Kamion: (or anyone that wants to see)  drive by bug report: daily setup errored installing kernel - I am running out, back in a few hours  - log files: http://dev.personnelware.com/carl/temp/Mar24/c/
[11:19] <infinity> CarlFK: 403 on syslog.
[11:20] <lamont> mvo: update-manager needs a versioned depends or two
[11:20] <lamont> ImportError: /usr/lib/libcairo.so.2: undefined symbol: FT_GlyphSlot_Embolden
[11:20] <lamont> hrm... or is that libcairo....
[11:20] <zyga> mvo: ping^^^
[11:20] <infinity> That's cairo having broken depends.
[11:21] <zyga> lamont: oh, sorry - didn't notice 'mvo' in there
[11:21] <lamont> zyga: np
[11:29] <_ion> Morning.
[11:38] <Amaranth> network-manager seems to be failing on wpasupplicant not being in main
[11:38] <infinity> Yes, I know.
[11:38] <Kamion> 20:27 < Amaranth> it's fixed in the latest isos
[11:38] <Kamion> Amaranth: please, please, please don't say that until you *know*
[11:38] <Amaranth> Kamion: It's not?
[11:38] <Kamion> Amaranth: we haven't done the ISO update yet, no
[11:39] <Kamion> one is planned
[11:39] <Amaranth> Kamion: Err, everyone I asked said it was.
[11:39] <Kamion> everyone you asked was wrong, I'm afraid
[11:39] <_ion> Have the n-m build-deps been fixed yet?
[11:39] <Kamion> if you install breezy and upgrade from security updates, you're fine
[11:39] <Kamion> but no updated ISOs have been made available
[11:39] <Amaranth> _ion: I just commented on that
[11:39] <infinity> _ion: Nope, bug keybuk.  I'm not going to touch until until I know if he had a valid reason for doing it that way.
[11:40] <Kamion> I hope to do it next week
[11:40] <Amaranth> doesn't pitti have to approve main inclusions?
[11:40] <_ion> amaranth: Yes, but wpasupplicant shouldn't be needed at all in the build-deps.
[11:40] <infinity> He's already approved wpasupplicant, but we haven't promoted it yet.
[11:40] <Amaranth> ah
[11:41] <Amaranth> well, anyone impatient can use apt-get source to build it themselves
[11:41] <Kamion> wpasupplicant drags in qt4 as well and I'm kinda reluctant to promote
[11:41] <infinity> Oh, you're kidding.
[11:41] <Kamion> see anastacia ...
[11:41] <infinity> Well, that's going to beed to be fixed, then.
[11:41] <infinity> need, too.
[11:41] <Amaranth> wha?
[11:42] <Amaranth> crap, i hope i didn't just install qt4
[11:42] <infinity> ;)
[11:42] <Amaranth> night kamion
[11:44] <Amaranth> it doesn't seem to depend on qt4 here
[11:45] <infinity> No, but wpagui does, which comes from the same source package.
[11:45] <infinity> So promoting the source to main means promoting libqt4-dev to main.
[11:46] <infinity> Which so ain't gonna happen on my watch either.  I'm with Kamion.
[11:47] <Amaranth> ah, is see
[11:47] <Amaranth> -s
[11:48] <Amaranth> hmm, i guess either make network-manager only suggest wpasupplicant or make the package stop building wpagui
[11:48] <infinity> Or build the other wpagui that's gt3.
[11:48] <infinity> qt3, too.
[11:48] <infinity> Odd type, that one.
[11:49] <infinity> And that typO too.
[11:49] <Amaranth> hehe
[11:49] <Amaranth> oh well, i guess people will have to wait until monday to get the new crack :)
[11:52] <SEJeff> But monday will be n-m 0.6 with working wpa?