[00:12] i wish to mount a LUKS volume *before* the root volume is mounted how would i go about this? [01:00] crypt-0: is the volume for / ? [01:00] if so cryptsetup has built in support for that [01:01] its all part of the initramfs scripts [01:05] lifeless, no trying to get two-factor auth working [01:05] then add a wiki when im done [01:06] well, you can mount a LUKS partition before / [01:06] how so? [01:06] but you can't mount other volumes before /, not sanely. [01:06] its built in, just make sure its listed appropriately in crypttab [01:07] s/mount a LUKS partition/unlock a LUKS partition/ [01:07] i was thinking of using a keyscript [01:07] that cats the keyfile [01:08] storing the password in a file defeats the purpose of the password in the first place [01:08] i know, the keydevice shall be a LUKS encrypted device [01:09] mounted before the root encrypted LVM [01:10] so the password will be to decrypt the keydevice, once decrypted the keyfile can be read and boot can continue [01:10] that is my goal [01:11] i was looking at a howto to do two factor with GPG, but GPG lacks PBKDF2 [01:11] uhm [01:11] and user passwords tend to be entropy weak [01:11] LUKS has keyfile support; put the keyfile on a USB device [01:11] thats something you have [01:12] I have to go, can chat later [01:12] right but i want the keyfile to be encrypted [01:12] and hwo are you going to mount that device? with a weak password? [01:13] *i* am not, but others may yes [01:13] the keyfile IS encrypted, with the password [01:14] huh? [01:14] pretty sure that the keyfile contains the real encyption key, which is itself encrypted using the password... possibly multiple times if you have multiple passwords [01:14] if i make a key using /dev/random that is plaintext just because i tell LUKS to use it doesn not mean it is encrypted. [01:15] I'm pretty sure that normally luks stores the key in a header it places on the disk... the key is randomly generated when you set up luks.... that key is then encrypted using your password and stored there too [01:15] when you put in your password, it is used to decrypt the real key [01:16] that's why you can change the password without wiping out everything on the disk... because the encryption key is not changed, it's just encrypted using the new password and stored on the disk [01:16] if read the LUKS spec, and did mention that [01:17] LUKS uses PBKDF2 , which changes your passhprase/keyfile > final decryption key [01:18] if Mallory has the password/keyfile she can use it. [01:18] right.... real key gets encrypted using your password(s) and stored on the disk... so even with access to the disk, you can't read the key without the password [01:21] yes that is if you consider the disk a factor. [01:21] 2/win 39 [01:21] huh? [01:22] if your disk is stolen and your password is too, the attacker has your data. [01:22] well of course [01:22] so don't write your password down on a sticky note pasted to the bottom of the laptop ;) [01:23] yes.... so if someone's laptop gets stolen with a weak password...it is gone [01:24] yes.... so if someone's laptop gets stolen with a weak password...but they are using two factor authentication with a USB stick its fine [01:24] encrypting it a second time does not help [01:24] keeping the key on a usb stick helps, provided that it is not also stollen [01:24] and if the attacker gets the laptop and the usb stick only the password is required [01:25] yep [01:25] that is what i want to set up. [01:25] then store the keyfile on a usb stick, that's pretty straight forward [01:25] ans wish to make a wiki so that others may use it [01:25] that's what lifeless ways saying [01:26] yes it is, but the keyfile requires no password [01:26] you can make it require one [01:26] you know the args? [01:26] for cryptsetup [01:27] the LUKS header is stored in plaintext [01:28] not offhand, but you should be able to put the key on a usb stick, AND have a password on it [01:28] yeah ive looked, but couldnt find a way [01:34] can anyone take a look at bug #534743 and see about applying the fix or at least bumping up the priority? this NEEDS to get fixed by release and I'm worried that if it doesn't get in for beta 2, it won't get in for release [01:34] Launchpad bug 534743 in dmraid "dmraid causes udev event feedback loop in Lucid" [Undecided,Confirmed] https://launchpad.net/bugs/534743 [01:41] lifeless, psusi the keyscript to be run http://pastebin.com/M2AhZDVR [01:43] doko__: around? just saw that you've taken bug #534459... to my findings, that's gcc miscompiling, but I haven't managed to produce a test-case more minimal than the entire patch package yet :( [01:43] Launchpad bug 534459 in gcc-4.4 "2.6-2 FTBFS on sparc (bus error in test cases)" [High,Confirmed] https://launchpad.net/bugs/534459 [01:44] sistpoty: uploaded, build with -fno-stack-protector on sparc. I assume it's kees's task now ;p [01:45] doko__: ah, thanks! [01:45] doko__: I've got a patch lying around that justs adds an assert for an out of bounds check (local only, the one at the bug report is wrong), which somehow makes the build pass as well, interested? [01:46] doko__: however I have retried to build fpc with a fixed patch package, didn't work (however that was a few gcc revisions ago already) [01:46] (didn't work due to a bus error later, iirc) [01:47] sistpoty: enotime, sorry. please ask kees. the fpc build on sparc is still running [01:47] doko__: kk, kees? [01:47] is there a way to enable SMART probing, an update disabled it? [02:38] kees: attached the patch to the bug report in question (however in reverted form :() [03:21] cjwatson, ping [03:39] cjwatson, updated OEMRescue wiki page with thoughts for you to read when you're back === syn-ack is now known as Guest79638 === Guest79638 is now known as syn-ack [05:25] apt-get remove plymouth wants to remove e2fsprogs ! [05:26] un214: Don't do that. [05:27] plymouth results in a brick [05:27] Removing it is just a longer path to tears. [05:27] File bugs and help get it fixed. [05:27] ? [05:28] plymouth isn't just a pretty splash screen. [05:28] I was better off when ubuntu didn't try to recognize my video card [05:28] It also does some important things with system I/O (I don't recall what) [05:28] So removing it is likely to have side effects eventually. [05:29] Considering you're using a development release and having problems with the most aggressive area of development in this development cycle, it's not stunning it's problematic for some. [05:29] Is it really a brick or just on a different vt? [05:30] last time I tried it, no display usable (bad driver) [05:30] How long ago was that? [05:30] about a month [05:31] usplash had the same problem [05:31] A lot has been done since then. [05:32] well we'll sure find out [05:36] well what do you know it actually came up this time [05:40] part of the problem is every so often I get a nouveau driver so bad I have to revert to using vgaconsole and VESA. I may end up having to do that anyway (potentially bad hardware). [05:40] ^bad nouveau driver [05:51] persia: hai [06:30] lifeless: Hey. [06:36] persia: hey [06:36] so [06:36] we're getting a test machine for lmirror in the dc [06:36] need some folk with the bandwidth & disk space to test mirroring from it [06:36] I'm happy to help with that. [06:36] \o/ [06:37] I've about 250-280ms latency, but can saturate the TCP/ACK window, and have plenty of available mirror space. [06:37] cool [06:37] whats your actual pipe size? [06:39] Technically, 1Gbps, but my fiber is a bit dirty, so I only get ~600Mbps, but my router is old and sad, so I only get ~40Mbps, but the DC is >250ms away, so I really only get ~25.6Mbps [06:39] hah lol [06:40] lmirror should saturate your tcp session [06:40] can you open your tcp buffers more ? [06:40] tcp profiling is likely to be a significant aspect of tuning it [06:40] Probably not usefully, because of my old, sad router. [06:41] isn't that endpoint determined ? [06:41] I'm happy to tweak endpoint stuff, but I'll lead guidance. [06:41] s/lead/need/ [06:41] sure [06:42] to start with, grab lmirror from bzr or a release tarball [06:42] Is it in the archives? [06:42] haha no [06:42] k [06:42] all the deps are, except testrepository which is only in debian atm [06:42] I did request a sync, but it hasn't been done. [06:43] OK. Source downloaded. [06:44] apt-get install bzr python-paste python-testresources python-testtools python-testscenarios [06:45] python -m testtools.run l_mirror.tests.test_suite [06:45] Hrm. Seems I need to fiddle, as some of this isn't in karmic :) [06:45] will then check that tests pass on your machine [06:45] oh heh :) [06:47] Failed to fetch http://ports.ubuntu.com/ubuntu-ports/pool/universe/p/python-openid/python-openid_2.2.4-1_all.deb 404 Not Found :( [06:48] wow, what dragged that in? [06:48] Dunno. [06:48] I had it on my local mirror of archive.u.c, but it's a bug that it's not on ports. [06:49] /usr/bin/python: No module named testtools.run [06:50] (yes, python-testtools is installed) [06:51] what version ? [06:51] 0.1~r16-0ubuntu1 [06:51] too old [06:52] 0.9.2 should be ok [06:52] [lucid] [06:52] or you can add the subunit release ppa, which has backports of a few of this sort of thing for karmic etc [06:53] lucid version installed fine [06:53] * persia plans to upgrade this server soon anyway [06:53] What does http://paste.ubuntu.com/409365/ imply I need to upgrade? [06:54] something [06:54] add -v to the command [06:54] you'll get a backtrace in the log, that actually has the problem import [06:56] * persia is looking at http://paste.ubuntu.com/409368/ [06:56] That would indicate that apport is the culprit? [06:56] ugh [06:56] no [06:56] try [06:57] python -c 'import l_mirror.tests' [06:57] ImportError: No module named testresources [06:57] did you install python-testresources? [06:57] I did. [06:57] * persia tries again [06:58] python -c 'import testresources' [06:58] dpkg -L python-testresources if that fails [06:59] Apparently I remembered incorrectly. Installing python-testresources results in "ImportError: cannot import name memory_transport_stat" [06:59] thats included in the lmirror source [06:59] did you grab a tarball or bzr ? [06:59] tarball [07:00] may be a bong tarball :> [07:00] :< [07:00] * lifeless hates on distutils some [07:00] * persia mumbles about release management and testing and pulls bzr (slowly) [07:00] persia: intentionally? [07:01] maco: No, but bzr doesn't seem to kjnow how to get much meyond 20KB/s for me. [07:01] persia: you've done bzr lp-login ? [07:02] lifeless: Yes. Anyway, with lp:lmirror, `python -c 'import l_mirror.tests'` succeeds cleanly. [07:03] ok [07:03] I'll fix [07:05] Running `python -m testtools.run l_mirror.tests.test_suite` now gets me "AttributeError: 'module' object has no attribute 'test_logging_resource'". Do I need -v again, or does this mean something to you? [07:06] try -v [07:07] traceback is still when trying to import apport. Shall I upgrade that? [07:07] no [07:07] its not apport [07:07] uhm [07:07] python -c 'import l_mirror.tests.logging_resource' [07:08] ImportError: cannot import name TestResourceManager [07:08] old testresources :< [07:08] uhm [07:08] edit that file [07:08] change TestResourceManager to TestResource [07:08] Um, why? Is there a good reason not to just upgrade? [07:09] grep for TestResourceManager through tests/*.py [07:09] l_mirror/tests/*.py [07:09] persia: may not be packaged; I don't want to yak shave right now. [07:09] though lucid has 0.2.4 which is what I'm using [07:10] so it should be packaged just fine [07:11] python -c 'import l_mirror.tests.logging_resource' works great with python-testresources (0.2.4-1) [07:11] ok [07:11] pop() [07:12] AttributeError: 'module' object has no attribute 'test_server' [07:12] Err, let me just make sure I have the lucid versions of the list of stuff you asked me to install :) [07:13] python -c 'import l_mirror.server' [07:17] OK. By installing the lucid versions of everything you asked in the beginning (except bzr), `python -m testtools.run l_mirror.tests.test_suite` runs, but I fail 35 tests. [07:17] heh [07:17] what tests fail ? [07:17] or rather [07:17] name a couple [07:17] python -c 'import l_mirror.server' runs cleanly [07:18] l_mirror.tests.commands.test_mirror.TestCommandCommands.test_mirrors_new l_mirror.tests.commands.test_mirror.TestCommandCommands.test_mirrors_incremental l_mirror.tests.commands.test_mirror.TestCommandCommands.test_error_no_source [07:19] The failures all seem to be "AttributeError: 'MemoryServer' object has no attribute 'start_server'" fromself.transport_factory.start_server() atl_mirror/tests/__init__.py:48 [07:20] newer bzr needed [07:20] but I don't really care if you run the tests or not [07:20] you should have enough to run it ;) [07:21] Good, because bzr gets compiled, and would need a real backport :) [07:21] err [07:21] the bzr ppa [07:21] already has it [07:22] 2.1.1-1~bazaar2~karmic ? [07:22] yes [07:23] Doesn't have it for my architecture. [07:24] oh [07:24] what arch? [07:24] sparc? [07:24] ppc [07:24] heh [07:24] well, you could grab source and respon [07:24] but frankly, just skip the tests. [07:24] So I don't need to backport bzr to do the test you wanted? Cool. [07:24] What do I need to do? [07:25] symlink lmirror into /usr/local/bin [07:26] done [07:26] cd to a dir somewhere, such as pool/main/libm [07:26] run lmirror init test [07:27] and lmirror mirror test /tmp/test [07:27] if those commands work [07:27] lmirror serve test [07:27] Should pool/main/libm be a current mirror? [07:27] open a new window [07:27] persia: doesn't matter; it won't write to the mirror files; it will make a .lmirror directory we'll delete shortly [07:27] and do lmirror mirror http://127.0.0.1:8080/test /tmp/test2 [07:28] if that works, then we can be pretty sure we're prepped to do some tests with jpds when his test archive server is up and running [07:31] persia: how did that go ? [07:32] you can check ~/.cache/lmirror/log to see what went on/is happening [07:32] or add -v (or -vv etc) to the command line [07:32] Just waiting for the result of lmirror mirror http://127.0.0.1:8080/test /tmp/test2 [07:33] lifeless, if while in initrd you mount a volume before mounting / and unmount it before mounting / is that safe? [07:33] ArneGoetje: When you're around, I'd like to chat about search engines and language-pack-ja [07:33] crypt-0: probably [07:33] lifeless: How long should it take for this last command to return? [07:35] persia: it should have taken no longer than the local disk mirror [07:35] can you du -sh /tmp/test ? [07:35] 24K [07:35] not test2 [07:35] /tmp/test [07:35] the one that worked [07:36] Both are the same. [07:36] interesting [07:36] does /tmp/test contain the libm content ? [07:37] It contains nothing at all. [07:37] But the directory in which I ran the tests also contained nothing. [07:37] oh [07:37] heh [07:37] well that would make it fast :P [07:37] so, it seems to be hung yeah ? [07:37] Indeed. [07:38] can you strace the client ? [07:38] I don't know how to do that interactively. I can kill it, and run again under strace. Would that output interest you? [07:39] use ps to find the process [07:39] then strace -p PID [07:40] spinning on "recv(4, "", 23, 0) = 0" [07:40] ok [07:40] its expecting more content, but not seeing it [07:40] which is interesting [07:40] I can probably reproduce this [07:41] could you add a file to your source dir [07:41] if its not a live mirror [07:41] and run lmirror start-change [07:41] and run lmirror start-change test [07:41] and then run lmirror finish-change test [07:42] and then repeat the lmirror mirror http://127.0.0.1:8080/test /tmp/test2 [07:42] I want to be sure its an empty-mirror bug, not a platform networking bug [07:45] persia: same symptoms ? [07:46] Yep. [07:47] has it written the new file to disk ? [07:47] I do get a .lmirrortemp file though, so it's trying to do soemthing. [07:47] ok [07:47] The .lmirrortempfile is 0-byte [07:47] is the new file you made 0-byte ? [07:47] the source is 15 byte [07:47] and strace shows it spinnnig on recv ? [07:48] Yes. [07:48] "recv(4, "", 15, 0) = 0" [07:48] any error on the server terminal ? [07:49] or in ~/.cache/lmirror/log ? [07:49] None [07:49] ~/.cache/lmirror/log has "2010-04-05 06:45:07Z: Writing file 'mirror.this'" [07:49] (which is the name of the test file) [07:51] ok [07:51] I have to do some stuff here [07:51] if you're up for it, might try to debug this more later [07:51] e.g. get a tcpdump trace of the request [07:52] btw do you have a http proxy configured ? [07:52] I'm happy to run stuff as you need. I don't use a proxy for that server [07:52] for now, you can delete the test file, the .lmirror dir in your test area, and /tmp/test and /tmp/test2 [07:52] (it has mirrors of Ubuntu and Debian, and any sane proxy would be useless most of the time) [07:52] persia: does it have http_proxy or similar configured ? [07:53] Not intentionally. Is there something I should check? [07:54] by "test file" do you mean some file named "test", or my "mirror.this" file used for testing? [07:54] mirror.this [07:56] OK. All deleted. I likely still have the "test" mirror configured in lmirror, but that can just sit there until it works. [07:58] nope, you've deleted the config if you deleted the things I said you could ;) [09:18] persia: I'm only only for a short time now... public holiday here today... what's up? [09:19] ArneGoetje: based on bug #526411 , we have the impression that we need to set the search providers for firefox in the langpacks, and if you have a pointer to a HOWTO or similar, we'd like to use that. [09:19] Launchpad bug 526411 in ubufox "In a fresh installation, firefox search engines are ordered alphabetically" [High,Fix released] https://launchpad.net/bugs/526411 [09:20] ArneGoetje: Any guideance would be input to discussion with yahoo.jp and mozilla.jp, as the en-US default is currently mostly useless. [09:21] persia: hum... I'm not sure about the sort ordering... but the localized searh engines are handled in langpack-o-matic, i.e. they are static there. [09:21] ArneGoetje: So what would be the best way to send a suggested order for the ubuntu-ja team? Just a bug, and subscribe you, or something more complicated? [09:22] persia: need to talk with asac first. I'm not sure what's the procedure for the localized entries. [09:23] I hear he won't be around until Wednesday or so. Does it have to be him, or will any member of the mozillateam work? [09:23] persia: can ask other members of the mozillateam... though I don't know if they know the answer... [09:24] ArneGoetje: Just to make sure I understand: you need information on how it is supposed to work, and then we'd file a bug subscribing you to make it work that way? [09:24] persia: yup [09:25] ArneGoetje: Thanks! I'll go hunt up an answer. [09:25] persia: thanks a lot! Please file the bug against the langpack-o-matic project. [09:26] Will do. === \vish is now known as vish [12:22] hi all (english is the official language here right ) ? [12:22] intick: [12:22] intick: yes [12:23] is it acceptable practice during the freeze to upload packages which are not essential for the beta on the basis that they will be processed after the freeze ends? [12:23] ok, first sorry for my poor english, i would like to know where can i share my bug experience with developpers of nautilus ? i have some comments to do [12:25] could someone un-private this bug (of course only if applicable) https://bugs.launchpad.net/bugs/549655 [12:25] Error: Could not parse data returned by Ubuntu: list index out of range (https://launchpad.net/bugs/549655) [12:27] ^^ is that ubottus way of saying this report is private? [12:28] intick: this is probably the place to start: http://live.gnome.org/Nautilus [12:29] thx mate that's what i'm looking for [12:29] cu [12:31] mdke, we are encouraged not to upload nonessential stuff during beta freeze [12:31] Um, it's more complicated that that, actually. [12:32] If a package appears in no images, it's fairly safe to upload. [12:32] i.e. universe? [12:32] Well, no. [12:32] Because many images draw from universe. [12:32] oh like... stuff in universe for ubuntu might in images for kubuntu and the likes? [12:33] If a package has an update and it is known in advance that there will be no need to change the package during the freeze, it's safe to upload (but will be held pending freeze lift) [12:33] well, my package does appear in an image, but if it isn't approved, then the upload shouldn't compromise an image, afaics [12:33] nigelb: No. The "universe flavours" vary by release. For lucid, they are xubuntu and ubuntustudio. [12:33] it's just a question of whether it will annoy the release managers [12:33] (to have it pending) [12:34] mdke: My personal suspicion is that we'll go into pre-release freeze once beta2 releases, so I would expect every upload from this point to require manual approval. [12:34] it does, it does [12:34] every upload needs release ack [12:34] persia: are you sure? That's not what the release schedule says [12:34] The risk with having it pending is that if it happens to end up having a milestone-critical bug, it's awkward to do an update that isn't the non-milestone targeted update. [12:35] mdke: I'm not sure at all. I'm just guessing. [12:35] hmm. [12:36] I'll wait until beta release and upload then I guess [12:36] That's safer for packages in images. [12:36] mdke, /me misread. Only during last week needs ack from release for all uploads :) [12:37] persia, nigelb: thanks for the input [12:43] persia: I don't think we're going to stay in pre-release freeze after the beta is out. [12:43] It's fine to upload stuff now and if there's time to review it and it appears low risk, it'll get in. [12:44] ScottK: Cool. So pre-release will just be from RC-freeze? [12:44] persia: AFAIK, yes. [12:46] That makes sense. I thought it might be more stringent because of the specialness of this cycle. [12:54] ScottK: you think it's ok to upload a package now even if it appears on a cd? (I'm not bothered about whether it is approved before or after beta release, but it would be convenient to me to get the upload off my plate now) [12:54] mdke: Yes. [12:55] ok, thanks [13:13] Hi, we in Debian Perl Group have a FTBFS on libgk2-perl (1:1.221-5) building against libgtk2-dev 2.20.0-2. If possible, could someone of you please rebuild libgtk2-perl in lucid against the gtk2.0 version there and check if it fails too? [13:25] carnil: FTBFS in my lucid pbuilder. It fails at some tests. (AMD64; libgtk2-perl: 1:1.221-4ubuntu1; libgtk2.0-dev: 2.20.0-0ubuntu3) [13:34] geser: is one of the failing test t/GtkAction.t? And thanks for testing! [13:34] [14:25] < geser> carnil: FTBFS in my lucid pbuilder. It fails at some tests. (AMD64; libgtk2-perl: 1:1.221-4ubuntu1; libgtk2.0-dev: 2.20.0-0ubuntu3) [13:34] ups, pasting to wrong channel ö [13:38] carnil: yes, "t/GtkAction.t (Wstat: 768 Tests: 19 Failed: 3)", "Failed tests: 11-13", "Non-zero exit status: 3" [13:45] geser: okay many thanks, at least it is consistent. If we manage to fix it before lucid release, hope it will get into it too. === dendro-afk is now known as dendrobates === ogra_ is now known as ogra [14:15] * hyperair wonders what ubuntu-iso in ubuntu-dev-toolsi s [14:15] yay for manpageless binaries [14:16] ah at least apt's description has it [14:26] hyperair: Just upload a manpage for it :) [14:27] persia: at this rate, i'm going to upload manpages for every single manpageless binary in ubuntu. why can't the authors of the binaries write them? [14:27] Sheer laziness. I know that I tend to avoid making changes that require changes to manpages to avoid doing manpages. [14:27] hyperair, when they have you why should they :D [14:28] * hyperair throws tomatoes at nigelb [14:29] lol [14:29] persia: i've mentioned this before, but i'm beginning to get the feeling that new contributors make better packages than old seasoned ubuntu developers. [14:29] persia: simply because they obey every single lintian complaint [14:30] hyperair: rotten ones, rotten ones! [14:30] sebner: haha not again [14:30] hyperair: you are always forgetting! :P [14:30] sebner: i like fresh tomatoes. i don't want to touch rotten tomatoes =\ [14:31] hyperair, I tend to agree (not about the tomatoes :D) [14:32] hahaha [14:32] nigelb: heheh i was about to ask whether you preferred rotten tomatoes instead =p [14:32] hehe [14:33] hyperair, I always tag patches, etc. but find very few patches tagged in packages I fix bugs [14:34] nigelb: because the seasoned ol ones don't need to please anybody [14:34] hyperair, there will come a day when lintian will check for patch tags ::D [14:37] * hyperair mumbles the code is open, you're free to patch it in... [14:37] nigelb: sound familiar? ;-) [14:37] hyperair, I thought about it, but its C and I'm zero there :D [14:38] nigelb: eh? lintian is C? [14:38] hyperair, I thought so [14:38] it isnt? [14:38] $ file /usr/bin/lintian [14:38] /usr/bin/lintian: a /usr/bin/perl -w script text executable [14:38] >_> [14:39] hyperair: all the same crap :P [14:39] sebner: perl's a different level of crap [14:39] perl? how retro [14:39] heh [14:39] but nothing is as crappy as assembly. [14:40] okay, maybe visual basic is. [14:40]