[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/<IP_ADDRESS>-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-<IP_ADDRESS> (<IP_ADDRESS>-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/<IP_ADDRESS>-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?


[00:11] <flan> Just one page left for the server. Yay.
[00:11] <flan> (But it's a big one and I'll have to write at least one support page to feed it information)
[00:42] <godbyk> daker: pong.
[00:42] <godbyk> daker: Is that from a TeX Live installation?  If so, you may want to try a different mirror.
[01:08] <Muscovy> Does the Maverick writing freeze mean it's just editing from then on?
[01:10] <godbyk> Muscovy: Basically, yeah.
[01:11] <Muscovy> I'd better get writing then.
[01:11] <Muscovy> :P
[01:11] <godbyk> Yeah, I know. We don't have a lot of time. :)
[01:13] <Muscovy> Yeah, let's not do this again for Natty.
[01:15] <godbyk> It's always a bit of a race since we're try to release the manual at the same time as Ubuntu is released.
[01:15] <godbyk> And it's hard to start writing and taking screenshots until after the UI freeze.
[06:09] <vish> hrm...
[14:47] <thorwil> i wonder if a green-screening like approach could be applied to the wallpaper for screenshots
[14:47] <nisshh> thorwil: what do you mean>
[14:48] <nisshh> ?
[14:49] <thorwil> nisshh: suppose the default wallpaper will change before release, but we start taking screenshots now. could one switch to seldomly used solid color or a pattern as background, to later on replace all parts of it shining through with the final wallpaper?
[14:50] <thorwil> but that was just a quick thought, partial transparency willmake that non-trivial
[14:50] <nisshh> thorwil: hmm, yea its doable, but that would take AGES since each one would most likely have to be done individually
[14:51] <nisshh> it would be different for each screenshot so its probably not automagical
[15:49] <flan> Well, a lot of screenshots won't expose any part of the wallpaper at all.
[15:50] <flan> So we could define all of those on the Quickshot server once I finish its base implementation in a few hours and start capturing those.
[15:50] <flan> Then define the rest once we know what the final wallpaper will look like.
[15:50] <flan> start capturing them*
[15:51] <flan> Or define everything and just keep the wallpaper-exposing ones disabled until we're ready for them.
[15:52] <flan> The hold-up will be the QS client, which, though I'm sure it's getting close to being done, won't be available much before the freeze.
[15:52] <flan> I'll be switching focus to help Jenkins with it starting tomorrow.
[16:38] <flan> Any web-designer-types around right now?
[16:38] <thorwil> hmm
[16:39] <flan> (Simple question related to DOM-ordering, 'cause my mind's not working right at the moment)
[16:40] <thorwil> flan: that's not my thing, but how about you just ask? :)
[16:40] <flan> Because I'm not thinking right. =P
[16:41] <flan> Hello!
[16:41] <flan> I can't remember which node I need to tweak.
[16:41] <flan> And my code's not close enough to complete to just try it.
[16:43] <flan> Oh. .data.
[16:43] <flan> Issue resolved.
[16:43] <thorwil> glad i could be of help ;)
[16:45] <flan> Quite. =P
[19:29] <jenkins> flan: ping
[19:44] <jenkins> nisshh ping
[19:46] <flan> Hi.
[19:46] <jenkins> hey flan can you have a look at lp:quickshot please
[19:46] <flan> What do you want me to look for?
[19:46] <jenkins> quickly run does not work giving and error
[19:47] <jenkins> *an
[19:47] <jenkins> http://paste.ubuntu.com/485544/
[19:48] <jenkins> but the folder is there, i moved everything to do with the program to the "source" folder and now it will not run. I am not sure if it has something to do with a missing package in mavrick as I have jsut changed to it. I thought I had it working again
[19:50] <flan> quickshot.py
[19:51] <jenkins> that error comes form the quickshot file in the source/bin folder
[19:52] <flan> I realize that. But Python expected a .py, .pyc, or .pyc file to match the name of the provided module, unless working with C extensions or doing something low-level with the import engine.
[19:52] <flan> expects*
[19:53] <flan> You're going to be breaking that monolithic file into smaller pieces anyway, so you might as well start separating it now.
[19:53] <flan> I should be (effectively) done with the server in about two hours.
[19:54] <jenkins> i am not following completly, that line (that is causing the error) worked before whats wrong with it?
[19:54] <flan> From what I can see of your paste, it's that it can't find a module named 'quickshot'.
[19:55] <flan> Which is where it expects to find the class you defined.
[19:55] <flan> When the 'quickshot' executable file is run directly, its module-name is '__main__', not 'quickshot'.
[19:56] <jenkins> I always read that line ( from quickshot import AboutQuickshotDialog ) to be from the folder quickshot import the file AboutQuickshotDialog
[19:57] <flan> Nope.
[19:57] <flan> From the file 'quickshot.py'.
[19:57] <flan> (Or pyc or pyo)
[19:58] <flan> It expects to find it either in the current package or in the process's root path, by default.
[19:58] <jenkins> well the file AboutQuickshotDialog is in a folder called "quickshot" :/ so has that bit of code always been screwed?
[19:58] <flan> import sys; print sys.path to see its search targets and order.
[19:59] <flan> Where's the file that holds the definition?
[19:59] <jenkins> the path is imported before the line from....
[20:00] <jenkins> http://paste.ubuntu.com/485549/ is the file
[20:00] <flan> ...An insert into sys.path?
[20:01] <flan> Did you write that or was it Simon?
[20:01] <jenkins> I don't know who wrote it may have been tommy
[20:01] <flan> Eew...
[20:01] <jenkins> http://imagebin.org/111924 is the file layout
[20:01] <flan> Not Tommy. But that code.
[20:01] <jenkins> lol
[20:02] <flan> Looks like this is gonna be a busy week.
[20:03] <jenkins> yea I have to start learning stuff, I have reached my limit on knoledge
[20:03] <flan> That import's going to fail because 'quickshot' isn't resolvable.
[20:04] <flan> First, you'll need to define an __init__.py in quickshot/ so Python will recognize the directory as a package.
[20:05] <flan> Second, you'll need to make that "import quickshot.AboutQuickshotDialog as AboutQuickshotDialog", unless you're like me and prefer infrequently used references to be explicit.
[20:05] <flan> In that case, you'd drop 'as' and refer to the full dotted path every time.
[20:06] <jenkins> ok I will have a go at the __inti.py
[20:06] <flan> touch __init__.py && bzr add __init__.py
[20:06] <flan> It can be empty.
[20:06] <jenkins> o it turns out that is just a file :P
[20:07] <jenkins> just worked that out
[20:07] <flan> It probably should be empty, until you're comfortable with writing packages as libraries.
[20:08] <flan> (We won't need to do that here, since you're writing application-level code)
[20:10] <jenkins> adding the init file makes it all work again I wonder if I removed it accedently
[20:19] <jenkins> yey got it working again fixed another problem
[20:19] <flan> Yay.
[20:21] <nisshh> jenkins: sorry, i was afk for a while, did you want something?
[20:21] <jenkins> hey nisshh I was just going to say i will try and finish my chapter off for the manual. I have been real busy with work lately
[20:22] <nisshh> jenkins: cool, i was going to do some work on the dev manual today, but i didnt get home till later so it didnt really work out
[20:23] <jenkins> just have to wait for another day then :)
[20:23] <nisshh> hehe
[20:23] <jenkins> flan: what would be the best way to make a spinner from http://imagebin.org/111925
[20:23] <nisshh> jenkins: anyway, im off to bed its nearly 4am here
[20:23] <nisshh> night
[20:23] <jenkins> night
[20:25] <jenkins> I have the gkt spinner source code but it is not in python http://paste.ubuntu.com/485557/
[20:26] <flan> That should be in pyGTK somewhere.
[20:27] <jenkins> i can use it in pyhton but it gives an awful spinner that looks weedy
[20:27] <flan> Can you provide a screenshot?
[20:27] <flan> It might not be bad as a placeholder.
[20:28] <flan> We don't have much time left, and a spinner's less important than having a clean codebase.
[20:28] <flan> Making that one work wouldn't be hard, but it'd take time that might be better spent elsehwree at this point.
[20:29] <flan> (It'd basically be a matter of loading the image, splitting it into pieces, and blitting those to a widget at regular intervals)
[20:29] <jenkins> I will post a screenshot when I can make the spinner work again :) I lost the file with it in
[20:30] <flan> If it's not hyper-critical, leave it aside and focus on functionality.
[20:30] <flan> We can pack a widget into the box during the pre-Maverick cycle.
[20:30] <flan> We'll be using that period as a buffer for testing and polish anyway. (unfortunately)
[20:30] <flan> (Stupid me-moving)
[20:32] <jenkins> http://imagebin.org/111927
[20:33] <flan> Looks fine to me. Until we have time to do something better.
[20:33] <flan> But that one has the advantage of improving authomatically.
[20:33] <flan> As GTK gets better (or the user gets better themes for the engine), the spinner should look better, too.
[20:34] <jenkins> I need to work out this whole inheritance thing. Can i use the inheritance thing to import a spinner and a text box into the space of the tables whilst the data is being downlaoded?
[20:34] <flan> Re-inventing the wheel (literally) may be counter-productive here.
[20:34] <jenkins> well there is a better spinner in evolution and other programs
[20:34] <flan> Y...es... but probabky not the way you're imagining it.
[20:35] <flan> You'll probably want a library of UI eyecandy for that.
[20:35] <flan> With functions you can call that return appropriate GTK objects to pack into boxes.
[20:35] <flan> Data's going to download pretty fast now.
[20:36] <jenkins> ok I will leave them out for now
[20:36] <flan> The whole bzr layer's gone and it's running in SQLite/filesystem stuff.
[20:36] <flan> It should be no slower than the time it takes to ping, plus a millisecond or ten.
[20:37] <flan> http://flan.uguu.ca:5000/ump/10-04/en_CA/_progress However long it takes for you to download this is how long the user'd need to wait to get data from the network.
[20:37] <jenkins> cool that is fast so how do i get the data into the program?
[20:39] <flan> http://pastebin.com/PvJiGeKv
[20:39] <flan> It'll be faster once I turn off debug mode ont he server.
[20:40] <flan> Just create a session using one of the two profvided functions and then call query_progress().
[20:40] <flan> It returns data in much the same way as the old system.
[20:40] <flan> (needed, pending, accepted)
[20:40] <flan> The main difference is that you'll get both a localized friendly name and the internal system name.
[20:41] <flan> The user needs to see the friendly name, while the server needs to get the system name in any upload/download requests.
[20:42] <jenkins> which provided functions?
[20:42] <flan> client/__init__.py They're near the bottom.
[20:42] <flan> Everything's documented.
[20:43] <flan> Put client/ into a lib/ directory and import it as 'lib/client'.
[20:43] <flan> You can rename it if you want.
[20:43] <flan> Er...
[20:43] <flan> lib/client*
[20:43] <flan> lib.client*
[20:43]  * flan eats keyboard.
[20:44] <jenkins> ok thanks I will have a read and paly
[20:44] <flan> Usage samples can be found in r142 on the server branch.
[20:45] <flan> It'll provide details like screen resolution, too.
[20:45] <flan> It's worth playing around with the library from an interpreter.
[20:46] <jenkins> will do
[21:28] <jenkins> night all, thanks for you help flan
[21:28] <flan> G'night~
[21:28]  * flan pushes support for rejecting screenshots.
[21:28] <flan> Just two more features left~
[21:29] <flan> Aww... He left too quickly. :(
[23:03] <flan> QS server's effectively done. Yay.
[23:04] <flan> Just need to comment it all (hundreds of functions!) and get feedback from real users... which, unfortunately, won't happen until it's actually needed.
[23:04] <flan> Hooray for moving!
[23:08] <flan> godbyk, it seems I have no trouble hosting it from home, and I still need to write a couple of support scripts and document how to host it on something common, like mod_wsgi, so I'll probably just run the site through this cycle. It'll make it easier to fix any bugs that might come up, too.
[23:10] <flan> If hosting from home becomes an issue, I'll move it to my webhost or put it on one of my Debian boxes at work and bounce DNS from my host.
[23:11] <flan> (Or let you set up a DNS record for it)
[23:11] <flan> (Which we could also do for hosting from home, if you want things to look consistent)
[23:11] <flan> (Just cname against hamsterx.homelinux.org, since my home IP is technically dynamic)


[01:47] <mark0> hey guys
[02:04] <jak2000> i want clone a hard disk to other how to do? i try download ubuntu64.iso and with unebotin install on a usb, start from the usb, but not give me the option of try or start ubuntu from usb. any advice?
[07:43] <MACscr> Any ideas my bond isnt working correctly? host is ubuntu 14.04 lts. http://pastie.org/10549923. Traffic on the bond stops working if mlx2 has no physical connection
[07:43] <MACscr> bond should be a bit more resilient than that i would hope
[09:49] <lordievader> Good morning.
[11:56] <jgjl> Hi, the "isolcpus" boot parameter does not seem to have any effect in Ubuntu 15.04 server.
[11:57] <jgjl> I set isolcpus=4-23,28-47 in the kernel, but cat "/proc/$$/status|tail -6" still gives me "Cpus_allowed_list: 0-47"
[11:57] <jgjl> Any ideas?
[12:56] <jgjl> Found the cause of the issue, "/proc/$$/status|tail -6" is not the right approach to check if "isolcpus" works, "sysctl -a | grep sched" does the trick
[12:59] <jgjl> however, isolcpus still does not work
[15:02] <mark0> morning all
[15:03] <mark0> do you guys do burn-in for new file server drives? I'm looking at running SMART long test then badblocks but it sounds like badblocks could take two full days or longer to run on 4tb drives
[15:09] <ikonia> burn in ?
[15:09] <ikonia> just plug them in and use them
[15:10] <mark0> I had read a few different guides that advised running burn-in tests to make sure the HDDs don't fail right off the bat
[15:10] <ikonia> just plug them in and use them
[15:50] <The_Shade>   hi
[18:32] <jimmy51v_> hello, i'm trying to install ubuntu server 14.04 under qemu.  installer errors with ""failed to load installer component" loading apt-cdrom-setup failed for unknown reasons" after a while.  is there some log i can look at to figure out why?
[18:34] <jimmy51v_> nothing in /var/log
[18:34] <jimmy51v_> other than syslog
[18:43] <arcsky> question guys, ist possible that sudo apt-get install gnome. reboots after its finished? if not can ubuntu reboot its self like windows updates do sometimes?
[18:43] <bekks> arcsky: No. No.
[18:45] <jimmy51v_> you can make it reboot if you want, i guess
[18:45] <bekks> No.
[18:45] <jimmy51v_> something like sudo apt-get install gnome && sudo reboot or whatever
[18:45] <dave4925> set a timer to reboot after 5 hours ;)
[18:45] <jimmy51v_> bekks: why not?
[18:45] <dave4925> I think you can cron it
[18:46] <arcsky> possible to check why machine got rebooted?
[18:46] <bekks> jimmy51v_: && is onvoking a second command after finishing apt-get. so no, there is no way to tell apt-get to reboot after installing updates. sudo reboot is a second command. :)
[18:46] <dave4925> it's just not developed to do that but it sounds like a good idea for the desktop environment
[18:46] <bekks> arcsky: Take a look at the logs.
[18:46] <bekks> dave4925: It sounds like a pretty pointless idea. No reboot is necessary except for kernel updates.
[18:48] <dave4925> bekks some apps really need a reboot but don't tell you.  If I'm on desktop I just reboot and I see the difference
[18:48] <bekks> dave4925: There is not a single app that requires a reboot in linux.
[18:48] <bekks> Not one.
[18:49] <dave4925> yeah that's what they say
[18:49] <bekks> Thats a fact.
[18:49] <dave4925> but guess what there are many devs and they don't all document each interaction
[18:49] <bekks> Which app does require a reboot for you, besides the kernel?
[18:49] <dave4925> it's just what I've noticed on desktop
[18:49] <bekks> NAme the particular app please :)
[18:50] <dave4925> I don't remember the particular ones there are thousands and I just told you my general experience.  It's been on desktop and not server
[18:51] <bekks> There is not a single app which requires a reboot. Only the kernel cannot be updated while it is loaded.
[18:51] <tarpman> some libraries i.e. openssl trigger update-notifier to recommend a reboot, to be 100% sure no running process still has the old image
[18:51] <tarpman> that's different from "requiring" a reboot, of course
[18:51] <dave4925> sometimes you just have to reload the UI to get things working proper
[18:51] <bekks> dave4925: Reloading the UI does not require a reboot.
[18:52] <jimmy51v_> RAM
[18:52] <bekks> RAM what? :)
[18:52] <jimmy51v_> my issue was RAM.  i needed to specify 512MB of RAM for my VM.
[18:53] <jimmy51v_> the installer crapped out with whatever the qemu/kvm default was
[18:54] <dave4925> I know rebooting is a major thing on a server but on a single user desktop whats the deal
[18:55] <bekks> Nothing's the deal. There is just nothing besides the kernel requiring an update.
[18:55] <bekks> s/update/reboot/.
[22:07] <teward> rbasak: still around/alive?
[22:27] <teward> rbasak: regarding the dpkg-divert and the nginx package, Appendix G is restated in Debian Package Policy 10.7.4 - diversions are not appropriate.  So, I've "Won't Fix"'d it on that point, and because the bug poster agrees it should be handled in Debian first.  Though, what they're trying to do appears to be policy violation.
[22:30] <teward> (no more actions from me on this)
[22:31] <teward> rbasak: you also can't isolate nginx-full, etc. from nginx-common - that would break everything.  They'd have to spin their own packages at that point to really make it work the way they need.
[22:40] <arcsky> my Vnc is just grey when i try to connect to it.  i did started it with sudo tightvncserver :1 -geometry 800x600 -depth 24
[22:42] <bekks> arcsky: what did you expect?
[22:48] <arcsky> gnome
[22:48] <arcsky> i got it to work. http://broderick-tech.com/vncxstartup-files-ubuntu-14-04/