| === asac_ is now known as asac | ||
| === Moot2 is now known as MootBot | ||
| === emgent_ is now known as emgent | ||
| kidfoo | foo has an Asus EeePC, can foo use ubuntu mobile on it ? | 08:50 |
|---|---|---|
| kidfoo | sorry | 08:51 |
| ogra | persia, i think i got the PATH issue | 12:22 |
| persia | lool: What was it? | 12:22 |
| ogra | its tricky to solve though | 12:23 |
| persia | ogra^^ | 12:23 |
| persia | (oops) | 12:23 |
| persia | What's the cause? | 12:23 |
| ogra | there is no session dbus running in your env | 12:23 |
| ogra | we need something like the script in this patch http://launchpadlibrarian.net/7170382/dbus_1.0.2-1ubuntu34.patch | 12:23 |
| ogra | ++# GNOME gets it right: the session bus has to be started by the session | 12:23 |
| ogra | ++# manager. Otherwise programs started by dbus do not get environment variables | 12:23 |
| persia | Erm. That's kinda tricky. | 12:24 |
| lool | ogra: dbus-launch should be included by Xsession.d again | 12:24 |
| ogra | i need to verify that first though, but i noticed you have no DBUS_SESSION_BUS_ADDRESS at all | 12:24 |
| ogra | lool, right, but that needs some wrapping, remember se use ck-launch-session | 12:25 |
| lool | ogra: It's egg and chicken unfortunately | 12:25 |
| ogra | yeah | 12:25 |
| lool | ogra: ck-launch-session probably needs session bus as well | 12:25 |
| ogra | yeah, dbus-launch should execute it | 12:26 |
| lool | The underlying root cause is programs relying on env vars which are not guaranteed to be present | 12:26 |
| lool | Instead, they should use some API e.g. dbus to retrieve the info they want | 12:26 |
| lool | What GNOME does for e.g. keyring is that the keyring env vars are seeded into gnome-session via the g-k API | 12:26 |
| persia | Yes, but that's hard! :) | 12:26 |
| ogra | well, many of them do, thats why installing ntp fails | 12:26 |
| lool | That's awful IMO, but it's needed if you want compatibility with programs which want keyring env vars or e.g. SSH_AGENT | 12:27 |
| ogra | the installer seems to rely on getting PATH from dbus | 12:27 |
| lool | What is the failing use case again? | 12:27 |
| ogra | ntp | 12:27 |
| lool | You install ntp, that calls synaptic? | 12:27 |
| lool | Which programs needs which env var? | 12:27 |
| ogra | set time-admin to automatic and it cant frind the deb installer | 12:28 |
| lool | We could make sure it's started as part of the STARTUP | 12:28 |
| ogra | not sure, is it synaptic ? | 12:28 |
| persia | lool: Start time-admin. Authenticate. Try to switch to NTP. NTP isn't there, so it wants to install. gst-package can't find synaptic because polkit-grant-helper doesn't reset the path. | 12:28 |
| lool | Who triggers the installatoin? | 12:28 |
| ogra | yes, STARTUP would be the quick hack | 12:28 |
| persia | time-admin calls gst-package for the installation. | 12:28 |
| eichi | hello | 12:29 |
| lool | Is time-admin running as root? | 12:29 |
| persia | No, time-admin can't run as root. | 12:29 |
| persia | time-admin gets root powers through policykit | 12:29 |
| eichi | when the n800 will be supportet by u-mobile? | 12:29 |
| ogra | lool, the prob with STARTUP will be that we dont have a system bus yet | 12:29 |
| lool | so time-admin talks to PK, does time-admin see the dbus session bus? | 12:29 |
| ogra | the upstart script executes everything before rc2.d has run | 12:30 |
| lool | ogra: Uh *system*? | 12:30 |
| persia | eichi: There are two issues. One is that some of the HW is ill understood. No idea for that. The other is that it is ARM architecture. This has been discussed, but no timeline established. | 12:30 |
| lool | I thought that was long solved | 12:30 |
| ogra | lool, the session bus needs to connect to it | 12:30 |
| eichi | okay, thanks | 12:30 |
| lool | ogra: So at some point, Tollef added a delay to ensure startx is only called when sys bus is ready IIRC | 12:30 |
| ogra | not sure what exactly happens if there is no systembus it can use | 12:31 |
| persia | lool: It's not solved. We'd have to change /etc/event.d/session to start on started rc2 to make sure the system dbus was there. | 12:31 |
| persia | lool: The delay is gone. | 12:31 |
| lool | Okayyy | 12:31 |
| ogra | that will massively cost bootime | 12:31 |
| lool | So we need a dependency, shuffling init scripts around, or a delay again | 12:31 |
| ogra | :( | 12:31 |
| persia | It used to be that ume-config-common started from rc2.d, and that worked, because it has a high value. | 12:31 |
| persia | Now, we use /etc/event.d/session, and we don't wait for rc2 to complete. | 12:31 |
| ogra | idealy we'd run dbus from upstart | 12:32 |
| ogra | i wonder if scott added the code to intrepid already so we could steal from there | 12:32 |
| lool | ume-config-$platform ships this file | 12:32 |
| persia | ogra: There's a bunch else we'd want to move to upstart if we're going to rely on upstart events. I'd be a lot more comfortable with start on started rc2 for now. | 12:32 |
| lool | How does one express a dependency in upstart? | 12:33 |
| ogra | persia, any measures how much that time eats ? | 12:33 |
| lool | Upstart 0.5: Relationships uhoh | 12:33 |
| persia | lool: You depend on an event. "start on started rc2" expresses that the event should be processed once the "rc2" event has started completely. | 12:34 |
| persia | ogra: I haven't run bootchart on it, but I'd say 15 seconds or so. | 12:34 |
| ogra | it seems a) that scott is actively working on upstart dbis integration but far from being done and b) that the old Xsession script is still in the dbus source | 12:34 |
| ogra | phew | 12:34 |
| ogra | 15secs | 12:34 |
| lool | persia: I have start on runlevel 2 | 12:35 |
| persia | lool: Some relationships work in upstart 0.3.9 | 12:35 |
| ogra | lool, right you need "start on started" | 12:35 |
| persia | lool: Right. So, upstart is the system init daemon: there is no "runlevel 2". | 12:35 |
| ogra | that will delay it | 12:35 |
| lool | We could have start on started dbus | 12:35 |
| ogra | then upstart would need to handle dbus first | 12:36 |
| persia | We pretend there is a runlevel 2 by having an rc2 event that maps to sysV style runlevel 2, called "rc2". | 12:36 |
| persia | We can choose to either start on the trigger that starts this event, or start when this event is completed. I favour the latter, but it costs us time. | 12:36 |
| persia | For comparison, my Zaurus takes about 5 minutes to boot, but I almost never actually shut down. | 12:37 |
| lool | If session dbus needs system dbus, then I think starting after system dbus is not later than the earliest we can start | 12:38 |
| persia | lool: Right, but we can't determine when that happens with that level of granularity with the current model. | 12:38 |
| ogra | other way round :) | 12:38 |
| ogra | err | 12:38 |
| ogra | sorry | 12:38 |
| ogra | misread | 12:38 |
| persia | We can either migrate /etc/event.d/session back into /etc/rc2.d/ or we can start on started rc2 | 12:38 |
| ogra | and we need the Xsession script back | 12:39 |
| persia | If we migrate it back in, we're depending on the other calls in rc2.d to get the timing right. If we use upstart, we wait for all the calls in rc2. | 12:39 |
| lool | persia: So you're saying we can't say "started dbus" with upstart 0.3? | 12:39 |
| persia | lool: We could say it, except that there's no dbus event defined by default, so it would never start. | 12:40 |
| ogra | i dont think upstart knows about dbus without handlig it itself | 12:40 |
| lool | Oh ok; I thought it had emulation | 12:40 |
| ogra | thats the work scott is just doing in intrepid | 12:40 |
| persia | We'd have to migrate dbus to upstart. As I understand it, not enough of the precursors are done for this to be the case even in intrepid. | 12:40 |
| lool | ogra: right, that's what I was fearing initially | 12:40 |
| lool | ogra: Well we could invoke-rc.d dbus start before startx | 12:40 |
| ogra | yeah | 12:40 |
| lool | -ogra | 12:40 |
| persia | The emulation is one-way. upstart emulates sysV init, but our sysV init scripts aren't emulating upstart | 12:40 |
| ogra | thats what i thought as well this moment :) | 12:41 |
| persia | Why do we want to invoke-rc.d dbus in /etc/event.d/session? | 12:41 |
| ogra | no | 12:41 |
| ogra | in the ume-config-common script | 12:41 |
| persia | Won't that cause resource contention with the /etc/rc.2/S??dbus ? | 12:42 |
| persia | ogra: Right. Same result though. | 12:42 |
| lool | It looks like it would be a bit racy, but would probably work | 12:42 |
| ogra | right, we need to mv it from S to K | 12:42 |
| * persia advocates start on started rc2 more forcefully | 12:42 | |
| ogra | 15 secs ? | 12:42 |
| lool | persia: If there's enough delay, it would simply notice that it's already started | 12:42 |
| persia | Sure. How often do these things get shut down anyway? | 12:43 |
| persia | We don't provide any interface to shut down: it has to be done manually from the command line. | 12:43 |
| lool | I'm not at shutdown yet | 12:43 |
| persia | OK, boot time only matters if one shuts down, otherwise it's a one-time event. | 12:44 |
| lool | But we're going to be benched on boot time, not on shutdown time | 12:44 |
| lool | And the measure is "UI fully functional" | 12:44 |
| persia | Paying 15 seconds for a one-time event to do it in a way that is correct, and allows us to just s/rc2/dbus/ to keep it correct for hardy isn't so bad. | 12:45 |
| persia | lool: My argument is that boot time is meaningless. Users will only boot when they get the device, when we give them a new kernel, when they upgrade to a new release, or when they install a new battery. Everything else is hibernate. | 12:45 |
| ogra | argh, meh | 12:49 |
| ogra | we cant do it from ume-gui-start | 12:49 |
| ogra | that would be executed by dbus-launch from the Xsession script | 12:49 |
| persia | No, it has to be from the init daemon. | 12:49 |
| ogra | i dont think dbuslaunch can run the system bus | 12:49 |
| ogra | right | 12:50 |
| lool | What were the arguments against the invoke-rc.d dbus start in the event session start script? | 12:50 |
| ogra | i dont think upstart can interpret that | 12:51 |
| persia | Race condition with /etc/rc2.d/S??dbus | 12:51 |
| persia | ogra: in the event script, not as an upstart directive. | 12:51 |
| ogra | well, thats eaily solved by mv /etc/rc2.d/S??dbus /etc/rc2.d/K??dbus | 12:51 |
| lool | Or by adding a lock file | 12:51 |
| lool | Anyway, I'm fine to move this to "rc2" started if it doesn't degrade boot time | 12:52 |
| lool | We're at 32 seconds ATM, quite close to the limit | 12:53 |
| ogra | another option would be to move half the world to rcS.d | 12:53 |
| persia | ogra: That's a really ugly hack though | 12:54 |
| lool | Or move dbus to upstart :) | 12:54 |
| ogra | lool, which isnt ready yet :) | 12:54 |
| persia | Doesn't dbus have dependencies that need to also move to upstart? That's a lot of work for a short timeframe. | 12:54 |
| persia | Definitely an intrepid target | 12:54 |
| lool | We could also busywait in the session event start script until runlevel is high enough | 12:54 |
| ogra | ask Keybuk, i may be wrong, but the changelogs in intrepid look like he's in the middle of it | 12:54 |
| ogra | but not done ... | 12:55 |
| * persia wants lool's hardware. Boot time is 1min by default with the SR8 | 12:55 | |
| * ogra wants HW at all :P | 12:57 | |
| ogra | but i'll get my atom cmpc next week ... | 12:57 |
| lool | persia: You don't really want a menlow/crownbeach | 12:58 |
| persia | lool: Right, I just want the chipsets, but in a sexy form-factor :) One more week, if I can get in line early enough. | 12:58 |
| persia | Right. It's impossible to install bootchart. Time for a new image... | 13:03 |
| ogra | hmm | 13:06 |
| lool | persia: if you have the occasion, test an USB install image created with a recent MIC | 13:08 |
| lool | I'd like to confirm /boot is properly mounted and usable | 13:08 |
| ogra | just adding the Xsession script seems to suffice | 13:08 |
| persia | ogra: I just tested with start on started rc2 anyway, rather than building new images, and policykit still doesn't change the path. | 13:08 |
| lool | persia: Also, that's probably what blocks you from installing bootchart I'd guess | 13:08 |
| ogra | i got a session bus variable now | 13:08 |
| persia | It's not just about dbus not being available. I think we need to also start a session dbus somewhere. | 13:08 |
| lool | persia: dbus-launch should be appended in Xsession.d; it might not be if Ubuntu drops that | 13:09 |
| lool | Also, dbus session busses are autospawned | 13:09 |
| persia | lool: The issue with installing bootchart is that initrd.img isn't in /boot, but in / | 13:10 |
| ogra | i just copied the Xsession script from the dbus source to 75dbus_dbus-launch | 13:10 |
| persia | lool: What autospawns it? | 13:10 |
| ogra | seems to be enough to get a proper session bus | 13:10 |
| ogra | persia, the upstart script if it is in Xsession.d | 13:10 |
| persia | ogra: Then the lack of a session bus, while possibly an issue, isn't the reason policykit doesn't work. | 13:10 |
| ogra | upstart respawns startx | 13:10 |
| ogra | startx executed Xsession.d every time | 13:11 |
| ogra | persia, yes, i just noticed, the PATH is still wrong :/ | 13:11 |
| persia | 90-console-kit? | 13:11 |
| ogra | as i said in the beginning i didnt verify yet | 13:11 |
| persia | heh :) | 13:11 |
| ogra | so my next hunt goes one level deeper .... | 13:12 |
| ogra | lets look what pam and su do | 13:12 |
| ogra | especially pam_env.so | 13:12 |
| ogra | if nothing helps we can just source /etc/environment at the top of the ume gui script but thats extremely ugly and does hide the actual cause | 13:13 |
| persia | ogra: Let's reserve that as a hammer if other things don't work. | 13:13 |
| ogra | yeah, its ok as emergency fallback | 13:14 |
| ogra | and works fine, just tested that | 13:14 |
| ogra | the pam setup looks identical to my laptop ... | 13:14 |
| ogra | :( | 13:15 |
| persia | I suspect it's something gdm-ish, but investigation of gdm didn't get me anywhere. | 13:15 |
| ogra | it should be set by su | 13:16 |
| ogra | or rather by pam if su is executed | 13:16 |
| persia | Except we're not using su, so it should be set by one of the polkit-grant helpers | 13:16 |
| ogra | sure we use su | 13:16 |
| persia | (which annoyingly hardcode it, rather than using ENV_SUPATH like they ought) | 13:16 |
| ogra | in the event.d/session script | 13:17 |
| ogra | exec su -l ume -c "/usr/bin/startx -- -dpi 96 -br" | 13:17 |
| ogra | thats what mine has | 13:17 |
| persia | ogra: Right, but we su to a uid != 0, so pam gives us ENV_PATH rather than ENV_SUPATH | 13:17 |
| ogra | and /etc/pam.d/su has "session required pam_env.so readenv=1" | 13:18 |
| ogra | which tells pam_env to read the default file ... which is /etc/environment | 13:18 |
| ogra | afterwards it does "session required pam_env.so readenv=1 envfile=/etc/default/locale" | 13:18 |
| ogra | which works properly here in my german setup | 13:19 |
| persia | Hrm. That ought work :/ | 13:19 |
| ogra | hmm, no, wait | 13:19 |
| ogra | /etc/default/locale is used in several initscripts as well | 13:20 |
| * ogra inspects | 13:20 | |
| persia | /etc/default/locale ought be used all over the place. | 13:20 |
| ogra | AHA !!! | 13:21 |
| ogra | gdm sources /etc/environment in its initscrip2 | 13:21 |
| ogra | *script | 13:21 |
| persia | Oho! In that case hacking it into /etc/event.d/session isn't such a big club after all... | 13:22 |
| * persia tests | 13:22 | |
| ogra | yeah | 13:22 |
| ogra | well, put it in the ume script | 13:22 |
| ogra | i just did that before, works perfect | 13:22 |
| persia | You mean /etc/X11/Xsession.d/25-ubuntu-config-common_startup? | 13:23 |
| persia | Or ume-gui-start? | 13:23 |
| ogra | ume-gui-start | 13:23 |
| ogra | right at the top | 13:23 |
| ogra | hmm, k, next prob, after instlling ntp time-admin switches back to manual in the gui | 13:24 |
| persia | Right. Testing again, and will commit. | 13:24 |
| ogra | bah, it doesnt set a default server either | 13:25 |
| persia | default server? | 13:25 |
| ogra | on next start time-admin *has* auto selected but has no default server | 13:25 |
| ogra | well, ntp needs to pull from anywhere | 13:25 |
| persia | Right. That's a long outstanding bug in g-s-t | 13:25 |
| ogra | well, i'D blame ntp rather | 13:26 |
| persia | No, it's g-s-t. | 13:26 |
| ogra | sudo ntpdate doesnt work either | 13:26 |
| ogra | it should use a default | 13:26 |
| persia | NTP has servers by default, unless you run time-admin, and don't set servers. time-admin clears the server list. | 13:26 |
| ogra | then the time-admin case ismoot | 13:27 |
| ogra | gah | 13:27 |
| ogra | evil | 13:27 |
| ogra | we also really should set polkit to accept time-admin chages by default without authentication | 13:28 |
| ogra | seems silly that you have to give your pw every time | 13:28 |
| persia | Makes the standard MIC password handy. | 13:28 |
| ogra | (especially if you have to type on the onscreen kbd) | 13:28 |
| ogra | well, polkit has a setting to just allow it per app | 13:29 |
| persia | Bah. I can't find the time-admin/ntp bug right now. I was looking at it a couple days ago. | 13:29 |
| ogra | its not that we have massively many users on such systems :) | 13:29 |
| persia | No, but the use case is such that it's easy for someone else to hold it for a few minutes. | 13:30 |
| persia | I regularly pass my Zaurus to someone to show them something, or let them type something. | 13:30 |
| ogra | and ? | 13:30 |
| ogra | he can set your time | 13:30 |
| persia | Might be different if everyone had one, but... | 13:30 |
| persia | Ah, yes. Per-app. | 13:30 |
| ogra | right | 13:30 |
| ogra | and synaptic will still ask | 13:30 |
| persia | (and on the Zaurus, it never asks for those things, just runs them as root if required, anyway) | 13:30 |
| ogra | its just that you dont have to be asked every time if you want to adjust to a new TZ or so | 13:31 |
| persia | synaptic doesn't ask. gst-package asks. | 13:31 |
| ogra | g-s-t is a pile of crap anyway, i know seb makes some attempt to get rid of them in intrepid | 13:31 |
| ogra | (adding a default group to users-admin to be shown in the gui makes your eyes bleed ... its really evil, hardcoding all options teh user sees there) | 13:32 |
| persia | ogra: gst-package caches the password. You have to enter it every time to set the time, but only once in a while to install/update/change packages. | 13:39 |
| persia | Maybe this isn't the ideal model? | 13:39 |
| ogra | thats polkit | 13:40 |
| ogra | gksu is what caches it, polkit doesnt deliberately | 13:40 |
| ogra | or rather sudo caches it, gksu just inherits | 13:41 |
| persia | Ah, so gst-package is calling gksu, which does the caching. | 13:41 |
| persia | Right. That makes sense. | 13:41 |
| persia | Still non-ideal, but... | 13:41 |
| ogra | polkit is crap isf you ask me | 13:41 |
| ogra | but i'm not upstream | 13:42 |
| persia | Why do we use *kit again? | 13:42 |
| ogra | and they decided to go with it | 13:42 |
| ogra | the apps start to require it | 13:42 |
| persia | I'm really not sure GNOME is very UNIXy, but that's a different issue. | 13:42 |
| ogra | more and more upstream gnome apps switch to that model | 13:42 |
| persia | Anyway, E isn't much these days, so... | 13:42 |
| ogra | yeah | 13:42 |
| ogra | its surely still not properly multiuser | 13:42 |
| persia | Not multiuser. | 13:43 |
| ogra | you would runs away screaming if you would see all the hacks we did for early ltsp5 implementations to even make i work :) | 13:43 |
| ogra | its gotten better over time | 13:43 |
| ogra | but is still not there | 13:43 |
| persia | Each app has lots of features, instead of there being lots of features that can be exposed in apps (this is slowly improving, but in an odd way) | 13:43 |
| ogra | yeah | 13:44 |
| persia | I did look at early ltsp stuff. I haven't looked at it since, perhaps because of that :) | 13:44 |
| ogra | ltsp5 != ltsp :) | 13:44 |
| persia | There are lots of different communication buses, rather than following the "everything is a file" rule. | 13:44 |
| persia | Anyway, enough GNOME bashing: I've been a GNOME user for years, and I'll likely stay that way for a while more... | 13:45 |
| ogra | well, i for one would be happy if it could work on a per session base and if every app had a proper distinction between front and backend | 13:45 |
| persia | ogra: Where's your initrd.img? | 13:45 |
| ogra | ? | 13:45 |
| ogra | which one now ? | 13:45 |
| persia | In your ume install? | 13:45 |
| persia | Mine is in /, which means NTP can't install. I wonder if I'm special. | 13:46 |
| ogra | in /boot | 13:46 |
| ogra | the one in /should only be a link | 13:46 |
| ogra | update-initramfs expects it in boot | 13:46 |
| ogra | and i guess u-a is run from ntp postinst | 13:47 |
| persia | Yeah. I'll check a different image: this one mignt not be right. | 13:47 |
| ogra | err | 13:47 |
| ogra | u-i | 13:47 |
| ogra | :) | 13:47 |
| persia | Yep :) | 13:47 |
| ogra | ah, wonderful, alarmclock has a quit button now | 13:54 |
| ogra | but lost the settings entry so i cant switch back to analog :/ | 13:54 |
| ogra | hmm, and the notification window doesnt go away | 13:55 |
| ogra | just sits in the middle | 13:55 |
| persia | Yeah, well. The notification goes away if you start the app. | 13:57 |
| persia | s/app/settings window/ | 13:57 |
| ogra | well, there is no settings wi anymore | 14:00 |
| ogra | it only goes away if i start aother app | 14:00 |
| ogra | *another | 14:00 |
| ogra-ume | the same happens if i start pidgin while already having it open | 14:01 |
| ogra-ume | i guess sapwood doesnt get the right info here | 14:02 |
| ogra-ume | where the heck is that thing documented ... hrm | 14:04 |
| ogra-ume | hmm, no .. | 14:05 |
| ogra-ume | i thought sapwood was responsible for apps to only be launched once | 14:06 |
| ogra | geez | 14:09 |
| ogra | closing pidgin crashed my desktop | 14:09 |
| persia | How? | 14:09 |
| ogra | gah, its reproducable | 14:10 |
| ogra | only happens if i'm looged in to any IRC channel though, not if you just open/close the app | 14:10 |
| persia | Can you get a backtrace? | 14:12 |
| ogra | strace first ... http://people.ubuntu.com/~ogra/pidgin.log | 14:17 |
| ogra | write(2, "pidgin: Fatal IO error 104 (Conn"..., 72) = -1 EIO (Input/output error) looks suspicious | 14:17 |
| persia | That doesn't look so bad for closing an app. There's an error, but it's relatively minor, as the app is shutting down anyway. | 14:18 |
| ogra | eek | 14:19 |
| ogra | there is no bonobo server running at all ? | 14:19 |
| ogra | that wont work | 14:19 |
| persia | It's a low-resource machine. See my previous comments about GNOME :) | 14:20 |
| ogra | yeah, but pidgin uses boobo for internal communication iirc | 14:20 |
| persia | Right. That might explain the previous existence of moblin chat. | 14:21 |
| persia | On the other hand, I suspect a backtrace will show you that the Hildon libraries aren't very robust. | 14:21 |
| ogra | hmm, even with bonobo in place it crashes | 14:22 |
| persia | The whole desktop, or just pidgin | 14:22 |
| persia | ? | 14:22 |
| ogra | the whole desktop | 14:24 |
| ogra | X restarts | 14:24 |
| persia | Right. Blame the hildon libraries. They ought trap the segfault, and not die. | 14:24 |
| ogra | but we shouldnt have a segfault first place | 14:25 |
| persia | The issue is that when hildon-desktop crashes, it takes down X, because of startx and the session scripts. | 14:25 |
| ogra | i surely dont get one with pidgin in a normal desktop | 14:25 |
| persia | No, but lots of apps segfault. Dropping back to the regular desktop is the least painful way to handle it. A segfault oughtn't kill X. | 14:26 |
| ogra | no, works just fine on my laptop | 14:26 |
| ogra | bonobo is installed but not runing | 14:27 |
| ogra | (in ume) | 14:28 |
| ogra | hmm, getting a backtrace is pretty hard without being able to get pidgin-dbg | 15:03 |
| ogra | (it uninstalls half the desktop) | 15:03 |
| ogra | and indeed it tears down gdb with it if i start it from xterm | 15:03 |
| ogra | intrestingly it doesnt respawn with gdb running | 15:04 |
| ogra | uuuh, i'm blind | 15:12 |
| ogra | /usr/share/autostart/xhost.desktop ?? | 15:12 |
| ogra | hmm. seems thats needed but appaears quite odd not to properly use xauth for that | 15:15 |
| lool | So hmm | 15:16 |
| lool | I have a small issue | 15:16 |
| lool | ogra: Can I discuss keyring stuff with you? | 15:16 |
| ogra | sure, if i can help | 15:18 |
| lool | Basically, ubuntu-keyring ships a keyring file at a special place and then calls apt-key update in postinst | 15:18 |
| lool | apt-key only checks this special place | 15:18 |
| lool | I am creating a keyring for UME | 15:18 |
| lool | The package is named differently and names the keyring differently | 15:19 |
| lool | But the keyring file isn't picked up | 15:19 |
| lool | Option 1), apt-key add the new keyring manually | 15:19 |
| lool | opens: do we want to apt-key remove <key id> on removal? not sure | 15:19 |
| lool | It's also weird because you don't get a real "main archive keyring" | 15:20 |
| lool | option 2), use the same package name and the same file name, call apt-key update | 15:20 |
| ogra | just call apt-key add in the postinst ? | 15:20 |
| lool | cons: prevents installing the main keyring, generally mixes package names for the different things | 15:20 |
| lool | pluses: works fast and easily | 15:20 |
| lool | ogra: So option 1? | 15:20 |
| lool | That's also my preferred for now | 15:21 |
| lool | But I wonder whether that's sensible | 15:21 |
| ogra | yeah, thats what i'd go with | 15:21 |
| lool | I also tried looking into other options, such as adding the keyring to the list of places apt looks at, but I couldn't find any config item for it | 15:21 |
| ogra | well, i'D do it for now and ask mvo then, nobody knows more about apt and keys i guess | 15:22 |
| lool | Ok, that was my plan, will have to wait until monday then | 15:23 |
| ogra | but the apt-key add method seems cean if we cant get it into the main keyring | 15:24 |
| lool | ogra: Also, do you have any idea why I'd get W: Failed to fetch http://archive.mobile.ubuntu.com/dists/um-ppa-hardy/Release Unable to find expected entry main/binary-lpia/Packages in Meta-index file (malformed Release file?) | 15:25 |
| lool | Hmm perhaps it strictly needs Packages | 15:26 |
| lool | Oh, I copied the list of files from the ppa example, but there's no Package there | 15:26 |
| lool | ogra: nm, fixed | 15:27 |
| lool | Cool, everything works | 15:27 |
| lool | Now copying packages | 15:27 |
| ogra | the keynames are hardcode in the /usr/bin/apt-key script btw | 15:29 |
| * ogra beats pidgin over the head | 15:30 | |
| lool | ogra: Yeah, hardcoding is *baaad* | 15:30 |
| ogra | well, in case of gpg i can understad that :) | 15:31 |
| ogra | what i dont understand is why pidgin crashes my ume desktop :/ | 15:31 |
| ogra | i guess i need to build a dbg packae myself, sigh | 15:31 |
| lool | ogra: apport should work BTW | 15:31 |
| ogra | oh, right | 15:32 |
| lool | ogra: I see a pidgin-dbg | 15:32 |
| ogra | yes, with wrong deps | 15:32 |
| lool | Now I only need to find the latest version of the report script | 15:32 |
| ogra | i would need a pidgin-maemo-dbg i guess | 15:33 |
| ogra | hmm, apport doesnt start | 15:41 |
| ogra | hmm, cant work, the kernel doesnt know about crashdump-size it seems | 15:43 |
| * ogra goes to do some lawn mowing ... to probably have an idea | 15:51 | |
| lool | ogra: /etc/init.d/apport start should DTRT | 16:02 |
| lool | unless our kernel dropped this support | 16:02 |
| ogra | looks like it did | 16:22 |
| ogra | no crash reports in /var/crash | 16:22 |
| lool | ogra: Try with -18 | 16:24 |
| lool | ogra: The only one which doesn't have this support can only be -17 from the ppa | 16:24 |
| lool | -19 might miss it as well though | 16:24 |
| lool | Ok, so I think I finished the archive | 16:24 |
| lool | Wow MIC still defaults to ... gutsy | 17:52 |
| emgent | heya | 21:24 |
| === matt_c_ is now known as matt_c | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!