=== dendro-afk is now known as dendrobates [04:32] hi, here is my package http://revu.ubuntuwire.com/p/iok , i couldn't understand the last comment, can anyone explain to me? [04:52] suji11: #uubntu-motu would be more appropriate for packaging help. [04:53] arand: ok [05:17] does anyone know when the Debian import freeze for Lucid is? [05:17] pabs3: Thursday [05:18] thanks [07:13] slangasek: bah, still hangs with .33rc7. the session works for a while (terminal, access to home), but launching nautilus breaks it for good === ttx_ is now known as ttx === tkamppeter_ is now known as tkamppeter [08:46] www.search2.net [09:16] Good morning [09:26] ev: confirmed; automation doesn't work with 20100210 either [09:26] (or 20090209.1) [09:26] Keybuk: indeed, already looking into it. Appears to be a casper bug, but I'm still digging. [09:49] bah, my desktop machine hung itself for the second time today and there's nothing in syslog [09:50] and gdm doesn't show up properly either [09:50] dholbach, do you have plytmouth installed there? [09:50] "hung itself" ? [09:51] Keybuk: like the mouse pointer does not move any more, I can't ssh in, music stutters like a broken record, etc :) [09:51] seb128: yes [09:52] dholbach, try uninstalling it [09:52] my box stop freezing since I removed it [09:52] seb128: will let you know in a bit [09:52] seb128: the plymouth/gdm freeze seems fixed /here though. Just did a normal boot. (I used a workaround the past week) [09:52] sebner, not there, I just did some testing for slangasek [09:52] I got it 3 times in a row today [09:52] until I uninstalled plymouth again [09:52] sebner: it works on my laptop (i386, intel graphics) too, just not on my desktop (amd64, nv) [09:53] it's racy [09:53] Keybuk: but at least magic sysrq still worked [09:53] so it will not happen every time [09:53] seb128: yay - problem "fixed"! ;) [09:54] seb128: dholbach : Well, as I said, I was seeing it too the whole past week (with nvidia) but tried a normal boot today and it worked. Maybe it was just luck [09:54] I hope that'll fix the kernel/whatever hang too :-) [09:54] dholbach, ;-) [09:55] I blame it on Keybuk for forcing plymouth on everybody and running away ;-) [09:55] dholbach: the funny thing is that on my box I'm seeing "self-healing" pretty often xD [09:56] not heard of that one being plymouth related [09:56] if X is up, plymouth shouldn't be running [09:57] another excellent one is if you shut the laptop lid during boot, and then reopen it to try and log in... [09:57] Keybuk: I'm sure the hang is unrelated to plymouth :) [09:59] Keybuk, launchpad bug #516412 [09:59] Launchpad bug 516412 in plymouth "Pressing causes X to freeze" [High,Confirmed] https://launchpad.net/bugs/516412 [09:59] only if your boot is very very fast and you never see plymouth [09:59] Keybuk, it's still the same vt1 conflict issue I think [10:00] like I said, only if your boot is very fast ;) [10:00] otherwise X will be on vt7 [10:00] my boot is not very fast [10:00] it's my d630 [10:00] it takes some 45 seconds to boot [10:00] do you see the ubuntu logo? [10:01] i get X running on vt7 too, and i still see it crash when hitting enter [10:01] chrisccoulson: then that's unrelated to plymouth afaik [10:01] Keybuk - when i have plymouth installed, I noticed that all my keyboard input gets routed to the VT that X is running on [10:01] Keybuk, I see "Starting up..." for 15 seconds, "_" in text for 3 seconds, plymouth for 3 seconds, empty screen with xorg cursor for 3 seconds [10:01] then session [10:01] if i stop X, everything I've ever typed is on the underlying VT [10:01] then box crash when I hit enter [10:02] seb128: I can't see how that's caused by plymouth [10:02] sounds more like an X bug [10:02] I doesn't happen without plymouth [10:02] so it's an interaction between both [10:02] slangasek says that plymouth is not supposed to exit that early [10:02] but plymouth has already exited by the time X starts, right? [10:03] ie I should still have plymouth on the spinning cursor time [10:03] boohoooo, the machine hung again :-((((( [10:03] * dholbach is very unhappy [10:03] oh, does plymouth segfault for you? [10:03] not that I know, at least it doesn't trigger apport [10:03] but it's only displayed for some 3 seconds [10:03] do you have a segfault message in kernel dmesg? [10:03] ie it goes away before having xorg displayed [10:04] yeah, sounds like plymouth crashed [10:05] no crash mention in the logs [10:06] it's a shame that the only 2 people not getting that issue are slangasek and you ;-) [10:07] in any case I can get debug informations if you need some [10:07] it happens pretty consistently there [10:08] I'll take a look after FF [10:09] ok thanks [10:23] mvo: had some time yet ? ;) [10:24] dupondje: still on my list, but todo should be fine [10:26] is anyone else getting emailed about build failures in the kubuntu-ppa-staging PPA? [10:28] mdz: oh yes. It's going to the ubuntu-reviews list, for some strange reason. [10:29] Riddell: ^^ [10:31] I think it's also going to all members of some group, to which kubuntu-devel belongs, and hitting ubuntu-core-dev as a result. === ogra_ is now known as ogra [10:40] * Keybuk wonders why he's now getting kubuntu build failure logs in his inbox [10:40] we thought you haven't had enough mails yet [10:40] * Tm_T hides [10:41] tm_T: I'll forward you the 2,000 odd mails in my LP folder shall I? :p [10:42] Keybuk: sure, I already have several thousand unread mails here [10:47] Which package determines that Ctrl+Alt+F1 means VT switch when in X? I'm trying to determine what changed on my lucid system such that it now VT-switches with plain Alt+Fx even when in X [10:49] maxb: linux-image-generic... [10:49] actually I think the Ctrl-Alt thing may be xorg-server ;) [10:50] Was about to say... didn't think I'd updated the kernel in the last few days [10:51] it's not an update or change [10:52] it's a bug [10:52] I suspect this to be the same bug that causes people's X servers to crash when they press Enter [10:54] crash as in display freezes on the last displayed image? I've seen that too [10:54] *blink* and the password I typed into gdm was displayed after the Login: prompt from a text getty after I quit X [10:59] yeah [10:59] you have the same bug then [11:01] maxb, uninstall plymouth... [11:02] * maxb does that [11:20] I need help: When there are updates available, update-manager gets somehow started automatically, probably via D-Bus. I want to do so with the firmware installation tool of HPLIP. Someone knows how this works? [11:20] Can I use libnotify for that? [11:21] it's done explicitly in update-notifier; grep that package and you should find it [11:23] cjwatson: Thanks [11:31] tkamppeter: jockey recently grew the ability to listen for "needs firmware" uevents, and launch if it found something (currently used for DVB-T sticks, which need firmware) [11:32] (the listening to those firmware events is also implemented in update-notifier) [11:35] pitti, I have the following situation: === jamesh_ is now known as jamesh [11:36] HPLIP recognizes with the UDEV rule /lib/udev/rules.d/56-hpmud_support.rules whether a printer needs a proprietary plug-in in order to work with HPLIP. [11:37] pitti, the udev rule simply runs "hp-mkuri -c" with the model name of the discovered printer in an env variable. [11:39] pitti, hp-mkuri checks whether the printer needs the plugin, and if yes, it simply generates a notification uing libnotify, telling the user to run the appropriate utility (which is part of HPLIP, "hp-plugin"). [11:39] pitti, I want that hp-mkuri starts the utility directly in that case. [11:40] pitti, and that with a not too big patch on hp-mkuri, so that I can contribute the patch upstream to HPLIP. [11:40] tkamppeter: how does it currently connect to libnotify? udev rules run as root, and are not attached to a particular user (session)? [11:41] tkamppeter: ah, so it's not "firmware" in the linux sense? (/lib/firmware/) [11:42] tkamppeter: can you please put /lib/udev/rules.d/56-hpmud_support.rules in a pastebin? (sorry, I don't have it installed) [11:42] pitti, no, the firmware is not installed into /lib/firmware and the plugin can contain other things than firmware, like color profiles or binary-only driver add-ons. [11:43] tkamppeter: ok, so it's more like a general package [11:43] tkamppeter: that sounds like a case for jockey, except that it doesn't do hotplugging without further support (from update-notifier) [11:43] pitti, http://pastebin.ubuntu.com/373145/ [11:44] RUN+="bin/sh -c '/usr/bin/hp-mkuri -c &'" [11:44] ?? [11:44] why doesn't it just run hp-mkuri straight away? [11:45] pitti, here is the source of hp-mkuri: http://pastebin.ubuntu.com/373147/ [11:46] See especially the notify() function which generates desktop notification bubbles via libnotify. [11:46] tkamppeter: so, adding this match to update-notifier looks straightforward (the firmware bit already listens to gudev and has an event handler) [11:46] (and drop that rule) [11:47] pitti, I do not know why the UDEV rule launches the program through a subshell, when I run hp-mkuri manually it exits already while the notification bubble is still there. [11:47] tkamppeter: I meant, why does it need that sh -c & hackery? [11:48] tkamppeter: but anyway, if the rule goes away in favor of changing update-notifier, it won't matter anyway [11:48] pitti, perhaps due to its non-zero exit codes, but for that one could also do "hp-mkuri || :" [11:48] it shouldn't care [11:48] Do we do anything to reduce swappiness when swap is on an SSD? [11:49] soren, i doubt that, usually the controller should care with recent SSDs [11:49] ogra: What do you mean? [11:49] soren, on recent SSDs the controller does the wear out levelling [11:50] Ah. [11:50] so it shouldnt matter what your swappiness is set to with newer HW [11:50] mvo: do you know what's going on with the return of bug 507842? I'm seeing it here too [11:50] Launchpad bug 507842 in python-central "Does not honor XS-Python-Version if debian/control contains a empty line before the Source: line" [Medium,In progress] https://launchpad.net/bugs/507842 [11:50] pitti, I would like more to modify the notify() function in hp-mkuri as this is more streamlined with upstream. I do not need to add a dependency on update-notifier, so it is easier forgetting it accepted upstream. [11:51] soren, indeed there is that grey area of SSDs that dont do that ... i know cking did a lot of SSD work, he might be able to tell you what is on/off wrt SSD handling today [11:51] ogra: That heavily depends on the filesystem used and the filesystems supported by the FTL (although many common FTLs do support ext2/3 now) [11:51] persia, swap is swap :) [11:52] unless you use a swapfile on top of a filesystem indeed :) [11:52] persia: FTL? [11:52] ogra: Ah, right. I have no idea if any available FTLs treat swap well. I seem to remember a discussion regarding using swapfiles to work around that. [11:52] soren: Flash-Translation-Layer : is the embedded computer that sits between the disk interface and the flash. [11:52] tkamppeter: this uses some weird trick to talk to an user session; I don't even see how it is supposed to work in the first place; it doesn't even do setuid(), let alone dbus connections to any user's session [11:53] cjwatson: re 507842> I have a look [11:53] tkamppeter: the update-notifier support would be ubuntu only indeed; nothing for upstream [11:53] one solution with older SSDs was to have a swapfile and copy that around all the time ... i played with that, but thats horribly slow and wasteful [11:53] Another solution is to use raw flash and UBI, but that requires motherboard support (and separate flash) [11:53] well, or use a modern SSD :) [11:54] with a proper controller [11:54] its a matter of price [11:54] pitti, you mean libnotify uses this weird trick? notify() in hp-mkuri only calls functions/methods of libnotify. [11:54] * soren thinks his Intel X-25M is modern enough [11:54] yeah, definately [11:54] Wow. This thing boots fast! [11:54] soren, bootchart ? [11:54] soren: Check with Intel regarding swap support in the FTL. You may find you want a swapfile. [11:54] tkamppeter: yeah, and that's what I don't understand; I can't believe that this works at all [11:55] soren, i have a samsung, with the upgrade to lucid my system went from 45 to under 10sec [11:55] (But you don't have to copy the swapfile around with an FTL that supports the underlying filesystem) [11:55] ogra: Yeah, I'm way under 10 sec. [11:55] pitti, is libnotify shouting into the D-Bus and some user session daemon (notify-osd?) is listening and showing the bubbles? [11:55] soren, i'm talking desktop though :) [11:55] ogra: Me too. [11:55] wow [11:56] tkamppeter: it's not "the" d-bus; notifications are happening on the session bus, which is per-user [11:56] and an udev rule doesn't have their addresses [11:56] ogra: It feels way less than 10 sec, at least. /me is doing a bootchart now. [11:56] tkamppeter: did you test that this current rule actually works? [11:56] soren, temporary use autologin to get reliable measures [11:57] ogra: I'm using ecryptfs, so no can do. [11:57] ogra: Oh, i guess I could create a dummy user to test it. [11:57] mvo: ta [11:57] my fastest was 8sec so far ... but it went up a little with the latest plymouth changes [11:57] pitti, yes. I have the HP LaserJet 1020 which needs firmware. I have removed the plug-in and then power-cycled the printer and I got a notification bubble. [11:57] its constantly around 9.5 now [11:58] pitti, the bubble showed 30 sec. [11:58] magic [11:58] pitti, and the bubble is in notify-osd style (black transparent with white text). [11:59] pitti, the magic must be inside libnotify. [11:59] apparently so [12:00] pitti, it works both by power-cycling the printer (then hp-mkuri runs as root) and by calling hp-mkuri on the command line (then it runs as me). [12:00] lool: hi, do you have a moment to talk about the latest python-central changes? [12:00] tkamppeter: so, you can't use libnotify to launch a program in the user session, so if you want to do that, you need to patch update-notifier [12:01] pitti, I do not know enough about the capabilities of libnotify, perhaps it can. [12:02] tkamppeter: with notification-daemon you could attach an action, which could then launch a program [12:02] but notify-osd doesn't have actions [12:04] pitti, notification-daemon is not used in Ubuntu any more? [12:04] tkamppeter: not by default [12:06] pitti, and hplip has a working dbus server only if hplip-gui is installed which is also not done by default in Ubuntu. [12:07] tkamppeter: the session d-bus is launched by gnome, independent of hplip-gui [12:08] pitti, how can I make use of the session d-bus the simplest way to let the udev rule launch an interactive program? [12:08] oh, you mean it exports a service over dbus, nevermind [12:08] tkamppeter: you can't [12:08] tkamppeter: you need a program in the user session to listen to udev events (such as update-notifier) [12:08] which then can launch a program [12:09] pitti, how will it work by using update-notifier? [12:09] pitti, does it require a change in update-notifier? [12:09] tkamppeter: update-notifier already sets up a handler for udev events (currently for firmware); this needs to be extended to match on that printer [12:09] tkamppeter: yes, it does [12:12] pitti, is there some general d-bus listener in the user's desktop session which I can use without modifying it? [12:12] tkamppeter: no, mvo and I have always talked about this, but we never got to that [12:13] tkamppeter: update-notifier should be fine, the code is our's, and easy [12:13] * pitti needs to run out for some 30 mins [12:13] long-term, the idea would be that Upstart could be that general listener, even in the desktop session case [12:13] but that's YEARS off [12:14] pitti, OK, can you do the changes on update-notifier? [12:19] tkamppeter: what is required? I can probably do it too [12:21] mvo, the program hp-mkuri (written in C, http://pastebin.ubuntu.com/373147/) should send a message to somewhere telling that a certain command line should be executed in the user's session, to run a GUI application. [12:25] mvo, the command line to be called is not a straight command line but a shell script one-line, like "if python -c 'import PyQt4.QtGui' 2>/dev/null; then gksu -- hp-plugin -u; else gksu -- xterm -T 'HPLIP Plugin Installation' -sb -rightbar -e hp-plugin -i; fi" so that it works on all Ubuntu systems. [12:25] tkamppeter: but the command line is not send as wel, right? that will be encoded in the session and the singal just is there to know which one to pick ? [12:26] tkamppeter: so when a signal like "plugin_installation_required" then u-n should call the above command? [12:26] mvo, one could send the command line, but one could also send only a signal. The command line does not depend onm the printer model or on its connection type. [12:27] mvo, but I would like that the HPLIP Ubuntu package provides this command line, because the command line can change with changes in future HPLIP versions. [12:27] tkamppeter: sending a commandline like this is scary, I would prefer to have it encoded inside u-n [12:28] tkamppeter: so just the signal, if future version require a different one, then I'm happy to update update-notifier [12:28] mvo, we could put it into a file which is part of the hplip package, and the part of u-n which executes it, reads this file, [12:29] tkamppeter: thats ok [12:29] mvo - on the topic of u-n - do you think u-n should check it is on the active console before doing things like launching update-manager and showing the reboot dialog? [12:29] chrisccoulson: yes, good idea! [12:30] mvo - want me to provide a patch to do that? [12:30] (if i get the chance) [12:30] tkamppeter: I can make the required changes if you give me the signal name [12:30] chrisccoulson: YES :-) [12:30] cool, i'll try and look at that :) [12:30] right, lunch time. bbiab [12:30] mvo, can you tell me where I should put the file and how to name it? Do not make it a conffile (not in /etc/) as it is only package- and not user-/system-dependent and so conffile update complications should get avoided. [12:31] mvo, I do not have a signal name yet and also do no know how to send such type of signal. Can you tell me what I have to do? [12:32] tkamppeter: ok, lets take that off the channel into private conversation then. I can help with that [12:33] mvo, OK. === MacSlow is now known as MacSlow|lunch [12:36] mvo: Sure, but I'm about to go for lunch [12:36] mvo: Do you have issues with them? [12:40] lool: I have a debdiff for review that fixes the most recent change http://paste.ubuntu.com/373188/ - I think its still not ideal, but works in my tests [12:41] mvo: That's odd, I tested the code and it worked for me; do you have a sample control where it fails? [12:41] lool: sure, try the atspi one [12:42] mvo: Oh it's comments [12:42] lool: the problem is that paraborder is set to "0" on the first line that is not a \n - but that means that control files with # this is autogenerated\ndo not\nedit\n\n will not work [12:42] lool: so if you are fine with the above debdiff I will upload now and rebuild pyatspi [12:42] re [12:43] mvo: how about http://paste.ubuntu.com/373190/ instead? [12:43] mvo, tkamppeter: we shouldn't use hp-mkuri in the middle, I think; update-notifier can just listen to the device event directly and fire up the gui [12:43] mvo: Sorry about that BTW, I forgot to handle comments, but I wanted to stop parsing of XS-PV in binary packages [12:44] lool: yeah, that is fine as well [12:44] mvo: Ok; I think my change is closer to what dpkg-dev does [12:44] see /usr/share/perl5/Dpkg/Cdata.pm [12:45] lool: fine with me [12:45] mvo: uploading [12:46] done [12:46] mvo: Sorry again for the trouble [12:46] mvo: Next thing on my list would be to turn on include-links by default in a PPA [12:46] * lool lunch & [12:46] lool: nice, thanks [12:47] pittim I do not know whether it is a good idea, as the UDEV rule is also subject to change with the HPLIP package, and so hplip should provide it. [12:48] pitti: ^^ [12:53] tkamppeter: make the udev rule ENV{ID_HPLIP_CHECK}="1" and only test the property in update-notifier, not the vendor/product ID directly? [12:54] tkamppeter, pitti: we can make u-n run a script provided by hplip when we get such a event [12:54] mvo: I thought that was by and large already there? [12:54] pitti: yes [12:55] pitti: I just wanted to decouple what is run from the u-n code, so that hplip can provide the command in a script [12:55] that makes sense [12:57] pitti, mvo, hp-mkuri is needed to check whether a download of the plugin is really necessary. It sends notifications only if the HP device really needs the plugin and if the plugin is not yet installed. [12:57] and hp-mkuri needs to run as root? or could it run as the user? [12:57] pitti, mvo, therefore I want to send the signal out of hp-mkuri, to not need to re-implement how to determine which device needs the plugin. [12:58] mvo: does u-n listen to the system bus? [12:58] if it does, hp-mkuri could send a signal to the system bus which u-n could pick up [12:59] pitti, mvo, hp-mkuri works also running as me. It gets the model by env variable, so it does not need to access the printer. [13:00] pitti, mvo, so you can see how the notification looks like by running: hp_model='HP LaserJet 1020' hp-mkuri -c; echo $? [13:00] pitti, mvo, no printer needs to be connected for that. [13:08] tkamppeter: if its enough if it runs as the user we could just make it part of the script in hplip that u-n triggers ? [13:17] Yes, then u-n can trigger the script on any HP printer, simply when /lib/udev/rules.d/40-hplip.rules has set ENV{ID_HPLIP}="1" [13:18] Only problem is that we also need to know the printer model somehow without the script needing to re-detect. [13:18] hp-mkuri needs the model in an env variable. /lib/udev/rules.d/56-hpmud_support.rules has it simply at hand. [13:19] pitti, mvo, ^^^^ === MacSlow|lunch is now known as MacSlow [13:29] asac: so it's still necessary to apply dozens and dozens of thumb2 patches to all kinds of packages? I thought that got fixed in gcc proper? [13:29] pitti, that doesnt fix the broken code that uses hardcoded asm [13:30] ah, so that's not just the workaround any more that we applied to gtk and such [13:30] there are lots of packages that use asm to add arm support, asm thats not supported in thumb2 mode [13:30] pitti: not sure what you mean [13:31] pitti, https://wiki.ubuntu.com/ARM/Thumb2 [13:31] pitti: there was a implicit-it fix that helped for a good bunch [13:31] the rest is assembler that isnt valid and needs to get ported [13:31] pitti, look at "assembler errors" at that wikipage [13:32] pitti: could you upload postgresql at some point before alpha3? [13:32] iirc my patch is fix committed there [13:33] asac: I meant thsi: http://launchpadlibrarian.net/36400628/glib2.0_2.23.0-1ubuntu1_2.23.0-1ubuntu2.diff.gz [13:33] pitti: https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList ... thats the fulll list of packages with assembler issues [13:33] * asac checks [13:33] asac: yep, can do, it went to testing right before the sprint [13:33] pitti: yes [13:33] thats the kind of patches we do [13:33] atomics [13:33] and other stuff [13:34] for atomics we can replace assembler with gcc atomic built-ins [13:34] for other stuff we need to add different assembler [13:35] https://wiki.ubuntu.com/ARM/Thumb2PortingHowto [13:35] thats the howto [13:35] pitti: the glib fix is upstream now [13:35] It's not a patch anymore [13:35] right [13:35] ah, I remembered that it was a workaround for a gcc fix [13:35] thanks [13:35] pitti: there was something else ... called "implicit-it" [13:35] It's a workaround to use gcc's functions instead of the builtin assembler implementation [13:36] we added that to a few packages in the beginning, but then doko made that default for gcc [13:36] Oh right, that's probably what pitti recalls [13:36] yes [14:07] pitti, mvo: Any comments on my last messages? [14:08] was there anything that stops us from uploading v3 formats to lucid directly? [14:08] does that LP bug mean that you will only be able to upload -0ubuntu1 packages? [14:09] v3 (.orig).tar.gz ought [14:09] to work [14:09] but not .bz2? [14:10] .bz2 and others were believed to be buggy, yes [14:11] ok, I'll stop implementing it then :-) [14:12] ? [14:12] it should be fine for native packages [14:13] which was the one I particularly cared about :-) [14:13] (dpkg) [14:14] sorry, I mean I'll stop implementing the bit that makes v3 source packages with .bz2 tarballs [14:15] I have the import part [14:27] james_w: ah, right [14:27] I've added a --v3 flag to merge-upstream that will make it not repack .bz2 tarballs, should be good for this release [14:28] we can make it more automatic when the toolchain is up to it [14:30] james_w: pristine-tar can repack bz2 - it's xz it has trouble with, if that's the problem you mean [14:31] james_w: is there a current bzr-builddeb release branch that doesn't require bzr 2.1? [14:34] cjwatson: that too, but I don't want to automatically create packages that will lead to problems later with Launchpad [14:34] mm, fair enough [14:35] cjwatson: no, unfortunately not. You can just edit __init__.py to comment out that block if you want. [14:35] it's for the changelog merge support [14:35] I just reverted to r398 :-) [14:39] pitti: does "dbus-send --system --dest=com.hp.hplip --type=signal /com/hp/hplip com.hp.hplip.NeedFirmware" in the backend as a singal name make sense to you? for signaling u-n? [14:41] Processing triggers for initramfs-tools ... [14:41] update-initramfs: Generating /boot/initrd.img-2.6.32-12-generic [14:41] cpio: ./lib/udev/firmware.sh: Function stat failed: No such file or directory [14:41] update-initramfs: failed for /boot/initrd.img-2.6.32-12-generic [14:41] should I be worried about that? === Hellow_ is now known as Hellow [14:41] just happened on an update, i'm reluctant to reboot till i can get it sorted [14:42] sabdfl: did the update fail or did you just read the message? Because I did a update some minutes ago (with gui) without problems [14:43] hmm.. was doing it under aptitude. i have some ppa's but don't think there's a kernel package in 'em [14:43] it did say i needed to do dpkg --configure -a [14:43] so i think it failed [14:45] sabdfl: oh, seeing it too now. I don't use PPAs so .. === dholbach_ is now known as dholbach [14:47] * sebner waves at Keybuk [14:50] sabdfl: bug 519855 [14:50] Launchpad bug 519855 in udev "update-initramfs fails: ./lib/udev/firmware.sh does not exist" [Undecided,New] https://launchpad.net/bugs/519855 [14:51] cjwatson: should i not reboot, or just go ahead? [14:51] I'm not sure yet [14:51] firmware.sh was converted to C [14:52] The old initramfs should still be there unchanged. [14:53] cjwatson: It set it to confirmed and there is already a patch [14:53] I was just writing the obvious patch :) [14:54] ah heh [14:54] sabdfl: you should be able to apply http://launchpadlibrarian.net/39011493/udev-firmware.patch and then 'update-initramfs -u' again [14:58] cjwatson: i don't mind waiting for it to come via update if it won't hose my system on reboot [14:58] or should i just be the guinea pig [14:59] sabdfl: in the worst case you might be able to do the "workaround" in the recovery shell :P [14:59] ok. if you don't see me again soon.... [14:59] I've just applied the patch, updated initramfs and rebooted - all works fine [14:59] anybody reboot without the patch? [15:00] sabdfl, someone on ubuntuforums did and it worked [15:00] ok, see you all soon then, and thanks for the help [15:00] kklimonda: bah, you are spoiling all the fun :P [15:00] sabdfl: hf! [15:01] reboot without the patch> that will depend on details of your hardware [15:01] i.e. whether you need firmware to be loaded in order to mount the root filesystem [15:02] most systems don't, but a few SCSI systems need the firmware loader [15:02] as do things like NFS-root over network devices that need firmware === RoAk is now known as RoAkSoAx [15:06] cjwatson, hmm.. but if update-initramfs fails older version of initramfs is going to be used which still has /lib/udev/firmware.sh - at which point is it going to fail to boot? [15:07] kklimonda: dunno [15:09] mvo: do you want to mark foundations-lucid-dynamic-cdrom-handling as implemented (I figure you should get the karma!), or do you want to do something about the postponed WI there? [15:12] kenvandine: Is there python-appindicator 0.0.12 build for karmic? [15:12] kees: ping re PIE for xulrunner [15:13] Keybuk: BTW, you asked about my initramfs-tools branch at the end of last week; as far as I can tell I pushed the changes to bzr before I uploaded them, and everything looked up to date when I checked independently [15:14] mbudde, oh... no... i need to do that in the ppa [15:15] mbudde, i'll ping you when it is [15:15] cjwatson: karma! [15:16] cjwatson: I mark it implemented :) thanks. the remaining item is really small, I will see what I can do about it, but its not a big issue in the UI [15:16] Keybuk, I wonder if you would be interested in looking over some "Deleting plymouth seems to have fixed/created issues" bugs I have on the kernel? [15:16] for instance bug 518452 [15:16] mvo: righto [15:16] Launchpad bug 518452 in linux "[Lucid] No longer boots with new 2.6.32-12 generic kernel" [Medium,Triaged] https://launchpad.net/bugs/518452 [15:16] kenvandine: great! === asac_ is now known as asac [15:43] Riddell: could it be that kdebase in the kubuntu-ppa has ubuntu-devel@lists.u.c set as Maintainer address? [15:44] hi [15:44] i tried to load "record" module X11 on 9.10 [15:44] but i couldnt [15:44] i heard it is broken [15:51] t3rm1n4l, I think it's better to ask in #ubuntu - if you think it's a bug you can report it (see https://launchpad.net/ubuntu/+filebug/) thanks [15:55] mvo: signal> looks fine to me [15:58] Riddell: kdepim4 and kdeutils4 too - we get mails on ubuntu-reviews because of that === xomas_ is now known as xomas [16:06] dholbach: isn't it just kubuntu-ninjas -> kubuntu-dev -> ubuntu-core-dev or some such [16:07] some team along the kubuntu bit of the chain probably needs to get a contact address set [16:07] ah ok [16:07] it's not particularly new, just that some stuff failed recently [16:40] keybuk, hi [16:43] for those who were asking: I've done a new-source run, mostly. I left out a few packages which collided with other source packages or whatever and needed some manual inspection; if you're still missing anything that's in testing and you can't figure out why it isn't in lucid, shout [16:43] cjwatson: did you do contrib and non-free too? [16:44] cjwatson: swt-gtk came up earlier : does that apply only for NEW sources, or also outstanding syncs? [16:44] * ogra just wants that one package that magically fixes all our bugs ... but i guess that wasnt even uploaded to debian yet :) [16:45] cjohnston: alien-arena [16:45] *cjwatson [16:45] I guess that counts for contrib [16:45] Keybuk: ^ [16:45] ogra: did you boot with "nobugs" on the kernel command-line? [16:45]