[01:02] <Kamion> it's annoying that usb-discover insists on being built with a new discover1-data rather than just using its lists at run-time
[01:02] <mdz> it's annoying that usb-discover exists
[01:02] <Kamion> oh, blast, I know why that is, it's because it's used on images too small for discover1-data
[01:02] <mdz> and discover1-data, for that matter :-)
[01:03] <Kamion> well, hotplug hasn't had data for some of the hardware detection bugs I've fixed today either
[01:03] <mdz> from what I see, hotplug should obsolete it
[01:03] <mdz> Kamion: please file bugs for Herbert with the info for anything which is missing
[01:03] <Kamion> joeyh's strongly held opinion is that it's better to have devices in discover which are known to work than devices in hotplug which maybe work and might break
[01:04] <mdz> my strongly held opinion is that the people who wrote the drivers know better which devices work, and they supply the information used by hotplug
[01:04] <Kamion> I think he does speak from a certain amount of experience here
[01:04] <Kamion> those people get it wrong too, and it can cause a lot of havoc :)
[01:04] <mdz> there is data in discover which is plain wrong, loading modules for devices they don't support
[01:04] <Kamion> sometimes it's worse to load the wrong driver than no driver at all
[01:04] <Kamion> really?
[01:04] <Kamion> there's data in the kernel like that too
[01:04] <mdz> when I did that big comparison, I found some
[01:05] <Kamion> both discover and the kernel lag behind actual hardware devices to some extent; the extents differ
[01:05] <mdz> sure
[01:06] <mdz> but there's no justifiable reason for them to have different data
[01:06] <Kamion> I guess part of the opinions held by people like joeyh are due to the 2.4 kernel, which is a lot crappier in this respect
[01:06] <mdz> true enough
[01:07] <mdz> what were the examples that you found today?
[01:07] <Kamion> NVIDIA USB, I think, I'll have to go back and compare
[01:08] <Kamion> probably:
[01:08] <Kamion>     - Add usb/usb-ohci for 10de00e7.
[01:08] <Kamion>     - Add usb/ehci-hcd for 10de00e8.
[01:08] <mdz> I was under the definite impression that USB stuff was handled based on PCI classes
[01:09] <Kamion> there were some explicit lists in the kernel
[01:09] <Kamion> of course maybe I was just believing pci_ids.h ...
[01:09] <mdz> mizar:[~]  grep hci /lib/modules/2.6.8.1-3-386/*pcimap
[01:09] <mdz> uhci-hcd             0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x000c0300 0xffffffff 0x0
[01:09] <mdz> ohci-hcd             0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x000c0310 0xffffffff 0x0
[01:09] <mdz> ehci-hcd             0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x000c0320 0xffffffff 0x0
[01:09] <mdz> ohci1394             0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x000c0010 0xffffffff 0x0
[01:09] <mdz> that's all that hotplug has for the HCI modules
[01:10] <Kamion> hm
[01:10] <Kamion> I wonder if usb-discover could do that (even if we lose it, Debian still has to keep it in form due to heterogeneous kernels)
[01:10] <Kamion> s/in form/in some form/
[01:11] <mdz> via discover, or directly?
[01:11] <Kamion> either
[01:11] <mdz> depends on whether you have a strong stomach, I guess :-)
[01:11] <mdz> neither is very palatable
[01:12] <Kamion> *shrug*, it's no worse than lots of hardware detection
[01:12] <mdz> in the first case, discover's code is gnarly
[01:12] <mdz> I guess directly is not that bad, /proc/bus/pci is pretty sane
[01:12] <Kamion> I don't see anything that might plausibly be PCI classes in /proc/bus/pci/devices
[01:12] <mdz> hmm
[01:12] <mdz> you're right
[01:13] <mdz> well that stinks
[01:13] <mdz> I wonder where lspci gets it, then
[01:13] <mdz> /proc/bus/pci/NN maybe
[01:13] <Kamion> does it?
[01:13] <mdz> ah, it uses sysfs
[01:13] <Kamion> oh, it has prog-if
[01:13] <Kamion> is that what you mean?
[01:13] <mdz> which looks the same as pci/NN
[01:14] <mdz> prog-if?
[01:14] <Kamion> 0001:01:1b.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI] )
[01:14] <Kamion> it appears to peek PCI configuration registers for that
[01:14] <mdz> aaha
[01:14] <Kamion>       c = get_conf_byte(d, PCI_CLASS_PROG);
[01:15] <mdz> mizar:[/tmp/usb-discover-0.22]  grep -w 0x0c0300 /sys/bus/pci/devices/*/class
[01:15] <mdz> silly IRC eating my output
[01:15] <Kamion> maybe you could get it from /proc/bus/pci/*/* if you tried hard enough
[01:15] <mdz> mizar:[/tmp/usb-discover-0.22]  grep -w 0x0c0300 /sys/bus/pci/devices/*/class | sed -e 's/^/ /'
[01:15] <mdz>  /sys/bus/pci/devices/0000:00:07.2/class:0x0c0300
[01:15] <mdz>  /sys/bus/pci/devices/0000:00:07.3/class:0x0c0300
[01:15] <Kamion> needs to be portable to 2.4 if I'm going to push it into Debian
[01:15] <mdz> that's all UHCI controllers
[01:16] <Kamion> although I suppose it could fall back to discover on 2.4
[01:16] <seb128> mdz: pong
[01:16] <Kamion> yes, that seems a nice approach
[01:16] <mdz> yeah, you should be able to add about 10 lines of shell and handle all USB controllers on 2.6
[01:16] <Kamion> neat
[01:17] <Kamion> ok, will try to do that
[01:17] <mdz> seb128: were you able to reproduce #1943?
[01:17] <seb128> mdz: no, tried on my 2 boxes
[01:17] <seb128> on without any soundcard, the other with module removed
[01:17] <seb128> no problem
[01:17] <mdz> seb128: do you have some time to work with me on it?
[01:18] <mdz> it is causing problems for many users
[01:18] <Kamion> mdz: advance approval to upload that when I implement it? :)
[01:18] <mdz> Kamion: yes
[01:18] <seb128> I've no real idea on the problem, I've never looked on the sound part ...
[01:18] <seb128> I can make test if you have some idea
[01:19] <mdz> seb128: I can set you up with shell access on a system which exhibits the problem
[01:19] <mdz> or I can try some things
[01:19] <seb128> the problem is that shel access to debug GNOME sessions ...
[01:19] <mdz> I'll try some strace
[01:20] <seb128> do you have something in ~/.xsession-errors
 looking at .xsession-errors showed "/tmp/esd/socket existing, esd already running, exiting"
 or something like that
 i think _this_ is the problem
[01:21] <seb128> this was some hours ago
[01:21] <seb128> do you have something in /tmp/esd ?
[01:21] <mdz> checking
[01:23] <mdz> no /tmp/esd
[01:23] <seb128> ok
[01:24] <mdz> in ~/.xsession I have:
[01:24] <mdz> /dev/dsp: No such file or directory
[01:24] <mdz> /dev/dsp: No such file or directory
[01:24] <mdz> /dev/dsp: No such file or directory
[01:24] <mdz> /dev/dsp: No such file or directory
[01:24] <mdz> /dev/dsp: No such file or directory
[01:24] <mdz> /dev/dsp: No such file or directory
[01:24] <mdz> ** (gnome-session:9507): WARNING **: Esound failed to start.
[01:25] <mdz> the /dev/dsp error is reapeated a few hundred times
[01:27] <Kamion> mdz: yup, ten lines. :-)
[01:27] <mdz> seb128: you want strace?
[01:27] <seb128> could try that yes
[01:28] <mdz> attached to the bug
[01:30] <seb128> ok, thanks
[01:30] <mdz> it is hard to tell where it is blocking
[01:32] <mdz> gnome-session itself forks esd
[01:32] <mdz> many times
[01:33] <Kamion> mdz: #1932 should be dead with the DMA changes, shouldn't it?
[01:33] <mdz> Kamion: yes, if that's a bad DMA symptom
[01:33] <sabdfl> hey guys
[01:34] <mdz> linux-source-2.6.8.1 (2.6.8.1-10) warty; urgency=low
[01:34] <mdz>   * Enabled IDEDMA_ONLYDISK.
[01:34] <Kamion> mdz: think so ... the new kernels won't make it onto the CD until tomorrow sometime, so I'll wait until there's something for him to test and then ask for a retest
[01:34] <jdub> sabdfl: pipermail's not working with external (lurker) turned on; disabling now and doing it another way.
[01:35] <Kamion> will probably do a manual CD build sometime tomorrow, I've uploaded enough stuff today that I want to test
[01:35] <seb128> jdub: do we want to remove the "launch terminal" entry from the nautilus' menu on the desktop ?
[01:36] <jdub> seb128: what for? :)
[01:36] <sabdfl> jdub: considered using a cron job to get lurker to parse the mbox files hourly?
[01:36] <seb128> jdub: #1777
[01:37] <jdub> sabdfl: won't be dynamic enough
[01:37] <jdub> sabdfl: i'm just going to deliver mail to it
[01:38] <sabdfl> jdub: mailman has an explicit option to do both mbox and pipermail
[01:38] <jdub> sabdfl: which is not working!
[01:38] <jdub> well
[01:38] <sabdfl> ok
[01:38] <jdub> mbox + pipermail is
[01:38] <jdub> mbox + pipermail + external is not
[01:39] <jdub> seb128: waste of patch, dude
[01:39] <seb128> jdub: ?
[01:39] <sabdfl> any particular reason to keep the pipermail archive?
[01:39] <jdub> seb128: #1777
[01:39] <seb128> jdub: "waste" ?
[01:39] <jdub> sabdfl: because currently, that's what people are looking at, and for some people, it's easier to read
[01:39] <seb128> jdub: it has been provided by vuntz .. people are free to provide patches afaik
[01:40] <sabdfl> yes, some views are cleaner in pipermail
[01:40] <jdub> seb128: we don't have to accept every patch :)
[01:40] <seb128> jdub: that's why I'm asking :) But I don't get the "waste" part ...
[01:40] <jdub> seb128: every patch we add is a cost
[01:40] <seb128> we use it or not, but that's not wasted
[01:40] <seb128> why ?
[01:40] <jdub> seb128: we shouldn't throw on frivolous patches just because they exist
[01:41] <jdub> seb128: because we have to maintain them, and because they set precedent
[01:41] <seb128> ok, so the answer is no :)
[01:41] <seb128> let's see if upstream accept it
[01:41] <jdub> er, 'yes', the answer is 'no' ;)
[01:44] <seb128> jdub: do you know if some other distro has sound events turned to on by default with GNOME ?
[01:45] <jdub> seb128: afaik, none do.
[01:45] <seb128> ok
[01:45] <jdub> seb128: given that there's minimal support for it upstream. :-)
[01:45] <seb128> yes, I was fearing that
[01:45] <jdub> and, um, they're just annoying ;)
[01:45] <seb128> we have a severe issue for people who don't have a working soundcard
[01:45] <seb128> session hangs
[01:45] <jdub> oh?
[01:45] <jdub> oh
[01:46] <seb128> we got a bunch of dup of the problem
[01:46] <seb128> but no problem here ... dunno the condition to get it
[01:47] <seb128> (#1943 if you want the bug number)
[01:48] <jdub> mmm, been watching the bug; no useful input as yet.
[01:51] <seb128> yes, but several dup on the list
[01:53] <mdz> hmm
[01:53] <mdz> hald is segfaulting
[01:59] <mdz> seb128: does the strace reveal anything to you?
[02:00] <seb128> no ...
[02:00] <seb128> I'm trying to get details on google, perhaps somebody else got the same problem
[02:00] <seb128> but most of the people avoid sound events/esd in GNOME
[02:03] <jdub> lots of people use esd, but veeeery few use sound events
[02:04] <sabdfl> jdub: prognosis for sound improvement in gnome 2.10?
[02:05] <jdub> sabdfl: well, i'm going to champion the DEATH OF ESOUND
[02:06] <jdub> sabdfl: but for sound events, no one cares. it's horrible stuff, needs restructuring if anyone cares about it at all.
[02:06] <sabdfl> fluendo guys not interested?
[02:06] <jdub> interface bleeps beyond errors are just annoying
[02:06] <jdub> no, they care about multimedia
[02:07] <jdub> i would just recommend avoiding the entire sound event mess for now, and if we think it has any serious benefit for users, help to restructure it
[02:10] <mdz> so basically, you guys (jdub and seb128) are saying that we should not enable sound events by default in Warty?
[02:10] <seb128> yes
[02:10] <jdub> yes
[02:11] <jdub> mdz: do you think sox is evil?
[02:11] <sabdfl> fine by me
[02:11] <mdz> jdub: moderately
[02:11] <sabdfl> can we play a startup sound using aplay?
[02:12] <mdz> using aplay would be >> sox
[02:12] <jdub> sabdfl: how about a gdm "you can login now" sound?
[02:12] <jdub> mdz: ok
[02:12] <mdz> jdub: don't we already ring the system bell for that?
[02:12] <sabdfl> you mean, other than "BEEP"
[02:12] <jdub> yes, but we can replace it with a sound
[02:12] <jdub> (i would like to)
[02:12] <sabdfl> seems perfect to me
[02:14] <jdub> ok
[02:15] <sabdfl> mdz: there is currently no warty-security universe
[02:16] <sabdfl> i think it needs to be there
[02:16] <sabdfl> we'll put stuff in it that's easy and obvious or provided by the comunity
[02:16] <sabdfl> not sure if that's an oversight or just not done yet
[02:46] <mdz> sabdfl: elmo was very much against it
[02:47] <mdz> there is a big problem with testing-security in Debian
[02:47] <sabdfl> i think it's criminal not to have SOMETHING
[02:47] <mdz> people see it in the archive and take it as a declaration of support
[02:47] <sabdfl> the apt.sources.list stuff is as explicit as we want it to be
[02:47] <mdz> then they send us hate mail when they don't get any updates from it :-)
[02:47] <sabdfl> the reality is there could be a trivial kde fix or something, tiny patch, as we *can't* get it to people
[02:48] <mdz> we can always toss it into universe itself
[02:48] <mdz> not that I'm entirely unsold on universe-security
[02:48] <sabdfl> by that argument, we could toss warty security updates into warty
[02:48] <sabdfl> we don't, for very good reason
[02:48] <sabdfl> i don't think being afraid of a misinterpretation of our level of support for universe is a good reason
[02:49] <sabdfl> it will happen in the first week, i'm certain of it
[02:49] <sabdfl> the moment we release:
[02:49] <sabdfl> joehacker: where's package foo?
[02:50] <sabdfl> blogghacker: it's in universe, doooood
[02:50] <sabdfl> joehacker: but that's version, 1.2.1 and there is a security fix in 1.2.2!
[02:50] <sabdfl> it's going to happen the day we release
[02:50] <sabdfl> anyhoo... i'm retiring from the battlefield
[02:50] <mdz> the reason we don't do that for warty is because we provide a certain level of quality and stability, which we don't for universe
[02:50] <sabdfl> for tonight :-)
[02:51] <sabdfl> see you all anon
[02:51] <mdz> ok
[02:51] <mdz> it's already happening
[02:51] <mdz> there are already known vulnerabilities in universe that we are not fixing
[02:51] <sabdfl> that's fine while we are during freeze
[02:51] <sabdfl> but i think we could quickly get a community hit squad together to approve or veto uploads to universe for security fixes
[02:51] <sabdfl> might be agood proving ground for new talent
[02:52] <mdz> sure
[02:52] <sabdfl> it's not something we need to worry about or invest time in (we explicitly say we won't)
[02:52] <sabdfl> but if the community process can carry the workload we should support it
[02:52] <sabdfl> and for hoary, universe will see a lot more work done by other people
[02:52] <sabdfl> and hence universe will be higher quality
[02:53] <Kamion> if packages in universe are getting significant work done by externals, the plan is to consider them for supported, isn't it?
[02:53] <mdz> we currently don't even have infrastructure for warty main security updates
[02:53] <mdz> I think you'll agree that gets priority :-)
[02:54] <mdz> Kamion: if it makes it past the comfort threshold, yes
[02:56] <sivang> mdz : universe sec bugs which are not getting fixed due to lake of priority for warty, or for being officially unsupported?
[02:56] <mdz> sivang: both
[02:57] <sivang> mdz : what about a sync up policy from debian?
[02:57] <mdz> sivang: what do you mean?
[02:57] <sabdfl> Kamion: yes, but even if they remain in universe for a few releases, it's better for us if universe is higher quality
[02:57] <sivang> mdz : as I remeber the report I made for 2004, most of the issues could be solved by fetching the newer source packages from sid.
[02:57] <Kamion> mdz: so, I'm seeing firmware loading problems with this prism54 card I've got here
[02:57] <Kamion> sabdfl: sure
[02:57] <sabdfl> and a well managed community process could be great for the community as well as for us
[02:58] <sabdfl> we will need to empower the right groups in teams and individuals
[02:58] <sivang> however that could be a very small subset of known and unknown sec bugs currently....
[02:58] <Kamion> mdz: having updated all the hotplug scripts to current versions etc., it seems to try loading the firmware, then it immediately issues a firmware remove action, then it tries to soft-reset the card and fails miserably, then it loops
[02:58] <mdz> Kamion: neat
[02:58] <sabdfl> anyhoo... i'm going to crash for the night... see you all tomorrow
[02:58] <mdz> Kamion: does it work correctly with the same hardware on an installed system?
[02:58] <Kamion> haven't tried it outside d-i yet though
[02:59] <Kamion> that machine is sacrificial weirdo corner-case testing box, so it isn't in an installed system often :)
[02:59] <mdz> sivang: when we're not in a deep freeze, we'll be more liberal about accepting new versions from Debian for universe
[03:00] <mdz> Kamion: perhaps you're running into the kill-switch-loop-of-death bug
[03:00] <mdz> which is fixed in the current kernel?
[03:01] <sivang> mdz : ok. I was thinking that security related issues can have an exempt from the freeze. but it do sounds more logic to do it for main, not universe.
[03:02] <Kamion> don't see a kill-switch flag in /sys
[03:03] <sivang> Kamion's special made iso for parted issue
[03:19] <Kamion> mdz: ok, seems to break in a real system too, I guess it isn't a d-i thing, I'll file a bug
[03:19] <mdz> Kamion: you're running with the 0.10 version of the driver?
[03:20] <Kamion> mdz: this is prism54, not ipw2200
[03:20] <mdz> Kamion: ohh
[03:21] <mdz> I didn't read that bit at all
[03:21] <Kamion> hence, no kill switch :-)
[03:41] <sivang> Kamion : still has that C/H/S message. where can I track it on the logs to see what's really spitted there?
[03:46] <sladen> is tht implying that it's /not/ actually working with fat*
[03:48] <sivang> i have only one fat32 partiton there, and grub. the linux parts on on /dev/hdb interestingly.
[03:48] <sivang> /dev/hda being the boot device
[03:50] <sivang> if only i could snapshot that scree see the details of this message..
[03:52] <sivang> anyways, i'm off to sleep.
[03:52] <sivang> night
[08:44] <mdz> jdub: ping?
[09:29] <jdub> pong
[09:31] <jdub> hrm
[09:31] <jdub> can't load ipw2200
[09:31] <jdub> FATAL: Error inserting ipw2200 (/lib/modules/2.6.8.1-3-686/kernel/drivers/net/wireless/ipw2200/ipw2200.ko): Unknown symbol in module, or unknown parameter (see dmesg)
[09:31] <jdub> ipw2200: disagrees about version of symbol ieee80211_wx_set_encode
[09:31] <jdub> ipw2200: Unknown symbol ieee80211_wx_set_encode
[09:31] <jdub> ipw2200: disagrees about version of symbol ieee80211_wx_get_encode
[09:31] <jdub> ipw2200: Unknown symbol ieee80211_wx_get_encode
[09:31] <jdub> ipw2200: disagrees about version of symbol ieee80211_wx_get_scan
[09:31] <jdub> ipw2200: Unknown symbol ieee80211_wx_get_scan
[09:32] <jdub> ipw2200: disagrees about version of symbol ieee80211_alloc
[09:32] <jdub> ipw2200: Unknown symbol ieee80211_alloc
[09:32] <jdub> ipw2200: disagrees about version of symbol ieee80211_rx
[09:32] <jdub> ipw2200: Unknown symbol ieee80211_rx
[09:32] <jdub> ipw2200: disagrees about version of symbol ieee80211_rx_mgt
[09:32] <jdub> ipw2200: Unknown symbol ieee80211_rx_mgt
[09:32] <jdub> ipw2200: disagrees about version of symbol ieee80211_skb_to_txb
[09:32] <jdub> ipw2200: Unknown symbol ieee80211_skb_to_txb
[09:32] <jdub> ipw2200: disagrees about version of symbol ieee80211_free
[09:32] <jdub> ipw2200: Unknown symbol ieee80211_free
[09:32] <jdub> 
[09:32] <daniels> mdz: hm
[09:33] <daniels> mdz: would solving #1981 be out of the question by creating a small wrapper that modprobes ppp_generic that's suid root, and only executable by dip?
[09:53] <mdz> jdub: I didn't even consider the possibility that the user was raising the firefox update issue without noticing that it wasn't enabled
[09:53] <mdz> daniels: I think pppd itself should just modprobe ppp_generic
[09:54] <mdz> jdub: did you perhaps install the driver from source at some point?
[09:54] <mdz> jdub: it works like a charm for me
[09:54] <jdub> mdz: nup
[09:54] <jdub> this is after a kernel update
[09:54] <jdub> oh
[09:54] <jdub> hold on
[09:54] <jdub> i don't think i've rebooted
[09:54] <jdub> hrm
[09:54] <jdub> i'll try that ;)
[09:55] <daniels> mdz: ok
[09:55] <mdz> jdub: how would I verify that the firefox thing is disabled?
[09:55] <mdz> jdub: if I go into preferences->advanced, the "periodically check for updates" bits are checked
[09:55] <mdz> and clicking "check now" produces a complaint about the critical update
[09:56] <mdz> there's an 'install now' button, which obviously doesn't work
[09:56] <mdz> so it seems to be enabled
[10:03] <jdub> ahr, bong
[10:03] <jdub> mdz: if periodically check for updates is checked (for the browser, not extensions), then we've messed that up in our update
[10:04] <jdub> ok, so it was a kernel/restricted sync issue
[10:04] <jdub> working fine now
[10:13] <mdz> jdub: ipw2200 isn't in restricted
[10:13] <mdz> jdub: so I'm having a hell of a time trying to track down #1943
[10:13] <jdub> oh yeah, good point
[10:13] <jdub> mdz: sounds?
[10:14] <mdz> yeah
[10:14] <mdz> I've tried disabling sound events and esd and stuff, and it's all very weird
[10:14] <jdub> even after disabling them, it's still happening?
[10:15] <mdz> no, it's more like I disable stuff, and then it goes away, and then I re-enable, and re-load the sound driver, but I still don't get sounds
[10:15] <mdz> maybe I do not fully grok gconf
[10:15] <mdz> right now I can't reproduce the problem, but I can't get it to play sounds either, so I think my settings are stuck
[10:16] <mdz> esd is running, but sound events are clearly off
[10:16] <mdz> even though gconf tells me they are enabled
[10:17] <mdz> mdz@potpal:~ $ !gconf
[10:17] <mdz> gconftool-2 -R / | grep sound_events
[10:17] <mdz>     sound_events = true
[10:17] <jdub> what does the sounds dialogue say?
[10:17] <mdz> but the box is unchecked if I go into sound preferences
[10:17] <mdz> (just looked)
[10:17] <jdub> ahr
[10:17] <mdz> wtf is that
[10:17] <jdub> hrm
[10:17] <mdz> checked the box, sounds are back
[10:20] <mdz> hmm
[10:21] <mdz> gnome-settings-daemon is opening the ALSA control device
[10:21] <mdz> why is it doing that?
[10:22] <mdz> 16733 open("/usr/lib/gstreamer-0.8/libgstalsa.so", O_RDONLY) = 35
[10:22] <mdz> jdub: gnome-settings-daemon is into all sorts of things
[10:23] <jdub> mdz: it handles the keyboard shortcuts for the mixer
[10:24] <jdub> that's a lot of the reason why it does heaps
[10:24] <jdub> that pmu on ppc thing is g-s-d too -> backlight control
[10:29] <mdz> jdub: bingo
[10:30] <mdz> jdub: removing gstreamer0.8-alsa suppresses the problem
[10:30] <mdz> so it's something messing with ALSA, and not esd or anything going through it
[10:50] <daniels> mdz: ok to upload http://people.ubuntu.com/~daniels/ppp/ppp_2.4.2+20040428-2ubuntu5-to-ubuntu6.diff ?
[10:51] <daniels> mdz: works here when invoking pon as non-root, with no ppp modules loaded
[10:51] <daniels> actually, holdasec.
[10:53] <daniels> yep
[10:53] <daniels> daniels@nanasawa:~% ls -l /dev/ppp
[10:53] <daniels> ls: /dev/ppp: No such file or directory
[10:53] <daniels> daniels@nanasawa:~% pon
[10:53] <daniels> daniels@nanasawa:~%
[10:53] <doko> good morning
[10:53] <daniels> doko: 'morning
[10:56] <Mithrandir> hi doko
[10:59] <doko> Mithrandir: see #1992, I'm wondering, how you did build OOo for amd64
[11:00] <mdz> daniels: it would be nice if it waited for /dev/ppp to appear rather than sleep(5)
[11:00] <mdz> especially when the module is already loaded and the device already exists
[11:00] <daniels> the sleep (5) was there for a reason
[11:01] <mdz> doko: look at the source package; it uses the i386 binaries
[11:01] <daniels> if you wait for /dev/ppp to appear, you could just spin infinitely
[11:01] <daniels> and that codepath only gets hit if /dev/ppp doesn't exist already
[11:01] <daniels> it's not a five-second hit on subsequent connects
[11:01] <mdz> waiting for /dev/ppp does not imply waiting indefinitely
[11:02] <mdz> but if it doesn't hit that code if /dev/ppp already exists, looks good to me
[11:02] <daniels> i can wait for /dev/ppp if you like, but seems like additional complexity to be including
[11:02] <daniels> rad
[11:02] <doko> mdz: ahh. ok the precompiled i386 binaries ...
[11:02] <Mithrandir> doko: what mdz says.
[11:03] <mdz> doko: if you want to track a bug for Ubuntu where there is already a Debian bug open, ask me to import the bug rather than opening a new one
[11:03] <Mithrandir> doko: make sure you don't end up conflicting with ia32-libs-ooo
[11:04] <doko> mdz: there was only one for gcc-3.4, not gcc-3.3.
[11:04] <mdz> doko: ?
[11:05] <doko> mdz: the problem exists both in gcc-3.3 and gcc-3.4. Debian gcc-3.3 is not biarch, therefore there is no bug report in the Debian BTS.
[11:06] <daniels> mdz: btw, if you want to make the owner/default assignee for ppp/pppoe/et al myself, I'm fine with that
[11:06] <daniels> as opposed to the de facto owner/default assignee ;)
[11:06] <doko> Mithrandir: will look. these are development files only, according to the name 'ia32-libs-ooo', there should be no -dev files in the package.
[11:06] <daniels> c
[11:06] <daniels> erk
[11:07] <mdz> doko: but when you filed the bug in bugzilla, you said it was the same as Debian bug #273755
[11:07] <mdz> but now that I have imported that bug, it does not seem to be the same at all
[11:08] <doko> the same for gcc-3.4. in the past you told me to use the BTS to track changes to packages proposed for upload to warty. that's what the bug was for. confused ...
[11:10] <mdz> doko: in the bug description, you wrote "this is Debian #273755".  what did you mean by that?
[11:10] <Mithrandir> I just love people who write C++ but just write C.  And I love people who cast pointers to ints.
[11:10] <mdz> Debian #273755 is a fortran bug
[11:11] <doko> ahh, ok I see ... I cited the wrong report ... #274362 is the amd64 one ...
[11:12] <doko> yes, and #273755 should be address as well. wrong code regression from g77-3.3 to g77-3.4
[11:13] <mdz> not critical for Warty
[11:13] <doko> which one, or both?
[11:14] <mdz> g77
[11:15] <mdz> the amd64 issue is debatable; the only thing we build with biarch is grub, which isn't C++
[11:15] <Mithrandir> mdz: I think the ooo-amd64 bug might be due to ia32-libs-ooo not shipping myspell. :)
[11:15] <mdz> but since it seems very simple to fix, it's OK with me
[11:15] <mdz> Mithrandir: ahh
[11:16] <Mithrandir> mdz: but it looks like ooo does some weird stuff:
[11:16] <Mithrandir> open("/usr/lib/libmyspell.so.3", O_RDONLY) = 22
[11:16] <Mithrandir> /usr/lib/libmyspell.so.3:   symbolic link to `libmyspell.so.3.1'
[11:16] <Mithrandir> /usr/lib/libmyspell.so.3.1: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
[11:17] <Mithrandir> maybe it's ldopen, I don't know.
[11:17] <Mithrandir> I'll build a 32 bit myspell and test
[11:19] <Mithrandir> 64 bit works.. mostly. ;)
[11:21] <Mithrandir> doko: do we include drdsl anywhere, or how do I get my Fritz!DSL card working?
[11:23] <doko> Mithrandir: what is it good for? I have a Fritz!DSL as well (the combined one with ISDN), and I don't use it at all.
[11:23] <Mithrandir> doko: I don't remember, it might be useless.
[11:25] <Mithrandir> doko: how do you set the vpi and vci?
[11:28] <doko> have /etc/drdsl/adsl.conf, but I don't call drdsl ... hmm
[11:28] <Mithrandir> ok, so it might be enough just to have the file
[11:29] <doko> controller 2
[11:29] <doko> protocol adslpppoe
[11:29] <doko> vpi 8
[11:29] <doko> vci 35
[11:42] <jdub> mdz: whoa, wacky
[11:43] <jdub> mdz: can we not install gstreamer0.8-alsa by default?
[11:43] <mdz> jdub: this is all so fucked, I am not sure that test was at all valid
[11:43] <mdz> my machine is fucking crashing now
[11:43] <jdub> oh.
[11:43] <mdz> and I am no closer to finding the problem
[11:44] <jdub> capplets is the only thing that depends on it
[11:44] <jdub> due to gstreamer-properties
[11:45] <jdub> hrm, no
[11:45] <mdz> I can't reproduce the bug when I'm stracing stuff
[11:45] <jdub> due to gnome-settings-daemon
[11:45] <jdub> heh, i hate those ones
[11:49] <mdz> a lot of people are installing ubuntu and finding it completely useless because of this bug
[11:49] <mdz> whatever it is
[11:52] <mdz> jdub: are you able to reproduce it?
[11:52] <mdz> do this: lsmod | grep '^snd' | awk '{ print $1 }' | xargs -n1 sudo rmmod
[11:52] <mdz> and then try to login in gdm
[11:52] <mdz> I need to know that I'm not crazy
[11:57] <mdz> anyone?
[12:00] <mdz> there are two gnome-settings-daemon processes
[12:00] <mdz> they appear to have a pipe open between them
[12:00] <mdz> one is writing to the pipe, and the other is waiting for the one writing to the pipe
[12:00] <mdz> so they're basically deadlocked
[12:10] <mdz> I can't stare at this any more tonight. I've put everything useful that I have so far into bugzilla
[12:10] <mdz> someone else please look at it when you have a chance
[12:13] <Mithrandir> which bug is this?
[12:23] <mdz> Mithrandir: #1943
[12:23] <mdz> the big red one :-)
[12:24] <Mithrandir> mdz/jdub: permission to upload new ia32-libs-openoffice.org with libmyspell3 included.
[12:24] <Mithrandir> fixes 1986
[12:24] <mdz> Mithrandir: yes
[12:24] <Mithrandir> thanks. :)
[12:25] <daniels> $(srcdir)/configure: $(srcdir)/configure.in $(ACLOCAL_M4) $(CONFIGURE_DEPENDENCIES)
[12:25] <daniels>         cd $(srcdir) && $(AUTOCONF)
[12:25] <daniels> GNAR
[12:35] <daniels> if it lasted twenty invocations of debuild, some with -S, some without, it should be OK
[01:21] <daniels> g-s-m built!!
[01:22] <tseng> who what?
[01:22] <tseng> oh.
[01:29] <doko> where can I find the query for the (currently 34) warty RC bugs?
[01:37] <daniels> doko: there are < 34 bugs with a Warty target milestone, so I assume it's just blocker/critical/major bugs
[01:45] <mdz> correct
[01:45] <mdz> everything >= major
[01:48] <doko> hmm, I get 32 when selecting all statuses, but a lot of them are set to resolved.
[01:51] <mdz> severity: blocker, critical, major + product: ubuntu + status: unconfirmed,new,assigned,reopened,needinfo,pendingupload
[01:51] <mdz> = 34
[01:52] <doko> is it possible to save queries like this one for everyone?
[01:56] <mdz> I'm not sure, ask justdave
[01:57] <doko> ahh, I did have Target=WartyWarthogFinal set as well
[01:59] <doko> mdz: ok to upload analog (#1924), missing mkdir in postinst?
[02:00] <mdz> doko: yes
[02:00] <doko> mdz: ok to upload samba (#1761), server string without version number?
[02:00] <mdz> doko: yes
[02:00] <doko> ok
[02:02] <sladen> keybuk: does anyone have the Canonical Logo as a vector format?
[02:04] <mdz> sladen: there is an SVG on the wiki
[02:04] <mdz> ah, never mind, you said canonical, not ubuntu
[02:05] <mdz> I only have a bitmap of that one
[02:07] <sladen> while we're on that subject, I did a cleaned up bitmap for the website that doesn't look so grotty
[02:07] <sladen> http://www.paul.sladen.org/ubuntu/branding-clean/www.canonical.com/logo.png
[02:07] <sladen> (contrast with the old  logo.jpg)
[02:16] <pitti> Hi guys!
[02:39] <doko> mithrandir: for amd64 we have lib32gcc1, lib32stdc++5, lib32stdc++6 in universe. why are they included/built in ia32-libs-openoffice.org as well?
[03:44] <pitti> Hi seb128!
[03:44] <pitti> I added some comments to 
[03:44] <pitti> seb128: I added some comments to #1919. Are you fine with the patch?
[03:44] <seb128> yes
[04:01] <doko> mdz, mithrandir: ping about #1996?
[04:27] <pitti> Hi sabdfl
[04:27] <sabdfl> hey pitti
[04:28] <sabdfl> what no hal-of-the-day? :->
[04:28] <pitti> sabdfl: no, this time it's gst-plugins :-)
[04:28] <pitti> sabdfl: but don't be afraid that there won't be further version, yesterday I got two new bugs :-/
[04:28] <sabdfl> any reason my sound has died recently? can't get a cd to play
[04:29] <pitti> sabdfl: but I have to care for a Debian applicant today, I dragged that for too long
[04:29] <sabdfl> but haven't had time to find the bug
[04:29] <pitti> sabdfl: do you just hear no sound, or does it stop with an error message?
[04:29] <sabdfl> cd seems to be spinning but no sound
[04:30] <pitti> sabdfl: so controlling the cd works? you can verify with headphones on the drive
[04:30] <sabdfl> aplay works fine i think
[04:31] <sabdfl> yes it works on a headset from the drive directly
[04:31] <pitti> sabdfl: and it worked with an earlier version?
[04:32] <sabdfl> i never tried the cd layer applet
[04:32] <sabdfl> do i need to configure gst?
[04:33] <pitti> sabdfl: actually this should not be necessary
[04:33] <pitti> sabdfl: when running the CD-ROM as audio player, you just need a cable which connects the CD with the sound card
[04:33] <sabdfl> hmm... maybe that's not setup
[04:33] <pitti> sabdfl: another approach is to read out the audio cd digitally and output it through the normal /dev/dsp
[04:34] <sabdfl> ok
[04:34] <sabdfl> i'll play around
[04:34] <pitti> sabdfl: a nice low-level tool is 'cdplay' from the cdtool package.
[04:34] <pitti> sabdfl: if that spins up the cd, but you don't hear sound (although the mixer is up), then the cable is probably missing
[04:35] <sabdfl> hmm... there seems to be a problem with rhythmbox too
[04:35] <sabdfl> double clicking a song gives me a dialog error:
[04:35] <sabdfl> "There is no element present to handle the stream's mime type application/x-id3"
[04:38] <Kamion> any opinions on where to put the new live CD image?
[04:39] <Kamion> releases/warty/preview/ seems a bit inappropriate since it isn't synced with the preview release
[04:41] <Kamion> actually never mind, I'll send mail
[04:47] <pitti> sabdfl: I also found this. gstreamer cannot process some of my mp3s, so I just converted them to ogg :-/
[04:49] <sabdfl> pitti: it's not just some of my mp3's, and these used to work just fine
[04:49] <sabdfl> hmm... i wonder if i removed some of the universe stuff...
[04:50] <sabdfl> Kamion: response coming on the mail front. we need a much simpler cdimage rsync export for mirrors
[04:50] <sabdfl> we can have a bigger tree of cd images in the full archive, but we'll get MANY more mirrors of just the cdimages
[04:51] <sabdfl> and we only want to show them the latest stuff, so there is no confusion about which piece they should be downloading
[04:53] <doko> sabdfl: will we have different background images as you presented in Oxford?
[04:53] <Kamion> sabdfl: hence my mail way back before preview anticipating this problem :-)
[04:53] <Kamion> (on sounder@)
[04:54] <sabdfl> Kamion: ok :-)
[04:54] <sabdfl> doko: yes, we are trying to figure out the best strategy on that front at the moment
[04:54] <sabdfl> have the images, just figuring out how to present them, defaults, calendar etc
[04:55] <doko> could we scan the first name of the user account we ask and then select the "appropriate" theme (m/f) for the user?
[04:59] <Kamion> how do you even work out the first name? :-)
[05:00] <sabdfl> doko, Kamion, we could record them saying "Ubuntu" then do a voiceprint analysis to determine gender :-)
[05:01] <doko> the first string looked up in a table of names. that's not much work. If it's ambigious or not found, fall back to a "safe" default ;-)
[05:05] <Kamion> doko: that's wrong for a big chunk of the world
[05:05] <sabdfl> default will be very conservative, no image at all
[05:05] <Kamion> lots of countries use given-name-last
[05:05] <doko> kamion: but at this point we already know the country
[05:06] <Kamion> sabdfl: aargh, I *wish* the cdimage layout had been stabilized before preview, I was really trying to have all the rearrangements finished by then; now we're going to annoy the mirrors we already have
[05:06] <Kamion> and break advertised URLs, etc.
[05:07] <Kamion> I also think it's a bad idea to remove previously available images, as the /preview-release/ -> warty symlink implies you want to do
[05:07] <Kamion> they need to be archived somewhere with a consistent URL
[05:08] <doko> kamion: during installation on pbook, how do I switch the console (german keyboard)?
[05:09] <Kamion> doko: loadkeys, I think
[05:09] <Kamion> if it's available; kbd-chooser does it in C
[05:29] <Mithrandir> doko: hysterical raisins, I think; do they work with ooo?
[05:30] <doko> Mithrandir: ???
[05:31] <Mithrandir> doko: why ia32-libs-ooo contains libstdc++5
[05:31] <doko> ahh, yes. I never had the chance to run oo on amd64, so I don't know ...
[05:34] <doko> mithrandir: could you check it out? replacing the libgcc.1 and libstdc++5 from ia32-libs-ooo with these from the lib32* packages?
[05:38] <Mithrandir> doko: yeah, I'll try
[05:40] <sladen> doko: remember, it's not just male/female---you have to take sexual preferences into account too!  ;-)
[07:24] <Mithrandir> hmm, a feature we might want to add, possibly is a question when booting up after an unexpected shutdown, a question on why, with possible reference to problem ticket id and so on.  shamelessly stolen from XP
[07:29] <sabdfl> Kamion: i think we can keep the existing structure, and add another rsync module which has the minimalist stuff for smaller mirrors
[07:30] <sabdfl> Kamion: also, i think we should name the iso's in a preview dir "preview-warty-i386.iso" so there is no confusion, in future
[07:46] <Kamion> sabdfl: I think I disagree there, I'd prefer to keep the image names identical and disambiguate by directory name
[07:46] <Kamion> makes it easier to have rsync scripts and stuff
[07:47] <sabdfl> Kamion: for that "simple cdimage" tree, i'd like to have one, and only one, warty dir.
[07:47] <sabdfl> for the full tree in the full archive, fine, as you wish
[07:47] <sabdfl> but the simple version should have a single warty dir
[07:47] <Kamion> maybe we'll just have to copy to the simple tree, then
[07:48] <sabdfl> Kamion: that's fine too
[07:48] <Kamion> let me sleep on this, I want to think out the consequences :)
[07:48] <sabdfl> i'm trying to greatly reduce the amount of knowledge required to find the right iso, know what you're getting, and get it
[07:52] <Kamion> understood
[07:53] <Kamion> mdz: uploading ddetect to fix a build problem in the /sbin/hotplug addition (whoops)
[07:57] <Kamion> sabdfl: the things I'm balancing against that are our need to be able to expect users to know which image they've got, and the need to make it reasonably easy for users to track along with us as we finish off warty without having to change mirroring scripts too often; they aren't contradictory concerns, but we've managed to balance everything thus far and I just want to be careful in ensuring that we continue to do s
[07:58] <sabdfl> Kamion: understood, what's been done so far is fine, i'm just trying to tweak for a new market of nuuubies
[07:58] <Kamion> right
[08:11] <fabbione> seconf operation day at home a complete success ;)
[08:11] <fabbione> s/f$/d
[08:16] <doko> fabbione: just reinstalled warty on a pbook 12" with german keyboard. there are some other people reporting problems with non-US keyboards. basically I can't type in @, ?, [ ]  { } \ |
[08:17] <fabbione> doko: yes i know
[08:17] <fabbione> we miss a file
[08:17] <fabbione> it has been committed to SVN today
[08:18] <fabbione> doko: i have the changes already merged in my tree, but i need to collect a bunch of fixes before uploading X
[08:19] <doko> ok thanks.
[08:19] <fabbione> it's the us_intl layout definition file missinf
[08:19] <fabbione> missing even
[08:19] <fabbione> it is built but Denis forgot just the detail to install it ;)
[08:20] <fabbione> and both Branden and I didn't notice until yesterday that someone reported the problem
[08:21] <fabbione> Treenaks: you rock! thanks a lot for all the tests!
[08:27] <pitti> fabbione: you mean that external screen on ppc will actually work in the forseeable future? Great!
[08:28] <fabbione> pitti: yes :-)
[08:29] <pitti> fabbione: Great! Maybe it works until December, then I can implement that beer offer in Spain :-)
[08:33] <fabbione> pitti: if we had more time to backport some X.org drivers it would be working now
[08:33] <fabbione> unfortunatly ATI driver has been updated too much and difficult to port
[08:33] <pitti> fabbione: well, the freeze... But till then I still have a small and uncared-of MacOS X installation :-)
[08:34] <fabbione> ehhe
[08:34] <pitti> fabbione: presenting JPGs and PDFs on a beamer is actually the only reason why I still have it
[09:09] <pitti> Guys, dancing tonight. Have a nice evening!
[09:25] <sivang> jdub : around?