[00:07] <infinity> ion: Does this mean you'll be sponsoring my uploads and reviewing my patches and such? ;)
[00:10] <ion> infinity: It did from 02:25:49 to 02:26:17 (UTC+3).
[00:14] <infinity> Damnit, I missed my chance.
[00:20] <lynxman> it was such short... but intense piloting
[00:22] <kees> anyone else seeing "debsums: invalid package name" errors?
[00:23] <kees> seems related to doing sums on transitional packages
[00:28] <ion> kees: Yeah. There’s a bug report about it on Launchpad.
[00:28] <ion> Bug #809924
[00:54] <stgraber> kees: debsums might be a bit broken at the moment because of the changes that happened to it to make it multiarch aware. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616066
[00:55] <stgraber> kees: what's in Oneiric is based on a relatively hacky script I wrote back the sprint but I probably missed some corner cases that have been addressed by the newer version of the patch in Debian
[01:00] <kees> stgraber: ah, cool
[01:57] <mynameisdeleted> I'd like to submit artwork to the ubuntu project
[01:57] <mynameisdeleted> whats the process for doign that?
[02:02] <hammma> where can I suggest ideas for the unity project?
[02:15] <sladen> hammma: ayatana-design
[02:17] <sladen> hamma: https://launchpad.net/~ayatana
[02:17] <sladen> hammma: should be a subscribe link at the bottom
[02:19] <hammma> thanks
[05:23] <pitti> Good morning
[05:46] <didrocks> good morning
[06:51] <YokoZar> Is there an environment variable that will set bzr launchpad-login ?
[06:55] <infinity> YokoZar: Setting it with 'bzr launchpad-login' isn't enough?
[06:56] <YokoZar> infinity: meh, I figured I could put it in bashrc along with the long list of other environment variables I have there like BZR_EMAIL
[06:56] <infinity> You could put "bzr launchpad-login whoever" in bashrc...
[06:58] <broder> bzr launchpad-login just sets a variable in ~/.bazaar, right?
[06:58] <YokoZar> for some reason I thought it did something a bit more complex than that, like verify the name somehow
[06:59] <infinity> launchpad_username in bazaar.conf, yeah.
[07:01] <YokoZar> ok then since it's persistent there's no need for environment variable or bashrc messing ;)
[07:01] <infinity> Nope, not if you always have a bazaar.conf.
[07:03] <dholbach> good morning
[07:04] <pitti> hey dholbach
[07:04] <geser> Hi pitti, dholbach
[07:05] <dholbach> hi pitti, hi geser
[07:10] <pitti> hey geser, wie gehts?
[07:22] <geser> pitti: I'm fine. And you?
[07:22] <pitti> pretty well, thanks! a bit in crunch mode due to the late respin for beta
[08:07] <dholbach> Ursinha, happy birthday!
[09:09] <jibel> pitti, where is the code of the apport duplicate finder ? it's doing things that doesn't make sense.
[09:10] <pitti> jibel: it's all in lp:apport, but where exactly depends on the nature of what you are seing
[09:10] <pitti> "seeing"
[09:10] <pitti> jibel: what's an example?
[09:11] <pitti> jibel: we recently added some non-crash dupe things to the ubuntu hook (/usr/share/apport/general-hooks/ubuntu.py); these are fairly new and might cause false positives
[09:12] <jibel> pitti, it marked bug 837503 and bug 837288 as duplicates of bug 837042. In its logic it is probably right but we should probably add rules to say "Don't touch a report that is in this state".
[09:13] <jibel> like don't touch what is triaged
[09:14] <jibel> or also bug 837282 as duplicate of bug 619363, one is a timeout of dbus the other is a dbus service not found
[09:17] <pitti> jibel: right, that DuplicateSignature looks totally inadequate for a manually created bug report
[09:18] <pitti> bdmurray: ^ I think ubuntu.py should only add these for crash bugs perhaps, not for manually filed bugs?
[09:19] <pitti> jibel: so for that I think the code is in /usr/share/apport/package-hooks/source_ubiquity.py
[09:20] <pitti> line 73 ff.
[09:20] <pitti> it sets the DuplicateSignature regardless of the ProblemType
[09:20] <pitti> it shuold only do that for "Crash" and perhaps "Package", but not "Bug"
[09:20] <pitti> bdmurray: ^ do you agree?
[09:22] <pitti> jibel: bug 837288 should keep the DuplicateSignature, though, do you agree?
[09:27] <jibel> pitti, the signature is wrong. It is not the error in the Traceback but from ubiquity syslog, which is not what triggered the crash.
[09:27] <pitti> jibel, bdmurray: first fix: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/oneiric/apport/ubuntu/revision/1834
[09:28] <pitti> bdmurray: can you look into the wrong DuplicateSignature in 837288?
[09:28] <pitti> jibel: right; I meant for these kinds of bugs it makes sense to keep a DuplicateSignature, but not for the other two (ProblemType Bug)
[09:28] <pitti> jibel: I'll remove that faulty master bug from the dup db in a moment
[09:29] <jibel> pitti, agree. for crash reports it makes sense to keep the signature.
[09:30] <lynxman> jhunt_: ping
[09:30] <jhunt_> lynxman: hi
[09:30] <lynxman> jhunt_: hey :)
[09:30] <lynxman> jhunt_: I've been fighting with a bug the last day, very nasty one
[09:31] <lynxman> jhunt_: looks like a race condition in the initrd ramfs when your root or swap are in extended partitions
[09:31] <lynxman> jhunt_: which makes udev not mount properly and you can't boot up
[09:31] <lynxman> jhunt_: in oneiric server
[09:31] <lynxman> jhunt_: bug 818177
[09:32] <jhunt_> lynxman: I'll take a look...
[09:32] <lynxman> jhunt_: adam_g suggested a small patch to /usr/share/initramfs-tools/scripts/init-bottom/udev
[09:32] <lynxman> jhunt_: just want to make sure it makes sense from the foundations side as well
[09:32] <lynxman> jhunt_: thanks :)
[10:17] <infinity> jml: I bet it suspends great, it just fails to resume. ;)
[10:18] <cjwatson> tkamppeter: it's too late to change beta-1 for anything short of an emergency
[10:19] <pitti> tkamppeter: this kind of bug can be fixed perfectly with a  post-installation upgrade
[10:37] <tkamppeter> cjwatson, pitti, OK. Probably beta1 users update regularly anyway, as it is not a final.
[10:37] <cjwatson> yes, I think that can be expected
[11:08] <cr3> is there a debian script or something for a package to modify the configuration file of another package when it doesn't have a convenient *.d directory, ie should be able to add either lines or a section on install and then remove that on uninstall
[11:09] <pitti> cr3: if it's a dpkg-managed configuration file (so-called "conffile"), this is not allowed
[11:09] <pitti> cr3: if it's a non-managed file, there are no scripts for this, as every conffile looks different; the usual approach is to use sed, etc.
[11:10] <cr3> pitti: /etc/sysctl.conf, I'm only writing a convenience optimization package for use in the cloud, not intended for the real archives :)
[11:10] <pitti> cr3: but these things need to be done very very VERY careful; it must never touch a file of an unkonwn/unexpected format, the code needs to be idempotent, etc.
[11:10] <ogra_> cr3, you want /etc/sysctl.d/ instead
[11:10] <pitti> cr3: sysctl.conf is a conffile; what ogra said
[11:11] <ogra_> that can override /etc/sysctl.conf and you only drop a file in place with your package
[11:12] <cr3> awesome, I didn't even notice sysctl.d! I can't remember last time I actually did an ls of /etc, strange :)
[11:13] <cr3> but now I have to modify /etc/postgresql/$version/main/postgresql.conf :(
[11:13] <pitti> cr3: that's not a conffile
[11:14] <pitti> cr3: also, that file isn't guaranteed to exist (there might be more/other/differnet clusters), but as long as it's for a personal package, that's fine
[11:14] <cr3> pitti: yeah, it's personal but I'm still trying to be minimally careful, like not just appending blindly and so forth
[11:50] <bdrung> cjwatson: are you working on a patch for xmms2?
[11:51] <bdrung> oh, now i got the mails. thanks for your work.
[11:55] <cjwatson> bdrung: I'm working on all the remaining libav NBS dependencies (that Fabrice doesn't beat me to)
[11:56] <bdrung> :)
[11:57] <cjwatson> it's just a bit tedious
[12:07] <bdrung> cjwatson: can you give me your patch as real file / attachment? i copied the inline patch and 'patch' complains about it.
[12:12] <cjwatson> bdrung: perhaps easiest to grab it from https://launchpadlibrarian.net/78695385/xmms2_0.7DrNo%2Bdfsg-2build2_0.7DrNo%2Bdfsg-2ubuntu1.diff.gz
[12:12] <cjwatson> minus the debian/control bit of course
[12:28] <Daviey> slangasek: Do you have thoughts on, bug 835625 .. smelling multiarch related.
[12:57] <jibel> pitti, do you still get bug 831884
[12:57] <jibel> ?
[12:57] <pitti> jibel: I didn't notice apport popping up for this
[12:57] <jibel> not  the master, the first report.
[12:58] <jibel> 831884
[12:58] <pitti> jibel: but I didn't do a test case with an existing user account, so there was nothign to migrate
[12:58] <pitti> jibel: ah, no, I don't get 831884 any more
[12:59] <jibel> it is still an issue there with ubiquity 2.7.25
[12:59] <pitti> I tried the beta-1 on the very same machine (Mini 10), plus my workstation (X201), both worked fine
[13:03] <jibel> I tried on an eeepc, same error. another system work fine booted from CD. I'll try from USB.
[13:30] <lynxman> jhunt_: hey sir o/ any feedback on bug #818177?
[13:47] <jhunt_> lynxman: can't recreate the problem myself yet, but the proposed solution sounds reasonable, although maybe we should have some sort of timeout waiting for udev?
[13:48] <lynxman> jhunt_: okay, I'll figure out a patch with a timeout value then :
[13:48] <lynxman> :)
[14:04] <bdmurray> pitti: one issue with using if report['ProblemType'] != bug is bug 712677
[14:22] <Andy80> hi all
[14:23] <Andy80> I've read that Oracle retired their license for distributing their SDK on Linux... does it mean we will be able to distribute only OpenJDK in the Software Center?
[14:24] <pitti> bdmurray: right, we need to fix that
[14:27] <bdrung> cjwatson: uploaded xmms2 to sid. i did more changes: http://anonscm.debian.org/gitweb/?p=pkg-xmms2/xmms2.git
[14:28] <cjwatson> ok, dh_python2 will need an FFe though
[14:30] <slangasek> Andy80: what Oracle has retired is their standing public redistribution license; given that the sun java packages currently available through Software Center are part of the Canonical Partner archive, not part of Ubuntu itself, it's not clear from this whether Oracle will maintain that particular relationship
[14:32] <Andy80> slangasek: ok, so it's a different agreement, not the general one. Thanks
[14:33] <slangasek> Andy80: well, I'm not actually privy to whether Canonical does have a separate license agreement for those packages - but by virtue of the package's presence in partner, I can say there's a direct *relationship*, so they may work something out :)
[14:33] <slangasek> Daviey: thanks, bug #835625 triaged
[14:47] <pitti> stgraber: oh, bfb? I thought that was gone in oneiric now, does 2d still have it?
[14:47] <stgraber> pitti: it's still called bfb (as in the file) but that's now the dash launcher
[14:47] <pitti> jibel: trying a zh_CN install with the oneiric desktop CD now; which one is simplified Chinese, the third-last or second-last in the language list?
[14:49] <pitti> stgraber: ah
[14:49] <jibel> pitti, this one 中文(简体)
[14:49] <slangasek> the simpler one, obviously! :)
[14:49] <pitti> jibel: ah, it does look a tad simpler, doesn't it
[14:49] <pitti> jibel: merci!
[14:49]  * pitti now trying to do a "blind" install
[14:50] <stgraber> pitti: anything in particular you want to test?
[14:50] <pitti> jibel: still curious that I don't see it when I create a chinese user in a running system, or in the live session
[14:50] <stgraber> pitti: I just did a chinese test install for Edubuntu
[14:50] <pitti> stgraber: bug 771510
[14:50] <pitti> stgraber: and the two related ones for two other indicators
[14:50]  * pitti retitles the bug
[14:50] <stgraber> pitti: ok, I have an installed chinese system here, let me have a quick look
[14:50] <pitti> bug 771510
[14:51] <pitti> stgraber: some indicators show "Empty Label" in them
[14:51]  * pitti figures out how to select US keyboard layout
[14:51] <stgraber> "Label Empty" actually
[14:52] <pitti> ah, right; bug updated
[14:52] <stgraber> session/me, sound and date all have the problem
[14:52] <pitti> yeah, seems everyone gets it but me..
[14:52] <pitti> I'm currently doing a clean test install with zh_CN right from the start
[14:53] <pitti> seems it doesn't happen in live session or post-install
[14:53] <stgraber> ouch, and seems like we also have some font problem (might be related
[14:53] <pitti> ah, with the "guess your keyboard layout" button I was able to find US :)
[14:53] <stgraber> pitti: default chinese keyboard is US
[14:55] <stgraber> pitti: http://www.stgraber.org/download/unity-chinese.png
[14:55] <stgraber> that doesn't look too good :)
[14:55] <pitti> whee
[14:55] <pitti> I didn't get that
[14:56] <pitti> after jibel's latest post I'm beginning to think it's a broken locale setting
[14:56] <stgraber> for some reason I didn't get that in the live session either, only on the installed system
[14:56] <pitti> stgraber: do you mind to post the output of "locale" to that bug, plus ~/.profile and /etc/default/profile ?
[14:56] <stgraber> pitti: and you'd be right, locale is wrong
[14:56] <pitti> if it is locale, then it'll also explain why I didn't get it with a test user
[14:56] <stgraber> pitti: I have zh_CN not zh_CN.UTF-8
[14:56] <pitti> as control-center sets it right
[14:56] <pitti> accountsservice, I mean
[14:57] <pitti> stgraber: I bet that's it; it's getting an invalid LC_CTYPE and chinese $LANGUAGE
[14:57] <stgraber> restarting session with the right locale
[14:57] <stgraber> everything looks good now
[14:58] <pitti> ok, so we should just attach the wrong files; my install is almost through, will do it afterwards unless you beat me to it
[14:58] <stgraber> ok, so I guess that bug should be changed to: "/etc/default/locale set to zh_CN instead of zh_CN.UTF-8 when installing in Chinese"
[15:00] <stgraber> pitti: attached the screenshot and /etc/default/locale to the bug
[15:01] <stgraber> I guess this will need re-assigning but not sure to what, localechooser?
[15:03] <stgraber> pitti: it very well might explain bug 838845
[15:03] <pitti> stgraber: very probabl
[15:03] <pitti> e
[15:03] <pitti> stgraber: I updated the bug and will add a few dupes
[15:06] <pitti> stgraber, jibel: ok, reproduced here as well; I updated the bug and duped the others
[15:14] <pitti> Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell
[15:14] <pitti> (freeze lifted, go wild)
[15:14] <pitti> didrocks: ^ you might fancy uploading unity-2d
[15:15] <didrocks> pitti: ah nice, I'm preparing the next release of unity-2d with the unity one right now :)
[15:25] <tkamppeter_> pitti, It looks like that LP has a problem with the two s-c-p uploads approved at once. It seems that it has picked the older one, 1.3.6+20110824-0ubuntu2 instead of 1.3.6+20110831-0ubuntu1.
[15:25] <pitti> tkamppeter_: it should have accepted both
[15:26] <tkamppeter> pitti, See https://launchpad.net/ubuntu/+source/system-config-printer, which shows the old version and https://launchpad.net/ubuntu/+source/system-config-printer/+changelog which includes the new version.
[15:27] <tkamppeter> pitti, I got two accept e-mails, but the one for the old version came after the one for the new version.
[15:27] <pitti> tkamppeter: the latter page shows unpublished sources, too; all is well
[15:30] <tkamppeter> pitti, yes I can access the newer version's page through a link on the changelog page.
[15:30] <cjwatson> don't worry about mail ordering
[15:31] <slangasek> if both are accepted, the higher version will win
[15:31] <cjwatson> just leave it an hour or so and everything will sort itself out
[15:34] <tkamppeter> OK, thanks.
[15:38] <bdmurray> superm1: Did you see my patch in bug 766160?
[16:05] <qmr> Why is empathy the default IM client?
[16:28] <hallyn> how come /dev/mqueue is not mounted  by default on an ubuntu system?  Just obsolete?
[17:00] <kirkland> jml: ping
[17:00] <jml> kirkland: hi
[17:00] <kirkland> jml: i'm not able to reproduce https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/838807
[17:00] <jml> kirkland: ah, ok. I can reproduce it easily and lots.
[17:00] <kirkland> jml: hmm
[17:01] <kirkland> jml: actually, hang on
[17:01] <jml> kirkland: I mean, sucks to be logging out all the time.
[17:01] <kirkland> jml: i'm encrypting all of $HOME, you're encrypting $HOME/Private
[17:01] <jml> kirkland: yep
[17:01] <kirkland> jml: let me try to reproduce that
[17:01] <jml> kirkland: ok. thanks.
[17:01] <kirkland> jml: oh, one more thing
[17:02] <kirkland> jml: ls -alF $HOME/.ecryptfs/auto-mount
[17:02] <kirkland> jml: and is this a recent thing?  or has it been doing this for a while?
[17:02] <jml> -rw-r--r-- 1 jml jml 0 2008-10-14 07:09 /home/jml/.ecryptfs/auto-mount
[17:02] <jml> kirkland: for a while
[17:02] <kirkland> jml: dang
[17:02] <kirkland> pitti: ping?
[17:02] <kirkland> pitti: you encrypt *just* $HOME/Private, right?
[17:02] <kirkland> pitti: have you seen https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/838807 yet?
[17:03] <cjwatson> I think I've seen that.  I can't log out right now though, and it seems fine on the first login after booting (which this is)
[17:04] <cjwatson> -rw-r--r-- 1 cjwatson cjwatson 0 2008-08-20 14:14 /home/cjwatson/.ecryptfs/auto-mount
[17:04] <kirkland> hmm, is there any chance that subsequent logins are short circuiting the pam stack in lightdm?
[17:04] <slangasek> twitch?
[17:06] <kirkland> jml: one more thing ...  could you try with ssh?
[17:06] <kirkland> jml: ie, logout of your desktop, and then ssh in/out repeatedly, and see if it's automounting/unmounting
[17:06] <kirkland> jml: i just tried that with an encrypted private, and ssh logins seem to be behaving properly
[17:07]  * kirkland logs out to test this
[17:10] <jml> kirkland: ok. sure. sorry for delay.
[17:10] <jml> umm
[17:10] <jml> I need something to log in with.
[17:12] <kirkland> jml: ssh?
[17:12] <kirkland> jml: if you're running an ssh server there, you can drop to a tty, login as root or another user, and ssh jml@localhost
[17:12] <jml> kirkland: ahh, right.
[17:12] <kirkland> jml: i just logged in/out 10x times with a test user and an encrypted private directory, with no luck reproducing the problem
[17:12] <jml> kirkland: ok. will try that.
[17:13] <kirkland> jml: do a mount | grep ecryptfs in between logins
[17:13] <kirkland> jml: to see if you're getting unmounted properly
[17:13] <jml> ok
[17:14]  * jml tries.
[17:20] <kirkland> jml: hmm, I'm just not reproducing this
[17:20] <tgm4883> jdstrand, ....
[17:21] <jandrusk> Really? Dead link off of "Create" section of developer.ubuntu.com? http://developer.ubuntu.com/create/qt/
[17:21] <superm1> bdmurray, yeah but i don't have access to sponsor it until next week.
[17:21] <jml> kirkland: so I tried logging out, but I need to reconfigure my SSH server :)
[17:21] <superm1> it looks fine to me though
[17:22] <jml> kirkland: give me a bit longer.
[17:22] <jml> kirkland: when I log in on the tty as jml, I get an error.
[17:22] <barry> @pilot in
[17:22] <kirkland> jml: np;  i'll get this solved for you, but we'll need to work together a bit to triage it, since I'm not reproducing it
[17:22] <jandrusk> It's the last link on the left on 'QT creator'.
[17:22] <jml> kirkland: but I think it's the one in the paste in the bug report
[17:23] <kirkland> jml: are you in your desktop now?
[17:23] <jml> kirkland: yes.
[17:23] <kirkland> jml: okay, give me a couple of pastebins ...
[17:23] <kirkland> jml: ll $HOME/.ecryptfs/
[17:24] <kirkland> jml: and
[17:24] <kirkland> jml: ll $HOME/.ecryptfs
[17:24] <jml> kirkland: http://paste.ubuntu.com/679942/
[17:25] <jml> kirkland: going to try the SSH thing again now.
[17:26] <kirkland> jml: hmm, okay, i do see one aberration
[17:26] <kirkland> jml: minor, but let's try this ...
[17:26] <kirkland> jml: echo "$HOME/Private" > $HOME/.ecryptfs/Private.mnt
[17:26] <kirkland> jml: ie, set your private mountpoint
[17:27] <kirkland> jml: i think that should default to $HOME/Private, but it's possible that it's not doing so for you?
[17:27] <jml> kirkland: ok. done that. Will log out and log in again.
[17:27] <kirkland> jml: k
[17:29] <jml> kirkland: no joy.
[17:29] <jml> kirkland: want me to try the SSH thing, now that I have a properly configured server?
[17:29] <kirkland> jml: okay ls -alF /dev/shm/ecryptfs-jml*
[17:30] <jml> kirkland: -rw------- 1 jml root 2 2011-09-01 18:28 /dev/shm/ecryptfs-jml-Private
[17:30] <jml> kirkland: but this is while it is mounted
[17:30] <kirkland> jml: cat /dev/shm/ecryptfs-jml-Private
[17:30] <jml> 1
[17:31] <kirkland> jml: okay, good
[17:31] <kirkland> jml: yeah, try ssh
[17:31] <kirkland> jml: you can even do it in your desktop session
[17:31] <kirkland> jml: just ssh in and out of localhost
[17:32] <jml> kirkland: ssh works while I'm in desktop session (thing shows up as mounted).
[17:32] <jml> kirkland: shall I try outside of desktop session?
[17:32] <kirkland> jml: ecryptfs-umount-private
[17:32] <kirkland> jml: make sure it gets unmounted
[17:32] <kirkland> jml: mount | grep ecryptfs
[17:33] <kirkland> jml: and then try in and out of ssh a couple of times (3?  4?  5?)
[17:34] <jml> kirkland: http://paste.ubuntu.com/679951/ (line 25 is when I umount)
[17:35] <kirkland> jml: ooh, so you can reproduce it with ssh alone?
[17:35] <kirkland> jml: dpkg -l ecryptfs-utils
[17:35] <jml> kirkland: apparently so. although I notice that with SSH I don't get the warning about keyctl_search, which I *do* get when I do a tty login after first desktop logout
[17:36] <jml> ii  ecryptfs-utils      90-0ubuntu1         ecryptfs cryptographic filesystem (utilities)
[17:36] <kirkland> jml: okay, do: keyctl list @u
[17:36] <kirkland> jml: this should show 2 keys in your keyring
[17:36] <kirkland> jml: well, 2 if you're encrypting filenames
[17:36] <jml> no, only one.
[17:36] <kirkland> jml: 1 if you're not
[17:37] <jml> I don't know if I'm encrypting filenames. I chose the option on install some three years ago :)
[17:37] <kirkland> jml: wc -l $HOME/.ecryptfs/Private.sig
[17:37] <kirkland> jml: :-P
[17:37] <kirkland> jml: if that wc is 1, then you're not
[17:37] <kirkland> jml: if it's 2, then you are
[17:37] <jml> 1
[17:37] <kirkland> jml: or, ls $HOME/.Private
[17:37] <kirkland> jml: and if you see normal filenames, then you're not encrypting filenames
[17:38] <jml> kirkland: right. they are all there.
[17:38] <kirkland> jml: if you see: ECRYPTFS_FNEK_ENCRYPTED.FWYkiiM.WVXtxUQ5kMZ3hnYV7a7TNI7Ya0xUZWDbvgdLrupba-Nlw.EU--
[17:38] <kirkland> jml: then you are :-)
[17:38] <kirkland> jml: okay, good
[17:39] <jml> kirkland: so, keyctl list @u has one key. Are there details there that you would like to see?
[17:39] <kirkland> jml: no need
[17:40] <kirkland> jml: okay, can you get it back to the point where you reproduce the problem, and then see if keyctl list @u shows 1 key?
[17:40] <jml> hmm. by "reproduce the problem", do you mean, say, in an ssh session?
[17:41] <kirkland> jml: sure
[17:41] <kirkland> jml: reproduce is "ssh in, enter password, but ~/Private is not mounted"
[17:42] <kirkland> jml: also, pastebin "md5sum /etc/pam.d/*"
[17:43] <jml> kirkland: http://paste.ubuntu.com/679960/
[17:45] <kirkland> jml: oooh, your /etc/pam.d/common-auth and /etc/pam.d/common-password differ from mine
[17:45] <kirkland> jml: could you pastebin those two files?
[17:45] <jml> kirkland: sure.
[17:45] <jml> http://paste.ubuntu.com/679966/
[17:46] <jml> http://paste.ubuntu.com/679968/
[17:47] <jml> kirkland: have 1 key under ssh
[17:47] <jml> oh
[17:47] <jml> but when I remount the thing I have two keys
[17:47] <kirkland> jml: oh ho ho, that's interesting, that gives me an idea
[17:48] <kirkland> jml: -auth   optional                        pam_smbpass.so migrate
[17:48] <kirkland> jml: that's inconsequential here
[17:48] <jml> also, the numbers are slightly different
[17:48] <jml> "1000    0" for one, "1000   1000" for the one that appears after mounting
[17:48] <jml> ok
[17:48] <jml> kirkland: sorry, I don't quite grok the "-auth" line.
[17:49] <kirkland> jml: oh, i just looked at your minor pam differences, and it's just an smbpass thing, which should have nothing to do with this
[17:49] <jml> ah right.
[17:50] <kirkland> jml: okay, so those two numbers are uid and gid, and that shouldn't matter here
[17:50] <kirkland> jml: but you're saying sometimes you have 2 keys in there, and sometimes 1?
[17:50] <jml> kirkland: when ~/Private is mounted, I have two
[17:50] <jml> kirkland: otherwise, 1
[17:50] <jml> kirkland: but maybe that's because I've been using the interactive command to mount it? /me really doesn't know. Not sure what it has on first login
[17:51] <kirkland> jml: okay, when private is mounted, could you give me the output of "mount | grep ecryptfs" ?  you may choose to fuzz the sig hex numbers, as these are hashes of your keys
[17:51] <kirkland> jml: i'm think i'm on the track here
[17:52] <jml> /home/jml/.Private on /home/jml/Private type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=XXXXXXXXXXX)
[17:53] <kirkland> jml: okay, take a mental note of the true value of your ecryptfs_sig=XXXXXXXXXXX
[17:53] <jml> got it.
[17:53] <kirkland> jml: now, do whatever you do to reproduce the problem (ie, get it to not auto mount)
[17:53] <kirkland> jml: and before mounting do your keyctl list @u
[17:53] <kirkland> jml: see if that hex key id is in the list
[17:54] <kirkland> jml: if i understand you correctly, there will be 1 and only 1 key in your list, and it won't be ecryptfs_sig=XXXXXXXXXXX
[17:54] <jml> kirkland: correct.
[17:54] <kirkland> jml: then do ecryptfs-mount-private
[17:54] <kirkland> jml: enter your pw, see that private mounted, and now keyctl list
[17:55] <kirkland> jml: and you get two keys in the list
[17:55] <kirkland> jml: which includes the necessary ecryptfs_sig=XXXXXXXXXXX
[17:55] <jml> kirkland: correct again.
[17:55] <kirkland> jml: okay, i have an idea of what's wrong
[17:56] <kirkland> jml: see line 46 of /usr/bin/ecryptfs-mount-private ... I need to simulate that in pam_ecryptfs.c
[17:56] <kirkland> jml: okay, give me a little while to get this reproduced and tested;  i'll put a package in a ppa for your testing
[17:56] <kirkland> jml: thanks for your patience
[17:56] <jml> kirkland: thank you for helping me debug this
[17:57] <jml> kirkland: or, umm, the other way around.
[17:57] <jml> kirkland: anyway, I'm grateful :)
[17:57] <kirkland> jml: :-)  yes, thank you
[17:57] <kirkland> jml: how much longer until your EoD?
[17:58] <jml> kirkland: I'm an hour past it.
[17:58] <kirkland> jml: okay, it might be on the morrow for you then
[17:58] <jml> kirkland: but I'll be around online most of the evening.
[17:58] <kirkland> jml: cheers, though, you'll have a ppa package waiting for you
[17:58] <jml> kirkland: ok, thanks. :)
[17:58] <kirkland> jml: okey doke
[18:12] <pdtpatr1ck> Question .. what's the preferred method for building a package.. there's dkpg-buildpackage -rfakeroot .. there's fakeroot dpkg-buildpackage -F .. there's debuild -S -sa and then sudo pbuilder build <package_version.dsc>
[18:20] <infinity> pdtpatr1ck: Any of those except for "fakeroot dpkg-buildpackage".
[18:20] <slangasek> pdtpatr1ck: debuild is a better interface than dpkg-buildpackage for developer use cases; fakeroot never needs to be specified manually becuase it's a default; what infinity said; and use of debuild vs. pbuilder has more to do with your workflow than whether one is a "preferred method".
[18:21] <infinity> pdtpatr1ck: "dpkg-buildpackage -rfakeroot" will only use fakeroot during the bits where it needs to (and debuild, pbuilder, and sbuild will all call dpkg-buildpackage in that same manner)
[18:21] <slangasek> if you already have a dsc, you're not going to be running 'debuild -S -sa', so the last two are orthogonal
[18:21] <pdtpatr1ck> Great .. much appreciated guys
[18:22] <infinity> slangasek: Is it sad that even though I know debuild is easier and less typing, muscle memory dictates that I still type "dpkg-buildpackage -rfakeroot -uc -us -S" every time?
[18:22] <infinity> slangasek: Worse still, because -rfakeroot is the default now, and I still type it.
[18:23] <infinity> Silly fingers.
[18:26] <pitti> kirkland: no, I switched to full $HOME encryption a few cycles ago
[18:26] <pitti> kirkland: yeah, I think I saw it sometimes; seems to be some kind of race condition or mis-counting sessions
[18:35] <slangasek> infinity: you're losing valuable seconds of your life that way!  best to just let the autobuilders do it all for you
[18:41] <infinity> slangasek: *glare*

[18:44] <pitti> infinity: "bzr bd" !!!11!
[18:45]  * infinity packs up his toys and goes home.
[18:45]  * pitti is still a bit grumpy about debhelper claiming 'dh', a command that nobody ever types into a shell
[18:46] <infinity> I imagine you'll get over it.
[18:46] <infinity> Besides, I type it in shells.
[18:46] <infinity> dh --no-act can be handy.
[18:47] <pitti> still, it's so un-Huffman-y
[18:48] <pitti> infinity: but anyway, I think you already LARTed me for my collection of aliases :)
[18:48] <infinity> You were a math major turned programmer, weren't you?
[18:48] <pitti> no, just a lazy typer :)
[18:48] <infinity> And I may have.  It sounds like the sort of thing I'd make fun of.
[19:23] <smoser> hey all. i'm looking at trying to find a solution for bug 838968 .
[19:24] <smoser> i'm wondering if there is any way suitable for that a daemon could avoid polling to see if all of a list of network interfaces are up and have IPs assigned to them.
[19:24] <smoser> s/suitable for that/suitable for ubuntu boot where/
[19:25] <hallyn> smoser: wasn't SpamapS working on an event for that?
[19:26] <smoser> hallyn, you're funny.
[19:26] <smoser> its broken :)
[19:26] <smoser> and i want to fix it.
[19:26] <stgraber> too bad upstart can't react to netlink activity yet...
[19:27] <hallyn> don't suppose there is a udev uevent when an address is defined?
[19:28] <smoser> polling is probably *really* light, but it just seems dirty.
[19:30] <hallyn> stgraber: are you thinking NETDEV_CHANGENAME?
[19:30] <slangasek> smoser: I think it's a bug in dhclient and/or ifupdown
[19:31] <smoser> its by design in dhclient
[19:31] <slangasek> yeah, I think the design is wrong :)
[19:31] <stgraber> hallyn: yeah, didn't remember the name though :)
[19:31] <DoctorPepper> hi guys !!!
[19:32] <slangasek> smoser: is there a reason you think it's correct for dhclient to background itself before it's gotten a response from the DHCP server and applied it?
[19:33] <slangasek> I think this is a bad design that only exists to work around historic limitations, but maybe I'm missing something
[19:33] <stgraber> hallyn: there's also NETDEV_CHANGEADDR but that might be for the mac address but maybe NETDEV_CHANGE would work then (haven't played with these in a while, just had to google for them again :))
[19:33] <smoser> slangasek, i dont have a good reason.
[19:34] <slangasek> stgraber: ^^ perhaps you have an opinion there
[19:34] <smoser> but even if i did, it in that bug info, it seems like ifupdown is going on immediately as opposed to waiting 60 seconds.  although in attempts to reproduce that outside of boot, i can't see it.
[19:35] <slangasek> ifupdown is going on immediately because dhclient has backgrounded and ifupdown has no channel by which to detect that the interface isn't actually up
[19:35] <stgraber> smoser: any reason we don't simply put a script in /etc/dhcp/dhclient-exit-hooks.d ?
[19:35] <smoser> slangasek, when run after boot, it doesn't do it immediately, dhclient holds around until it gets an IP address.
[19:36] <slangasek> stgraber: because ifupdown and networkmanager already emit events when interfaces are "up", and we should fix *that* to work as intended instead of adding more layers
[19:36] <smoser> i have the luxury of working on a system where the driver is apparently bad and a dhcp request is taking like 45 seconds, so i know this :)
[19:36] <slangasek> stgraber: since ifupdown and network-manager still have to have them for the static interface case
[19:37] <smoser> slangasek i just assumed that the static interface case was more straight forward. is it not?
[19:37] <slangasek> smoser: I did see another bug report recently about *statically* configured interfaces getting the up event emitted before the driver was ready to tx/rx - maybe you have the same issue?
[19:37] <slangasek> smoser: er, from upstart's perspective static vs. dynamic is (and should be) the same model
[19:37] <smoser> stgraber, so, saying theres a hooks dir there, how would you tie that all together to ?
[19:38] <DoctorPepper> chrisccoulson: i need your  help  , i am trying to build  globalmenu-extension for installing on a non ubuntu distribution (archlinux) , but  when running autoconf  i get the following error : build/autoconf/acwinpaths.m4:44: error: defn: undefined macro: AC_OUTPUT_FILES when the build fails
[19:38] <smoser> slangasek right, i agree it should be the same.
[19:38] <stgraber> smoser: as slangasek said before, it's probably not a good idea to add yet another hook, but otherwise a workaround would have been to change the ifupdown script not to send the event when doing dhcp and add a hook in dhclient to send the event when it gets an ip
[19:38] <chrisccoulson> DoctorPepper, you need autoconf2.13
[19:39] <chrisccoulson> i'm sure you already asked me that a while ago, and i gave the same answer ;)
[19:39] <smoser> stgraber, right... and then i' dhave to have another upstart job that ran on if-really-up, and determine if all interfaces were up in *that* and fire the event.
[19:41]  * stgraber starts liking NM for that ;) at least we have one piece of software starting everything and that knows the state of all NICs
[19:42] <stgraber> smoser: yeah, that'd get even more of a mess than what we currently have...
[19:42] <DoctorPepper> about 6 month ago but back then  i was impossible to build  it since i was using  fedora  the whole appmenu infrastructure  wasnt avalaible
[19:42] <smoser> yes.
[19:42] <smoser> but it would give me a solution
[19:42] <smoser> which i need
[19:42] <smoser> :)
[19:43] <DoctorPepper> chrisccoulson: i got another error : ./allmakefiles.sh: line 104: ./toolkit/toolkit-makefiles.sh: No such file or directory
[19:43] <DoctorPepper> what should ido ?
[19:44] <smoser> slangasek, how much would you hate me if i did something like that? if it was clearly marked as "the only consumer of 'is-really-up' events is 'static-networking-up.conf', DO NOT USE IT YOURSELF"
[19:45] <slangasek> smoser: a lot :P
[19:45] <slangasek> smoser: that's a lousy workaround - fix the real bug
[19:46] <smoser> do you really think "fix the real bug" is even an option for 11.10 ?
[19:46] <slangasek> ifupdown shouldn't say the interface is up until it's up; whatever is causing it to say it's up before it is is a bug
[19:46] <slangasek> yes
[19:46] <smoser> changing dhclient to not bacakground itself would be seemingly invasive at this point.
[19:46] <chrisccoulson> DoctorPepper, looking in the README file would be a good start
[19:46] <slangasek> I disagree.  We're not making dhclient not background itself, we'd only be changing *when* it backgrounds itself.
[19:47] <stgraber> smoser: is dhclient being called with -d?
[19:47] <stgraber> smoser: if so, that's your bug
[19:48] <smoser> stgraber, i dont thin it is. but i think you're reading the man page wrong.
[19:48] <smoser> -d just says "never background"
[19:48] <stgraber> wasn't the manpage but yes I read it wrong ;)
[19:48] <smoser> i did the same thing
[19:49] <DoctorPepper> chrisccoulson:  i worried about one thing   i see  two option  disabling both ogg and web  would this affect the ability  to play ogg and web video on the browse
[19:49] <chrisccoulson> DoctorPepper, no, they have no effect at all
[19:50] <chrisccoulson> the build system is copied straight from firefox, so those build options just stop you depending on them
[19:50] <smoser> SpamapS, ^ slangasek says "make it work right".
[19:50] <SpamapS> smoser: so is dhclient backgrounding itself too early?
[19:50] <chrisccoulson> DoctorPepper, in fact, the build system is basically from https://launchpad.net/mozilla-build-system ;)
[19:51] <DoctorPepper> ok thanks
[19:51] <smoser> SpamapS, so i think there are 2 issues.  1, by design dhclient is not what we'd like.
[19:51] <smoser> 2. i swear i'm seeing ifupdown emit the interface immediately, but i can't see how.
[19:53] <slangasek> where is it said that this is by design in dhclient, btw?
[19:54] <slangasek> in fact, dhclient has a '-nw' option
[19:54] <slangasek> which we should avoid using :)
[19:55] <slangasek> (and we're not, in either ifupdown or NM - so dhclient daemonizing before IP is acquired is certainly a bug)
[19:55] <SpamapS> slangasek: it daemonizes after 60 seconds I believe
[19:55] <smoser> yeah... so maybe i'm having old daemons in my head.
[19:56] <smoser> i know it used to do this "no ip found for XX seconds backgrounding"
[19:56] <slangasek> right; and that's not a sensible thing to do with a modern init system
[19:56] <smoser> and actually, i can verify that right now on a system not connected . if i 'sudo ifup eth1' then it *does* return and dhclient is in daemon mode afterwards
[19:57] <stgraber> are we sure it's dhclient daemonizing when it shouldn't and not ifupdown starting it in the background to start with (I see quite a few fork() in ifupdown's code)?
[19:57] <slangasek> not sure at all
[19:58] <smoser> i'm not usre.
[19:58] <smoser> then *it* would have to be performing the "wait for a little while".  i can test it easily on my unconnected eth1
[19:59] <slangasek> you can run dhclient directly with the same options as ifupdown does, check the behavior?
[19:59] <smoser> yeah. thats what i was going to do.
[20:00] <slangasek> what's the full dhclient commandline it uses, btw?  I only have ifupdown-managed dhcp on Debian machines handy, not Ubunut
[20:00] <stgraber> smoser: can you try: killall dhclient3 ; ifconfig eth0 0.0.0.0 ; dhclient3 eth0; ifconfig eth0?
[20:00] <stgraber> smoser: I just did it a few times here and I always get an IP when dhclient returns
[20:01] <SpamapS> I only see two fork's in ifupdown's code
[20:01] <slangasek> stgraber: yes, but in your case you *are* getting an IP so that's a racy test :)
[20:01] <DoctorPepper> is anyone from the appmenu team here ?
[20:01] <slangasek> more interesting is to see what happens when you aren't
[20:01] <smoser> slangasek, ok. i verified.
[20:02] <smoser> time sudo dhclient3 -e IF_METRIC=100 -pf /var/run/dhclient.eth1.pid -lf /var/lib/dhcp3/dhclient.eth1.leases eth1
[20:02] <smoser> that comes back in 1 minute and 0 seconds and change
[20:02]  * slangasek nods
[20:02] <smoser> and syslog shows
[20:02] <smoser> Sep  1 16:01:35 mabolo dhclient: No DHCPOFFERS received.
[20:02] <smoser> Sep  1 16:01:35 mabolo dhclient: No working leases in persistent database - sleeping.
[20:03] <smoser> and dhclient on eth1 still running per 'ps'
[20:03] <slangasek> so there's a built-in timeout of 60 for dhclient
[20:03] <smoser> right.
[20:03] <slangasek> I wonder if we can set that to -1
[20:04] <slangasek> or if the timeout is fine and we just need to fix the behavior *when* it times out
[20:04] <SpamapS> "To run force dhclient to always run as a foreground process, the  -d flag  should be specified. "
[20:04] <slangasek> we don't want it to always run as a foreground process
[20:04]  * SpamapS notices a bug in the man page. :)
[20:05] <SpamapS> -1 for a timeout would mean what though?
[20:05] <DoctorPepper> can anyone tell me why   installation of ubuntu on lvm encrypted partitions dont boot ?
[20:06] <smoser> SpamapS, no.
[20:06] <slangasek> SpamapS: that it would wait forever for a server instead of the current behavior, which is that it waits for 60 seconds and then *backgrounds anyway* as if it had succeeded
[20:06] <smoser> slangasek is wanting it to background when and only when it gets a connection.
[20:06] <SpamapS>        The -1 flag will cause dhclient to try once to get a lease.  If it fails, dhclient  exits  with  exit  code
[20:06] <SpamapS>        two.  In  DHCPv6  the -1 flag sets the max duration of the initial exchange to timeout (from dhclient.conf,
[20:06] <SpamapS>        default sixty seconds).
[20:07] <SpamapS> Sounds like thats what you want.
[20:07] <slangasek> right - devil's in the details.  What does "try once" mean here?
[20:07] <slangasek> does it mean it will never try to renew?  that it will only send out one request packet?
[20:07] <SpamapS> DoctorPepper: this is for discussion of development of Ubuntu. You may want to try #ubuntu if you're talking about a stable release, or #ubuntu+1 if you're trying this on oneiric.
[20:09] <DoctorPepper> SpamapS: actually  i tried it  on both 10.04 , 11.04 and oneric  always the same results  failure to boot
[20:10] <hrw> apparmor messages should rather not appear in dmesg - right?
[20:10] <stgraber> -1 seems to do what we want. It tries until it reaches the timeout, when it does it exits with exit 1. If it gets an IP before the timeout, it'll go in the background and renew it as usual
[20:10] <kirkland> jml: fixed!
[20:10] <kirkland> jml: package pushed to ppa:ecryptfs/ppa
[20:10] <kirkland> jml: but i've reproduced the problem and tested the solution here locally
[20:10] <slangasek> SpamapS, stgraber: my testing concurs, -1 does seem to DTRT at least for the cases of reliable and non-existent dhcp servers.  I don't know about an intermittent one, though
[20:11] <kirkland> jml: i'm confident enough that I'm just going to push
[20:11] <slangasek> stgraber: did you test to make sure it will retransmit the requests?
[20:11] <smoser> we may want to bump the timeout on it too.
[20:11] <slangasek> hrw: apparmor is a kernel lsm, so it will log in dmesg
[20:12] <SpamapS> it seems to just skip the daemonization step
[20:12] <smoser> 60 seconds is reasonable, but if its not blocking, then it might as well be longer.
[20:12] <stgraber> slangasek: what I tested is the behaviour with link and no DHCP (waited a minute and died), with link and dhcp (got an IP went in the background) and with an existing lease (renewed it)
[20:12] <stgraber> smoser: I wouldn't change that timeout as it's likely going to affect NetworkManager too
[20:12] <hrw> slangasek: thx
[20:12] <smoser> stgraber, so can you test no link, start it, plug in link, what happens.
[20:12]  * hrw -> sleep
[20:12] <slangasek> smoser: well, would anything else in the boot sequence wind up blocking indefinitely if we raised the timeout?
[20:13] <slangasek> and is that a good or bad thing?
[20:13] <smoser> plug in link after ~ 30 seconds or so, to make sure that dhclient is re-transmitting its requests if the first dont go through.
[20:13] <slangasek> SpamapS: "seems"?  it still daemonizes here on successful lease, which is what we want
[20:13] <SpamapS> slangasek: with the failsafe boot, boot happens 30 seconds after 'filesystem' no matter what.
[20:13] <stgraber> can we set the timeout on the command line so we don't have to change it for everyone?
[20:14] <stgraber> smoser: it's an LXC container, the "no link" case is a bit of a problem to implement ;)
[20:14] <slangasek> stgraber: how about the "DHCP server not running yet, gets started in the middle" case?
[20:14] <SpamapS> slangasek: right, on receiving a lease it always daemonizes. "onetry" mode just skips the daemonization after reaching the initial timeout.
[20:14] <slangasek> SpamapS: right - 'swhat we want
[20:14] <stgraber> slangasek: that I can try
[20:15] <slangasek> so, have we analyzed this to death now? :)
[20:15] <stgraber> slangasek: works fine
[20:15] <SpamapS> it only takes 4 people to analyze it
[20:15] <SpamapS> :)
[20:16] <smoser> but this is good.
[20:17] <smoser> SpamapS, and i think i ssee the flaw in our /etc/network/if-up.d/upstart logic.
[20:18] <smoser> we are reading /var/run/network/ifstate for "is interface up".  (ie, just checking that the interface is in there).  I think that ifupdown is pupulating that immediately.
[20:18] <smoser> populating it immediately even.
[20:19] <SpamapS> That would be.. unfortunate, but makes sense.
[20:19] <slangasek> heh, that's true
[20:19] <SpamapS> So instead of trusting that, being in there means its "up" .. we have to additionally check that it has the configuration intended?
[20:19] <SpamapS> god I hate ifupdown's code
[20:19] <smoser> SpamapS, well not really. we can just make our own
[20:20] <smoser> that only is populated on successful bringup
[20:20] <stgraber> SpamapS: bah, it's just a big manpage that happens to have C in it (and some other things) ;)
[20:20] <smoser> hm... but races
[20:20] <SpamapS> stgraber: you forgot the bit that turns "defn" to C
[20:20] <SpamapS> and the bit that turns nowebm to "defn"
[20:21] <smoser> can that perl script compile this conversation into working code ?
[20:21] <stgraber> ;)
[20:22] <SpamapS> so  yeah, looking at the code, I think its adding it to say "I've got this don't try to do it"
[20:23] <SpamapS> not to sya "this is up"
[20:23] <SpamapS> so we can simply replace that with our own state managed by if-up.d/upstart ...
[20:23] <smoser> thats what i said.
[20:23] <SpamapS> smoser: setting bootytraps?
[20:23] <smoser> but we have to avoid racy-ness.
[20:24] <SpamapS> smoser: I'm prepared to simply ignore /var/run/network/ifstate entirely
[20:24] <smoser> i'm prepared to do that too
[20:24] <smoser> but its not as simple
[20:24] <SpamapS> smoser: what I need is "what should be up" (ifquery gives us that) and then a canonical source of what *is* up.. initctl list gives us that.
[20:24] <smoser> as you can't just "echo $IFACE" >> /var/run/my-really-up-state
[20:25] <slangasek> initctl list seems like a good choice
[20:25] <slangasek> alternatively, you could use 'pidof ifup' + /var/run/network/ifstate
[20:25] <SpamapS> the race isn't as important since this is forward only..
[20:25] <SpamapS> if something comes up, then goes down again, we don't really care.. thats not something we can solve.
[20:25] <SpamapS> what we want is the moment at which they were all "up"
[20:25] <smoser> i dont follow that.
[20:25] <slangasek> if ifup is still running for an interface you care about, and it's not the *current* interface, then you're not ready yet... oh, except those can race each other, so ignore this.
[20:26] <slangasek> initctl list is the best
[20:26] <SpamapS> right, because start/running is only achieved after ifup --allow auto $INTERFACE returns
[20:26] <slangasek> well, no
[20:27] <slangasek> it's achieved *within the upstart hook* :)
[20:27] <smoser> network-interface (eth1) start/running
[20:27] <slangasek> oh
[20:27] <slangasek> right
[20:27] <slangasek> thinking of the wrong event, sorry
[20:27] <smoser> that is from my system, where eth1 is unplugged
[20:27] <SpamapS> initctl list | grep '^network-interface .* start/running$'
[20:27] <SpamapS> smoser: thats because ifup didn't error out
[20:27] <SpamapS> it should have
[20:28] <SpamapS> because we're calling dhclient wrong, it didn't
[20:28] <smoser> right.
[20:28] <smoser> ok.
[20:28] <slangasek> you could have an instantiated job that does nothing but catch the net-device-up event
[20:28] <SpamapS> one issue, do we want it trying ifup.. forever?
[20:28] <slangasek> and then enumerate *those* jobs with initctl list
[20:29] <smoser> why another layer of indirection, slangasek ?
[20:29] <SpamapS> slangasek: thats sort of what the if-up.d/upstart script is already.. so it wouldn't be too far fetched to simply move all of this into that job.
[20:30] <slangasek> smoser: because there's no other way currently that lets you count interfaces as "up" that's not racy
[20:30] <smoser> i think its ok.
[20:30] <slangasek> SpamapS: you couldn't move *all* of it into that job... you couldn't move the part that emits the event you're trying to catch ;)
[20:31] <smoser> in the if-up.d of all of them you just say "are all auto interfaces up" (other than self) and emit if that is the case.
[20:31] <slangasek> you have no way to determine that's the case
[20:31] <slangasek> that's the bit that needs solved
[20:32] <slangasek> /var/run/network/interfaces is an imperfect proxy
[20:32] <slangasek> it tells you "ifup has been called", not "the interface is up"
[20:32] <smoser> oh, and initclt list was not sufficient ?
[20:32] <smoser> fyi: network-interface (eth3) start/running
[20:32] <slangasek> yes, it's not sufficient
[20:32] <smoser> eth3 is not in interfaces at all
[20:33] <slangasek> consider two interfaces, eth0 and eth1
[20:33] <slangasek> both are detected in parallel, so ifup is launched for each
[20:34] <slangasek> dhcp runs in parallel on each, finishes within a split second of each other
[20:34] <slangasek> so /etc/network/if-up.d/upstart is called for each interface; emits the 'net-device-up' event, which doesn't directly start any uniquely identifiable jobs that will show up in 'initctl list'
[20:35] <slangasek> at this point, you'll see this output in initctl list:
[20:35] <slangasek> network-interface (eth0) start/starting
[20:35] <slangasek> network-interface (eth1) start/starting
[20:35] <slangasek> you can ignore your *own* interface, but what about the other?
[20:36] <slangasek> if you say "it's starting, that's close enough", you risk emitting the event before the interface is actually up
[20:36] <slangasek> if you say "it's starting, we'll do nothing and let the *other* script handle it when it starts", you risk both scripts doing the same thing and nobody emitting the event
[20:37] <SpamapS> slangasek: indeed, race found.. so we should sync these up...
[20:38] <SpamapS> wait-for-state to the rescue?
[20:38] <Laney> cody-somerville: can you vote on chase and brian please?
[20:38] <SpamapS> hrm no.
[20:38] <slangasek> right, so one way to do that is to instantiate a job for each interface, at a point in this script before it does the initctl check
[20:39] <slangasek> has to be done synchronously, of course, not using -n
[20:39] <slangasek> but the last of the interfaces to do so is guaranteed to see all interfaces as up
[20:40] <slangasek> (...then you just have to deal gracefully with our event being emitted multiple times, which you already have to do)
[20:41] <jml> kirkland: testing now
[20:41] <smoser> slangasek, we were avoiding multiple times with mkdir /var/run/network/static-network-up-emitted . but maybe im' missing something.
[20:41] <kirkland> jml: thanks!
[20:42] <kirkland> jml: man this bug has a bunch of dupes
[20:42] <slangasek> smoser: ahh yes
[20:42] <SpamapS> slangasek: hm.. I'm trying to remember if emitting a sync event returns when the goal is changed to start, or when the jobs have entered start/running
[20:42] <slangasek> smoser: a perfectly cromulent semaphore :)
[20:42] <smoser> exactly
[20:43] <SpamapS> if the former, then we still have the race.
[20:44] <SpamapS> Well except now we don't care about start/running .. just start/
[20:44] <SpamapS> so I think that will work
[20:44] <slangasek> true
[20:44] <SpamapS> since we're really just using upstart as a synchronous place holder
[20:45] <jml> great. I have to get a libreoffice update at the same time :)
[20:45] <SpamapS> which makes me wonder if we shouldn't just use /var/run/network dirs for simplicity sake...
[20:45] <smoser> SpamapS, i couldn't avoid a race there either.
[20:45] <slangasek> SpamapS: right, and does that seem reasonable or should we just do it all in /run :)
[20:45] <SpamapS> jml: if we never updated openoffice, I would never have an excuse to check facebook. ;)
[20:45] <slangasek> rather than making init do it for us
[20:45] <smoser> how would you avoid the race?
[20:46] <slangasek> smoser: by having this script write to /run/network, instead of starting an upstart job
[20:46] <jml> SpamapS: heh.
[20:46] <smoser> when you ccheck "are all other interfaces done" you risk a race of 2 jobs saying "nope, the other isnt done yet"
[20:46] <jml> SpamapS: sadly, I get plenty of chances.
[20:46] <SpamapS> smoser: create the dir, /var/run/network/ifup.$INTERFACE , then ls /var/run/network/ifup.* .. compare with /etc/network/interfaces list..
[20:47] <slangasek> SpamapS: why a dir instead of a file? in this case no collisions
[20:47] <SpamapS> smoser: as long as you only check after you've updated yours, you are ok
[20:47] <SpamapS> Whoa
[20:47] <SpamapS> earthquake
[20:47] <slangasek> also, /run/network please, /var/run is a compat symlink :)
[20:47] <slangasek> how bad?
[20:48] <barry> seriously?  what's with all this seismic activity?
[20:48] <smoser> SpamapS, i think there is a race still.
[20:48] <slangasek> he's in California, he's statistically ignorable :P
[20:48] <slangasek> smoser: there isn't, because you're doing a filesystem-level test and set :)
[20:48] <SpamapS> not much
[20:48] <smoser> eth0 touch /var/run/network/ifup.eth0; eth1 touch /var/run/network/ifup.eth1
[20:49] <SpamapS> Los Angeles area.. sometimes I think I feel them and its just a big truck.. old building..
[20:49] <smoser> wait...
[20:49] <slangasek> smoser: each instance must create its own flag file *before* checking the list.  Therefore, whichever one creates its file *last* is guaranteed to see all of them
[20:49] <barry> slangasek: :)
[20:49] <smoser> eyah..i guess.
[20:49] <smoser> k.
[20:49] <smoser> much easier.
[20:49] <slangasek> as long as we're using a POSIX filesystem, that is ;)
[20:50] <smoser> as long as we dont remove them.
[20:50] <slangasek> which we shouldn't
[20:50] <smoser> i think we're kind of screwed if /run is not POSIX
[20:50] <SpamapS> slangasek: we decided to put off non posix support for /run until after systemd migration... 15.10 maybe? ;)
[20:51] <SpamapS> http://earthquake.usgs.gov/earthquakes/recenteqscanv/FaultMaps/118-34.html
[20:51] <slangasek> just making sure your code isn't portable to Win32 ;)
[20:51] <SpamapS> 4.1 in the valley
[20:51] <smoser> SpamapS, ok
[20:51] <slangasek> s/your code/you know your code/
[20:51] <smoser> so i'm still going to make the /var/run/network/static-network-up-emitted dir.
[20:51]  * slangasek nods
[20:51] <smoser> or touch that. or something. so that when i come up i can say "has that event happened?"
[20:52] <slangasek> the mkdir is best because you only want it to succeed once
[20:54] <kirkland> jml: what's the word?
[20:54] <jml> kirkland: ssh test failed. trying logout of desktop session.
[20:54] <smoser> SpamapS, i have to run. i'll put together a merge proposal later.
[20:55] <Daviey> smoser: don't break it.
[20:59] <SpamapS> smoser: ok THANKS!
[20:59] <kirkland> jml: hmm, i don't get it ... i reproduced your setup and the bug here exactly
[20:59] <kirkland> jml: and this is fixing it for me
[21:02] <kirkland> slangasek: howdy
[21:02] <slangasek> kirkland: hiyo
[21:02] <kirkland> slangasek: okay, a grep shows: http://paste.ubuntu.com/680126/
[21:02] <kirkland> slangasek: so all of these can/should be dropped to a LOG_DEBUG?
[21:03] <slangasek> kirkland: my position is that at least the first 2 should not be logged at all unless the module is being passed some debugging option
[21:04] <slangasek> because "pam_sm_authenticate: Called" is bloody useless output
[21:04] <slangasek> unless you're debugging the module
[21:04] <kirkland> slangasek: agreed, okay
[21:04] <slangasek> kirkland: also, please put the module name *in* the log messages :)
[21:04] <kirkland> slangasek: agreed
[21:05] <jml> kirkland: v91?
[21:05] <kirkland> jml: hmm
[21:05] <slangasek> kirkland: we actually have a pam helper function in current Linux-PAM that you could use, fwiw (pam_syslog())
[21:06] <kirkland> jml: i think i might have push a bad upload to the ppa
[21:06] <kirkland> jml: ie, without the fix
[21:06] <jml> kirkland: ah, ok.
[21:06] <jml> kirkland: I've got to head now -- laptop and mental batteries are fading
[21:06] <jml> kirkland: but I can test on the morrow if you upload to your ppa again.
[21:06] <kirkland> jml: k
[21:21] <Apteryx> Hey, I've got a really trivial patch (one mirror line to add to /usr/share/python-apt/templates/Ubuntu.mirrors
[21:23] <dupondje> Somebody pushed some upgrades :D
[21:23] <Apteryx> I made a patch, showing the added line, see: http://pastebin.com/EFF2mvhv
[21:24] <Apteryx> What's the process to get this line incorpored efficiently in Ubuntu 11.04 and later?
[21:25] <Apteryx> I could report a bug against python-apt, but it seems almost overkill.
[21:28] <kirkland> jml: ecryptfs-utils_92-0ubuntu1~ppa1_source.changes uploaded to ppa:ecryptfs/ppa
[21:30] <stgraber> Apteryx: this is a generated file, so shouldn't be patched
[21:31] <slangasek> Apteryx: as stgraber says - the correct procedure is to get your mirror registered with launchpad
[21:31] <slangasek> see https://launchpad.net/ubuntu/+archivemirrors
[21:31] <slangasek> (and the 'register a new mirror' button)
[21:32] <slangasek> if it's already registered and what's needed is to refresh the mirror list in the package, please do file a bug against python-apt
[21:33] <stgraber> Apteryx, slangasek: http://paste.ubuntu.com/680146/ is the diff from what we currently have in python-apt and what's in Launchpad
[21:35] <stgraber> Apteryx: what version of Ubuntu was that patched written for? I see the uqam mirror at the top of LOC:CA in the current package
[21:35] <stgraber> Apteryx: http://paste.ubuntu.com/680147/ is what we have in Oneiric
[21:35] <sladen> skaet: are we unfrozen now post beta1 ?
[21:35] <slangasek> sladen: we are now in feature freeze again instead of beta freeze, yes
[21:36] <skaet> sladen.  yup
[21:37] <skaet> thanks slangasek. :)
[21:39] <slangasek> sure :)
[21:39] <sladen> ta :-)
[22:15] <slangasek> tedg: hi
[22:16] <tedg> slangasek, Unfortunately I need to run... I was just logging out.
[22:16] <slangasek> tedg: ok
[22:16] <tedg> I'll assume you'll implement the highlander directive and we're all happy :-)
[22:16] <slangasek> :)
[22:16] <slangasek> well, wanted to talk through it with you
[22:17] <slangasek> the reason apt has such a problem with it is because the breaks is so deep in the dependency tree
[22:17] <slangasek> if it were done against the indicators themselves, which seems perfectly appropriate, apt would sort it out
[22:17] <slangasek> but I realize there are a lot more of those, so it's hard to be comprehensive
[22:17] <tedg> slangasek, Hmm, okay.  I have no specific concern there, but we just thought if we did it lower it would be more complete.
[22:17] <tedg> Which I guess is kinda the problem :-)
[22:18] <slangasek> yeah :)
[22:18] <tedg> slangasek, So, in a nutshell, I'm totally open to ideas, but I think we need to have something to protect for that situation in the package.
[22:18] <slangasek> agreed
[22:19] <slangasek> I'll see what I can come up with
[22:19] <tedg> Cool, thanks.  I'll run around in 100 degree heat with 5 year olds ;-)
[22:23] <SpamapS> err.. can somebody explain this one for me...
[22:23] <SpamapS> http://paste.ubuntu.com/680171/
[22:24] <SpamapS> I have python3 3.2-3 installed, but it says the >= 3.2 < 3.3 dependency is not satisfiable..
[22:30] <barry> SpamapS: i've seen that before too, and i don't understand it either
[22:30] <barry> tumbleweed: ping
[22:30] <SpamapS> maybe its to signal that python3-profiler isn't a separate package anymore.. which is cool
[22:31] <barry> SpamapS: i find apt's error messages to be about as cryptic as you can get ;)
[22:41] <jelmer> Sweetshark, hi
[22:42] <jelmer> Sweetshark, just noticed you registered a libreoffice import - unfortunately we don't support git imports over http using the smart server protocol yet, I've fixed the URL
[22:42] <jelmer> Sweetshark, There was already an import at lp:~vcs-imports/libreoffice/trunk; that failed to scan for some reason
[22:43] <barry> @pilot out
[23:00] <TheMuso> @pilot in
[23:46] <pdtpatrick_> Which team would I ask this question to? .. why does the shell built-ins navigate better than for instance /usr/bin/less? ... here's an example.
[23:46] <pdtpatrick_> http://pastebin.com/BLXiiV4M
[23:47] <pdtpatrick_> notice how if u use cd it would add the /
[23:47] <pdtpatrick_> when u tab to autocomplete
[23:47] <pdtpatrick_> when u use less .. if u tab - it just creates a space instead of realizing you're navigating a directory