[00:19] pitti, bug 512048 -> fixed in debian, thank you! [00:19] Launchpad bug 512048 in simple-scan "avoid excessive dependencies" [Low,Triaged] https://launchpad.net/bugs/512048 [01:54] how to find a maintainer of a specific driver? [01:55] owen1: which touchpad driver? also, X Window System driver or kernel driver? [01:55] driver for touchpad. it's elantech. [01:55] crimsun: dell inpiron 11z and dell mini 10 both comes with this touchpad. [01:56] crimsun: and i can't configure it at all. i am about to give up and return my laptop to dell. [01:56] crimsun: http://ubuntuforums.org/showthread.php?t=1347942&page=2 [01:57] xserver-xorg-input-synaptics and linux certainly are new enough [01:57] do you have a pointer to a specific bug report on Launchpad? [01:58] crimsun: no. i did'n know it's a bug. [01:59] crimsun: i'll go there and look for bug reports. maybe someone mentioned it. [01:59] crimsun: can u take a look at this link- http://arjan.opmeer.net/elantech/ [01:59] is it helpul in any way? [02:00] I already looked, which is why I mentioned the above source packages. [02:04] crimsun: i am sorry but i am a bit confused. did u find a bug report about the issue? [02:04] crimsun: if not, i'll be happy to add a bug. [02:05] owen1: I did not look; I'm busy ATM. [03:05] crimsun: np. i'll go to launchpad [04:25] here is a similar bug - https://bugs.launchpad.net/ubuntu/+source/gsynaptics/+bug/132627 [04:25] Ubuntu bug 132627 in gsynaptics "GSynaptics couldn't initialize." [Undecided,Fix released] [04:26] how was it fixed? [04:27] the original bug is for 7.04 and i have 9.10. [04:27] i think it's related to elantech touchpads. [04:28] they are not recognized for some laptops (inspiron 11z and mini 10) [04:30] can anyone help me with submitting bug to launchpad? [04:30] i am not sure if i should create new bug [04:32] owen1: If it's not the same hardware, you'll want a new bug. [04:33] You might try running `ubuntu-bug xserver-xorg-input-synaptics` [04:34] Most bug discussion happens in #ubuntu-bugs, but that's more about bug triage than about actually solving them. [04:34] pitti: say, can we just disable palimpsest? it seems to be warning way too much (bug 438136) [04:34] You might also find useful support in #ubuntu [04:34] Launchpad bug 438136 in libatasmart "palimpsest bad sectors false positive" [Unknown,Confirmed] https://launchpad.net/bugs/438136 [04:34] i'd kind of like to SRU it off too [04:35] kees: I was going through FTBFS this weekend, and got stuck with libpam-alreadyloggedin : it appears to get confused by some of the stack-smashing-protection, but only for i386 and powerpc. Am I on the right track, or confused by some byproduct? [04:36] persia: hrm, confused how? [04:36] * kees reads the buildlog... [04:36] https://launchpad.net/ubuntu/+source/libpam-alreadyloggedin/0.3-1/+build/1428110/+files/buildlog_ubuntu-lucid-i386.libpam-alreadyloggedin_0.3-1_FAILEDTOBUILD.txt.gz [04:37] I had similar sorts of issues for libpam-slurm, and ended up fixing those by adding lots more -nostdlib calls to the Makefile, but that felt like a big hammer. [04:37] yeah, -nostdlib is the right fix, but it's weird that amd64 didn't blow up in the same way [04:38] err .. -lc [04:38] That was why I asked. I had thought SSP would be on amd64, but nothing seems to fail there. [04:38] that would imply libc ?? [04:40] persia: OH! [04:40] ld instead of gcc [04:40] wrong: ld -lpam --shared -lc pam_alreadyloggedin.o -o pam_alreadyloggedin.so [04:40] right: gcc -lpam --shared -lc pam_alreadyloggedin.o -o pam_alreadyloggedin.so [04:41] OK. Would you be up for explaining why? [04:41] Also, if you had any ideas why it worked on amd64, I'd be interested. [04:44] any build admins able to bump a package up the queue [04:44] I need Lernid to be built in my PPA ready for developer week starting [04:50] persia: because the compiler has the logic for knowing how to call the linker correctly. i think -shared turns off somethig there [04:51] not sure why it worked on amd64, maybe the linker handles things differently there [04:51] OK. Thanks for the hint. I'll go look at --shared in hopes of understanding at least a little bit before uploading :) [04:51] i think this is a flaw in my modifications of the spec files, ld must be missing something. [04:53] You might also want to look at libpam-slurm if you're looking at stuff, as it shows the same broken on i386/works on amd64 behaviour if you remove my latest patch. [04:53] And it uses gcc for all the calls when doing so. [05:05] kees: dude, I am scared now...I live in a gated community, and the closest streetview is over 2 miles away...the community voted to not allow google in our subdivision, yet the mac address at my house is dead on, and the mac address here at my girlfriends is dead on...this is way to freaky [05:06] * persia pipes whois output to the OMCD [05:09] yeah, that definitely belongs on charles darwin, now that I figured it out after the fact [05:10] Not really. It's probably your ISP providing data. [05:10] Get a more private ISP, or set up fancy tunnels. [05:10] att uverse at both locations [05:10] Right. Tunnel it is then. [05:11] Get a vhost somewhere and set up a VPN. [05:11] my cell phone on the other hand, isn't even close [05:12] that's probably the location of your carrier's internet gateway [05:13] if that were the case, then the gateway is in both my house and my girlfriends house :) [05:13] it seems that att, like persia said, is giving out way to much info [05:14] Well, depends on the user. Some users prefer convenience to privacy. [05:14] any build admins around? [05:16] jono: To retry, or bump the score? [05:19] nixternal: I was driving to pick up one of my kids from a friends house last night and using the Google navigation feature on my 'droid. When I got to the destination it popped up a picture of the house so I could know which one it was. It was totally cool. [05:19] StevenK, it is down to build in two days [05:19] and I really need a Lernid and Karmic build ready for Ubuntu Developer Week which starts on Monday [05:19] this is really weird, persia even if I do use a tunnel, it knows where that MAC address is located [05:20] can you help bump it up, StevenK? [05:20] nixternal: Then you don't have enough hardware between your device and your tunnel. [05:20] * persia takes this somewhere slightly less off-topic [05:21] jono: "It"? And I can't, but I can help get it done [05:21] StevenK, Lernid [05:21] * Hobbsee looks in [05:21] jono: in a ppa, or main archive, or? [05:21] Hobbsee, hi! thanks :-) [05:21] it is in my PPA [05:21] Lernid 0.5 [05:21] I kicked off a Lernid built and then I planned a copy for a Karmic build [05:21] * Hobbsee looks it up [05:21] https://edge.launchpad.net/~jonobacon/+archive/ppa/+build/1465979 [05:22] Hobbsee: ^ [05:22] https://edge.launchpad.net/~jonobacon/+archive/ppa/+build/1465979 [05:22] aha :) [05:22] jono: prodded [05:22] Hobbsee, what do you mean? [05:22] oh wow! [05:22] jono: it means i took it on a walk [05:22] you are a rockstar :) [05:23] jono: for reference, it's great if you can provide that link earlier, so buildd admins don't have to scramble looking for which you might mean, particularly if it's for a ppa ;) [05:23] haha, np [05:23] Hobbsee, will do :) [05:23] thanks! [05:24] * Hobbsee starts to think it'd be nice for buildd to be modified to work for ppas too [05:26] jono: how clever [05:27] Hobbsee, :) [05:27] And lernid is built [05:27] persia: thanks [05:27] nice, i like how it's clear on what stage it's up to now, and why it isn't there in the archive yet [05:28] owen1: That worked for you then? Excellent. [05:28] Hobbsee, mind doing the same for https://edge.launchpad.net/~lernid-devs/+archive/lernid-releases/+build/1466114 ? [05:29] persia: i just read your reply, didn't run that command yet [05:30] jono: prodded with the Long Pointy Stick of Doom!!!! ™ [05:30] Hobbsee, that stick is awesome! [05:30] jono: very! it's had a long vacation [05:30] Hobbsee, good to be back :-) [05:30] so is nicely sharp and pointy, ready for it's next adventures [05:30] yup! [05:30] * jono hugs Hobbsee :) [05:30] :D [05:31] Hobbsee, you must be so pleased :) [05:32] Hobbsee: That's what happens when you store the Long Pointy Stick in a pencil sharpener when you're not using it [05:33] StevenK: if i'd done that, i don't think it'd exist anymore [05:33] it'd be all sharpened out [05:33] At least it wouldn't be so long. [05:33] Damn, my plan has been foiled. [05:33] Hobbsee, is there likely to be a delay in publishing the packages? [05:33] as in, a 2 day delay [05:33] :) [05:34] jono: Nope. [05:34] jono: nah. publishing happens every 20 minutes, last i knew [05:34] sweet :) [05:35] wow, +builds has had a lot of improvements. Think i'll have to close some of my bugs against it [05:35] all set for Ubuntu Developer week :) [05:35] Lernid is rocking :) [05:37] Hobbsee: */5, now! You are behind the times. [05:37] wgrant: oh nice. very behind the times [05:37] wgrant: seeing as you are not, do you know how i get https://bugs.edge.launchpad.net/~hobbsee to work? [05:38] Hobbsee: Use production. [05:38] There is a bug. [05:38] oh yeah [05:38] rightio [05:38] I believe the bugfix is yet to land, although it has been written. [05:38] * StevenK attempts to get undistracted [05:39] fair enough [05:43] * ScottK cheers the reappearence of the stick. [05:43] StevenK: Thanks for luatex. [05:43] persia: ok, i submitted new bug. thanks [05:43] https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/512192 [05:43] Ubuntu bug 512192 in xserver-xorg-input-synaptics "configuring Elan tech touchpad on Delll Inspiron 11z" [Undecided,New] [05:43] heya ScottK! [05:43] Heya Hobbsee. [05:44] owen1: Good luck. [06:45] what is the best way for me to re-build Lernid 0.5 but for Lucid? [06:45] in https://edge.launchpad.net/~lernid-devs/+archive/lernid-releases [06:49] jono: Looks like you should be able to safely binary-only copy that to lucid. [06:49] good morning [06:50] RAOF, you think? [06:51] jono: You could copy the source & have to poke to have it rebuilt again, but it's pure-python, right? [06:51] RAOF, it is [06:51] it just has a stack of dependenices [06:51] dependencies [06:52] It looks like they're all satisfied on Lucid, as well. [06:53] And you'll have manually specified those dependencies, because we aren't awesome enough to extract python dependancies from python source. [06:53] RAOF: "Yet" [06:54] StevenK: Indeed. [06:56] It's not as easy as extracting shlib depends, but it's not impossible. [07:06] RAOF: Doesn't ${python:Depends} try to do something like that? [07:07] persia: Mostly it helps pick the right version of the python interpreter to depend on. [07:08] Someday .... [07:08] Ah. I thought it somehow dig into setup.py and did the right thing [07:08] s/dig/dig/ [07:08] dug! [07:08] dog? [07:11] dag [07:12] No, really, dug. Not quite the same vowel transition as sit/sut, but the same idea. [07:12] * persia wishes for a sanely conjugated language as the de facto international default [07:13] All languages have their little excentricities :) [07:13] Sometimes native-speakers are even able to spell each word in a sentence correctly, too. [07:14] If we're lucky [07:14] Somehow I suspect some difficulties combining that with grammatical sanctity. [07:17] Good morning [07:18] Good morning. [07:18] pitti and lool: Thanks for the quick MIR review on luatex over the weekend. [07:31] kees: "disable palimpsest"? [07:31] kees: oh, the bad block warning; we should perhaps disable that if it's not fixed in time, indeed [07:57] could someone please sync epiphany-extensions from debian/unstable? It doesn't look like it will find its way to testing soon, but epiphany 2.29 is already in lucid. I'll file a sync request later… [07:58] siretart`: synced [07:59] Good morning everyone! =) I have exam today, wish me luck =) Testing alternative daily cd now [08:04] persia: someone has the same touchpad issue as me! [08:05] how many people should be affected by a bug so it will be fixed by ubuntu developers? [08:08] pitti: it's not fixed in karmic too -- it's causing a lot of bug reports. [08:08] nixternal: yikes. :P [08:15] pitti: thanks! [08:17] pitti: wrt python-launchpadlib, I'm going to include fix in Debian too, thanks for fixing! [08:18] DktrKranz: thanks! I sent a Debian bug, just didn't receive the ack for it yet [08:19] fine, thanks again :) [08:25] DktrKranz: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566795 [08:25] Debian bug 566795 in python-launchpadlib "python-launchpadlib: Always depend on python-simplejson" [Important,Open] [08:33] pitti: committed as http://svn.debian.org/viewsvn/python-modules?view=rev&revision=11298 [08:33] \o/ === alkisg1 is now known as alkisg [09:52] Keybnz: ok, I've committed my attempt at splitting the plymouth upstart job; I've exercised it every way I can think of here (startup, shutdown, with or without being pulled into the initramfs, adding some sleeps here or there to cause races), and it's standing up for me [09:53] Keybnz: but I'd like it if you could give it a once-over before I upload [10:04] hey, good morning pitti. We've got a bug with a karmic-proposed language pack (bug 511837) - What's the usual procedure to sort this out? Do I simply ask you or any archive admin for removal of the package? [10:04] Launchpad bug 511837 in language-pack-ast "Latest language pack in 'karmic-proposed' breaks Firefox in Asturian" [Undecided,New] https://launchpad.net/bugs/511837 === xomas_ is now known as xomas [10:16] hey dpm [10:16] hey :) [10:16] dpm: if the others work fine, then let's just remove that -proposed version, indeed [10:17] dpm: however, a better fix would of course to upload a new langpack with a fix; so that's not easy to do? [10:18] pitti, yeah, altough we haven't yet located the problem [10:18] the cause, I mean [10:18] dpm: -gnome-ast is okay, though? [10:19] pitti, they've only complained about the -ast one, as they've noticed the problem with FF, which is in that pkg [10:20] pitti, let me ask you something else somehow related first: [10:20] you copied the 20090115 PPA langpacks to karmic-proposed at Arne's request, but at around the same time the 20090122 language packs were released on the PPA. [10:21] I want to make a call for testing, but for those using the PPA it might be a bit cumbersome, since they'll have to downgrade to the 20090115 langpacks in karmic-proposed in order to test them [10:21] Do you think it might be possible to copy all the 20090122 PPA langpacks to karmic-proposed? Is it an involved process? [10:22] dpm: not involved for me, just takes some buildd time [10:22] dpm: I'm happy to move them over if you want those tested instead [10:23] dpm: language-pack-ast removed from karmic-proposed, btw [10:23] dpm: so want me to copy ppa to proposed (except -ast)? [10:24] pitti, if possible, yes, please, all 20090122 from the PPA to karmic-proposed except -ast [10:28] dpm: running now [10:28] dpm: ETA half an hour for copying the sources, and perhaps a day for all the binaries to get built [10:28] awesome, thanks pitti! [10:28] you're welcome [10:39] persia: 20:00 UTC on Friday... hmm, not having managed to get around to prepping for it this weekend, I probably shouldn't commit, no :/ [10:41] slangasek: Well, let me know if you change your mind. I'm more than happy to not get up early, and while I'll prep, it's not much (as I've given the same session a few times before). [10:42] hello all [10:48] persia: ack, thanks [10:57] seb128, do you know which module provides /usr/bin/g-ir-scanner? [10:58] which binary you mean in lucid? [10:58] gobject-instrospection [10:58] MacSlow: http://packages.ubuntu.com/ [11:01] seb128, cjwatson: thanks [11:19] Is there a place where I can easily see the dependencies between pockets? [11:19] I guess it's somewhere in the Launchpad source code, I would guess near the ogre-model implementation [11:20] lool: How do you mean? Which pockets depend on which other pockets? [11:20] persia: Yes [11:20] e.g. -proposed depends on -updates [11:21] It's main->(null), restricted->(main), universe->(main), multiverse->(main,restricted,universe) [11:21] I'm not quite sure whether -updates depends on -security since the security updates are copied [11:21] Oh, at that level. [11:21] persia: I mean pockets, not components [11:21] Oh, sorry. I'm not sure. [11:28] Keybnz, are you around by chance ? i'm trying to find out how plymouth is supposed to work, i seem to be able to run it imaually on my babbage board and get a progressbar on tty8 but i dont see anything on boot [11:30] *manually [11:34] cjwatson: in GNOME, gnome-keyring-daemon already provides an ssh auth agent and sets $SSH_AUTH_SOCK; would it be okay if 90x11-common_ssh-agent would check that condition (i. e. running gnome and gnome-keyring autostart exists) and not run ssh-agent in that case? [11:35] pitti: if you can stop me being flooded with bug reports about that ssh agent sucking? [11:35] cjwatson: (i. e. without that Xsession.d script we save the0.7 second overhead, but still retain the nice UI password dialogs) [11:35] I wish we could *only* use the openssh one, frankly [11:35] asac: ping [11:36] cjwatson: well, I asked you only the second time now; but instead of just doing it, I'd rather check with you first [11:36] I don't see an obvious benefit for day-to-day desktop use, but I'm sure you know better what else it is used for [11:36] whatever, do it [11:36] I'll ask you any time I get a bug about it [11:36] cjwatson: what kind of UI would ssh-agent2 use? [11:37] day-to-day> this is the fallacy of novice users ... [11:37] right, and that's why I'm asking you :) [11:37] the point is that if we're making it difficult to use the openssh agent, the GNOME one had better be absolutely robust [11:37] since at least under GNOME, gnome-keyring does the password input, not ssh-agent (apparently) [11:37] and it isn't, judging from my bugmail [11:37] the openssh agent spawns ssh-askpass [11:38] well, how do you suppress g-keyring UI today? [11:38] you turn off the gnome-keyring autostart I guess [11:38] I'm not talking about removing the Xsession.d file; we need it for !GNOME or for people who remove the autostart file [11:38] using the capplet [11:38] seb128: right [11:38] but we can check for exaclty that [11:39] the change would break that [11:39] since the etc autostart will not go away [11:39] a .local one is written [11:39] when you uncheck it using the capplet [11:39] seb128: ah, good to know [11:39] now, still easy to test [11:39] pitti: what exact diff are you talking about applying here? [11:39] cjwatson: I don't have the diff yet; talking about strategy before starting to mess up things [11:40] AFAICS that Xsession script *already* checks [ -z "$SSH_AUTH_SOCK" ] [11:40] right, but it's ran before gnome-keyring [11:40] right, but g-k is started later on [11:41] how can we make it straightforward for people to use g-k for gpg but not ssh? [11:41] if there's a good argument for keeping it running even under GNOME, I'm happy to take a look at the ssh-agent code and see whether things can be moved around [11:41] to not block the startup for that long until it forks [11:41] cjwatson, g-k doesn't do gpg [11:41] cjwatson, seahorse does [11:41] oh [11:41] is it not seahorse that's being the ssh agent then? [11:41] * cjwatson is confused about how all the pieces fit together [11:41] no, gnome-keyring is [11:41] seahorse is the gpg agent [11:42] ah [11:42] pitti: the good argument is that ssh-agent is much more robust [11:42] (which we don't install by default) [11:42] I keep getting bugs about the agent having died; they always turn out to be because people were using g-k [11:42] urg [11:43] we may have been reassigning some of them incorrectly to seahorse [11:43] I will check [11:43] but I'm subscribed to both and see very few crashers there [11:43] and I think g-k doesn't support all the features either; IIRC it doesn't support time-limited identities [11:43] well, it's some for g-k versus none for openssh :) [11:44] right [11:44] I've no opinion on whether you should better fix gnome-keyring or drop it [11:44] oh, ssh-agent doesn't cache passphrases by default? [11:44] ah, ignore me [11:45] I've no issue with gnome-keyring and I expect it works for most users just sshing random boxes [11:45] I'd definitely like to know why ssh-agent makes a significant difference to startup time [11:45] it does hardly anything on startup [11:45] it might have limitation than power users hit though [11:45] http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-3.png vs. http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-3-no-ssh-agent.png [11:46] (note that on the former, the first gnome-session process is actually ssh-agent, due to the fork/execve'ing bootchart gets confused) [11:47] an strace would be useful [11:48] hm; I disabled the g-k autostart .desktop, and I still don't get passphrase caching [11:48] seb128: anyway, text-mode only input isn't really an option, is it? (i. e. dropping g-k); it would break sftp gvfs connections and all that? [11:48] cjwatson: aye, I'll give it some tracing [11:49] dropping g-k isn't text-mode-only [11:50] hm, perhaps the agent just isn't working for me [11:50] ssh-add reads a passphrase from the terminal if it has one, but if it doesn't have one and it has $DISPLAY, it uses ssh-askpass-gnome [11:51] god ! [11:51] who decided to lock my screen every time DPMS kicks in [11:51] thats overly annoying [11:51] of course we don't install ssh-askpass-gnome by default ... [11:51] oh, we do [11:51] we don't, but that could be fixed [11:52] we do, it has Task: ubuntu-desktop [11:52] ah, it's called gnome-ssh-askpass, sorry [11:52] oh, the binary is, yes [11:53] I wonder if it's taking ages to seed the RNG for some reason [11:53] hm; $SSH_AGENT_PID points to ssh-agent, and $SSH_AUTH_SOCK is set as well [11:54] We could put 50 megabytes of random bits to the installer CD and have installations use the file for fast random numbers. [11:55] FSVO "random", yes :) === MacSlow is now known as MacSlow|lunch [12:00] so, AFAICS the check for "will gnome-keyring be running" should be done either way, since g-k just shadows ssh-agent [12:01] but there's still the option of disabling g-k by default and thus making ssh-agent actually used [12:01] bugs in g-k relevant to ssh: bug 505278 (missing feature, arguably dangerous), bug 485537 (stability), bug 470456 (key decode problem?), bug 418879 (stability), bug 383926 (stability), bug 365589 (stability) ... [12:01] Launchpad bug 505278 in gnome-keyring "ssh-add -D deleting all identities does not work. Also, why are all identities auto-added?" [Low,Confirmed] https://launchpad.net/bugs/505278 [12:02] Bug 485537 on http://launchpad.net/bugs/485537 is private [12:02] Launchpad bug 470456 in gnome-keyring "gnome keyring with ssh-agend breaks pubkey login" [Low,Triaged] https://launchpad.net/bugs/470456 [12:02] Launchpad bug 418879 in gnome-keyring "seahorse fails with concurrent ssh connections" [Low,New] https://launchpad.net/bugs/418879 [12:02] Launchpad bug 383926 in openssh "ssh-aggent stopped accepting connections" [Undecided,Invalid] https://launchpad.net/bugs/383926 [12:02] it appears that generally gnome-keyring just stops accepting connections rather than actually crashing [12:03] the failure mode where it all gets stuck and ssh-add -l says it can't connect to the agent seems moderately common [12:03] hm, I still can't get this to work; "ssh-agent /bin/bash" sets the $SSH_* but doesn't do any caching; so it seems the Xsession.d script is actually wrong [12:04] cjwatson: thanks for fishing out the bugs; that's good to know for deciding which one to use by default [12:04] oh and some problem with the confirmation prompt which seems like it might be bound up with a bug or two in openssh as well? bug 209447 [12:04] Launchpad bug 209447 in gnome-keyring "gnome-keyring-daemon does not honor constrained ssh identities" [Medium,In progress] https://launchpad.net/bugs/209447 [12:04] oh, you have to explicitly use ssh-add [12:05] yes [12:05] looks like I ought to backport the patch from https://bugzilla.mindrot.org/show_bug.cgi?id=1612 [12:05] bugzilla.mindrot.org bug 1612 in ssh-add "ssh-add should not discard constraints if the agent fails to implement them" [Normal,Closed: fixed] [12:06] but 209447 still indicates that ssh-add -c will be ineffective with g-k [12:07] pitti: users of openssh ssh-agent and g-k do have slightly different expectations [12:07] *nod* [12:07] the expectation with g-k is (as far as I can tell?) that it loads all your identities automatically [12:07] the expectation with ssh-agent is that you have to explicitly request addition of the identities you want [12:07] but if you always have to open a terminal to do "ssh-add" and enter your passphrase, where does the UI come into play? [12:08] I believe that if you use an ssh program without a terminal attached, you should get a passphrase prompt too ... [12:08] it just won't cache it [12:10] hmm, maybe I'm wrong [12:11] if I could remember how to detach from a tty, I could test this :) [12:11] hmm; if I kill g-k, have ssh-agent running, and use "Connect to server" (sftp), I again get a g-k dialog [12:11] cjwatson: "nohup program"? [12:12] no, doesn't work, sorry (that just diverts stdin) [12:12] Alt+F2 "ssh foo" -> that works [12:12] I remember some packages linking against python and failing because of -lssl missing. Does someone remember how to fix it? Because I've a similar issue when merging vim (the python interpreter support doesn't get build-in because of this). [12:12] I see gnome-askpass-ssh [12:13] ah yes, thanks [12:13] geser, yes, one minute, I look for the change [12:14] similarly command-line sftp from Alt-F2 works [12:14] I'm not sure what "Connect to server" is doing [12:14] geser, https://bugzilla.gnome.org/attachment.cgi?id=146930 [12:14] geser, see https://bugzilla.gnome.org/show_bug.cgi?id=600706 [12:14] cjwatson: it uses gvfs' sftp module to create a virtual mount (thruogh sftp) [12:14] I guess the question is whether the expectations of openssh ssh-agent are sufficiently different to make it difficult to migrate to in the Ubuntu desktop [12:14] Gnome bug 600706 in general "don't use LOCALMODLIBS in the configure" [Normal,Unconfirmed] [12:15] geser, could be similar [12:15] cjwatson: right now it seems that g-k is woven pretty tightly into gnome; I'm not sure it'd be a good idea to rip that all apart in an LTS [12:16] there is no reason we could fix the few issues g-k has, it doesn't seem to be too buggy [12:16] couldn't [12:17] seb128: thanks, I'll check if I get this adopted to vim. Should this be forwarded to Debian (I don't know if Debian's python and ours are similar enough to cause similar problems in Debian too)? [12:18] geser, dunno if that's similar but the use is wrong in any case [12:18] seb128: the concurrency issue is the big one, I think [12:18] geser, having it failing it build now is just a sideeffect [12:19] ok [12:19] it would be nice to add the missing agent protocol features as well, but concurrency problems are the ones that bite most users [12:20] right [12:20] we should try to get this one fixed in any case [12:20] would be useful to have an overview of the behaviour difference [12:21] and how gnome-keyring integrates in GNOME where the openssh one doesn't [12:21] cjwatson: so, thanks for your help! it doesn't seem useful to me to have two agents running at the same time, so I'll work on that Xsession.d script [12:21] looks like the bug reports on gnome-keyring are reasonably complete [12:22] pitti: yes; as long as there's a reasonably easy (preferably documented!) way to use the openssh one [12:22] cjwatson: ^ I agree; that's the very same problem right now, though (i. e. disable gnome-keyring autostart) [12:22] * pitti ponders where to add that [12:23] could go into a comment into that Xsession.d file, but that's not very visible [12:23] that would be OK [12:28] pitti: perhaps a link to http://live.gnome.org/GnomeKeyring/Ssh [12:28] or just the gconftool command from there [12:29] ah, thanks [12:30] I'd much prefer actual documentation than a web link: sometimes I am in networks where ssh is permitted and http is not. [12:30] seb128: hm, querying for a gconf key is much more expensive than querying for the presence of an autostart file [12:30] pitti, sure, it uses gconf [13:08] Does anyone know if quilt will make a directory if need be? [13:08] * NCommander can't remember if it does on the fly [13:08] NCommander: It depends on your .quiltrc [13:08] * persia hunts up the super-cool script [13:08] persia, I meant if building on the biuldds. [13:09] persia, I've almost finished porting likewise to ARM, but I need to add a new directory with files in it [13:09] You mean, can a quilt patch create a directory? [13:09] persia, yeah [13:09] Yes, that's no problem at all, so long as it contains contents. [13:11] Anyway, the cool snippet fell off p.d.o anyway. It automagically created debian/patches if needed. [13:11] s/anyway// [13:13] lool, persia: re components> https://wiki.ubuntu.com/SecurityTeam/FAQ#Repositories [13:13] lool, persia: (and pockets) [13:14] jdstrand: Cool. Thanks. [13:15] jdstrand: excellent, thanks [13:19] jdstrand: Is there a -security -> -updates copy that happens as well? [13:20]