[00:01] <slangasek> james_w: hmm, I'm running into a few package merges where the debian/squeeze branch isn't up-to-date
[00:01] <slangasek> james_w: is there a way for us to trigger those, or do you want a list, or?
[00:01] <james_w> slangasek: there's no way for you to trigger unfortunately
[00:02] <james_w> slangasek: a list to me will work, but with added latency
[00:02] <james_w> slangasek: is the https://launchpad.net/debian/+source/<package> up to date for these packages?
[00:03] <slangasek> james_w: well, unless you think this might be caused by a bug and having a list will help you track that down, I'm not going to bother, it's obviously much more efficient for me to just grab the merge from MoM in that case
[00:03] <slangasek> checking (bsd-mailx for the current example)
[00:03] <slangasek> yes, that page lists the correct "latest release"
[00:03] <james_w> slangasek: ok, thanks for checking
[00:03] <james_w> I'm happy for you to mention them to me
[00:03] <slangasek> ok
[00:03] <james_w> investigating may help find bugs, and so reduce the frequency
[00:11] <jjohansen> jdstrand: it should be
[00:12] <jdstrand> jjohansen: I'll mark it as such-- thanks :)
[01:31] <dtchen> jdstrand: your audio bug should be fixed in 2.6.32-git
[01:32] <dtchen> lifeless: WRT hda-intel, mm, not really. There are too many issues, but wiki/DebuggingSoundProblems is a starting point. I've also blogged about common issues (with workarounds) in 9.10.
[01:33] <dtchen> lifeless: for the most part, the issues are resolved upstream already, but they may not land for 10.04. 2.6.33 will have them for certain.
[01:46] <lifeless> dtchen: thanks
[02:03] <jdstrand> dtchen: ok-- I'll keep an eye out, thanks!
[02:04] <jdstrand> though, it'll be after UDS before I can test it
[03:51] <slangasek> dtchen: please don't mark bugs as duplicates of #470265 when there's no specific evidence that their /etc/kernel-img.conf was broken.
[03:53] <slangasek> dtchen: this undermines any efforts to determine the actual cause of the problem the user is having
[03:54] <dtchen> slangasek: all right, is there a separate bug I should be triaging against?
[03:54] <dtchen> slangasek: also, sorry for the added workload
[03:55] <slangasek> dtchen: you shouldn't be marking any bugs as duplicates before you've shown that it's a duplicate!  Just reassign the bugs to the grub package in that case
[03:56] <dtchen> slangasek: no, I'm specifically asking what I should be doing with Karmic bugs that are filed against alsa-driver that clearly are not running 2.6.31-1[45]-generic
[03:56] <slangasek> if you need a bug for "I munged menu.lst myself and it broke", I can get you a bug for that; but so far these bugs don't actually seem to be triaged far enough to even say that's the problem the user is having
[03:56] <slangasek> dtchen: just reassign them to the grub package, then
[03:56] <dtchen> slangasek: sure thing, thanks
[03:57] <slangasek> thank you
[05:56] <JohnFlux> Hey all
[05:57] <JohnFlux> Hi all
[05:57] <JohnFlux> Does anyone know who is dealing with input methods at the moment?
[06:28] <slangasek> JohnFlux: ArneGoetje
[06:31] <slangasek> james_w: lp:debian/squeeze/cmake also out of date, it appears
[06:45] <PRIDE> um...question
[06:50] <PRIDE> question?....new to ubuntu, is this where i come if i need help with getting an update for my laptop webcam..my laptop is hp dv6000
[06:50] <ScottK> PRIDE: No.  That's #ubuntu.
[06:50] <ScottK> This is the channel for coordinating development work.
[06:51] <PRIDE> ScottK, mmmk...the problem is they dont kno anything about webcam so i was wondering if the developers could make an update/patch for hp webcams
[06:51] <ScottK> PRIDE: Filing a bug on Launchpad is the best way to approach that.
[06:52] <PRIDE> how would i do that?
[06:52] <ScottK> That question they will know how to answer on #ubuntu.
[06:52] <PRIDE> ScottK, thx
[08:04] <dholbach> good morning
[08:04] <\sh> moins
[08:13] <mvo> hey dholbach
[08:14] <dholbach> hi mvo
[08:24] <glatzor__> morning mvo and dholbach!
[08:24] <maco> the vegetarian brigade?
[08:24] <dholbach> yeeeehaww!
[08:25] <dholbach> hi glatzor__: long time no see - how are you doing?
[08:26] <mvo> hey glatzor__! nice to see you
[08:26] <jsgotangco> wow
[08:27] <dholbach> hey jsgotangco!
[08:27] <jsgotangco> hi dholbach, mvo, glatzor__
[08:27] <mvo> hey jsgotangco
[08:30] <glatzor__> hey jsgotangco !
[08:30] <glatzor__> dholbach, quite well. I hope yourself, too!
[08:30]  * dholbach hugs glatzor__
[08:30] <dholbach> glatzor__: I got my dose of ubuful before flying to UDS :)
[08:31] <maco> well dont hug the man, you're gonna infect him!
[08:36] <\sh> dholbach, this time it could be named ubu-swine-flu ;)
[08:37] <Tm_T> \sh: why not ubu-flu?
[08:38] <\sh> Tm_T, ubuflu is the standard ;) ubu-swine-flu is todays hype, regarding our pediatrician ;)
[08:40] <jsgotangco> dholbach: are you vegetarian already?
[08:41] <dholbach> jsgotangco: yeah, for more than a year now :)
[08:41] <dholbach> jsgotangco: it's what India did to me :)
[08:41] <maco> someone suggested an "ubuntu vegetarians" team on lp so that we could easily coordinate group-meals during UDSs
[08:41] <jsgotangco> dholbach: i'm almost there too
[08:41] <maco> maybe glatzor__ or mvo?
[08:42] <jsgotangco> dholbach: haven't had read meat for more than a year
[08:42] <dholbach> mvo already owns https://launchpad.net/~canonical-vegetarians :)
[08:42] <dholbach> look at these happy people: https://launchpad.net/~canonical-vegetarians/+mugshots
[08:43] <maco> heh nice
[08:44] <maco> we found a vegan restaurant in barcelona
[08:44] <maco> a big group of about 20 of us. 17 went in there while the other 3 went "no meat? i'm out"
[08:52] <\sh> *grmpf* Meeting Topic: "How do you write PHP applications the right way™" -> gone
[08:53] <chrisccoulson> good morning everyone
[08:54] <mvo> maco: ubuntu-vegetrians sounds good to me, that is a bit broader than just the canonical group
[10:30] <ogra> james_w, i have a slight prob trying to merge apex with bzr ... seems the debian branch misses tags http://paste.ubuntu.com/314967/ anything i can do about that ?
[10:34] <slangasek> ogra: merge-package doesn't work for native packages
[10:34] <ogra> aaah !
[10:34] <ogra> ok, the wikipage should probably state that :)
[10:35] <slangasek> it's a bug (bug report is open)
[10:35] <ogra> ah
[10:35] <slangasek> feel free to document on the wiki, too
[12:03] <Riddell> asac: how come network-manager-[vpnc|openvpn|pptp] are in universe?
[12:17] <doko_> Riddell: gdb pong
[12:19] <Riddell> doko_: I'm told by Qt developers that gdb 7.0 doesn't work well with c++, do you know anything about that?
[12:20] <doko_> Riddell: no
[12:20] <doko_> Riddell: is there an upstream report?
[12:21] <Riddell> doko_: http://lists.trolltech.com/pipermail/qt-creator/2009-November/004963.html
[12:30] <Riddell> doko_: so I'm getting calls to put 6.8 into backports, does that make sense?
[12:31] <doko_> Riddell: as a separate package?
[12:31] <Riddell> yes
[12:33] <doko_> Riddell: I don't mind, but it's not a step forward for lucid. could you check if disabling the pie patches helps?
[12:36] <pitti> doko_: remaining java bits for ant moved to -updates now; thanks for confirming the debhelper issue
[12:36] <doko_> pitti: \o/
[12:41] <doko_> Riddell: and it would be good to have reports in launchpad to track those
[13:05] <asac> Riddell: historic reason is that the vpn stuff was more like a second tier product and there were no guarantees that they are maintained in sync
[13:05] <asac> Riddell: plan is to make at least pptp installed by default in lucid
[13:05] <Riddell> asac: will also said this.. 12:14 < wstephenson> Riddell: also the dbus policy perms for pptp appear to be globally wrong in *buntu, NetworkManager can't call the VPN plugin to ask it if it needs secrets
[13:06] <Riddell> asac: is that right?
[13:06] <asac> Riddell: there is a bug yes. but we verified that the vpn plugins work at least a bit
[13:07] <Riddell> "a bit" :)
[13:07] <asac> so its not a general issue ... most likely related to system-settings/user-settings related secrets
[13:08] <asac> i will ask cyphermox to verify them again ... and fix accordingly.
[13:13] <JanC> asac: I think the vpnc stuff is at least as useful in main; from what I hear a lot of colleges/universities/etc. use that
[13:15] <asac> JanC: the main thing we found out around RC time is that in russia you need pptp to get online for most dsl providers .... but I agree ... adding a blueprint for vpn support in lucid
[13:21] <siretart`> asac: I can confirm that the openvpn plugin works in karmic, but I almost always have to activate my vpn connection several times until it stays for longer than about a second.
[13:23] <asac> siretart`: you think you could provide me an account so i can test that on the setup where you see that?
[13:31] <asac> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-vpn-out-of-box-experience
[13:31] <asac> JanC: ^^
[13:32] <JanC> asac: nice
[13:47] <siretart`> asac: hm. that's gonna get difficult. I could paste/attach my logs to some bug if that would help
[13:48] <asac> siretart`: ok. filing a bug against -openvpn would be a good start i guess
[13:48] <asac> thx
[13:56] <ion> Darn, wxErlang is removed in Ubuntu. Not that Wx is very nice, but i’d rather use the Wx bindings than the Tk bindings. :-P
[14:06] <pitti> mvo: flex merge> hppa is no more, so this could have been a sync
[14:06] <mvo> pitti: oh, sorry
[14:07] <pitti> JFYI for next time :)
[14:07] <mvo> indeed
[14:08] <mvo> thanks
[14:14] <jdstrand> Keybuk: hi! I've been going through the blueprints for lucid. I was wondering if there is an upstart session that would be beneficial for people doing upstartification in lucid (ie, what to do, what to avoid, etc)
[14:14] <jdstrand> Keybuk: I checked around, but didn't see anything that quite fit (I could have easily missed it)
[14:15] <Keybuk> jdstrand: I don't think it's worth a session
[14:15] <Keybuk> anything I say now will be out of date by the time lucid releases
[14:15] <jdstrand> heh
[14:15] <jdstrand> ok
[14:15] <Keybuk> and it'd be just a rehash of the session I did in Barcelona anyway ;)
[14:16] <jdstrand> unfortunately I missed that one
[14:16] <jdstrand> Keybuk: the part I most care about atm is the part that is likely one of the most moviing targets
[14:16] <jdstrand> Keybuk: ie, being quiet, but displaying erros appropriately
[14:16] <jdstrand> errors
[14:17] <Keybuk> exactly, that's all subject to change
[14:17]  * jdstrand nods
[14:25] <dholbach> wow, bug 429322 has 2030 subscribers
[14:25] <\sh> hmmm...I'm now somehow stucked with update-manager-core and do-release-upgrade ... it can't be used from a server which doesn't have a internet connection, but I have an ubuntu mirror inhouse...so how do I configure it correctly, without mirroring changelog.ubuntu.com
[14:27] <mvo> \sh: do you have a cdrom? the easiest ist to use the alternative cd then
[14:28] <\sh> mvo, the servers are remote, they don't have any removable medias...:)
[14:28] <\sh> mvo, and I have hundreds of them ;)
[14:29] <\sh> I could however copy the meta-release and meta-release-lts files, and point them to my local archives...
[14:30] <\sh> .oO(and then I wonder why the upgrade tool of hardy points to hardy-proposed and not hardy-updates like e.g. karmic or so (UpgradeTool: http://archive.ubuntu.com/ubuntu/dists/hardy-proposed/main/dist-upgrader-all/0.87.31/hardy.tar.gz)
[14:30] <asac> Riddell: did you already add the firefox/kde spec
[14:32] <mvo> \sh: just download the upgrader in this case http://es.archive.ubuntu.com/ubuntu/dists/karmic-proposed/main/dist-upgrader-all/current/ (karmic.tar.gz) and run it as sudo
[14:32] <mvo> \sh: if you have just internal uris in sources.list it should DTRT
[14:32] <mvo> \sh: if not, please let me know, but I now need to take a short break
[14:35] <\sh> mvo, what should I call from the dist-upgrader archive?
[14:40] <Riddell> asac: no I'm stuck on something silly that's taking too long, but it's next on my todo list
[14:49] <asac> Riddell: created this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-firefox-kde-integration ...
[14:49] <asac> if you have references to current opensuse patches etc. please put them there too
[14:50] <Riddell> ok
[14:51] <Tm_T> asac: lovely (:
[14:52] <Tm_T> Riddell: is there blueprint or other related to why KHTML isn't enough for us, as I would like to do testing with it, what is not working etc
[14:52] <soren> Keybuk: What was the magic trick to make upstart wait until lo was configured before entering runlevel 2?
[14:53] <Keybuk> soren: ... and net-device-up lo ?
[14:53] <soren> Keybuk: WherE?
[14:53] <Keybuk> in /etc/init/rc.conf
[14:53] <Keybuk> though that will break being able to switch runlevel
[14:53] <Keybuk> (ie. you won't even be able to shutdown or reboot)
[14:54] <soren> So... What to do?
[14:54] <Keybuk> nothing
[14:54] <soren> I believe you mentioned you'd SRU a fix for this.
[14:54] <Keybuk> no I didn't
[14:55] <Keybuk> I believe I said I wouldn't block someone else doing an SRU if they could come up with a fix that didn't break everything else <g>
[14:55] <soren> Keybuk: http://irclogs.ubuntu.com/2009/10/27/%23ubuntu-devel.txt at 15:26?
[14:56] <soren> Maybe I misunderstood.
[14:56] <Keybuk> but, frankly, I think it's a waste of time dealing with these problems
[14:56] <soren> mai ænglish nud so guud.
[14:56] <Keybuk> races between Upstart jobs and SysV init jobs, that is
[14:56] <Keybuk> I think it's better to spend the time fixing the bugs that prevent them being made Upstart jobs in the first place
[14:57] <Keybuk> soren: oh, so I did, but I can think of major breakages that will cause now, so I don't :p
[14:59] <Riddell> Tm_T: try reading yesterday's news in slashdot
[14:59] <highvoltage> dholbach: are you around?
[15:00] <soren> So to sum up... When people come into #ubuntu-server complaining their network is broken because the networking job runs before their nics are available, I just tell them to add a "sleep 5" before "ifup -a" and don't deal with the fact that this will exacerbate the problems caused by lo not being configured (since it will be even longer before it is)?
[15:00] <soren> Keybuk: Å
[15:00] <soren> Er...
[15:00] <soren> Keybuk: ^
[15:00] <soren> typing is hard today..
[15:00] <Keybuk> if you like
[15:01] <Keybuk> give them a lollipop too ;)
[15:01] <Keybuk> err
[15:01] <Keybuk> what networking job?
[15:01] <soren> /etc/init/networking.conf ?
[15:01] <Keybuk> that's an Upstart job
[15:01] <soren> i know
[15:01] <Tm_T> Riddell: roger (:
[15:01] <Keybuk> soren: I was actually thinking a bit about this the other day
[15:02] <Keybuk> we use network manager to bring up network devices
[15:02] <soren> Keybuk: Where else would I add it?
[15:02] <Keybuk> so the whole ifup-on-network-device-added thing could go away
[15:02] <soren> You're not going to install networkmanager on people's servers.
[15:02] <soren> Are you?
[15:02] <Keybuk> why not? :p
[15:02] <soren> Because you are not in #ubuntu-server explaining this to people.
[15:03] <soren> I am.
[15:03] <Keybuk> I bet they hate D-Bus too
[15:03] <soren> Are you adding bridging and bonding support to network-manager?
[15:03] <Keybuk> no
[15:03] <Keybuk> that sounds like a server team project
[15:03] <soren> Or are you just going to declare those completely unsupported?
[15:04] <evand> Keybuk: You're just here to cause trouble, aren't you? :-P
[15:06]  * soren gives up
[15:09] <pitti> soren, Keybuk: could there be an udev rule which checks whether a newly added eth device is in /e/n/i and call ifup for it? (instead of an upstart job)
[15:09] <pitti> hardware triggered actions sound fine for this?
[15:10] <pitti> description     "configure virtual network devices"
[15:10] <pitti> oh
[15:10] <pitti> soren: so the problem is that those virtual ones sit on top of real ones which aren't available at that time yet?
[15:10] <pitti> (bonded, etc.)
[15:10] <\sh> pitti, I'll take over, soren asked because of me
[15:11] <\sh> pitti, bonding interfaces are in need of hw nics...and somehow after my dist-upgrade, network isn't there (using bonding and vlans on top of the bond) which is horrible for server people
[15:12] <pitti> \sh: how did that ever worked in earlier releases then? it was just a static init script as well, after all?
[15:12] <pitti> just sheer luck, and init script running later?
[15:12] <\sh> pitti, in jaunty is was still /etc/init.d/networking and if-up magic
[15:13] <pitti> \sh: well, that's pretty much what we have now, too
[15:13] <pitti> it just might be started a tad earlier
[15:14] <\sh> pitti, I'm rebooting the server just now...where can I look which job is started when (regarding the mix of upstart + init scripts)
[15:14]  * pitti declares victory over dk-disks bugs and leaves it with zero new ones
[15:15] <pitti> \sh: now, ifup -a is started as soon as local file systems are mounted and udev coldplugging is done
[15:15] <maco> 0 boogs? oooo, shiny!
[15:15] <pitti> (see /etc/init/networking.conf)
[15:15] <pitti> maco: 0 new bugs
[15:15] <maco> still shiny!
[15:15] <pitti> plenty of incomplete/triaged, too
[15:15] <maco> slightly shiny ;-)
[15:17] <\sh> pitti: oh weia...i hope it's not the same crap I triggered during intitramfs dhcp requests with "ipconfig"
[15:17] <soren> pitti: It's a well known problem.
[15:17] <\sh> pitti, then I can give you at least one thing: nic devices are not set to auto when doing bonds or vlans
[15:17] <soren> pitti: The networking job (which calls "ifup -a") is run much, much earlier in karmic than before.
[15:18] <soren> So early, in fact, that the physical nic's often are not available yet.
[15:18] <pitti> soren: ah, what I suspected; so it was by and large "luck"
[15:18] <soren> In a sense.
[15:18] <pitti> which made me wonder whether we should have an additional udev rule to catch late stragglers
[15:18] <soren> It's always been racy, but I don't know of anyone who was ever bitten by this before.
[15:19] <soren> In Karmic, I haven't heard of anyone for whom it works.
[15:19] <soren> pitti: The solution is to configure the virtual interfaces when the corresponding physical ones are available.
[15:19] <pitti> is it really the nics which arrive so late? shouldn't udevsettle wait for them?
[15:20] <soren> pitti: I thought so too, but no.
[15:20] <pitti> soren: exactly
[15:20] <pitti> soren: and that's what udev rules are for, like ACTION=="add", SUBSYSTEM=="net", ...
[15:20] <soren> pitti: Right.
[15:20] <pitti> with ... being something that calls a script on the $INTERFACE variable which checks if that is in /e/n/i
[15:20] <soren> pitti: Problem is that /etc/network/interfaces is the other way around.
[15:21] <soren> pitti: It defines the bond0 interface, which then specifies that it "contains" eth0 and eth1, for instance.
[15:21] <soren> Rather than:
[15:21] <soren> iface eth0
[15:21] <soren>    part-of bond0
[15:21] <soren> or whatever.
[15:21] <soren> Otherwise, it'd be easy.
[15:22] <pitti> sure, but you could just try to bring up all of those
[15:23] <\sh> pitti, if the interfaces are "auto up" they won't be used by the bond module...they need to be unconfigured, and not up..management of those hw nic interfaces is being done by the bond module
[15:23] <soren> Keybuk: What if we simply called "ifup -a" from network-interface.conf ?
[15:23] <pitti> soren, \sh: a very brutal and hopelessly inefficient rule would just be
[15:24] <soren> Ah, no, that'd be bad.
[15:24] <pitti> ACTION=="add", SUBSYSTEM=="net", RUN+="/sbin/ifup -a"
[15:24] <soren> pitti: No, that will be bad.
[15:24] <pitti> soren: .. assuming that the ones where half of the componetns are still missign will just gracefully fail, of course
[15:24] <soren> pitti: If you ifdown an interface and then another one turns up, they'll both be ifup'ed.
[15:25] <pitti> soren: right, which is why I only propose this for a first test :)
[15:25] <pitti> it doesn't handle manual ifdowns at all
[15:25] <soren> It will work around the problems on servers, but is not a proper fix.
[15:26] <pitti> no doubt
[15:26] <\sh> pitti, don't we get a "I catched all hw nic interfaces now, and I'm, the almighty udev, is done doing jobs on hw NICs, now do your job, evil ifup -a" event
[15:26] <soren> You can't know when it's caught all the hw interfaces.
[15:26] <pitti> \sh: that's what I suspected it'd already do
[15:26] <pitti> after an udevadm trigger/udevadm settle I had expected everything to be "there"
[15:26] <nxvl> james_w: if there is a package that doesn't have bzr branch, can i import-dsc and upload it? or it needs to be automagically?
[15:27] <soren> You can never know if another interface is going to turn up.
[15:27] <pitti> which made me wonder whether it's really the NICs which are missing, or whether some other modules are only loaded later
[15:27] <soren> Maybe you add a USB one later on.
[15:28] <\sh> pitti, I ran into a similar problem while doing dhcp request inside the initramfs (ipconfig is executed, I can see the module being loaded, but the dhcp request was already sent out into the dark, which gives a really nice timeout)
[15:29] <\sh> somehow I wonder if I can change it when adding the correct nic kernel module
[15:29] <soren> Keybuk: Can you confirm that "udevadm trigger;udevadm settle" does not guarantee that all your NIC's have been handled by udev?
[15:29] <soren> Keybuk: Or the opposite of "confirm", whatever that is.
[15:30] <pitti> soren: I actually wondered about that as well; how do you say for "confirm that it is false"?
[15:31] <dholbach> highvoltage: yes
[15:33] <\sh> just to remark: if someone does an upgrade from hardy to lucid in the future, this will strike many server people running hardy lts on their infra...and they won't be amused when their tests are failing ;)
[15:35] <soren> Keybuk: How serious are you about network manager on servers?
[15:35] <highvoltage> heh, who would want that?
[15:36] <soren> highvoltage: Noone, except Keybuk, I imagine.
[15:36] <soren> highvoltage: Trouble is, he sits on upstart and udev and all that jazz.
[15:37]  * soren /really/ goes to pick up daughter at day care
[15:37] <highvoltage> soren: ok :)
[15:41] <Keybuk> soren: sorry, I've been on a call for the past hour
[15:41] <Keybuk> soren: just reading scrollback
[15:42] <Keybuk> pitti: actually udev rules must *NOT* be used for this
[15:42] <Keybuk> pitti: udev rules are subject to timeouts, security issues, etc.
[15:42] <Keybuk> pitti: ACTION=="add", SUBSYSTEM="net",... in udev => "on net-device-added" in upstart
[15:43] <Keybuk> pitti: it's run at the same time, except in a sane environment, with very well understood blocking semantics, etc.
[15:43] <pitti> oh, interesting; and that's safer than a straight udev rule?
[15:43] <Keybuk> pitti: (and you can multiplex them :p)
[15:43] <pitti> good to know
[15:43] <Keybuk> soren: "udevadm trigger; udevadm settle" only guarantees that udev is idle - it does not guarantee *ANYTHING* about the state of any hardware device
[15:44] <Keybuk> pitti: much safer
[15:44] <Keybuk> anything in a udev RUN rule should really be considered "part of udev"
[15:45] <Keybuk> a good rule of thumb is that if it doesn't immediately reconfigure the device in any way, or doesn't result in further processing, it should not be
[15:45] <Keybuk> (udev-config-printer I'm looking at you - you will die)
[15:45] <Keybuk> if you want something to happen "when a device is ready", that's what Upstart is for ;)
[15:46] <\sh> Keybuk, and when you need to know if "more then one device needs to be ready"?
[15:46] <Keybuk> exactly
[15:46] <pitti> Keybuk: so ifup'ing doesn't count as "immediate processing'?
[15:46] <Keybuk> now, the bonded interface problem
[15:46] <Keybuk> pitti: no, because it can run things like wpa supplicant, dhclient, etc.
[15:46] <pitti> ah, right
[15:46] <Keybuk> there are lots of bugs when we used to run ifup from udev where udev got bored and killed it ;)
[15:47] <Keybuk> thus /etc/init/network-interface.conf
[15:47] <Keybuk> which is the same udev rule, expressed as an upstart job
[15:47] <Keybuk> so, NOW, the bonded interface problem
[15:47] <Keybuk> ifup eth0
[15:47] <Keybuk> ifup eth1
[15:47] <Keybuk> that's all easy, because we have a physical device
[15:48] <Keybuk> bond0 (eth0 eth1) is hard
[15:48] <Keybuk> what you want is something that notes down each network device as it comes up
[15:48] <Keybuk> configures them if necessary
[15:48] <Keybuk> and also knows about bonded devices, bridges, tunnels, and all manner of other virtual devices
[15:48] <Keybuk> and knows what their dependencies ar
[15:48] <Keybuk> so when it has both eth0 and eth1, it configures the bridge or the bond
[15:49] <pitti> shouldn't /e/n/i already have all this information?
[15:49] <Keybuk> it probably does in the wrong order
[15:49] <Keybuk> but then you still need a daemon that parses /e/n/i and acts on it, as a result of events from udev
[15:50] <Keybuk> we have one of those ;)
[15:50] <Keybuk> we could teach it about bonded interfaces, bridges, and stuff
[15:50] <Keybuk> and then we would have win
[15:50] <pitti> (NM stopped reading /e/n/i long ago, I think)
[15:50] <mr_pouit> james_w: lp:ubuntu/mousepad doesn't seem to exist (it's the first one missing I encounter, so maybe this is a bug :])
[15:50] <Keybuk> really? the Fedora one still does basically this for its sysconfig stuff
[15:51] <pitti> well, you probably wouldn't need a daemon, it could be done in the upstart job?
[15:51] <Keybuk> ah
[15:51] <Keybuk> now
[15:51] <pitti> asac: ^
[15:51] <Keybuk> that's a different thing
[15:51] <Keybuk> we could do this a different way
[15:51] <Keybuk> we could parse /e/n/i and generate upstart jobs from it
[15:51] <Keybuk> since upstart jobs can do the "when eth0 and eth1 are ready" thing
[15:51] <qense> Aren't the lp:ubuntu/source-pacakage branches now pointing to Lucid?
[15:51] <ion> Upstart could be extended to watch /e/n/i and create/update internal job definitions like network/bond0: while network/eth0 and network/eth1, ...
[15:51] <pitti> ah, clever
[15:51] <Keybuk> so you could have an auto-generated job that was basically
[15:51] <Keybuk>   on net-device-up eth0 and net-device-up eth1
[15:52] <ion> Ah, i should have read Keybuk’s last few lines. :-P
[15:52] <Keybuk>   exec ifup bond0
[15:52] <mr_pouit> qense: there is no branch at all for this package apparently (lp:ubuntu/<release>/mousepad)
[15:52] <Keybuk> this is, in principle, what we're planning to eventually do for fstab
[15:52] <Keybuk> we had a bunch of crappy shell scripts that did everything badly
[15:52] <Keybuk> we replaced it with a daemon that intermediates between udev and upstart
[15:53] <Keybuk> and encodes all of the corner cases
[15:53] <Keybuk> and we intend that daemon to go away again in the longer-term, with its code being used to generate upstart jobs instead
[15:53] <qense> mr_pouit: no there isn't, apparantly it's code is not hosted on Launchpad yet
[15:53] <pitti> Keybuk: "a daemon" == mountall?
[15:53] <Keybuk> ie. mountall would become a "upstart-fstab-helper" that resulted in mount/sda1 mount/sda2 type jobs being automatically created
[15:53] <Keybuk> pitti: exactly
[15:54] <Keybuk> so for networking, we have basically the same issue
[15:54] <Keybuk> ifup doesn't really lend itself to event-driven construction
[15:54] <Keybuk> but we don't have the intermediate daemon either, or the final solution
[15:54] <qense> mr_pouit: you could try "apt-get source mousepad", but you'd have to have the right source repository enabled
[15:55] <mr_pouit> qense: I know. I thought that all packages had already been imported, that's why I'm wondering.
[15:56] <qense> ah
[15:57] <Keybuk> so given that, it's not unreasonable to have an upstart-eni-helper as well <g>
[15:57] <qense> I see a lot of people that still have CD-drives in their fstab. Is that really necessary, or does UDev handle them just as well without?
[15:59] <Keybuk> qense: udev doesn't care about fstab at all
[15:59] <qense> You could just as well remove the entry?
[16:02] <pitti> oh, udev 147
[16:02] <evand> qense: https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-dynamic-cdrom-handling
[16:02] <pitti> Keybuk: FYI, we have a new CK ready for udev 147
[16:02] <Keybuk> pitti: yeah
[16:02] <Keybuk> pitti: it's ready?
[16:03] <qense> evand, Keybuk: thanks
[16:03] <pitti> Keybuk: yep; I already committed all our remaining changes to Debian git, so we'd only need to sync
[16:04] <pitti> Keybuk: new CK has Breaks: udev (<< 147~)
[16:04] <Keybuk> shouldn't that be << 147 ?
[16:04] <Keybuk> since 147~ is in karmic
[16:04] <pitti> Keybuk: right, we need to bump that
[16:05] <pitti> I'll just bump it in Debian git and upload a snapshot
[16:05] <Keybuk> http://launchpadlibrarian.net/35479479/amilo-karmic-20091110-3.png
[16:05] <Keybuk> ^ I wonder whether he's using wubi
[16:06] <Keybuk> pitti: I think I'll get to udev tomorrow
[16:06] <pitti> Keybuk: I'll upload a new CK to ubuntu-desktop PPA
[16:07] <Keybuk> ok
[16:08] <Keybuk> (I have two hours left of the day, and have some bug triage to do first :p)
[16:09] <evand> wubi would be my guess as well
[16:11] <cjwatson> Riddell: FYI: the debconf KDE frontend has been removed upstream, since it's still qt3 and the qt4 perl bindings aren't ready yet. It'll fall back to other frontends as available
[16:11] <\sh> Keybuk, and what would be now a good workaround for people like e.g. me, upgrading from jaunty to karmic or from hardy to karmic? or should I write upstart jobs as you described earlier?
[16:13] <Riddell> cjwatson: thanks, that's interesting.  we don't really use it though since packagekit doesn't do debconf much currently
[16:14] <cjwatson> Riddell: yeah, I have mail about that to process at some point too :)
[16:14] <cjwatson> anyway, thought I'd better not merge before telling you
[16:42] <\sh> Keybuk, this net-device-up thingy should work from karmic on?
[16:42] <Keybuk> yes
[16:42] <Keybuk> it's *used* in karmic
[16:42] <Keybuk> though I reserve the right to change the syntax, name of the event, etc. :p
[16:43] <\sh> Keybuk, well, it's used in mountall-met as "start on net-device-up" but start on (net-device-up eth0 and net-device-up eth1) etc. some doesn't work ;) I replaced /etc/init/networking.conf with that
[16:44] <\sh> (or I'm too stupid to understand Upstart right now ;))
[16:44] <\sh> s/met/net/
[16:44] <Keybuk> sometimes doesn't work?
[16:44] <Keybuk> or flat-out doesn't work?
[16:44] <Keybuk> do you have iface eth0 and iface eth1 in your /e/n/i ?
[16:45] <MacSlow> mvo, hey there
[16:45] <\sh> Keybuk, no...that's the point using bonding ;)
[16:45] <Keybuk> if not, you want s/-up/-added/ :p
[16:45] <\sh> ah...
[16:45] <Keybuk> ie. when the network device exists, not when it's been broght up
[16:45] <\sh> yes..ok..understood ;)
[16:48] <\sh> Keybuk, can someone create the "start on ..." statement in pre-start script automagically?
[16:50] <Keybuk> \sh: not currently
[16:50] <Keybuk> and Upstart has no "memory" so even if you created the job on boot, you'd have a race
[16:51] <\sh> Keybuk, hmmm..
[16:51] <\sh> Keybuk, btw..http://paste.ubuntu.com/315215/ <- this is now what I have
[16:51] <\sh> and it doesn't work ;)
[16:53] <mvo> hey mac
[16:53] <mvo> hey MacSlow
[16:53] <Keybuk> please be more verbose
[16:53] <Keybuk> is it started?
[16:54] <\sh> Keybuk, it is started somehow (i see the bond interface) but no hw nics (speak eth0 eth1 eth2 eth3) added to the bond...so the bond itself -> success, but no unterlaying hw interfaces
[16:54] <Keybuk> \sh: so there must be something else it needs
[16:54] <Keybuk> Upstart is doing the right thing for you, but ifup isn't
[16:54] <\sh> therefore the next interface (vlan) is not up, because the bond is not functional
[16:54] <\sh> Keybuk, /etc/init.d/networking restart -> et voila
[16:55] <Keybuk> that tells me you need something else in that ...and... clause
[16:56] <\sh> Keybuk, but what is missing? there can't be much more ... module-init-tools?
[16:57] <Keybuk> \sh: buggered if I know
[16:57] <Keybuk> bondage is something I prefer to do in my spare time
[16:57] <\sh> Keybuk, ok...in /etc/modules I have the bonding module and the 8021q module..so module-init-tools is loaded somehow...
[16:57] <Keybuk> \sh: ...and stopped module-init-tools
[16:59] <\sh> let see
[17:00] <\sh> Keybuk, you think we can get that straight before lucid? adding such scripts manually and thinking about a very insane setup I and others have regarding several types bonding ... I think we need for lucid a good safeword to make people happy ;)
[17:01] <\sh> na..failed
[17:01] <Keybuk> \sh: I will not get anywhere close to straight on that before lucid
[17:01] <Keybuk> if it's important, I will need help
[17:02] <jdong> ooooooh ureadahead?
[17:02] <jdong> *must play*
[17:03] <\sh> Keybuk, how can I enable upstart --debug? and where to look after?
[17:03] <Keybuk> \sh: initctl log-priority info
[17:03] <Keybuk> (you don't want debug)
[17:04] <\sh> Keybuk, is this static then, or is this gone after reboot
[17:04] <Keybuk> \sh: gone after reboot
[17:04] <Keybuk> you can add --verbose to the kernel command-line to get the same effect
[17:07] <\sh> Keybuk, in menu.lst you mean and then ? just "--verbose" or more "init=/sbin/upstart --verbose" or something
[17:07] <Keybuk> just --verbose
[17:13] <\sh> Keybuk, I can see the networking after udev-finish init: handling started event \n networking main process exited normally goal changed from start to stop netowrking state changed from running to stopping -> init: Handling stopping event state changed from stopping to killed, from killed to post-stop and post-stop to waiting
[17:14] <\sh> sorry...but I reproduced the output via manual typing while reading from IlO ;)
[17:14] <\sh> Keybuk, means: networking failed again ;)
[17:15] <Keybuk> so you need something else too ,g>
[17:15] <Keybuk> keep adding those ...ands :p
[17:15] <\sh> Keybuk, lol
[17:15] <\sh> Keybuk, anyways..ending for today....tomorrow more :) thx anyways :)
[17:15] <\sh> soren: same goes to you :) thx
[17:44] <thekorn> ping
[17:46] <thekorn> whos's the korn now?!
[18:15] <kirkland> cjwatson: slangasek: approximately when do lucid livecd ISOs start showing up?
[18:18] <cjwatson> "at some point"
[18:18] <cjwatson> I think slangasek was planning to do it this week
[18:19] <cjwatson> kirkland: are you making plans based on them?
[18:31] <jdstrand> mdeslaur: it just occurred to me slangasek would be good to have in your 2-factor auth session
[19:20] <xisco> hi all, I want to know if there's any way to stop pynotify right the way
[19:35] <pitti> mbiebl: hm, do you see a clever way how to get bug 465054 solved for Debian, without an admin group?
[19:37] <pitti> mbiebl: of course we could just patch the .policy to generally allow it to local foreground users, but that seems a little too much to me
[19:38] <mbiebl> I don't think that would be a good idea
[19:38] <mbiebl> question is, if you want to use the "admin" group
[19:38] <mbiebl> or if we create a custom group for that
[19:39] <pitti> mbiebl: we don't currently have the concept of "admin" vs. "underdog" users in Debian, I think?
[19:39] <mbiebl> There are special purpose groups like netdev/plugdev etc
[19:39] <mbiebl> but afaik no "admin" group by default
[19:40] <pitti> plugdev was introduced as the exact opposite, though
[19:40] <pitti> nowadays it's pretty much obsolete, I think
[19:41] <mbiebl> exact opposite, why?
[19:41] <pitti> mbiebl: it gave you the privilege to mount removable devices (only) without password
[19:41] <pitti> that was from the pmount age
[19:42] <pitti> s/removable/hotpluggab/e
[19:42] <mbiebl> yeah, and you want the same behaviour for internal devices
[19:42] <pitti> mbiebl: yes
[19:42] <mbiebl> I didn't want to imply that we have to use plugdev for that
[19:43] <pitti> $ grep auth_admin /usr/share/polkit-1/actions/*|wc -l
[19:43] <pitti> 70
[19:44] <pitti> I guess this problem extends beyond dk-disks, but there we got the most complaints from so far
[19:44] <mbiebl> pitti: my thinking is rather if we should design new groups for the pk-1 world
[19:44] <mbiebl> or reuse existing ones
[19:44] <mbiebl> groups == roles
[19:45] <pitti> mbiebl: (https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.html FYU)
[19:45] <pitti> FYI
[19:45] <pitti> gosh, time to stop typing for today
[19:47] <pitti> mbiebl: I just went through sid's default groups, and plugdev and cdrom seem closest to me
[19:47] <pitti> I'm just a bit averse against adding even more
[19:48] <pitti> powerdev/netdev/plugdev are all related in some way
[19:48] <pitti> but they are all too specific
[19:50] <mbiebl> pitti: I think this is something we can discuss in a few days :-)
[19:51] <pitti> mbiebl: heh, over a dinner with Debian guys perhaps :)
[19:51] <pitti> mbiebl: it was an easy fix for Ubuntu (just committed), but I guess it'll annoy Debian users, too
[19:51] <mbiebl> yeha
[19:54] <mbiebl> I just think you might be overloading the semantics of the "admin" groups i.e. it could be useful to have more fine grained groups
[19:54] <mbiebl> but maybe not
[19:55] <pitti> it's a very coarse-grained design, yes
[19:55] <pitti> mbiebl: oh, having these groups might be useful indeed; the problem is just that each time you introduce a new one, you have to migrate existing users
[19:56] <pitti> I guess no matter how you design it, some people will not like it :/
[19:57] <mbiebl> it would be cool if you could say that being part of group admin automatically implies membership of a set of groups (roles)
[19:58] <mbiebl> which would also allow to grant permissions on a per user / group basis
[19:58] <mbiebl> in a more fine-grained manner
[19:58] <pitti> mmmm nested groups
[19:59] <pitti> . o O { isn't that actually possible with some ldap/AD systems? }
[19:59] <mbiebl> maybe, dunno
[19:59] <pitti> mbiebl: however, with PK this would actually work
[20:00] <pitti> mbiebl: e. g. DK-D would give the *-internal bits to groups "admin" and "diskadm"; network-manager would give them to "admin" and "netdev", and so on
[20:00] <mathiaz> jcastro: hi
[20:00] <mathiaz> jcastro: does luke have a LP account?
[20:00] <pitti> mbiebl: then you can locally decide to put users just into diskdev, or make them full admins (including sudo, etc.)
[20:00] <pitti> mathiaz: TheMuso you mean? "themuso"
[20:01] <mathiaz> pitti: oh - no. Sorry - I meant luke kanies
[20:01] <mbiebl> pitti: we could split it up like that
[20:01] <mathiaz> jcastro: ^^
[20:08] <bibinou> cody-somerville: ?
[20:08] <bibinou> I need help with one bug you reported
[20:08] <bibinou> https://bugs.launchpad.net/ubuntu/+bug/409640
[20:09] <cody-somerville> okay
[20:09] <bibinou> in the description, you said you modified something
[20:09] <bibinou> where did you find this information ?
[20:11] <bibinou> i'm trying to gather some info about this bug because it is very similar to another bug I misinterpreted as a duplicate of this one
[20:11] <cody-somerville> one sec, on the phone
[20:11] <bibinou> no problem
[20:12] <amgarchIn9> so people, everything breaks. "Nov 10 21:03:18 novo init: kdm respawning too fast, stopped" even after I dpkg-reconigured gdm and choose gdm. I also removed the link /etc/init.d/kdm. Why is kdm being started at all?
[20:12] <amgarchIn9> I am afraid it is buried somewhre in Upstart configs, but I am not really famiiar with that.
[20:12] <amgarchIn9> when both gdm and kdm are competing for display ubuntu ends up in a propmpt to reconfigure graphics. "Low graphics mode" prompt if you ever seen that.
[20:21] <kirkland> pitti: would you mind processing a tiny incremental fix to the eucalyptus package in karmic-proposed?
[20:22] <kirkland> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/458904
[20:22] <pitti> kirkland: no problem; can you please build it with -v to include the previous -proposed changelogs into the source.changes?
[20:22] <kirkland> pitti: whoops
[20:23] <kirkland> pitti: should i do a .3 with that?
[20:23] <kirkland> pitti: i added the debdiff to the bug pointed to above^
[20:23] <kirkland> pitti: oh, actually.... this was a question i had
[20:23] <pitti> kirkland: ah, you already uploaded? nothing in the queue yet
[20:23] <kirkland> pitti: yeah, so let me ask this question ...
[20:23] <kirkland> pitti: i was uploading a .2 version over the top of a .1 in -proposed
[20:24] <pitti> kirkland: http://launchpadlibrarian.net/35497155/out -> this rewrites changelog history, please don't
[20:24] <kirkland> pitti: i just edited the current changelog entry, with the existing SRU changes in there
[20:24] <pitti> add a new changelog entry
[20:24] <kirkland> pitti: ah, okay, that answers it
[20:24] <pitti> kirkland: .2 wasn't accepted, so if you upload again, reuse .2 please
[20:24] <kirkland> pitti: okay, let me redo that then
[20:25] <pitti> kirkland: http://launchpadlibrarian.net/35497155/out -> what difference does it make?
[20:25] <pitti> kirkland: the only difference that I see is that the file would end up being executable (missing -m 644)
[20:25] <kirkland> pitti: it wasn't ending up in the .deb before; it is now
[20:26] <pitti> ah, so the rule was never executed?
[20:26] <kirkland> pitti: empirically, yes, that's what it looked like to me
[20:26] <kirkland> pitti: i did not investigate why
[20:26] <pitti> kirkland: so, I don't mind the "changed history" too much
[20:27] <kirkland> pitti: i'll do whatever you require
[20:27] <pitti> kirkland: the point about -v is to include previous changelogs and bug references, but with that this actually happens as well
[20:27] <pitti> it's just unusual to rewrite history
[20:27] <kirkland> pitti: gotcha
[20:27] <pitti> but nevermind, processing
[20:27] <kirkland> pitti: oh?  okay?  so you're accepting after all?
[20:28] <kirkland> pitti: i was fixing the changelog, etc.
[20:28] <pitti> jsut happens that the two problems (no new changelog, and missing -v)  cancel each other out :)
[20:28] <kirkland> pitti: so in the future, you want a new changelog entry for each upload going through proposed; that makes sense
[20:28] <kirkland> pitti: :-)
[20:28] <kirkland> pitti: well, my heart was in the right place -- to ensure that you saw *all* of the changes in the SRU
[20:28] <pitti> right, and upload with -v if the previous one didn't go to -updates yet
[20:29] <kirkland> pitti: i see that -v + a new changelog is a better way to do it
[20:31] <kirkland> pitti: okay, cheers, thanks man
[20:31] <pitti> thanks to you
[20:36] <cody-somerville> bibinou, okay, whats your question?
[20:37] <bibinou> cody-somerville:
[20:37] <bibinou> I was wondering
[20:37] <bibinou> as you provide very specific commands in the description of your bug
[20:38] <bibinou> where did you find that info and if you have more info about the problem
[20:38] <bibinou> and more to the point, is it a dupe of https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/395476
[20:39] <cody-somerville> no, its not a dupe of 395476
[20:39] <cody-somerville> I get the solution from http://www.wiredrevolution.com/ubuntu/fix-blue-tinted-video-in-ubuntu
[20:39] <bibinou> ok, the second problem is that some people confused the two bugs like me in the comments
[20:39] <cody-somerville> * git
[20:40] <bibinou> either in the comments of 395476 that those of 409640
[20:40] <bibinou> thanks for your link
[20:55] <cowgarden> will there be a global equalizer one day? I'd love it
[21:19] <cody-somerville> seb128, I have a patch I'd like to SRU to karmic for gst-plugins-base0.10 but I can't do the initial fix in lucid because lucid's gst-plugins-base0.10 is dep-wait. I see you did that requested that sync. Are you working still on the getting the build deps into lucid?
[21:23] <seb128> cody-somerville, what change do you want to sru exactly?
[21:23] <seb128> cody-somerville, I will sort lucid build issues later, you don't need to fix it in lucid to do a sru though
[21:25] <cody-somerville> seb128, Generally its preferred to fix it in the development series before doing an SRU but since I'm just applying a patch from upstream GIT I suppose I'm not too worried about it getting forgotten for lucid.
[21:25] <cody-somerville> seb128, http://cgit.freedesktop.org/gstreamer/gst-plugins-base/patch/?id=acaeed6131539facc523862e0f418f8602c6b095
[21:25] <seb128> right, no need to bother for this change
[21:25] <seb128> you can sru it before having the change in lucid
[21:25] <cody-somerville> kk
[21:52] <cody-somerville> seb128, its refusing to build the alsa plugin. Any hints?
[21:53] <seb128> cody-somerville, what arch do you use?
[21:53] <cody-somerville> seb128, amd64
[21:53] <seb128> and what error do you get?
[21:54] <cody-somerville> dh_install -pgstreamer0.10-alsa
[21:54] <cody-somerville> cp: cannot stat `./debian/tmp/usr/lib/gstreamer-0.10/libgstalsa.so': No such file or directory
[21:54] <cody-somerville> Looking up in the build log, configure lists alsa as not going to be built
[21:54] <cody-somerville> from debian/rules:
[21:54] <cody-somerville>  ifeq ($(DEB_HOST_ARCH_OS),linux)
[21:54] <cody-somerville> PLUGINS += alsa
[21:54] <cody-somerville> endif
[21:55] <cody-somerville> I'm guessing that conditional branch isn't being executed.
[21:56] <seb128> is type-handling installed?
[21:56] <cody-somerville> ah
[21:56] <cody-somerville> no it is not
[22:28] <seb128> jdstrand, hey
[22:28] <seb128> jdstrand, I've a pending evince sru for fixing printing issues should I wait for the bzip changes?
[22:29] <seb128> jdstrand, or do you want to look at that in a next upload?
[22:29] <jdstrand> seb128: I just assume fix it
[22:29] <jdstrand> seb128: when are you planning to upload?
[22:29] <seb128> jdstrand, I've the change on disk, no hurry though I can wait until later or tomorrow to batch the bzip change too
[22:30] <jdstrand> seb128: is a bzr commit and a ping to you good enough?
[22:30] <seb128> jdstrand, can you send me a debdiff rather? or add it to the bug?
[22:31] <jdstrand> seb128: sure
[22:31] <seb128> the bzr has the lucid version now
[22:31] <jdstrand> seb128: give me a half hour to get it going and test it
[22:31] <seb128> thanks
[22:56] <jdstrand> seb128: ok, debdiff attached to the bug. tested and updated qa-regression-testing for this
[22:56] <jdstrand> seb128: I'll add the SRU text to the bug
[22:57] <seb128> jdstrand, thanks
[23:00] <jdstrand> seb128: oh, and committed to bzr
[23:00] <jdstrand> seb128: I can upload to lucid if you'd like
[23:02] <seb128> jdstrand, would be nice thanks
[23:02] <jdstrand> sure, np