[00:01] james_w: hmm, I'm running into a few package merges where the debian/squeeze branch isn't up-to-date [00:01] james_w: is there a way for us to trigger those, or do you want a list, or? [00:01] slangasek: there's no way for you to trigger unfortunately [00:02] slangasek: a list to me will work, but with added latency [00:02] slangasek: is the https://launchpad.net/debian/+source/ up to date for these packages? [00:03] 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] checking (bsd-mailx for the current example) [00:03] yes, that page lists the correct "latest release" [00:03] slangasek: ok, thanks for checking [00:03] I'm happy for you to mention them to me [00:03] ok [00:03] investigating may help find bugs, and so reduce the frequency === dendrobates is now known as dendro-afk [00:11] jdstrand: it should be [00:12] jjohansen: I'll mark it as such-- thanks :) === dendro-afk is now known as dendrobates [01:31] jdstrand: your audio bug should be fixed in 2.6.32-git [01:32] 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] 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] dtchen: thanks === ubott2 is now known as ubottu [02:03] dtchen: ok-- I'll keep an eye out, thanks! [02:04] though, it'll be after UDS before I can test it === davidm_ is now known as davidm === greeneggsnospam is now known as jsgotangco === ]reed[ is now known as [reed] === elmo_ is now known as elmo [03:51] 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] dtchen: this undermines any efforts to determine the actual cause of the problem the user is having [03:54] slangasek: all right, is there a separate bug I should be triaging against? [03:54] slangasek: also, sorry for the added workload [03:55] 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] 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] 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] dtchen: just reassign them to the grub package, then [03:56] slangasek: sure thing, thanks [03:57] thank you === YDdraigGoch is now known as Richie === robbiew is now known as robbiew_ [05:56] Hey all [05:57] Hi all [05:57] Does anyone know who is dealing with input methods at the moment? [06:28] JohnFlux: ArneGoetje [06:31] james_w: lp:debian/squeeze/cmake also out of date, it appears [06:45] um...question === funkyHat_ is now known as funkyHat [06:50] 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] PRIDE: No. That's #ubuntu. [06:50] This is the channel for coordinating development work. [06:51] 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] PRIDE: Filing a bug on Launchpad is the best way to approach that. [06:52] how would i do that? [06:52] That question they will know how to answer on #ubuntu. [06:52] ScottK, thx [08:04] good morning [08:04] <\sh> moins === porthose_ is now known as porthose === dholbach_ is now known as dholbach [08:13] hey dholbach [08:14] hi mvo [08:24] morning mvo and dholbach! [08:24] the vegetarian brigade? [08:24] yeeeehaww! [08:25] hi glatzor__: long time no see - how are you doing? [08:26] hey glatzor__! nice to see you [08:26] wow [08:27] hey jsgotangco! [08:27] hi dholbach, mvo, glatzor__ [08:27] hey jsgotangco [08:30] hey jsgotangco ! [08:30] dholbach, quite well. I hope yourself, too! [08:30] * dholbach hugs glatzor__ [08:30] glatzor__: I got my dose of ubuful before flying to UDS :) [08:31] 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] \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] dholbach: are you vegetarian already? [08:41] jsgotangco: yeah, for more than a year now :) [08:41] jsgotangco: it's what India did to me :) [08:41] someone suggested an "ubuntu vegetarians" team on lp so that we could easily coordinate group-meals during UDSs [08:41] dholbach: i'm almost there too [08:41] maybe glatzor__ or mvo? [08:42] dholbach: haven't had read meat for more than a year [08:42] mvo already owns https://launchpad.net/~canonical-vegetarians :) [08:42] look at these happy people: https://launchpad.net/~canonical-vegetarians/+mugshots [08:43] heh nice [08:44] we found a vegan restaurant in barcelona [08:44] 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] good morning everyone [08:54] maco: ubuntu-vegetrians sounds good to me, that is a bit broader than just the canonical group [10:30] 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] ogra: merge-package doesn't work for native packages [10:34] aaah ! [10:34] ok, the wikipage should probably state that :) [10:35] it's a bug (bug report is open) [10:35] ah [10:35] feel free to document on the wiki, too === dendrobates is now known as dendro-afk [12:03] asac: how come network-manager-[vpnc|openvpn|pptp] are in universe? [12:17] Riddell: gdb pong [12:19] 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] Riddell: no [12:20] Riddell: is there an upstream report? [12:21] doko_: http://lists.trolltech.com/pipermail/qt-creator/2009-November/004963.html [12:30] doko_: so I'm getting calls to put 6.8 into backports, does that make sense? [12:31] Riddell: as a separate package? [12:31] yes [12:33] 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] doko_: remaining java bits for ant moved to -updates now; thanks for confirming the debhelper issue [12:36] pitti: \o/ [12:41] Riddell: and it would be good to have reports in launchpad to track those [13:05] 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] Riddell: plan is to make at least pptp installed by default in lucid [13:05] 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] asac: is that right? [13:06] Riddell: there is a bug yes. but we verified that the vpn plugins work at least a bit [13:07] "a bit" :) [13:07] so its not a general issue ... most likely related to system-settings/user-settings related secrets [13:08] i will ask cyphermox to verify them again ... and fix accordingly. === ogra_ is now known as ogra [13:13] 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] 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] 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] siretart`: you think you could provide me an account so i can test that on the setup where you see that? [13:31] https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-vpn-out-of-box-experience [13:31] JanC: ^^ [13:32] asac: nice [13:47] asac: hm. that's gonna get difficult. I could paste/attach my logs to some bug if that would help [13:48] siretart`: ok. filing a bug against -openvpn would be a good start i guess [13:48] thx [13:56] 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] mvo: flex merge> hppa is no more, so this could have been a sync [14:06] pitti: oh, sorry [14:07] JFYI for next time :) [14:07] indeed [14:08] thanks === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [14:14] 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] Keybuk: I checked around, but didn't see anything that quite fit (I could have easily missed it) [14:15] jdstrand: I don't think it's worth a session [14:15] anything I say now will be out of date by the time lucid releases [14:15] heh [14:15] ok [14:15] and it'd be just a rehash of the session I did in Barcelona anyway ;) [14:16] unfortunately I missed that one [14:16] Keybuk: the part I most care about atm is the part that is likely one of the most moviing targets [14:16] Keybuk: ie, being quiet, but displaying erros appropriately [14:16] errors [14:17] exactly, that's all subject to change [14:17] * jdstrand nods === highvolt1ge is now known as highvoltage [14:25] wow, bug 429322 has 2030 subscribers [14:25] Launchpad bug 429322 in seahorse-plugins "seahorse-agent assert failure: ERROR:iop-profiles.c:606:IOP_generate_profiles: assertion failed: (obj && (obj->profile_list == NULL) && obj->orb)" [High,Confirmed] https://launchpad.net/bugs/429322 [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] \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] Riddell: did you already add the firefox/kde spec [14:32] \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] \sh: if you have just internal uris in sources.list it should DTRT [14:32] \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] asac: no I'm stuck on something silly that's taking too long, but it's next on my todo list === robbiew_ is now known as robbiew [14:49] Riddell: created this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-firefox-kde-integration ... [14:49] if you have references to current opensuse patches etc. please put them there too [14:50] ok [14:51] asac: lovely (: [14:52] 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] Keybuk: What was the magic trick to make upstart wait until lo was configured before entering runlevel 2? [14:53] soren: ... and net-device-up lo ? [14:53] Keybuk: WherE? [14:53] in /etc/init/rc.conf [14:53] though that will break being able to switch runlevel [14:53] (ie. you won't even be able to shutdown or reboot) [14:54] So... What to do? [14:54] nothing [14:54] I believe you mentioned you'd SRU a fix for this. [14:54] no I didn't [14:55] 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 [14:55] Keybuk: http://irclogs.ubuntu.com/2009/10/27/%23ubuntu-devel.txt at 15:26? [14:56] Maybe I misunderstood. [14:56] but, frankly, I think it's a waste of time dealing with these problems [14:56] mai ænglish nud so guud. [14:56] races between Upstart jobs and SysV init jobs, that is [14:56] 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] soren: oh, so I did, but I can think of major breakages that will cause now, so I don't :p [14:59] Tm_T: try reading yesterday's news in slashdot [14:59] dholbach: are you around? [15:00] 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] Keybuk: Å [15:00] Er... [15:00] Keybuk: ^ [15:00] typing is hard today.. [15:00] if you like [15:01] give them a lollipop too ;) [15:01] err [15:01] what networking job? [15:01] /etc/init/networking.conf ? [15:01] that's an Upstart job [15:01] i know [15:01] Riddell: roger (: [15:01] soren: I was actually thinking a bit about this the other day [15:02] we use network manager to bring up network devices [15:02] Keybuk: Where else would I add it? [15:02] so the whole ifup-on-network-device-added thing could go away [15:02] You're not going to install networkmanager on people's servers. [15:02] Are you? [15:02] why not? :p [15:02] Because you are not in #ubuntu-server explaining this to people. [15:03] I am. [15:03] I bet they hate D-Bus too [15:03] Are you adding bridging and bonding support to network-manager? [15:03] no [15:03] that sounds like a server team project [15:03] Or are you just going to declare those completely unsupported? [15:04] Keybuk: You're just here to cause trouble, aren't you? :-P [15:06] * soren gives up [15:09] 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] hardware triggered actions sound fine for this? [15:10] description "configure virtual network devices" [15:10] oh [15:10] 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] (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 === marjomercado is now known as marjo [15:12] \sh: how did that ever worked in earlier releases then? it was just a static init script as well, after all? [15:12] 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] \sh: well, that's pretty much what we have now, too [15:13] 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] \sh: now, ifup -a is started as soon as local file systems are mounted and udev coldplugging is done [15:15] 0 boogs? oooo, shiny! [15:15] (see /etc/init/networking.conf) [15:15] maco: 0 new bugs [15:15] still shiny! [15:15] plenty of incomplete/triaged, too [15:15] 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] 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] pitti: The networking job (which calls "ifup -a") is run much, much earlier in karmic than before. [15:18] So early, in fact, that the physical nic's often are not available yet. [15:18] soren: ah, what I suspected; so it was by and large "luck" [15:18] In a sense. [15:18] which made me wonder whether we should have an additional udev rule to catch late stragglers [15:18] It's always been racy, but I don't know of anyone who was ever bitten by this before. [15:19] In Karmic, I haven't heard of anyone for whom it works. [15:19] pitti: The solution is to configure the virtual interfaces when the corresponding physical ones are available. [15:19] is it really the nics which arrive so late? shouldn't udevsettle wait for them? [15:20] pitti: I thought so too, but no. [15:20] soren: exactly [15:20] soren: and that's what udev rules are for, like ACTION=="add", SUBSYSTEM=="net", ... [15:20] pitti: Right. [15:20] with ... being something that calls a script on the $INTERFACE variable which checks if that is in /e/n/i [15:20] pitti: Problem is that /etc/network/interfaces is the other way around. [15:21] pitti: It defines the bond0 interface, which then specifies that it "contains" eth0 and eth1, for instance. [15:21] Rather than: [15:21] iface eth0 [15:21] part-of bond0 [15:21] or whatever. [15:21] Otherwise, it'd be easy. [15:22] 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] Keybuk: What if we simply called "ifup -a" from network-interface.conf ? [15:23] soren, \sh: a very brutal and hopelessly inefficient rule would just be [15:24] Ah, no, that'd be bad. [15:24] ACTION=="add", SUBSYSTEM=="net", RUN+="/sbin/ifup -a" [15:24] pitti: No, that will be bad. [15:24] soren: .. assuming that the ones where half of the componetns are still missign will just gracefully fail, of course [15:24] pitti: If you ifdown an interface and then another one turns up, they'll both be ifup'ed. [15:25] soren: right, which is why I only propose this for a first test :) [15:25] it doesn't handle manual ifdowns at all [15:25] It will work around the problems on servers, but is not a proper fix. [15:26] 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] You can't know when it's caught all the hw interfaces. [15:26] \sh: that's what I suspected it'd already do [15:26] after an udevadm trigger/udevadm settle I had expected everything to be "there" [15:26] 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] You can never know if another interface is going to turn up. [15:27] which made me wonder whether it's really the NICs which are missing, or whether some other modules are only loaded later [15:27] 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] Keybuk: Can you confirm that "udevadm trigger;udevadm settle" does not guarantee that all your NIC's have been handled by udev? [15:29] Keybuk: Or the opposite of "confirm", whatever that is. [15:30] soren: I actually wondered about that as well; how do you say for "confirm that it is false"? [15:31] 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] Keybuk: How serious are you about network manager on servers? [15:35] heh, who would want that? [15:36] highvoltage: Noone, except Keybuk, I imagine. [15:36] 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] soren: ok :) [15:41] soren: sorry, I've been on a call for the past hour [15:41] soren: just reading scrollback [15:42] pitti: actually udev rules must *NOT* be used for this [15:42] pitti: udev rules are subject to timeouts, security issues, etc. [15:42] pitti: ACTION=="add", SUBSYSTEM="net",... in udev => "on net-device-added" in upstart [15:43] pitti: it's run at the same time, except in a sane environment, with very well understood blocking semantics, etc. [15:43] oh, interesting; and that's safer than a straight udev rule? [15:43] pitti: (and you can multiplex them :p) [15:43] good to know [15:43] 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] pitti: much safer [15:44] anything in a udev RUN rule should really be considered "part of udev" [15:45] 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] (udev-config-printer I'm looking at you - you will die) [15:45] 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] exactly [15:46] Keybuk: so ifup'ing doesn't count as "immediate processing'? [15:46] now, the bonded interface problem [15:46] pitti: no, because it can run things like wpa supplicant, dhclient, etc. [15:46] ah, right [15:46] there are lots of bugs when we used to run ifup from udev where udev got bored and killed it ;) [15:47] thus /etc/init/network-interface.conf [15:47] which is the same udev rule, expressed as an upstart job [15:47] so, NOW, the bonded interface problem [15:47] ifup eth0 [15:47] ifup eth1 [15:47] that's all easy, because we have a physical device [15:48] bond0 (eth0 eth1) is hard [15:48] what you want is something that notes down each network device as it comes up [15:48] configures them if necessary [15:48] and also knows about bonded devices, bridges, tunnels, and all manner of other virtual devices [15:48] and knows what their dependencies ar [15:48] so when it has both eth0 and eth1, it configures the bridge or the bond [15:49] shouldn't /e/n/i already have all this information? [15:49] it probably does in the wrong order [15:49] 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] we have one of those ;) [15:50] we could teach it about bonded interfaces, bridges, and stuff [15:50] and then we would have win [15:50] (NM stopped reading /e/n/i long ago, I think) [15:50] 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] really? the Fedora one still does basically this for its sysconfig stuff [15:51] well, you probably wouldn't need a daemon, it could be done in the upstart job? [15:51] ah [15:51] now [15:51] asac: ^ [15:51] that's a different thing [15:51] we could do this a different way [15:51] we could parse /e/n/i and generate upstart jobs from it [15:51] since upstart jobs can do the "when eth0 and eth1 are ready" thing [15:51] Aren't the lp:ubuntu/source-pacakage branches now pointing to Lucid? [15:51] 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] ah, clever [15:51] so you could have an auto-generated job that was basically [15:51] on net-device-up eth0 and net-device-up eth1 [15:52] Ah, i should have read Keybuk’s last few lines. :-P [15:52] exec ifup bond0 [15:52] qense: there is no branch at all for this package apparently (lp:ubuntu//mousepad) [15:52] this is, in principle, what we're planning to eventually do for fstab [15:52] we had a bunch of crappy shell scripts that did everything badly [15:52] we replaced it with a daemon that intermediates between udev and upstart [15:53] and encodes all of the corner cases [15:53] 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] mr_pouit: no there isn't, apparantly it's code is not hosted on Launchpad yet [15:53] Keybuk: "a daemon" == mountall? [15:53] ie. mountall would become a "upstart-fstab-helper" that resulted in mount/sda1 mount/sda2 type jobs being automatically created [15:53] pitti: exactly [15:54] so for networking, we have basically the same issue [15:54] ifup doesn't really lend itself to event-driven construction [15:54] but we don't have the intermediate daemon either, or the final solution [15:54] mr_pouit: you could try "apt-get source mousepad", but you'd have to have the right source repository enabled [15:55] qense: I know. I thought that all packages had already been imported, that's why I'm wondering. [15:56] ah [15:57] so given that, it's not unreasonable to have an upstart-eni-helper as well [15:57] 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] qense: udev doesn't care about fstab at all === yofel_ is now known as yofel [15:59] You could just as well remove the entry? [16:02] oh, udev 147 [16:02] qense: https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-dynamic-cdrom-handling [16:02] Keybuk: FYI, we have a new CK ready for udev 147 [16:02] pitti: yeah [16:02] pitti: it's ready? [16:03] evand, Keybuk: thanks [16:03] Keybuk: yep; I already committed all our remaining changes to Debian git, so we'd only need to sync [16:04] Keybuk: new CK has Breaks: udev (<< 147~) [16:04] shouldn't that be << 147 ? [16:04] since 147~ is in karmic [16:04] Keybuk: right, we need to bump that [16:05] I'll just bump it in Debian git and upload a snapshot [16:05] http://launchpadlibrarian.net/35479479/amilo-karmic-20091110-3.png [16:05] ^ I wonder whether he's using wubi [16:06] pitti: I think I'll get to udev tomorrow [16:06] Keybuk: I'll upload a new CK to ubuntu-desktop PPA [16:07] ok [16:08] (I have two hours left of the day, and have some bug triage to do first :p) [16:09] wubi would be my guess as well [16:11] 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] cjwatson: thanks, that's interesting. we don't really use it though since packagekit doesn't do debconf much currently [16:14] Riddell: yeah, I have mail about that to process at some point too :) [16:14] 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] yes [16:42] it's *used* in karmic [16:42] 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] sometimes doesn't work? [16:44] or flat-out doesn't work? [16:44] do you have iface eth0 and iface eth1 in your /e/n/i ? [16:45] mvo, hey there [16:45] <\sh> Keybuk, no...that's the point using bonding ;) [16:45] if not, you want s/-up/-added/ :p [16:45] <\sh> ah... [16:45] ie. when the network device exists, not when it's been broght up [16:45] <\sh> yes..ok..understood ;) === BenC1 is now known as BenC [16:48] <\sh> Keybuk, can someone create the "start on ..." statement in pre-start script automagically? [16:50] \sh: not currently [16:50] 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] hey mac [16:53] hey MacSlow [16:53] please be more verbose [16:53] 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] \sh: so there must be something else it needs [16:54] 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] 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] \sh: buggered if I know [16:57] 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] \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] \sh: I will not get anywhere close to straight on that before lucid [17:01] if it's important, I will need help [17:02] ooooooh ureadahead? [17:02] *must play* [17:03] <\sh> Keybuk, how can I enable upstart --debug? and where to look after? [17:03] \sh: initctl log-priority info [17:03] (you don't want debug) [17:04] <\sh> Keybuk, is this static then, or is this gone after reboot [17:04] \sh: gone after reboot [17:04] 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] just --verbose === amitk is now known as amitk-afk [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] so you need something else too ,g> [17:15] 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 === robbiew is now known as robbiew_ === dendro-afk is now known as dendrobates === thekorn is now known as RainCT007 === einalex is now known as the === the is now known as thek === thek is now known as thekorness === thekorness is now known as thekorn [17:44] ping [17:46] whos's the korn now?! === thekorn is now known as thekorn_not === RainCT007 is now known as sugar_honey === thekorn_not is now known as einalex === sugar_honey is now known as recover === JayFo is now known as JFo === asac__ is now known as asac [18:15] cjwatson: slangasek: approximately when do lucid livecd ISOs start showing up? [18:18] "at some point" [18:18] I think slangasek was planning to do it this week [18:19]