[12:43] <gustavonarea> Hello, everyone. I have a Toshiba Satellite L35 laptop and it doesn't work with the latest kernel versions in Gutsy (either X or KDM/GDM don't start). It does work with Feisty's latest kernel. Do you want me to report this bug right now or would you prefer to try to solve this now?
[12:44] <nixternal> gustavonarea:
[12:44] <Riddell> stgraber: DVD OEM installs aren't d-i any more (at last not by default), they should be changed to ubiquity in isotester
[12:44] <nixternal> hey, that laptop has an ati x1300 or something right?
[12:45] <gustavonarea> nixternal: yes, it has an ati
[12:45] <nixternal> gustavonarea: what a huge coincidence, mjg59 just helped me on Sunday fix that same exact issue
[12:46] <nixternal> gustavonarea: bug #144297
[12:46] <ubotu> Launchpad bug 144297 in xserver-xorg-video-ati "[Gutsy]  ATI (Radeon) and Linux 2.6.22 will not start" [Undecided,New]  https://launchpad.net/bugs/144297
[12:46] <nixternal> it is a known bug, if you could, comment you have the same problem, and see if the fix I included in the report works for you as well
[12:47] <gustavonarea> nixternal: OK... Thank you very much!
[12:47] <nixternal> no problem...
[12:58] <gustavonarea> exit
[01:10] <Riddell> bryce_: about?
[01:10] <bryce_> yup
[01:13] <Riddell> bryce_: I'm after some details of bullet proof x
[01:13] <Riddell> what does gdm call when it notices X has failed?
[01:14] <Riddell> bryce_: maelcum here is looking at the relevant code in kdm that might be able to do what gdm does now
[01:14] <maelcum> so, about bullet-proof X for kdm... what do you need?
[01:15] <Riddell> hmm, he was awake a moment ago
[01:16] <bryce_> heya maelcum
[01:16] <slangasek> ogra: there's currently no mention of Edubuntu-specific improvements in https://wiki.ubuntu.com/GutsyGibbon/Beta; was this deliberate because we want a separate Edubuntu page like the one for Kubuntu, or is this an oversight I should correct now?
[01:16] <maelcum> hey bryce_. i guess kdm should run some script and then try to start X again, right?
[01:16] <bryce_> gdm calls /etc/gdm/failsafeXServer
[01:17] <bryce_> essentially yes; the failsafeXServer kicks in, shuts down gdm, does its gui thing, then restarts gdm
[01:17] <maelcum> ok, pretty easy. that would be /etc/kde3/kdm/failsafeXServer then
[01:17] <bryce_> we'll need to modify that script to be kdm aware, but yes essentially we just need to have kdm run that script
[01:18] <bryce_> fwiw, the only reason I had to shut down gdm is because gdm has a rudimentary failsafe handler in it, that was getting in the road
[01:18] <maelcum> ok, i was wondering. that should be fixable in kdm
[01:18] <bryce_> so if kdm is quiescent it may not need to be shut down
[01:19] <bryce_> however you'll probably want to have kdm do whatever it needs to do to start using the new xorg.conf
[01:19] <maelcum> the path to failsafeXServer should probably not be hardcoded if this is to be more than a distro-specific hack
[01:21] <bryce_> there's also a couple gdm-isms in /etc/gdm/failsafeXinit that'd need altered
[01:22] <bryce_> I would like to think we could logic around these to make the same scripts work for both kdm and gdm
[01:23] <bryce_> but probably it'd be easiest to just hack them to make them all work kdm-specifically, and then see how different the scripts end up, and look into re-merging at that point
[01:23] <maelcum> passing -config <failsafe-config-file> to the X server should work to temporarily replace its configuration without any hacks
[01:24] <maelcum> now we need to figure out how to tell it to load a certain app
[01:24] <bryce_> some of the behavior could also be improved, such as if the hardware can't do vesa (or anything else), bulletproof-x can get stuck in a loop; however I'm not sure how to detect this situation cleanly yet
[01:24] <bryce_> you can specify X to start with a client, and then pass it an init script that runs displayconfig-gtk
[01:25] <maelcum> that's almost trivial to implement - just changet the command-line options of X and run it again
[01:26] <bryce_> yup
[01:26] <bryce_> er, maybe
[01:26] <maelcum> try to start again two times, run failsafe again if it doesn't work and so on
[01:27] <maelcum> there are always unforeseen difficulties
[01:27] <maelcum> of course
[01:27] <maelcum> bryce_: until when do you need the feature?
[01:28] <bryce_> do you mean the kdm feature?
[01:28] <maelcum> yo
[01:29] <bryce_> hmm, it's actually a bit late already, but since it's a kubuntu thing, I'd defer to Riddell's judgment on this
[01:29] <Riddell> unless it's especially trivial it's too late for gutsy
[01:30] <bryce_> yeah
[01:30] <Riddell> so any time in the next 6 months is great
[01:30] <bryce_> so, then aim for Hardy feature freeze :-)
[01:33] <maelcum> that sounds very doable
[02:01] <Pici> Suggestion: Change the deskbar screenshot on https://wiki.ubuntu.com/GutsyGibbon/Beta to properly reflect the actual deskbar behavior.
[02:33] <slangasek> initial feisty->gutsy upgrade guide committed at <https://help.ubuntu.com/community/GutsyUpgrades>; could someone confirm whether the Kubuntu upgrade rules still make sense?
[02:35] <slangasek> Riddell: can you confirm that those upgrade steps still apply for kubuntu feisty->gutsy? ^^
[02:35] <Riddell> slangasek: needs some changes, can I edit?
[02:36] <slangasek> Riddell: please :)
[02:40] <therethinker> hm... for some reason, the update-manager -d doesn't do anything special -- upgrading wise
[02:42] <therethinker> never mind, I'm stupid
[02:47] <nemik> can anyone run ekiga and have it work with any SIP without crashing?
[02:49] <sladen> nemik: that doesn't.  what matters is if /you/ run /ekiga/ and it crashes.
[02:49] <nemik> yea, it crashes hard
[02:50] <nemik> ekiga: symbol lookup error: /usr/lib/libopal.so.2.2: undefined symbol: _ZN11PSafeObjectC2Ev
[02:50] <nemik> looks like other people have the problem but haven't seen anything for resolution yet
[02:51] <sladen> nemik: https://launchpad.net/ubuntu/+source/ekiga/+filebug
[02:51] <slangasek> so far, the proposed resolution is a no-change rebuild of both libopal and ekiga
[02:53] <nemik> ah ok. seems to be taken care of a few days ago. then just some time to make it into repos/
[02:55] <Riddell> slangasek: done
[02:56] <slangasek> Riddell: cheers
[04:20] <tonyyarusso> Hi, I just noticed the package perl-suid, in main, has the note "Usage of this program is now strongly deprecated upstream and support (along with this package) will probably be removed in 5.10." in the description, but I see it still exists in Gutsy.
[04:20] <bryce_> cjwatson: I think I have a strong lead on bug 127008
[04:20] <ubotu> Launchpad bug 127008 in xresprobe "Alternate install of Tribe-4 corrupts video display when installing packages (affected hardware includes Santa Rosa)" [High,In progress]  https://launchpad.net/bugs/127008
[04:20] <cjwatson> great
[04:21] <cjwatson> tonyyarusso: it means perl 5.10, not Ubuntu 5.10
[04:21] <tonyyarusso> cjwatson: Aaaah.  Makes a lot more sense then.
[04:21] <bryce_> cjwatson: it occurs only on laptops, but I found I can reproduce it on my new 965 desktop, however *only* during installation
[04:22] <bryce_> is there something unique about Xorg while in the alternate installer environment, compared with a normal session?
[04:22] <bryce_> essentially, what's going on is this is getting called:  /usr/bin/Xorg :67 -ac -probeonly -logfile "$TMPLOG" -config "$TMPCONF"
[04:23] <bryce_> this seems to work fine after installation, but while in the alternate installation session it causes those blocks on intel
[04:23] <cjwatson> there's really nothing unique, apart from the fact that the system is still being put together
[04:23] <cjwatson> certainly /usr/bin/Xorg is the same
[04:23] <cjwatson> /dev etc. should be bind-mounted
[04:24] <bryce_> I think I can put in an exception for intel laptops to not attempt this, but I'd also like to get this reported upstream, if I can demonstrate it independently of our installer environment
[04:24] <bryce_> I'm wondering if there's some framebuffer magic going on
[04:26] <mjg59> The alternate installer uses vga16fb
[04:27] <bryce_> mjg59: is there a way I could start a vga16fb session from a post-install session?
[04:28] <mjg59> modprobe vga16fb
[04:28] <mjg59> (make sure you do that from a console, not X!)
[04:33] <bryce_> ok thanks
[04:36] <bryce_> hmm, not seeing the bug.
[04:40] <cjwatson> bryce_: you might need to make sure vesafb isn't loaded
[04:41] <cjwatson> which might involve booting without splash
[04:43] <mjg59> cjwatson: No, we never use vesafb
[04:44] <mjg59> Unless vga= is passed to the kernel, which isn't the default
[04:46] <bryce_> hmm, I tried booting without splash, modprobe fbcon vga16fb, but still no bug
[04:47] <bryce_> ok, going to go think about it over dinner.  bbiab
[05:24] <tripzero> anyone know what package sets up the xorg.conf in gutsy?
[05:24] <tripzero> (in the livecd)
[05:24] <cjwatson> tripzero: the live CD boot code just calls dpkg-reconfigure xserver-xorg, so the same package as usual
[05:25] <cjwatson> (i.e. xserver-xorg, the xorg source package if you're looking to file a bug)
[05:25] <tripzero> ahh, okay
[06:44] <slangasek> BenC: do you still need more info than what's there for bug #123617?
[06:44] <ubotu> Launchpad bug 123617 in linux-source-2.6.22 "Can't boot unless passing "irqpoll" option to the kernel" [High,Incomplete]  https://launchpad.net/bugs/123617
[07:35] <dholbach> good morning
[07:35] <slangasek> 'morning
[07:35] <dholbach> hey slangasek
[07:42] <superm1> bryce_, you here?
[07:43] <bryce_> yup
[07:44] <pitti> Good morning
[07:44] <superm1> i was looking to test bulletproof x on the mythbuntu disks/setups, but its not coming up?  In our gdm-cdd.conf i've added the line  FailsafeXServer=/etc/gdm/failsafeXServer
[07:44] <superm1> .  is there anything more that is supposed to be done for it?
[07:45] <superm1> displayconfig-gtk is in our seed and installed
[07:45] <StevenK> Morning pitti
[08:01] <bryce_> superm1: that should do it
[08:02] <bryce_> superm1: what's happening instead?  is gdm starting up ok, or is it failing?
[08:02] <superm1> bryce_, well it's appearing that the xorg.conf.failsafe isn't bringing up X.
[08:02] <superm1> its just coming back to a terminal
[08:02] <superm1> /var/log/Xorg.0log is coming up with (EE) No devices detected.
[08:03] <bryce_> it should say why in /var/log/Xorg.0.log
[08:03] <superm1> no screens found
[08:03] <viviersf> Mithrandir, is unionfs fix these days ?
[08:04] <superm1> bryce_, also with a warning (WW) VESA: No matching Device section for instance (BusID PCI:0:2:0) found
[08:04] <bryce_> check the busid
[08:04] <superm1> it is indeed 0:2:0
[08:04] <superm1> according to lspci
[08:04] <bryce_> hmmm
[08:05] <superm1> however if i look at the /etc/X11/xorg.conf.failsafe that was made
[08:05] <superm1> its listing the busid at 1:0:0
[08:05] <bryce_> ah, then that's the problem
[08:05] <superm1> problem being on our side or yours :)?
[08:06] <bryce_> the problem being with @*%$ debconf
[08:07] <superm1> i'm assuming at some point the busid is stored in debconf and then recovered when building xorg.conf.failsafe?
[08:07] <bryce_> right
[08:07] <superm1> why can't you detect it dynamically?
[08:07] <superm1> when you build the xorg.conf.failsafe
[08:08] <bryce_> you can confirm this by running dexconf -o /tmp/xorg.conf
[08:09] <superm1> yup same busid
[08:09] <superm1> 1:0:0
[08:09] <bryce_> I had found it sometimes gives 0:5:0 when it has no clue
[08:10] <superm1> well now i might have some further insight into this though
[08:10] <bryce_> apparently it can also return 1:0:0 when it doesn't know
[08:10] <superm1> this live disk was built on my laptop from our debootstrap/chroot script
[08:10] <superm1> and my busid for my graphics card is 1:0:0, but in the virtual machine i booted and am testing on its different
[08:10] <bryce_> I can put in another exception to ignore 1:0:0 in addition to 0:5:0, if you think this is a common thing, and not specific to mythtv
[08:11] <superm1> so at what point is that busid filled?  when a certain package is installed? (Perhaps when we debootstrap/chroot the disk)?
[08:11] <bryce_> debconf fills in everything during xorg-server postinit time
[08:12] <bryce_> so pretty early on in installation
[08:12] <superm1> so how is this avoided when building the normal ubuntu disks then?
[08:13] <superm1> you would think that the machine producing those disks would also put it's information into debconf
[08:15] <bryce_> that would be nice
[08:16] <superm1> which?
[08:16] <bryce_> I think when building the normal ubuntu disks, it just happens that the bus id is going to be identical in both cases
[08:17] <superm1> well perhaps a hook for d-i and ubiquity would be a good idea
[08:17] <superm1> to watch for busid
[08:17] <superm1> and update it in debconf before the reboot
[08:18] <superm1> either that or if you could dynamically determine the video devices available rather than relying on debconf when you generate that xorg.conf.failsafe
[08:18] <superm1> is there a technical reason why that's not feasible?
[08:19] <bryce_> in theory I should not need to specify the bus id at all; xorg should be able to autodetect that itself
[08:19] <bryce_> in testing, though, I found on a couple machines that it'd fail without it
[08:20] <superm1> oh that's very unfortunate
[08:20] <bryce_> I decided rather than invent my own bus id detector, to keep things as parallel to dexconf as possible
[08:21] <superm1> what types of machine combos were you coming across that would fail w/o it?
[08:22] <bryce_> iirc, it failed on my amd64 dell box
[08:23] <bryce_> I think it failed on my old thinkpad, however it since lost its harddrive so I've not re-tested it lately
[08:24] <bryce_> wait, the amd64 case was where it was getting detected as 0:5:0; that case worked properly when I didn't use a bus id
[08:24] <superm1> i see
[08:24] <bryce_> the thinkpad's pretty old - a T20
[08:24] <superm1> yeah i was gonna say, on machines 1-3 years old that i've dealt with, i usually dont define a busid in there anyhow
[08:24] <superm1> in case i move cards around
[08:24] <superm1> and i've been fine
[08:27] <superm1> bryce_, with your current solution, things do break then also if someone moves a card to another slot then right?
[08:30] <bryce_> superm1: possibly; I wonder how common that will be though
[08:31] <superm1> bryce_, well how would this sound for a solution?  By default write out the config with no busid, and should things still not come out without the busid, write out a new config that contains one?
[08:32] <superm1> it would cover most people from the first case at least, and the others would just have a longer time booting up into the bulletproof-x env than the first group
[08:32] <bryce_> I don't have an easy way of detecting a sequence of failed boots
[08:32] <superm1> oic
[08:33] <bryce_> gdm carries no state between different failsafeXServer calls
[08:35] <superm1> what about writing out two device sections?
[08:35] <superm1> one with busid and one without
[08:35] <bryce_> would that work?
[08:36] <Mithrandir> viviersf: unionfs should be fixed now, yes.
[08:36] <liw> does Ubuntu have a page like http://www.debian.org/distrib/packages to search existing packages (so that one can check, for example, whether a particular program is included)?
[08:36] <bryce_> like packages.ubuntu.com ?
[08:36] <ScottK> You mean like packages.ubuntu.com?
[08:37] <superm1> broonie, well you would need multiple screens defined too then i would think
[08:37] <superm1> oops bryce_ ^
[08:37] <liw> ok, how does one find out about packages.ubuntu.com? :)
[08:37] <pitti> Mithrandir: it's not fully fixed unfortunately
[08:38] <Mithrandir> pitti: it's not?
[08:39] <pitti> Mithrandir: we still got quite a lot of unionfs oopses recently, especially in edubuntu
[08:39] <pitti> Mithrandir: bug 144945 et al
[08:39] <ubotu> Launchpad bug 144945 in linux-ubuntu-modules-2.6.22 "kernel Oops in unionfs with l-u-m version 2.6.22-12.32 using Edubuntu amd64 daily 200709025" [High,New]  https://launchpad.net/bugs/144945
[08:39] <pitti> and last night in #ubuntu-testing with the very latest images (from stgraber)
[08:40] <Mithrandir> pitti: hm, ok.
[08:40] <stgraber> morning
[08:44] <superm1> bryce_, well if you define two devices, screens,monitors, and server layouts, that can work.  is there a way to make it try both server layouts though?
[08:44] <superm1> i can only get it to use one of them
[09:02] <bryce_> superm1: honestly the simplest solution would probably be to just drop the bus id stuff
[09:03] <bryce_> unfortunately I think it's with older hardware where bulletproof-x has the most utility
[09:03] <bryce_> newer stuff tends to get autodetected okay
[09:03] <superm1> i'm still a bit surprised that there is "any" hardware that can't at least detect busid
[09:03] <superm1> X -scanpci will still identify it as video hardware
[09:03] <superm1> will it not?
[09:04] <bryce_> unfortunately I don't have an easy way to test that
[09:05] <pwnguin> lspci -nn | grep VGA seems to work for me, but im guessing you guys have edge cases or something
[09:05] <bryce_> I thought about that, but it felt too hackish to me
[09:05] <fabbione> pwnguin: that won't work
[09:05] <bryce_> for instance, what if you have multiple vga cards?
[09:05] <fabbione> exactly
[09:05] <fabbione> i recall when we had to hack around that stuff
[09:06] <superm1> well how does bulletproof-x handle that right now?
[09:06] <fabbione> it's not as easy as it sounds
[09:06] <superm1> configure both cards?
[09:06] <bryce_> no, it takes the one that debconf says to use
[09:06] <fabbione> superm1: you can't. there are limitations of what you can do when X is not running to detect
[09:06] <pwnguin> fabbione: select the one with the lowest pci id?
[09:06] <fabbione> pwnguin: and what guarantee do you have that it is the one in use?
[09:07] <fabbione> no you can override that in most BIOs by selecting PCI/AGP first
[09:07] <fabbione> it's really tricky
[09:07] <bryce_> pwnguin: it could easily be that the user added a higher power card because s/he didn't like the on-board video
[09:07] <pitti> nixternal, Riddell, Hobbsee: Kubuntu page is still in the works? the strigi section has some broken formatting
[09:07] <pwnguin> ah, i suppose thats a point to consider
[09:07] <superm1> have you considered just offering a poll up on the forums?  you'd get a pretty wide audience at least.  Just ask folks to take out the busid line of xorg.conf, and see if things work, and post their hardware that doesn't work with it missing
[09:07] <pwnguin> i was thinking of those people with two cards because they love xinearama
[09:07] <Hobbsee> pitti: oh damn it, the US people are sleeping *again*?
[09:07] <pwnguin> or SLI
[09:07] <superm1> you could at least start to build a blacklist database that way
[09:07] <pitti> nixternal, Riddell, Hobbsee: and it doesn't have any download links, is that intended?
[09:07] <pwnguin> at which point, i think they can figure out xorg.conf on their own =/
[09:08] <Hobbsee> pitti: got no idea, i havent spoken to nixternal
[09:08] <fabbione> what bryce_ is doing is the safest
[09:08] <fabbione> have been tested for years and it's basically the only way to go
[09:08] <bryce_> heh, well now you understand why I favored to stick close to what dexconf already does - figured others had sorted out all these decisions for me ;-)
[09:08] <superm1> heh :)
[09:08] <fabbione> bryce_: daniels and I did spend months trying to get that right
[09:09] <fabbione> that's the closest we could get with automatic detection
[09:09] <bryce_> fabbione: yup
[09:09] <superm1> well regarding my original concern then, on a fresh install, how is that debconf first filled in then right now if there is no d-i hook for it
[09:09] <pwnguin> how do the other distros fare with autodetection?
[09:10] <superm1> assuming you are using a disk built from the datacentre
[09:10] <bryce_> fabbione: although Xorg does a much better job figuring these things out these days
[09:10] <stgraber> pitti: hmm, that's weird you advertise the new thin client capatibilities but they don't work with beta (and the bug isn't in the caveats part)
[09:10] <fabbione> bryce_: yes.. but that requires you to fire up X. we didn't really have that option at the time
[09:11] <pitti> stgraber: it'll go to the caveats
[09:11] <fabbione> bryce_: http://people.ubuntu.com/~fabbione/IMG_0342.JPG
[09:11] <pitti> stgraber: the workaround is to fix /e/n/i manually, right?
[09:11] <fabbione> bryce_: note 2 things: it's dead dark outside.. and how long is our beard after 15 days of hacking in the same room (daniel on the left.. me on the right)
[09:12] <fabbione> bryce_: that was the first Ubuntu X spring
[09:12] <fabbione> sprint
[09:12] <pwnguin> sounds less like a sprint and more like a marathon
[09:12] <fabbione> now.. next one that will want to fix the PCI-ID thingy.. needs to prove that it can do better and grow longer beard :)
[09:12] <bryce_> heh, like a couple of sasquatches ;-)
[09:12] <fabbione> pwnguin: it was
[09:19] <fabbione> oh hmmm... minor bug in tasksel
[09:20] <stgraber> pitti: yes, but the comes the ssh issue, so you'd have to fix ethX + update the SSH known host (there is a command for that) + rebuild the ltsp image
[09:20] <stgraber> then
[09:21] <pitti> stgraber: hm, so we should just declare thin client booting as broken for beta
[09:24] <stgraber> I think that's the easiest yes
[09:24] <stgraber> as it's not "easy" to fix it
[09:24] <stgraber> for someone who doesn't know how the whole ltsp stuff works
[09:24] <pitti> stgraber: what's the bug# for the ssh issue?
[09:24] <pwnguin> maybe dave jones has an opinion on how to scan for bus IDs?
[09:24] <pwnguin> i seem to recall him really hating X's user space intelligence
[09:25] <pwnguin> "stupid things in userspace" if i recall
[09:26] <fabbione> X itself opens /dev/kmem just to scan pci.. that's not clever either
[09:26] <fabbione> or at least it used to do it
[09:26] <fabbione> only the very last reason why X had to run as root
[09:31] <pitti> fabbione: that should only happen once, though? so in theory it could drop to nobody after opening /dev/kmem?
[09:31] <pitti> fabbione: well, I guess lots of device drivers need root
[09:34] <fabbione> pitti: i don't recall all the details anymore...
[09:37] <stgraber> pitti: can't find it, I'll ping ogra when he's back to see if he reported it
[09:38] <cjwatson> superm1: don't think about d-i hooks. d-i calls pkgsel which calls tasksel which calls apt-get install <stuff including xserver-xorg>, and xserver-xorg generates xorg.conf all by itself (using debconf defaults, autodetection, etc.)
[09:38] <cjwatson> superm1: d-i is several steps removed from xorg.conf generation and never goes anywhere near it
[09:38] <cjwatson> (quite deliberately)
[09:39] <superm1> cjwatson, where would a hook fit most appropriately then for that to at least store the correct busid?
[09:39] <cjwatson> superm1: that does not belong in d-i
[09:39] <cjwatson> anything to do with the bus id should be done in the xserver-xorg package
[09:39] <superm1> perhaps a deliberate call to reconfigure xserver-xorg instead then?
[09:39] <cjwatson> no
[09:40] <cjwatson> it's configured from scratch already, you don't need to reconfigure it
[09:40] <superm1> well the issue that i'm seeing is that it is being configured with the busid information from the system it was built on (in the debootstrap/chroot)
[09:41] <cjwatson> superm1: you realise that casper already reconfigures X?
[09:41] <cjwatson> superm1: (and if you're talking about mythbuntu, leave d-i out of it)
[09:42] <superm1> cjwatson, yeah i realize that.  is casper supposed to be storing the new information it got from reconfiguring X in debconf then?
[09:42] <cjwatson> I think it would help if you read debconf-devel(7) end to end first
[09:42] <cjwatson> it isn't casper's responsibility to store that in debconf. The package does that all by itself
[09:43] <cjwatson> and if its reconfiguring logic is wrong, it should be fixed
[09:43] <cjwatson> don't go hacking around adding hooks
[09:44] <superm1> well i'm not planning on doing so. i'm still trying to determine which package then is actually storing the correct busid in debconf then other than xserver-xorg
[09:44] <cjwatson> it's very simple, 'dpkg-reconfigure -fnoninteractive xserver-xorg' as called from casper should cause it to configure itself for the current system
[09:44] <cjwatson> superm1: xserver-xorg is the only thing that stores that value that I'm aware of; the value in debconf is for use only by xserver-xorg
[09:44] <pwnguin> superm1: could the answer be none? i sometimes get the wrong answer =/
[09:45] <superm1> that's what i had thought
[09:45] <cjwatson> superm1: I think you're sort of mixed up about how debconf is involved
[09:46] <cjwatson> individual packages provide their own templates to debconf, which may contain default values
[09:46] <cjwatson> they may also set values at run-time
[09:46] <superm1> right
[09:46] <cjwatson> in normal operation their interaction with debconf is self-contained
[09:47] <cjwatson> that however doesn't stop them from detecting things from the current system and setting them in the debconf database (and then pulling them out again and using them to generate configuration files) in the absence of user input
[09:48] <superm1> well my confusion was that i didn't realize that casper was actually supposed to be updating these items by calling upon dpkg-reconfigure
[09:48] <cjwatson> the self-contained bit is important though and for some reason people seem to have particular trouble with this where X is concerned
[09:48] <cjwatson> casper doesn't get any information when it reconfigures X
[09:48] <cjwatson> it tells X to reconfigure, and the result is an updated xorg.conf
[09:49] <cjwatson> casper never looks at that
[09:49] <cjwatson> it simply trusts that it is done correctly
[09:49] <cjwatson> similarly it seems to be common to think that the installer is responsible for generating xorg.conf - it isn't, because the X packages themselves stand a much better chance of doing that correctly :)
[09:50] <cjwatson> ubiquity copies over xorg.conf from the live filesystem, but ultimately that still comes from xserver-xorg
[09:50] <superm1> i think i need to more throughly read xserver-xorg's postinst
[09:51] <superm1> which i understood previously, (regarding how the xorg.conf was generated)
[09:51] <cjwatson> now, it appears to be possible to preseed xserver-xorg/config/device/bus_id to force the bus ID to something else
[09:51] <cjwatson> BUT
[09:52] <cjwatson> it sounds like your problem is that a value of the bus ID from a previous run on the same filesystem (though possibly different monitor etc.) is kicking around, and that isn't the sort of problem you can solve by preseeding
[09:52] <cjwatson> it would be a straight bug in reconfiguration logic, i.e. not reconfiguring properly
[09:53] <superm1> yeah, preseeding is not the solution to this problem
[09:54] <superm1> which would again bring me back to reading that postinst to track if i can catch where things are going wrong in the reconfiguration logic :)
[10:22] <mvo> Riddell: if you are interessted, here http://www.pastebin.ca/716414 is a patch that makes kde screen lock under kde work with compiz (http://bugs.opencompositing.org/show_bug.cgi?id=292)
[10:22] <ubotu> bugs.opencompositing.org bug 292 in Core "kdesktop_lock weird behaviour" [Major,New] 
[10:31] <Hobbsee> nvneat
[10:32] <Hobbsee> er, mvo: neat
[10:32] <mvo> hello Hobbsee
[10:32] <Hobbsee> hi mvo
[10:38] <superm1> hi mvo
[10:40] <mvo> hi superm1
[10:40] <superm1> mvo you got a few min to discuss some python-apt stuff?
[10:44] <cjwatson> iwj: did you ever get round to coming up with a better regex for bug 105890?
[10:44] <ubotu> Launchpad bug 105890 in ubiquity "hostname permitted containing consecutive dots" [Low,Confirmed]  https://launchpad.net/bugs/105890
[10:47] <stgraber> soren: ping
[10:49] <soren> stgraber: pong
[10:50] <stgraber> soren: I heard that server team would like to do some testcases change to the tracker, can you add your changes to : bug 145502 ?
[10:50] <ubotu> Launchpad bug 145502 in ubuntu-qa-tracker "Adjust test case entries in tracker" [High,Confirmed]  https://launchpad.net/bugs/145502
[10:52] <soren> stgraber: I think mathiaz was working on something like that.
[10:52] <soren> stgraber: Could you ping him when he shows up? (Usually around 1300 UTC, AFAIR)
[10:52] <stgraber> sure
[10:54] <mvo> Riddell: if you have a moment, could you please have a look at bug #145351? is it enough to comment the debug statements out?
[10:55] <ubotu> Launchpad bug 145351 in update-manager "ERROR not handled expection in KDE frontend: update-manager vanished during upgrade from feisty to gutsy" [Medium,Confirmed]  https://launchpad.net/bugs/145351
[10:56] <mvo> superm1: sorry, disconnected. sure, I'm available
[10:57] <superm1> great.  okay so inside ubiquity there is some internal usage of python apt, and its boiling down to a call of cache.open(None).
[10:57] <superm1> and this call is just hanging
[10:57] <superm1> i traced a littler further in, and its hanging at
[10:57] <superm1>         self._cache = apt_pkg.GetCache(progress)
[10:58] <superm1> so i was wondering if you might have some suggestions as to why there would possibly be a hang happening there
[10:58] <superm1> its not upon every run, however.
[10:59] <cjwatson> mvo: (we call cache.open(None) because it seems to be a reasonably efficient way to get the cache to take account of the commit it just did; we do cache.commit(); cache.open(None); check for broken packages)
[11:00] <mvo> cjwatson, superm1: is there a way to reproduce this for me? if its just for the check-for-broken-packages check, that shouldn't be needed, if the cache.commit() does not throw a error, then all should be fine
[11:00] <cjwatson> IME that hasn't been true
[11:01] <cjwatson> and in any event I want to know which the broken packages are on error
[11:01] <cjwatson> so I catch errors from commit and if there are any or if cache._depcache.BrokenCount > 0 then I display a list of broken packages
[11:02] <pitti> ogra: stgraber mentioned that ltsp thin client booting is broken beyond the persistent-net.rules due to some ssh key stuff; what's the bug# for that? (for caveats)
[11:02] <superm1> mvo, sure i can reproduce this again, it occurs on probably 90% of the runs
[11:03] <ogra> pitti, no bugnumber yet, iuts something i surely wont forget about (just needs a changed order (thin client NIC needs to be configured before we build the client so ssh has a key for the interface)
[11:03] <mvo> cjwatson: there where issues with older versions, but recent versions (~eraly 2006) throw exceptions on error and report the error via the error() callback in the installprogress class. but using open() and checking for borken packages is fine of course too
[11:03] <pitti> ogra: can we have one, for including into the "Caveats" section of the announcement?
[11:03] <ogra> pitti, that bugs me so long altready that i can promise it wont get lost even without a bug :)
[11:03] <mvo> superm1: is there a way for me to reproduce it?
[11:04] <ogra> yeah, i'll file one
[11:04] <pitti> ogra: it's more about providing a place to track it and to explain a workaround for people installing beta
[11:04] <pitti> ogra: thanks
[11:04] <superm1> mvo, yeah, i'd need to get you a copy of one of our dailies though, or you'd need to build one locally
[11:04] <mvo> superm1: if its just cache["foo"] .markInstall(); cache.commit(); cache.open(None) I will try it out and see if I get the hang here too
[11:05] <mvo> superm1: that is fine, just tell me where I can download it
[11:05] <mvo> cjwatson: does that bug happen on ubuntu as well?
[11:05] <esr> Is anyone from the laptop team here?
[11:05] <cjwatson> mvo: I can't say I've seen it but I'm not certain
[11:05] <superm1> its using the same function that normally installs language package in the gtk frontend
[11:06] <cjwatson> mvo: but, as superm1 says, the code is common between the gtk and mythbuntu frontends
[11:06] <esr> I havee two package requests for Gutsy Final related to the Thinkpad X61; I'm wondering where to submit them.
[11:06] <superm1> mvo, okay i'll have to upload it to some webspace tonight, i'll get you a url some time later today after its up
[11:07] <mvo> superm1: do you have a repository url for me so that I can stare at the code a bit?
[11:07] <superm1> mvo, sure
[11:08] <cjwatson> esr: file bugs with the needs-packaging tag (if they aren't there already of course); see https://wiki.ubuntu.com/MOTU/Packages/New
[11:08] <superm1> mvo, https://code.edge.launchpad.net/~mythbuntu/ubiquity/mythbuntu-ubiquity
[11:08] <esr> cjwatson: Thanks, will do.
[11:08] <mvo> superm1: thanks, getting it now
[11:09] <cjwatson> dholbach: I think MOTU/Packages/New should say "is not a trivial process" rather than "is not an easy process". It sounds a bit too forbidding at the moment.
[11:09] <cjwatson> Oh dear me I'm an idiot. Note to self, cdrom != netboot
[11:09] <superm1> mvo, if you follow in to scripts/mythbuntu/mythbuntu_install.py.  that is where the mythbuntu specific stuff is.  it inherits from scripts/install.py
[11:10] <dholbach> cjwatson: will change that
[11:10] <cjwatson> mvo: I'm happy to take simplifications to that stuff if you're very certain that they're post-beta-worthy. :-)
[11:10] <ogra> pitti, bug #145514 (milestoned already)
[11:10] <ubotu> Launchpad bug 145514 in ltsp "interface nonexistent in the installer for ssh key creation" [Undecided,New]  https://launchpad.net/bugs/145514
[11:10] <dholbach> cjwatson: there are much more changes that need to happen there
[11:10] <mvo> superm1: ok, thanks. I give it a go. and it happens 90% of the cases? did it ever worked (is that a regression)?
[11:10] <superm1> yeah it worked as of about a month ago
[11:10] <cjwatson> dholbach: noted, it was just the first thing that came to mind when reading that
[11:10] <dholbach> cjwatson: it makes perfect sense
[11:10] <mvo> cjwatson: heh! post-gutsy ;)
[11:10] <superm1> i'm not sure at what point it broke though, because unionfs has plagued the ability to test
[11:11] <mvo> superm1: oh, hrm, apt/python-apt haven't really changed recently, that is bad(tm)
[11:13] <soren> cjwatson: I added a suggestion to bug 105890.
[11:13] <ubotu> Launchpad bug 105890 in ubiquity "hostname permitted containing consecutive dots" [Low,Confirmed]  https://launchpad.net/bugs/105890
[11:14] <cjwatson> soren: thanks, looks plausible
[11:14] <cjwatson> Would be interested to hear from iwj if I'm missing anything else of course ...
[11:14] <soren> cjwatson: Sure.
[11:14] <cjwatson> soren: (I prefer the second, but then I would. :-))
[11:19] <superm1> mvo, well it's going to be ~2hrs for the upload to finish.  it will show up here: http://uk.cdimages.mythbuntu.org/~superm1/  It is ~441M, so if you can grab after its finished, that'd be great.  During install, just choose any option that will install packages.  i've been just enabling the openchrome driver during install to install xserver-xorg-video-openchrome and remove xserver-xorg-video-via
[11:21] <mvo> superm1: ok,thanks
[11:22] <superm1> mvo, okay i'm going to head to bed for now, i'll be back in a few hours :)
[11:22] <superm1> there is an md5sum up there too to check with
[11:22] <defcon_> where are the beta iso releases for gutsy
[11:23] <mvo> superm1: good night
[11:23] <cjwatson> defcon_: they are expected to be released later today
[11:23] <defcon_> nice
[11:23] <defcon_> where will it be posted? http://cdimage.ubuntu.com/daily/current/?
[11:23] <cjwatson> when the schedule says "27 September", it very deliberately doesn't mention a time :)
[11:23] <cjwatson> defcon_: you should subscribe to the ubuntu-announce mailing list, where links will be posted
[11:24] <defcon_> ok
[11:24] <defcon_> will do
[11:24] <cjwatson> and no, they won't be on /daily/current/
[11:27] <soren> cjwatson: Gah. I updated the regex again. I was missing a few test cases.
[11:34] <defcon_> ok this is a serious bug that effects thousands of people that run the ralink chipsets "https://bugs.launchpad.net/ubuntu/+bug/34902" will this be fixed in gutsy?
[11:35] <ubotu> Launchpad bug 34902 in ubuntu "Ralink Wireless legacy drivers (rt2500 rt61 rt73 rt2570) USB/PCMCIA/PCI hangs PC" [High,Confirmed] 
[11:35] <defcon_> all tribe versions havnt fixed it yet
[11:37] <iwj> cjwatson: No, 'fraid not.
[11:38] <iwj> cjwatson: I see Soren has posted one in a comment but it's not quite correct.
[11:38] <soren> iwj: Not the most recent one, either?
[11:39] <iwj> OTOH it is an improvement.#
[11:39] <iwj> It permits domains ending in `.'.
[11:39] <iwj> Avoiding that is quite tedious.
[11:39] <soren> Quite. I added support for that on purpose :)
[11:39] <soren> Maybe I was missing a bit of context.
[11:40] <soren> It doesn't match the fqdn?
[11:40] <iwj> cjwatson: IMO you should use Soren's regexp from https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/105890/comments/3
[11:40] <ubotu> Launchpad bug 105890 in ubiquity "hostname permitted containing consecutive dots" [Low,Confirmed] 
[11:41] <iwj> soren: "example.com." isn't a valid domain name (in this context, anyway - you shouldn't set your hostname to it).
[11:41] <soren> iwj: Sure. I just thought it was the fqdn that was matched against the regex.
[11:42] <soren> If not, you're absolutely right.
[11:42] <iwj> Err, well, FQDNs ought not to be quoted with trailing . in most contexts.
[11:42] <iwj> soren: I'm afraid I don't seem to follow the point you're making.
[11:43] <soren> iwj: You don't think a proper fqdn ends with a '.'?
[11:44] <iwj> I suppose one could do r'^(([a-z0-9] |[a-z0-9] [a-z0-9-] *[a-z0-9] )\.?)+(?<=\.)$' if Python supports that.
[11:44] <cjwatson> iwj: OK, I don't have to do the whole thing in a single regex so just if not foo.endswith('.') is fine
[11:44] <iwj> soren: Well, the situation is a bit confused, but basically, yes.
[11:44] <iwj> cjwatson: Oh, that's better.  Do that.
[11:45] <soren> iwj: Yes, you don't or yes, you do? :)
[11:45] <iwj> soren: When you pass a name to the resolver, or write it in a zonefile, trailing `.' is treated specially.
[11:46] <soren> iwj: Yes. An fqdn is supposed to be unique. To be sure of its uniqueness, you add the trailing dot. Otherwise things might (rightfully) append other stuff to it.
[11:46] <iwj> But normally trailing `.' just leads to syntactically invalid uses.  For example, if we set the hostname to `host.example.com.' then it will eventually do MAIL FROM:<root@host.example.com.> which is a syntax error.
[11:47] <cjwatson> soren: I don't need your separate '-' test though - it already handles that separately
[11:47] <cjwatson> and throws a separate error
[11:48] <TheMuso> Is there any particular reason why bash-doc ships /usr/share/info/dir.gz? I see that dir and dir.old files exist in /usr/share/info, presumably generated by info to keep a record of the info directory's contents. There are a couple of packages in universe that also ship /usr/share/info/dir.gz, which of course have a file conflict.
[11:48] <TheMuso> Is the best approach to remove the dir.gz file from these packages?
[11:48] <cjwatson> TheMuso: there was a discussion about that in Debian a while back - basically one of the tools was generating dir.gz and so packages ended up shipping it by accident
[11:49] <cjwatson> it would be worth checking at the same time that the info documentation is actually being installed correctly in other ways
[11:49] <soren> iwj: Yes, in that particular case, it's wrong.
[11:49] <TheMuso> cjwatson: Ok.
[11:50] <soren> iwj: I don't know how much value it holds for you, but wikipedia seems to agree with me. "To distinguish an FQDN from a regular domain name, a trailing period is added."
[11:50] <Mirv> defcon_: I think the title of that bug is wrong, but I do hope that someone would upgrade the rt2x00 drivers to the latest 2.0.8 release
[11:50] <iwj> soren: Also, in any case, the user knows none of this.  When the user types the domain name in, most users will just type it.  And the installer knows it's always fq.
[11:51] <cjwatson> I could just have the installer strip any trailing .
[11:51] <iwj> cjwatson: That would work too.
[11:51] <cjwatson> I forget whether netcfg does that
[11:51] <soren> iwj: True.
[11:51] <defcon_> Mirv, same here, where can I find gutsy driver support
[11:51] <soren> iwj: Anyhow, this is turning into a discussion for the sake of the discussion.
[11:51] <soren> ...and I'm getting hungry.
[11:52] <cjwatson> netcfg doesn't appear to, but then it asks for a domain while ubiquity only asks for a hostname
[11:52] <cjwatson> (at least it asks in expert mode if the moon is waning gibbous etc.)
[12:08] <pitti> ogra: do we have a bug now? we need to finalize the announcement, and move it to www.u.c. (which will take ~ 45 minutes)
[12:09] <esr> cjwatson: if you're interested in seeing what your help led to, see http://www.thinkwiki.org/wiki/Installation_instructions_for_the_ThinkPad_X61 and https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadX61 ; I just finished the latter.
[12:10] <esr> X61 support in Gutsy Tribe 5 is actually looking really good.
[12:11] <pitti> ogra: ATM I don't even know what to write there
[12:11] <defcon_> how is the ralink support?
[12:12] <azeem> w32
[12:12] <azeem> bah
[12:12] <esr> The remaining issue is sound.  The X61 neeeds ALSA 1.0.15, whiuch is due out any day now.  When is the package update freeze for Gutsy final?
[12:16] <StevenK> Upstream Version Freeze started a while ago
[12:18] <esr> Ouch.
[12:19] <ogra> pitti, ?
[12:19] <pitti> StevenK: (UVF does not exist any more, will be announced soon)
[12:19] <ogra> pitti, the feature list is on the canonical wiki since weeks ....
[12:20] <esr> Well...1.0.15 is suppised to be a minor bug fix release; I see in your guidelines that merging those is sometimes done after FeatrureFreeze.  Who do I ping about this?
[12:20] <pitti> ogra: I meant for the 'broken ltsp boot' bug
[12:20] <ogra> bug #145514
[12:20] <ubotu> Launchpad bug 145514 in ltsp "interface nonexistent in the installer for ssh key creation" [Undecided,New]  https://launchpad.net/bugs/145514
[12:21] <pitti> ogra: ah, thanks
[12:21] <ogra> pitti, and bug #121547
[12:21] <ubotu> Launchpad bug 121547 in ltsp "[Gutsy]  LTSP chroot building progressbar in d-i hangs" [Low,In progress]  https://launchpad.net/bugs/121547
[12:21] <ogra> these are the two major ones
[12:22] <pitti> ogra: ah, thanks
[12:22] <StevenK> esr: If you want to push to get 1.0.15 into Gutsy, you'll need to have a good reason and show that it is justifible in a bug report.
[12:23] <torkel> isn't there a bug about it already?
[12:23] <esr> I understand.
[12:23] <esr> I'm looking for an existing bug on Launchpad.
[12:23] <mjg59> The necessary code is already in linux-ubuntu-modules
[12:24] <mjg59> However, the speakers are disabled by default
[12:24] <mjg59> I'm looking into that
[12:24] <esr> That update is needed for Lenovo Thinkpads to work.  As popular as those are, I hope that qualifies as a good reason.
[12:24] <sladen> [some]  Lenovo Thinkpads
[12:24] <esr> Recent ones.
[12:24] <mjg59> It's unlikely that we're bringing in the whole of the HDA code from 1.0.15, since last time we tried that (last month) it caused a pile of regressions
[12:24] <esr> Using the AD1984 chipset.
[12:26] <sladen> esr: thing to do is pull out the specific patch that actually fixes your machine---promote that fix
[12:26] <esr> mjg59, I hust installed Gutsy beta today.  Is there some incantation I can mutter to enable the speakers and test if the mess actually works?  If so, I'll add it to the LaptopTestingTeam area.
[12:26] <esr> s/hust/just/
[12:27] <mjg59> Enable all the options in the mixer preferences. That'll cause a checkbox marked "Speakers" to appear in one of the panes.
[12:27] <sladen> esr: alsamixer
[12:27] <esr> I'll try that, thanks.
[12:28] <esr> This would be under Preferences -> Sound?
[12:29] <esr> sladen: I have alsamixer up now.  It's not obvious what to do.
[12:33] <slangasek> ogra: I'm having a hard time boiling the description of 145514 down into something I can put in the release notes, can you help me understand the consequences of the ssh key not being in the chroot?
[12:33] <pitti> slangasek: it comes down to "thin clients do not boot", I think
[12:34] <ogra> pitti, not at all :)
[12:35] <ogra> slangasek, it prevents you from being able to log in on a thin client
[12:35] <pitti> that's what it was like yesterday for stgraber at least
[12:35] <pitti> ah, right
[12:35] <slangasek> ogra: ok, thanks
[12:35] <ogra> pitti, that was the udev bug (which is an ubuntu bug and not related to edu)
[12:35] <pitti> ah
[12:35] <ogra> udev creating random interface names in the oersistent rules
[12:35] <ogra> Persistent
[12:36] <ogra> not sure about the number, let me look
[12:36] <ogra> that needs to be in the ubuntu list though
[12:36] <sladen> esr: using the <- left and -> right arrow keys, is one of the options/columns "Speakers";  toggle "mute" state with the 'm' key
[12:36] <slangasek> pitti: and this goes on the main release notes page, there's no separate page for Edubuntu like there is for Kubuntu?
[12:37] <slangasek> ogra: that one's already errataed, don't worry about it
[12:37] <pitti> slangasek: right
[12:37] <ogra> that was bug 145382 (just to confirm)
[12:37] <ubotu> Launchpad bug 145382 in udev "[Gutsy]  broken 70-persistent-net.rules" [High,New]  https://launchpad.net/bugs/145382
[12:38] <slangasek> yes
[12:38] <sladen> esr: https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadX61  "External-monitor (Fn-F8) button."  should that be Fn-F7 ?
[12:38] <esr> sladen:  That was puzzling for a moment, as the speaker column was offscreen and there was no "more" indication.  But it's done.
[12:38] <ogra> slangasek, the canoinical wiki has a list of features if you need any ...
[12:38] <esr> sladen: Yes, it should.  Typo.  You want to fix it or shall I?
[12:40] <sladen> esr: yes please.  Also "The Fn-F7 and Fn-F9 keys do nothing."  Could you document the expected behave from each.  The X61 has intel graphics?
[12:40] <sladen> behavious
[12:40] <sladen> behaviour
[12:40] <esr> It does.
[12:42] <esr> I think Fn-F9 is supposed to be dock-eject.  I don't know what the Fn-F8 graphic is supposed to be.
[12:43] <esr> Oh, good.  Sound is working.
[12:43] <torkel> probably something todo with the touchpad/pointing stick (at least on T61)
[12:44] <torkel> s/pointing stick/TrackPoint
[12:44] <ogra> nipple ?
[12:45] <sladen> esr: ah, touchpad toggle (enable/disable).  Needs an X extension writing to control the synaptic pad to do it securely
[12:45] <tepsipakki> hmm, I have problems with static network configuration.. fresh install complains "no such device" when trying to ifup eth0
[12:45] <tepsipakki> gutsy daily live works fine
[12:46] <pitti> tepsipakki: was it only dhcp/auto?
[12:46] <esr> torkel: Oh, yeah. That odd trefoil thingy does look like a trackpad between 3 keys.
[12:46] <tepsipakki> pitti: no, inet static
[12:46] <ogra> tepsipakki, check bug 145382
[12:46] <ubotu> Launchpad bug 145382 in udev "[Gutsy]  broken 70-persistent-net.rules" [High,New]  https://launchpad.net/bugs/145382
[12:46] <tepsipakki> pitti: this was the real problme that I mentioned last week, not our ldap conf :)
[12:46] <esr> torkel: is your Fn-F5 a wireless toggle?
[12:46] <tepsipakki> ah, reading
[12:47] <ogra> it probably has arandom fantasy name now :)
[12:47] <torkel> esr: see http://www.thinkwiki.org/wiki/Installing_Ubuntu_6.10_(Edgy_Eft)_on_a_ThinkPad_T60#Enable.2FDisable_Touchpad
[12:47] <pitti> tepsipakki: we deliberately do not put dhcp/auto stanzas into /e/n/i any more
[12:47] <torkel> esr: looks like it
[12:47] <pitti> tepsipakki: thus, 'sudo ifup eth0' will not work on the common Ubuntu system
[12:47] <tepsipakki> pitti: I mean it should have "iface eth0 inet static" etc
[12:48] <esr> Stylized computer with little radio-wave thingies flanking it?
[12:48] <pitti> oh
[12:48] <ogra> but if it doesnt finda an eth0 it wont be able to start that :)
[12:48] <tepsipakki> I'll boot in su-mode to see what's going on
[12:48] <tepsipakki> ogra: right, it does load e1000 though
[12:49] <ogra> tepsipakki, yeah, but ifg udev calls it eth7 you wont have any luck with eth0
[12:49] <slangasek> yes, if it's the udev bug (and it probably is), the problem isn't a lack of drivers, the problem is the interface has been renamed so e/n/i no longer matches the kernel interface name
[12:49] <tepsipakki> ahh, right
[12:50] <slangasek> I'm puzzled that it didn't affect me here with my alternate CD install, my udev rules look perfectly normal
[12:51] <ogra> slangasek, do you have any static interfaces ?
[12:51] <tepsipakki> udev log has eth0, but ifconfig -a shows eth1
[12:51] <slangasek> ogra: no; but I also see valid rules in /etc/udev/rules.d/70-persistent-net.rules which should /not/ break my interface names...
[12:51] <ogra> and the persistent rules ?
[12:52] <tepsipakki> sorry, they are both there
[12:52] <ogra> tjhen its not udev
[12:52] <tepsipakki> I mean both mentioned in the udev log
[12:52] <ogra> ah
[12:52] <tepsipakki> the persistent rules file only has eth0
[12:53] <ogra> with the matching MAC ?
[12:53] <tepsipakki> umm, no MAC there
[12:54] <tepsipakki> and it's listed seven times
[12:54] <ogra> oh
[12:54] <tepsipakki> identical lines
[12:55] <ogra> ideally it should have only the bottom lines of http://www.stgraber.org/download/70-persistent-net.rules
[12:55] <ogra> and not the stuff above
[12:55] <tepsipakki> right
[12:55] <ogra> (with the right names indeed)
[12:56] <ogra> my upgraded one has not a single line with unset ATTRS{address} pasrameter
[12:56] <ogra> 75-persistent-net-generator.rules might be at fault here
[12:57] <tepsipakki> if someone has suggestions for a fix, I'm willing to debug that :)
[12:57] <ogra> well
[12:58] <ogra> obviously /etc/udev/rules.d/75-persistent-net-generator.rules creates the 70-persistent-net.rules
[01:00] <ogra> if you delete the empty lines and reboot, does it work then (make a backup of teh file indeed)
[01:01] <tepsipakki> empty lines in 75-?
[01:04] <MacSlow> mvo, meeting is in one hour right?
[01:04] <pitti> MacSlow: right
[01:06] <mvo> MacSlow: yeah
[01:07] <tepsipakki> ogra: yep, removing those lines made it work
[01:08] <tepsipakki> network, that is. 70- remains empty
[01:19] <ogra> asac, NM patch seems to be working
[01:20] <ogra> asac, you can test it yourself by running: LTSP_CLIENT=something nm-applet
[01:21] <esr> sladen, mjg59, cjwatson, torkel: Thanks, you were extremely helpful; my X61 is fully working now and I've posted appropriate recipes to ThinkWiki and the LaptopTesting area.
[01:21] <ogra> esr, thanks for writing it down :)
[01:23] <esr> Always.  It's what I do.  I really am "ESR" :-)
[01:23] <ogra> :)
[01:29] <sladen> esr: thanks.  are Fn-F7 and Fn-F8 still the wrong way around;  I would expect Fn-F7 to be video toggle and Fn-F8 to be trackpad toggle.  (Though Lenovo did swap Fn-F2 and Fn-F3 so I'm not putting it past them)
[01:30] <esr> Um, I thought I fixed that on the wiki page . I'll check.
[01:31] <esr> BTW, I just fiound out that the mute button on the X61 just sets volume to 0, so you can unmute with the volume-up button.  In fact, you have to :-)
[01:32] <sladen> esr: thinkpad mute is  always-mute
[01:32] <sladen> rather than toggle
[01:32] <esr> Ah.
[01:32] <glatzor> ping bryce_
[01:33] <sladen> esr: is the "speaker mute" button different to the normal mute button (next to escape and Down/Up/ThinkVantage )
[01:34] <esr> No, that's the one I mean alright.
[01:38] <esr> Dang.  There's a launchpad bug about an upgrade that would fix UltraBase hotswapping, I've seen it.  But I can't find it.
[01:40] <esr> And it *totally rocks* that installing Gutsy Beta make my X61 wireless work.  That had been a real pain in the butt for me.
[01:40] <ogra> tepsipakki, does your 70-persistent-net.rules have any header (some lines of commented text) ?
[01:41] <ogra> (i dont see that in stgraber's attachment to the bug)
[01:41] <tepsipakki> ogra: no
[01:41] <ogra> aha
[01:41] <ogra> udev.poastinst is supposed to add four lines of comments at the top
[01:42] <ogra> either that didnt run or the file was overwritten by something
[01:42] <stgraber> ogra: no it doesn't
[01:42] <tepsipakki> I'll check for errors in the install syslog
[01:42] <ogra> ah, wait it only creates these entries if the file doesnt exist alread<
[01:42] <ogra> y
[01:43] <ogra> i wonder if in d-i the file is created already by something else
[01:43] <tepsipakki> udev-udeb?
[01:44] <ogra> probably
[01:45] <tepsipakki> there's a write_net_rules in the udebv
[01:45] <tepsipakki> -v
[01:46] <cjwatson> nothing else in d-i creates that rules file
[01:46] <ogra> there is also code that copies 70-persistent-net.rules from the installer environment to /target
[01:46] <cjwatson> yes
[01:46] <cjwatson> which is intended to preserve network interface names from one environment to the other
[01:48] <ogra> well, i suspect udev in d-i already has the wrong entries then
[01:48] <stgraber> ok, so question is : Is the installer's 70-persistent-net.rules correct
[01:48] <cjwatson> easy to check
[01:49] <cjwatson> look at it from the shell just before reboot
[01:49] <ogra> (dont blame the installer though :) its udev only)
[01:50] <TheMuso> On my ThinkPad R50, my wireless is eth0 at configure time, and ethernet is eth1. When I reboot, ethernet is eth2, and wireless is eth3. THis is using alternate with d-i.
[01:53] <ogra> TheMuso, yeah, they seem to move up the naming by $num_of_devices
[01:55] <stgraber> http://www.stgraber.org/download/udev-installer
[01:55] <stgraber> that's 70-persistent-net.rules from d-i
[01:55] <ogra> aaha
[01:55] <stgraber> (generated a bit after entering hostname (before partitioning))
[01:55] <ogra> yeah
[01:56] <ogra> i got two such entries here
[01:56] <ogra> (before the hostname though
[01:57] <cjwatson> perhaps write_net_rules is broken in the udeb
[01:57] <ogra> yeah, something like that
[01:57] <ogra> ah, there is the master for that bug
[01:57] <ogra> hey Keybuk
[01:58] <cjwatson> Keybuk: I don't see where write_net_rules + rule_generator.functions in udev-udeb ever generates a comment
[01:59] <cjwatson> the COMMENT variable is never set
[01:59] <cjwatson> those files are the same as in the deb
[02:00] <cjwatson> oh, I see, it's set in the .rules file
[02:00] <cjwatson> never mind me
[02:01] <cjwatson> Keybuk: apparently http://www.stgraber.org/download/udev-installer is 70-persistent-net.rules within d-i shortly after entering the hostname
[02:01] <tepsipakki> I'll reinstall to see how it looks here
[02:01] <ogra> i have something similar even after selecting the lang already (after the udeb is loaded)
[02:02] <stgraber> ogra: strange, at this point I only have 75- not 70-
[02:03] <ogra> well, tty1 is asking for the hostname but i didnt confirm anything (switched consoles before it showed up)
[02:03] <Keybuk> cjwatson: do you have a different rules file than the real system?
[02:04] <cjwatson> Keybuk: don't seem to
[02:05] <ogra> Keybuk, the real system gets the stuff from above plus the proper lines ... seems the proper ones are added on first boot
[02:06] <Keybuk> cjwatson: then write_net_rules is called from persistent-net-generator.rules ?
[02:06] <ogra> IMPORT{program}="write_net_rules $attr{address}"
[02:06] <ogra> Keybuk, from /etc/udev/rules.d/75-persistent-net-generator.rules
[02:06] <ogra> i dont think they differ in d-i
[02:06] <Keybuk> ok
[02:06] <Keybuk> and that always calls that with a comment set
[02:06] <cjwatson> $ diff -u <(deb-extract-file /mirror/ubuntu/pool/main/u/udev/udev_113-0ubuntu11_i386.deb /etc/udev/rules.d/75-persistent-net-generator.rules) <(deb-extract-file /mirror/ubuntu/pool/main/u/udev/udev-udeb_113-0ubuntu11_i386.udeb /etc/udev/rules.d/75-persistent-net-generator.rules)
[02:07] <cjwatson> $
[02:08] <Keybuk> so you can see my confusion ;)
[02:10] <ogra> well, it mibght be that non static setups have the same entries but dont affect anything since NM doesnt care about iface names
[02:10] <ogra> actually we didnt check that yet :)
[02:11] <ogra> has anyone here a working install from yesterday/today without static NICs ?
[02:12] <jdong> keescook: hmm what happened to *your* XFS? This is like the 4th XFS corruption story I've heard this month, not including my mishaps with horribly corrupted /usr... can't help but wonder if there's something wrong with gutsy's kernel on XFS :(
[02:12] <ion_> Yeah, s/gutsy's kernel on// ;-)
[02:12] <jdong> lol
[02:13] <jdong> it worked much much more reliably in previous releases, edgy aside.
[02:14] <Keybuk> cjwatson: the fact that there's multiple entries suggests that whatever is writing those is called repeatedly
[02:14] <Keybuk> assuming that it's udev for a moment
[02:14] <Keybuk> the problem could be a lack of environment in the triggered events
[02:15] <Keybuk> d-i using udevtrigger and not anything older, right?
[02:15] <cjwatson> d-i does call udevtrigger+udevsettle several time
[02:15] <cjwatson> s
[02:18] <seb128> pitti: what do you think about http://packages.qa.debian.org/libj/libjpeg6b/news/20070905T222914Z.html?
[02:18] <seb128> pitti: libjpeg62 has no .gnu_debuglink set at the moment, it needs a rebuild
[02:19] <seb128> pitti: I was going to upload an build1 version but the new debian revision like simple enough
[02:24] <sladen> Hobbsee: morning or evening?
[02:24] <Hobbsee> sladen: evening, last i checked.
[02:24] <Hobbsee> sladen: sky is black, anyway
[02:25] <ogra> sladen, use the new timezone feature in your clock applet :)
[02:25] <StevenK> Oh, I so want that
[02:27] <StevenK> seb128: Debian has grown rc3 of GIMP, do you think it's worth me merging that?
[02:27] <Hobbsee> time to upgrade, StevenK
[02:27] <Hobbsee> StevenK: out of principle, i'd say no :P
[02:27] <StevenK> Hobbsee: We have rc2. :-)
[02:29] <Hobbsee> StevenK: yes, i know, but thinking of previously... :)
[02:30] <seb128> StevenK: I was going to look at it today if you want to do the merge you are welcome
[02:31] <ogra> http://www.mail-archive.com/gnome-doc-list@gnome.org/msg02690.html
[02:31] <ogra> meh
[02:31] <ogra> seb128, any chance we get it back in 2.20.1 ?
[02:32] <pitti> seb128: fine for me
[02:32] <seb128> pitti: thanks
[02:32] <StevenK> seb128: Okay, cool, I'll do it shortly and save you the work
[02:32] <seb128> ogra: it's still available that's only a gconf key for now
[02:32] <ogra> ah
[02:32] <seb128> StevenK: thank you
[02:32] <ogra> Ng, ^^^^
[02:33] <Ng> thanks
[02:33] <seb128> look for a key named show_timezones in gconf-editor
[02:35] <seb128> pitti: will you unfreeze the archive soon? any need to keep upload broken since new images are not going to be rolled?
[02:35] <pitti> seb128: it'll happen tomorrow
[02:35] <pitti> seb128: just to give us the possibility for emergency stuff after release and user feedback
[02:35] <seb128> why not before?
[02:36] <seb128> hum
[02:36] <pitti> seb128: see https://wiki.ubuntu.com/BetaProcess
[02:36] <pitti> but I hope we can flush the queue tomorrow around midday
[02:36] <seb128> like if beta is not good we are going to stay frozen enough to roll new images, etc?
[02:36] <pitti> I don't like to stall it any further
[02:36] <seb128> I don't get it
[02:36] <pitti> seb128: I seriously hope that this won't happen
[02:36] <pitti> and the images should be good, but *shrug*, I didn't invent that policy
[02:36] <pitti> but I do see that it makes sense
[02:36] <seb128> k
[02:36] <seb128> well, that's only a beta
[02:36] <seb128> if it has some bugs that's not a big deal
[02:37] <pitti> yeah, I agree
[02:37] <slangasek> do we have to worry that anything that's already uploaded to the queue shouldn't have been because it violates FeatureFreeze, and needs to be cleaned out before unblocking?
[02:37] <pitti> seb128: we have much more safety space for the finals
[02:37] <pitti> slangasek: I don't think so, since we do not do it during FeatureFreeze either
[02:37] <Hobbsee> slangasek: imo, people should be being careful in what they upload.
[02:37] <Hobbsee> slangasek: so, probably not
[02:37] <seb128> slangasek: I don't think so, we don't control upload before accepting them after the freeze
[02:38] <pitti> slangasek: if something in appropriate is in that, we need to apply a combination of LARTing and reverting
[02:38] <slangasek> right
[02:39] <siretart> .oO( and I was just about to ask if uploading a new memtest86+ was okay. intended for after betarelease, of course )
[02:39] <pitti> siretart: sure, uploads are fine, they just get stalled
[02:40] <pitti> siretart: but it's often more convenient to 'fire and forget' than to remember to upload it later
[02:40] <siretart> right
[02:40] <siretart> okay, so I'll do the upload, forget about  it and get suprised about an ACCEPTED mail from soyuz :)
[02:42] <cjwatson> pitti: I have to say it would be useful to let openoffice.org start building
[02:42] <pitti> yeah, we might give that an exception
[02:43] <pitti> cjwatson: although, if we delay the queue opening for the reason of having space for another CD rebuild, then OO.o is the single package we should  *not* rebuild now
[02:44] <pitti> cjwatson: for the same reason why I didn't accept it on Tuesday: one partial FTBFS, and the archive is a big mess of uninstallability
[02:44] <cjwatson> pitti: except that OO.o being broken at the moment makes the desktop uninstallable
[02:44] <cjwatson> I'm having that problem on powerpc - can't build livefses
[02:44] <pitti> oh?
[02:44] <cjwatson> not sure how i386 gets away with it TBH
[02:45] <pitti> cjwatson: because oo.o and -l10n *both* FTBFSed on all arches
[02:45] <pitti> and -l10n is not really -l10n ATM, but just a copy of ooo
[02:45] <cjwatson> http://royal.buildd/~buildd/LiveCD/gutsy/ubuntu-ps3/latest/livecd-20070927-powerpc.out
[02:45] <cjwatson> The following packages have unmet dependencies:
[02:45] <cjwatson>   openoffice.org-common: Depends: openoffice.org-core (> 1:2.3.0~rc1) but 1:2.3.0~oog680m1-1ubuntu3 is to be installed
[02:45] <cjwatson> earlier today
[02:46] <seb128> that's becaue the rc1 ftbfs on powerpc
[02:46] <seb128> that's because the rc1 ftbfsed on powerpc
[02:46] <cjwatson> ah, yes, of course
[02:47] <seb128> carlos: any new of the language packs update?
[02:47] <carlos> seb128: still running
[02:47] <pitti> cjwatson: we can only hope that it actually builds on ppc this time, but give the last couple of ppc failures I'm not that optimistic :/
[02:48] <seb128> carlos: any eta for the update?
[02:48] <cjwatson> pitti: the last one was just a timeout
[02:48] <pitti> uh
[02:48] <carlos> seb128: the movement to production means also that I have less control over that process.. so I don't know how much time more would it take, although it should finish soon... or is already taking too much time
[02:48] <pitti> no luck with that
[02:48] <carlos> seb128: this is the first full export from production
[02:48] <pitti> carlos: in the end it was more reliable on the mirror...
[02:48] <carlos> so I don't have any ETA on it :-(
[02:49] <sladen> ogra: it's the same problem as firefox and Kubuntu.  Openoffice and Firefox are *brands* and ones that people have heard of and expect to find around
[02:49] <pitti> carlos: can you trigger an additional export from the mirror this time?
[02:49] <carlos> pitti: not really, if it fails now, we have all infrastructure to know about it
[02:49] <carlos> pitti: and now I'm not a the single point of failure
[02:49] <seb128> carlos: ok
[02:49] <carlos> jtv and danilo should be able to handle any errors that appear with the exports
[02:49] <ogra> sladen, well, i have some freedom in edubuntu and xubuntu already pulls both to main anyway
[02:50] <carlos> pitti: the mirror is not being updated since last friday and tom is not around to fix that (I think Stuart is using the mirror to do some debugging tasks with postgres)
[02:50] <carlos> pitti: so I'm not sure whether that's a good idea
[02:51] <pitti> hmkay
[02:54] <Mithrandir> pitti: huzzah!
[02:54] <ogra> yay
[02:54] <StevenK> Yay!
[02:55] <pitti> OPEN THE FLOODGATES, DRAIN THE DC PIPES!
[02:56] <Hobbsee> yay!
[02:56] <iwj> pitti: Well done, and have a nice rest now.
[02:59] <pitti> mmm candy
[02:59] <asac> ogra: ok will do
[03:00] <agoliveira> Yay! Beta time! Kudus to all of you guys!
[03:02] <StevenK> seb128: Oh, and just so you are aware, ari grabbed me the day after I uploaded rc2, and told me the wizard patch is no longer necessary, so I will drop it.
[03:02] <seb128> StevenK: ok, good
[03:02] <seb128> StevenK: why isn't it necessary?
[03:03] <StevenK> seb128: Since upstream don't use the wizard any more
[03:03] <seb128> StevenK: so what did you patch out? ;)
[03:03] <seb128> they let the code unused?
[03:03] <StevenK> That's a very good point.
[03:04] <StevenK> seb128: I'll unpack rc3, and look over the code in question and see if it's called.
[03:04] <seb128> ok, thanks
[03:04] <Mithrandir> Tonio_: hm, some time back you had some patches for bluez-* for kubuntu (iirc, the pin helper patch could be dropped).  Did anything happen with that?
[03:05] <agoliveira> Talking about beta, yesterday I spent some significant time testing my updated desktop with compiz on (I'm really not a fan of this kind of eye candy) and I most say that I'm impressed. It was rock solid and I was able to run other opengl programs very smoothly, even games. Congrats!
[03:07] <Tonio_> Mithrandir: no need for those patches anymore, as latest kdebluetooth finally succeeds in using dbus :)
[03:07] <Mithrandir> Tonio_: you're core-dev, aren't you?  If so, it'd be good if you could just upload a new bluez-utils with them removed.
[03:10] <StevenK> seb128: Right, it isn't called. But the code is still there.
[03:10] <StevenK> seb128: The call doesn't hit the compiler, it get ifdef'd out
[03:10] <StevenK> it gets, even
[03:11] <seb128> StevenK: ok
[03:11] <StevenK> seb128: So I'll drop the patch
[03:11] <seb128> StevenK: alright
[03:14] <AlinuxOS> wow Great ;)
[03:14] <AlinuxOS> thank you guys! ;)
[03:14] <stgraber> mathiaz: ping
[03:15] <mathiaz> stgraber: hi !
[03:15] <stgraber> mathiaz: I heard that server team would like to do some testcases change to the tracker, can you add your changes to : bug 145502 ?
[03:15] <ubotu> Launchpad bug 145502 in ubuntu-qa-tracker "Adjust test case entries in tracker" [High,Confirmed]  https://launchpad.net/bugs/145502
[03:16] <mathiaz> stgraber: ok. I'll add the server cd testcases to the bug.
[03:17] <Riddell> dholbach: where's that page of bugs with patches you keep pinging me about?
[03:18] <StevenK> seb128: Can I get your thoughts on http://paste.ubuntu.com/465/ ?
[03:21] <\sh> hmmm...did anyone tried to install vmware server 1.0.4 from orig tarball on feisty server?
[03:21] <seb128> StevenK: I like the Ubuntu version better and we already have translations
[03:21] <StevenK> seb128: Okay, cool.
[03:21] <seb128> StevenK: keep the Ubuntu variant for now we can deal with that next cycle if required
[03:21] <\sh> I just got some strange error: Unable to get last modification timestamp of destination file /etc/vmware/ssl/rui.key...but installing on feisty desktop works
[03:22] <StevenK> seb128: Sure. Just test building
[03:23] <Keybuk> right
[03:23] <Keybuk> this bug is only affecting alternate, right?
[03:23] <ogra> Keybuk, right and apparently it only causes probs with static interfaces
[03:24] <Keybuk> causes problems for, or occurs for?
[03:24] <ogra> well, i have heard an complaints from users using NM and no staic devices
[03:24] <ogra> since NM doesnt care about interface names at all it seems
[03:25] <Keybuk> you wouldn't expect to hear complaints from NM users
[03:25] <Keybuk> indeed
[03:25] <ogra> it's surely there as well but does no harm
[03:25] <ogra> apparently
[03:25] <Keybuk> it's a bit like why we never hear udev complaints from people who use our usual desktop stuff
[03:25] <Keybuk> because HAL doesn't care about device names
[03:25] <ogra> heh
[03:25] <Keybuk> it's only the weird people who want /dev/mouse/yellow_with_stars
[03:26] <Keybuk> StevenK: it's a gimp suit
[03:26] <StevenK> Keybuk: Gimp as in Wilbur? :-P
[03:26] <StevenK> Oh, bugger. gimp -rc3-1 Conflicts/Replaces with gimp-print (<= 5.0.1-3) for some reason.
[03:27] <StevenK> Ah ha. It has it's own print plugin now.
[03:28] <mpt> Someone wants a udev complaint?
[03:28] <ogra> mpt, do you want to design one ?
[03:29] <mpt> No need, I have one already prepared
[03:29] <ogra> heh
[03:29] <Keybuk> mpt: ?
[03:29] <mpt> "Mummy, udevd is using 93.2% of my CPU and has been doing so for the past three days now"
[03:29] <mpt> "Make it stop"
[03:29] <ogra> come on ...
[03:29] <ogra> it leaves you 7% !!!
[03:30] <ogra> (nearly=
[03:30] <Keybuk> mpt: purge evms
[03:30] <ogra> )
[03:30] <mpt> I don't even know what udev is, let along evms
[03:30] <Keybuk> and use the update-manager next time which would have recommended that you do that :p
[03:30] <Keybuk> (actually, it may only recommend that when you do a release->release update)
[03:30] <mpt> I did use update-manager, 7.04->gutsy
[03:31] <Keybuk> mpt: did you get a "support has ended" dialog?
[03:31] <mpt> Keybuk, no, though I did get an "update-manager has crashed" alert
[03:32] <mpt> So I had to restart it partway through, which may have caused it to forget to remind me to purge the whatsit
[03:33] <Keybuk> could be
[03:33] <Keybuk> you filed the crash report?
[03:34] <mpt> ... I'm sorry, Keybuk.
[03:34] <liw> update-manager used about 95% of my cpu today, for half an hour, until I killed it; it claimed it was updating four packages
[03:34] <StevenK> seb128: It looks like due to gimp having it's own print stuff, it *might* require gutenprint changes. I'm still digging.
[03:34] <mpt> I did file an extremely detailed suggestion on how update-manager can make its progress meter go from 0% to 100% once, instead of jumping around
[03:34] <StevenK> liw: I'd be curious if it had actually spawned dpkg or apt.
[03:35] <mpt> and doing that distracted me from reporting the crash.
[03:35] <mpt> I know, priorities.
[03:35] <Keybuk> mpt:  :-)
[03:35] <liw> StevenK, I didn't see one, but I was doing other things most of the time, so it might have been there part of the time
[03:35] <mpt> heh
[03:35] <mpt> Isn't that Gnome's?
[03:36] <ogra> Keybuk, just respect it :)
[03:36] <Keybuk> "You have 3 tabs open, are you sure you wish to close?"
[03:36] <mpt> "You're gonna lose your data, sucka, and we've forgotten to include a Cancel button"
[03:36] <mpt> oh, that one
[03:36] <Keybuk> YES, I JUST CLICKED ON THE FRAKKING ClOSE BUTTON
[03:36] <mpt> I won'tfixed that bug when I was its QA contact, but it was reopened.
[03:36] <Spads> what I love
[03:36] <ogra> mpt, you meant recovery ?
[03:36] <StevenK> Keybuk: I like that dialog, it stops me closing it by accident.
[03:36] <Spads> is that if you do that, it won't restore those tabs on the next load
[03:36] <Hobbsee> Keybuk: i thought you could disable that.
[03:36] <liw> Keybuk, otoh, some people get *livid* if their browser doesn't ask that (I have a friend like that, refuses to use any browser that doesn't have it)
[03:36] <Keybuk> StevenK: it's bad UI
[03:37] <Spads> so often the best option for me is to kill -9 firefox
[03:37] <Keybuk> better UI would have been if when you closed it, it remembered your open tabs
[03:37] <Spads> so that I can free up the resources, and still have those tabs when I start again
[03:37] <Keybuk> so when you opened it again, they were still there
[03:37] <Keybuk> then it doesn't *matter* if you accidentally close it
[03:37] <StevenK> My firefox remembers
[03:37] <evand> Spads: you can set the "home page" to your previous tabs, so you don't have to kill the process to get all the tabs back.  That doesn't work with multiple windows though.
[03:38] <mpt> ogra, I'm not sure of the context of your question
[03:38] <Spads> evand: kill works fine
[03:38] <evand> ok
[03:38] <Keybuk> Spads: heh
[03:38] <Keybuk> so I'm not the only person who deliberately kill -9's firefox to save state?
[03:38] <Spads> nope
[03:38] <Spads> hehe
[03:38] <Spads> crash-only software FTW
[03:39] <Hobbsee> StevenK: tab mix plus?
[03:39] <mpt> ogra, but if you're offering to tell me how to "purge evms", I'm all ears :-)
[03:39] <Hobbsee> or works by default now?
[03:40] <mpt> oh, never mind, The Google has it
[03:40] <mpt> sudo aptitude purge evms
[03:40] <Keybuk> I have a dream about the whole desktop behaving like that
[03:40] <Keybuk> so there's no "Log Out" option, just "Shutdown" and "Switch User"
[03:40] <liw> is the decision to make Nautilus windows be browser windows by default instead of spatial browser windows a big political issue in Ubuntu?
[03:41] <Keybuk> if you switch user, the system either leaves your session running or saves the session for later
[03:41] <mpt> Keybuk, that would be awesome
[03:41] <Hobbsee> mpt: apt-get remove --purge evms..?
[03:41] <Keybuk> so when you switch back to use, it either returns to the running session or restores the saved one
[03:41] <Keybuk> and the only difference between them would be that the latter took a bit longer
[03:41] <Keybuk> liw: yes
[03:42] <ogra> mpt, there is no cancxel button in FFs recovery dialog i thought you referred to that one (since its really annoying)
[03:42] <mpt> Keybuk, anything to reduce the "Seven Ways to Leave Your Lover^W^WUbuntu" problem
[03:42] <Keybuk> mpt: I hate that dialog
[03:42] <Keybuk> my brain has learned where to click the mouse whenever I see it
[03:43] <Keybuk> so I always do *click* OH FUCK I WANTED A DIFFERENT OPTION THIS TIME
[03:43] <mpt> i.e. "habituation"
[03:43] <mpt> Textbook example!
[03:44] <mvo> Riddell: could you please have a look at bug #103374 ? it seems like this is one of the qt+unicode+utf8 issues that I have little experience with
[03:44] <ubotu> Launchpad bug 103374 in language-selector "[apport]  qt-language-selector crashed with TypeError in _()" [Undecided,New]  https://launchpad.net/bugs/103374
[03:45] <Riddell> mm, ok
[03:45] <mpt> liw, it was in the Breezy era, not so much now
[03:45] <ogra> Keybuk, imagine you have 10 sites like that open: http://www.carteretcountyschools.org/bms/teacherwebs/sdavenport/artgallery6.htm (careful !!!)
[03:45] <ogra> your FF would just kill X at some point
[03:46] <ogra> (we have that prob massively in LTSP, FF just eats up all X ram for teh pixmap cache and makes it hardlock the system)
[03:47] <mpt> liw, I still dislike it because it makes moving/copying between unusual folders more difficult, though I recognize the mountain-of-windows problem
[03:47] <liw> ogra, that shows bugginess on so many levels in the system it's funny -- X shouldn't crash for running out of memory, FF shouldn't use so much memory, FF especially shouldn't waste excessive resources based on instructions from suspicious sources (read: the net)
[03:48] <mpt> liw, I'd prefer it was a window-by-window setting ("View" > "as Browser"), rather than a global setting
[03:48] <ogra> liw, yeah, its also an old bug it seems
[03:49] <ogra> you dont see it on machines with plenty of ram ...
[03:49] <liw> mpt, let's not discuss the pro and con of spatial/browsers, if it's a touchy issue, I just wanted to know if it was
[03:49] <Mithrandir> Keybuk: saving session> how would you handle terminals and network connections and such in that case?  "Don't"?
[03:50] <Keybuk> Mithrandir: terminals could save their scrollback, current directory, etc.
[03:51] <liw> apps need to be able to deal with breaking network connections in any case (think suspend, if nothing else)
[03:51] <Mithrandir> Keybuk: in some way, that feels wrong to me.. I'd rather not have a terminal than have one which is no longer connected to the remote host.
[03:52] <Keybuk> Mithrandir: it depends to which depth you support session saving really
[03:53] <Spads> Keybuk: it should re-open emacs on the remote AIX system in the same mode as it was left
[03:55] <Mithrandir> Spads: tunnelled through the four machines, including the special IP-over-DNS hack in the middle.
[03:55] <Keybuk> there's probably some depth which would make people content
[03:55] <Keybuk> ie. if they just used the plain "Terminal" launcher
[03:55] <ogra> just use xmove and suspend the session :P
[03:55] <Keybuk> keep the window size/position, scrollback, working directory, etc.
[03:55] <Keybuk> and if there was a running command at the time of death, place that running command on the command-line
[03:55] <Keybuk> so you'd get
[03:55] <ogra> so the apps dont need to save their states

[03:55] <Keybuk> wd$ ssh ...
[03:55] <Keybuk> in your terminal, and just press enter
[03:55] <Keybuk> or something
[03:56] <bddebian> Heya folks
[03:56] <Keybuk> if that command supported session management (emacs!) then you could run it and go further, etc.
[03:56] <lamont> Keybuk: my remote session windows are all of the form 'xterm ... -e ssh ...'
[03:56] <Keybuk> lamont: right, so for you it'd work better since they'd all automatically respawn with the same command :)
[03:56] <lamont> when is emacs going to provide a login window?
[03:57] <lamont> but no state. :-(
[03:57] <bddebian> So does someone want to tell me their definition of Fix committed?
[03:57] <lamont> "I checked it into my VCS"
[03:57] <Keybuk> bddebian: fix applied to the bzr branch
[03:57] <Keybuk> (or if no bzr branch, fix applied to a package in my home directory)
[03:57] <bddebian> How is that fix committed in Ubuntu?
[03:58] <Keybuk> bddebian: doesn't need to be "in"
[03:58] <lamont> it's committed to the next upload...
[03:58] <Keybuk> that's what Fix Released is for
[03:58] <Hobbsee> bddebian: committed.  not released.
[03:58] <lamont> "Fix released"  == "I uploaded it"
[03:58] <Keybuk> In Progress - working on it
[03:58] <bddebian> Released means it's actually in the repo
[03:58] <Keybuk> Fix Committed - I have a fix
[03:58] <Keybuk> Fix Released - uploaded
[03:58] <liw> hm, Ubuntu doesn't want me to be bilingual (~/Desktop is translated when the account is created, but if I don't like that language...)
[03:58] <Keybuk> bddebian: no, fix released means it's been uploaded
[03:58] <bddebian> I was always told fix committed meant uploaded
[03:58] <Keybuk> bddebian: it still takes some hours after FR before it's available for download
[03:58] <bddebian> Release meant it built on all archs
[03:58] <lamont> bddebian: released means it's uploaded - it might not actually be on the mirrors yet, or even the main archive.
[03:58] <Keybuk> FR is applied automatically on upload
[03:59] <bddebian> Bah, I give up
[03:59] <lamont> Keybuk: applied automatically for those of us who can speel.. :-)
[03:59] <Keybuk> lamont: ?
[03:59] <lamont> bddebian: if it doesn't build on all architectures, then taht's a different bug. :)
[04:00] <Keybuk> lamont: our spellings match
[04:00] <lamont> Keybuk: it's LP: #nnn, not Closes: LP#nnn, as I keep reminding myself post-upload. :-(
[04:00] <Keybuk> ahh
[04:00] <Hobbsee> lamont: you want to use vi with syntax highlighting.
[04:00] <bddebian> I think I need an Ubuntu glossary package somewhere where I can download daily and check what means what "today"
[04:00] <lamont> Hobbsee: what's that?
[04:00] <lamont> :-)
[04:00] <Hobbsee> lamont: :)
[04:01] <Keybuk> bddebian: that's what the bug statuses have always meant?
[04:01] <Hobbsee> lamont: if you actually tried it, you'd find that you never got the syntax wrong again.
[04:01] <Hobbsee> bddebian: sponsorship process decided to make things screwy
[04:01] <Keybuk> bddebian: https://help.launchpad.net/BugStatuses
[04:01] <lamont> Hobbsee: in oxford, I was one of the people arguing for nvi in base....
[04:01] <Hobbsee> bddebian: i've always thought it was complete and utter crack, so have ignored it myself.
[04:01] <bddebian> Keybuk: That is not what I have been told in the past but that's fine
[04:01] <pitti> Keybuk: "statuses"? is that really right? (states?)
[04:01] <lamont> Hobbsee: if I knew how to turn it on, I'd probably use it
[04:01] <Hobbsee> bddebian: the people telling you are on crack - i just havent hardbailed in and said "no".
[04:02] <Hobbsee> lamont: syn on, in ~/.vimrc
[04:02] <bddebian> Hobbsee: ??
[04:02] <mathiaz> pitti: I've just made a small modification to the Beta wiki page in the AppArmor section.
[04:02] <pitti> mathiaz: ah, too late, it's on www.u..c now
[04:02] <lamont> Hobbsee: we're just doing what he said: <bddebian> So does someone want to tell me their definition of Fix committed?
[04:02] <Hobbsee> bddebian: you've picked up your strange definitions from the sponsorship queue stuff.
[04:02] <pitti> let me note that on the page
[04:03] <Hobbsee> lamont: no, not you.  i'm talking about where he got his original definitions of committed and released from.
[04:03] <bddebian> Hobbsee: No, that's what I have been using for the last 3 (or 4? releases)
[04:03] <lamont> oh.
[04:03] <mathiaz> pitti: it's the last sentence.
[04:03] <Hobbsee> bddebian: interesting.  then, you're still wrong :P
[04:03] <bddebian> So what else is new
[04:04] <lamont> "in progress" == "I'm working on it"; "fix committed" == "I committed it to my VCS/SCM/$TLA"; "Fix Released" == "Source is uploaded"
[04:04] <mathiaz> pitti: beta page on the w.u.c is fine.
[04:04] <Hobbsee> lamont: as to why we dont put syntax highlighting on by default, i'm not sure.
[04:04] <bddebian> Maybe it's just retirement time
[04:04] <mathiaz> pitti: actually no.
[04:04] <cjwatson> bddebian: FixReleased has meant "uploaded" since Ubuntu moved to Launchpad
[04:04] <Keybuk> bddebian: there could be an argument for "Fix Committed", "Fix Uploaded", "Fix Available" instead of the two states
[04:04] <Keybuk> but it'd be a bit of a nightmare to track
[04:04] <Keybuk> especially given the dream of tools setting them automatically
[04:04] <Keybuk> Fix Committed = applied automatically when a commit appears in a bzr branch specially tagged
[04:04] <Keybuk> Fix Uploaded = applied automatically when the upload processor sees a special changelog entry (LP: #1234)
[04:04] <Keybuk> Fix Available = applied automatically when the mirror tracker sees that the fixed version has appeared on all mirrors
[04:04] <Keybuk> the problem with the latter is what happens when an upload fails to build?
[04:04] <Keybuk> the FTBFS is a new upload
[04:04] <Keybuk> with a new bug fix
[04:04] <pitti> mathiaz: ok, I'll ask Matthew to do that change on www.u.c., thanks for spotting
[04:04] <Keybuk> so the system would have to apply it to the current version and all previous FTBFS versions
[04:04] <Keybuk> and that's not reliable
[04:04] <cjwatson> or when a mirror in Antarctica is broken for seven weeks
[04:04] <Hobbsee> Keybuk: oh no, now you're sounding like kiko
[04:05] <Keybuk> since the fix to fix the building may have been to back out the bugfix again
[04:05] <Hobbsee> cjwatson: *cries*.  but i want my antarctic mirror to work! :P
[04:05] <Keybuk> Hobbsee: I am?
[04:05] <cjwatson> Hobbsee: might be faster than the Australian ones, I concede
[04:05] <Keybuk> cjwatson: or when a fix is uploaded on September 11th
[04:05] <bddebian> Uncle, Uncle,.. I said OK....
[04:05] <ogra> cjwatson, not from australia i guess :)
[04:05] <Hobbsee> Keybuk: he was discussing this at UDS. yes.  or perhaps it was matt.
[04:05] <Keybuk> "it can't be fix available, the Chilean mirror is down"
[04:05] <Hobbsee> cjwatson: *grin*
[04:06] <Hobbsee> cjwatson: no, the default au ones suck.  the planet mirror ones are much better :)
[04:06] <Hobbsee> cjwatson: i've no idea why we dont change the default au mirror, to something that *doesnt* suck.
[04:06] <dholbach> Riddell: http://daniel.holba.ch/sponsoring
[04:31] <Kopfgeldjaeger> hi
[04:35] <saispo> anyone have heard some problem with bcm43xx and gutsy ?
[04:37] <pitti> saispo: works fine for me
[04:37] <pitti> --verbose?
[04:39] <ogra> works great here
[04:40] <ogra> lots better than in feisty (read: i had no crashes at all yet)
[04:40] <saispo> pitti: will try this evening @home
[04:41] <saispo> pitti: the connection is well, association with ap too
[04:41] <saispo> but i lost a lot of packages, not possible to apt, etc, etc...
[04:41] <saispo> i have this since the lastest kernel updates, with the old 2.6.22 no problem
[04:44] <asac> pitti: so you ended up with bcm43xx for your new laptop?
[04:44] <asac> (or still your mac?)
[04:44] <pitti> asac: no, that's still my old one (the iBook)
[04:44] <pitti> asac: latitude is ordered, that has an ipw3945
[04:44] <asac> ok great. dell appears to have shipping issues though.
[04:45] <ogra> pitti, do you have the 3 years full ?
[04:45] <asac> pitti: what is your expected shipping date?
[04:45] <saispo> pitti: you use wich firmware with bcm43xx ?
[04:45] <pitti> ogra: yes
[04:45] <ogra> wow
[04:45] <ogra> i still have to wait til may
[04:45] <pitti> asac: I ordered Tuesday, they sad "on or before Oct 23"
[04:45] <mvo> Riddell: does the qt update-notifier support the reboot-required flag?
[04:46] <pitti> I seriously hope that it's well before that
[04:46] <pitti> ogra: I started in August 2004
[04:46] <mvo> pitti: which one did you ordered?
[04:46] <pitti> mvo: D430
[04:46] <asac> pitti: yeah ... i doubt it ... read in the news that dell in germany has serious issues
[04:46] <mvo> pitti: cool!
[04:46] <asac> the one i ordered is scheduled for 5 weeks :/
[04:46] <pitti> but I want this baby for UDS!
[04:46] <ogra> they talked about at least 7 weeks what i read
[04:46] <asac> but lets hope ;)
[04:47] <ogra> but only certain models (the colored ones, not sure which # tht is)
[04:47] <asac> ogra: yes, but still ridiculous for a global player like dell
[04:49] <ogra> yeah
[04:50] <bddebian> heh
[04:50] <StevenK> Nah, it's me.
[04:50] <bddebian> StevenK: Oh, I looked breifly at libapache-asp-perl last night and it appears that it might work with apache2 and the filter depends might be able to be dropped
[04:50] <StevenK> Oh well
[04:51] <StevenK> bddebian: Great
[04:51] <pochu> pitti: liferea-gdb is in NEW, in case you can take a look at it :-) (or any other archive admin)
[04:54] <seb128> pochu: hey
[04:54] <seb128> pochu: did you do the tracker update?
[04:58] <pochu> seb128: yes, although I havent added the deskbar scripts to postinst and prerm :(
[04:58] <seb128> pochu: no need of that, we changed the deskbar schemas to list deskbar by default
[04:59] <seb128> to list tracker
[04:59] <pochu> oh, nice :-)
[04:59] <pochu> seb128: let me test it a bit (haven't done it yet)
[04:59] <Mithrandir> hm, OOo's presentation thingy really doesn't handle dualhead well
[04:59] <seb128> pochu: ok, uploads will not be accept before tomorrow anyway
[05:00] <pochu> seb128: do we need an UVFe for this?
[05:01] <esr> mjg59: still there?
[05:02] <seb128> pochu: no
[05:02] <sladen> esr: !just ask
[05:02] <bddebian> heh
[05:02] <seb128> pochu: it already has been approved, we want the fixes in the new version
[05:03] <bddebian> esr: You are in Philadelphia?
[05:03] <pochu> seb128: cool. I'm reindexing, let's see how it works :-)
[05:03] <esr> bddebian: Near it.  Why?
[05:03] <bddebian> Just curious.  I live in Schwenksville, work in Philly
[05:04] <bddebian> I didn't know we had anyone "famous" around here :-)
[05:06] <esr> I used to live very near Schwenksville, actually -- about halfway between there and Collegeville.  For a couple years in the early Seventies.
[05:06] <StevenK> seb128: It looks like rc3 includes its own print plugin, and the Debian package Conflicts/Replaces with gimp-print 5.0.1-3.
[05:06] <bddebian> Wow, you learn something new every day :)
[05:07] <seb128> StevenK: it's a bit late for a new plugin, can we disable it and keep using the current one for gutsy?
[05:07] <StevenK> seb128: I don't see why not. I'll look at doing so.
[05:07] <esr> mjg59: I note that acpi-support doesn't include a script for the dock-eject key.  Is there any good reason not to add one that simply calls eject(1)?
[05:08] <seb128> StevenK: thanks
[05:08] <soren> esr: That would just eject the cdrom?
[05:09] <ogra> soren, dock-eject sounds somewhat like eject to remove laptop from docking station
[05:09] <esr> Well, if you had a floppy inserted it would eject the floppy. :-) But yes.
[05:09] <ogra> (just a guess)
[05:09] <soren> esr: "If no name is specified, the default name "cdrom" is used."
[05:09] <ogra> <- nt good at guessing today :)
[05:10] <soren> esr: Of course you might have cdrom symlinked to your floppy drive.. :/
[05:10] <esr> No, the graphic makes it clear it's meant as a CD-ROM eject.
[05:10] <soren> Ah, I thought you just established it was a dock eject sort of thing?
[05:12] <Riddell> mvo: yes, I added reboot required notification to adept in gutsy
[05:12] <StevenK> seb128: Okay, I've changed the configure flags and dropped the Conflicts/Replaces against gimp-print, I'll test build it and make sure it doesn't build/install the print plugin.
[05:12] <esr> Actually...the graphic uses a littler triangle-above-bar thing that looks like the eject graphic on CD and tape players.
[05:12] <seb128> StevenK: thanks
[05:12] <StevenK> seb128: If I sort that out, do you think it's okay to upload?
[05:12] <seb128> StevenK: yes
[05:12] <StevenK> seb128: Okay, cool
[05:13] <seb128> StevenK: we still need an approval from pitti or slangasek but that's should be alright
[05:13] <soren> esr: meh
[05:13] <StevenK> esr: If it's a slot load CD-ROM, I'd say it's for that
[05:14] <esr> It is.
[05:14] <soren> esr: Yes, but it's not like there's anything particularly cdrommy about it.
[05:14] <soren> esr: It's a generic eject pictogram.
[05:15] <StevenK> "cdrommy" I'll have to remember that one
[05:15] <soren> esr: I don't find that the graphic makes it at all clear that it's meant as a CD-ROM eject. Party because... well, it isn't. it's meant as a dock eject.
[05:16] <soren> esr: Some docks have metal lock things that keep you from taking you machine off of the dock without break either or both.
[05:16] <esr> soren: And what does "dock ejecct" mean to you?  Trust me, the button cannot be used to release the UltraBase.
[05:16] <StevenK> Why the dock eject be on the laptop itself, though? Every dock I've seen has a big eject on them *not* the laptop.
[05:17] <esr> And it can't be used to operate a lock, either. There is one, but it's mechanical.
[05:17] <soren> esr: "Dock eject" means eject (from) dock.
[05:17] <soren> to me.
[05:17] <StevenK> And on the UltraBase itself, I'm betting
[05:18] <soren> Just because something's mechanical doesn't mean it can't be operated from software.
[05:18] <esr> OK, shall we just forget that "name* for cripsesakes?  I got it from ThinkWiki; Ghod knows what Lenovo calls the key.
[05:18] <soren> Fans, cd-rom drives, hard drives, floppy drives, USB missile launchers.. Stuff.
[05:18] <StevenK> There's an easy way. Put a CD in and hit the key, if the CD ejects, bingo
[05:19] <soren> On my thinkpad, that button has a pictogram depicting my laptop right next to the eject pictogram.
[05:19] <esr> It doesn't.  I think I can fix things so it does.  And then send that patch to mgj59, who maintains acpi-support.
[05:19] <soren> I don't know what it's supposed to do. I'm responding to two things here:
[05:19] <esr> soren: Mine also.
[05:21] <mvo> Riddell: nice, thanks!
[05:21] <Ng> StevenK: IBM ones do indeed tend to have a button on the dock as well (mine certainly does)
[05:22] <soren> esr: You specifically asked: "what does "dock ejecct" mean to you?". Also, you said "the graphic makes it clear it's meant as a CD-ROM eject".
[05:22] <esr> Yes.
[05:22] <soren> esr: I answered the former, and contested the latter.
[05:22] <soren> I'm sorry if I didn't fulfill you expectations to this conversation.
[05:22] <mvo> Riddell: is bug #103374 something easy to fix? looks like a str<->unicode<->qt issue (you may have answered this already, but I get constantly disconnected so I may have missed a reply)
[05:22] <ubotu> Launchpad bug 103374 in language-selector "[apport]  qt-language-selector crashed with TypeError in _()" [Undecided,New]  https://launchpad.net/bugs/103374
[05:22] <esr> You may scease being pointlessly difficult at any time, you know.
[05:22] <Keybuk> cjwatson: random question
[05:22] <superm1> mornin mvo, did you obtain a few to download that iso and try to reproduce?
[05:23] <Keybuk> do you udevtrigger in the target?
[05:23] <cjwatson> Keybuk: d-i doesn't, some package might
[05:23] <mvo> superm1: good morning! its still downloading, but it should be here soon (I started the download a bit late)
[05:24] <superm1> very good
[05:24] <Riddell> mvo: I replied saying how that was my very favourite sort of bug and I have added to me todo
[05:24] <Keybuk> cjwatson: it's definitely whatever bit of d-i does the dhcp
[05:24] <mvo> Riddell: thanks a lot (and sorry for the naging)
[05:24] <soren> esr: You start by suggesting that something called dock-eject should eject people's cd-rom. I don't think I'm the one causing confusion.
[05:25] <ion_>  /lh
[05:25] <Riddell> mvo: if people don't nag, it'll never get done :)
[05:25] <ion_> Whoops
[05:26] <Keybuk> cjwatson: actually, sorry; it's the "Detecting network hardware" bit
[05:29] <Mithrandir> Keybuk: detecting network hardware is way before you have any target to do udevtrigger in.
[05:29] <Keybuk> right
[05:29] <Keybuk> err, why can't I get into expert mode?
[05:29] <Mithrandir> you're not an expert, apparently? :-P
[05:30] <Keybuk> you can't do it from the gfxboot?
[05:30] <Mithrandir> yes, press F6 twice and you should be allowed to, iirc
[05:31] <Keybuk> I never even knew you could press F6 twice :p
[05:31] <Keybuk> I've just always given up and dropped back to boot:
[05:46] <Keybuk> heh
[05:46] <Keybuk> the udev-udeb includes udevmonitor
[05:46] <Keybuk> but not the important rule to make udev actually send things *to* udevmonitor
[05:46] <Keybuk> d'oh
[05:47] <Mithrandir> details. :-P
[05:57] <Keybuk> weird
[05:57] <Keybuk> UDEV ... add /class/net/eth0 (net)
[05:57] <Keybuk> COMMENT=PCI device 0x1022:0x2000 (pcnet32)
[06:04] <Keybuk> hmm
[06:04] <Keybuk> /lib/udev/write_net_rules: 81: [: not found
[06:05] <iwj> Stupid udev is trying to run /lib/udev/[
[06:05] <iwj> I bet.
[06:05] <iwj> Why oh why oh why etc.
[06:05] <Keybuk> no, this is a shell script
[06:05] <StevenK> But [ is a built-in...
[06:05] <Keybuk> iwj: that actually makes kooky sense, RUN+= might have to run things before /bin/sh is available (yes, don't look at me like that, embedded people are strange)
[06:06] <iwj> It ought to take a list of strings for exec then.
[06:06] <Keybuk> it basically does
[06:06] <iwj> This is hardly rocket science.
[06:06] <Keybuk> with a PATH of /lib/udev only
[06:06] <iwj> Err, why doesn't it use exec[lv] p[e]  then ?
[06:07] <Keybuk> /lib/udev is the only thing you should "by default" guarantee exists
[06:07] <iwj> Ha ha ha.
[06:07] <Keybuk> it forces you to think "ah, do I *have* this tool" when you write the rule
[06:07] <Keybuk> that's the theory anyway
[06:07] <Keybuk> StevenK: this is what's confusing me
[06:08] <StevenK> Keybuk: With good reason. :-)
[06:09] <dobey> hey Keybuk
[06:11] <Keybuk> wow, I don't remember a 1.2.0 -- did someone finally resurrect dircproxy?
[06:18] <Keybuk> entirely replicable too
[06:18] <Keybuk> the [ built-in is missing from /bin/sh
[06:23] <jdong> meh it won't be missed too much.
[06:23] <jdong> who needs conditionals anyway.
[06:25] <iwj> Keybuk: You've got some crazy /bin/sh ?
[06:25] <iwj> ian@anarres:~ $ /bin/sh -c 'type ['
[06:25] <iwj> [ is a shell builtin
[06:26] <Keybuk> iwj: yes, the installer's /bin/sh
[06:26] <iwj> I didn't realise it wasn't just dash or something.
[06:26] <Keybuk> ~ # /bin/sh -c 'type ['
[06:26] <Keybuk> [ is /usr/bin/p
[06:26] <Keybuk> err, [ is /usr/bin/[
[06:26] <Keybuk> (typed from vmware)
[06:26] <Keybuk> so that's the cause of the bug
[06:26] <Keybuk> cjwatson: ^
[06:28] <AlinuxOS> BenC, hello
[06:29] <AlinuxBETA> BenC, ping
[06:30] <AlinuxBETA> https://edge.launchpad.net/ubuntu/+source/network-manager/+bug/37396 Hello, I'm about this bug in Gutsy, My Wireless Card is: 00:09.0 Network controller: Intersil Corporation Prism 2.5 Wavelan chipset (rev 01) it's not recorgnised. I remeber that with Dapper this card worked very well.
[06:30] <ubotu> Launchpad bug 37396 in wpasupplicant "orinoco/prism54 cannot connect to WEP networks" [Medium,Fix released] 
[06:43] <mathiaz> macd: are you on the ubuntu-server mailing ? (wrt to your hardware lab)
[06:43] <macd> no, just the motu-ml
[06:43] <macd> I'll join it today
[06:44] <mathiaz> macd: excellent. We're looking for hardware testing for the beta release.
[06:44] <macd> our vps platform is built on feisty-server, so that shouldnt be a problem at all
[06:45] <mathiaz> macd: you can find all the information at wiki.ubuntu.com/ServerTeam/
[06:45] <macd> we've been running gusty through hoops for a few weeks
[06:55] <bddebian> Anyone an apache guru?
[06:58] <mathiaz> bddebian: try #ubuntu-server
[06:58] <bddebian> mathiaz: OK, thx
[07:08] <mvo> superm1: I got a i/o error duing the install of mythubuntu, is that the python-apt error? I guess not :) it should hang, shoulldn't it?
[07:08] <superm1> mvo, where did you get the i/o error?
[07:08] <superm1> it should be hanging yes
[07:09] <superm1> the disk check upon boot does work
[07:09] <superm1> if you wanted to check it there
[07:41] <bddebian> it looks like most of the libapache modules have names like libapache2-mod-foo2 now.  If libapache-asp-perl works, should the binary package be libapache2-mod-perl2 now?
[07:43] <thom> no
[07:43] <thom> it's a perl package, not an apache module
[07:43] <thom> it should reflect the naming of the perl module
[07:43] <thom> ie, Apache::ASP or whatever
[07:44] <bddebian> Huh?
[07:44] <bddebian> libapache-mod-perl is libapache2-mod-perl2
[07:44] <thom> and that's an APACHE module, not a perl module
[07:45] <thom> (it ought to be libapache2-mod-perl, but anyway, that was my mistake and it won't get fixed now)
[07:46] <bddebian> So should it be libapache2-asp-perl or just stay libapache-asp-perl? (I'm still not getting you. :-) )
[07:46] <thom> what is the name of the perl module? it should exactly reflect that
[07:46] <thom> ie, if it is Apache::ASP, then libapache-asp-perl
[07:47] <thom> if it is Apache2::ASP, then libapache2-asp-perl
[07:47] <bddebian> Ahh, now I gotcha
[07:47] <bddebian> Though I swore I saw an Apache2::ASP somewhere.  Hrmm
[07:49] <bddebian> Ohh, hrm, I think it's part of mod_perl2 now
[07:52] <bddebian> Oh, no, I'm a crack-head.  It's a new module. apache2-asp
[07:52] <bddebian> seb128: See why I need to quit :)
[07:55] <bddebian> thom: mod_include (SSI) and mod_ext_filter are part of apache2 now and don't need seperate packages, correct ?
[07:56] <thom> now?
[07:56] <thom> for the last hundred million years
[07:57] <bddebian> I was going to ask for removal of libapache-asp-perl, libapache-ssi-perl, and libapache-filter-perl
[07:59] <thom> those are perl modules, not apache modules
[07:59] <thom> hence the cunning addition of *-perl* on the end
[08:00] <bddebian> thom: Understood but libapache-asp-perl is apache 1.x only.
[08:01] <jander99> Does anyone know who maintains Ubuntu's hardware database?
[08:33] <glatzor> bryce_: Riddell: could one of you please upload a new version of kde-guidance, since I updated the MonitorsDB
[08:33] <glatzor> it should fix most generic monitors
[08:56] <stgraber> mathiaz: ping
[09:21] <stgraber> mathiaz: do you want to add testcases for things like "print server", "mail server", ... ?
[09:22] <mathiaz> stgraber: yes. That would be great.
[09:22] <mathiaz> stgraber: heno said we'd wait after beta.
[09:23] <stgraber> mathiaz: have a list of them ?
[09:23] <mathiaz> stgraber: but since the test cases are already written.
[09:23] <stgraber> mathiaz: I'm working on the testcases list for RC
[09:23] <heno> mathiaz: right, we are doing a batch of updates now
[09:23] <mathiaz> stgraber: https://wiki.ubuntu.com/Testing/Cases/ServerInstall
[09:23] <mathiaz> stgraber: the wiki page lists 7 test cases.
[09:25] <heno> I added those here https://wiki.ubuntu.com/Testing/TrackerUpdate
[09:26] <mathiaz> heno: seems good to me for the server cd.
[09:26] <heno> cool
[09:27] <stgraber> heno: should we check with the different flavour if they want tests to be added ? (LTSP for Edubuntu would be an example)
[09:28] <heno> stgraber: yes, sounds good
[09:28] <heno> they should be written first though
[09:28] <stgraber> Riddell ^
[09:28] <stgraber> (ogra not around)
[09:28] <heno> I have no idea how to test LTSP :)
[09:29] <stgraber> Who's xubuntu guy ?
[09:29] <stgraber> heno: You need two NICs in your server, one connected to the internet, the other to a switch where another computer is connected, then netboot the computer
[09:29] <stgraber> heno: it should be possible to do that with Virtualbox's virtual network
[09:30] <Riddell> looks fine to me
[09:30] <heno> ok, we might have to write a detailed howto for that
[09:31] <heno> yes, Kubuntu and Xubuntu should be fine with the same test types as Ubuntu. they are quite generic
[09:31] <stgraber> ok, so let's just add a LTSP test to Edubuntu
[09:37] <heno> stgraber: yep, agree
[09:39] <stgraber> heno: if you have some free time can you start putting the wiki URLs next to the testcase on the wiki page ?
[09:41] <heno> stgraber: will do
[09:49] <heno> hm, we're missing an oem page; adding a placeholder
[09:50] <stgraber> also add a placeholder for LTSP, I'll write it a bit later (probably on Saturday)
[10:03] <heno> stgraber: done. I've added several placeholders
[10:03] <heno> so now I have a bunch of test cases to write :)
[10:04] <heno> that was a good exercise
[10:05] <stgraber> :)
[10:05] <stgraber> thanks
[10:18] <Mithrandir> seb128: any thoughts about pushing in the new conduit?
[10:36] <seb128> Mithrandir: not really, I don't use nor maintain conduit
[10:38] <Mithrandir> seb128: but, but, but, it's gtk.  You must surely maintain it.
[10:38] <Mithrandir> ;-)
[10:38] <Mithrandir> (ok, point taken)
[10:40] <seb128> Mithrandir: ok, let's do it the usual GTK way, "hum, new crack, let's get it under the permanent GNOME exception nobody will notice" :p
[10:41] <seb128> (just joking)
[10:41] <Mithrandir> seb128: it's actually just dragged in through autosync, so I'll file a bug in Debian asking why the maintainer is slacking. :-P
[10:41] <seb128> ;-)
[11:12] <lamont> hrm.. did someone change the default on lid-close to suspend instead of lock?
[11:15] <Kmos> http://cdimage.ubuntu.com/ports/daily/20070927/gutsy-alternate-powerpc.OVERSIZED
[11:15] <Kmos> IA-64 also oversized
[11:16] <Kmos> sparc and ps3 are fine
[11:50] <Keybuk> that's weird
[11:50] <Keybuk> apport must have broken
[11:50] <Keybuk> it's catching up on literally dozens of unreported crashes
[11:55] <Mithrandir> Keybuk: yeah, I saw it too.  I think it might be the reporter being reenabled lately
[11:57] <Keybuk> apport's firefox invocation must be sub-optimal
[11:57] <seb128> Keybuk: I've fixed update-notifier just before beta, it just silently stacked crashes during the time the notification was b0rked
[11:57] <Keybuk> because I keep getting errors about firefox being unable to start
[11:57] <seb128> though it should clean crashes older than a week, there is a cron task doing that normally
[11:58] <Nafallo> seb128: ekiga fixes isn't there yet?
[11:58] <Keybuk> it also occurs to me that asking the user for information about what they were doing at the time of the crash is sub-optimal
[11:58] <Keybuk> the program should be able to supply that itself
[11:58] <seb128> Nafallo: if the question is "is the freeze over yet", the response is no, it'll be tomorrow
[11:59] <Nafallo> seb128: ah. thanks. I hoped it would be over as soon as we released ;-)
[11:59] <seb128> Nafallo: no, keep some margin to rebuild CDs in case of beta breakage
[11:59] <Nafallo> seb128: ah, oki :-)
[12:00] <Nafallo> seb128: hope it didn't broke then, cause I've uploaded about 130GB ;-)
[12:00] <seb128> ;)
[12:23] <Keybuk> meh, typo sucks sooo hard
[12:26] <terlmann> hello guys... I was testing gutsy with my system , I use an r_200 , and running sauerbraten I encountered multiple glitches. However, the development run is almost over and I switched back to feisty for a clean system . After manually installing sauerbraten's libs, I ran it. None of the artifacts in gutsy were there. I think this problem is due to the recent debian pull for gutsy , as I used debian on this system shortly before testing gutsy and had
[12:26] <terlmann>  the same trouble.
[12:27] <Keybuk> terlmann: did you file a bug?
[12:27] <terlmann> I don't know how to report this bug because it is not really a bug , and there is no error messages or anything
[12:27] <terlmann> just telling you
[12:27] <terlmann> sdl packagers or someone should be notified
[12:27] <Keybuk> bugs are the method of telling us
[12:28] <terlmann> Report what ? no proof :-P
[12:28] <Keybuk> you must be able to describe what didn't work?
[12:28] <terlmann> If you meet someone who runs into this like I did, say hello for me. Terlmann over and out.
[12:28] <terlmann> What did not work ? wireframes and outlining
[12:29] <RAOF> terlmann: Or post a screenshot of the graphical corruption?
[12:29] <terlmann> I never bothered to take one... I assumed at the time someone else would notice this.
[12:29] <Keybuk> probably not
[12:29] <Keybuk> it's in multiverse
[12:29] <Keybuk> that means it's not only supported, but maybe not even modifiable
[12:30] <terlmann> well the bug is not in the game , I use my own copy
[12:30] <terlmann> and the copy is the same
[12:30] <terlmann> I transfered it on disk
[12:30] <terlmann> I compile my own :-)
[12:31] <pwnguin> its likely in universe because the graphics are non-free
[12:31] <pwnguin> ironic
[12:31] <pwnguin> given that users can modify and share level maps in game
[12:31] <terlmann> the game is free
[12:31] <terlmann> not nonfree
[12:31] <pwnguin> point, click and add a wall
[12:31] <pwnguin> DFSG free
[12:31] <terlmann> AND the only dep's are SDL
[12:32] <terlmann> A heck of a lot of sdl
[12:32] <terlmann> but that is it
[12:32] <pwnguin> well yea
[12:32] <terlmann> the bug is in sdl
[12:32] <terlmann> trust me