| === cpplogger is now known as apachelogger | ||
| psusi | hrm.. I'm a bit out of my realm here with all this dbus and gconf stuff, but it looks to me like the cpufreq panel is already broken up into two components where the cpufreq-selector-servervice is supposed to be run as root and called on by the panel | 00:38 |
|---|---|---|
| psusi | there's an xml file in here that looks like it's supposed to define some sort of control interface methods at /org/gnome/CPUFreqSelector | 00:40 |
| psusi | it doesn't look like it's actually getting installed though | 00:40 |
| persia | kees: The point of the way mk-sbuild does things is that you don't need to start a VM: just `schroot -c` or `sbuild -d` as usual. Plus what lool said. | 00:41 |
| persia | kees: also, both armel and powerpc are known to work (armel works better). I believe the rest of the architectures are untested (but bugs against qemu-kvm-extras-static would be nice if they don't) | 00:43 |
| ccheney | anyone know of a simple code snippet for debian/rules to do patching if it isn't using cdbs? | 01:09 |
| ccheney | or an example package that i can look at for it | 01:09 |
| cjwatson | use dpkg-source v3, and then you can just leave the patches applied and not have to worry about junk in debian/rules | 01:10 |
| persia | ccheney: there are a bundle of them. What's your debian/rules look like now? | 01:10 |
| ccheney | persia: i'm adding a patch to karmic webkit in particular for backport to hardy | 01:11 |
| ccheney | cjwatson: hmm sounds cool but can't do that for hardy :) | 01:12 |
| cjwatson | run what-patch to see what system it's using now | 01:12 |
| cjwatson | you should always stay in line with that | 01:12 |
| ccheney | cjwatson: good idea for lucid and neweer though :) | 01:12 |
| ccheney | cjwatson: ok | 01:12 |
| cjwatson | if it isn't using any patch system, just apply the patch directly | 01:12 |
| ccheney | cjwatson: as best as i can tell it isn't using any patches at the moment | 01:12 |
| * persia avoids repeating the obviously correct advice | 01:12 | |
| cjwatson | I must get round to finishing that blog post about my experiences with 3.0 (quilt) | 01:13 |
| ccheney | ok so i'll have it applied directly along with a copy of the patches in debian/patches for anyone who wants to pull them out separately (if ever) | 01:13 |
| cjwatson | oh, at best semi-relatedly but while I think about it, my current projection is that dh will overtake cdbs in unstable sometime in July | 01:14 |
| ccheney | cjwatson: dh 7? | 01:14 |
| cjwatson | the dh command in debhelper 7, yes | 01:14 |
| ccheney | ah i see | 01:15 |
| ccheney | cjwatson: is there a doc on how deb 3.0 works? | 01:15 |
| ccheney | cjwatson: other than man dpkg-source i mean | 01:15 |
| cjwatson | that was what I was going to recommend | 01:15 |
| ccheney | so does it automatically create the debian tarball for you or do you do that yourself? | 01:16 |
| micahg | cjwatson: any chance you can approve thunderbird and ubufox in the queue? | 01:16 |
| ccheney | i didn't notice where it mentioned how that happens, i might have missed it | 01:16 |
| cjwatson | it automatically creates it the same way as it automatically creates .diff.gz | 01:16 |
| cjwatson | micahg: sorry, I'm just about to go to bed | 01:16 |
| micahg | cjwatson: k | 01:16 |
| cjwatson | micahg: poke on #ubuntu-release if you need to | 01:16 |
| ccheney | cjwatson: ok, so you just need premade other tar.gz's but the debian one is automatically made? | 01:16 |
| micahg | cjwatson: thanks | 01:16 |
| cjwatson | ccheney: yes | 01:16 |
| ccheney | cjwatson: ok thanks that helps a lot :) | 01:16 |
| cjwatson | ccheney: oh, there's http://wiki.debian.org/Projects/DebSrc3.0 too | 01:18 |
| ccheney | cjwatson: thanks | 01:18 |
| ccheney | cjwatson: are we going to get xz support anytime soon (lucid/lucid+1 ?) | 01:19 |
| cjwatson | lucid+1 | 01:19 |
| ccheney | ok | 01:19 |
| cjwatson | I believe anyway, haven't paid terribly close attention but I saw some commits go by | 01:20 |
| * ccheney will do the testing for that with OOo for lucid+1, aiui it works better than lzma | 01:20 | |
| ccheney | ok | 01:20 |
| psusi | bug #356208 mentions: The reason appears to be that in order to work, the CPU applet (and a whole bunch of other things) attempt to validate that the "Desktop User" is a user who can perform administration. They look for the user who was setup during installation and not finding that user, they don't do anything. But, they also provide no errors, nor do they they attempt to use the "root" user. | 02:02 |
| ubottu | Launchpad bug 356208 in gnome-applets "CPU Frequency Scaling Monitor Applet does not allow me to change CPU Frequency (Ubuntu 8.10)" [Low,New] https://launchpad.net/bugs/356208 | 02:02 |
| psusi | how exactly does the policy kit decide who is the admin? or where can I start tracing that process? | 02:02 |
| psusi | hrm.... here's a question... it seems that the default upstream policy is for the cpufreq applet to admin_auth_keep, so you have to type your password the first time it needs it... | 02:42 |
| psusi | bug #455694 people are complaining about the password prompt... it seems like no harm can be caused by allowing admin users to set their cpu frequency without entering their password first | 02:43 |
| ubottu | Launchpad bug 455694 in gnome-applets "CPU Frequency Scaling Monitor asks for authentication all the time" [Low,New] https://launchpad.net/bugs/455694 | 02:43 |
| psusi | if I were to attach a debdiff adding a patch changing it to just be allowed, would this be accepted? | 02:43 |
| persia | psusi: How do you detect "admin user" then, if not by authentication? | 02:44 |
| lifeless | persia: group membership ? | 02:44 |
| psusi | persia, hrm... actually I guess just setting it to yes allows anyone to do it... | 02:44 |
| persia | lifeless: Wasn't pitti trying to drop the "admin" group? | 02:45 |
| lifeless | persia: so don't use that group :) | 02:45 |
| psusi | the policy kit now has auth_admin_keep set... so you have to type your password the first time you try to change the frequency | 02:45 |
| lifeless | personally I'd say the 'local' bit is policy kit should be enough | 02:45 |
| psusi | some users on the forums have suggested editing it to just yes so it doesn't annoy you | 02:45 |
| RAOF | lifeless: at_console? Yeah, that's what I was thinking. | 02:45 |
| psusi | eh? at_console? that a group or polkit rule? | 02:46 |
| lifeless | RAOF: yah, if thats what its called. | 02:46 |
| persia | psusi: That's the "stick it under the rug" solution. Dig into policykit a bit more, and see if you can't determine whether the current user should be able to do that by other means, and only ask for authentication when this fails. | 02:46 |
| persia | (at_console seems reasonable for most use cases) | 02:46 |
| psusi | hrm... yea, I guess that's the question... is there something between allow_active=auth_admin_keep and yes | 02:47 |
| psusi | oh wait, no... it sounds like allow_inactive lets anyone do it, and allow_active=yes means anyone on the local console can do it | 02:48 |
| persia | "anyone at the local console" breaks the use case of doing something, opening a guest account, and handing it to the person next to you, but I'd hope that's a rare use case. | 02:49 |
| lifeless | persia: for cpu frequency setting | 02:50 |
| lifeless | persia: I don't think it matters | 02:50 |
| psusi | yes, the guest would also be able to use it, but the most harm they can do is slow down the cpu, so... | 02:50 |
| psusi | yea, don't think it really matters.... | 02:50 |
| lifeless | persia: because they can also take the machine and walk away :) | 02:50 |
| persia | Agreed, hence my contrived use case : we generally don't care if a long-running job takes a little longer when *someone else* is currently at console. | 02:50 |
| lifeless | persia: ok, now I understand. your description was a little opaque | 02:51 |
| psusi | so I can change it to yes and attach the debdiff to the bug and request a sponsor upload and it should be accepted? | 02:51 |
| persia | psusi: None of the folks in this conversation so far can upload it, so the answer is "maybe". | 02:52 |
| persia | But if it does something sensible, and is still relatively secure, likely. | 02:52 |
| psusi | it looks like there is no option to require admin, but NOT require them to enter their password again, shame... | 02:54 |
| persia | Maybe it doesn't really require admin. | 02:55 |
| persia | I think the lack of behaviour you see is to support things like computer labs, where most active users are *not* admins. | 02:55 |
| psusi | wait, what was the magic phrase to put in the change log to auto close the lp bug? | 02:58 |
| persia | (LP: #nnnnn) | 02:59 |
| psusi | to allow the interactive user to set the cpu frequency without first authenticating as an admin. Closes (LP: #455694). | 03:01 |
| psusi | that look good? | 03:01 |
| ScottK | You don't need closes | 03:01 |
| persia | psusi: debuild -S -us -uc to get a source.changes : check for the launchpad-fixes-bugs header (or whatever it's called) | 03:01 |
| psusi | hrm... ok | 03:01 |
| psusi | so just "authenticating as an admin (LP: #455694)."? | 03:02 |
| maco | "Closes: #12345" is Debian BTS syntax | 03:02 |
| psusi | hrm... seems the existing quilt patches here all start with two digits... how should I choose a number for mine? | 03:03 |
| psusi | or do I have to even? | 03:03 |
| maco | number tells what order they were added to the package, usually | 03:09 |
| psusi | ohh, it looks like it uses bzr... should I instead create a branch on lp and modify that, then link to the branch in the bug? hrm... | 03:16 |
| micahg | or what order they need to be applied sometimes | 03:18 |
| micahg | nm,not for quilt | 03:19 |
| psusi | I'm confused... why is it using quilt, if it already uses bzr? | 03:20 |
| === sconklin is now known as sconklin-gone | ||
| kees | lool: do we have kernels for anything besides versatileab from the list in qemu-system-arm -M help | 04:09 |
| kees | (I actually get _no_ output from qemu-system-arm when booting them) | 04:13 |
| pitti | Good morning | 06:58 |
| persia | kees: What are you trying to do at a higher level. | 06:59 |
| pitti | persia, lifeless: CPU freq scaling admin group> I'll answer in the bug report; I have a plan for the similar problem in udisks | 06:59 |
| persia | pitti: Excellent. Thanks. | 07:00 |
| === MacSlow is now known as MacSlow|afk | ||
| dholbach | good morning | 07:21 |
| jiboumans | TheMuso, crimsun: pitti says you might know about this; karmic + dell vostro + built in mic; any known issues with the mic not actually working? | 07:27 |
| === jelmer_ is now known as jelmer | ||
| lool | kees: No, only versatilepb and ab (I think the kernel is configured for both) | 07:54 |
| lool | kees: There's a qemu branch for OMAP3 and an OMAP3 kernel is pending, that might be a new combination in the future | 07:54 |
| lool | kees: Make sure you pass -cpu cortex-a8 to qemu-system-arm | 07:54 |
| lool | kees: The default for versatile is an older CPU, but our userspace needs armv7+ | 07:55 |
| lool | (cortex-a8 is v7; we also patched the versatile Kconfig to select v7) | 07:55 |
| === sabdfl1 is now known as sabdfl | ||
| === MacSlow|afk is now known as MacSlow | ||
| === tkamppeter_ is now known as tkamppeter | ||
| ev | mdz: would you be so kind as to file a bug for the usb-creator umount issue you ran into? | 09:32 |
| ev | lifeless: I think that's perfectly reasonable as a command line option. If you file a bug, I'll put it on my list for lucid+1. | 09:33 |
| lifeless | ev: ok, I'll double check my facts and put a bug up for you | 09:35 |
| ev | much appreciated | 09:35 |
| lifeless | de nada | 09:35 |
| mvo | Riddell: if you could have a look at #538522 that would be much appreciated | 09:36 |
| Riddell | mvo: where do I look for the error in the test case logs? http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/kubuntu/ | 10:21 |
| mvo | Riddell: I pasted the relevant bits in the bugreport I think, its in http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/kubuntu/apt-term.log | 10:21 |
| mvo | Riddell: if you search for "dpkg: error" there | 10:22 |
| mvo | Riddell: you will find the file overwrite problem | 10:22 |
| mvo | Riddell: sorry, its not entirely user-friendly yet the output :/ | 10:22 |
| Riddell | oh aye there it is | 10:23 |
| === jelmer_ is now known as jelmer | ||
| smb | pitti, Do you know off your head whether something from userspace already touches /sys/power/disk. I am looking at a bug for one system that requires the "shutdown" instead of the default "platform" method and I am wondering whether this justifies a new quirking method in the kernel or is much simpler done in user-space... | 10:35 |
| pitti | smb: the only thing I know of is pm-utils' hibernate command, which writes a "hibernate mode" to /sys/power/disk (and then "disk" to /sys/power/state) | 10:37 |
| pitti | I don't think we touch it anywhere else | 10:37 |
| pitti | smb: I think this $HIBERNATE_MODE might be what you are looking for | 10:38 |
| pitti | it can be overridden by hooks, I figure | 10:38 |
| smb | pitti, Well mode would probably be what I am looking for. Right | 10:38 |
| pitti | pm/defaults:# HIBERNATE_MODE="shutdown" | 10:38 |
| pitti | ah, that's just a comment | 10:39 |
| pitti | smb: our actual default is "" | 10:39 |
| smb | pitti, Ok. But its a place to investigate further | 10:39 |
| pitti | smb: in other words, we don't write /sys/power/disk by default | 10:39 |
| pitti | smb: but if a suspend.d script would set it, it should respect it | 10:40 |
| smb | pitti, Ok. Thanks. I think thats a starting point | 10:40 |
| directhex | hm. i guess glxinfo shouldn't segfault, right? | 11:08 |
| pecisk | right | 11:10 |
| pecisk | :) | 11:10 |
| pecisk | directhex: Xorg driver? | 11:10 |
| directhex | pecisk, intel | 11:11 |
| pecisk | directhex: bug reported? | 11:11 |
| directhex | pecisk, doing it now | 11:11 |
| directhex | eh? i appear to have nvidia libglx.so | 11:16 |
| pecisk | wow | 11:18 |
| pecisk | directhex: isn't some kind of new hardware you got there? | 11:18 |
| directhex | pecisk, dell laptop. | 11:18 |
| pecisk | directhex: brand new? | 11:18 |
| directhex | pecisk, nope | 11:18 |
| directhex | worked with karmic. wonder what happened | 11:19 |
| pecisk | directhex: pastebin.ca lspci please | 11:19 |
| directhex | http://paste.ubuntu.com/396106/ | 11:22 |
| pecisk | directhex: there is no Nvidia. Do you have nvidia-glx installed? Maybe remove it, restart and try again. | 11:23 |
| directhex | wait a sec, this xorg.0.log is ancient. | 11:23 |
| pecisk | ahh :) | 11:23 |
| directhex | no, my mistake, was reading the Release Date line | 11:24 |
| directhex | i really don't get it. md5sums for libglx.so match the xserver-xorg-core.md5sums file, yet Xorg.0.log says vendor="NVIDIA Corporation" on the module | 11:25 |
| directhex | huh? strings says it's not nvidia's | 11:26 |
| directhex | wtf is going on -_- | 11:27 |
| pecisk | directhex: 'dpkg -l | grep nvidia' >> pastebin.ca :) | 11:27 |
| directhex | wait a sec, it's this "nvidia-current". bleh @ constant renaming of nvidia packages. also, wtf did it come from? | 11:28 |
| pecisk | directhex: nvidia-current I think is newest nvidia-glx driver, just so you don't have to remember which version of nvidia driver you have to install | 11:30 |
| pecisk | just remove it and reboot machine | 11:30 |
| pecisk | faulty dependencies I think | 11:30 |
| pecisk | directhex: how did you installed Lucid? | 11:30 |
| directhex | where is the log from an update-manager upgrade? | 11:30 |
| pecisk | have no idea | 11:31 |
| directhex | 2010-03-09 14:19:10 install nvidia-current <none> 195.36.08-0ubuntu1 | 11:32 |
| directhex | came in with my upgrade, i think | 11:32 |
| pecisk | something pulled it in | 11:33 |
| directhex | wobbly windows are back | 11:34 |
| pecisk | yay \w/ | 11:35 |
| === MacSlow is now known as MacSlow|lunch | ||
| mvo | directhex: /var/log/dist-upgrade | 12:03 |
| directhex | mvo, right. definitely came with the upgrade | 12:06 |
| directhex | aha! libmyth-0.22-0 | 12:07 |
| directhex | so if you had mythtv on karmic, upgrading to lucid will break non-nvidia 3d | 12:07 |
| directhex | that's probably a bug | 12:08 |
| === jcarter is now known as highvoltage | ||
| === MacSlow|lunch is now known as MacSlow | ||
| radoe | hm, I wonder if I did something wrong with bug #535090? It is marked as security vulnerability (although of lower impact). I grabbed it last week, linked branches with fixes from intrepid up to lucid and debdiffs for easier review. I think I subscribed the right groups, but nothing seems to happen about it. | 13:08 |
| ubottu | Launchpad bug 535090 in erlang "CVE-2008-2371 (outer level option with alternatives caused crash)" [Low,Confirmed] https://launchpad.net/bugs/535090 | 13:08 |
| highvoltage | has anyone had any weird sudo behavior on the live cds? the first time I use sudo on the edubuntu livecd it kills gdm and shows some weird characters while it's restarting. after that it works fine | 13:24 |
| persia | radoe: Everything looks right for that bug. In the most recent secuirty team meeting, there was talk of a backlog: I suspect you've just hit that. | 13:25 |
| superm1 | directhex, mvo i'm not sure why libmyth-0.22-0 was even kept/upgraded during the upgrade though, nothing should be depending on it, and there is a 0.23-0 in the archive that should have pulled in libvdpau1 rather than anything nvidia | 13:26 |
| directhex | superm1, well, that's the only culprit i can find for why it was there o_o | 13:26 |
| radoe | persia: well, thx for this info. | 13:27 |
| === doko_ is now known as doko | ||
| psusi | pitti: I see you got involved with the cpufreq polkit bug... last night I chanced the source code policy for gnome-applets to fix the policy file, then installed the new package, but the policy file on my system remained unchanged, and it doesn't look like the binary package contains that file... what gives? | 13:30 |
| seb128 | psusi, what file? | 13:30 |
| psusi | also the package seems to be using both quilt and bzr, so which should I use? make a quilt patch? make a bzr branch? make a quilt patch IN a bzr branch? | 13:30 |
| seb128 | psusi, the later option | 13:30 |
| psusi | ugh, really? use one vcs to change control another? | 13:31 |
| seb128 | psusi, quilt is used by the packaging, bzr is just where we store the changes | 13:31 |
| psusi | that just seems.... wrong... | 13:31 |
| seb128 | psusi, quilt is used as a patch system not a vcs | 13:31 |
| psusi | that seems like saying something is a car, not a vehicle ;) | 13:31 |
| diwic | psusi: which then gets into a diff.gz, so in practice you have at least three indirection layers for a patch. | 13:32 |
| seb128 | psusi, the policy is in the -data binary btw, not sure if that reply to your question | 13:32 |
| psusi | what is the purpose of continuing to use quilt IN bzr? bzr should be providing you with everything quilt does and more | 13:32 |
| seb128 | psusi, the usecase we have usually is to drop a git commit from upstream in the patches dir | 13:32 |
| seb128 | psusi, we don't have the full source in bzr just the debian dir | 13:33 |
| psusi | ohh | 13:33 |
| seb128 | psusi, and we keep upstream changes in the debian dir not in the diff.gz | 13:33 |
| seb128 | upstream -> distro | 13:33 |
| psusi | I see | 13:33 |
| diwic | psusi: People who gets the built source package don't necessarily have bzr | 13:34 |
| psusi | as for what file, it was the polkit file... I can't recall exactly now but it was something like /usr/polkit-1/actions/org.freedesktop.cpufreq-selector | 13:34 |
| psusi | I found where that file was in the source and changed the auth_admin_keep line to yes, and rebuilt... but that file does not seem to make it into the binary paackage | 13:35 |
| seb128 | psusi, the -data binary has it as said before | 13:36 |
| diwic | psusi: It would be cool to make a system which uses git/bzr and created quilt patches directly from the commits instead of having yet another indirection layer | 13:36 |
| seb128 | psusi, did you install that one too? | 13:36 |
| psusi | hrm... I didn't notice an additional .deb in the pbuilder directory... maybe I missed it | 13:37 |
| psusi | that reminds me, isn't pbuiolder supposed to allow non root users to build packages via fakeroot? so why do I always have to sudo it? | 13:37 |
| psusi | ohh, and is there something wrong with dpkg these days? it seemed to be taking AGES to install the dep packages last night in pbuilder... I noticed a thread about a massive slowdown on debian-dpkg, but it seems to be talking about a newer version that is in lucid | 13:39 |
| persia | psusi: Yes. A fix has been uploaded. | 13:39 |
| persia | (for lucid) | 13:40 |
| psusi | ohh... got a bug #? | 13:40 |
| psusi | or I can go search for it... | 13:40 |
| seb128 | psusi, #537241 | 13:40 |
| psusi | ohh, so we DID backport the damn fsync patch to dpkg | 13:46 |
| cjwatson | yes, because there was a bug with 200 duplicates fixed by it | 13:46 |
| psusi | really? what is that? seems like the underlying bug is the default mount options for ext4 are dangerous | 13:49 |
| pitti | ugh, that reinstall of my laptop took ages; now I mean what cjwatson meant with "dpkg performance regression".. | 13:49 |
| psusi | yea, it's like a 10-50x slow down | 13:49 |
| pitti | psusi: hm, I can't say without seeing your changes, I'm afraid | 13:49 |
| pitti | psusi: ah, seems you already discussed that; but please don't change it in gnome-applets | 13:50 |
| psusi | pitti: why is that? I seem to be missing something about how that file gets from gnome-applets to /usr/polkit-1/actions.. I don't really understand polkit | 13:51 |
| psusi | on the dpkg thing, last night when I had pbuilder build gnome-applets, it took like 5-10 minutes to install the dep packages, then only like 20 seconds to actually build gnome-applets... ssd = very nice, that dpkg sync patch = very bad | 13:52 |
| pitti | psusi: there's no magic; it's just a file put into the .deb, which is built by the source | 13:52 |
| psusi | pitti: I would have thuoght, but it iddn't get updated when I installed the new package, and when I did a dpkg -L, the file was not listed as belonging to the package... so I did a dpkg -x and sure enoguh, the file was not in there | 13:53 |
| pitti | $ dpkg -S /usr/share/polkit-1/actions/org.gnome.cpufreqselector.policy | 13:53 |
| pitti | gnome-applets-data: /usr/share/polkit-1/actions/org.gnome.cpufreqselector.policy | 13:53 |
| pitti | works here | 13:53 |
| psusi | ahh... ok, I must have missed the -data binary | 13:54 |
| psusi | ohh, in fact, I know why I did... I was only looking for amd64, it's probably an _all | 13:54 |
| cjwatson | psusi: please see debian-dpkg, I'm not going to repeat myself at that kind of length here :) | 13:54 |
| cjwatson | anyway, the relevant small part of the patch has been reverted, so there's no need to continue to rant about how dreadful it is | 13:55 |
| psusi | now you seem to not want to change it in the source because a server might not want that change? but the change only allows INTERACTIVE users access, so for a server the only interactive user ever there shuold be the admin | 13:55 |
| pitti | psusi: yes, it's Arch: all (as most of the -data packages, otherwise having them wouldn't make sense) | 13:55 |
| pitti | psusi: you might also want to not have those policies in a business environment; having a separate package (1) is more flexible, and (2) avoids delta to Debian/upstream | 13:56 |
| psusi | hrm... why is debconf hardly ever used? it seems like this is the sort of thing that debconf should ask you when yuo install or reconfigure it, at least if you use the correct question priority level | 13:57 |
| psusi | couldn't you set up debconf to have a low priority question to override it, and otherwise default to auth for server and yes for desktop? | 14:01 |
| pitti | psusi: you'd have to debconfize many packages then, though | 14:02 |
| psusi | what do you mean? | 14:02 |
| pitti | and (1) we don't show debconf by default, and (2) most desktops are installed with the desktop CD, where pacakges don't get "installed" in teh dpkg/debconf sense | 14:02 |
| pitti | psusi: you'd have to apply this to udisks, gnome-applets, gnome-panel (for the time setting), etc. | 14:03 |
| psusi | I thought 1) the default was to ask only high priority questions at install, medium at manual instal, and low only get asked when you explicitly say so at install or reconfigure, and 2) since it would be a low priority that wouldn't really matter since they would need to explicitly dpkg-reconfigure and ask for low priority questions | 14:04 |
| pitti | but if most people don't see it at all, why bother? | 14:04 |
| psusi | ohh, right, because you're trying to bundle up changes to all of them at once... | 14:04 |
| pitti | I think we should just configure servers and desktops with sane default permissions | 14:04 |
| psusi | because isn't this kind of the purpose of debconf? so that when I as a user go, why is this thing not set up the way I want? let me see what debconf options I can tweek... | 14:05 |
| pitti | debconf has never been really entailed by ubuntu, though | 14:06 |
| pitti | erm, "adopted" | 14:06 |
| psusi | yea... I've noticed, and find it kind of disappoiinting | 14:06 |
| cjwatson | yes it has, just in contexts other than the default desktop | 14:07 |
| psusi | well I know there have been a few times I've installed daemons on servers and wondered why I get no configuration options even on low priority debconf ;) | 14:08 |
| pitti | psusi: on servers you'll see a few, for example mysql | 14:08 |
| pitti | or web apps asking for an admin password or so | 14:08 |
| cjwatson | obviously there are going to be exceptions, but we have not in general ripped out debconf questions that are in place in Debian | 14:08 |
| psusi | yea, I've seen one or two high priority questiosn, but never medium or low | 14:08 |
| pitti | psusi: right, our default priority is "high"; everything else below that isn't shown by default | 14:09 |
| psusi | right, but even if I do a dpkg-reconfigure and ask it to show me low, nothing new shows up | 14:09 |
| psusi | seems nobody bothers writing medium or low priority questions, probably because they assume nobody will ever see them | 14:10 |
| psusi | cjwatson: rename() resulting in a file size of 0 after a crash problem that the sync patch seems to try to fix seems to have an ext4 mount option to fix: auto_da_alloc | 14:13 |
| mdeslaur | siretart`: take a look at bug #539555 | 14:35 |
| ubottu | Launchpad bug 539555 in ogmrip "mencoder crashed with SIGSEGV in x264_nal_encode()" [Undecided,New] https://launchpad.net/bugs/539555 | 14:35 |
| mdeslaur | siretart`: mplayer in lucid isn't compatible with the x264 version in lucid it appears | 14:35 |
| siretart` | mdeslaur: seems I need to backport more if not all of libmpcodecs/ve_x264.c. thanks for notifying me | 14:36 |
| siretart` | mdeslaur: btw, any news on the ffmpeg patches? | 14:37 |
| mdeslaur | siretart`: nobody assigned additional CVE numbers for the other issues. There were a couple of those CVEs that didn't seem to have patches associated to them in lucid...I was waiting to see what you thought of that | 14:38 |
| mdeslaur | siretart`: did you get a chance to look at the CVEs that didn't seem to have patches in my email? | 14:39 |
| mdeslaur | siretart`: ie: issue 16, 21 and 22? | 14:39 |
| siretart` | oh right, the ball was in my camp. sorry, I didn't find time to look up the CVE numbers. | 14:40 |
| siretart` | that time, I rather focused on roundup issue numbers and svn commits | 14:40 |
| siretart` | now I have to match theses to your issues, which is terribly time consuming :( | 14:40 |
| mdeslaur | siretart`: yeah, thanks for that | 14:40 |
| mdeslaur | siretart`: actually, I gave you the list with everything already matched up | 14:41 |
| mdeslaur | siretart`: the quoted part at the bottom of the email has the upstream commits, and the top part in my email has your corresponding patches in lucid | 14:41 |
| siretart` | that list didn't contain svn commits in trunk, did it? | 14:41 |
| mdeslaur | siretart`: yes! take a look at the quoted part at the bottom | 14:41 |
| mdeslaur | siretart`: well, it's from upstream trunk, not your repo | 14:42 |
| siretart` | yes, your mail links to mans git-svn import, that's at least straight forward to map | 14:43 |
| siretart` | yes, I'll see that I can tackle this tonight | 14:43 |
| mdeslaur | so, if we can decide what to do with the 2-3 missing patches, I'll then release updates for hardy-karmic | 14:44 |
| siretart` | great! | 14:44 |
| mdeslaur | with the existing list of CVE numbers | 14:44 |
| mdeslaur | siretart`: again, thanks for your excellent work in pulling out all the patches :) | 14:44 |
| jibel | psusi, from the tests I've done the auto_da_alloc doesn't prevent the 0 length problem, at least with dpkg | 14:52 |
| psusi | jibel: really? with data=ordered? | 14:54 |
| psusi | because the man page specifically says: This provides roughly the same level of guarantees as ext3, and avoids the "zero-length" problem that can happen when a system crashes before the delayed allocation blocks are forced to disk. | 14:57 |
| jibel | psusi, yes with data=ordered | 14:59 |
| psusi | hrm... sounds like a kernel bug then... | 15:00 |
| jibel | psusi, it's written in the man page but it doesn't in the case of dpkg. | 15:00 |
| cjwatson | there's no way dpkg can rely on kernel options anyway. | 15:01 |
| jibel | psusi, no necessarily , you'd better talk with dpkg dev who knows dpkg's code path better than me. | 15:01 |
| psusi | it should be able to rely on the filesystem not being broken though... | 15:01 |
| cjwatson | "broken" is, apparently, a matter of opinion. (yes, I know, and I have *my* opinion, but it apparently isn't shared by e.g. POSIX.) | 15:02 |
| cjwatson | this was discussed at enormously tedious length last year ... | 15:02 |
| jibel | psusi, you'll encounter this problem with all fs supporting delayed allocation. | 15:02 |
| cjwatson | I agree that enabling auto_da_alloc by default would be sane, if it isn't already | 15:03 |
| cjwatson | but if it doesn't entirely fix things for some arcane reason ... wewll | 15:03 |
| cjwatson | *well | 15:03 |
| psusi | then they are all broken... historically many applications have relied on rename() to provide an atomic replace... hell, even Microsoft wrote NTFS to detect this and make sure it worked properly | 15:04 |
| cjwatson | I agree that any filesystem that does not treat rename() this way is *at best* wilfully ignoring 40 years of Unix history | 15:04 |
| ScottK | Willfully ignoring history seems to be the order of the day (thus the KibiByte). | 15:05 |
| cjwatson | and is only useful for specially written applications | 15:05 |
| cjwatson | noting that e.g. shell scripts can't do the fsync thing | 15:05 |
| psusi | indeed... and the read only mount flag no longer meaning read ONLY | 15:05 |
| cjwatson | anyway, I stated my opinion on debian-dpkg. dpkg should do its best to mitigate these issues up to some point that doesn't kill performance too badly, but there's a point where it becomes a kernel configuration problem. | 15:07 |
| psusi | indeed | 15:07 |
| jibel | cjwatson, I totally agree | 15:07 |
| psusi | but if that mount option does not fix it then it seems it should be reported upstream as a kernel bug since it says it should | 15:07 |
| stgraber | geser: ping, DMB meeting | 15:08 |
| cjwatson | sure, somebody who has something more resembling a test case should push it upstream :) | 15:08 |
| cjwatson | I just want to make it not suck for lucid | 15:08 |
| directhex | mmm, i like the bootsplash i'm seeing on the laptop right now. the fsck message is rather more slick than it was in karmic | 15:08 |
| psusi | I guess the unfortunate thing is that relying on rename() being a barrier is itself just a workaround to the filesystem apis lacking means to control barriers | 15:10 |
| jcastro | directhex: yeah I just ran into a fsck the other day, it's quite lovely | 15:11 |
| doko | seb128: http://blogs.gnome.org/alexl/2009/09/21/archer-gdb-macros-for-glib/ are these packaged? | 15:21 |
| directhex | jcastro, haven't updated today, mind... it's a bit less pretty on the nvidia-based desktop | 15:22 |
| seb128 | doko, no | 15:22 |
| jcastro | directhex: it's a tradeoff, do I want pretty boot or vdpau ... :) | 15:23 |
| seb128 | doko, debian don't install those because they "need an experimental gdb version" | 15:23 |
| seb128 | doko, I can change that in the next upload if we want those now | 15:23 |
| doko | seb128: that would be nice | 15:23 |
| seb128 | doko, ok, will do after beta1 | 15:24 |
| amitk | Keybuk: have you had a change to look at bug 527666? | 15:30 |
| ubottu | Launchpad bug 527666 in lvm2 "LVM Not mounting in Lucid" [High,Confirmed] https://launchpad.net/bugs/527666 | 15:30 |
| Keybuk | amitk: I don't look at LVM bugs generally | 15:30 |
| amitk | Keybuk: it contains mountall with --debug info | 15:31 |
| Keybuk | so? | 15:31 |
| Keybuk | it's unlikely to be a mountall issue | 15:31 |
| Keybuk | it's more likely it's in fstab wrong, or LVM is configured wrong | 15:31 |
| amitk | Keybuk: errm, you asked for it last time it was reported on ubunt-devel | 15:31 |
| Keybuk | usually to prove it's not a mountall issue ;) | 15:32 |
| highvoltage | Keybuk: the text plymouth theme is awesome! | 15:32 |
| amitk | Keybuk: heh, ok. But 3-4 people are seeing this bug consistently. I guess I need to find someone who will look at LVM. | 15:32 |
| Keybuk | amitk: sadly, without cloning, I'm just not able to look at all of the bugs that I'm a perfect person to look at | 15:33 |
| Keybuk | there are too many bugs, and I'm the perfect person to look at too many different things | 15:33 |
| Keybuk | and I'm not sure cloning would help, I'd just end up making out with myself :p | 15:33 |
| === jamie is now known as Guest93964 | ||
| Keybuk | highvoltage: I love how many people it's confusing | 15:34 |
| cjwatson | narcissist | 15:34 |
| === beuno is now known as beuno-lunch | ||
| jcastro | plus every subsequent clone would be worse, so after 3 or 4 you'd start creating more bugs I'd guess | 15:34 |
| Keybuk | I actually had someone try and debug why the logo filename wasn't being picked up - they hadn't realised it was entirely faked :) | 15:34 |
| highvoltage | Keybuk: hah! so they thought it was like an alt="" in an <img | 15:35 |
| Keybuk | highvoltage: yes ;) | 15:35 |
| highvoltage | awesome. | 15:35 |
| Keybuk | exacty that in fact | 15:35 |
| Keybuk | I do have the VGA 16 theme working now too | 15:36 |
| Keybuk | that looks kinda neat | 15:36 |
| Keybuk | though I can't decide whether it looks better with Flloyd-Steinberg or without | 15:37 |
| * highvoltage racks brain to remember closest colour in aubergine to VGA16 | 15:37 | |
| highvoltage | to aubergine, even | 15:37 |
| Keybuk | highvoltage: just reprogram the VGA to know about aubergine | 15:37 |
| highvoltage | ah, ok. | 15:37 |
| Keybuk | though it looks quite fetching in MAGENTA http://twitpic.com/18nmqr | 15:37 |
| highvoltage | Keybuk: but that won't work on EGA displays will it!? | 15:38 |
| highvoltage | (sorry I shouldn't try to be ironic) | 15:38 |
| directhex | i get a text-only boot :( | 15:38 |
| Keybuk | highvoltage: I don't think they've ever made a 386 with EGA | 15:39 |
| highvoltage | Keybuk: I've seen some, but I'm not sure whether they were sold like that | 15:39 |
| Keybuk | for a start, I haven't seen any monitor with an old EGA connector in decades | 15:39 |
| highvoltage | yes they died out quite quickly. | 15:41 |
| ccheney | well VGA apparently came out in apr 1987 so some really old 386 had them but probably not too many | 15:41 |
| tseliot | Keybuk: maybe you can try with purple? #800080 | 15:42 |
| tseliot | i.e. 128,0,128 | 15:42 |
| amitk | kirkland: bug 527666 | 15:43 |
| ubottu | Launchpad bug 527666 in lvm2 "LVM Not mounting in Lucid" [High,Confirmed] https://launchpad.net/bugs/527666 | 15:43 |
| Keybuk | tseliot: for the vga16 stuff, I just reprogram the palette now | 15:43 |
| Keybuk | so it's ubuntu aubergine | 15:43 |
| xhaker | bdrung_: hi. is Eclipse 3.5.2 in the plan for inclusion in lucid? (noticed the merge in git) | 15:43 |
| bdrung_ | xhaker: yes | 15:43 |
| tseliot | Keybuk: ah, nice. Does the logo look ok now? | 15:44 |
| bdrung_ | xhaker: we try to release 3.5.2-1 to debian really soon and sync it then | 15:44 |
| Keybuk | tseliot: mostly, still fiddling with it | 15:44 |
| Keybuk | tseliot: haven't released it yet because there are bugs with text mode I want to fix first ;) | 15:44 |
| ccheney | anyone know how to modify a symbols file to work on multiple architectures? i backported webkit and it builds fine on amd64 but fails on i386 due to missing symbols, can i just add the i386 symbols (i would think it would then complain on amd64)? | 15:45 |
| tseliot | Keybuk: good idea ;) | 15:45 |
| siretart` | ccheney: depends :-) | 15:45 |
| cjwatson | you can put architecture tags in the symbols files if that's appropriate. see man dpkg-gensymbols | 15:46 |
| ccheney | cjwatson: thanks, guess i need to look at each arch to see what it complains about to determine what to add to its specific symbol file | 15:48 |
| siretart` | ccheney: for some libs it might be worth first checking if it really only exports symbols that are supposed to be exported | 15:51 |
| xhaker | bdrung_: thanks | 15:52 |
| ccheney | siretart`: ok | 15:52 |
| tkamppeter | pitti, hi | 15:56 |
| tkamppeter | rickspencer3, hi | 15:56 |
| rickspencer3 | hi tkamppeter | 15:57 |
| pitti | hi tkamppeter | 16:02 |
| === seb128_ is now known as seb128 | ||
| tseliot | directhex: do you know anything about #536925 ? | 16:07 |
| tkamppeter | pitti, I have seen you have worked on SRUs (moving verified packages to -updates), did you forget bug 293832? | 16:08 |
| ubottu | Launchpad bug 293832 in poppler "printer prints page at wrong position, page cut" [High,Fix committed] https://launchpad.net/bugs/293832 | 16:08 |
| directhex | bug 536925 ? | 16:09 |
| ubottu | Launchpad bug 536925 in mono "docky gmail checker is unable to connect to gnome-keyring" [Undecided,Confirmed] https://launchpad.net/bugs/536925 | 16:09 |
| directhex | tseliot, i don't know anything about it. i could take a look. the docky bug report seems entirely unhelpful | 16:10 |
| tseliot | directhex: basically it doesn't seem to be able to access gnome-keyring. Is there anything else that you need to debug it? | 16:11 |
| directhex | tseliot, running it from a console might help give some diagnostic output, but as i said, the developers seem actively unhelpful. "broken" as a term should be banned from launchpad | 16:16 |
| directhex | tseliot, i can believe that there's an incompatible change to gnome-keyring, since adobe air apps are broken, but i see no evidence of any commits to g-k-s's svn repo for about a year | 16:18 |
| pitti | tkamppeter: hm, there is no poppler upload in the queue | 16:20 |
| tseliot | directhex: the console output is here: https://bugs.launchpad.net/docky/+bug/456166/comments/12 | 16:21 |
| ubottu | Launchpad bug 456166 in docky "gmail applet doesn't work" [Low,Fix released] | 16:21 |
| tseliot | directhex: are you sure that libgnome-keyring1.0-cil hasn't changed recently? | 16:21 |
| tseliot | recently = since karmic | 16:22 |
| Laney | not substantively | 16:22 |
| directhex | tseliot, only a build fix. | 16:22 |
| tseliot | ok | 16:23 |
| directhex | http://changelogs.ubuntu.com/changelogs/pool/main/g/gnome-keyring-sharp/gnome-keyring-sharp_1.0.0-2/changelog | 16:23 |
| mathiaz | zul: hi - do you have any idea why ubuntu-server is a bug contact for the beautifulsoup package? | 16:25 |
| zul | mathiaz: because it was apart of the lucid mir spec | 16:25 |
| directhex | eek, and g-k-s is hand-rolled, not just gapi | 16:26 |
| tkamppeter | pitti, there is a debdiff of poppler, as I cannot upload poppler. | 16:29 |
| directhex | tseliot, it looks an awful lot like g-k-s 2.29 is incompatible with earlier versions, yet upstream didn't touch the soname. i.e. a big fat dollop of stupid. | 16:31 |
| tseliot | directhex: ouch | 16:32 |
| pitti | tkamppeter: ok, I'll sponsor in a bit | 16:35 |
| Keybuk | bryceh, tjaalton: can you think of any hardware that nouveau actually works on OOI? | 16:36 |
| mvo | james_w: moving to here because of the meeting in #ubuntu-desktop -- yes, I tested it a couple of times and it seems to work. I have not been able to reproduce the race so I can not say if it really fixes it, but from looking at it it appears it will | 16:36 |
| tjaalton | Keybuk: my 8600gt works | 16:43 |
| Keybuk | tjaalton: what hardware? | 16:43 |
| Keybuk | this Dell Latitude D620, with nVidia G72M (7300?) just gets corrupt screen | 16:44 |
| directhex | tseliot, developer resources will need to be spent cleaning up the g-k-s mess. but, i repeat, it's not unique to g-k-s, since adobe air apps no longer function either (as air cannot talk to the new gnome-keyring either) | 16:44 |
| tjaalton | Keybuk: it's a desktop | 16:45 |
| tjaalton | some intel chipset | 16:45 |
| tjaalton | core duo | 16:45 |
| tseliot | directhex: ok, I hope we don't release Lucid with this problem (unfortunately I wouldn't know where to begin with this bug) | 16:48 |
| tjaalton | Keybuk: try without splash, that helps some people | 16:49 |
| directhex | tseliot, assuming gnome-keyring isn't going to revert its incompatible changes, and nobody cares about the false soname it uses, then someone needs to port gnome-keyring-sharp to the new api | 16:49 |
| Keybuk | tjaalton: I'm trying to *debug* the splash! :D | 16:49 |
| tseliot | directhex: do we have a bug report filed upstream? | 16:50 |
| directhex | tseliot, which upstream? | 16:50 |
| Keybuk | tjaalton: I need to find something that nouveau modeset works on, so I can figure out why plymouth is having issues | 16:50 |
| tseliot | directhex: gnome-keyring perhaps? Or whoever works on the bindings | 16:51 |
| tjaalton | Keybuk: hah, of course :s | 16:51 |
| seb128 | hum | 16:51 |
| seb128 | Keybuk, cjwatson, slangasek: the check disk item from the livecd doesn't reboot on key press as it should, is that a known issue? | 16:52 |
| seb128 | is that a plymouth bug? | 16:52 |
| Keybuk | there's one open about that | 16:53 |
| cjwatson | it would either be plymouth or casper. there's an open bug about casper not rebooting properly at the end of installation, but I'm not sure about after CD checking | 16:53 |
| Keybuk | I think it doesn't get space or enter or something | 16:53 |
| Keybuk | but gets random other keys | 16:53 |
| seb128 | well the text says "press any key" | 16:54 |
| seb128 | or it seems to work with random keys | 16:54 |
| seb128 | Keybuk, cjwatson: ok thanks | 16:54 |
| cjwatson | I don't suppose it's in raw mode and failing to do scancode->keycode translation? | 16:54 |
| cjwatson | that's the sort of thing that could appear to permute the keymap bizarrely | 16:55 |
| Keybuk | plymouth always has the keymap in raw mode I think | 16:55 |
| doko | seb128: the glib integration should only require gdb-7.0, which is in testing as well | 16:55 |
| seb128 | doko, ok thanks | 16:56 |
| Keybuk | cjwatson, apw: so I talked to Ted about the O_PONIES, fsync, dpkg thing | 17:00 |
| Keybuk | he can think of no reason that we need an fsync() in that path, except for crash-safe-ness | 17:00 |
| Keybuk | there is absolutely no race if the power stays on | 17:00 |
| cjwatson | right, I backed out that fsync already | 17:00 |
| Keybuk | which makes sense | 17:00 |
| tkamppeter | mvo, hi | 17:01 |
| apw | Keybuk, good i was starting to think unix semantics were rubbish | 17:01 |
| cjwatson | and I mailed a long semi-rant to debian-dpkg trying to clarify the desired semantics | 17:01 |
| Keybuk | apw: I was confusing wiht the following | 17:01 |
| Keybuk | open file, write, write ... other process doesn't see anything yet | 17:01 |
| cjwatson | http://lists.debian.org/debian-dpkg/2010/03/msg00041.html | 17:01 |
| apw | yeah that makes sense | 17:01 |
| Keybuk | it might see a zero-byte file, but no data | 17:01 |
| Keybuk | but that's different | 17:01 |
| Keybuk | cjwatson: only one thing is wrong in that post | 17:07 |
| Keybuk | since Essential packages are required | 17:07 |
| Keybuk | to work at all times, even when semi-unpacked | 17:07 |
| Keybuk | -- | 17:07 |
| Keybuk | no they bloody well are not ;) | 17:07 |
| Keybuk | they are required to work when unpacked | 17:07 |
| Keybuk | not semi-unpacked | 17:07 |
| cjwatson | I wasn't sure about the exact requirement, but I know from things Ian has said in the past that the intention was to make sure that dpkg itself didn't do anything that could render your system unbootable if you had a power failure in the middle of dealing with an Essential package | 17:09 |
| cjwatson | policy says "must be available and usable on the system at all times" | 17:09 |
| cjwatson | (and qualifies that with "unconfigured (but unpacked) state", but that's the main body of the requirement) | 17:09 |
| === deryck is now known as deryck[lunch] | ||
| Keybuk | if you're semi-unpacked, you have different versions of files for the package over the filesystem | 17:11 |
| cjwatson | I didn't say it was easy, or that everything got it right :) | 17:11 |
| Keybuk | just seems a mad requirement to me | 17:11 |
| Keybuk | and since I know for a fact that dpkg itself could never survive that ... ;P | 17:11 |
| Keybuk | (dpkg and dpkg-deb tend to need to be the same version <g>) | 17:12 |
| cjwatson | most essential packages are relatively simple packages with self-contained binaries. there are a few things that are harder | 17:12 |
| Keybuk | completely aside for a moment | 17:12 |
| Keybuk | my installed cmdline was | 17:12 |
| Keybuk | append initrd=desktop/initrd.lz boot=casper netboot=nfs nfsroot=10.15.0.192:/var/lib/nfsroot/desktop only-ubiquity automatic-ubiquity debug-ubiquity ubiquity-debug file=/cdrom/daily/mario.seed quiet splash -- nouveau.modeset=0 | 17:12 |
| Keybuk | but after install, it hasn't copied nouveau.modeset=0 | 17:13 |
| Keybuk | that's a bug, right? | 17:13 |
| cjwatson | yeah, that's odd | 17:13 |
| cjwatson | definitely a bug | 17:13 |
| cjwatson | hmm, I seem to have forgotten to make that change to grub-installer | 17:13 |
| cjwatson | I think there's a bug about this already, it sounds familiar | 17:13 |
| * hyperair is looking for a kind archive admin to take care of a sync.. | 17:13 | |
| Keybuk | hyperair: we're in beta freeze | 17:14 |
| hyperair | Keybuk: does that mean no syncs? | 17:14 |
| seb128 | hyperair, syncs bypass the queue | 17:14 |
| hyperair | seb128: what queue? | 17:14 |
| seb128 | so no sync if not really required no | 17:14 |
| Keybuk | hyperair: it means follow the procedure and request through the usual channels | 17:14 |
| seb128 | hyperair, the freeze one | 17:14 |
| hyperair | ah | 17:14 |
| seb128 | hyperair, during freeze uploads go in a moderation queue | 17:15 |
| hyperair | it's banshee | 17:15 |
| cjwatson | Keybuk: I can't find the bug for this, so if you could file it on grub-installer, make it lucid/beta-2 and assign it to me, that would be good | 17:17 |
| Keybuk | sure | 17:17 |
| cjwatson | thank | 17:17 |
| cjwatson | s | 17:17 |
| Keybuk | tjaalton: so, with this card, I boot with mode setting enabled - and I just get a very pretty corrupt screen | 17:18 |
| Keybuk | tjaalton: how would I debug this? | 17:18 |
| sebner | hyperair: banshee \o/ | 17:18 |
| === zanoi_ is now known as zanoi | ||
| hyperair | =) | 17:20 |
| === sabdfl1 is now known as sabdfl | ||
| tkamppeter | pitti, hi | 17:45 |
| pitti | hi tkamppeter | 17:49 |
| tkamppeter | Any dbus expert around? | 17:51 |
| pitti | tkamppeter: what's the actual problem? | 17:53 |
| tkamppeter | pitti, I am sending a D-Bus signal: | 18:02 |
| tkamppeter | dbus-send --system --dest=com.hp.hplip --type=signal /com/hp/hplip com.hp.hplip.NeedPlugin | 18:02 |
| tkamppeter | update-notifier should catch it and start a program. This does not happen. | 18:03 |
| tkamppeter | pitti, for you to test it, do "sudo -s", then "echo /usr/bin/gedit > /usr/bin/hplip-plugin-ubuntu" and then "exit"/ | 18:04 |
| tkamppeter | and sudo chmod +x /usr/bin/hplip-plugin-ubuntu | 18:05 |
| pitti | tkamppeter: why would u-n catch a signal sent to hplip? | 18:05 |
| tkamppeter | pitti, update notifier has the following code: http://pastebin.ubuntu.com/396286/ | 18:07 |
| tkamppeter | AFAI understand, the hplip_init() function, which is called when update-notifier starts, makes a D-Bus Listener out of update-notifgier. | 18:08 |
| seb128 | tkamppeter, hi | 18:08 |
| seb128 | tkamppeter, have you seen bug #530218? | 18:08 |
| tkamppeter | update-notifier runs as a daemon, with my user rights. | 18:08 |
| tkamppeter | Seems that ubottu has left for the day ... | 18:09 |
| ubottu | Launchpad bug 530218 in system-config-printer "PrinterDriversInstaller service: AccessDenied error" [Low,Confirmed] https://launchpad.net/bugs/530218 | 18:10 |
| tkamppeter | seb128, I did not change anything on the DBus mechanisms of s-c-p, seems that some policies of our distro have changed. | 18:10 |
| tkamppeter | pitti, is this D-Bus code correct? | 18:10 |
| mdeslaur | a|wen: I was just building the mediawiki packages :) | 18:11 |
| mdeslaur | a|wen: is only hardy and intrepid affected by the regression? | 18:11 |
| tkamppeter | And also the command? | 18:11 |
| tkamppeter | pitti, I have also tried | 18:11 |
| tkamppeter | dbus-send --system --dest=com.hp.hplip --print-reply --type=signal /com/hp/hplip com.hp.hplip.NeedPlugin | 18:12 |
| tkamppeter | and then dbus-send hangs until a timeout happens. | 18:12 |
| === deryck[lunch] is now known as deryck | ||
| a|wen | mdeslaur: cool :) the fix was introduced by the CVE-2009-0737 fix present in hardy, intrepid and jaunty ... i'm looking into jaunty now | 18:13 |
| ubottu | Multiple cross-site scripting (XSS) vulnerabilities in the web-based installer (config/index.php) in MediaWiki 1.6 before 1.6.12, 1.12 before 1.12.4, and 1.13 before 1.13.4, when the installer is in active use, allow remote attackers to inject arbitrary web script or HTML via unspecified vectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0737) | 18:13 |
| mterry | slangasek, in recent cryptsetup, you added a hard dependency on plymouth. To reduce extra messages to the console, apparently. Can that not be done in a less plymouth-inducing way? | 18:17 |
| mdeslaur | a|wen: hmm...the part of the patch you are removing is present in karmic and lucid...do you not need to encode $conf->DBtype? | 18:18 |
| cjwatson | mterry: plymouth doesn't necessarily mean splash screen. its purpose is in part to be a multiplexer for user interaction during boot, and we don't want to have multiple paths for that since it tends to create bugs | 18:26 |
| mterry | cjwatson, understood. I'm working on a project that doesn't want plymouth, so I was curious why the decidedly non-dependency was listed as such. Seems like an issue for seeds, not fake Depends | 18:27 |
| jdong | it's not a fake Depend if the upstart job / init script logs startup items via plymouth... | 18:28 |
| Keybuk | mterry: why don't you want plymouth? | 18:29 |
| mterry | jdong, oh, I didn't notice it doing that | 18:29 |
| persia | mterry: Can you just use a text theme and pretend? | 18:29 |
| mterry | Ideally I'd use plymouth. But for the nonce I'm not. And was curious why cryptsetup was requiring it. Regardless of why I don't want plymouth, I think the critique stands | 18:30 |
| tkamppeter | pitti, still there? | 18:30 |
| a|wen | mdeslaur: the variable is already being quoted in config/index.php in hardy/intrepid while it isn't in the newer versions; looks like the handling has changed between 1.12 and 1.13... removing the quoting could work as well afaict; maybe that indeed is a better approach | 18:31 |
| Keybuk | mterry: because we use plymouth to marshal input and output of the console during boot | 18:31 |
| Keybuk | cryptsetup is run asynchronously on block device detection | 18:31 |
| Keybuk | so you may need to ask for the passphrase for two different devices at the same time | 18:31 |
| Keybuk | meanwhile mountall might be running fsck on a third block device | 18:31 |
| Keybuk | so needs to display progress | 18:31 |
| Keybuk | or may even need to tell you fsck failed, and ask whether you'd like to try again with --fix | 18:32 |
| a|wen | mdeslaur: just tested; jaunty isn't affected | 18:32 |
| Keybuk | plymouth deals with that for us | 18:32 |
| Keybuk | we ask plymouth to ask | 18:32 |
| Keybuk | it queues up the things wanting input | 18:32 |
| Keybuk | and ensures things are displayed at different points on the screen | 18:32 |
| Keybuk | it's one of the *main* reasons we're using it | 18:32 |
| mterry | Keybuk, yar. I agree those are all good arguments for why I should be using plymouth. But not quite for why cryptsetup should hard-depend it | 18:32 |
| mterry | Keybuk, vs, say the seed | 18:33 |
| directhex | tseliot, i have a VERY full timetable this evening, but i'll try to look at g-k-s later | 18:33 |
| mterry | Keybuk, unless asking for input just doesn't work at all without plymouth? | 18:33 |
| Keybuk | mterry: because cryptsetup hard-depends on it | 18:33 |
| Keybuk | all of the methods of asking for input without plymouth *cause* bugs | 18:34 |
| Keybuk | so we've removed them | 18:34 |
| Keybuk | ie. "crash your X server" bugs | 18:34 |
| mterry | Keybuk, oh. my quick grepping indicated it was always careful to [ -x /usr/bin/plymouth ] | 18:34 |
| mterry | Keybuk, i see | 18:34 |
| Keybuk | so you want plymouth :p | 18:36 |
| highvoltage | Keybuk: any chance you could smack together some documentation or quick notes so that we can get the plymouth (and text-based plymouth) right for Edubuntu? | 18:38 |
| mdeslaur | a|wen: I can't seem to locate where you say it's already being quoted in intrepid... | 18:38 |
| * directhex is on text-based. sniff. | 18:38 | |
| Keybuk | highvoltage: see the log of this chanel | 18:38 |
| Keybuk | earlier today | 18:38 |
| highvoltage | Keybuk: ok, will do | 18:38 |
| Keybuk | or the log of -desktop within the last hour | 18:39 |
| a|wen | mdeslaur: in toggleDBarea('<?php echo Xml::encodeJsVar( $conf->DBtype ); ?>', ... Xml::encodeJsVar( $conf->DBtype ) does in itself quote the variable | 18:40 |
| mdeslaur | a|wen: but, that's the part your updated patch is removing | 18:41 |
| JFo | pitti, had another bug reporter send me an odd error when trying apport-collect. I just sent it out via our e-mail thread from the other day. | 18:41 |
| mdeslaur | a|wen: you're changing it back to: toggleDBarea('<?php echo $conf->DBtype; ?>' | 18:42 |
| * psusi wonders why /etc/init/failsafe-x.conf is installed on server with no x or gdm | 18:43 | |
| a|wen | mdeslaur: true; there is two options to fixing the regression ... either we should skip the Xml::encodeJsVar or we should skip the quoting (in jaunty onwards the quoting is gone) ... currently i prepared the first option, but i'm considering if the second might be better | 18:43 |
| === yofel_ is now known as yofel | ||
| a|wen | mdeslaur: i'll prepare a new set of patches using the second option and test them | 18:47 |
| mdeslaur | a|wen: ok, cool. | 18:47 |
| genii | Is there any plan to configure IRC default channel by way of localisation? eg: spanish install goes to #ubuntu-es etc etc ? | 18:49 |
| kklimonda | I use Linux at work, and have a Mac at home, and there is a lightyear sized gap between the two in useability. Example - I'm trying to set up an IRC chat program for a friend. I click on an "import accounts" button to transfer accoutns from another chat app already on the system. Nothing happens. No message, no indication that there was a problem, nothing. | 18:52 |
| zyga | mvo: hi | 18:52 |
| kklimonda | oh crap.. | 18:52 |
| kklimonda | sorry | 18:52 |
| zyga | mvo: do you have the time to help me with the UVF exception process we talked about last time? | 18:53 |
| pitti | ev: I'm not quite sure what bug 537986 is about -- what is the "superfluous help text"? isn't that a label as well? | 19:02 |
| ubottu | Launchpad bug 537986 in ubiquity "Freeze exception request: inactive labels on the user setup page." [Undecided,New] https://launchpad.net/bugs/537986 | 19:02 |
| tjaalton | Keybuk: I haven't done much kms debugging, but unless it's completely hung maybe a sysrq-trace might give some ideas? | 19:03 |
| pitti | ev: and since the screenshot also has a label with an explanatory text, how does it differ in practice? | 19:03 |
| tseliot | directhex: thanks a lot | 19:03 |
| pitti | ev: oh, nevermind, I understand | 19:04 |
| a|wen | mdeslaur: new version of the regression fixes uploaded to bug 537974 | 19:05 |
| ubottu | Launchpad bug 537974 in mediawiki "1.15.2 security update released; CSS validation issue" [Undecided,Confirmed] https://launchpad.net/bugs/537974 | 19:05 |
| tjaalton | psusi: because it's installed by x11-common, which belongs to the standard task | 19:05 |
| Keybuk | tjaalton: bryce thinks it's a modeline isasue | 19:05 |
| tjaalton | Keybuk: but if kms works without plymouth? | 19:05 |
| mdeslaur | thanks a|wen | 19:06 |
| Keybuk | tjaalton: kms does not work at all | 19:06 |
| tjaalton | Keybuk: ok then :) | 19:06 |
| Keybuk | bug #539730 fwiw | 19:06 |
| ubottu | Launchpad bug 539730 in xserver-xorg-video-nouveau "[G72M] Screen corruption when using KMS. Dell Latitude D620 / Quadro NVS 110M/GeForce Go 7300" [Undecided,New] https://launchpad.net/bugs/539730 | 19:06 |
| mvo | zyga: yes, let me quickly check the bug reference again | 19:08 |
| tkamppeter | mvo, hi | 19:11 |
| mvo | tkamppeter: hello | 19:11 |
| zyga | mvo: thanks! it's bug 538306 | 19:11 |
| ubottu | Launchpad bug 538306 in command-not-found "[ffe] command-not-found 0.2.41" [Wishlist,New] https://launchpad.net/bugs/538306 | 19:11 |
| persia | genii: It would need a patch to each IRC client. Needs a bug for discussion. | 19:12 |
| zyga | mvo: BTW if it's too late today we can postpone this, I understand, people have life apart from their fun/work/etc :-) | 19:12 |
| mvo | zyga: no worries, should be ok now. I think the outstanding items are "does it build, install/upgrade, not break" | 19:13 |
| mvo | zyga: the later one is a non-issue because command-not-found has no rdepends | 19:14 |
| zyga | mvo: right, okay, should I put a link to the ppa? | 19:14 |
| mvo | zyga: yes | 19:14 |
| zyga | the upgrade process could do one more thing though | 19:14 |
| mvo | zyga: and maybe a script(1) log of installing it | 19:14 |
| mvo | and that it does not fail then | 19:14 |
| zyga | it could move the barely used .command-not-found.blacklist to XDG_CONF_DIR/commant-not-found/blacklist.conf | 19:15 |
| zyga | but the old path is still supported | 19:15 |
| zyga | so this step is not required, just it could be a tiny bit better | 19:15 |
| zyga | hmm, I'll check out script | 19:15 |
| zyga | what about pbuilder? | 19:15 |
| tjaalton | Keybuk: yeah the timings are probably wrong | 19:17 |
| tkamppeter | mvo, I have a problem with update-notifier, it does not react to the D-0Bus signal of HPLIP. | 19:18 |
| Keybuk | tjaalton: that's just trial-and-error to get right though isn't it? :-/ | 19:18 |
| mvo | zyga: script would just create a "log" that installing from the PPA works just fine, pbuilder is not needed, the ppa builds it already in a pbuilder like environment | 19:19 |
| tjaalton | Keybuk: well the devs probably know best.. too bad it's hard to test mainline .34rc1 because the api changed so you'd need to update libdrm and -nouveau too | 19:20 |
| zyga | mvo: ok, I'll post a apt-get dist-upgrade session with to ppa package and point to the archive, do you think that is all I should add> | 19:20 |
| mvo | tkamppeter: hm, I think it needs a slightly different way to send the singal from hplip. did you had a chance to discuss this with upstrema yet? | 19:20 |
| mvo | tkamppeter: are they fine with us adding a "official" signal? | 19:20 |
| mvo | zyga: I think that should be enough | 19:21 |
| mvo | zyga: let me know when its there, I will add a note too | 19:21 |
| zyga | ok thanks, let me add those changes now | 19:21 |
| slangasek | mterry: short of a plymouth magic patch to capture and eat all console messages, no, it can't | 19:21 |
| tjaalton | Keybuk: (noticed you were asking for it on #u-k) | 19:22 |
| Keybuk | tjaalton: yeah, even .33 would be nice | 19:22 |
| Keybuk | but apparently we don't build our mainline kernels against the lucid config | 19:23 |
| Keybuk | which I keep forgetting | 19:23 |
| Keybuk | slangasek: there is that magic, I just haven't turned it on yet | 19:23 |
| tjaalton | why does it matter? | 19:23 |
| tjaalton | .33 mainline should work fine | 19:23 |
| Keybuk | tjaalton: because karmic's config doesn't enable nouveau, amongst other things | 19:23 |
| tjaalton | karmic? | 19:23 |
| slangasek | ah, didn't know it was written | 19:23 |
| tjaalton | Keybuk: oh, the mainline config doesn't, yes | 19:24 |
| Keybuk | slangasek: yeah, it redirects console output into /var/log/boot.log | 19:24 |
| tkamppeter | mvo, I think I should get the full chain working and then I send a patch to upstream. | 19:26 |
| tjaalton | Keybuk: just to make sure; it's the same without splash? | 19:27 |
| tkamppeter | mvo, currently I send the signal via | 19:27 |
| tkamppeter | mvo: dbus-send --system --dest=com.hp.hplip --type=signal /com/hp/hplip com.hp.hplip.NeedPlugin | 19:27 |
| tkamppeter | The command runs as root. | 19:27 |
| psusi | hrm... is there no way to query init for what events a job is waiting for? or do you just have to read the conf file? | 19:28 |
| tkamppeter | mvo: To avoid adding another library dependency, I let HPLIP run this command line. | 19:28 |
| mvo | tkamppeter: right, I think the best way is to run it via the existing dbus service that hplip already ships, but that needs a bit of work on the hplip code. I'm currently looking at bug #516727, but when I finished with that I can have another look | 19:30 |
| ubottu | Launchpad bug 516727 in apt "breaks dist-upgrade: E: Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle." [Critical,Triaged] https://launchpad.net/bugs/516727 | 19:30 |
| === radoe_ is now known as radoe | ||
| === beuno-lunch is now known as beuno | ||
| Caesar | slangasek: what do you think about bug 539814 in terms of severity? | 19:36 |
| ubottu | Launchpad bug 539814 in tar "Impossible to bootstrap Lucid on Dapper" [Undecided,New] https://launchpad.net/bugs/539814 | 19:36 |
| Keybuk | tjaalton: yes ;p | 19:37 |
| slangasek | Caesar: middling | 19:37 |
| slangasek | Caesar: certainly not a beta-1 blocker | 19:37 |
| Caesar | I'm chatting to bdale now to see if it can get fixed in sid | 19:37 |
| slangasek | pitti: bug #539742 seems to be the same as the earlier "plymouthd still running" apport reports, except it didn't match the bug pattern and also doesn't include the new information from the updated hook? | 19:38 |
| ubottu | Launchpad bug 539742 in plymouth "does not terminate at computer shutdown" [Undecided,New] https://launchpad.net/bugs/539742 | 19:38 |
| Caesar | Actually, it might be fixed in sid already | 19:38 |
| zyga | mvo: as for c-n-f if the freeze exception works and we get 0.2.41 in the beta this will be a good way of checking if my choice of having auto-install option default to 'ask' was a good idea | 19:39 |
| slangasek | Caesar: from lamont, I recall that there are other bits of lucid that are unhappy on a dapper kernel, fwiw | 19:39 |
| slangasek | I think the solution there was "go through a lot of pain to get a hardy kernel running on the powerpc buildds" | 19:39 |
| Caesar | Fun | 19:39 |
| tjaalton | Keybuk: ok.. but did kms ever work with these? | 19:40 |
| Keybuk | tjaalton: with this machine? not that I know of | 19:41 |
| tjaalton | Keybuk: what about the ati? | 19:41 |
| Keybuk | tjaalton: likewise, not that I know of | 19:41 |
| Keybuk | both worked in karmic | 19:41 |
| tjaalton | ok | 19:41 |
| Keybuk | but in lucid, neither works | 19:41 |
| lamont | slangasek: karmic, actually | 19:42 |
| slangasek | lamont: mmk | 19:42 |
| lamont | amusingly, the only machine that hates that kernel is davis | 19:42 |
| NCommander | lamont: what was the problem with karmic/lucid on davis? Oops? | 19:42 |
| Caesar | slangasek: I think this particular issue is fixed in sid's tar (1.23) | 19:43 |
| lamont | NCommander: yep. and if you can tell me how to get a serial console on the box, I'll capture the oops output for you | 19:43 |
| NCommander | lamont: is the serial port seen in dmesg? (or is /dev/ttyS0 exist?) | 19:43 |
| lamont | yep | 19:44 |
| tjaalton | Keybuk: you can try .33 mainline with ati though | 19:44 |
| Keybuk | tjaalton: I can ;) | 19:45 |
| NCommander | lamont: https://help.ubuntu.com/community/SerialConsoleHowto | 19:45 |
| kklimonda | has the UnitsPolicy been discussed with other distributions and is a coordinated plan or are we doing that alone? | 19:48 |
| lamont | NCommander: that's great. now answer the question for yaboot | 19:48 |
| NCommander | lamont: you want the bootloader on serial? That requires a trip to OpenFirmware land | 19:48 |
| NCommander | lamont: power cycle the machine and hold down option-command-o-f to get to the 0 > prompt | 19:49 |
| Keybuk | tjaalton: though I have to share a power supply between the two boxes | 19:49 |
| Keybuk | so I wanted to drain debugging on this one at least first | 19:49 |
| Caesar | slangasek: I plonked tar 1.23-1 into the chroot and that worked | 19:49 |
| lamont | NCommander: I don't recall all the iterations I went through trying to get there. I do recall that it's annoying needing to wait for someone to get back to the data center to boot it because you can't adequately recover from just a remote console over kvm | 19:49 |
| tjaalton | Keybuk: you can ask darktama on #dri-devel about the nouveau if you like | 19:49 |
| NCommander | lamont: you have to set the output-device in openfirmware to ttya I believe on xserves | 19:49 |
| Keybuk | tjaalton: I asked on #nouveau - no reply yet | 19:50 |
| Keybuk | (not directly at darktama) | 19:50 |
| Caesar | So I guess I should turn bug 539814 into a sync request for tar? | 19:50 |
| ubottu | Launchpad bug 539814 in tar "Impossible to bootstrap Lucid on Dapper" [Undecided,New] https://launchpad.net/bugs/539814 | 19:50 |
| tjaalton | Keybuk: ah ok, yeah I asked on #dri-devel and airlied pinged darktama, think he's away atm | 19:50 |
| NCommander | lamont: actually, you don't need OF access | 19:51 |
| lamont | NCommander: it's a bit below my radar since the buildds have been surviving just fine with it. | 19:52 |
| NCommander | lamont: well with OF and yaboot over serial (which a google search confirmed works properly on xserves), you shouldn't ever need anyone to remotely manage unless the battery goes dead :-/ | 19:53 |
| lamont | or the case is opened.. or... :-( | 19:54 |
| lamont | but yeah, some specific education in that regard would not be amiss | 19:54 |
| lamont | and I might even make time to test taht | 19:55 |
| lamont | esp if we can get the thing to oops again | 19:55 |
| pitti | slangasek: hm, that's strange indeed -- I'll investigate the pattern failure first | 19:57 |
| pitti | slangasek: hm, weird; it seems to work for me here; I guess one could workaround that check by collecting information on an offline system, and reporting the .crash file from another one | 20:04 |
| pitti | but that's not very likely | 20:04 |
| pitti | I'll ask in the bug | 20:04 |
| kees | lool, persia: either of you around and got a running qemu armel image? nothing I try works. :( | 20:13 |
| superm1 | pitti, re bug 537986, i believe it's to remove the really wordy labels that accompany the dialogs in exchange for labels that only show up in gray on the text boxes when the text boxes are empty | 20:19 |
| ubottu | Launchpad bug 537986 in ubiquity "Freeze exception request: inactive labels on the user setup page." [Undecided,New] https://launchpad.net/bugs/537986 | 20:19 |
| pitti | superm1: right, I figured that out 30 secs after pinging ev.. but thanks for confirming | 20:20 |
| NCommander | lamont: maybe during UDS if there isn't a rush to force something newer on that box | 20:33 |
| lamont | it'll almost certainly have lucid by that point | 20:35 |
| psusi | why are there multiple ttyX.conf files in /etc/init? can't a single conf file manage multiple instances? | 20:38 |
| Keybuk | yes | 20:39 |
| Keybuk | hysterical raisins mostly | 20:39 |
| psusi | lol... Mmm... raisins... | 20:39 |
| psusi | Keybuk: there's no secret switch to initctl status to list exactly what the events are that the job is waiting for is there? ;) | 20:41 |
| Keybuk | psusi: no, but I do intend to write one | 20:41 |
| Keybuk | I can tell you how to find out | 20:41 |
| psusi | heheh, would be nice ;) | 20:41 |
| Keybuk | as long as you promise to tell *nobody* | 20:41 |
| Keybuk | especially not kees | 20:42 |
| psusi | lol | 20:42 |
| psusi | ok? | 20:42 |
| Keybuk | what you need to is write an upstart .conf file | 20:42 |
| Keybuk | that crashes upstart | 20:42 |
| Keybuk | but crashes it in the child when you try and run it | 20:42 |
| Keybuk | then you have a core file with all the init daemon state in it <g> | 20:42 |
| psusi | rofl | 20:42 |
| Keybuk | exec a path that doesn't exist seems to work well atm | 20:42 |
| Keybuk | you may need "expect fork" in there, depending on the version of upstart | 20:43 |
| psusi | kill -ABORT, heh | 20:43 |
| Keybuk | exactly | 20:43 |
| Keybuk | or just drive it against an assertion | 20:43 |
| Keybuk | if you can predict the pids, it's even better | 20:44 |
| Keybuk | you can attach gdb to it | 20:44 |
| Keybuk | and then you have a live process you can do things like | 20:44 |
| Keybuk | (gdb) p job_hash_lookup (...) | 20:44 |
| Keybuk | against | 20:44 |
| * kees looks around for target of great vengence and furious anger | 20:44 | |
| Keybuk | that's what I tend to do | 20:44 |
| psusi | hrm... I'm a bit confused... I thought an event was implemented internally as a job with no main process, so once an event has fired, it should still show up as a job in the started/running state? | 20:44 |
| Keybuk | no | 20:44 |
| Keybuk | you're confusing events and jobs | 20:45 |
| Keybuk | they're completely different | 20:45 |
| psusi | ahh, yep, that explains it... | 20:45 |
| * kees doesn't know why he'd be upset about init children dumping core. | 20:45 | |
| lamont | kees: because root could pwn the box? | 20:46 |
| lamont | oh wait. nm. :-D | 20:46 |
| kees | 'zactly | 20:47 |
| Keybuk | kees: I'm just invoking you | 20:53 |
| Keybuk | because you seemed to like it so much yesterday :p | 20:53 |
| Keybuk | it's fun | 20:53 |
| \sh | hmmm...I hope I didn't blow up our production environment right now with my puppet script | 20:54 |
| kees | Keybuk: yup, I just need to formalize my strike-from-above phrases | 21:02 |
| lool | kees: Sure | 21:03 |
| kees | lool: what is the magic? I'm ready to learn | 21:03 |
| Keybuk | kees: I have a manual override built into the ion cannon control | 21:04 |
| Keybuk | it's linked to my foursquare account | 21:04 |
| lool | kees: https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap | 21:04 |
| kees | Keybuk: haha | 21:04 |
| Keybuk | you can't fire it within 5 miles of my current location | 21:04 |
| lool | kees: rootstock does basically that behind the scenes | 21:04 |
| lool | kees: I start my rootfs with qemu-system-arm -m 256 -drive file=lucid.img,media=disk -M versatilepb -cpu cortex-a8 -kernel linux-image-2.6.32-16-versatile_2.6.32-16.24/boot/vmlinuz-2.6.32-16-versatile -append 'root=/dev/sda rootwait' | 21:04 |
| kees | Keybuk: I guess I'll use "beam weapon charging" for now | 21:04 |
| lool | kees: I can upload the rootfs, but will take me a whilke | 21:04 |
| lool | and it has installed crap in it | 21:04 |
| * lool starts rsync | 21:05 | |
| kees | lool: I think it's the kernel that isn't working for me. | 21:05 |
| lool | kees: just qemu-system-arm -m 256 -kernel <versatile-vmlinuz-from-lucid> -cpu cortex-a8 should work | 21:06 |
| lool | kees: It might help to use serial console mode to see some debug messages, but really that should give you a SDL window with the fb output | 21:06 |
| kees | lool: so not wget http://people.canonical.com/~lool/versatile-cortex-a8-zImage ? | 21:06 |
| lool | kees: Oh no | 21:07 |
| lool | kees: Well that might work | 21:07 |
| kees | it's what the wiki says? | 21:07 |
| kees | lool: which kernel image URL should I use? | 21:07 |
| lool | kees: Sorry, it might work, not sure, but it's best to use the lucid one | 21:07 |
| lool | http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/ | 21:07 |
| psusi | Keybuk: rc-sysinit.conf tests for FROM_SINGLE_USER_MODE... it looks like that's how rcS tells rc that the system has already been initialized, but I can't see any way for rc-sysinit to run with FROM_SINGLE_USER_MODE=y | 21:07 |
| lool | kees: Will update wiki, thanks | 21:07 |
| lool | kees: image wasn't available back then | 21:07 |
| Keybuk | psusi: did you read rcS.conf ? | 21:08 |
| kees | lool: okay | 21:08 |
| lool | kees: updated, thanks | 21:08 |
| psusi | Keybuk: yes... it sets it when it switches to another mode, but AFAICS, switching to another mode invokes rc.conf, not rc-sysinit.conf | 21:08 |
| kees | lool: how does the initrd figure in? | 21:08 |
| lool | kees: You can also unpack the vmlinuz from the linux-image-versatile.deb obviously, and you'll find modules in there as well | 21:08 |
| lool | kees: Sadly, initrds are borken (help welcome!) as well as initramfs | 21:09 |
| lool | kees: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/524893 | 21:09 |
| ubottu | Ubuntu bug 524893 in qemu-kvm "versatile: Can't boot initramfses" [Low,In progress] | 21:09 |
| Keybuk | psusi: could you read the line out to the class? | 21:09 |
| lool | I suspect our kernel is too big for the memory map assumptions, or something like that | 21:09 |
| kees | lool: so what's the right way to boot a live environment? | 21:10 |
| lool | (but I looked at the memory map and it seemed to leave plenty of space) | 21:10 |
| slangasek | pitti: well, bug #539869 is another one | 21:10 |
| ubottu | Launchpad bug 539869 in plymouth "does not terminate at computer shutdown (dup-of: 537262)" [Undecided,New] https://launchpad.net/bugs/539869 | 21:10 |
| lool | kees: Currently none, you could try with kexec though | 21:10 |
| ubottu | Launchpad bug 537262 in plymouth "plymouth pid missing from OMITPIDS and terminated by sendsigs" [High,Confirmed] https://launchpad.net/bugs/537262 | 21:10 |
| slangasek | pitti: oh, you already triaged that ;) | 21:10 |
| lool | kees: Do you mean a live env as in casper, or just a real system? | 21:10 |
| lool | kees: Cause the kernel can boot a real system just fine, even without initrd | 21:10 |
| psusi | Keybuk: which line? you mean start --no-wait rc-sysinit FROM_SINGLE_USER_MODE=y | 21:10 |
| pitti | slangasek: that one at least has Processes.txt and InitctlList.txt | 21:10 |
| kees | lool: either, preferrably a real system | 21:10 |
| lool | kees: casper does need initrd though | 21:11 |
| pitti | slangasek: I was looking at https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=shutdown-hang&orderby=targetname and duplicating a few | 21:11 |
| lool | kees: Oh just as I wrote with lucid.img earlier | 21:11 |
| kees | lool: okay, so convert a debootstrapped system into an image, and boot that? | 21:11 |
| * psusi facepalms | 21:11 | |
| pitti | slangasek: but it seems this is now going from a little bug fix to a major project.. | 21:11 |
| lool | kees: exactly | 21:11 |
| * kees attempts to trick qemu-nbd into working... | 21:11 | |
| lool | kees: The page has the low level instructions, rootstock does the same thing as a script and outputs either an img or a tgz | 21:11 |
| pitti | slangasek: I think we should probably disable this hook again after beta; it helped us to discover the plymouth issue (which really makes things worse), but the others are just too many; I've seen a couple of frozen mount processes or blkid, etc. (in "D" state) | 21:12 |
| lool | kees: I'm uploading my fs, but will take a long while | 21:12 |
| slangasek | pitti: huh, yes - and the initctllist.txt and process.txt there show the correct behavior | 21:12 |
| lool | kees: Do you get fb output with the lucid kernels? | 21:12 |
| slangasek | pitti: yep - hung mount processes are probably a network teardown issue | 21:12 |
| slangasek | not something we need every user hitting it to be bothered with | 21:12 |
| kees | lool: I did this time finally. | 21:12 |
| psusi | ohh, I see.... it fires back to rc-sysinit so it can figure out what the runlevel should transition to | 21:13 |
| pitti | slangasek: right, plymouth is running, but it fails to get added to $OMITPIDS | 21:13 |
| slangasek | pitti: yes, but *not* because of a bug in 'initctl list', according to this output | 21:13 |
| lool | kees: Great; sorry about the link to an obsolete kernel which was on this page I pointed at | 21:13 |
| pitti | slangasek: hm, indeed; so it seems it's not a duplicate after all | 21:14 |
| kees | lool: does qemu-nbd work for you? | 21:14 |
| lool | kees: Happy to hear if you're stuck on any subsequent part of the install | 21:14 |
| lool | kees: I'm not using it; I think I heard mention of it recently, but I don't remember in which context | 21:14 |
| lool | kees: I think virtio could technically work for qemu disks, but my attempts at forcing it into arm kernels resulted in OOPSes | 21:15 |
| kees | kirkland: have you used nbd recently? it seems to just hang for me? | 21:15 |
| slangasek | pitti: no, I think it is a duplicate, it just doesn't appear to be an upstart or plymouth bug :) | 21:15 |
| lool | I'm not much of a kernel developer I'm afraid | 21:15 |
| Keybuk | psusi: the one that says how rc-sysinit is started, and how that environment variable is passed to it, yes | 21:15 |
| Keybuk | pitti: I've had reports of that from lots of things now | 21:15 |
| pitti | slangasek: OTOH that initctl list is not the same as the sendsigs script is calling, but a new call from the apport hook | 21:15 |
| Keybuk | pitti: there's one on udev for example | 21:15 |
| pitti | Keybuk: yes, and I saw a hung blkid, etc. | 21:15 |
| kees | kirkland: nevermind, PEBKAC | 21:16 |
| Keybuk | but I do also see plymouth getting SIGKILL'd by sendsigs | 21:16 |
| pitti | Keybuk: I'll do a round of triaging on those after beta-1; I guess we should disable the apport hook soon again, too | 21:16 |
| lool | kees: ogra mentionned qemu-nbd on #ubuntu-arm recently, but had some issues as well; perhaps check with him | 21:16 |
| slangasek | pitti: uh, grr then - I think we need it to be the same call to have reliable bug reports | 21:16 |
| Keybuk | so sabdfl's slow shut down one evening has led us to finding a whole undiscovered nest of bugs under a rock | 21:16 |
| slangasek | pitti: because if there *is* an initctl bug, it's almost certainly racy | 21:16 |
| Keybuk | I doubt it's an initctl bug per se, that's just talking d-bus | 21:17 |
| pitti | slangasek: well, OmitPids is by and large the output from it, too | 21:17 |
| psusi | Keybuk: is the event case sensitive? i.e. is start on runlevel S the same as start on runlevel s? | 21:17 |
| Keybuk | sounds more like an upstart bug | 21:17 |
| Keybuk | psusi: yes | 21:17 |
| psusi | Keybuk: then it looks like runlevel s and runlevel S are handled slightly differnetly... | 21:17 |
| slangasek | pitti: yes, but the question is, why is it *different* between the two runs | 21:17 |
| slangasek | pitti: if it's a race, then showing that it *is* different between two runs doesn't help us debug | 21:18 |
| pitti | *nod* | 21:18 |
| pitti | what might help is a set -x output from sendsigs itself | 21:18 |
| pitti | I used that a lot for debugging | 21:19 |
| Keybuk | psusi: no | 21:19 |
| kees | lool: I, uh, forgot to partition the lucid.img so my nbd devices didn't have any partitions. *hang head* | 21:19 |
| Keybuk | psusi: there is no runlevel s only zuul | 21:19 |
| Keybuk | err, I mean runlevel S | 21:19 |
| pitti | but even that wouldn't give us new info about a potential race | 21:19 |
| psusi | Keybuk: it looks to me like rcS.conf only runs for runlevel S, which you get either by passing the kernel S or single, or -s | 21:19 |
| psusi | but if you pass s then rcS.conf won't run? | 21:20 |
| Keybuk | psusi: no... | 21:20 |
| Keybuk | psusi: seriously, do you bother reading any code before you assume bugs? :p | 21:20 |
| psusi | lol... I'm reading and trying to follow along, but it isn't easy ;) | 21:21 |
| Keybuk | go read util/telinit.c in upstart | 21:21 |
| Keybuk | case 'S': | 21:21 |
| Keybuk | case 's': | 21:21 |
| Keybuk | ret = sysv_change_runlevel ('S', extra_env, NULL, NULL); | 21:21 |
| Keybuk | break; | 21:21 |
| Keybuk | ^ that bit specifically | 21:21 |
| psusi | ahh, ok... so telinit forces it to uppercase | 21:21 |
| lool | kees: bah I don't partition my drives either | 21:22 |
| lool | hence root=/dev/sda | 21:22 |
| Keybuk | slangasek: I'm not sure where this bug lies | 21:22 |
| Keybuk | it sounds like it could be upstart forgetting pids | 21:22 |
| * psusi wonders if he could do it with initctl emit runlevel s ;) | 21:23 | |
| Keybuk | but it also sounds like it could be sendsigs not parsing initctl output right, so killing them anyway | 21:23 |
| Keybuk | psusi: you can do that, but it won't get converted to uppercase | 21:23 |
| Keybuk | psusi: and you're missing the environment | 21:23 |
| slangasek | Keybuk: well, we know upstart hasn't forgotten them permanently, because when apport calls 'initctl list' again, the PID is there :) | 21:23 |
| Keybuk | psusi: initctl emit runlevel RUNLEVEL=S PREVLEVEL= is basically all "telinit S" does | 21:23 |
| psusi | Keybuk: that's what I'm trying to do... get into runlevel 's' not 'S', hehe | 21:23 |
| Keybuk | err | 21:23 |
| Keybuk | psusi: initctl emit runlevel RUNLEVEL=S PREVLEVEL=$RUNLEVEL | 21:23 |
| Keybuk | psusi: there is no 's' | 21:23 |
| Keybuk | slangasek: oh, now that's more interesting - I hadn't got that bit | 21:24 |
| slangasek | Keybuk: another possibility is that it's a race condition where plymouth has started *after* sendsigs has called initctl list | 21:24 |
| Keybuk | slangasek: possible, but then it's starting very late | 21:24 |
| slangasek | then calls ps, at which point plymouthd is there | 21:24 |
| Keybuk | slangasek: and that wouldn't explain the udev bug ;-) | 21:24 |
| Keybuk | which is certainly not started on shutdown <g> | 21:24 |
| slangasek | ah, hadn't seen the udev bug | 21:24 |
| Keybuk | yeah udevd -> didn't close on shutdown | 21:24 |
| psusi | Keybuk: well, yea that's one way of looking at it... but an emit runlevel s would get you into runlevel s, just no jobs run in runlevel s, right? | 21:25 |
| * kees stabs qemu-nbd in the face | 21:25 | |
| Keybuk | psusi: there is no runlevel 's' | 21:27 |
| Keybuk | it would cause some events to be emitted | 21:27 |
| Keybuk | but since System V doesn't define such a runlevel, nothing would be run | 21:27 |
| psusi | insofar as there are no jobs defined for it... but manually emitting runlevel s would get runlevel to be s, which would effectively be a zombie runlevel no? | 21:27 |
| Keybuk | you couldn't add an /etc/rcs.d and expect it to work, for example | 21:27 |
| psusi | right... zombie runlevel ;) | 21:27 |
| Keybuk | actually, that's not true, system v defines "s" to mean "I couldn't be bothered to hold down shift when I typed S" | 21:27 |
| Keybuk | well | 21:28 |
| Keybuk | you can do | 21:28 |
| Keybuk | initctl emit runlevel RUNLEVEL=allegro PREVLEVEL=$RUNLEVEL | 21:28 |
| Keybuk | you can do whatever you want ;) | 21:29 |
| Keybuk | but don't expect the system to play along | 21:29 |
| Keybuk | for a start, those things won't end up in utmp/wtmp | 21:29 |
| Keybuk | slangasek: bug #539402 | 21:29 |
| ubottu | Launchpad bug 539402 in udev "does not terminate at computer shutdown" [Undecided,New] https://launchpad.net/bugs/539402 | 21:29 |
| slangasek | Keybuk: neato | 21:31 |
| Keybuk | though that one is also somewhat odd | 21:31 |
| unggnu | hi all | 21:35 |
| unggnu | Is the boot splash for Lucid final or are there still changes planned? I mean it looks great but I think the animation looks too much like a progress bar which is misleading imho. | 21:37 |
| Keybuk | unggnu: I'm not aware of any changes planned | 21:40 |
| Keybuk | it happens that 5s is the average time it's actually visible anyway ;-) | 21:40 |
| Keybuk | so it's probably not an issue if it looks too much like a progress bar <g> | 21:40 |
| unggnu | Keybuk: it depends on the system :) | 21:40 |
| Keybuk | not really, splash shows after ureadahead, so even on HDD you're mostly just waiting for X to init | 21:41 |
| unggnu | Keybuk: It wouldn't matter if it wouldn't already look so professionel :) | 21:41 |
| Keybuk | if you feel your concerns are particularly strong - talk to the Design team | 21:41 |
| Keybuk | they would need to approve any changes | 21:41 |
| Keybuk | (filing a bug on plymouth is not a way of talking to them) | 21:41 |
| unggnu | I guess I am now on the artwork channel | 21:41 |
| Keybuk | sure | 21:41 |
| directhex | i think i'm finding why docky doesn't work... and AIR... it's not a pretty issue if it's what i think | 21:42 |
| unggnu | It seems that the start time is really fast through the "progress bar" and then suddenly it starts again. | 21:42 |
| unggnu | (the animation) | 21:42 |
| Keybuk | unggnu: huh, it if starts again, you have an old plymouth | 21:45 |
| Keybuk | the current theme draws orange dots from left to right | 21:45 |
| Keybuk | then replaces them with white dots from left to right | 21:45 |
| Keybuk | and then repeats | 21:45 |
| unggnu | Keybuk: this is what I meant with again :) | 21:45 |
| Keybuk | only older versions fill from left-to-right then go back to five white | 21:45 |
| unggnu | until the reds get replaced again you might think it is a progress bar | 21:45 |
| Keybuk | I iz not designer | 21:46 |
| Keybuk | when I last did a splash screen theme, it had a dancing monkey on it | 21:46 |
| Keybuk | you need to talk to them :p | 21:46 |
| unggnu | Keybuk: I am, but they are not there or not replying :D | 21:48 |
| Keybuk | that's because it's close to 10pm in the UK | 21:48 |
| directhex | what happened to the gnome-keyring socket? | 21:48 |
| Keybuk | they're probably at home with their husbands, wives and dogs | 21:48 |
| Keybuk | or down the pub | 21:48 |
| unggnu | or in some fancy art gallery ;) | 21:49 |
| directhex | there's no GNOME_KEYRING_SOCKET environment anymore, and no /tmp/keyring-foo32d987h273ry/socket file | 21:49 |
| directhex | seb128, ^ | 21:49 |
| seb128 | directhex, right | 21:50 |
| * sebner waves at directhex :) | 21:50 | |
| Keybuk | Where does the +-sign come from? | 21:50 |
| Keybuk | As far as I know, Ubuntu does not use ACL by default. | 21:50 |
| Keybuk | heh, ... you iz wrong! | 21:50 |
| seb128 | directhex, you are supposed to use libgnome-keyring not hack other software sockets | 21:50 |
| Keybuk | (/me catches up on ML for a few minutes) | 21:50 |
| directhex | seb128, and the seemingly empty dbus interface? | 21:51 |
| seb128 | directhex, the dbus interface is the next generation way | 21:52 |
| seb128 | until now it had libgnome-keyring only | 21:52 |
| seb128 | it's being turned in a freedesktop.org dbus interface for GNOME3 | 21:53 |
| seb128 | but that's work in progress started this cycle | 21:53 |
| seb128 | libgnome-keyring is still what is used by GNOME | 21:53 |
| seb128 | you can play with the dbus interface if you want though | 21:53 |
| directhex | there doesn't seem to be anything exported via the dbus interface, if dbus-explorer is to be believed | 21:53 |
| Keybuk | that just means the dbus server doesn't do introspection | 21:54 |
| Keybuk | it's kinda optional | 21:54 |
| Keybuk | you tend to add it the first time you have to debug your own d-bus interface, and wish you didn't have to keep writing client stuff and could just use d-feet :p | 21:55 |
| Keybuk | the trick is to avoid writing the client as long as possible | 21:55 |
| Keybuk | though then you end up with upstart 0.5 - where the server has a wonderfully rich d-bus interface, with full introspection | 21:55 |
| Keybuk | and initctl had never caught up - cause I could do all my testing with dbus-send and d-feet :p | 21:56 |
| directhex | hm. seems i have a rather short period of time to rewrite gnome-keyring-sharp from scratch then | 21:56 |
| kees | lool: okay, so booting my debootstrap'd image, I get as far as mountall: Could not connect to Plymouth | 21:57 |
| kees | Keybuk: if I'm starting a crazy arm image without an initrd, what do I have to do to trick mountall into starting plymouth on its own (instead of the initrd doing it)? | 21:59 |
| directhex | is it an upstream change or an ubuntu change to remove the socket? | 21:59 |
| Keybuk | kees: it doesn't | 22:00 |
| Keybuk | kees: upstart should start mountall and plymouth ? | 22:00 |
| kees | Keybuk: weird, I'm getting "mountall: Could not connect to Plymouth" | 22:00 |
| Keybuk | implies plymouth isn't running | 22:00 |
| kees | precisely. :) | 22:00 |
| Keybuk | you sure it's on that image? | 22:01 |
| seb128 | directhex, upstream, we don't have ubuntu changes to gnome-keyring | 22:01 |
| * kees checks | 22:01 | |
| directhex | it seems to break any keyring usage in mono apps. which means f-spot can no longer store passwords, presumably. it also kills other things like bbc iplayer (or any adobe air app, really) | 22:01 |
| seb128 | directhex, you can a /tmp/keyring-nnnnn/control | 22:02 |
| kees | Keybuk: neato, the debootstrap missed it. | 22:02 |
| seb128 | not sure what it's used for | 22:02 |
| kees | is it part of -minimal? | 22:02 |
| seb128 | directhex, but it might be useful for what you need | 22:02 |
| lool | kees: make sure you setup the network | 22:02 |
| kees | lool: yup | 22:02 |
| lool | kees: /etc/network/interfaces or network-manager | 22:02 |
| lool | kees: the plymouth thing is just a warning | 22:02 |
| kees | lool: yeah, I'm updating it via my schroot first, then will re-sync to the disk image. | 22:02 |
| directhex | seb128, control appears not to be the same thing | 22:03 |
| kees | lool: just a warning? it didn't do anything after that. :( | 22:03 |
| Keybuk | pitti: maybe check http://websvn.kde.org/trunk/KDE/kdebase/workspace/ for blame? | 22:03 |
| Keybuk | what file is the vt8 appearing in ? | 22:03 |
| RAOF | Keybuk: You wanted to know if the lbm_nouveau patches can be dropped? They can be. It'll make the upstream nouveau testing PPA slightly harder to keep current, as it'll need to pull in patched plymouth & such, but Lucid doesn't need any of those patches. | 22:03 |
| lool | kees: presumably it was waiting for some event to launch the ttys | 22:03 |
| Keybuk | RAOF: so we still intend to support lbm-nouveau for lucid onwards? | 22:03 |
| Keybuk | RAOF: what's in the "upstream nouveau testing PPA" ? | 22:04 |
| lool | kees: Usually for me it's the network | 22:04 |
| lool | kees: You can confirm things work by running /bin/sh | 22:04 |
| kees | lool: yeah, init=/bin/sh worked | 22:04 |
| lool | kees: You did the second stage part of your debootstrap already I guess | 22:04 |
| Keybuk | pitti: I can't find vt8 grepping through the source | 22:04 |
| lool | kees: You want your rootfs in /etc/fstab too | 22:04 |
| kees | lool: I did the debootstrap via mk-sbuild | 22:04 |
| Keybuk | pitti: ah, I can find vt%d | 22:04 |
| lool | kees: Or you want to pass rw on the kernel cmdline | 22:04 |
| kees | lool: oh, I bet I missed that. | 22:04 |
| lool | kees: I think I filed that one against mountall, not sure | 22:05 |
| lool | kees: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/527216 | 22:05 |
| ubottu | Ubuntu bug 527216 in mountall "Boot hangs waiting for local filesystems if / isn't in fstab and / is only mounted ro" [Medium,Triaged] | 22:05 |
| Keybuk | yeah we debugged that one | 22:06 |
| lool | kees: I personally like loop mounting my rootfs quite often; I use a wrapper to launch a shell in the mount and umount on exit | 22:06 |
| lool | kees: http://people.canonical.com/~lool/loop-mnt-do | 22:06 |
| Keybuk | is caused by mountinfo having /dev/root in it | 22:06 |
| lool | kees: (You might find this useful when changing the rootfs between boots) | 22:07 |
| RAOF | Keybuk: The upstream nouveau testing PPA contains packages for bleeding edge upstream; the DDX, libdrm, and nouveau's linux branch. | 22:07 |
| Keybuk | RAOF: -> kernel | 22:08 |
| directhex | found it. Stef Walter broke the socket on 2009-12-17 | 22:11 |
| kees | lool: yup, missing fstab entry was it. | 22:11 |
| lool | kees: Cool; so I guess you're working on the security features for ARM? | 22:11 |
| kees | lool: no, just making a list of what's missing. | 22:11 |
| lool | ok | 22:12 |
| pitti | Keybuk: yeah, I already grepped code for ->serverVT, but didn't complete that yet (didn't see something obvious after 3 minuts) | 22:13 |
| Keybuk | pitti: thinking about this now for a moment | 22:13 |
| Keybuk | pitti: where is kdm pulling that 8 from? have you found out? | 22:13 |
| Riddell | pitti: amd64 | 22:14 |
| pitti | Keybuk: I'll look in a bit | 22:14 |
| pitti | Riddell: if you are on amd64, I can toss you the binary | 22:14 |
| Keybuk | pitti: cause me thinking | 22:14 |
| pitti | Riddell: great architecture that | 22:14 |
| Keybuk | if kdm is guaranteed to always use 8, we don't need the patch "for the first server" | 22:14 |
| Keybuk | that's there not to use plymouth's vt, but to make sure we don't use 1-6 right | 22:15 |
| pitti | Keybuk: I'll check in a bit | 22:15 |
| Keybuk | so all we really want is if plymouth-is-running use the currently active vt, whatever that might be | 22:15 |
| pitti | Riddell: http://people.canonical.com/~pitti/tmp/kdm | 22:15 |
| pitti | Riddell: copy that to /usr/bin, and restart | 22:15 |
| pitti | Keybuk: ah, it seems to call get_active_vt() | 22:17 |
| pitti | Keybuk: VT_GETSTATE on /dev/tty0 | 22:17 |
| pitti | Keybuk: which is a bit weird, I called kdm from tty3 | 22:18 |
| Keybuk | pitti: active vt will be 7 though ... | 22:18 |
| pitti | Keybuk: ah, no, sorry; that was from the broken 104_kubuntu patch | 22:18 |
| pitti | that code path won't be active | 22:18 |
| pitti | nothing ever writes that stamp file | 22:19 |
| * pitti searches further | 22:19 | |
| slangasek | Keybuk: plymouth is stopped on starting kdm, so what would "if plymouth-is-running" check? | 22:19 |
| Keybuk | slangasek: huh? | 22:19 |
| Keybuk | ECONTEXT | 22:19 |
| slangasek | 15:15 < Keybuk> so all we really want is if plymouth-is-running use the currently active vt, whatever that might be | 22:19 |
| Keybuk | ah | 22:19 |
| Keybuk | right | 22:19 |
| Keybuk | sorry | 22:19 |
| Keybuk | if pitti is right, kdm is always pushing X to vt8 | 22:20 |
| Keybuk | it seems to be very insistent on always passing vtX | 22:20 |
| Riddell | pitti: seems to do the job | 22:20 |
| Keybuk | if that's true, kdm *is not* vulnerable to the getty-and-X-on-vt1 bug | 22:20 |
| Keybuk | because kdm likes vt8 | 22:20 |
| Keybuk | if we can prove it's not vulnerable, we don't need this patch | 22:20 |
| slangasek | so dropping the --retain-splash solves all the races/conflicts, and the remainder is just getting the X transition pretty? | 22:20 |
| Keybuk | yes | 22:21 |
| pitti | Keybuk: I looked through all instacnes of serverVT and reqSrvVT again, and I still don't find the code which sets those to 8 | 22:23 |
| * pitti searches harder | 22:23 | |
| Riddell | using pitti's KDM binary is much nicer than dropping --retain-splash, it doesn't drop me to a terminal for several seconds | 22:23 |
| Keybuk | Riddell: it will though | 22:24 |
| Keybuk | once we lose the --retain-splash | 22:24 |
| pitti | Riddell: can you check user switching, with a second X? that should land on vt8 then | 22:24 |
| pitti | I tested that here as well, but just to make sure | 22:24 |
| kees | lool: what do you use for qemu networking? i.e. how do you get your arm VM talking on the network? | 22:26 |
| pitti | Keybuk: ah, it's in allocateVT() in kdm/backend/dm.c | 22:26 |
| pitti | I don't see reqSrvVT being set anywhere, so it must be dynamic | 22:27 |
| Keybuk | it's from config | 22:27 |
| Riddell | pitti: user switching seems to work, I have one user on control-alt-F7 and one on control-alt-F9 | 22:31 |
| pitti | hm, and serverVTs starts with 7, so why doesn't it actually _pick_ 7 initially? | 22:31 |
| Keybuk | because it queries whether each one is allocated in turn | 22:31 |
| Keybuk | sees VT7 is in use | 22:31 |
| pitti | and vt7 is allocated? | 22:31 |
| Keybuk | so ++ | 22:31 |
| Keybuk | yes | 22:31 |
| Keybuk | plymouth had it | 22:31 |
| Riddell | F8 is blank with a cursor | 22:31 |
| pitti | ah, ok | 22:31 |
| Riddell | first user is on vt 8 second on vt 9 | 22:31 |
| Keybuk | plymouth didn't VT_DEALLOCATE | 22:32 |
| Keybuk | it left it for X to find | 22:32 |
| pitti | Keybuk: ok, so it seems that forcing it to vt7 is about as ugly/working as in gdm then | 22:32 |
| Keybuk | right | 22:32 |
| Keybuk | so this code is largely good | 22:32 |
| Keybuk | it's safe from death by getty after all | 22:32 |
| pitti | at least for beta-1 it's probably good enough | 22:32 |
| Keybuk | yup | 22:32 |
| pitti | I really hate those two patches, but *shrug* | 22:32 |
| Keybuk | for beta-2, we want to include plymouthness in there, and use the current vt whatever that is, whether allocated or not | 22:33 |
| pitti | working > beauty this close to release | 22:33 |
| Keybuk | but beta-1 no need to change kdm | 22:33 |
| pitti | oh? | 22:33 |
| Keybuk | well, kdm works right? | 22:33 |
| pitti | so we're going with the --retain-splash thing? | 22:33 |
| Keybuk | it will use the first free vt from 7 onwards | 22:33 |
| Keybuk | no, we're dropping --retain-splash | 22:33 |
| Keybuk | steve and I talked about that separately | 22:33 |
| pitti | ok, fine for me | 22:33 |
| Keybuk | it introduces too many issues | 22:33 |
| Keybuk | and a fix for the vt1 issue makes it harder to keep | 22:33 |
| Keybuk | (login: for people) | 22:34 |
| pitti | so you don't actually want me to upload that kdm patch then? | 22:34 |
| tkamppeter | mvo, pitti, did one of you have another look at the D-Bus problem. | 22:34 |
| pitti | tkamppeter: sorry, -EBUSY | 22:34 |
| Keybuk | pitti: nope, but thanks very much for doing the work to figure out how kdm gets its vt | 22:34 |
| Keybuk | that's useful knowledge! | 22:34 |
| pitti | Keybuk: at least we have a patch on the shelf now, should we still need it | 22:34 |
| pitti | brb, booting into an X session again | 22:35 |
| kees | lool: ah, got it, was missing dhclient. har har | 22:35 |
| pitti | Riddell, Keybuk: so the h4ck is on http://people.canonical.com/~pitti/tmp/kdm.firstserver-force-vt7.patch (that corresponds to http://people.canonical.com/~pitti/tmp/kdm) | 22:38 |
| pitti | I won't delete it just yet :) | 22:38 |
| pitti | Riddell, Keybuk: do you still need anything from me now for this issue? | 22:45 |
| Keybuk | pitti: nope, thanks! | 22:46 |
| pitti | Keybuk: thanks to you! | 22:46 |
| * pitti cd /bed | 22:46 | |
| Riddell | Keybuk: so resolution is to drop --retain-splash and that's us sorted for beta? | 22:46 |
| pitti | Riddell: current kdm won't at least run into the "start on vt1" problem, so it will look a bit ugly, but should work | 22:47 |
| Keybuk | Riddell: yes | 22:47 |
| Riddell | Keybuk: so you'll upload that tonight and have slangasek get us a new set of CDs to test tomorrow? | 22:48 |
| Keybuk | yes | 22:50 |
| Riddell | Keybuk: should I e-mail tseliot to tell him it's sorted for beta but the smooth transition patch is still needed if he is in a KDM patching mood? | 22:50 |
| Keybuk | Riddell: yup | 22:52 |
| Riddell | Keybuk: groovy, thanks for giving over your evening to this | 22:52 |
| Keybuk | that's quite ok, thanks for your help | 22:54 |
| Keybuk | good to get to the bottom of it | 22:54 |
| Guest36494 | kees, qemu-nbd definately had issues for me uin it from scripts, i had to call it twce to work | 23:47 |
| Guest36494 | s/uin/running/ | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!