[00:00] <wgrant> ah, no, it's asynchronous.
[00:02] <wgrant> 7 minutes with still no logtail? Has it died again?
[00:02] <wgrant> Even on non-virt builders...
[00:05] <wgrant> elmo: ^^
[00:15] <tgm4883> wgrant, not sure if it helps, but my packages usually takes about 2 minutes to build and it's over 20 now
[00:15] <wgrant> tgm4883: Yep, it seems to have died again.
[00:16] <wgrant> Probably for the same reason.
[00:16] <wgrant> But the code seems to be written such that it *won't* block if the resume command hangs.
[01:19] <elmo> FFS
[01:19] <elmo> fixed
[01:20] <wgrant> elmo: Same issue?
[01:21] <elmo> yeah, I've hard-killed the problematic buildd
[01:21]  * wgrant notices shipova gone.
[01:21] <wgrant> Right.
[01:21] <wgrant> Thanks.
[01:24] <wgrant> Things are still looking decidedly stuck.
[01:25] <wgrant> (and it shouldn't have even got to trying to resume things yet)
[01:27] <wgrant> Aha.
[01:27] <elmo> yeah, the buildd-manager process was FUBAR; I've restarted it
[01:27] <elmo> and it's now doing something
[01:28] <wgrant> I think I might have had some replication lag, too.
[01:29] <wgrant> OK, buildds full... now let's see if it hangs again.
[01:32] <wgrant> Are you repeatedly bouncing it?
[01:33] <elmo> no?
[01:33] <wgrant> Hm.
[01:33] <wgrant> I saw a build restart three times.
[01:34] <wgrant> It lives!
[01:34] <elmo> are you sure it wasn't the same build for different suites?
[01:34] <wgrant> I am.
[01:34] <wgrant> Anyway, all working now.
[01:35] <elmo> there's a lot of manualdepwait, maybe it throws them back a couple of times *shrug*
[02:13] <cprov> elmo: thanks
[02:13] <cprov> elmo: the resume trigger can block, thanks for reporting the bug.
[04:06] <nhandler> When a mailing list is deactivated, is the mail archive still viewable?
[06:26] <kb9vqf> When trying to build a package dependent on inn2, I get a "innconfval: hostname does not resolve or domain not set in inn.conf" failure from the PPA builder and the installation process halts.  Is there any way to get this fixed?
[06:26] <kb9vqf> Interestingly, the LPIA build succeeded
[06:26] <kb9vqf> Failure log is here: http://launchpadlibrarian.net/29532700/buildlog_ubuntu-jaunty-i386.smartcardauth_1.0-0ubuntu1_FAILEDTOBUILD.txt.gz
[06:31] <mwhudson> well, certainly builds in ppas cannot contact the internet
[06:40] <kb9vqf> Is there a way to bypass the error and force installation of the package so that building can continue?  I only need access to one of the binary files from that package, not the services or anything else.
[06:41] <wgrant> No.
[06:41] <wgrant> You have to fix the package.
[06:41] <wgrant> Or not depend on it.
[06:41] <kb9vqf> Great
[06:41] <wgrant> At the point at which that build failed, the package being built is not yet in power.
[06:41] <wgrant> Odd that it succeeded on lpia, though. Do you have a log for that?
[06:42] <kb9vqf> I had it backwards earlier...AMD64 worked, while i386 and LPIA failed.  Here's the log for AMD64: https://launchpad.net/~kde3-maintainers/+archive/ppa/+build/1133350/+files/buildlog_ubuntu-jaunty-amd64.smartcardauth_1.0-0ubuntu1_FULLYBUILT.txt.gz
[06:43] <kb9vqf> Still odd, and I don't know if it points to an inn2 package problem or a builder configuration problem
[06:44] <wgrant> kb9vqf: Retry the builds.
[06:44] <wgrant> Actually, maybe not so useful if it failed on both.
[06:45] <kb9vqf> I'll retry anyway, just in case.  It gets messy if I have to redo the inn2 package under a different name just to build my package properly...
[06:46] <kb9vqf> That is, with a "fix" not to start the inn2 server under the PPA environment
[06:46] <wgrant> Does it work in the primary archive?
[06:47] <kb9vqf> What do you mean by primary archive?
[06:47] <wgrant> The official Ubuntu archive.
[06:48] <kb9vqf> I'm sorry, but I don't understand what you are asking.
[06:48] <kb9vqf> I never uploaded to the official archive
[06:49] <wgrant> Does the package build-depend on inn2 in the official Ubuntu archive, and if so does it build?
[06:49] <kb9vqf> This is a package I wrote, so it is not in the official archives
[06:49] <wgrant> Aha.
[06:49] <kb9vqf> :)
[06:52] <kb9vqf> wgrant: Retrying the LPIA build caused it to work?!?!
[06:52] <kb9vqf> Maybe there was a temporary network failure or something
[06:52] <wgrant> Possibly.
[06:52] <wgrant> Or you hit a bad builder.
[06:52] <kb9vqf> i386 still failed though
[06:52] <kb9vqf> there may be a few bad builders if that was the case
[06:53] <kb9vqf> retrying i386 again...
[06:53] <kb9vqf> Thanks for the help!
[06:53] <wgrant> np
[06:53]  * kb9vqf is glad he doesn't have to pull his hair out redoing the inn2 package
[06:54] <wgrant> It's building on aluminium again - it was a few minutes ago, so it might fail again.
[06:55] <kb9vqf> Yeah, I noticed that.  Can you lock it to another machine?
[06:55] <kb9vqf> Otherwise, I'll just keep trying...maybe tomorrow morning I'll get a different machine
[06:56] <wgrant> The way I might do it is wait until aluminium is taken by something else, then retry.
[06:56] <kb9vqf> and......BOOM.....innconfval: hostname does not resolve or domain not set in inn.conf
[06:56] <kb9vqf> That's a good idea
[06:56] <kb9vqf> Might have to wait for a while though..." 0 builds waiting in queue "
[06:56] <kb9vqf> on i386
[07:35] <kb9vqf> wgrant: Yup, that was it...for i386, sandpaperfig and aluminum are broken, while iridium is OK.
[07:35] <kb9vqf> In case someone wanted to fix them ;-)
[08:35] <timut> hi all
[09:15] <geser> kb9vqf: just curious: why do need inn2 (a news server) during building of a package which has something to do with smartcards?
[10:03] <Halabund> A couple of years ago I created a launchpad account, and a bit later I wanted to delete it.  Then I was told that it is not possible to delete it.  The only option was "deactivating" it "in case I want to re-activate it later".  OK, so now I would like to re-activate it.  How can I do that?  Unfortunately I do not remember what email address I used to sign up, but I do remember the user name I used.
[10:06] <Halabund> hmm seems like I managed to figure it out
[11:50] <meoblast001> hi
[13:35] <cprov> wgrant: morning
[13:35] <cprov> wgrant: re. 'PPA download stats' we sort of have a plan
[13:36] <cprov> wgrant: we intend to parse the logs of the apache serving ppa.l.n and increment the LFA-based hits.
[13:37] <cprov> wgrant: I haven't done any prototype yet, but this is the path we want to go.
[13:43] <wgrant> cprov: But the LFA will only get you the BPR, not the archive, won't it?
[13:44] <cprov> wgrant: BPR or SPR files, then we can group then as needed.
[13:44] <cprov> wgrant: I'm not sure if we want to count hits on the repo indexes.
[13:45] <wgrant> cprov: You don't care about index hits, no.
[13:45] <cprov> wgrant: is 'you' == 'us' ?
[13:46] <wgrant> cprov: I think so.
[13:46] <wgrant> Index hits aren't really useful.
[13:46] <cprov> wgrant: righto
[13:51] <maxb> Index hits can serve a purpose - they can suggest at numbers of people keeping the PPA in theirs sources.list long-term
[13:52] <maxb> Also, what would be really neat would be to categorize all the hits by user-agent
[13:53] <maxb> the apt version number lets you infer a distroseries
[14:10]  * Daviey would really like some PPA stats.. It's useful to guage demand for a particular package, and generally ppa series
[14:10] <Daviey> i can't see a reason for NOT wanting to display that information to ppa owners?
[14:12] <maxb> I think it's not displayed simply because it doesn't exist
[15:39] <cprov> maxb: agreed, the only problem is that from the code PoV storing hits from pool/ files is very different (and much easier) than doing the same thing for repo indexes.
[15:40] <cprov> maxb: that's why we will probably start with pool/ files then later workout how we can sanely store indexes hits.
[15:41] <cprov> maxb: you have a nice point about inferring the clients series using the apt version on the http-agent
[16:59] <SpamapS> hey if I click 'request another review' on a merge proposal, will it incorporate everything changed since the first review?
[17:00] <AdamDV> SpamapS: I would assume so.
[17:01] <SpamapS> me too but I don't want to annoy the rest of the dev team with a duplicate merge proposal. ;)
[17:01] <AdamDV> :P
[17:02] <SpamapS> ah help.launchpad.net .. maybe that knows for sure..
[17:04] <AdamDV> Probably
[17:05] <kb9vqf> geser: I need the ckpasswd utility, of all the stupid things.  Sometime in the future I will probably rewrite it to build standalone, but I don't have the time right now.
[17:05] <SpamapS> hm it doesn't mention that functionality
[17:09] <SpamapS> ah the answer is, no, it does not
[17:10] <SpamapS> it simply allows you to ask somebody else to review the merge proposal
[17:15] <andrea-bs> SpamapS, you can do safe tests on https://staging.launchpad.net
[17:18] <geser> kb9vqf: I'm surprised that you can use chpasswd from inn2 which is made to be used by inn2/nnrpd for your case
[17:19] <kb9vqf> Works well enough...I just need something to authenticate usernames and passwords
[17:19] <geser> kb9vqf: and btw: your package doesn't respect the FHS (creates a new dir below /) and also install files into /usr/local
[17:19] <kb9vqf> Yeah, I know.  It's a prototype
[17:22] <SpamapS> ahh what I was looking for was 'resubmit'
[17:30] <geser> kb9vqf: I hope you also improve the security of those scripts. As passing passwords through parameters is a really bad idea. Using "ps aux" in the right moment and the password is leaked.
[17:31] <kb9vqf> I may end up rewriting the two main scripts in C...I just don't have the time ATM
[17:39] <kb9vqf> Is there a way to, for example, do this in BASH more securely: /opt/kde3/bin/kdmctl -g login :0 now $smartcard_username $smartcard_password
[17:39] <kb9vqf> geser: Or am I just forced to rewrite this with the backend API in C?
[17:44] <geser> kb9vqf: I'm not very knowlegdable in that area (better talk to someone who knows more about security than me). Perhaps even something like $(cat $smartcard_passwd_file) instead of $smartcard_passwd is good enough (assuming that file is securely created)
[17:45] <geser> I don't know if command subsitution is visible in ps aux or not
[17:46] <geser> but it would be IMHO a bad design if kdmctl expects the password in cleartext as parameter (instead of e.g. reading it from a file handle)
[17:47] <kb9vqf> geser: I never really thought about that...I guess I should see if it will accept a file handle
[17:47] <kb9vqf> I use root-secured files elsewhere in the script, so adapting it shouldn't be a problem
[17:47] <kb9vqf> btw I'm fixing the FHS problems now...
[17:49] <geser> and better use mktemp to create temp files with an unpredictible name (symlink attack)
[17:50] <kb9vqf> good idea...I really needed some kind of security review on this package; thanks for taking a look at it! :-)
[17:55] <geser> I don't know at which state of the boot the scripts are run. but if a user had a chance to create e.g. a symlink from /tmp/query to /etc/shadow and setupcard.sh is run as root say goodbye to your passwords
[17:58] <kb9vqf> That script is a setup script, so it is run in init 5 after graphical login; I'm not sure how to deal with that kind of attack
[18:11] <Oleg_Andreych> hello guys!
[18:12] <Oleg_Andreych> there is a problem with logging in launchpad
[18:14] <Oleg_Andreych> I've forgotten password, and when I've tried to recover it, i saw  a message, that there is no account with my email, but when i tried to regiser a new one whith my email it tolds me that account with my email already exists
[18:15] <Oleg_Andreych> so I just wanna know... what a hell is going on?!
[18:17] <Oleg_Andreych> helooooooo, is anybody there?
[18:21] <geser> kb9vqf: that makes it less likely to be exploited but this a good example to use mktemp instead of a known tempfile
[19:21] <kb9vqf> geser: sorry, went to lunch.  I will integrate mktemp into my program; hopefully that (and removing parameter passing) will secure it enough to be useful.  I'll let you know when I have the new package up....this is a feature I really want to see in Karmic
[19:22]  * kb9vqf really likes not having to type his 20+ character password over and over
[19:28] <LarstiQ> kb9vqf: you might want mkstemp instead of mktemp? Anyway, try to get it reviewed by someone with actual secure programming experience
[19:29] <kb9vqf> LarstiQ: Will do
[19:29] <geser> LarstiQ: mkstemp is only available in C but not shell
[19:30]  * LarstiQ hadn't cought on that this was shell
[19:30] <kb9vqf> I'm toying with the idea of creating my own, root-secured temporary directory for the temp files, but I don't know if this is a good idea
[19:31] <kb9vqf> I think it is probably still susceptible to the ln attack
[19:31]  * kb9vqf goes to try it in a shell
[20:26] <synic> is there a way to mark tickets as "Fix Comitted" in a bzr comment?
[20:31] <intellectronica> synic: yes!
[20:32] <intellectronica> synic: bzr commit -m 'bla bla bla' --fixes=lp:12345
[20:32] <intellectronica> synic: actually, i'm talking nonsense. that will link the branch to the bug, not mark fix commited
[20:32] <dtchen> right
[20:32] <intellectronica> sorry, i should have read your question more carefully :-/
[20:32] <dtchen> i was just about to add that in my use of --fixes, it only links the branch
[20:33] <intellectronica> dtchen, synic: but it should be easy to do something like that using the launchpad api (and a bzr plugin). a nice little project
[20:33] <synic> ok
[21:23] <savvas0> hi, about the new automatic translation merging  to bzr: why does the branch have to be owned by me only? can't I use a branch that points is owned by a group?
[21:23] <savvas0> -points
[21:50] <mwhudson> savvas0: i don't know, perhaps ask a question on launchpad?
[21:51] <savvas0> will do, dinner time :)
[21:51] <savvas0> thanks
[21:51] <mwhudson> i wouldn't have thought any rosetta devs would be around now
[21:58] <thumper> morning
[21:59] <thumper> synic: we don't yet, but it is planned
[22:51] <dm1tri> Hi, as I create the archive .change will be PPA?