[00:23] Guest36494: yeah, timing issues for me. [00:23] Guest36494: and sometimes i/o stalls :( [00:44] I should plug the wrong AC adapter into Dells more often [00:44] it's great for debugging [00:44] you get a nice *BEEP*BEEP* and have to press F1 [00:45] otherwise it won't switch on/reboot [00:45] heh [00:45] still a dell adaper? [00:45] so I can then press F1 and hold down shift ;) [00:46] slangasek, cjwatson: I thought P-a-s was in sync with debian? [00:47] we don't seem to have this change: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543601 [00:47] Debian bug 543601 in buildd.debian.org "prelink compiles on all architectures" [Normal,Open] [00:47] kees: it's manually synced [00:47] gar [00:47] lp:~ubuntu-core-dev/packages-arch-specific/ubuntu [00:47] merged from lp:packages-arch-specific [00:47] * kees fixes [00:47] we've had our own branch for ... maybe a year now? [00:52] okay, I've merged the Debian changes from Feb and Mar now [00:54] damnit bzr [00:54] if you don't know a push location, why not try and see if you can push to the parent hmm? [00:54] * slangasek grins [00:55] Keybuk: because thats usually the wrong thing [00:55] no it isn't [00:55] lifeless: Really? When is pushing to the parent the wrong thing? [00:55] bzr branch lp:blahblahblah [00:55] work on it [00:55] bzr push [00:56] bbiab [00:56] RAOF: everytime you don't own the branch [00:56] if you don't own it, you can't push to it [00:56] so it'll fail [00:56] and then you can say "no push location" [00:56] it could at least *try* :) [00:57] lool: is there any way to run ARM with >256M of memory? all it seems to do is segv if I try to change it. [00:57] hell, surely at branch point it knows whether or not you can write? [00:57] so bzr branch could save the push location as the parent if it happens to know it's writable [01:02] i'm wondering if anybody can help me understand something in the intersection between dh_install and policy kit on lucid [01:04] barry: shoot [01:05] slangasek: thanks. so i'm nearly done with my dbus refactoring of computer janitor. it needs to install a polkit policy. mvo extended computerjanitor.install to install the policy file to /usr/share/PolicyKit/policy but that doesn't work. i believe it needs to go to /usr/share/polkit-1/actions [01:06] slangasek: now, i've hacked the .install file to do that, but i had to explicitly mention the PolicyKit path and i'm wondering, shouldn't dh_install install it to the right place automatically? [01:06] kees: thats a limitation on the platform emulated by qemu afaik, I think lool has a patch to allow 512MB though but not sure it applies to the more recent qemu's or it'd be there I imagine [01:06] slangasek: otoh, i don't know all the magic that dh_install actually does ;) [01:06] barry: dh_install is the generic "install files where I tell you to" command [01:07] barry: there are many other specialized commands that install common files of various sorts in the obvious places, but there's no dh_policykit that I'm aware of [01:07] slangasek: i think you're right, i couldn't find a dh_installpolicykit either [01:07] slangasek: so, mvo had this originally in the computer-janitor.install file: [01:08] /usr/share/PolicyKit [01:08] i tried changing that to [01:08] er, no leading slash [01:08] usr/share/polkit-1 [01:08] and dh_install --fail-missing complained [01:09] that was "/usr/share/PolicyKit" on a line by itself? [01:09] slangasek: usr/share/PolicyKit on a line by itself [01:11] barry: right, that's a magic rule meaning "copy debian/tmp/usr/share/PolicyKit to a tree of the same name in the package" [01:11] barry: so you need to do usr/share/PolicyKit/* usr/share/polkit-1 instead if you want dh_install to magic this away for you, I think [01:12] slangasek: how did computerjanitord/data/com.ubuntu.computerjanitor.policy get into usr/share/PolicyKit in the first place? [01:12] sec, let me pull the package to see [01:13] slangasek: oh wait. i bet it's the setup.py that did it [01:13] could be [01:14] slangasek: cool, that fits together then. let me try that. thanks for the help! [01:14] sure thing [01:14] (fwiw, the package I grabbed doesn't seem to do what you're talking about, oops :) [01:15] slangasek: it would be lp:~barry/computer-janitor/dbus-merged [01:16] slangasek: ^^ is a new version of c-j i'm trying to get landed [01:16] ok [01:18] slangasek: yep, that was it. thanks again [02:07] bryceh: still around? [02:10] yeah, but a bit busy, what's up? [02:14] bryceh: random question for you [02:14] X multi-head [02:15] laptop has widescreen netbookish LVDS [02:15] plug into 4:3 external display [02:15] X picks a very random resolution to clone both together [02:15] 800x600 @ 60 hz or something [02:15] it's not even the highest common resolution they both support [02:15] why? [02:15] brain damage [02:16] usually the Xorg.0.log will list out the logic as to why it arrives at a particular resolution arrangement [02:16] Same here. The laptop has a 1280×800 display and it’s connected to a 1920×1200 monitor. X picks something like 800×600 by default. [02:16] bryceh: xrandr --auto doesn't fix this either [02:16] I have to --preferred each display [02:17] with cloning, it seems like there's three different ways it could be done, and no one of the three will cover all possible use cases [02:17] upstream seems to have picked an approach that suits the smallest of the three use cases. [02:17] why does it clone by default at all? [02:18] I guess that's what confused me [02:18] s/800×600/1024×768/ actually [02:18] I think it's for the projector use case, and assuming people will want to see everything on both screens [02:19] so it tries to find the lowest common matching resolution [02:19] with 4:3 and an HD monitor, there really isn't a good common denominator [02:19] it's kinda annoying [02:19] you see [02:19] I guess way back when, laptops also had 4:3 so that worke [02:19] d [02:19] we put some amount of effort to support multi-head with plymouth [02:19] so even if you have a monitor [02:19] the splash screen looks sexy on both the panel and the monitor [02:19] now days it generally falls all the way down to one of the vesa modes [02:19] not stretches [02:20] all text on both [02:20] etc. [02:20] and that looks nice [02:20] then gdm starts [02:20] and you end up in the resolution from hell [02:20] and the smooth transition doesn't look so slick after all ;) [02:20] * bryceh nods [02:21] brain damage, like I said [02:25] hi all [02:25] who knows about mono [02:27] A number of people. They're more likely to answer if you ask an actual question, though. [02:27] ok [02:27] looking for a ppa of mono2.6 [02:27] specifically libapache2-mod-mono 2.6 [02:27] ...as long as that question is on-topic for #ubuntu-devel :) [02:28] otherwise the status of mono 2.6 in ubuntu, and roadblocks if any [02:28] Status of mono 2.6 in Ubuntu Lucid: 2.6 is not a long term support release, 2.4 is. We're sticking with 2.4. [02:29] ffuuuu [02:30] hmmm [02:30] Launchpad's pretty good at searching in PPAs now; just browse to the mono source package, and it'll list PPAs which build mono. [02:30] ok thanks === plars` is now known as plars [07:32] good morning [07:33] Good morning [07:33] hey pitti === crypt-0 is now known as test === test is now known as crypt-0 === tkamppeter_ is now known as tkamppeter [07:48] Keybuk: shall I commit your gdm changes to bzr, or did you do already and just need to push? [08:18] pitti, mvo, hi [08:27] kees: I don't think you need the rootfs anymore, but in case you do http://people.canonical.com/~lool/rootfs.img [08:57] Hi, I'm really looking forward to Beta 1... Is the exact time of release known? I know it's tomorrow, but when exactly does it become available? [09:07] PetrolCB: There's no precise time : sometime after the images are tested and confirmed beta-quality. [09:07] ok, thanks [09:07] PetrolCB: If you'd like to help out with testing, you may be able to help make it be sooner. [09:08] I've subscribed to ubuntu-announce so I guess I'll get an email not too long after it's been released [09:08] sure, how can I help? [09:09] Head over to #ubuntu-testing where the coordination happens, and someone will surely help you get started. [09:12] pitti: shall I upload nvidia too (in addition to fglrx) since they won't be approved anyway? [09:13] tseliot: go ahead [09:14] pitti: ok, thanks [09:15] pitti, hi [09:15] hi tkamppeter [09:17] I have tried around with the dbus problem, and tried to use a session bus service. [09:17] tkamppeter: what is the problem again? [09:20] The problem is that if a printer is connected and detected by HPLIP and it needs firmware, the udev script (running as root) sends a dbus message so that a program of the user's desktop can catch the signal and run a firmware download GUI (running as the user). [09:20] tkamppeter: ah, right; was that added to update-notifier? [09:21] There was a suggestion to use ubuntu-notifier as the listener and mvo has written a piece of code to do the task: http://pastebin.ubuntu.com/396286/ [09:21] thanks, persia [09:22] With this code ubuntu-notifier listens for a NeedPlugin signal on com.hp.hplip which root sends via [09:22] dbus-send --system --dest=com.hp.hplip --type=signal /com/hp/hplip com.hp.hplip.NeedPlugin [09:22] hmm [09:23] this adds a listener to the system bus [09:23] mvo: ^ wouldn't that collide if you have more than one session? [09:23] Problem is probably here also that com.hp.hplip is already used by HPLIP for PolicyKit. [09:23] pitti: the problem is that dbus-send does not really gives the right kind of signal, it need to come from the com.hp.hplip dbus server that is already there [09:23] yes, it should be com.ubuntu.UpdateNotifier [09:24] or update-notifier needs to add low level matchers (I ahve code for this but its ugly) [09:24] My suggestion is to add a service to the session bus. [09:24] mvo: oh, nevermind me; I read it the wrong way round [09:24] mvo: u-m just connects to the existing hplip D-BUS service, right? [09:24] and reads signals from it [09:24] yes [09:24] so we should add the signal there IMO [09:24] For a quick test I edited /usr/share/hplip/hpssd.py adding a new method to com.hplip.StatuisService: [09:25] tkamppeter: with your dbus-send, you are sending a signal *to* the hplip D-BUS service [09:26] tkamppeter: what you really need is having the D-BUS service (the process for com.hp.hplip) send out the NeedPlugin signal [09:26] http://pastebin.ubuntu.com/396603/ [09:26] Name of the method is InstallPlugin [09:27] Problem of this is that it works only if the message is sent by the user, not by root. [09:28] tkamppeter: so, the way it's meant to be is to have the hplip daemon listen to udev events (with libudev), pick out the "needs firmware" thing, and send the signal from its d-bus service [09:28] sending that from udev rules doesn't work, since there is no process/D-BUS service attached to an udev rule invocation [09:29] you can't send signals in the name of another process [09:29] pitti, but if an HPLIP daemonlistens, it could directly start the plugin-installer, without using update-notifier. [09:29] tkamppeter: hplip runs as a root system daemon, though? [09:29] and I thought you need a GUI [09:30] pitti, HPLIP does not have a root system daemon. [09:30] pitti, if hplip-gui is installed, there is a session daemon running as the user, hp-systray. [09:31] tkamppeter: now, that is the client side component which could pick up a signal, or udev event [09:31] tkamppeter: i. e. this could use libudev to watch out for firmware events [09:31] (instead of the udev rule, dbus-send, and the other hackery) [09:32] hp-systray can pop up a GUI program when it gets a dbus message. [09:33] tkamppeter: but if hplip doesn't have a daemon, there's nothign to send the d-bus message from; also, it'd be the wrong way around [09:33] pitti, you mean that the listener which runs as the user and pops up the plugin installer should listen for udev events and not for dbus messages? [09:33] tkamppeter: I think hp-systray or u-m should just listen to the udev event [09:33] it's how the system is meant to work, and the most robust way without hacks [09:33] tkamppeter: correct [09:34] pitti, is a daemon needed to send dbus messages? dbus-send is not a daemon. [09:34] tkamppeter: no, please drop the dbus-send stuff [09:34] tkamppeter: you just need libudev (or python-gudev if it's python), and install a listener for the subsystem that the udev rule is currently listening to [09:34] "firmware"? [09:34] or usb, or whatever it's listening to === MacSlow is now known as MacSlow|errand [09:35] tkamppeter: is that C or Python? [09:36] So what I need would be a small Python program which is started for the user session (via /etc/xdg/autostart/*.desktop) and it listens for plug events of firmware-needing printers? [09:36] nonononono, please no more additional python programs [09:37] yet another python process in the session?! [09:37] tkamppeter: I thought there already was a hp-systray thing? [09:37] tkamppeter: if there is none, we can use update-notifier [09:37] it already uses gudev and listens to events [09:37] Can I make somehow make use of /lib/udev/rules.d/56-hpmud_support.rules [09:37] it's dead cheap to add it there, instead of the current dbus listener [09:37] pitti++ [09:37] I'm happy to add the code for that, its pretty trivial [09:38] either to u-n, or system-config-printer [09:38] the latter runs in the session anyway, too [09:38] mvo, can you chabge the src/hplip.c there, so that it listens to udev and not to dbus? [09:39] tkamppeter: sure [09:39] tkamppeter: the rule needs to be rewritten into C code, so you can use the logic of the rule [09:39] mvo, it is important that it works with both plugging the printer during the session and also if the printer got plugged before the session started. [09:40] i. e. you listen for the correct subsystem (firmware/usb/whatever) and then check the attributes/properties of the udev_device you get in the event handler [09:40] tkamppeter: for the latter you won't get an uevent; for that you need to iterate over all existing udev devices and pick out the existing ones [09:40] but one thing at a time [09:40] Important in the rule is the use of hp-mkuri, as this HPLIP utility determines whether the printer needs the plugin or not. [09:45] pitti, mvo, in general, for the packaging it works well for now to have the listener in update-notifier, but for the future one needs to think about the following: [09:46] 1. system-config-printer is not a good place as upstream will never accept it. Fedora does not only have a "Do not ship proprietary software" policy, but a "Do not tell the user that proprietary software exists" policy. [09:47] 2. Is update-notifier GNOME-only? Or is it also available in Kubuntu? [09:47] tkamppeter: 2. KDE has a counterpart, but it's different code [09:48] I'm off IRC for some minutes to debug a suspend bug [09:49] pitti, mvo, so the code stub which we are adding to ubuntu-notifier now we better put into a separate C program which we ship with HPLIP [09:49] pitti, mvo: This would also be better for HPLIP upstream/ [10:05] pitti, are you back? [10:06] tkamppeter: yes [10:08] pitti, mvo, so the code stub which we are adding to ubuntu-notifier now we should better put into a separate C program which we ship with HPLIP, so that also KDE users get it working and in addition we can submit the code to HPLIP upstream, so that all HPLIP users get their firmware easily installed. [10:09] tkamppeter: can we put it into u-n for lucid? it's a much less intrusive change, avoids yet another daemon to start up, and more packaging changes [10:10] pitti, OK, I will start separating it later. [10:11] tkamppeter: what does the code do? [10:12] Riddell, if udev discovers an HP printer which needs its firmware loaded whenever it gets turned on (only HP has such printers) then it should be popped up a GUI to download and install the proprietary firmware file. [10:14] tkamppeter: ok that sounds non-trivial to get ported to Kubuntu but maybe send me an e-mail so I don't forget about it [10:14] Riddell: HPLIP has a utility which is called by the udev rule and determines whether the firmware needs to be installed. For now only a message pops up, telling the user to run the firmware installer, but the firmware installer is not actually popped up. [10:14] an e-mail pointing at where the code is in update-notifier once it's in [10:16] pitti, mvo, Riddell: My idea of the separate code was that HPLIP gets added two files: The listener in C and an /etc/xdg/autostart/*.desktop file to start it and this way on all desktops the firmware installer pops up if needed. [10:18] pitti, mvo, Riddell: The update-notifier solution does not add files, but it is GNOME-only, would also need an additional KDE implementation, and so is perhaps more code addition to Lucid. [10:18] tkamppeter: if it's GUI code we would want it re-written for KDE preferably. however there is a rewrite of the printer applet part of system-config-printer-kde happening currently so it might make sense to add it to that project [10:20] Riddell, the listener has no GUI at all. It is simply a process running as the desktop user, listening for udev messages and starting a program named hp-plugin-ubuntu (this program ships with HPLIP). [10:21] Riddell, so the listener is exactly the same for KDE and GNOME. [10:22] tkamppeter: but there must be a GUI part too no? [10:22] Riddell, we should also avoid to put any code for the proprietary plugin of HPLIP into s-c-p, as s-c-p upstream will not accept it. [10:22] Riddell, the GUI part is in hp-plugin-ubuntu.\ [10:22] right [10:24] Riddell, HPLIP itself has only Qt-based GUIs, so hp-plugin-ubuntu checks whether Qt is there and if so starts the native HPLIP GUI for the plugin download, if no Qt is there it starts the interactive text mode interface for the plugin download in a terminal. [10:25] tkamppeter: so where does update-notifier come into it? [10:47] Riddell, update-notifier was only used to make use of an already existing user-session daemon. The idea was not to introduce another one. [11:03] dyfet: do we care about your plasma-widget-message-indicator upload for beta 1? [11:10] Riddell: You're probably best poised to answer that: it's an rdepend of kubnutu-desktop and kubuntu-netbook. Currently it's stuck at 0.5.1 due to FTBFS, the upload would get 0.5.2. You uploaded 0.5.2 on 10 march for some reason :) === jussi01 is now known as o1 === o1 is now known as jussi01 [11:17] persia: fair point :) [11:18] ev: on bug 534473 what's a Cruzer Micro? I get that bug on my normal CD installs [11:18] Launchpad bug 534473 in ubiquity "Wrong CD device used when installed from a Cruzer Micro." [High,Triaged] https://launchpad.net/bugs/534473 [11:18] Riddell: it's a usb disk. I think they're the same bug, regardless. [11:20] ev: seems quite a nasty bug to have in for beta, means OEM install can't work. I guess I can test in a virtual machine === Klanticus_ is now known as Klanticus [11:21] indeed, I hadn't realized it affected regular CD installs until you just pointed it out [11:21] hrm [11:21] maybe this isn't the same bug after all [11:21] Riddell: did you have more than one CD inserted? [11:22] ev: no only 1 CD [11:22] yikes, okay [11:22] I'll undupe your bug then [11:23] happens on both of my machines [11:24] maybe we should go back to bind-mounting /cdrom (though perhaps onto /media/apt or something) if we have it rather than letting apt-cdrom use libudev for that bit [11:24] Riddell: FWIW I'm pretty sure it doesn't happen everywhere [11:24] it's not clear exactly what's going on - I suspect that apt's libudev integration might be subtly wrong and doesn't catch all cases [11:25] I'll do a test to double-check, but I'm pretty sure that that part of the installation works OK in kvm at least [11:25] in which case I think we could release-note it for now [11:25] right, I don't get the problem in a virtual machine [11:26] I bet it depends on the exact type of CD drive [11:26] e.g. whether it's also DVD-capable [11:26] I looked at the code last week and thought the parameters we set in apt cause it to not go down the libudev path, but I could be very wrong. [11:27] I think maybe in base-installer but not in ubiquity [11:27] which is probably an oversight! [11:28] list-devices (in debian-installer-utils) certainly checks several more cases than apt-cdrom does [11:28] is there 'udevadm info -q all' output for one of these devices around somewhere? [11:29] ('udevadm info -q all -n /dev/blah') [11:32] no, but I did get a udisks dump: http://launchpadlibrarian.net/40499554/udisks.txt [11:32] sdc? [11:33] correct [11:33] with sr0 being the fake cdrom for windows drivers [11:33] not clear from that though, or else I'm not smart enough to extract it [11:48] mvo. pitti, can you do the code change in update-notifier to pop up the plugin installer ("hp-plugin-ubuntu", not "hplip-plugin-ubuntu"), and tell me when you are ready, then I will do the HPLIP changes. === MacSlow|errand is now known as MacSlow [12:40] tkamppeter: for the dbus stuff or does that need to be converted to udev ? [13:45] mvo, this must be converted to UDEV as I understand from our discussion. [13:46] mvo, if needed, I can add something to the UDEV rules file, so that these printers are somehow distinguishable from ordinary printers in the list of UDEV-reported devices. [13:49] tkamppeter: if you could do the udev rule part, that would be nice, my experience there is limited [13:50] pitti, can you help on the UDEV part in the C code of update-notifier? [13:50] tkamppeter: yes, but not today/tomorrow (hands full with beta stuff) [13:51] pitti, mvo, so let us move it out for after the beta release. [13:55] tkamppeter: the udev C bits are no problem, the udev rule file is what I do not have a lot of experience iwth [13:57] mvo, the meaning is the following: [13:58] tkamppeter: can you paste it somewhere? (I don't have it here); mvo, I'm happy to interpret it/help with tanslating to gudev [14:01] When a USB device is added and it has vendor ID 0x03f0 and product IS 0xXX17 (XXX are two arbitrary hex digits) then the command line is executed. The com,mand line sets the environment variable hp_model to the model ID (text vertsion) of the USB device and then runs "hp-mkuri -c" in the background. [14:01] pitti: I did push! [14:01] that branch is owned by the importer anyway - so if I hadn't pushed, it would have shown up [14:02] Keybuk: ah, -EWRONGBRANCH then [14:02] Keybuk: I'll commit it, don't worry [14:03] pitti: ? I used lp:ubuntu/gdm [14:03] Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/gdm/ubuntu [14:03] "hp-mkuri -c" checks whether the printer whose model name is suppied via the hp_model variable needs firmware and whether the firmware is already installed. IF and only if the printer needs firmware and the firmware is NOT installed, it generates a desktop notification and also sends a message to the system (currently via dbus, but I can change it to any other type of message. [14:03] mvo, ^^^ [14:03] pitti: ah, I missed that [14:03] pitti: still using debian-only packaging then? [14:04] yes, for now; we'd loose all the history [14:04] (and would be stuck with a much worse performance) [14:05] pitti: of course, the nice thing is you can cherry-pick the change from lp:ubuntu/gdm no? [14:06] pitti, mvo, the udev-rules file is /lib/udev/rules.d/56-hpmud_support.rules and is part of the hplip package. Here it is pasted for all the Samsung printer users who have uninstalled HPLIP: http://pastebin.ubuntu.com/396702/ [14:06] Keybuk: I grabbed the diff from LP and committed it; all good now [14:06] pitti: I've never figured out how to deal with these separated debian branches [14:06] I can never get to the point I can build from them [14:07] Keybuk: bzr-builddeb is awesome for those [14:07] Keybuk, bzr-buildpackage [14:07] still doesn't give me the source [14:07] one command, gets the tarball and do everything for you too [14:07] it does [14:07] it auto-downloads the orig.tar.gz, and everything [14:07] it gets the archive one or use the watch for new versions [14:08] Keybuk: so usually you'd do "bzr bd-do", hack the (now full source) tree, and if you exit the shell it copies back the changes to debian/ [14:08] Keybuk: bzr bd -S -> build source, bzr bd -- -b -> build binaries, etc. [14:08] bzr bd-do and edit-patch usually [14:08] I did use edit-patch the other day [14:08] kudos to mvo [14:09] mvo: so basically, you use http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/GUdevClient.html#g-udev-client-new to listen to "usb" subsystem events (what the udev rule sya) [14:10] pitti: ok, adding the code now [14:10] Keybuk: :) [14:10] mvo: and whenever you get an add or change event, you use http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/GUdevDevice.html#g-udev-device-get-sysfs-attr to check idVendor/idProduct [14:11] mvo: you can just copy & paste the general listener stuff from the jockey firmware code [14:11] mvo: or, even easier, just add it to that event handler, so that we don't need two listeners :) [14:11] it's firmware either way, after all [14:11] pitti: good point [14:14] pitti: should I test for idVendor, idProduct or should it rather add a PROPERTY to look for in the udev rule file ? [14:14] pitti: and I test on that property then? [14:17] mvo: we should just drop the udev rule [14:17] mvo: just check the attribute, that's fine [14:17] aha, ok [14:17] no need to needlessly add more stuff into the chain === sconklin-gone is now known as sconklin [14:35] tkamppeter, pitti: what is %E{ID_MODEL} ? sysfsattr, property? something else? [14:35] mvo: property [14:35] thanks [14:36] mvo: http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/GUdevDevice.html#g-udev-device-get-property [14:36] mvo: but I wonder whether hp-mkuri is actually the program that we have to call? tkamppeter? [14:36] thanks, I figured that :) [14:37] tkamppeter: do I need to call hp-mkuri -c to check if the firmware is needed? or can I just unconditionally call the hp-plugin-ubuntu helper? [14:39] mvo: don't forget to respond to debian squid guy at some point! [14:39] jcastro: weeh, right [14:52] tkamppeter: I commited the changes to update-notifier now, it currently calls hp-mkuri -c, if that is unneeded, just let me know and I remove it [14:52] tkamppeter: get it with lp:update-notifier and build with bzr-buildpackage to try it out [15:24] mvo, got it, thank you. I am building it now. [15:27] tkamppeter: thanks, let me know about hp-mkuri -c (but feel free to just modify the code yourself) [15:43] hi, can someone direct me to a resource describing conventions in coding C for ubuntu if there are any? [15:45] kobrien: there aren't any [15:46] if you want to read some conventions, a good idea is to download a copy of the GNU Standards, print them out, and then BURN THEM! [15:46] (actually, they're probably as good a guide as any - at least to building. ie. your project should use autoconf + automake, etc.) === highvolt1ge is now known as highvoltage [15:55] shtylman, Riddell: any idea why the kde frontend of ubiquity has started to consume 100% cpu (bug 538505)? It's not happening in the GTK+ frontend, and my attempts so far at cracking this have proven unsuccessful. [15:55] Launchpad bug 538505 in ubiquity "Extremely slow reponsiveness / high CPU usage" [High,Confirmed] https://launchpad.net/bugs/538505 [15:57] ev: I've not seen that issue (and I've done quite a few installs today) [15:57] Riddell: odd, I can reproduce it in KVM and on real hardware [15:58] ev: I'm more worried about https://launchpad.net/bugs/540275 currently [15:58] Ubuntu bug 540275 in ubiquity "Installing in French breaks the keyboard setup page" [Undecided,New] [16:01] gah === binarylooks is now known as binarylooks_away [16:02] ev: it's a shtylman_ bug from his lovely keyboard page, something is being translated which shouldn't be, I'll take a look after I've had some lunch [16:02] * ev shakes his fist at shtylman ;) [16:03] Riddell: cool, thanks [16:03] fish shaking is the wrong approach I'm sure, intravenous irn bru would work much better [16:03] umm, fist shaking :) [16:05] ev Riddell :) [16:06] life is boring without bugs [16:07] ev: I will test the 100% cpu issue tonight.. ive never seen 100% cpu .. but do find parts of the installer slow... so maybe there is some race or other crazyness happening [16:14] mvo, I am currently fine-tuning your code by testing it with the actual printer (and also testing with HP printers which do not need firmware). === beuno is now known as beuno-lunch [16:17] Riddell: do you know where debug() (e.g. server.c) in kdm writes to? [16:17] i.e. to what log file [16:17] tseliot: /var/log/kdm.log ? [16:18] Riddell: ok, thanks [16:19] tkamppeter: sweet, once its ready let me know and I merge/upload [16:19] tkamppeter: thanks! === yofel_ is now known as yofel === binarylooks_away is now known as binarylooks [16:28] mvo, first bug: in on_uevent() it must read [16:28] if (g_strcmp0 (action, "add") != 0 && g_strcmp0 (action, "change") != 0) [16:28] (&& and not ||) [16:29] mvo, after having corrected that, the firmware dialog actually popped up, but for all HP LaserJet and HP Color LaserJet printers, not only for my LaserJet 1020. [16:30] Keybuk: cheers, I use the gnu standards as it is. cool [16:30] tkamppeter: aha, sorry. I think its not properly checking the return code of hp-mkuri, let me fix that [16:31] mvo, then I checked your use of hp-mkuri and saw that you do not check the exit status. See "hp-mkuri -h". Firmware installation should only happen if the exit status is 2 or 5. [16:31] tkamppeter: ok, fixing ths now [16:31] mvo, I added if (ret != 2 && ret != 5) return TRUE; before calling the firmware installer. [16:33] mvo, In addition, I added more g_debug lines and this way I saw that after the hp-mkuri call ret was set to 512. Is ret not the exit status? [16:33] tkamppeter: it needs to be converted via WEXITSTATUS() [16:34] mvo: 512/256 = 2, is the conversion shifting ret by 8 bits to the right? [16:36] tkamppeter: man waitpid has the info, its available via the macro WEXITSTATUS() [16:36] mvo, thanks, trying WEXITSTATUS(ret) ... [16:37] tkamppeter: or run bzr up [16:37] tkamppeter: I added your fixes to my branch [16:37] (including this one) [16:45] lool: cool, thanks. if anything goes really weird in mind rootfs, I can compare it to yours. [16:51] Keybuk: so, do we know that it's definitely on 'plymouth deactivate', rather than in ply_terminal_close? [16:51] sorry, not following your question [16:51] I'm grepping for paths that call ply_terminal_set_buffered_input [16:52] there seem to be two, and I was wondering if we'd confirmed which one [16:52] set_buffered_input should be guarded [16:52] the one in ply_terminal_close() should return without doing anything because it's called in the deactivate path [16:52] what has happened before is that we ended up with a ply_terminal_set_unbuffered_input() between those two [16:52] so ply_terminal_close() set buffered again [16:53] that was caused, amongst other things, by the fact every damned terminal write did it [16:53] mvo, it is working now, do you need a patch? [16:55] cjwatson: any ideas as to what can be causing this code to exit with return code 10 ? http://pastebin.ubuntu.com/396800/ [16:55] I'm not following where the guard is [16:55] but if this is boring, feel free to tell me and I'll stop pursuing it [16:55] tseliot: have you used DEBCONF_DEBUG=developer? [16:55] tkamppeter: plesae check if trunk/ works correctly, if it does we are good, otherwise I need the patch [16:55] tkamppeter: I fixed the bits you mentioned [16:56] cjwatson: well, I can't reproduce the problem here. A user reproduced it when he was updating the kernel [16:56] Keybuk: I'm finally getting around to remastering the CD to strace plymouth; is that still a useful thing for me to do, or are you already past it? [16:56] tseliot: best ask them for that information [16:56] mv, I see you have already committed the correct version. Can you upload the package? I will update the HPLIP package. [16:56]