[00:00] ah, no, it's asynchronous. [00:02] 7 minutes with still no logtail? Has it died again? [00:02] Even on non-virt builders... [00:05] elmo: ^^ [00:15] wgrant, not sure if it helps, but my packages usually takes about 2 minutes to build and it's over 20 now [00:15] tgm4883: Yep, it seems to have died again. [00:16] Probably for the same reason. [00:16] But the code seems to be written such that it *won't* block if the resume command hangs. [01:19] FFS [01:19] fixed [01:20] elmo: Same issue? [01:21] yeah, I've hard-killed the problematic buildd [01:21] * wgrant notices shipova gone. [01:21] Right. [01:21] Thanks. [01:24] Things are still looking decidedly stuck. [01:25] (and it shouldn't have even got to trying to resume things yet) [01:27] Aha. [01:27] yeah, the buildd-manager process was FUBAR; I've restarted it [01:27] and it's now doing something [01:28] I think I might have had some replication lag, too. [01:29] OK, buildds full... now let's see if it hangs again. [01:32] Are you repeatedly bouncing it? [01:33] no? [01:33] Hm. [01:33] I saw a build restart three times. [01:34] It lives! [01:34] are you sure it wasn't the same build for different suites? [01:34] I am. [01:34] Anyway, all working now. [01:35] there's a lot of manualdepwait, maybe it throws them back a couple of times *shrug* === cprov-afk is now known as cprov [02:13] elmo: thanks [02:13] elmo: the resume trigger can block, thanks for reporting the bug. === OldSchool is now known as vorian [04:06] When a mailing list is deactivated, is the mail archive still viewable? [06:26] 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] Interestingly, the LPIA build succeeded [06:26] Failure log is here: http://launchpadlibrarian.net/29532700/buildlog_ubuntu-jaunty-i386.smartcardauth_1.0-0ubuntu1_FAILEDTOBUILD.txt.gz [06:31] well, certainly builds in ppas cannot contact the internet [06:40] 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] No. [06:41] You have to fix the package. [06:41] Or not depend on it. [06:41] Great [06:41] At the point at which that build failed, the package being built is not yet in power. [06:41] Odd that it succeeded on lpia, though. Do you have a log for that? [06:42] 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] Still odd, and I don't know if it points to an inn2 package problem or a builder configuration problem [06:44] kb9vqf: Retry the builds. [06:44] Actually, maybe not so useful if it failed on both. [06:45] 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] That is, with a "fix" not to start the inn2 server under the PPA environment [06:46] Does it work in the primary archive? [06:47] What do you mean by primary archive? [06:47] The official Ubuntu archive. [06:48] I'm sorry, but I don't understand what you are asking. [06:48] I never uploaded to the official archive [06:49] Does the package build-depend on inn2 in the official Ubuntu archive, and if so does it build? [06:49] This is a package I wrote, so it is not in the official archives [06:49] Aha. [06:49] :) [06:52] wgrant: Retrying the LPIA build caused it to work?!?! [06:52] Maybe there was a temporary network failure or something [06:52] Possibly. [06:52] Or you hit a bad builder. [06:52] i386 still failed though [06:52] there may be a few bad builders if that was the case [06:53] retrying i386 again... [06:53] Thanks for the help! [06:53] np [06:53] * kb9vqf is glad he doesn't have to pull his hair out redoing the inn2 package [06:54] It's building on aluminium again - it was a few minutes ago, so it might fail again. [06:55] Yeah, I noticed that. Can you lock it to another machine? [06:55] Otherwise, I'll just keep trying...maybe tomorrow morning I'll get a different machine [06:56] The way I might do it is wait until aluminium is taken by something else, then retry. [06:56] and......BOOM.....innconfval: hostname does not resolve or domain not set in inn.conf [06:56] That's a good idea [06:56] Might have to wait for a while though..." 0 builds waiting in queue " [06:56] on i386 === sunoano is now known as Guest47510 [07:35] wgrant: Yup, that was it...for i386, sandpaperfig and aluminum are broken, while iridium is OK. [07:35] In case someone wanted to fix them ;-) [08:35] hi all [09:15] kb9vqf: just curious: why do need inn2 (a news server) during building of a package which has something to do with smartcards? [10:03] 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. === yofel_ is now known as yofel === NCommand` is now known as NCommander [10:06] hmm seems like I managed to figure it out [11:50] hi [13:35] wgrant: morning [13:35] wgrant: re. 'PPA download stats' we sort of have a plan [13:36] wgrant: we intend to parse the logs of the apache serving ppa.l.n and increment the LFA-based hits. [13:37] wgrant: I haven't done any prototype yet, but this is the path we want to go. [13:43] cprov: But the LFA will only get you the BPR, not the archive, won't it? [13:44] wgrant: BPR or SPR files, then we can group then as needed. [13:44] wgrant: I'm not sure if we want to count hits on the repo indexes. [13:45] cprov: You don't care about index hits, no. [13:45] wgrant: is 'you' == 'us' ? [13:46] cprov: I think so. [13:46] Index hits aren't really useful. [13:46] wgrant: righto [13:51] Index hits can serve a purpose - they can suggest at numbers of people keeping the PPA in theirs sources.list long-term [13:52] Also, what would be really neat would be to categorize all the hits by user-agent [13:53] 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] i can't see a reason for NOT wanting to display that information to ppa owners? [14:12] I think it's not displayed simply because it doesn't exist [15:39] 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] maxb: that's why we will probably start with pool/ files then later workout how we can sanely store indexes hits. [15:41] maxb: you have a nice point about inferring the clients series using the apt version on the http-agent === cprov is now known as cprov-afk [16:59] hey if I click 'request another review' on a merge proposal, will it incorporate everything changed since the first review? [17:00] SpamapS: I would assume so. [17:01] me too but I don't want to annoy the rest of the dev team with a duplicate merge proposal. ;) [17:01] :P [17:02] ah help.launchpad.net .. maybe that knows for sure.. [17:04] Probably [17:05] 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] hm it doesn't mention that functionality [17:09] ah the answer is, no, it does not [17:10] it simply allows you to ask somebody else to review the merge proposal [17:15] SpamapS, you can do safe tests on https://staging.launchpad.net [17:18] 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] Works well enough...I just need something to authenticate usernames and passwords [17:19] kb9vqf: and btw: your package doesn't respect the FHS (creates a new dir below /) and also install files into /usr/local [17:19] Yeah, I know. It's a prototype [17:22] ahh what I was looking for was 'resubmit' [17:30] 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] I may end up rewriting the two main scripts in C...I just don't have the time ATM [17:39] 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] geser: Or am I just forced to rewrite this with the backend API in C? [17:44] 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] I don't know if command subsitution is visible in ps aux or not [17:46] 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] geser: I never really thought about that...I guess I should see if it will accept a file handle [17:47] I use root-secured files elsewhere in the script, so adapting it shouldn't be a problem [17:47] btw I'm fixing the FHS problems now... [17:49] and better use mktemp to create temp files with an unpredictible name (symlink attack) [17:50] good idea...I really needed some kind of security review on this package; thanks for taking a look at it! :-) [17:55] 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] 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] hello guys! [18:12] there is a problem with logging in launchpad [18:14] 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] so I just wanna know... what a hell is going on?! [18:17] helooooooo, is anybody there? [18:21] kb9vqf: that makes it less likely to be exploited but this a good example to use mktemp instead of a known tempfile [19:21] 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] kb9vqf: you might want mkstemp instead of mktemp? Anyway, try to get it reviewed by someone with actual secure programming experience [19:29] LarstiQ: Will do [19:29] LarstiQ: mkstemp is only available in C but not shell [19:30] * LarstiQ hadn't cought on that this was shell [19:30] 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] I think it is probably still susceptible to the ln attack [19:31] * kb9vqf goes to try it in a shell === sale_ is now known as sale [20:26] is there a way to mark tickets as "Fix Comitted" in a bzr comment? [20:31] synic: yes! [20:32] synic: bzr commit -m 'bla bla bla' --fixes=lp:12345 [20:32] synic: actually, i'm talking nonsense. that will link the branch to the bug, not mark fix commited [20:32] right [20:32] sorry, i should have read your question more carefully :-/ [20:32] i was just about to add that in my use of --fixes, it only links the branch [20:33] 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] ok [21:23] 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] -points === yofel_ is now known as yofel [21:50] savvas0: i don't know, perhaps ask a question on launchpad? [21:51] will do, dinner time :) [21:51] thanks [21:51] i wouldn't have thought any rosetta devs would be around now [21:58] morning [21:59] synic: we don't yet, but it is planned === yofel_ is now known as yofel [22:51] Hi, as I create the archive .change will be PPA? === Qway is now known as Sarah === Sarah is now known as Guest69490 === fidji is now known as Villon === Guest69490 is now known as Fiorella