| kees | Guest36494: yeah, timing issues for me. | 00:23 |
|---|---|---|
| kees | Guest36494: and sometimes i/o stalls :( | 00:23 |
| Keybuk | I should plug the wrong AC adapter into Dells more often | 00:44 |
| Keybuk | it's great for debugging | 00:44 |
| Keybuk | you get a nice *BEEP*BEEP* and have to press F1 | 00:44 |
| Keybuk | otherwise it won't switch on/reboot | 00:45 |
| lifeless | heh | 00:45 |
| lifeless | still a dell adaper? | 00:45 |
| Keybuk | so I can then press F1 and hold down shift ;) | 00:45 |
| kees | slangasek, cjwatson: I thought P-a-s was in sync with debian? | 00:46 |
| kees | we don't seem to have this change: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543601 | 00:47 |
| ubottu | Debian bug 543601 in buildd.debian.org "prelink compiles on all architectures" [Normal,Open] | 00:47 |
| slangasek | kees: it's manually synced | 00:47 |
| kees | gar | 00:47 |
| cjwatson | lp:~ubuntu-core-dev/packages-arch-specific/ubuntu | 00:47 |
| cjwatson | merged from lp:packages-arch-specific | 00:47 |
| * kees fixes | 00:47 | |
| cjwatson | we've had our own branch for ... maybe a year now? | 00:47 |
| kees | okay, I've merged the Debian changes from Feb and Mar now | 00:52 |
| Keybuk | damnit bzr | 00:54 |
| Keybuk | 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:54 | |
| lifeless | Keybuk: because thats usually the wrong thing | 00:55 |
| Keybuk | no it isn't | 00:55 |
| RAOF | lifeless: Really? When is pushing to the parent the wrong thing? | 00:55 |
| Keybuk | bzr branch lp:blahblahblah | 00:55 |
| Keybuk | work on it | 00:55 |
| Keybuk | bzr push | 00:55 |
| lifeless | bbiab | 00:56 |
| lifeless | RAOF: everytime you don't own the branch | 00:56 |
| Keybuk | if you don't own it, you can't push to it | 00:56 |
| Keybuk | so it'll fail | 00:56 |
| Keybuk | and then you can say "no push location" | 00:56 |
| Keybuk | it could at least *try* :) | 00:56 |
| kees | 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 |
| Keybuk | hell, surely at branch point it knows whether or not you can write? | 00:57 |
| Keybuk | so bzr branch could save the push location as the parent if it happens to know it's writable | 00:57 |
| barry | i'm wondering if anybody can help me understand something in the intersection between dh_install and policy kit on lucid | 01:02 |
| slangasek | barry: shoot | 01:04 |
| barry | 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:05 |
| barry | 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 |
| Sarvatt | 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 |
| barry | slangasek: otoh, i don't know all the magic that dh_install actually does ;) | 01:06 |
| slangasek | barry: dh_install is the generic "install files where I tell you to" command | 01:06 |
| slangasek | 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 |
| barry | slangasek: i think you're right, i couldn't find a dh_installpolicykit either | 01:07 |
| barry | slangasek: so, mvo had this originally in the computer-janitor.install file: | 01:07 |
| barry | /usr/share/PolicyKit | 01:08 |
| barry | i tried changing that to | 01:08 |
| barry | er, no leading slash | 01:08 |
| barry | usr/share/polkit-1 | 01:08 |
| barry | and dh_install --fail-missing complained | 01:08 |
| slangasek | that was "/usr/share/PolicyKit" on a line by itself? | 01:09 |
| barry | slangasek: usr/share/PolicyKit on a line by itself | 01:09 |
| slangasek | 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 |
| slangasek | 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:11 |
| barry | slangasek: how did computerjanitord/data/com.ubuntu.computerjanitor.policy get into usr/share/PolicyKit in the first place? | 01:12 |
| slangasek | sec, let me pull the package to see | 01:12 |
| barry | slangasek: oh wait. i bet it's the setup.py that did it | 01:13 |
| slangasek | could be | 01:13 |
| barry | slangasek: cool, that fits together then. let me try that. thanks for the help! | 01:14 |
| slangasek | sure thing | 01:14 |
| slangasek | (fwiw, the package I grabbed doesn't seem to do what you're talking about, oops :) | 01:14 |
| barry | slangasek: it would be lp:~barry/computer-janitor/dbus-merged | 01:15 |
| barry | slangasek: ^^ is a new version of c-j i'm trying to get landed | 01:16 |
| slangasek | ok | 01:16 |
| barry | slangasek: yep, that was it. thanks again | 01:18 |
| Keybuk | bryceh: still around? | 02:07 |
| bryceh | yeah, but a bit busy, what's up? | 02:10 |
| Keybuk | bryceh: random question for you | 02:14 |
| Keybuk | X multi-head | 02:14 |
| Keybuk | laptop has widescreen netbookish LVDS | 02:15 |
| Keybuk | plug into 4:3 external display | 02:15 |
| Keybuk | X picks a very random resolution to clone both together | 02:15 |
| Keybuk | 800x600 @ 60 hz or something | 02:15 |
| Keybuk | it's not even the highest common resolution they both support | 02:15 |
| Keybuk | why? | 02:15 |
| bryceh | brain damage | 02:15 |
| bryceh | usually the Xorg.0.log will list out the logic as to why it arrives at a particular resolution arrangement | 02:16 |
| ion | 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 |
| Keybuk | bryceh: xrandr --auto doesn't fix this either | 02:16 |
| Keybuk | I have to --preferred each display | 02:16 |
| bryceh | 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 |
| bryceh | upstream seems to have picked an approach that suits the smallest of the three use cases. | 02:17 |
| Keybuk | why does it clone by default at all? | 02:17 |
| Keybuk | I guess that's what confused me | 02:18 |
| ion | s/800×600/1024×768/ actually | 02:18 |
| bryceh | I think it's for the projector use case, and assuming people will want to see everything on both screens | 02:18 |
| bryceh | so it tries to find the lowest common matching resolution | 02:19 |
| bryceh | with 4:3 and an HD monitor, there really isn't a good common denominator | 02:19 |
| Keybuk | it's kinda annoying | 02:19 |
| Keybuk | you see | 02:19 |
| bryceh | I guess way back when, laptops also had 4:3 so that worke | 02:19 |
| bryceh | d | 02:19 |
| Keybuk | we put some amount of effort to support multi-head with plymouth | 02:19 |
| Keybuk | so even if you have a monitor | 02:19 |
| Keybuk | the splash screen looks sexy on both the panel and the monitor | 02:19 |
| bryceh | now days it generally falls all the way down to one of the vesa modes | 02:19 |
| Keybuk | not stretches | 02:19 |
| Keybuk | all text on both | 02:20 |
| Keybuk | etc. | 02:20 |
| Keybuk | and that looks nice | 02:20 |
| Keybuk | then gdm starts | 02:20 |
| Keybuk | and you end up in the resolution from hell | 02:20 |
| Keybuk | and the smooth transition doesn't look so slick after all ;) | 02:20 |
| * bryceh nods | 02:20 | |
| bryceh | brain damage, like I said | 02:21 |
| jmg | hi all | 02:25 |
| jmg | who knows about mono | 02:25 |
| RAOF | A number of people. They're more likely to answer if you ask an actual question, though. | 02:27 |
| jmg | ok | 02:27 |
| jmg | looking for a ppa of mono2.6 | 02:27 |
| jmg | specifically libapache2-mod-mono 2.6 | 02:27 |
| RAOF | ...as long as that question is on-topic for #ubuntu-devel :) | 02:27 |
| jmg | otherwise the status of mono 2.6 in ubuntu, and roadblocks if any | 02:28 |
| RAOF | 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:28 |
| jmg | ffuuuu | 02:29 |
| jmg | hmmm | 02:30 |
| RAOF | 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 |
| jmg | ok thanks | 02:30 |
| === plars` is now known as plars | ||
| dholbach | good morning | 07:32 |
| pitti | Good morning | 07:33 |
| dholbach | hey pitti | 07:33 |
| === crypt-0 is now known as test | ||
| === test is now known as crypt-0 | ||
| === tkamppeter_ is now known as tkamppeter | ||
| pitti | Keybuk: shall I commit your gdm changes to bzr, or did you do already and just need to push? | 07:48 |
| tkamppeter | pitti, mvo, hi | 08:18 |
| lool | kees: I don't think you need the rootfs anymore, but in case you do http://people.canonical.com/~lool/rootfs.img | 08:27 |
| PetrolCB | 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? | 08:57 |
| persia | PetrolCB: There's no precise time : sometime after the images are tested and confirmed beta-quality. | 09:07 |
| PetrolCB | ok, thanks | 09:07 |
| persia | PetrolCB: If you'd like to help out with testing, you may be able to help make it be sooner. | 09:07 |
| PetrolCB | I've subscribed to ubuntu-announce so I guess I'll get an email not too long after it's been released | 09:08 |
| PetrolCB | sure, how can I help? | 09:08 |
| persia | Head over to #ubuntu-testing where the coordination happens, and someone will surely help you get started. | 09:09 |
| tseliot | pitti: shall I upload nvidia too (in addition to fglrx) since they won't be approved anyway? | 09:12 |
| pitti | tseliot: go ahead | 09:13 |
| tseliot | pitti: ok, thanks | 09:14 |
| tkamppeter | pitti, hi | 09:15 |
| pitti | hi tkamppeter | 09:15 |
| tkamppeter | I have tried around with the dbus problem, and tried to use a session bus service. | 09:17 |
| pitti | tkamppeter: what is the problem again? | 09:17 |
| tkamppeter | 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 |
| pitti | tkamppeter: ah, right; was that added to update-notifier? | 09:20 |
| tkamppeter | 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 |
| PetrolCB | thanks, persia | 09:21 |
| tkamppeter | With this code ubuntu-notifier listens for a NeedPlugin signal on com.hp.hplip which root sends via | 09:22 |
| tkamppeter | dbus-send --system --dest=com.hp.hplip --type=signal /com/hp/hplip com.hp.hplip.NeedPlugin | 09:22 |
| pitti | hmm | 09:22 |
| pitti | this adds a listener to the system bus | 09:23 |
| pitti | mvo: ^ wouldn't that collide if you have more than one session? | 09:23 |
| tkamppeter | Problem is probably here also that com.hp.hplip is already used by HPLIP for PolicyKit. | 09:23 |
| mvo | 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 |
| pitti | yes, it should be com.ubuntu.UpdateNotifier | 09:23 |
| mvo | or update-notifier needs to add low level matchers (I ahve code for this but its ugly) | 09:24 |
| tkamppeter | My suggestion is to add a service to the session bus. | 09:24 |
| pitti | mvo: oh, nevermind me; I read it the wrong way round | 09:24 |
| pitti | mvo: u-m just connects to the existing hplip D-BUS service, right? | 09:24 |
| pitti | and reads signals from it | 09:24 |
| mvo | yes | 09:24 |
| mvo | so we should add the signal there IMO | 09:24 |
| tkamppeter | For a quick test I edited /usr/share/hplip/hpssd.py adding a new method to com.hplip.StatuisService: | 09:24 |
| pitti | tkamppeter: with your dbus-send, you are sending a signal *to* the hplip D-BUS service | 09:25 |
| pitti | tkamppeter: what you really need is having the D-BUS service (the process for com.hp.hplip) send out the NeedPlugin signal | 09:26 |
| tkamppeter | http://pastebin.ubuntu.com/396603/ | 09:26 |
| tkamppeter | Name of the method is InstallPlugin | 09:26 |
| tkamppeter | Problem of this is that it works only if the message is sent by the user, not by root. | 09:27 |
| pitti | 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 |
| pitti | sending that from udev rules doesn't work, since there is no process/D-BUS service attached to an udev rule invocation | 09:28 |
| pitti | you can't send signals in the name of another process | 09:29 |
| tkamppeter | pitti, but if an HPLIP daemonlistens, it could directly start the plugin-installer, without using update-notifier. | 09:29 |
| pitti | tkamppeter: hplip runs as a root system daemon, though? | 09:29 |
| pitti | and I thought you need a GUI | 09:29 |
| tkamppeter | pitti, HPLIP does not have a root system daemon. | 09:30 |
| tkamppeter | pitti, if hplip-gui is installed, there is a session daemon running as the user, hp-systray. | 09:30 |
| pitti | tkamppeter: now, that is the client side component which could pick up a signal, or udev event | 09:31 |
| pitti | tkamppeter: i. e. this could use libudev to watch out for firmware events | 09:31 |
| pitti | (instead of the udev rule, dbus-send, and the other hackery) | 09:31 |
| tkamppeter | hp-systray can pop up a GUI program when it gets a dbus message. | 09:32 |
| pitti | 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 |
| tkamppeter | 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 |
| pitti | tkamppeter: I think hp-systray or u-m should just listen to the udev event | 09:33 |
| pitti | it's how the system is meant to work, and the most robust way without hacks | 09:33 |
| pitti | tkamppeter: correct | 09:33 |
| tkamppeter | pitti, is a daemon needed to send dbus messages? dbus-send is not a daemon. | 09:34 |
| pitti | tkamppeter: no, please drop the dbus-send stuff | 09:34 |
| pitti | 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 |
| pitti | "firmware"? | 09:34 |
| pitti | or usb, or whatever it's listening to | 09:34 |
| === MacSlow is now known as MacSlow|errand | ||
| pitti | tkamppeter: is that C or Python? | 09:35 |
| tkamppeter | 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 |
| pitti | nonononono, please no more additional python programs | 09:36 |
| seb128 | yet another python process in the session?! | 09:37 |
| pitti | tkamppeter: I thought there already was a hp-systray thing? | 09:37 |
| pitti | tkamppeter: if there is none, we can use update-notifier | 09:37 |
| pitti | it already uses gudev and listens to events | 09:37 |
| tkamppeter | Can I make somehow make use of /lib/udev/rules.d/56-hpmud_support.rules | 09:37 |
| pitti | it's dead cheap to add it there, instead of the current dbus listener | 09:37 |
| mvo | pitti++ | 09:37 |
| mvo | I'm happy to add the code for that, its pretty trivial | 09:37 |
| pitti | either to u-n, or system-config-printer | 09:38 |
| pitti | the latter runs in the session anyway, too | 09:38 |
| tkamppeter | mvo, can you chabge the src/hplip.c there, so that it listens to udev and not to dbus? | 09:38 |
| mvo | tkamppeter: sure | 09:39 |
| pitti | tkamppeter: the rule needs to be rewritten into C code, so you can use the logic of the rule | 09:39 |
| tkamppeter | 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:39 |
| pitti | 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 |
| pitti | 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 |
| pitti | but one thing at a time | 09:40 |
| tkamppeter | Important in the rule is the use of hp-mkuri, as this HPLIP utility determines whether the printer needs the plugin or not. | 09:40 |
| tkamppeter | 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:45 |
| tkamppeter | 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:46 |
| tkamppeter | 2. Is update-notifier GNOME-only? Or is it also available in Kubuntu? | 09:47 |
| pitti | tkamppeter: 2. KDE has a counterpart, but it's different code | 09:47 |
| pitti | I'm off IRC for some minutes to debug a suspend bug | 09:48 |
| tkamppeter | 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 |
| tkamppeter | pitti, mvo: This would also be better for HPLIP upstream/ | 09:49 |
| tkamppeter | pitti, are you back? | 10:05 |
| pitti | tkamppeter: yes | 10:06 |
| tkamppeter | 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:08 |
| pitti | 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:09 |
| tkamppeter | pitti, OK, I will start separating it later. | 10:10 |
| Riddell | tkamppeter: what does the code do? | 10:11 |
| tkamppeter | 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:12 |
| Riddell | 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 |
| tkamppeter | 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 |
| Riddell | an e-mail pointing at where the code is in update-notifier once it's in | 10:14 |
| tkamppeter | 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:16 |
| tkamppeter | 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 |
| Riddell | 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:18 |
| tkamppeter | 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:20 |
| tkamppeter | Riddell, so the listener is exactly the same for KDE and GNOME. | 10:21 |
| Riddell | tkamppeter: but there must be a GUI part too no? | 10:22 |
| tkamppeter | 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 |
| tkamppeter | Riddell, the GUI part is in hp-plugin-ubuntu.\ | 10:22 |
| Riddell | right | 10:22 |
| tkamppeter | 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:24 |
| Riddell | tkamppeter: so where does update-notifier come into it? | 10:25 |
| tkamppeter | Riddell, update-notifier was only used to make use of an already existing user-session daemon. The idea was not to introduce another one. | 10:47 |
| Riddell | dyfet: do we care about your plasma-widget-message-indicator upload for beta 1? | 11:03 |
| persia | 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 :) | 11:10 |
| === jussi01 is now known as o1 | ||
| === o1 is now known as jussi01 | ||
| Riddell | persia: fair point :) | 11:17 |
| Riddell | ev: on bug 534473 what's a Cruzer Micro? I get that bug on my normal CD installs | 11:18 |
| ubottu | Launchpad bug 534473 in ubiquity "Wrong CD device used when installed from a Cruzer Micro." [High,Triaged] https://launchpad.net/bugs/534473 | 11:18 |
| ev | Riddell: it's a usb disk. I think they're the same bug, regardless. | 11:18 |
| Riddell | 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 | 11:20 |
| === Klanticus_ is now known as Klanticus | ||
| ev | indeed, I hadn't realized it affected regular CD installs until you just pointed it out | 11:21 |
| ev | hrm | 11:21 |
| ev | maybe this isn't the same bug after all | 11:21 |
| ev | Riddell: did you have more than one CD inserted? | 11:21 |
| Riddell | ev: no only 1 CD | 11:22 |
| ev | yikes, okay | 11:22 |
| ev | I'll undupe your bug then | 11:22 |
| Riddell | happens on both of my machines | 11:23 |
| cjwatson | 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 |
| cjwatson | Riddell: FWIW I'm pretty sure it doesn't happen everywhere | 11:24 |
| cjwatson | 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:24 |
| cjwatson | 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 |
| cjwatson | in which case I think we could release-note it for now | 11:25 |
| Riddell | right, I don't get the problem in a virtual machine | 11:25 |
| cjwatson | I bet it depends on the exact type of CD drive | 11:26 |
| cjwatson | e.g. whether it's also DVD-capable | 11:26 |
| ev | 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:26 |
| cjwatson | I think maybe in base-installer but not in ubiquity | 11:27 |
| cjwatson | which is probably an oversight! | 11:27 |
| cjwatson | list-devices (in debian-installer-utils) certainly checks several more cases than apt-cdrom does | 11:28 |
| cjwatson | is there 'udevadm info -q all' output for one of these devices around somewhere? | 11:28 |
| cjwatson | ('udevadm info -q all -n /dev/blah') | 11:29 |
| ev | no, but I did get a udisks dump: http://launchpadlibrarian.net/40499554/udisks.txt | 11:32 |
| cjwatson | sdc? | 11:32 |
| ev | correct | 11:33 |
| ev | with sr0 being the fake cdrom for windows drivers | 11:33 |
| cjwatson | not clear from that though, or else I'm not smart enough to extract it | 11:33 |
| tkamppeter | 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. | 11:48 |
| === MacSlow|errand is now known as MacSlow | ||
| mvo | tkamppeter: for the dbus stuff or does that need to be converted to udev ? | 12:40 |
| tkamppeter | mvo, this must be converted to UDEV as I understand from our discussion. | 13:45 |
| tkamppeter | 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:46 |
| mvo | tkamppeter: if you could do the udev rule part, that would be nice, my experience there is limited | 13:49 |
| tkamppeter | pitti, can you help on the UDEV part in the C code of update-notifier? | 13:50 |
| pitti | tkamppeter: yes, but not today/tomorrow (hands full with beta stuff) | 13:50 |
| tkamppeter | pitti, mvo, so let us move it out for after the beta release. | 13:51 |
| mvo | tkamppeter: the udev C bits are no problem, the udev rule file is what I do not have a lot of experience iwth | 13:55 |
| tkamppeter | mvo, the meaning is the following: | 13:57 |
| pitti | tkamppeter: can you paste it somewhere? (I don't have it here); mvo, I'm happy to interpret it/help with tanslating to gudev | 13:58 |
| tkamppeter | 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 |
| Keybuk | pitti: I did push! | 14:01 |
| Keybuk | that branch is owned by the importer anyway - so if I hadn't pushed, it would have shown up | 14:01 |
| pitti | Keybuk: ah, -EWRONGBRANCH then | 14:02 |
| pitti | Keybuk: I'll commit it, don't worry | 14:02 |
| Keybuk | pitti: ? I used lp:ubuntu/gdm | 14:03 |
| pitti | Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/gdm/ubuntu | 14:03 |
| tkamppeter | "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 |
| tkamppeter | mvo, ^^^ | 14:03 |
| Keybuk | pitti: ah, I missed that | 14:03 |
| Keybuk | pitti: still using debian-only packaging then? | 14:03 |
| pitti | yes, for now; we'd loose all the history | 14:04 |
| pitti | (and would be stuck with a much worse performance) | 14:04 |
| Keybuk | pitti: of course, the nice thing is you can cherry-pick the change from lp:ubuntu/gdm no? | 14:05 |
| tkamppeter | 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 |
| pitti | Keybuk: I grabbed the diff from LP and committed it; all good now | 14:06 |
| Keybuk | pitti: I've never figured out how to deal with these separated debian branches | 14:06 |
| Keybuk | I can never get to the point I can build from them | 14:06 |
| pitti | Keybuk: bzr-builddeb is awesome for those | 14:07 |
| seb128 | Keybuk, bzr-buildpackage | 14:07 |
| Keybuk | still doesn't give me the source | 14:07 |
| seb128 | one command, gets the tarball and do everything for you too | 14:07 |
| seb128 | it does | 14:07 |
| pitti | it auto-downloads the orig.tar.gz, and everything | 14:07 |
| seb128 | it gets the archive one or use the watch for new versions | 14:07 |
| pitti | 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 |
| pitti | Keybuk: bzr bd -S -> build source, bzr bd -- -b -> build binaries, etc. | 14:08 |
| seb128 | bzr bd-do and edit-patch usually | 14:08 |
| Keybuk | I did use edit-patch the other day | 14:08 |
| Keybuk | kudos to mvo | 14:08 |
| pitti | 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:09 |
| mvo | pitti: ok, adding the code now | 14:10 |
| mvo | Keybuk: :) | 14:10 |
| pitti | 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:10 |
| pitti | mvo: you can just copy & paste the general listener stuff from the jockey firmware code | 14:11 |
| pitti | mvo: or, even easier, just add it to that event handler, so that we don't need two listeners :) | 14:11 |
| pitti | it's firmware either way, after all | 14:11 |
| mvo | pitti: good point | 14:11 |
| mvo | pitti: should I test for idVendor, idProduct or should it rather add a PROPERTY to look for in the udev rule file ? | 14:14 |
| mvo | pitti: and I test on that property then? | 14:14 |
| pitti | mvo: we should just drop the udev rule | 14:17 |
| pitti | mvo: just check the attribute, that's fine | 14:17 |
| mvo | aha, ok | 14:17 |
| pitti | no need to needlessly add more stuff into the chain | 14:17 |
| === sconklin-gone is now known as sconklin | ||
| mvo | tkamppeter, pitti: what is %E{ID_MODEL} ? sysfsattr, property? something else? | 14:35 |
| pitti | mvo: property | 14:35 |
| mvo | thanks | 14:35 |
| pitti | mvo: http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/GUdevDevice.html#g-udev-device-get-property | 14:36 |
| pitti | mvo: but I wonder whether hp-mkuri is actually the program that we have to call? tkamppeter? | 14:36 |
| mvo | thanks, I figured that :) | 14:36 |
| mvo | 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:37 |
| jcastro | mvo: don't forget to respond to debian squid guy at some point! | 14:39 |
| mvo | jcastro: weeh, right | 14:39 |
| mvo | 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 |
| mvo | tkamppeter: get it with lp:update-notifier and build with bzr-buildpackage to try it out | 14:52 |
| tkamppeter | mvo, got it, thank you. I am building it now. | 15:24 |
| mvo | tkamppeter: thanks, let me know about hp-mkuri -c (but feel free to just modify the code yourself) | 15:27 |
| kobrien | hi, can someone direct me to a resource describing conventions in coding C for ubuntu if there are any? | 15:43 |
| Keybuk | kobrien: there aren't any | 15:45 |
| Keybuk | 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 |
| Keybuk | (actually, they're probably as good a guide as any - at least to building. ie. your project should use autoconf + automake, etc.) | 15:46 |
| === highvolt1ge is now known as highvoltage | ||
| ev | 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 |
| ubottu | Launchpad bug 538505 in ubiquity "Extremely slow reponsiveness / high CPU usage" [High,Confirmed] https://launchpad.net/bugs/538505 | 15:55 |
| Riddell | ev: I've not seen that issue (and I've done quite a few installs today) | 15:57 |
| ev | Riddell: odd, I can reproduce it in KVM and on real hardware | 15:57 |
| Riddell | ev: I'm more worried about https://launchpad.net/bugs/540275 currently | 15:58 |
| ubottu | Ubuntu bug 540275 in ubiquity "Installing in French breaks the keyboard setup page" [Undecided,New] | 15:58 |
| ev | gah | 16:01 |
| === binarylooks is now known as binarylooks_away | ||
| Riddell | 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:02 | |
| ev | Riddell: cool, thanks | 16:03 |
| Riddell | fish shaking is the wrong approach I'm sure, intravenous irn bru would work much better | 16:03 |
| Riddell | umm, fist shaking :) | 16:03 |
| shtylman_ | ev Riddell :) | 16:05 |
| shtylman_ | life is boring without bugs | 16:06 |
| shtylman_ | 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:07 |
| tkamppeter | 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). | 16:14 |
| === beuno is now known as beuno-lunch | ||
| tseliot | Riddell: do you know where debug() (e.g. server.c) in kdm writes to? | 16:17 |
| tseliot | i.e. to what log file | 16:17 |
| Riddell | tseliot: /var/log/kdm.log ? | 16:17 |
| tseliot | Riddell: ok, thanks | 16:18 |
| mvo | tkamppeter: sweet, once its ready let me know and I merge/upload | 16:19 |
| mvo | tkamppeter: thanks! | 16:19 |
| === yofel_ is now known as yofel | ||
| === binarylooks_away is now known as binarylooks | ||
| tkamppeter | mvo, first bug: in on_uevent() it must read | 16:28 |
| tkamppeter | if (g_strcmp0 (action, "add") != 0 && g_strcmp0 (action, "change") != 0) | 16:28 |
| tkamppeter | (&& and not ||) | 16:28 |
| tkamppeter | 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:29 |
| kobrien | Keybuk: cheers, I use the gnu standards as it is. cool | 16:30 |
| mvo | tkamppeter: aha, sorry. I think its not properly checking the return code of hp-mkuri, let me fix that | 16:30 |
| tkamppeter | 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 |
| mvo | tkamppeter: ok, fixing ths now | 16:31 |
| tkamppeter | mvo, I added if (ret != 2 && ret != 5) return TRUE; before calling the firmware installer. | 16:31 |
| tkamppeter | 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 |
| mvo | tkamppeter: it needs to be converted via WEXITSTATUS() | 16:33 |
| tkamppeter | mvo: 512/256 = 2, is the conversion shifting ret by 8 bits to the right? | 16:34 |
| mvo | tkamppeter: man waitpid has the info, its available via the macro WEXITSTATUS() | 16:36 |
| tkamppeter | mvo, thanks, trying WEXITSTATUS(ret) ... | 16:36 |
| mvo | tkamppeter: or run bzr up | 16:37 |
| mvo | tkamppeter: I added your fixes to my branch | 16:37 |
| mvo | (including this one) | 16:37 |
| kees | lool: cool, thanks. if anything goes really weird in mind rootfs, I can compare it to yours. | 16:45 |
| cjwatson | Keybuk: so, do we know that it's definitely on 'plymouth deactivate', rather than in ply_terminal_close? | 16:51 |
| Keybuk | sorry, not following your question | 16:51 |
| cjwatson | I'm grepping for paths that call ply_terminal_set_buffered_input | 16:51 |
| cjwatson | there seem to be two, and I was wondering if we'd confirmed which one | 16:52 |
| Keybuk | set_buffered_input should be guarded | 16:52 |
| Keybuk | the one in ply_terminal_close() should return without doing anything because it's called in the deactivate path | 16:52 |
| Keybuk | what has happened before is that we ended up with a ply_terminal_set_unbuffered_input() between those two | 16:52 |
| Keybuk | so ply_terminal_close() set buffered again | 16:52 |
| Keybuk | that was caused, amongst other things, by the fact every damned terminal write did it <g> | 16:53 |
| tkamppeter | mvo, it is working now, do you need a patch? | 16:53 |
| tseliot | cjwatson: any ideas as to what can be causing this code to exit with return code 10 ? http://pastebin.ubuntu.com/396800/ | 16:55 |
| cjwatson | I'm not following where the guard is | 16:55 |
| cjwatson | but if this is boring, feel free to tell me and I'll stop pursuing it | 16:55 |
| cjwatson | tseliot: have you used DEBCONF_DEBUG=developer? | 16:55 |
| mvo | tkamppeter: plesae check if trunk/ works correctly, if it does we are good, otherwise I need the patch | 16:55 |
| mvo | tkamppeter: I fixed the bits you mentioned | 16:55 |
| tseliot | cjwatson: well, I can't reproduce the problem here. A user reproduced it when he was updating the kernel | 16:56 |
| cjwatson | 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 |
| cjwatson | tseliot: best ask them for that information | 16:56 |
| tkamppeter | mv, I see you have already committed the correct version. Can you upload the package? I will update the HPLIP package. | 16:56 |
| tseliot | ok, thanks | 16:56 |
| cjwatson | tseliot: 10 can mean various things, I don't see anything blindingly obvious | 16:56 |
| tseliot | me neither | 16:57 |
| cjwatson | tseliot: it means "bad parameters" in general | 16:57 |
| Keybuk | cjwatson: I have a CD with a plymouth installed that has -g -O0 no stripped and the source code in the right place :p | 16:57 |
| cjwatson | it's like EINVAL | 16:57 |
| Keybuk | I'm hoping this will help | 16:57 |
| cjwatson | but, it typically comes with more information in the debconf debug output | 16:58 |
| === beuno-lunch is now known as beuno | ||
| tseliot | cjwatson: ok, there must be something else that triggers this (as DKMS used to do). I'll ask the user to try again with that variable | 16:58 |
| tseliot | thanks | 16:58 |
| tkamppeter | mvo, stop, as expected, it does not work, I will tell you what needs to be changed ... | 16:58 |
| mvo | tkamppeter: ok | 16:59 |
| tseliot | cjwatson: it looks like that we have that kind of information already: http://pastebin.ubuntu.com/396803/ | 17:01 |
| tseliot | well, I don't know if it's the same as debconf debug | 17:01 |
| cjwatson | tseliot: that'll do, and there you go, it tells you the problem | 17:02 |
| cjwatson | DEBCONF_DEBUG=developer is less noisy for the same effect, but | 17:02 |
| cjwatson | + RET='10 nvidia-common/obsolete doesn'\''t exist' | 17:02 |
| tkamppeter | mvo, sorry, when I updated yourt code got mixed up with my code. Now I have reloaded your code and it works. Upload the package exactly as you have it in your repo. | 17:02 |
| dmart | Does anyone know how to enable debug on a network interface in Ubuntu? | 17:03 |
| mvo | tkamppeter: thanks for the fixes and the tests, I will do the upload now | 17:03 |
| tkamppeter | mvo, does you new code also cover cold-plugging (printer is already connected and turned on before update-notifier starts)? | 17:03 |
| tseliot | cjwatson: yes, I noticed that but I don't understand why it's happening | 17:03 |
| dmart | BSD's ifconfig has a "debug" option, but Ubuntu's ifconfig doesn't seem to support this. Currently I needed to write my own tool to set IFF_DEBUG on an interface... | 17:04 |
| mvo | tkamppeter: no, not yet, shall we wait on this? I guess so, I can work on this after dinner or tomorrow | 17:04 |
| zyga | mvo: I want to start filing bugs on each ubuntu package that is using the update-alternatives comment in any script | 17:05 |
| cjwatson | tseliot: well, it just means that it isn't in the template database, which probably means the package that provides that template isn't installed yet (or is doing something mad) | 17:05 |
| zyga | mvo: I want to make a blueprint on adding more metadata to debian packages to indicate all possible update-alternatives that a package install script might perform | 17:05 |
| zyga | mvo: does this sound insane or should I go ahead with this project? | 17:05 |
| kees | slangasek: as samba maintainer, what do you think of upstream's recent change: http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=bd269443e311d96ef495a9db47d1b95eb83bb8f4 | 17:05 |
| kees | slangasek: if we backport this, wide links would be disabled by default, which could break poeple using them. | 17:06 |
| kees | slangasek: but it closes the CVE-2010-0926 hole | 17:06 |
| ubottu | The default configuration of smbd in Samba before 3.3.11, 3.4.x before 3.4.6, and 3.5.x before 3.5.0rc3, when a writable share exists, allows remote authenticated users to leverage a directory traversal vulnerability, and access arbitrary files, by using the symlink command in smbclient to create a symlink containing .. (dot dot) sequences, related to the combination of the unix extensions and wide links options. (http://cve.mitre.org/cgi-bin/cvena | 17:06 |
| Riddell | ev, shtylman_: I do see CPU at 90% now I look at top while ubiquity is running :( | 17:06 |
| shtylman_ | Riddell: it pains me to hear these things :( | 17:06 |
| tseliot | cjwatson: I think nvidia-common was already installed (and I call debconf in the postinst anyway) as in this case its postinst was called by a kernel hook | 17:07 |
| tseliot | maybe something removed the template? | 17:07 |
| tseliot | BTW it's bug #533970 | 17:08 |
| ubottu | Launchpad bug 533970 in linux "package linux-image-2.6.31-20-generic 2.6.31-20.57 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/nvidia-common exited with return code 10" [Undecided,Confirmed] https://launchpad.net/bugs/533970 | 17:08 |
| === RoAk is now known as RoAkSoAx | ||
| cjwatson | tseliot: I don't know, you're probably better-equipped to take it from here than I am TBH as you know those packages better | 17:08 |
| cjwatson | debconf is just reporting the condition | 17:08 |
| slangasek | kees: omitting the loadparm.c change would at least mitigate the user impact; widelinks would still be disabled by default *because* unix extensions are on by default, but anyone who's turned off unix extensions will have widelinks ok | 17:09 |
| tseliot | cjwatson: ok, thanks | 17:09 |
| cjwatson | sorry | 17:09 |
| slangasek | kees: fwiw, as maintainer my answer to the bug reporter was "fixed in unstable, not screwing around with stable for this unless the security team asks me to" | 17:09 |
| mdeslaur | slangasek, kees: that's not the commit I was looking at, hold on | 17:09 |
| kees | mdeslaur: oh? that's what was tied to the CVE | 17:10 |
| mdeslaur | oh, yes it was | 17:10 |
| mdeslaur | please ignore me, like usual :) | 17:10 |
| mvo | zyga: sounds good, ideally we would make it a declarative think and not part of maintainer scripts. but metadata is a start | 17:11 |
| mdeslaur | slangasek, kees: it was further improved with http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=16e73d88944ce644cccfa19a99338f5903c061f0 | 17:11 |
| zyga | mvo: not part of the scripts, part of control file | 17:11 |
| zyga | like x-provides-alternavies: xxx, yyy | 17:11 |
| kees | slangasek: but that's just a small subset. the people we're worried about are those using both wide links and unix extensions. | 17:11 |
| slangasek | kees: well, I don't think most people are *using* wide links, I think they just unwittingly have them enabled | 17:13 |
| slangasek | so I'm not sure how bad the impact on users would really be | 17:13 |
| slangasek | but as I said, I'm not pushing to make this change in lenny | 17:13 |
| * kees nods | 17:13 | |
| mdeslaur | slangasek: so, you're okay with everyone inadvertently sharing the whole filesystem in lenny? | 17:14 |
| kees | slangasek: the problem is that it allows (DAC-limited) arbitrary file read from the server if a user has the ability to create symlinks | 17:14 |
| mdeslaur | there's a cool metasploit module for it :) | 17:14 |
| cjwatson | w/wg 47 | 17:15 |
| cjwatson | dok | 17:15 |
| zyga | mvo: great, I assume I have your backing on this, I'll patch the harvester to support this and add this as a proof of concept to selected package, if it wokrs I'll draft a blueprint for review | 17:16 |
| slangasek | mdeslaur: there are no public shares by default, users are discouraged from running Internet-facing samba servers; and as kees says it's DAC-limited. Vs. suddenly breaking things for users who are intentionally using wide links, yeah, I'm ok with that | 17:16 |
| slangasek | expecting your authenticated users to not be able to read world-readable files on the server just because they're not shared via SMB is right up there with expecting PHP safe mode to work, I think | 17:18 |
| mdeslaur | slangasek: well, by "everyone", I meant "everyone who set up a corporate file server" :) | 17:18 |
| tseliot | cjwatson: just to double check, the template should be /var/lib/dpkg/info/$package_name.templates, right? (it's /var/lib/dpkg/info/nvidia-common.templates in my case) | 17:19 |
| mdeslaur | slangasek: huh? I would assume most people who are running a samba file server don't let their users log into the box... | 17:19 |
| kees | slangasek: I think samba shares are held to a higher standard that php safe mode. :P | 17:19 |
| cjwatson | tseliot: yes, though something needs to arrange to load that; see debconf-devel(7) | 17:19 |
| cjwatson | tseliot: does nvidia-common ship a config file? | 17:20 |
| tseliot | cjwatson: no, it doesn't anymore | 17:20 |
| slangasek | mdeslaur, kees: my point is that I don't regard it as privilege escalation. But you guys do what you think is best.:) | 17:20 |
| kees | slangasek: okay, cool, thanks. | 17:20 |
| mdeslaur | slangasek: ok, our samba update will disable php, thanks for your input :) | 17:21 |
| tseliot | cjwatson: I got rid of the config file and moved the logic into the postinst as you suggested: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/nvidia-common/lucid/revision/23 | 17:23 |
| cjwatson | tseliot: hm, right, so it's possible the templates file hasn't been loaded yet if the template is being used from places other than the postinst file, as you indicate | 17:24 |
| tseliot | oh | 17:24 |
| cjwatson | tseliot: I think the best option would be to add a config script that is simply as follows: | 17:24 |
| cjwatson | #! /bin/sh | 17:24 |
| cjwatson | . /usr/share/debconf/confmodule | 17:24 |
| cjwatson | exit 0 | 17:24 |
| cjwatson | that will cause debconf to load that templates file up-front | 17:25 |
| cjwatson | might want a comment as well to explain why it exists :-) | 17:25 |
| cjwatson | this is a bit of a gotcha, it's bitten me as well in the past. the way debconf arranges to load templates at the right time is known-hackish | 17:25 |
| tseliot | cjwatson: sure, I'll do that, thanks | 17:25 |
| mathiaz | jelmer: hi - I was trying to run bzr update on a remote git repository: http://paste.ubuntu.com/396819/ | 17:30 |
| mathiaz | jelmer: ^^ is this a known bug? | 17:30 |
| jelmer | mathiaz: Hi | 17:31 |
| jelmer | mathiaz: Yep, it's a known bug - seems to be caused by a newer version of python that's now in Lucid | 17:31 |
| cjwatson | Keybuk: I have the strace if it's any use, though I suspect it isn't | 17:31 |
| jelmer | mathiaz: It's been fixed in bzr-git trunk, but I haven't had the time to upload new packages to Debian/Ubuntu yet (at a sprint atm) | 17:31 |
| mathiaz | jelmer: great than - is there a workaround for now (or a bug number)? | 17:31 |
| mathiaz | jelmer: ok - I'll look at the bzr-git trunk and fix it locally then | 17:32 |
| Keybuk | cjwatson: please | 17:32 |
| Keybuk | because right now, I'm about to say "it's not plymouth" | 17:32 |
| cjwatson | I can see a few TCSETS at the end | 17:33 |
| mathiaz | jelmer: is the fix revision 743? | 17:33 |
| jelmer | mathiaz: yeah, sorry about the uninformative commit message | 17:33 |
| cjwatson | strace doesn't tell me details | 17:33 |
| cjwatson | Keybuk: attached to bug 540256 | 17:33 |
| ubottu | Launchpad bug 540256 in plymouth "enter kills X when booting with text plugin" [High,Confirmed] https://launchpad.net/bugs/540256 | 17:33 |
| Keybuk | huh | 17:34 |
| Keybuk | ok, well | 17:34 |
| Keybuk | I just traced every line of plymouth | 17:34 |
| Keybuk | and it did not fail | 17:34 |
| Keybuk | but enter doesn't kill X either | 17:34 |
| cjwatson | oh, strace does tell me, I'm just being dim | 17:35 |
| cjwatson | 273 17:29:05.425303 ioctl(8, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0 | 17:35 |
| cjwatson | Keybuk: there's a SIGWINCH terminal change right beforehand. I have to say that this looks very much like it's in ply_terminal_close | 17:35 |
| Keybuk | yes, but it can't be | 17:36 |
| Keybuk | there's a great big guard at the top | 17:36 |
| Keybuk | SIGWINCH though => hmmmmm | 17:36 |
| Keybuk | why would you have SIGWINCH?! | 17:36 |
| Keybuk | let me talk myself through the strace for a minute | 17:36 |
| Keybuk | 273 17:28:25.803402 read(7, "D\0", 2) = 2 | 17:36 |
| Keybuk | ^ received deactivate | 17:37 |
| cjwatson | it's not receiving SIGWINCH, it's ditching its handler for it | 17:37 |
| === binarylooks is now known as binarylooks_away | ||
| Keybuk | 273 17:28:25.815653 rt_sigaction(SIGUSR1, {SIG_DFL, [USR1], SA_RESTART}, {0x6df710, [USR1], SA_RESTART}, 8) = 0 | 17:37 |
| Keybuk | 273 17:28:25.815938 rt_sigaction(SIGUSR2, {SIG_DFL, [USR2], SA_RESTART}, {0x6df710, [USR2], SA_RESTART}, 8) = 0 | 17:37 |
| Keybuk | 273 17:28:25.816149 ioctl(8, VIDIOC_ENUM_FMT or VT_SETMODE, 0xbfbfbe38) = 0 | 17:37 |
| Keybuk | restore VT back to VT_AUTO | 17:37 |
| Keybuk | (and stop watching the signals) | 17:37 |
| Keybuk | 273 17:28:25.816299 ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 | 17:37 |
| Keybuk | put terminal back into Canonical Mode | 17:37 |
| Keybuk | 273 17:28:25.816633 write(7, "\6", 1) = 1 | 17:38 |
| Keybuk | done | 17:38 |
| Keybuk | right | 17:38 |
| Keybuk | so that looksok | 17:38 |
| cjwatson | and X starts at 17:28:26, according to its log file | 17:38 |
| cjwatson | and will presumably switch back to raw mode | 17:38 |
| Keybuk | 273 17:28:25.842325 read(7, "V\0", 2) = 2 | 17:38 |
| Keybuk | 273 17:28:25.842451 write(7, "\6", 1) = 1 | 17:38 |
| Keybuk | do we have an active vt? => yes | 17:39 |
| Keybuk | lots of polling, times and an occasional update of the screen while we wait for X to start | 17:39 |
| Keybuk | ok | 17:40 |
| Keybuk | no ioctl in that lot | 17:40 |
| Keybuk | now | 17:40 |
| Keybuk | 273 17:29:05.412303 read(7, "Q\2", 2) = 2 | 17:40 |
| Keybuk | that's "quit" | 17:40 |
| Keybuk | so X is up, gdm wants us to leave | 17:40 |
| Keybuk | looks like it's with --retain-splash given the \1\0 | 17:40 |
| Keybuk | 273 17:29:05.412435 read(7, "\1\0", 2) = 2 | 17:40 |
| Keybuk | 273 17:29:05.424512 ioctl(8, PIO_CMAP, 0x82a88f0) = 0 | 17:41 |
| Keybuk | reset the colour map | 17:41 |
| Keybuk | (so vts don't stay purple forever) | 17:41 |
| Keybuk | 273 17:29:05.425021 rt_sigaction(SIGWINCH, {SIG_DFL, [WINCH], SA_RESTART}, {0x6df710, [WINCH], SA_RESTART}, 8) = 0 | 17:41 |
| Keybuk | 273 17:29:05.425141 ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0 | 17:41 |
| Keybuk | 273 17:29:05.425227 ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0 | 17:41 |
| Keybuk | 273 17:29:05.425303 ioctl(8, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0 | 17:41 |
| Keybuk | 273 17:29:05.425394 ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 | 17:41 |
| Keybuk | and | 17:41 |
| Keybuk | like you say | 17:41 |
| Keybuk | restore SIGWINCH | 17:41 |
| cjwatson | (I'm rebuilding plymouthd with --enable-tracing) | 17:41 |
| Keybuk | then fuck around with the console mode | 17:41 |
| Keybuk | and | 17:42 |
| Keybuk | like you say | 17:42 |
| Keybuk | this must be ply_terminal_close | 17:42 |
| Keybuk | we did each of those steps | 17:42 |
| Keybuk | we restored the colour palette | 17:42 |
| Keybuk | we removed the epoll watch on the tty fd | 17:43 |
| Keybuk | we removed the signal for SIGWINCH | 17:43 |
| Keybuk | then ply_terminal_set_buffered_input () gets called | 17:43 |
| Keybuk | the first ioctl is TCGETS | 17:43 |
| Keybuk | so that's the "get current terminal attributes" | 17:43 |
| cjwatson | the guard at the top of ply_terminal_close is "has ply_terminal_close already been called?" | 17:43 |
| Keybuk | it doesn't have ICANON | 17:43 |
| Keybuk | so we don't return | 17:43 |
| cjwatson | and AFAICS deactivate doesn't close the terminal? | 17:44 |
| cjwatson | quit_splash, OTOH, does | 17:44 |
| Keybuk | then we restore terminal settings | 17:44 |
| Keybuk | so right | 17:44 |
| Keybuk | this looks like we went through ply_terminal_set_buffered_input | 17:44 |
| Keybuk | and reset the terminal back to Canonical Mode because X reset it to Raw Mode | 17:44 |
| Keybuk | -- | 17:44 |
| Keybuk | no | 17:44 |
| Keybuk | the guard at the top of ply_terminal_set_buffered_input | 17:45 |
| Keybuk | if (!terminal->is_unbuffered) | 17:45 |
| Keybuk | return true; | 17:45 |
| Keybuk | clearly that must be false | 17:45 |
| Keybuk | is_unbuffered starts false | 17:45 |
| Keybuk | it's set to true by ply_terminal_set_unbuffered_input | 17:45 |
| cjwatson | is it definitely the same ply_terminal_t? | 17:45 |
| Keybuk | and set to false by ply_terminal_set_buffered_input | 17:45 |
| Keybuk | should be state->terminal yeah | 17:46 |
| Keybuk | ohhhhh | 17:47 |
| Keybuk | hmmm | 17:47 |
| Keybuk | look at the deactivate ioctl | 17:48 |
| Keybuk | 273 17:28:25.816299 ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 | 17:48 |
| Keybuk | ... | 17:48 |
| Keybuk | the terminal was *already* ICANON | 17:48 |
| Keybuk | something reset the terminal to Canonical Mode under plymouth! | 17:48 |
| cjwatson | er, are we looking at the same one? | 17:48 |
| Keybuk | scroll up | 17:48 |
| cjwatson | oh I see what you mean | 17:49 |
| Keybuk | so when deactivate was called | 17:49 |
| Keybuk | we went into ply_terminal_set_buffered_input | 17:49 |
| Keybuk | that did a tcgetattr (that ioctl) | 17:49 |
| Keybuk | and was informed that the terminal was already in canonical mode | 17:49 |
| Keybuk | now look at the code ... | 17:49 |
| Keybuk | set_buffered_input returns at that point | 17:49 |
| Keybuk | and *never* resets terminal->is_unbuffered | 17:49 |
| Keybuk | so when we call the same function in ply_terminal_close ... the guard is wrong | 17:50 |
| cjwatson | right, so we could work around this by updating the state flag there, but we need to know what's fiddling with the console | 17:50 |
| Keybuk | so that tries again harder to set the terminal into buffered mode | 17:50 |
| Keybuk | and since X has reset it back to raw mode since then | 17:50 |
| Keybuk | plymouth helpfully resets it back | 17:50 |
| Keybuk | we do yes | 17:50 |
| cjwatson | console-setup might be the obvious culprit, but it's really careful to touch only tty[1-6] | 17:50 |
| Keybuk | since if the terminal is in Canonical Mode under plymouth - then input and stuff doesn't work | 17:50 |
| cjwatson | 'zactly | 17:50 |
| Keybuk | and this explains why, when I stopped and restarted plymouth | 17:51 |
| Keybuk | I couldn't replicate the problem | 17:51 |
| Keybuk | it obviously happens relatively early in the boot sequence | 17:51 |
| cjwatson | just a silly question, but | 17:52 |
| cjwatson | it isn't upstart is it? | 17:52 |
| cjwatson | that would explain the difference between a boot with plymouth in the initramfs (live CD) and one without (most installed systems) | 17:52 |
| Keybuk | I was just thinking the same thing | 17:52 |
| cjwatson | system_setup_console sets ICANON on whatever /dev/console is, which would be the foreground console, right? | 17:52 |
| Keybuk | yes | 17:52 |
| Keybuk | so | 17:53 |
| Keybuk | putting plymouth in the initramfs, and rebooting | 17:53 |
| Keybuk | should replicate this on any machine | 17:53 |
| lucas | Is it normal to wait almost a week for syncs to be processed? should I upload fake syncs instead when I need the package in ubuntu ASAP? | 17:55 |
| cjwatson | lucas: during beta freeze, yes it is. what's the bug? | 17:55 |
| cjwatson | +number | 17:55 |
| lucas | #538271 | 17:55 |
| cjwatson | it's in main, but not AFAICT on CDs | 17:56 |
| * cjwatson greps just to make sure | 17:56 | |
| cjwatson | no, that's on the server CD | 17:57 |
| cjwatson | which is currently final for beta-1 and isn't due a respin (yet ...) | 17:57 |
| lucas | ok, I see | 17:58 |
| cjwatson | lucas: can this wait until after beta-1? it should only be a day or so now | 17:58 |
| cjwatson | I can make sure to do it ASAP after that | 17:58 |
| lucas | cjwatson: it can, it's just that I would like to get as much testing in ubuntu as possible | 17:58 |
| cjwatson | or is there a strong reason why it should be specifically in beta-1? | 17:58 |
| Keybuk | cjwatson: confirmed, setting FRAMEBUFFER=y on a normal machine does the same thing | 17:59 |
| cjwatson | mathiaz: ^- (can't see ttx), what do you think? | 17:59 |
| cjwatson | if we need to rev upstart, we might well need to respin everything - this bug would break cryptsetup on a server system, for example | 17:59 |
| mathiaz | cjwatson: bug 538271? | 17:59 |
| lucas | cjwatson: well, puppet apparently breaks with the current ruby1.8 version. it's probably not major enough to rebuild the server CD. | 17:59 |
| ubottu | Launchpad bug 538271 in ruby1.8 "Sync ruby1.8 1.8.7.249-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/538271 | 17:59 |
| cjwatson | mathiaz: yes | 17:59 |
| mathiaz | cjwatson: right - I don't think it's worth respinning an iso for beta1 | 18:00 |
| cjwatson | do you have test cases for puppet? | 18:00 |
| mathiaz | cjwatson: not yet | 18:00 |
| cjwatson | perhaps we can address lucas' concerns by making sure that's explicitly and formally tested for beta-2? | 18:00 |
| cjwatson | at least partially address, anyway | 18:00 |
| mathiaz | cjwatson: yes - that's the plan | 18:00 |
| lucas | cjwatson: well by testing I mean user testing. | 18:00 |
| mathiaz | cjwatson: we're planning more QA testing on puppet later | 18:01 |
| lucas | cjwatson: the original bug is a random+obscure hang | 18:01 |
| mathiaz | cjwatson: as far as beta1 is concerned I don't it's worth a respin | 18:01 |
| highvoltage | lamont: hi, are you around? | 18:01 |
| mathiaz | cjwatson: I don't *think* it's worth a respin | 18:02 |
| cjwatson | mathiaz: how about the upstart/plymouth bug in scrollback above? | 18:02 |
| cjwatson | well, upstart's involvement is still conjectural but seems likely at this point | 18:02 |
| mathiaz | lucas: does that seem reasonable to you (sync ruby after beta1 is released)? | 18:02 |
| Keybuk | cjwatson: no, it is upstart | 18:02 |
| Keybuk | I just commented out that code, and rebooted | 18:02 |
| Keybuk | now enter doesn't kill X | 18:02 |
| cjwatson | excellent | 18:03 |
| lucas | mathiaz: yes | 18:03 |
| Keybuk | cjwatson: I'm just trying to work out why that code is even there | 18:03 |
| cjwatson | lucas: sorry we didn't catch this earlier, it was probably just at the start of beta freeze | 18:03 |
| Keybuk | I think it's a case of "sysvinit did it" | 18:03 |
| mathiaz | cjwatson: bug https://launchpad.net/bugs/540256? | 18:04 |
| ubottu | Ubuntu bug 540256 in plymouth "enter kills X when booting with text plugin" [High,Confirmed] | 18:04 |
| cjwatson | Keybuk: mm, doesn't the kernel set sane defaults? (or does it, I'm not sure I trust the vt code to do anything ...) | 18:04 |
| lucas | cjwatson: np | 18:04 |
| cjwatson | mathiaz: yes | 18:04 |
| Keybuk | cjwatson: I'm just reviewing that now | 18:04 |
| cjwatson | mathiaz: don't go solely by the bug summary though; 17:50 <Keybuk> since if the terminal is in Canonical Mode under plymouth - then input and stuff doesn't work | 18:04 |
| Keybuk | Canonical Mode being Purple ;-) | 18:04 |
| mathiaz | cjwatson: ok - let me catch up on the bug | 18:04 |
| highvoltage | heh, that explains why my X session was killed on the livecd when I typed 'sudo -s' (I didn't expect it to be the actual enter key that did it :) ) | 18:05 |
| cjwatson | mathiaz: I think the practical impact on server is that if you are using cryptsetup (and so the initramfs is built with FRAMEBUFFER=yes) then neither fsck nor cryptsetup will/may be able to accept input | 18:05 |
| cjwatson | highvoltage: right, that's roughly where we came in, it's just taken all day to narrow it down | 18:05 |
| Keybuk | well, it took all afternoon to narrow it down | 18:05 |
| Keybuk | it took until then to wait for me to get out of bed :p | 18:05 |
| cjwatson | I was working on it in the morning too, just less competently :-) | 18:06 |
| mathiaz | cjwatson: so the impact is limited to cryptsetup server installation? | 18:06 |
| cjwatson | mathiaz: I think so, I can't think of other situations where you get an initramfs with FRAMEBUFFER=yes on server? | 18:06 |
| cjwatson | perhaps somebody can verify that from more reliable memory | 18:06 |
| highvoltage | well, thanks to both of you for getting out of bed today :) | 18:07 |
| Keybuk | the two things that I know that set that are cryptsetup and casper | 18:07 |
| cjwatson | I get rousted out of sleep at god-awful-o-clock by a small child | 18:07 |
| cjwatson | doesn't matter when I went to bed | 18:07 |
| highvoltage | heh | 18:07 |
| Keybuk | right | 18:07 |
| Keybuk | I'm going to take a few minutes to collect state | 18:07 |
| Keybuk | not to mention update the bug | 18:08 |
| cjwatson | I'm going to leave at this point, as I'm due elsewhere. Please SMS / google-talk me if I need to log in and poke the publisher or whatever, and I can do that | 18:08 |
| mathiaz | cjwatson: I think it's *not* worth a -server iso respin for the plymounth/upstrart bug | 18:09 |
| dahud | How far do I need to get in my education before I can begin to understand and work on Ubuntu? Are there some lower-level tasks to be done? | 18:09 |
| mathiaz | cjwatson: given that it only affects cryptsetup installations | 18:09 |
| Keybuk | cjwatson: I can do that ;) | 18:09 |
| cjwatson | mathiaz: OK, that will probably help matters, thanks | 18:09 |
| highvoltage | dahud: reading https://wiki.ubuntu.com/ContributeToUbuntu and its sub pages will give you some idea | 18:10 |
| dahud | highvoltage: Thanks | 18:10 |
| highvoltage | dahud: anyone can with enough work and patience | 18:10 |
| cjwatson | dahud: there's e.g. https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize - but personally my advice has always been to find something that annoys you personally and seems like it ought not to be too hard, grab the code, and read through it until you've figured out how to fix it | 18:11 |
| cjwatson | dahud: repeat a couple of hundred times :-) | 18:11 |
| === binarylooks_away is now known as binarylooks | ||
| cjwatson | and then if you're (un)lucky you end up maintaining it ... | 18:11 |
| psusi | say has any thought been given to disabling partition detection in the kernel and moving it to udev with partx? I can't find any mention of it on the wik or -devel archive | 18:12 |
| Keybuk | psusi: look in lkml | 18:12 |
| cjwatson | IME working on things that other people have listed tends to be less fulfilling | 18:12 |
| dahud | OK. Another question: what IDE do you all use? | 18:12 |
| zyga | dahud: I don't want to repeat anything everyone else said but basically most of the stuff depends on your ability to read/write code, many people can contribute without that feature | 18:12 |
| cjwatson | dahud: you'll get a wide variety of answers, but many experienced long-term Ubuntu developers just use an advanced editor (vim or emacs) plus command-line tool | 18:13 |
| cjwatson | s | 18:13 |
| cjwatson | obviously there are IDEs available as well | 18:13 |
| dahud | I mainly want the practice working with real code | 18:13 |
| === sconklin is now known as sconklin-gone | ||
| Keybuk | cjwatson: oh I wonder | 18:14 |
| Keybuk | you know that whole plymouth-can't-catch-enter thing? | 18:14 |
| Keybuk | could that be because Enter looks a lot like SIGQUIT to plymouth too ? | 18:14 |
| Keybuk | or is this while still in casper? | 18:15 |
| cjwatson | that's on shutdown, I think | 18:15 |
| zyga | dahud: if you can read (x10) and write (x1) c/python you have access to vast majority of stuff around ubuntu :-), still - please read that wiki first | 18:15 |
| Keybuk | ah, ok | 18:15 |
| Keybuk | so a new plymouth | 18:15 |
| cjwatson | well, at least one of the instances is | 18:15 |
| psusi | Keybuk: as an experiment I just tried using fdisk to add a new partition and the re-read ioctl fails since another partition is in use, but partx -a has no problem adding the new partition... I might have to look into getting gparted to use that | 18:15 |
| cjwatson | IIRC there's a problem with CD checking too, which is on startup | 18:15 |
| Keybuk | that's while within the initramfs though, right? | 18:16 |
| cjwatson | good point, yes it is | 18:17 |
| cjwatson | anyway, really gone | 18:17 |
| psusi | damn... my search is turning up zero instances of partx on lkml... | 18:22 |
| ogra | Keybuk, apparently the crash is already reported as bug 537262 and the flickering isnt reproducable on subsequent boots anymore | 18:39 |
| ubottu | Launchpad bug 537262 in plymouth "plymouth pid missing from OMITPIDS and terminated by sendsigs" [High,Confirmed] https://launchpad.net/bugs/537262 | 18:39 |
| Keybuk | that's not a crash then, is it? :p | 18:40 |
| ogra | well, it triggers apport | 18:40 |
| ev | Riddell: confirmed and fixed | 18:54 |
| ev | I'll do an upload now | 18:54 |
| Riddell | ev: ooh | 18:57 |
| Riddell | ev: so I was too quick to defame shtylman_? | 18:57 |
| ev | we both were :) | 18:57 |
| ev | I fixed this bug in console-setup at the sprint | 18:57 |
| ev | but forgot to port it over to ubiquity | 18:57 |
| Riddell | I always knew shtylman_ was unimpeachable | 18:58 |
| shtylman_ | Riddell ev: :) | 19:00 |
| ev | lol | 19:01 |
| === radoe_ is now known as radoe | ||
| mvo | Keybuk: i see this at boot now: "Your disk drives need to be checked for error, this may take some time " \o/ -- last week there was only a [C] :) | 19:42 |
| jdong | is there a way to convince apport not to do dupe checking when filing bugs? | 19:43 |
| jdong | in a telepathy-butterfly bug, it's pretty certain that a user's getting a TypeError crash on a different codepath as the bug that apport claims is a dupe | 19:43 |
| jdong | and the user claims apport refuses to allow him to submit a new bug report, saying the bug is already reported at the bug opened in the web browser? | 19:44 |
| lamont | highvoltage: am now | 19:48 |
| ScottK | doko: All the Main stuff that was broken due to qt4-x11 on IA64 is built now. Thanks for taking care of it. | 19:56 |
| chrisccoulson | jdong - it's likely that the bug pattern needs editting | 19:57 |
| * ScottK wants apport --please-for-the-love-of-god-let-me-file-this-bug | 19:57 | |
| chrisccoulson | jdong - try checking here: http://bazaar.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns/annotate/head%3A/telepathy-butterfly.xml | 19:58 |
| chrisccoulson | it's quite possible that the submitters bug inadvertently matches an existing pattern. If that's incorrect, then the pattern needs fixing | 19:59 |
| slangasek | jdong: if the new bug is being refused, a bug pattern is set for it server-side; you'd need to have pitti change the bug pattern (maybe someone else has access, but I don't know who) | 19:59 |
| micahg | slangasek: bug control should have access to the patterns | 20:00 |
| micahg | so devs included | 20:00 |
| chrisccoulson | i just pointed a link to the telepathy-butterfly patterns :) | 20:00 |
| micahg | I don't know offhand how often they update | 20:00 |
| slangasek | micahg: well, I can guarantee that not all of bug control has a clue where to set them :) | 20:00 |
| thopiekar | hi .I'm a member of the Canola project and atm almost the only person working on Canola.. I need more people here at #canola to improve the code.. the player is great and many plugins are available.. please help. the developters that where working on it in the past were paied to work on it - now they have other priorities so - we need you! | 20:16 |
| * Keybuk has returned | 20:42 | |
| Keybuk | zombies may crave brains, but Keybuks crave Spring Vegetable Soup and a mug of hot Tea | 20:42 |
| Caesar | Does the "compiled with the following options" chunk of this excerpt of Universe's Packages file look strange to anyone else? | 20:44 |
| Caesar | http://paste.ubuntu.com/396924/ | 20:44 |
| Keybuk | Caesar: I guess someone was taking notes in the control file and forgot to delete them ;-) | 20:49 |
| lamont | stgraber: around? | 20:49 |
| Caesar | Keybuk: zomg, debian/rules puts it there | 20:50 |
| Keybuk | probably trying to add it to the description | 20:51 |
| Caesar | and failing dismally | 20:52 |
| Caesar | Oh fun, it works fine in Debian | 20:58 |
| Caesar | It's something to do with the insertion of the Original-Maintainer maintainer field in Ubuntu | 20:58 |
| Keybuk | yes | 20:59 |
| Keybuk | it goes at the bottom | 20:59 |
| Caesar | Not in this package | 20:59 |
| Caesar | It's in the middle (see the pastebin thingy) | 20:59 |
| lamont | highvoltage: you around? | 21:15 |
| highvoltage | lamont: yep, hi! | 21:16 |
| lamont | crying a little here... | 21:17 |
| highvoltage | lamont: do you think you'll have a chance to look at that additional squashfs image on the edubuntu disc thisweek? | 21:17 |
| highvoltage | lamont: crying? how so? | 21:17 |
| lamont | Is there any way of getting the livecd tarball build to _NOT_ require install inetd and half the networking daemons in existance? | 21:18 |
| lamont | wow. that was almost english | 21:18 |
| highvoltage | I understood it at least :) | 21:18 |
| c_korn | is lucid going to have support for the SSD's trim command ? I read it will be in the 2.6.33 kernel. | 21:19 |
| highvoltage | lamont: it currently tries to install that during the build? because it shouldn't | 21:19 |
| lamont | iproute, tcpd, and openbsd-inetd are particularly offensive | 21:19 |
| highvoltage | perhaps I accidentally made ltsp-livecd depend on ltsp-server (one moment while I check) | 21:19 |
| lamont | ltsp-server depends on them, and ltsp-server provides ltsp-build-client and lts-update-image | 21:19 |
| lamont | so I think you intentionally made it depend on ltsp-server | 21:20 |
| highvoltage | we want ltsp-server to be shipped on the disc, not to beinstalled, I just checked and ltsp-livecd definitely doesn't depend on ltsp-server | 21:20 |
| * highvoltage checks the seeds | 21:20 | |
| lamont | it's installed inside the chroot where we build the image | 21:21 |
| lamont | which is what I'm bitching about | 21:21 |
| highvoltage | just so that we're clear, inside the edubuntu chroot or in the ltsp chroot? | 21:21 |
| lamont | on terranova is a build-lucid-live/chroot-lucid chroot in which we build build/chroot-live (which becomes the casper image), and the ltsp image chroot, which becomes your file | 21:22 |
| lamont | my complaint is about ltsp-server's dependencies getting installed in build-lucid-live/chroot-lucid | 21:23 |
| lamont | nbd-server belongs on the list too | 21:23 |
| lamont | OTOH, we block all the services from starting, so it's not particularly bad, it just makes me want to stab myself in the eyes | 21:23 |
| highvoltage | lamont: ok, I'm not sure where that comes from but I'll find out now and get it out, it really shouldn't be there | 21:23 |
| highvoltage | lamont: heh, understood | 21:24 |
| lamont | livecd-rootfs (installed in build-lucid-live/chroot-lucid) Depends: ltsp-server (to get those commands), which Depends: all kinds of crap that we don't actually start, so we don't actually need it. | 21:25 |
| lamont | highvoltage: IOW, building the client image shouldn't be something that requires me to run it on the server. | 21:26 |
| lamont | but that's a design bug that won't get fixed for lucid | 21:26 |
| highvoltage | lamont: ok, I'm going to talk to stgraber, that package is in main so I can't change it myself, but I'll ask him to remove it and then give you a ping. thanks a lot for the feedback | 21:28 |
| lamont | I won't let it block us this go round, but can we pretty please fix it for lucid+1? | 21:29 |
| Keybuk | dear pbuilder, if I give you a changes file, you should know what to do - you're not bzr, you don't have to be pedantically annoying and difficult | 21:32 |
| highvoltage | lamont: ok, for sure | 21:32 |
| highvoltage | lamont: ok, so the fix for ltsp-server would be to add conditional dependencies on either something like dnsmasq and/or a dummy package that satisfies ltsp-server's dependencies (that would make you squirm less and we'd have a better looking livecd), unfortunately a dummy package would require a FFE and a promotion to main, so it will probably be done early in the M cycle. | 21:52 |
| lamont | what's wrong with splitting the package into the part that builds the client and the part that needs the daemons? | 21:53 |
| highvoltage | lamont: splitting it would require FFE's and main promitions right? | 21:55 |
| lamont | yeah, for M | 21:55 |
| highvoltage | lamont: yep, that could also work. | 21:56 |
| lamont | because as soon as I upload 1.107, I'm going to file a bug against ltsp to split it, and then a bug against livecd-rootfs dependent on that bug to "NOT DEPEND: ltsp-server, but rather just the bits we need" | 21:56 |
| lamont | I hate dummy packages | 21:56 |
| highvoltage | so what would you recommend, having the scripts in a package that's something like ltsp-server-scripts and then have ltsp-server depend on that? | 21:57 |
| lamont | they're nothing but clutter. Also, I'd like to deploy ltsp in a couple of places, and can't use the packages, since the NFS server, tftp server, and dhcp server are 3 different machines, and no way I'm installing all of the daemons on all of the boxes | 21:57 |
| lamont | yeah - that would be a good appraoch | 21:58 |
| highvoltage | lamont: ok, great | 21:59 |
| highvoltage | stgraber: nice timing :) | 21:59 |
| highvoltage | stgraber: lamont suggess that (for the M release) the scripts from ltsp-server should rather go into something like ltsp-server-scripts that doesn't depend on anything, and then ltsp-server can depend on that | 22:00 |
| highvoltage | stgraber: that also makes sense in the cases where (like his use case) people don't want everything on one server | 22:00 |
| lamont | LiveCD/lucid/edubuntu/20100317.1/livecd.edubuntu-ltsp-20100317.1-i386.squashfs <-- highvoltage | 22:17 |
| lamont | Squashfs filesystem, little endian, version 4.0, 55992121855 bytes, 38459 inodes, blocksize: 13 bytes <-- sound about right? | 22:18 |
| lamont | the 13 byte blocksize seems a little funnhy | 22:18 |
| highvoltage | lamont: *hug* | 22:21 |
| highvoltage | lamont: yes it seems a lot funny | 22:21 |
| lamont | it's also hardy's file command printing that | 22:21 |
| lamont | anyway, once 1.107 is in lucid, wait a day and the image file will be there and you can pester the CD build process to deliver the file for you | 22:21 |
| highvoltage | ok thanks, I'll look at it as soon as it's available | 22:22 |
| lamont | yeah - seems there's this pesky beta1 freeze or something. :-( | 22:22 |
| amitk | tearjerker | 22:43 |
| === oSoMoN_ is now known as oSoMoN | ||
| cjwatson | so where does this "does not terminate at computer shutdown" apport thing come from? | 23:02 |
| cjwatson | ah, /usr/share/apport/unkillable_shutdown | 23:03 |
| sebner | cjwatson: do you know if "using stuff in Trash folder" will be fixed in Gnome3? I consider this as br0ken by design (gfvs) as you should be able to open an image (e.g on windows) | 23:04 |
| cjwatson | sebner: hmm, do I have my fake plastic GNOME developer hat on or something? :) | 23:07 |
| cjwatson | (I have no idea, I don't normally work on GNOME) | 23:07 |
| slangasek | superm1: may I suggest http://mythbuntu.org/10.04/beta1 as a URL, since we're getting 2 betas this time 'round? | 23:07 |
| seb128 | sebner, what is broken? | 23:08 |
| sebner | cjwatson: I see you as someone very wise and (nearly) omniscient :P | 23:08 |
| sebner | seb128: broken by design. Files in Trash are not usable. e.g open a picture like it works unter windows | 23:08 |
| cjwatson | sebner: not about this, try a desktop developer. :) | 23:08 |
| seb128 | sebner, how does it work under microsoft os-es? | 23:09 |
| seb128 | sebner, double clicking on an image in the trash do works in Ubuntu | 23:10 |
| seb128 | not sure what your issue is | 23:10 |
| chrisccoulson | sebner - what image viewer do you use? | 23:10 |
| sebner | seb128: not here, eog tells me about not found location and gvfs crashes :P | 23:10 |
| sebner | chrisccoulson: eog | 23:10 |
| chrisccoulson | hmm, it works fine here | 23:10 |
| seb128 | wfm | 23:10 |
| sebner | videoplaying is also not working, with any player | 23:10 |
| sebner | chrisccoulson: lucid | 23:10 |
| sebner | ? | 23:10 |
| chrisccoulson | sebner, yes | 23:10 |
| sebner | chrisccoulson: weird | 23:11 |
| cjwatson | wow, when I say "broken by design" it usually means I've confirmed this against the design ;-) | 23:11 |
| superm1 | slangasek, yeah that should be fine, i'll make sure the guys know | 23:11 |
| slangasek | superm1: ok, thanks | 23:11 |
| chrisccoulson | sebner, normally issues like that will arise for applications not using gio | 23:11 |
| seb128 | sebner, trash is a known uri for gvfs, any app using gio will be able to use it | 23:11 |
| chrisccoulson | but that is not the case here | 23:11 |
| seb128 | sebner, if you have a crash send it using apport | 23:12 |
| sebner | seb128: apport is too br0ken to send xD | 23:12 |
| seb128 | reinstall your box? | 23:12 |
| seb128 | it seems your install is screwed | 23:12 |
| chrisccoulson | i was just thinking the same thing ;) | 23:12 |
| sebner | seb128: not wondering. using it since lucid openend. I have to admit that it works *now* but I'm sure tomorrow I'll be able to produce a crash log | 23:13 |
| sebner | chrisccoulson: lucid ftw! :P | 23:14 |
| sebner | seb128: ever heard about apport complaining about not being able to send the bug report because there is no internet connection (when there *is* one) ? | 23:14 |
| seb128 | no | 23:14 |
| seb128 | do you use a proxy? | 23:14 |
| === robbiew is now known as robbiew_ | ||
| chrisccoulson | sebner - there was a launchpad issue over the weekend. did you try recently? | 23:15 |
| sebner | seb128: nope | 23:16 |
| sebner | chrisccoulson: recently = 1-2 days ago, yes | 23:16 |
| sebner | seb128: I guess my system is __really__ b0rken | 23:16 |
| sebner | seb128: chrisccoulson : sorry for the noise and thx for your time :) | 23:18 |
| chrisccoulson | yw ;) | 23:18 |
| seb128 | yw | 23:19 |
| sebner | seb128: but playing videos is *not* supported I guess? | 23:19 |
| seb128 | ? | 23:20 |
| seb128 | you would image any modern operating system not able to play a video? | 23:20 |
| seb128 | oh, you mean from the trash | 23:20 |
| seb128 | totem should support gio locations just fine | 23:20 |
| seb128 | sebner, works there | 23:21 |
| seb128 | I just moved an ogg video in the trash and double clicked on it | 23:21 |
| seb128 | totem play it | 23:21 |
| sebner | seb128: ah, here too (now), vlc is a bad boy then :) | 23:22 |
| ion | vlc probably just doesn’t know what to do with a gvfs URI. | 23:22 |
| ion | Something like trash:///blah probably gets passed to it. | 23:22 |
| sebner | kk :) | 23:23 |
| seb128 | yes | 23:23 |
| seb128 | ion, well if it does that's because it's .desktop is buggy | 23:23 |
| seb128 | hum, maybe not for trash: though, not sure about this one | 23:23 |
| seb128 | nautilus passes the .gvfs mounts for apps who don't handle uris | 23:24 |
| Lord-Readman | hello | 23:29 |
| Keybuk | I'm going to write abot | 23:29 |
| Keybuk | a bot too | 23:30 |
| Lord-Readman | can someone please tell me the package that holds System > Administration > Printing in gnome ubuntu 10.04 | 23:30 |
| Lord-Readman | ? | 23:30 |
| Keybuk | this bot, once a day, will go through all the bugs in LP that are at Confirmed or Triaged | 23:30 |
| Keybuk | and will post | 23:30 |
| Keybuk | THIS BUG IS STILL THERE!!!! OMG!!!! | 23:30 |
| ion | That could be an internal feature of Launchpad. | 23:30 |
| micahg | Keybuk: you should have the bot post it once for each subscriber... | 23:31 |
| RAOF | ion: I'm sure that performance would be greatly improved with a local connection to the database :) | 23:31 |
| cjwatson | Lord-Readman: here's how you find out: | 23:31 |
| cjwatson | Lord-Readman: run System -> Administration -> Printing; open a terminal window and run 'xprop | grep WM_CLASS', then click on the window | 23:32 |
| cjwatson | it says: | 23:32 |
| cjwatson | WM_CLASS(STRING) = "system-config-printer.py", "System-config-printer.py" | 23:32 |
| cjwatson | so run 'dpkg -S system-config-printer.py' | 23:32 |
| cjwatson | system-config-printer-gnome: /usr/share/system-config-printer/system-config-printer.py | 23:32 |
| elmo | is nano particularly highly scored in lucid or am I losing my mind? | 23:33 |
| Lord-Readman | thanks | 23:33 |
| rickspencer3 | slangasek, for the beta announcement, should I remove things that were new in Alpha 3, but are no longer new for Beta 1? | 23:39 |
| slangasek | rickspencer3: no, certainly not - the beta announcements are targeted to a different audience than the alphas | 23:39 |
| rickspencer3 | thanks | 23:40 |
| rickspencer3 | slangasek (that saves me a bit of work ;) ) | 23:40 |
| === gnomefreak76 is now known as gnomefreak | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!