[00:01] <LaserJock> Pupeno: you should be able to use the package copy UI in PPA
[00:14] <bryce> ogasawara: for linux bugs, should they now be filed against just 'linux' or 'linux-source-2.6.24' or ...?
[00:14] <ogasawara> bryce: against "linux" now
[00:15] <bryce> ok
[00:16] <bryce> ogasawara: bug #223870 looks like it may be a kernel issue rather than an "ordinary" x crash, but needs some additional kernel-oriented triaging work.  Mind taking a look?
[00:16] <ogasawara> bryce: np, looking right now
[00:32] <bryce> ogasawara: that also might be one to have Intel test
[02:40] <Hobbsee> damn compiz
[02:40] <RAOF> To a lifetime of driver bugs?
[02:42] <Hobbsee> it crashed.  again.
[02:42] <Hobbsee> screen froze.
[02:43] <RAOF> :(
[02:44] <RAOF> Apparently there was a cycle in the animation plugin that could do that, but I think it's fixed in -updates.
[02:45] <Hobbsee> RAOF: it's still in proposed, i have it installed, and i ithink it's hanging more than usual
[02:46]  * Hobbsee had been testing it from mvo's ppa for a while though
[02:46] <RAOF> Sucks.
[02:47] <Hobbsee> hmm, there's some more updates, including an intel driver
[04:54] <pranith> hello
[04:54] <pranith> hello... when i do an objectdump of a binary, what are those addresses i get?
[04:54] <pranith> are they relative addresses of some kind??
[05:10] <giggidyy> I have a general question concering the USB Architecture as it exists on a PC: can a USB Host emulate a USB device?
[06:01] <jscinoz> ugh, where on launchpad was the intrepid new queue again?
[06:03] <StevenK> jscinoz: https://edge.launchpad.net/ubuntu/intrepid/+queue
[06:03] <jscinoz> ah thanks
[06:04] <jscinoz> how long of a delay is there normally between a package being uploaded to Debian Unstable, and it being imported to Ubuntu's new queue?
[06:05] <StevenK> Depends on when -archive runs the autosyncer
[06:08] <jscinoz> If i remember correctly, the freeze for importing packages from unstable is considerably earlier than the other freezes? Some time in june i believe?
[06:10] <jdong> jscinoz: yes, the auto-sync stops at an earlier point
[06:10] <jdong> jscinoz: but until the actual upstream version freeze it's very simple to request a sync anyway
[06:10] <jscinoz> alright
[06:11] <jdong> Dear Compiz Overlords:
[06:11] <jdong> I suggest that for Intrepid we include some Compiz games.
[06:11] <jscinoz> Should i give it a bit longer for the auto-sync to do it, or file a syncrequest now?
[06:11] <jscinoz> compiz games?
[06:11] <jdong> yes.
[06:11] <jdong> I've invented a few good ones while I've been bored in lectures.
[06:11] <jdong> open up 20 or so windows...
[06:12] <jdong> hit super-M to invert the entire screen's colors
[06:12] <jdong> then randomly hit alt-tab and super-n to de-invert individual windows.
[06:12] <jdong> Now, uninvert the whole screen and start a stopwatch
[06:12] <jdong> time how long it takes to get all windows back to the correct color.
[06:12] <jscinoz> >_<
[06:12] <jdong> (yes, I was really bored during lecture)
[06:13] <jscinoz> speaking of lectures and education, i really should get back to studying for my preliminaries tomorrow >_<
[06:13] <jdong> or, a random desktop plugin that shuffles your windows across all your desktops
[06:13] <jscinoz> thanks for the clarification on the autosync thing
[06:13] <jscinoz> *away*
[06:13] <jdong> sure thing
[06:16] <pitti> Good morning
[06:16] <tjaalton> Caesar: seems that the patch worked, you can find the package here https://edge.launchpad.net/~tjaalton/+archive
[06:33] <Caesar> tjaalton: thanks
[06:34] <Caesar> So is it in dapper-proposed now?
[06:55] <dholbach> good morning
[07:15] <tjaalton> Caesar: not yet, it would be nice to test that the patch does what it's supposed to do first :)
[08:32] <seb128> soren: hello
[08:32] <seb128> soren: do you care about gtk-vnc?
[08:35] <soren> seb128: I do.
[08:35] <seb128> soren: do you know about bug #206227? I think that's something we should try to get fixed for 8.04.1
[08:36] <seb128> soren: http://gtk-vnc.codemonkey.ws/hg/outgoing.hg/rev/e1b964facd65 seems to be the upstream fix for the issue
[08:36] <seb128> soren: also bug #207205
[08:37] <soren> You seem to have done all the work already? :) What do you need me for?
[08:37] <seb128> soren: no, I'm just reading bug mail, I don't want to do the actual testing and update ;-)
[08:37] <seb128> soren: you are better placed than me to make sure it doesn't create issues for the virt stack
[08:39] <soren> seb128: The problem is that the virt-stack is very well behaved (in this context at least). I have very little clue about all the quirks of commercial vnc servers and all that jazz.
[08:39] <soren> seb128: pochu has been very interested in this in the past. Maybe we can get him to drive it.
[08:39] <seb128> soren: well, the idea is basically to backport the change, verify it fixes the issue (trying to connect to a dapper box should be enough to test apparently) and that virt things are still working correctly and upload
[08:40] <seb128> soren: ok, will talk to him, thanks
[08:40] <seb128> soren: he commented on the bugs already
[08:41] <seb128> soren: bug #218667 mentions that the new version creates virt-manager issues that's why I want somebody to test it after patching
[08:42] <seb128> pochu: ^ do you think you could try to prepare a gtk-vnc sru fixing those issues?
[08:46] <soren> pochu: In particular, it seems that Jonh knows exactly which commits would fix this, so if we could just cherry-pick those (instead of importing new gtk-vnc and vinagre versions wholesale), that would be great.
[08:48] <foka> Hi!  I have a question: Is there a concerted effort to translate package descriptions into local languages?  :-)
[09:25] <Ademan> hey this might be a little out of place, but does apt/can apt download multiple packages concurrently? if apt-torrent or something similar were to ever mature, that might be a desirable feature
[09:30] <Company> Ademan: if you use multiple mirrors in your sources.list, it already downloads multiple packages at once
[09:31] <Ademan> Company: ah, cool
[09:36] <cjwatson> Ademan: we don't want it to hammer our mirrors like that, as a general rule ...
[09:36] <cjwatson> when you multiply that sort of thing up by millions of users it starts to turn into serious server abuse
[09:38] <Ademan> cjwatson: well, i'm curious more in terms of apt-p2p and debtorrent, as i'm really big on the idea of RELIEVING repository stress, and I think peer to peer apt would certainly go a long way to doing that.  But since it's rather unlikely that you will max out your connections download speed downloading from a handful of peers, it would be useful to concurrently download multiple packages via a peer to peer system
[09:39] <Ademan> download multiple packages concurrently*
[09:40] <cjwatson> just saying that's why it doesn't do that at the moment
[09:41] <\sh> Ademan, how does the trust model work for apt-p2p? actually, who can someone achieve, that peer X doesn't inject malicous packages?
[09:41] <Ademan> cjwatson: ah, so is the functionality there though? just disabled?
[09:41] <cjwatson> Ademan: I doubt it
[09:41] <\sh> s/who/how/
[09:41] <cjwatson> Ademan: (but I'm not an apt developer)
[09:42] <cjwatson> \sh: AFAIK it still checks against (signed) archive checksums afterwards
[09:42] <Ademan> \sh: the way i envision it existing packages.gz files would provide hashes for the files in question, plus packages are signed, correct?
[09:42] <cjwatson> individual packages are NOT signed
[09:42] <Ademan> ah
[09:42] <Klessou> Is it normal when edit the gnome-terminal LAUNCHER (in the panel) and I add "sudo" (or "gksudo") before "gnome-terminal" command. I'm using directly the root user without password ... ??
[09:42] <cjwatson> each package's checksum is in Packages.gz, Packages.gz's checksum is in Release, and Release is signed
[09:42] <Klessou>  ... in a terminal when I do "sudo gnome-terminal", at the same time I hate to put my password ...
[09:43] <cjwatson> so you don't need to go around separately verifying signatures from however many developers are involved
[09:43] <Klessou>  ... in a terminal when I do "sudo gnome-terminal", at the same time I have to put my password ...
[09:43] <Ademan> that makes sense
[09:43] <pochu> seb128, soren: I prepared gtk-vnc, although it was 0.3.5, but a user reported quite a few regressions so I'm afraid of breaking the virt stuff
[09:44] <pochu> seb128: soren: bug 218667
[09:44] <Ademan> anyways, it certainly feels less secure, but i don't believe it should be a problem
[09:44] <seb128> pochu: I've nominated 3 bugs for hardy, do you want to backport the corresponding changes?
[09:44]  * \sh is just afraid about the chain of trust...I trust the *.ubuntu.com infrastructure more then I trust any temp source of download for packages ;)
[09:45] <Ademan> lol
[09:45] <Mithrandir> \sh: uh, the Packages file is signed so that doesn't matter.
[09:45] <seb128> pochu: the crash on closing, the compatibility mode and the powperpc color issue
[09:45] <seb128> pochu: those have no reason to break keyboard, etc, and hardy-proposed is there to test changes before pushing to updates
[09:45] <cjwatson> the only thing that apt-torrent would change is that it would become much easier to attack checksums
[09:45] <Ademan> plus i like the idea of using /var/cache/apt for 'seeding' packages, since that means the most popular packages will theoretically be fastest
[09:46] <cjwatson> at the moment you have to take over a full-scale mirror to try that kind of attack
[09:46] <cjwatson> with apt-torrent, you'd be able to attempt collision attacks on individual packages
[09:46] <cjwatson> which does scare me a bit (not as much as \sh's description, but a bit)
[09:46] <Ademan> wouldn't adding another simple metric like file size make a hash collision nearly impossible? (with malicious code anyways)
[09:46] <\sh> cjwatson, which is quite easy with a small ammount of criminal energy
[09:46] <cjwatson> Ademan: not in the slightest (anyway, size is already checked)
[09:47] <cjwatson> Ademan: if you read the literature on collisions they're normally if anything easier to construct with the same file size
[09:47] <Ademan> cjwatson: interesting, i would have assumed that adding a second constraint of any sort would make it tougher to do
[09:47] <cjwatson> not that one
[09:47] <Ademan> lol
[09:48] <cjwatson> the biggest constraint that makes a difference is that the result still has to be a valid .deb
[09:48] <cjwatson> which I think means we probably aren't in serious danger right now
[09:48] <Ademan> cjwatson: ah, true
[09:48] <cjwatson> but I would not bet money on that continuing to be the case
[09:49] <cjwatson> Ademan: the thing is that you have to add an *independent* constraint, and it turns out that size and checksum are not as independent as you might think; as a rough unmathematical demonstration, think of the structure of the hash algorithm - the number of iterations of the hash you perform is very much related to the file size
[09:50] <cjwatson> Ademan: similarly, other hash algorithms with a "sort of similar" structure aren't independent either; it turns out that MD5 + SHA1 gives you about 6 extra bits of security over SHA1 alone, which is much less than many people expect
[09:50] <Ademan> cjwatson: ah true, this may fall into the same category, but would having two independent hash algorithms help?  say SHA-1 and MD5 work?
[09:50] <Ademan> ahah
[09:50] <cjwatson> no :-)
[09:51] <cjwatson> you're much better picking a single good one
[09:51] <cjwatson> concatenating hashes is a waste of time
[09:51] <Ademan> hrm
[09:51] <cjwatson> unfortunately, right now, there are no good hashes
[09:51] <pitti> argh argh argh intltool
[09:52] <cjwatson> in the sense that there are none that cryptanalysts aren't on a path towards breaking
[09:52] <Ademan> do *.debs preserve file attributes like creation and modification dates?
[09:52] <cjwatson> .debs contain a tarball for the actual filesystem data, so yes
[09:53] <Ademan> well that might be effective, even if it's not included in Packages.gz, a file manifest with creation and modification dates sounds effective
[09:53] <cjwatson> not really; bear in mind that metadata is a minority of the content
[09:54] <cjwatson> I suggest not worrying about it for now; armchair cryptography is usually a lot harder than it looks. :-)
[09:54] <Ademan> lol
[09:54] <Ademan> well i really am interested in working on apt-p2p, but the last thing i want to do is create a gaping security hole lol
[09:54] <cjwatson> I don't think you really are - it's a concern but not a gaping one
[09:55] <cjwatson> as in, it lowers the bar to attacks that aren't yet feasible, but maybe will be some day - but if they are then we'll have to address that *anyway*
[09:56] <cjwatson> and this sort of thing has been improved lately by switching to SHA256 in Packages
[09:58] <Ademan> hrm, well i suppose i'll heap apt-p2p on my giant list of crap i want to contribute to
[09:58] <Ademan> lol
[10:02] <jeromeg> ScottK: hello
[10:02] <jeromeg> I tested with glest-data, everything works fine
[10:07] <pitti> doko: did you see slangasek's questions on bug 222876?
[10:09] <jeromeg> ScottK or jdong: could one of you ack bug 227225 please ?
[10:35] <emgent> someone can add tmp execption in fiordland.ubuntu.com?
[10:38] <cjwatson> emgent: why not use the --lp option?
[10:38] <cjwatson> as I suggested last night, but you didn't respond
[10:39] <emgent> i used it, but dont work
[10:40] <\sh> emgent, did you install this lp-support  python package?
[10:40] <emgent> yes
[10:40] <cjwatson> then you need to talk to #canonical-sysadmin if you want changes to fiordland
[10:41] <emgent> \sh: python-launchpad-bugs ?
[10:41] <\sh> emgent, yes...
[10:41] <emgent> yes is in
[10:41] <\sh> or python-launchpad-integration something like this
[10:42] <emgent> i use p-l-b for anteater (u-whitehat) and work fine
[10:42] <emgent> only requestsync dont work to me..
[10:42] <\sh> hmm....but I thought the public smtp server is open to everyone, even without having an ubuntu.com address?!
[10:42] <emgent> DktrKranz2: say to me that fiordland accept only @ubuntu.com address
[10:43] <\sh> emgent, nope...I don't use my @ubuntu.com address, it's at least attached to my lp account....but first used email is my sourcecode.de address...
[10:44] <emgent> oh ok
[10:44] <\sh> emgent, it even works when you use a local smtp server which sends the email from your local system
[10:45] <\sh> emgent, important is only the gpg sig to the mail, your key needs to be known to lp...anyways...going back to work :)
[10:46] <emgent> yes i know
[10:49] <emgent> anyway i'm talking with canonical-sysadmin
[10:49] <emgent> thanks for all now :)
[10:51] <doko> pitti: replied and fixed, please reject the package, to be honest ... I think fixing this was a waste of time
[10:59] <emgent> cjwatson \sh
[10:59] <emgent> (11:57) ( Ng) emgent: well from our MTA logs it looks like your mail was delivered fine, so we'll need  to check with the launchpad guys for what their code did with it
[11:17] <pitti> doko: ok; nothing to reject, though, it's not in the queue
[11:21] <pitti> doko: ah, now it's there, uploaded 33 seconds ago :)
[11:23] <victory747> ArneGoetje, asac I should ask you about font substutition in gnome/firefox/etc regarding Chinese fonts
[11:24] <victory747> I have long had problems when using simplified chinese that first a traditional chinese font is chosen and if the glyph fails in there it falls back to a simplified chinese font
[11:24] <victory747> but the two fonts used have different typefaces and sometimes the simplified font is hard to read.  This often happens to me in thunderbird.
[11:24] <ArneGoetje> victory747: which font settings do you use?
[11:26] <victory747> in thunderbird, or in gnome, or in what?
[11:28] <ArneGoetje> victory747: in Hardy WQY ZenHei is the default font for sans-serif and monospace and therefor the default on the desktop. And this one is a Simplified Chinese font which is fairly complete in the CJK Basic area. For Serif, AR PL UMing CN is used in the zh_CN locale, which does not follow any shape standard yet and therefor you will see mixed HK and CN style glyphs. This is work in progress. Otherwise we don't have any free purely simplified 
[11:29] <ArneGoetje> victory747: ok, other question: did you do a fresh hardy install or did you upgrade from a previous version? Also, which locale setting do you use?
[11:32] <victory747> ArneGoetje, this was on a fresh gutsy install
[11:32] <ArneGoetje> victory747: try upgrade to hardy
[11:32] <victory747> ArneGoetje, my hardy machine was upgraded, but I'm not sure if it has that problem or not
[11:32] <ArneGoetje> victory747: which locale do you use?
[11:33] <victory747> ArneGoetje, The menus don't have problems, it's more things like web pages or text messages in thunderbird.  using zh_CN
[11:33] <victory747> zh_CN.UTF-8
[11:34] <ArneGoetje> for firefox and thunderbird you may need to tweak the font settings yourself in the Preferences dialog.
[11:34] <ArneGoetje> victory747: although, on my hardy machine the fonts are chosen correctly for Chinese.
[11:36] <victory747> ArneGoetje, I'll look at it more in hardy and see if I can't find problems there.  I just remember being disapointed that it still was not working as expected but I don't have any specifics.
[11:36] <victory747> Where is the order of font substitution set?
[11:36] <ArneGoetje> victory747: what does fontconfig-voodoo -l show ?
[11:36] <victory747> zh_TW
[11:36] <victory747> ja_JP
[11:36] <victory747> ko_KR
[11:36] <victory747> zh_HK
[11:36] <victory747> zh_SG
[11:36] <victory747> zh_CN
[11:36] <victory747> zh_MO
[11:36] <victory747> ka_GE
[11:37] <victory747> I wish we could change that for zh_CN locale.
[11:37] <ArneGoetje> victory747: change what for zh_CN locale?
[11:37] <victory747> ArneGoetje, where is the list of fonts used.
[11:37] <victory747> change the order of font substituion
[11:38] <victory747> I mean where is the order of font substitution specified.
[11:38] <ArneGoetje> victory747: the order of font substitution is correct for zh_CN. the question is just if your system picks it up or not
[11:38] <ArneGoetje> victory747: /etc/fonts/conf.d/
[11:38] <victory747> oh?  But I would want to use a simplified font before a traditional font in ALL situations
[11:39] <ArneGoetje> victory747: that;s the default setting
[11:39] <victory747> oh, even in gutsy?  maybe it's just my thunderbird that's messed up
[11:39] <ArneGoetje> victory747: we just don't have any purely simplified Song style font available.
[11:40] <victory747> right, you said that
[11:40] <ArneGoetje> victory747: in gutsy we don't have any purely simplified font available.
[11:41] <victory747> ArneGoetje, mabye I should do a clean install in vmware to test because my systems are always such a mess anyway
[11:41] <ArneGoetje> victory747: that';s why I suggest to upgrade to hardy
[11:41] <victory747> ArneGoetje, I'll try to find some good cases - I have nothing specific right now that I can give to you
[11:42] <ArneGoetje> victory747: as I said, on gutsy there is no purely simpplified font available. Therefore you can't change it.
[11:42] <victory747> ArneGoetje, ok, i'll upgrade my other computer to hardy soon and see how it works
[11:42] <ArneGoetje> victory747: ok
[11:43] <victory747> ArneGoetje, do you suggest a fresh install instead?  I would probably do that anyway.
[11:43] <ArneGoetje> victory747: depends on if you've messed around with fontconfig or not...
[11:44] <victory747> ArneGoetje, I'll try a fresh install I think - mostly i'm interested in the experience of chinese nationals
[11:45] <ArneGoetje> victory747: ok
[11:45]  * ArneGoetje gotta go now...
[11:59] <ogra> asac, my FF cashes if i use and close gmail (i rarely use the web interface so i didnt notice yet)
[11:59] <asac> ogra: start ffox in -safe-mode
[12:00] <asac> and see if you still get that
[12:00] <ogra> one sec
[12:01] <ogra> woah, a million password popups
[12:02] <ogra> asac, http://paste.ubuntu.com/10491/
[12:02] <ogra> silent segfault
[12:07] <asac> ogra: i think its -safe-mode not --safe-mode
[12:07] <ogra> oh
[12:07] <ogra> well, it looked quite different and opened the granparadiso startpage
[12:08] <ogra> (didnt use the stored window size etc)
[12:08] <ogra> but i can try again
[12:09] <asac> ogra: how can you reproduce? for me it doesn't crash
[12:09] <creAtion> any idea when the intrepid web forum will open up?
[12:10] <ogra> asac, open gmail, go to the spam folder let it sit there for some seconds, close the tab and see ff vanishing with it
[12:10] <asac> ogra: running -proposed? or intrepid?
[12:11] <ogra> are you crazy ? i wouldnt run intrepid :)
[12:12] <ogra> running -proposed
[12:12] <ogra> http://paste.ubuntu.com/10494/
[12:12] <ogra> one dash gives a bit more output :)
[12:12] <ogra> wonders if anyone is really mad enough to run intrepid before UDS :)
[12:13] <asac> mozillateam folks are all on intrepid already ;)
[12:13] <asac> not my idea :)
[12:13] <dholbach> asac: does X run for them? :)
[12:13] <ogra> wow, thats what i call couraged
[12:13] <asac> haven't asked that much in depth ... but i think so ;)
[12:13] <dholbach> it doesn't run in my kvm session
[12:14]  * ogra wouldnt run intrepid for money
[12:14] <jussi01> just FYI, we now have intrepid supported by the bot package lookup ;)
[12:14] <pitti> ogra: why not, it's certainly fun?
[12:14] <ogra> pitti, i have work to do :)
[12:15] <emgent> cjwatson: i saw now, if i use requestsync with --lp script give a little output with "Could not find Firefox cookie file
[12:15] <persia> ogra: Not even enough to purchase a test box?
[12:15] <emgent> "
[12:15] <pitti> ogra: in a way, you *do* get money for it :-P
[12:15]  * pitti hugs ogra
[12:15] <ogra> pitti, lol, indeed :)
[12:15]  * ogra hugs pitti 
[12:15] <emgent> but seems strange, anteater use l-p-b and work fine.
[12:15] <emgent> (with firefox cookies)
[12:15] <pitti> actually it's the first release where I did *not* upgrade to the new dev release immediately
[12:15] <seb128> same for me
[12:15] <asac> ogra: are you in the SRU team? otherwise you must upgrade now ;)
[12:15] <ogra> yeah, there is crazy breakage ahead
[12:15] <soren> ogra: I distinctly remember back in the Edgy days when your machine was broken in so many ways and all you had to say was "Edgy is so much fun". :)
[12:15]  * pitti hugs seb128, the fix-hardy-harder companion
[12:15] <seb128> I'm pondering installing it somewhere though
[12:16]  * seb128 hugs pitti
[12:16] <soren> ogra: Oh, google remembers, too: http://irclogs.ubuntu.com/2006/07/07/%23ubuntu-devel.txt
[12:16] <soren> :)
[12:16] <ogra> asac, oh, u-m didnt tell me yet
[12:16] <seb128> I think I'll get a vm running it to upload GNOME srus to intreprid too at least
[12:16] <cjwatson> emgent: ah, right, well that should be easy to fix I guess
[12:17] <asac> ogra: can you install -dbgsym for xulrunner-1.9 and firefox-3.0 and get a backtrace please?
[12:17] <cjwatson>     try:
[12:17] <cjwatson>         cookiefile = glob.glob(os.path.expanduser('~/.mozilla/*/*/cookies.txt'))[0]
[12:17] <emgent> i will try to paste path ?
[12:17] <cjwatson>     except IndexError:
[12:17] <cjwatson>         print >> sys.stderr, 'Could not find Firefox cookie file'
[12:17] <cjwatson>         return False
[12:17] <soren> ogra: But of course you were younger back then. Slightly. :)
[12:17] <cjwatson> aha
[12:17] <asac> ogra: and try with a fresh profile (keep a backup of the old one in case its that)
[12:17] <cjwatson> it's cookies.sqlite in firefox 3
[12:17] <ogra> soren, haha, yeah the old times :)
[12:17] <cjwatson> emgent: the version of requestsync in ubuntu-dev-tools trunk fixes this
[12:18] <emgent> ok thanks cjwatson  i will take a look
[12:18] <cjwatson> bug 208808
[12:19] <ogra> asac, btw, nothing ff related in proposed for me ... sadly i cant compare before and after the xulrunner update i got yesterday, i didnt open gmail in this ff at all since the machine was installed until today
[12:20] <asac> ogra: in -proposed there is a xulrunner-1.9 upgrade
[12:20] <ogra> asac, yes, got that yesterday
[12:20] <emgent> true
[12:20] <cjwatson> asac: FWIW (and it's highly subjective) the I/O problems seem a lot better now
[12:20] <cjwatson> with that xulrunner-1.9
[12:21] <asac> cjwatson: comment on bug :)
[12:21] <cjwatson> will do at some point :)
[12:21] <asac> cjwatson: bug 215728
[12:21] <asac> ok, ill try to remember to remember you in a few days.
[12:22] <cjwatson> ah, never mind, I'll do it now
[12:22] <asac> thanks
[12:23] <emgent> cjwatson: http://bazaar.launchpad.net/~ubuntu-whitehat/ubuntu-whitehat-project/uwht.dev/revision/emgent%40emanuele-gentili.com-20080408225722-t2k7o6n8z4ztz43l?start_revid=emgent%40emanuele-gentili.com-20080409012057-5lmtoh9tc6cim8wu#anteater/anteater.py-s
[12:23] <emgent> i will try to fix with: glob.glob(os.path.expanduser("~/.mozilla/firefox/*/cookies.sqlite")).pop()
[12:24] <siretart> pitti: if you happen to be working on NEW, I'm happy to answer questions on the ffmpeg-free package if necessary. it replaces the current 'ffmpeg' source package which is in main.
[12:24] <pitti> siretart: Riddell's archive day today, I'll get to it on Friday
[12:24] <dholbach> asac: it's bug 226156
[12:25] <siretart> pitti: Ah, never mind then
[12:25] <emgent> cjwatson: solved, now work fine.
[12:25] <siretart> Riddel: if you happen to be working on NEW, I'm happy to answer questions on the ffmpeg-free package if necessary. it replaces the current 'ffmpeg' source package which is in main. :)
[12:25] <cjwatson> emgent: excellent
[12:26] <cjwatson> pitti,evand: does encrypted-filesystems need another session at UDS (for ubiquity support)? it's on my roadmap, but I'm inclined to think it probably doesn't need a session
[12:26] <asac> dholbach: "branch" == crash?
[12:26] <ogra> asac, same issue with a fresh profile, installing dbgsym now
[12:27] <asac> ogra: what kind of spam do you have ;)
[12:27] <pitti> cjwatson: I agree; the discussion bits are done, it's a "simple" matter of programming now IMHO
[12:27] <cjwatson> pitti: ok
[12:27] <cjwatson> I generally try to keep things that didn't get done on the roadmap so that they don't get forgotten about
[12:28] <dholbach> asac: Xorg does not find fonts with the new libxfont - that's why it bombs out
[12:28] <ogra> asac, well, there seems to be about over 20000 msgs (as i said i never use the web interface, i only pop my mail into evo from there so i only clean thatup once every decade :) )
[12:28] <asac> ogra: all on one page?
[12:28] <ogra> nope
[12:29] <ogra> default setting (100 per page i think)
[12:29] <cjwatson> ogra: you added "stripped-down lightweight kernel flavour" to the platform roadmap. Extra kernel flavours generally give me the willies because they increase build time a lot - is this just removing unnecessary modules, or is there more to it?
[12:30] <ogra> cjwatson, its more about the core image, i was thinking about handling the modules in the initrmfs profiling spec (they somewhat belong together)
[12:31] <cjwatson> what is in the core image that could be stripped down to improve performance?
[12:31] <cjwatson> bearing in mind that simply removing features generally only improves size, not performance
[12:31] <cjwatson> or is performance not what you meant?
[12:31] <ogra> thats what i want to determine in the process of that spec :)
[12:32] <cjwatson> I have indeed put modules in the initramfs profiling spec
[12:32] <ogra> well, ram hunger rather
[12:32] <cjwatson> ogra: could you discuss this one with BenC? I don't feel it really belongs in platform, but perhaps he has room for it
[12:32] <ogra> archlinux uses our ltsp implementation using a 2.6.24 kernel as we do, but their kernel manages to boot in 16M
[12:32] <cjwatson> and can stick you in <person/> on his agenda so that you can be pulled in
[12:33] <hunger> ogra: Who? me?
[12:33] <ogra> thats my main pointer here, i'd like to compare our default setup to theirs and whatever else i find booting in such a setup
[12:33] <ogra> hunger, do you have ram for breakfast usually ? else no, not you ;)
[12:34] <hunger> ogra: Nope I usually have cornflakes, so not me, great:-)
[12:34] <ogra> :)
[12:34] <ogra> cjwatson, that spec would also go hand in hand with the compcache one
[12:34] <BenC> ogra: Any way you can use MODULES=dep for initramfs on the clients?
[12:34] <BenC> ogra: or am I missing what you want to do?
[12:35] <ogra> BenC, my core kernel (before using the intramfs) already needs more than 24M (32M if it should even be able to uncompress the initramfs)
[12:35] <ogra> BenC, and thats with netboot (i.e. only NIC drivers in the initramfs)
[12:36] <ogra> BenC, modules=dep is already a good way, but i think that can be improved as well
[12:37] <ogra> BenC, my focus in that spec is on the kernl image itself and the space it needs to load, independently of the initramfs
[12:37] <BenC> ogra: Then you are suggesting a custom flavor kernel for ltsp to use?
[12:37] <ogra> BenC, generally for low ram systems
[12:37] <BenC> or maybe that we can improve our current -generic config
[12:37] <ogra> not tsp specific
[12:37] <ogra> right, either
[12:37] <BenC> gotcha
[12:38] <BenC> ogra: sounds like a good spec...can you email me a reminder?
[12:38] <ogra> it will also be relevant for subnotebooks etc
[12:38] <ogra> BenC, will do
[12:39]  * ogra would love to get back to the sizes bootfloppies used to need ...
[12:51] <pitti> Riddell: https://bugs.edge.launchpad.net/ubuntu/+source/kaffeine/+bug/226475/comments/6 ??
[12:52] <Riddell> pitti: just a jest for the chap who closed the bug
[13:08] <sivang> mneptok: ping
[13:12] <Hobbsee> sivang!
[13:26] <laga> pitti: thanks for your mail regarding the mythbuntu-control-centre SRU. IMHO it's not necessary that the first upload is promoted to -updates, i'd rather see the second one there. or is that against policy?
[13:29] <mok0> Does anyone here know something about the mesa package?
[13:29] <mok0> I'd like to know why glw was removed
[13:30] <mok0> ... which annoys me a great deal since I am looking at source code that needs it
[13:34] <ogra> mok0, check the changelog, it should tell you
[13:34] <mok0> ogra: it tells me that it has been removed, not why
[13:34] <ogra> for sure it does
[13:34] <mok0> ogra: lesstif?
[13:34] <ogra> look closer
[13:35] <mok0> to remove lesstif deps?
[13:35] <ogra> if it says so
[13:35] <mok0> ogra: is lesstif deprecated?
[13:36]  * ogra doesnt do anything with mesa, but knows we write proper changelogs usually .-)
[13:37] <mok0> I still don't understand the reason for removing a software component that is needed by several programs
[13:38] <mok0> Unless there's a working replacement, which there isn't in this case
[13:38] <ogra> very likely because it would pull lesstif into main if it did build dep on it
[13:38] <mok0> ogra: well, then it should move to universe
[13:39] <ogra> so you that would lose 3D support all over in ubuntu ?
[13:39] <StevenK> mesa needs to be in main -- other things in main require it.
[13:40] <mok0> ... or another source package could build the missing bits
[13:40] <ogra> StevenK, well, i guess it would be possible to drop it and go back to fvwm2 as default desktop :P
[13:40] <mok0> Sorry to sound uptight, but I just a wee bit annoyed to get stuck at this point
[13:41] <ogra> mok0, the optimal solution would be to convince upstream to release it in a separate tarball, then it could build on its own in universe
[13:41] <StevenK> To be completly honest, this is like the first time I've seen someone actually miss GLw.
[13:42] <mok0> StevenK: I just googled for it, and there are many people wanting it
[13:42] <StevenK> I meant on IRC
[13:43] <pitti> laga: no, it's not against policy, it just makes testing increasingly more difficult
[13:43] <mok0> Perhaps I am looking at old code, but I don't have a whole lot of motivation to spend days with it
[13:43] <mok0> I just need to compile this code and get on with it
[13:43] <azeem> mok0: use Debian?
[13:43] <azeem> or just locally rebuild the Debian mesa package against Ubuntu
[13:44] <mok0> azeem: yeah
[13:44] <mok0> azeem: will be interesting to see what then breaks
[13:44] <azeem> StevenK: I think I complained once, when one of my packages got stripped of its OpenGL features in Ubuntu
[13:44] <azeem> never realized this was because of the main/universe split, I assumed some technical/maintainance issues
[13:45] <mok0> azeem: probably because only very few packages deal with 3D graphics
[13:46] <StevenK> GL isn't the problem, GLw is.
[13:46] <mok0> azeem: ... and Ubuntu aims to be a 2D graphics distribution.~
[13:46] <StevenK> mok0: Sigh.
[13:46] <mok0> StevenK: Sorry :-)
[13:46] <StevenK> And I think GLw affects like what, five packages.
[13:46] <azeem> mok0: eh yes, that was some pretty stupid reasoning here
[13:46] <azeem> StevenK: there might be tons of legacy code, dunno
[13:47] <mok0> StevenK: plus an unknown number of tarballs and locally developed software
[13:47] <ScottK> What it would need is some interested MOTU who would make an appropriate package ...
[13:47]  * ScottK looks around at who that might be ....
[13:47]  * mok0 hides
[13:47] <mok0> :)
[13:47]  * mok0 sighs
[13:48] <mok0> This is not the digression I am looking for at the moment
[13:50] <StevenK> So, you'd like us to demote mesa and re-enable GLw in Hardy?
[13:50] <StevenK> (Or something)
[13:51] <Hobbsee> he actually wants to start developing for breezy
[13:51] <StevenK> Bwahaa.
[13:51]  * Hobbsee is surprised that this is the first time it's clearly come up where it might get changed in intrepid, since breezy.
[13:51]  * StevenK still has a breezy chroot around somewhere.
[14:00]  * Amaranth doesn't even know what GLw is :P
[14:01] <ogra> Amaranth, it involves brick like button shapes .... (lesstif)
[14:02] <Amaranth> so an old crappy toolkit using GL
[14:03] <azeem> it's to embed OpenGL into Motif apps
[14:03] <azeem> AFAICT
[14:03] <infinity> Or, rather, allows you to draw Motif widgets on a GL canvas.
[14:03] <infinity> It's dead code.  Very dead code.
[14:04] <ogra> probably not on irix :)
[14:04] <ogra> (which might be dead code itself though :) )
[14:04] <infinity> IRIX is also dead code at this point.
[14:04] <mok0> StevenK: No
[14:05] <mok0> But perhaps create another source package the will build the missing glw  bits
[14:06] <azeem> mok0: just a warning - the mesa packaging isn't one of the friendliest
[14:06] <azeem> at least the Debian one, dunno if Ubuntu repackaged it
[14:06] <StevenK> It's liable to bite limbs off
[14:06] <Amaranth> mesa is not friendly
[14:06] <ScottK> From what I've seen, a lot of science packaging is pulling stuff from the mists of time into the modern age.
 also, is there anyone alive who understands && doesn't hate mesa's debian/rules? * ejka . o O ( you can write fortran program in any language... )
[14:06] <mok0> azeem: Ubuntu just disabled a few packages AFAICT
[14:06] <azeem> bah, line break
[14:07] <ScottK> mok0: You might want to look at how I split amavisd-new into amavisd-new and amavisd-new-milter for an example then.
[14:08] <mok0> ScottK: ok, thanks for the tip
[14:10] <mok0> ScottK: yeah, I can see that the orig.tar.gz are identical
[14:11] <ScottK> The packages are virtually identical.  I just don't build all the .debs in the two packages.
[14:11] <ScottK> The idea is each is a minimal diff from Debian to build stuff for Universe or Main.
[14:12] <ScottK> My alternative was to get Sendmail in Main, so split the package I did.
[14:12] <mok0> ScottK: very smart
[14:17] <ScottK> slangasek: You touched pinentry last.  I'd be glad to take the merge off your hands unless you want it for some reason?
[14:24] <asac> tjaalton: if i get something like http://paste.ubuntu.com/10516/ ... what could be the reason? are those codes in the error message meaningful?
[14:25] <mok0> ScottK: How do you define the inheritance of both amavisd-new and amavisd-new-milter on the same Debian package?
[14:25] <tjaalton> asac: was that all you got?
[14:25] <asac> tjaalton: no i also get something about using --sync
[14:26] <asac> tjaalton: http://paste.ubuntu.com/10517/
[14:26] <ScottK> mok0: My plan is to remember to to the second when I merge the first.  I've filed a bug against MoM to have it special cased to have MoM look to the one common parent for both.
[14:26] <asac> tjaalton: funny thing is that its when starting midbrowser ... it works on my desktop though
[14:27] <mok0> ScottK: In fact, it is a problem that could arise often: splitting a debian multi package into several
[14:27] <asac> tjaalton: can you install midbrowser package (should be quite small) and see if you get the same when starting it?
[14:28] <tjaalton> asac: ok I'll try
[14:28] <ScottK> mok0: Historically stuff has just been dropped, but I wasn't comfortable with that since we'd provided the package for a long time.
[14:28] <tjaalton> I think the serial* stuff varies
[14:28] <ScottK> mok0: I agree though.
[14:29] <mok0> ScottK: It's a bad idea to drop stuff without a working replacement
[14:29] <asac> tjaalton: for me the serial stuff is always the same (at least in the same X session)
[14:30] <tjaalton> asac: fails here too.. serial is different, rest is the same
[14:30] <ScottK> mok0: I agree, but sometimes with limited resources it's the best you can do.
[14:30] <tjaalton> and to reply the original question, no I don't know where those come from ;)
[14:31] <mok0> ScottK: that's always a restriction, of course. But if distributions only want to be "self-contained", and forget that people have their own software that also has dependencies, it is a problem
[14:32] <ScottK> mok0: Fortunately motivated volunteers show up to solve the problem. ;-)
[14:32] <mok0> :-)
[14:34] <asac> tjaalton: ok thanks for testing ... intel chip?
[14:34] <tjaalton> asac: yes. here's another with the same codes: http://fixunix.com/xwindows/90854-received-x-window-system-error.html
[14:36] <asac> tjaalton: wierd. i guess its compiz then
[14:36] <asac> i have metacity on the other system
[14:39] <asac>   gdk_window_set_events (gdk_get_default_root_window (),
[14:39] <asac>                         (GdkEventMask) (gdk_window_get_events (gdk_get_default_root_window ())
[14:39] <asac>                                         | GDK_ALL_EVENTS_MASK));
[14:39] <asac> tjaalton: i dont understand why i cant listen for all events :(
[14:40] <tjaalton> asac: that's from compiz?
[14:40] <asac> tjaalton: no from midbrowser
[14:40] <tjaalton> ah
[14:40] <asac> we listen mainly for Matchbox Events ... and key events
[14:41] <asac> tjaalton: maybe if WM doesn't support an event i am listeing for it makes X choke?
[14:41] <asac> but metacity doesn't have the events either
[14:42] <kirkland> pitti: hey, i had a few questions about some filesystem encryption work you've done previously, according to kees
[14:42] <pitti> hi kirkland
[14:42] <kirkland> pitti: howdy ;-)
[14:42] <pitti> kirkland: well, personally I did very little, but what's your question?
[14:42] <tjaalton> asac: hm, mystery
[14:43] <asac> tjaalton: anyway, thanks for the inof ... at least i have a new pointer now ;)
[14:43] <tjaalton> asac: cool :)
[14:43] <kirkland> pitti: we're kicking around intrepid ideas in the server team, and i threw out a suggestion for creating an encrypted mountpoint in each user's home directory, say ~/Confidential using ecryptfs + PAM
[14:43] <kirkland> pitti: see http://ecryptfs.sourceforge.net/ecryptfs-pam-doc.txt for more detailed instructions
[14:43] <pitti> kirkland: ah, I think I read about it
[14:44] <pitti> kirkland: is this per-file or a block device?
[14:44] <kirkland> pitti: ecryptfs is built in Ubuntu kernels, ecryptfs-utils is presently in universe as of hardy
[14:44] <kirkland> pitti: per-file/per-mount
[14:44] <hunger> kirkland: Does that reencrypt on PW-changes?
[14:44] <kirkland> pitti: it's a vfs
[14:44] <pitti> ah, cool
[14:44] <pitti> hunger: well, I hope it has a long random key, and the password just decrypts the key
[14:45] <pitti> (what LUKS does)
[14:45] <hunger> pitti: Yes, looks like it does.
[14:45] <kirkland> pitti: right
[14:45] <hunger> pitti: Key is stored in a file... not as good as luks does it.
[14:46] <pitti> kirkland: I'm not too convinced about per-file encryption, but it might be handy in some situation, yes
[14:46] <lucent> folder-level encryption would be interesting
[14:46] <kirkland> pitti: ecryptfs was just a suggestion.  i'm open to other encryption technologies
[14:46] <Caesar> tjaalton: okay, we'll do some testing internally
[14:46] <kirkland> rather than encrypt everything, i was thinking a per user folder to put your important stuff
[14:46] <hunger> kirkland: LUKS is better, but I don't see how to include that properly as a per-user setup.
[14:46] <lucent> kirkland: what I'm really missing in Ubuntu (Desktop really though) is support for file-based luks
[14:46] <lucent> when I pop in my encrypted USB partition thumbdrive, it works like a champ
[14:47] <pitti> kirkland: oh, I wasn't criticizing the actual implementation of ecryptfs
[14:47] <kirkland> pitti: k
[14:47] <pitti> kirkland: I just prefer to encrypt the entire fs, since it gives away less information and, more importantly, data does not leak to /tmp, swap, backup files, etc.
[14:47] <lucent> why must it only work for partitions?   is loop in a file too hard?
[14:47] <tjaalton> Caesar: thanks, I haven't been able to reproduce it here
[14:47] <pitti> lucent: loop files are a pain to setup by default, since you need to know the size in advance, etc.
[14:47] <kirkland> pitti: encrypted swap is essential, IMHO, if we start doing encryption by default at all
[14:48] <lucent> uhm,  swap is not encrypted?
[14:48] <lucent> my laptop system I use here was installed with alternate CD, and I put LVM-on-luks
[14:48] <hunger> lucent: I think that is because udev does the luks magic... and having udev check each file as it becomes visible might be a bit expensive.
[14:48] <pitti> kirkland: I have used an entirely encrypted LVM for half a year on my laptop without problems
[14:48] <ogra> pitti, nbd loopmounts might help ;)
[14:48] <kirkland> pitti: but encrypt everything approach wastes a lot of cpu cycles on stuff like /lib, /usr,
[14:48] <lucent> hunger: ah
[14:48] <kirkland> pitti: soren said earlier, try doing a massive compilation on an encrypted filesystem
[14:48] <ogra> pitti, makes every file you like a blockdevice
[14:48] <hunger> kirkland: Swap and tmp, too. /var/tmp as well.
[14:49] <pitti> kirkland: true, but in practice it doesn't matter so much IMHO
[14:49] <soren> pitti: Your laptop must be beefier than mine was.
[14:49] <pitti> kirkland: I guess it really depends on what your aims are
[14:49] <Robot101> you have to have swap encrypted if you want encrypted files to be meaningful at all
[14:49] <tjaalton> how to summon ubotu on a channel?
[14:49] <lucent> LVM-on-luks works better than I expected
[14:49] <tjaalton> (ubuntu-x
[14:49] <tjaalton> )
[14:49] <pitti> if you just want to protect your office documents and encrypt swap, ecryptfs might be good
[14:49] <Hobbsee> tjaalton: ask in #ubuntu-ops)
[14:49] <hunger> kirkland: If you want to do it right, then every user-writeable FS needs to be encrypted.
[14:50] <Robot101> or you'll just leak data onto your other partitions
[14:50] <Robot101> including /tmp
[14:50] <soren> pitti: Most of the time, I got by by logging into my machine at home and compiling kernels on that, but when I was stuck on the outskirts of the internet (i.e. in the US), either option *sucked*.
[14:50] <pitti> kirkland: but if you are concerned about a lot of differnet things (email, swap files, gpg keys, log files, everything that leaves trails), you quickly loose with that approach
[14:50] <kirkland> pitti: I use LVM encryption of my whole FS too...  but I don't think the run-of-the-mill Ubuntu user is ready for that.  I'd think a /home/user/Confidential directory might be more palatable
[14:50] <hunger> Robot101: Right. Every user-writeable FS needs to be encrypted if you want to do it right.
[14:51] <lucent> kirkland: "LVM encryption"  are you referring to a feature of LVM, or LVM-on-luks PV ?
[14:51]  * Robot101 LVM's his entire HDD just because in practice, separating system data from mutable data is quite hard, particularly when you upgrade often too
[14:51] <pitti> kirkland: the problem I see with that is that people might feel protected by that and stop being careful
[14:51] <soren> lucent: The latter.
[14:51] <Robot101> LVM on LUKS, rather
[14:51] <hunger> Robot101: do you have one of those encrypting HDD drives?
[14:51] <pitti> kirkland: TBH I'd rather do it the other way around: encrypt the entire /home, /, etc., and just put /usr and some other explicit stuff on an unencrypted partition
[14:52] <lucent> LVM on LUKS works but the PVs must all be encrypted, it's a flawed concept for server space
[14:52] <pitti> lucent: how do you mean?
[14:52]  * hunger would like to get one, but unfortunately his laptop is still using PATA for the drives (even though the control itself is SATA already).
[14:52] <Robot101> hunger: no its software, using LUKS
[14:52] <lucent> I mean that if you want to expand storage, you'd have to set up another partition with LUKS, and make that a PV
[14:52] <Robot101> (and dm-crypt)
[14:52] <lucent> so it means more passwords
[14:52] <pitti> lucent: you can of course also encrypt the LVs, but by encrypting the PVs you might need fewer passwords
[14:53] <Robot101> you could stack them... :P
[14:53] <pitti> lucent: right, if you have 50 PVs and 3 LVs, you'd rather use an unencrypted LVM and encrypted LVs, I guess
[14:53] <lucent> pitti: it's kind of unclear how to grow encrypted LVs
[14:53] <hunger> Robot101: Had that setup for a while, too. But LUKS kept on losing the key. Dunno why... got a new drive after the first time.
[14:53] <kirkland> pitti: so i like the idea of encrypting /root, /etc, /tmp ...  but for /home, I'd think on a per-user basis, and tied to PAM would be preferable
[14:53] <pitti> lucent: but I do see that this is a problem, yes
[14:53] <Robot101> hunger: ... ouch!
[14:53] <pitti> kirkland: libpam-mount and per-user encryption of ~ is great indeed
[14:54] <hunger> Robot101: I do have backups:-)
[14:54] <pitti> kirkland: however, you still need a global password for the swap partition (or live without suspend-to-disk)
[14:54] <kirkland> pitti: ecryptfs has one other nice benefit for homedirs, that you can do incremental backups of the underlying encrypted files
[14:55] <pitti> yeah
[14:55] <realist> I only do encrypted swap and home
[14:55] <kirkland> pitti: i use that for securely storing sensitive data on my co-lo's
[14:55] <pitti> kirkland: I think the biggest problem with all that is that the requirements of users are all differnet, and thus it is hard to come up with a default schema that suits most people
[14:55] <realist> Not sure of the benefit in crypting the system files?
[14:55] <kirkland> pitti: true dat
[14:55] <pitti> realist: encrypting /usr etc. is indeed a waste
[14:56] <pitti> realist: but encrypting log files and other stuff in /var isn't
[14:56]  * realist nods
[14:56] <pitti> and /etc as well, for obvious reasons
[14:56]  * wgrant installs a trojan on pitti's machine.
[14:56] <pitti> (secret SSL and SSH keys, shadow, etc.)
[14:56] <hunger> pitti: Depends... with encrypted /usr you can make sure nobody messes with those files.
[14:56] <wgrant> Yep.
[14:56] <pitti> not really
[14:56] <lucent> there's two motivations to encryption:  A)  Making it unclear what your data is  B)  preventing read access to unauthorized users
[14:56] <pitti> encryption is solely an offline protection
[14:57] <pitti> it does not protect you *at all* from Trojans
[14:57] <realist> If they crack the live boxes, they still get an unencrypted view of all your filesystems
[14:57] <pitti> encryption is defence against stealing your (switched off) laptop
[14:57] <hunger> pitti: Well, when I am online /usr is mounted ro anyway:-)
[14:57] <pitti> if it's still in suspend-to-ram, or running, you lose
[14:57] <lucent> pitti: there's legal ramifications to this too
[14:57] <pitti> lucent: yes, unfortunately
[14:58] <lucent> I mean to the point where you cannot be pursued because your data is indistinguishable from random data
[14:58] <wgrant> pitti: Right, but if I grab your laptop while you're away for a bit, I can boot into a live CD and alter some binary in /usr to grab your keys or similar.
[14:58]  * StevenK is reminded of a netgod quote.
[14:58] <realist> pitti: suspend to disk also
[14:58] <pitti> lucent: for people who are concerned about those, you need complete encryption of the entire hard disk, without metadata like LUKS
[14:58] <lucent> ah yeah
[14:58] <pitti> then you can plausibly deny the existence of anything; 'just unpartitioned HD space'
[14:58] <realist> Or a recently powered down laptop (frozen memory hack)
[14:58] <lucent> I think my point is, which use case are we going for?
[14:58] <lucent> people encrypting financial saved data
[14:58] <pitti> lucent: right, my point also
[14:58] <lucent> or people who are running stuff that's illegal under law
[14:58] <pitti> i. e. hard to find a default setup which suits everyone
[14:59] <kirkland> offline protection + protection of remotely stored/backed-up data (see incremental backups to co-lo's)
[14:59] <pitti> since the encryption goals vs. the price you're willing to pay (convenience, performance) vary
[14:59] <realist> I only encrypt /home for my gnucash data
[14:59] <realist> Some keyrings too, but keys can still be revoked
[15:00] <pitti> kirkland: what would really be great is to offer setups for different use cases (complete encryption, /home encrypted, per-user ~/Confidential, etc.) and the installer would ask you
[15:00] <pitti> kirkland: then we need to support all of those, of course
[15:00] <kirkland> pitti: ;-)
[15:00] <lucent> uh
[15:01] <pitti> with the alternate installer, you have some flexibility at least
[15:01] <lucent> if I'm root uid, can I not just su into people's homes and read their Confidential?
[15:01] <pitti> and per-user ~/Confidential can be set up at post-install time
[15:01] <pitti> lucent: not if those people aren't logged in
[15:01] <wgrant> lucent: If they're mounted, yes.
[15:01] <kirkland> lucent: yes, as pitti said, this is about offline protection of the data
[15:02] <pitti> lucent: if you use libpam-mount, and ~/Confidential is unlocked at login time (with your password), that's reasonably ok
[15:02] <kirkland> and by offline, that can mean "if the user isn't online, logged in"
[15:02] <pitti> lucent: of course root can just install a daemon which just waits
[15:02] <lucent> root will...  oh okay  it will have normal root rights
[15:02] <pitti> and as soon as he logs in, copies it over to somewhere else
[15:02] <lucent> but it won't be able to unlock the store
[15:02] <pitti> lucent: eventually root will
[15:03] <pitti> root controls the hardware, user's don't, so there is nothing that users can do to defend against root powers when they are online
[15:03] <pitti> s/user's/users/
[15:03] <Caesar> tjaalton: it's very difficult to reproduce
[15:03] <wgrant> Our root can lie in wait and catch the user's passphrase, and unlock the volume at their leisure.
[15:03] <lucent> IMO "encryption" should be handled much the same way "root uid" access via sudo is
[15:04] <lucent> you'd do like, ideally,  crypdo
[15:04] <kirkland> pitti: however, i don't have root on my remote backup system...  i rsync the encrypted underlying fs, and I have no concern about that root reading anything of mine
[15:04] <lucent> enter password,
[15:04] <lucent> now have access
[15:04] <lucent> and it times out
[15:04] <kirkland> it's as secure as a few thousand gpg files
[15:04] <pitti> kirkland: right, on the backup server your stuff is safe
[15:04] <tjaalton> Caesar: ah, ok.. I remember there was someone who said he could reproduce it always
[15:04] <kirkland> pitti: right, just emphasizing that use case
[15:05] <pitti> kirkland: right, my co-lo server provider also offers 10 GB on a central FTP backup server; I just pipe the backup tarball through gpg -e and ftp that
[15:05] <kirkland> pitti: whole tarball everytime, or are you able to do it somewhat incrementally?
[15:05] <pitti> kirkland: I have a pretty simple system (weekly complete plus daily incremental)
[15:06] <pitti> kirkland: it's not actually a tarball, it's an afio archive
[15:06] <pitti> kirkland: that's still my ancient backup solution
[15:06] <kirkland> pitti: heh, if it works :-)
[15:06] <pitti> at home I am now using rsnapshot, that works less conveniently with gpg
[15:06] <pitti> kirkland: it does, that's why I don't bother to change it :)
[15:07] <pitti> (it's just the /etc/.bzr, the psql dump, and some wiki data, a mere 25 MB compressed)
[15:08] <kirkland> pitti: hmm, so that's more "system" type data, than "user" type data...  which leads us back to your suggestion that defining particular use scenarios in the installer
[15:09] <lucent> Hardy ships AFAIK with a pretty useless combination of Server choice for encryption
[15:09] <pitti> kirkland: maybe we should do that step by step
[15:09] <kirkland> pitti: okay, well thanks for the feedback.  sounds like this is a bigger beast than i might have initially thought
[15:09] <lucent> no encrypted swap I think
[15:09] <kirkland> pitti: i'm all for doing this incrementally
[15:09] <pitti> kirkland: we have supported by-block-device with LUKS for two releases, so we can additionally support one technology for per-file (such as ecryptfs)
[15:09] <kirkland> pitti: encrypted swap is a great start
[15:09] <pitti> kirkland: so we should provide some integration bits to setup such a thing post-install (ecryptfs)
[15:10] <kirkland> pitti: good to hear you're open to this then....  ;-)
[15:10] <pitti> like a GUI to do it, and think about sane key handling, as well as getting the pam-mount bits right
[15:10] <ogra> encrypted swap would become difficult with hibernating i think
[15:10] <pitti> kirkland: oh, I am (I love encryption)
[15:10] <pitti> kirkland: my pain starts when we'd want to set it up by default
[15:10] <wgrant> ogra: Works fine as long as you don't use a random key.
[15:10] <ogra> (at least it forces twp PW prompts)
[15:10] <ogra> *two
[15:10] <wgrant> Not if all volumes are on one encrypted PV.
[15:10] <kirkland> pitti: so, like i said, the kernel part is already built into Ubuntu kernels (have been for some time)
[15:11] <pitti> our default LUKS setup doesn't require two keys
[15:11] <kirkland> pitti: ecryptfs-utils would need to be promoted from universe -> main
[15:11] <lucent> I think, that pain is avoided when having LVM on LUKS
[15:11] <kirkland> pitti: and the pam-mount bits, as you said
[15:11] <ogra> pitti, well, you would have to give a pw for resume to read from swap, no ?
[15:11] <pitti> kirkland: MIR doesn't scare me
[15:11] <ogra> plus the pw we ask for anyway from gnome-screensaver
[15:12] <lucent> LVM on LUKS hibernate works for me here
[15:12] <realist> encrypted swap (using random key) should be the default
[15:12] <pitti> ogra: right, you just need one password to decrypt the entire LVM (which includes swap)
[15:12] <pitti> realist: no, that breaks suspend-to-ram
[15:12] <pitti> realist: erm, to-disk
[15:12] <realist> pitti: make the two mutually exclusive?
[15:12] <pitti> realist: it might not be a concern on servers, but it sucks on laptops, and many desktops, too
[15:13] <pitti> realist: then you'd suspend to disk in an unencrypted way, there goes your data security
[15:13] <lucent> realist: what sucks on laptops?
[15:13] <cjwatson> kees: just to check, you guys are aware of bug 227322 (or at any rate the CVE behind it), aren't you?
[15:13]  * kirkland points cjwatson to jdstrand (kees doesn't appear online yet)
[15:13] <jdstrand> cjwatson: yes
[15:13] <cjwatson> jdstrand: ^--
[15:14] <cjwatson> aha
[15:14] <lucent> oh I goofed the nickname hilight
[15:14] <lucent> pitti: what sucks on laptops?
[15:14] <lucent> I'm using LVM on LUKS for a laptop, it's been fine, I think?
[15:14] <jdstrand> cjwatson: it's funny, I *just* looked at it a couple minutes ago :)
[15:14] <kirkland> pitti: you have anything regarding encryption on tap at UDS?
[15:15] <cjwatson> jdstrand: I get desktop notifications of new bugs coming in now, so if I happen to be online at the time, I notice pretty quickly
[15:15] <pitti> kirkland: not ATM, no
[15:15] <kirkland> pitti: we've discussed it a little on the Server team, but realize that we probably need to involve the platform and desktop folks too...
[15:15] <pitti> kirkland: incidentally, cjwatson just asked me this morning whether there was anything further to discuss
[15:15] <pitti> kirkland: I said no for the ubiquity bits
[15:15] <jdstrand> cjwatson: oh yeah, that irssi thingy I saw you posted-- is it working out well? (I use irssi too)
[15:16] <cjwatson> jdstrand: yeah, it's really good
[15:16] <pitti> kirkland: and frankly I think that "encrypted LVM" and "manual partitioning" are the only sane fs encryption bits that we can put into the installer
[15:16] <jdstrand> I need to check it out
[15:16] <azeem> what irssi thing?
[15:16] <pitti> kirkland: but I'd like to discuss the ecryptfs stuff further if you want
[15:16] <StevenK> azeem: I was about to say that
[15:16] <cjwatson> azeem: http://people.ubuntu.com/~cjwatson/notifications/
[15:16] <kirkland> pitti: you bet ;-)
[15:16] <cjwatson> no instructions on that page (I'll put them up at some point) - you need the fnotify irssi script as well
[15:17] <cjwatson> but with that you can have desktop notifications of people addressing you on IRC, even if you use irssi on a different machine via ssh and screen
[15:17] <pitti> kirkland: can we combine it with thinkfinger? my left index finger is my real system, my right index finger unlocks a virgin and dull standard Ubuntu instlalation, for presenting at the customs? :-P
[15:17] <Hobbsee> cjwatson: irssinotifier is good, too
[15:17] <cjwatson> (it's not original, I modified stuff I found on the web to make it work better)
[15:17] <azeem> oh that's awesome
[15:17] <jdstrand> cjwatson: oh excellent-- that is my configuration
[15:17] <kirkland> pitti: :-D
[15:18] <Robot101> cjwatson: *rad* :)
[15:18] <azeem> now I just wished it worked on oldstable - I'm trapped with sarge at the uni
[15:18] <realist> pitti: they actually ask you to boot up your laptop?
[15:18] <StevenK> realist: I've had Singapore customs ask me to
[15:18] <cjwatson> Hobbsee: cool, though I haven't quite figured it out from that page - how does that get the notifications back to your desktop?
[15:18] <pitti> realist: not so far
[15:19] <StevenK> All that did was annoy me, and presumably, everyone behind me.
[15:19] <ogra> pitti, ++ for thinkfinger support (my new lappie has that too, sadly the yet unsupported device)
[15:19] <realist> wow, next they'll be asking you to take your shoes off!?
[15:19] <StevenK> realist: The US already does
[15:19] <cjwatson> Hobbsee: I quite like mine since I can really easily piggyback other things on top of it, like notification of new LP bugs via procmail
[15:19] <pitti> ogra: Keybuk hacked that in for hardy
[15:19] <Hobbsee> realist: i had that.  in every airport i went through.
[15:19] <realist> I've never been asked to boot mine.
[15:19] <Hobbsee> and was frisked in almost all of them.
[15:19] <azeem> cjwatson: hrm, that only works if you can directly ssh to your desktop, right?
[15:19] <Hobbsee> (the shoes, not the laptop)
[15:19] <ScottK> US customs explicitly claims a right to take an image of any digital media moving through customs.
[15:19] <ogra> pitti, he wrote a driver ?
[15:20] <kirkland> pitti: what about a package, that requires ecryptfs-utils, pam-mount, etc. and does the setup for you?
[15:20]  * ScottK doesn't plan to bring his secret key to UDS.
[15:20] <cjwatson> azeem: no, mine is the other way round, you initiate the ssh connection *from* your desktop and it pulls notifications
[15:20] <ogra> pitti, my device ID is yet unsupported by the driver
[15:20] <lucent> realist: United States plane goers walk shoeless through the security checkpoints
[15:20] <pitti> ogra: no, thinkfinger has been there for a long time; I have used it for a while, too
[15:20] <azeem> cjwatson: ah, didn't get that bit, that's gold
[15:20] <realist> ScottK: they can take a copy of my encrypted partition then.
[15:20] <pitti> ogra: he just fixed some integration bits
[15:20] <StevenK> realist: Last time I flew to the States, it was. "Laptop out. pockets empty" for Australia, and it's "Jacket off, shoes off, laptop out, pockets empty, belt off" for the States
[15:20] <cjwatson> azeem: I'll htmlify my instructions for it in a bit
[15:20] <lucent> yeah
[15:21] <lucent> StevenK: but you can have 7 inch knitting needles
[15:21] <Hobbsee> cjwatson: ssh tunnel and the notify stuff, i think.
[15:21] <lucent> go figure
[15:21] <StevenK> I didn't try that.
[15:21] <Hobbsee> cjwatson: i didn't check it out too much, as i then switched across to bip.
[15:21] <Hobbsee> (meaning that i rarely used irssi)
[15:21] <StevenK> I didn't want to be in prison for UDS.
[15:21] <StevenK> :-P
[15:21] <cjwatson> the only slightly irritating bit is that you get notifications even if you're watching the channel
[15:21] <lucent> StevenK: my auntie likes to knit on the plane
[15:21] <Caesar> tjaalton: yeah we've got users internally who can reproduce it reasonably reliably, but it's never affected me personally for example
[15:22] <lucent> they made her throw out a paperback book because it was not "appropriate"
[15:22] <StevenK> lucent: I've heard about US Customs snapping knitting needles.
[15:22] <ogra> pitti, well, according to upstream "its being worked on to get that devies into the driver as well" last time i looked
[15:22] <lucent> but she was cleared to bring her knitting needles
[15:22] <lucent> ha, no customs for her
[15:22] <lucent> that's a different kind of personal abuse
[15:22] <kirkland> yeah, my wife brought knitting needles on the plane, and they seized my 3" screwdriver
[15:22]  * lucent laughs
[15:23] <lucent> that's exactly true
[15:23] <lucent> some stupid country I live in
[15:23] <lucent> sorry to herd this off-topic
[15:23] <lucent> I just wanted to confirm the shoe thing is true
[15:24] <lucent> I was waved through with a 5lb snowboard iron
[15:24] <lucent> of all the things that could be a lethal weapon, my shoes definitely are not
[15:24] <lucent> that iron was.
[15:25] <lucent> it sounds silly but that is how it goes, I checked my laptop through a few times and the worst that's happened is some fat woman or man sprinkles dust on the top and pretends to look concerned about your safety
[15:27] <hunger> When I went to the UK last they even took the time to vacuum clean my laptop at the custom area. That is service!
[15:27] <lucent> hunger: vacuum it...with drug-snorting dogs?
[15:28] <wgrant> They have these great bomb-detecting vacuum cleanerish things.
[15:28] <hunger> wgrant: Whatever the reason... it did clean my keyboard pretty nicely.
[15:28] <wgrant> Heh.
[15:29] <hunger> wgrant: The guy didn't like being asked to vacuum around the screen once more though:-(
[15:29] <wgrant> Not surprising.
[15:37] <jcwinnie> Help! Ubuntu. Help! Wubi has fallen down the well again.
[15:38] <StevenK> Okay then
[15:40] <soren> pitti: xgettext seriously doesn't scan for _("foo")? Only _('foo')?
[15:41] <pitti> soren: the quotes don't matter, of course
[15:41] <pitti> soren: but not _(var)
[15:42]  * soren exhales, relieved.
[15:42]  * pitti apologizes for his inconsistent quote style in the bug reply
[15:43] <pitti> soren: in python I generally prefer ', since it doesn't need shift
[15:43] <ogra> pitti, depends on your keymap, really
[15:44]  * ogra needs shift here on a german keymap
[15:44] <ogra> oh, sorry i just noticed i have the ' key twice ....
[15:44]  * ogra shuts up
[15:44] <soren> pitti: So, how does this work, then? print _("foo %s") % bar ?  print _("foo %s" % bar) ? Something else?
[15:45] <cjwatson> _("foo %s") % bar
[15:45] <soren> cjwatson: Thanks.
[15:45] <cjwatson> the translatable thing needs to be (roughly) a constant string and translators are expected to do sensible things with format string markup inside
[15:46] <tjaalton> is archive.u.c having some issues? I get hash sum mismatches
[15:46] <ogra> its slow at least
[15:46] <tjaalton> it is that
[15:46] <tjaalton> is there a place to sync a mirror from
[15:46] <ogra> i just switched to the de mirror here for chroot building, that helps
[15:46] <lucent> _("foo") + bar
[15:47] <lucent> heh
[15:47] <soren> tjaalton: It's horribly slow, and I keep getting checksum errors and shit, too.
[15:47] <tjaalton> soren: ok, I'll change to another mirror then
[15:47] <soren> tjaalton: apt-cacher was acting up at the same time, so I blamed that.
[15:54] <azeem> cjwatson: it shouldn't fire for highlights in the current chan/window, IMO
[15:57] <pitti> soren: btw, if you fix the _() thing, please reupload with the same version number
[15:57] <pitti> soren: otherwise -changes@ and my SRU watch pages will just get the _() update changelog, and not the original one
[15:57] <cjwatson> azeem: yeah, I'm sure that's fixable in irssi/fnotify, just haven't spent time figuring it out
[15:58] <soren> pitti: Already done.
[15:58] <soren> pitti: ~5 minutes ago, so it should be in your queue now.
[15:59] <pitti> soren: great, thanks
[16:03] <ogra> could https://wiki.ubuntu.com/SecurityUpdateProcedures be linked from the development wikipages ? it took me quite a while to find it by searchig
[16:15] <tjaalton> whoops? :)
[16:16] <Hobbsee> nice work.  that would have changed all channel topics that weren't locked
[16:17] <Hobbsee> until it crashed, anyway
[16:22] <realist> cjwatson: is there anything special I need in order for fnotify to work?
[16:22] <cjwatson> realist: I have proper instructions on http://www.chiark.greenend.org.uk/~cjwatson/code/notifications/ now
[16:22] <tjaalton> hmh, apt-mirror refuses to work with !a.u.c
[16:24] <psusi> bdmurray: my ubuntu-bugcontrol membership is about to expire, could you renew it please?
[16:24] <tjaalton> Hobbsee: changed the topic on #u-x again
[16:25] <realist> cjwatson: it doesn't appear to be writing out to ~/.irssi/fnotify for some reason
[16:25] <Hobbsee> tjaalton: i don't have control, i'm just watching -ops
[16:25] <tjaalton> darn
[16:25] <cjwatson> realist: dunno about that, sorry, it just worked for me
[16:25] <cjwatson> realist: you may need to explicitly /hilight things you care about
[16:25] <Hobbsee> tjaalton: i've been staying quite deliberately away from it
[16:26] <tjaalton> Hobbsee: :)
[16:27] <realist> cjwatson: not even working for privmsg :-(
[16:30] <ogra> seb128, do you think david will put any more time into gnome bug 526320 ? he doesnt sound like he would
[16:31] <seb128> ogra: no, you want the change backported right?
[16:31] <seb128> ogra: it's on my todolist
[16:31] <ogra> i have lots of ltsp users complaining, yes
[16:31] <ogra> wow, ubottu is slooow :)
[16:32] <ogra> seb128, ok, thanks, but he doesnt seem to really care which is really sad imho
[16:33] <seb128> ogra: not really true, he's usually responsive but I think he has lot of other issues on his plates already and there is no obvious way to get that one work better easily
[16:34] <ogra> yeah, fedora is nearing the release, i understand he's busy
[16:35] <emgent> dholbach: thanks for ACKs, sympa fixed and ready when you have time. :)
[16:37] <Hobbsee> ogra: they're trying to fix the meeting stuff
[16:38] <ogra> meeting stuff ?
[16:39] <jdavies> ogra: the automatic topic update in #u-meeting
[16:40] <dholbach> emgent: I guess I'll get to it tomorrow if nobody else does before - thanks
[16:40] <emgent> thanks to you dholbach
[16:41] <ogra> Hobbsee, ah, youre referring to my bot comment ... took a while to make click :)
[16:41] <Hobbsee> ogra: yes :)
[16:51] <azeem> cjwatson: ok, took me one irssi segfault, but here it is: http://paste.debian.net/2301/
[16:51] <azeem> doesn't notify for current chan anymore
[16:53]  * cjwatson applies the same to priv_msg
[16:56] <azeem> good point
[16:56] <cjwatson> azeem: looks good, I think
[16:58] <cjwatson> azeem: updated http://www.chiark.greenend.org.uk/~cjwatson/code/notifications/fnotify, thanks
[17:15] <LaserJock> azeem: is there a reason you're going nuts in #debichem? :-)
[17:15] <Savago> @all: it seems that Hardy has some problems with Bluetooth services (# 148712 and others).
[17:15] <Savago> Is anyone actively working on this?
[17:16]  * Savago wants to help if possible.
[17:17] <azeem> LaserJock: euh
[17:17] <azeem> LaserJock: well, see above, I was testing cjwatson's fnotify script
[17:17] <azeem> I totally thought I was alone with CIA in there
[17:19] <LaserJock> azeem: no problem, just wondered if you were having mental problems and started talking to yourself ;-)
[17:19] <azeem> cjwatson: I've now modified it further to only notify if I'm away (which means screen detached when using screen_away), but this is probably not everybody's facourite
[17:19] <cjwatson> yeah, I don't use that ...
[17:19] <cjwatson> though I sort of like the idea, not sure
[17:23] <realist> cjwatson: I found the bug in fnotify
[18:02] <slangasek> ScottK: I have no attachment to pinentry, feel free to take the merge
[18:02] <ScottK> slangasek: OK.  Will do.
[18:08] <Keybuk> asac: is network-manager-applet supposed to be missing a build-dep on libnotify-dev?
[18:34] <ScottK> Is CDBS generally broken right now or is my upload special?
[18:35] <ScottK> http://launchpadlibrarian.net/14261790/buildlog_ubuntu-intrepid-i386.pinentry_0.7.5-2ubuntu1_FAILEDTOBUILD.txt.gz
[18:35] <norsetto> scottk: is that inttool?
[18:36] <ScottK> Yes
[18:36] <norsetto> scottk: its broken right now
[18:37] <ScottK> norsetto: Thanks.
[18:37] <norsetto> ScottK: np
[19:55] <mario_limonciell> mvo_, ping
[19:58] <mvo_> hello mario_limonciell
[19:59] <mario_limonciell> hi mvo_ .  i was speaking to Amaranth about a fix for bug 160264
[19:59] <mario_limonciell> and he had said to bring it up to you so it can get into intrepid before going the SRU route on it
[20:09] <mvo_> mario_limonciell: intrepid is in a bit too much flux
[20:09] <mvo_> mario_limonciell: if it needs testing I think the compiz ppa is a good candidate
[20:09] <mvo_> mario_limonciell: but we can sru it directly if the patch is reasonable small (let me check)
[20:09] <mario_limonciell> yeah its very small
[20:09] <mario_limonciell> i've attached a debdiff to the bug
[20:11] <mvo_> mario_limonciell: hm, it just drops 30_fix_screensaver ? is that 100% sure that the xserver is now fixed ? otherwise we open a huge security hole
[20:11] <mario_limonciell> mvo_, yes
[20:11] <mario_limonciell> i linked the rationale
[20:11] <mario_limonciell> in my comment
[20:12] <mvo_> mario_limonciell: yeah, I have seen the changelog - I will give it a test run tomorrow morning, ok?
[20:12] <mario_limonciell> but widespread testing will of course be necessary per the SRU
[20:12] <mario_limonciell> mvo_, sure
[20:12] <mario_limonciell> i've also built it on my PPA if you want to save yourself a test build
[20:12] <mvo_> mario_limonciell: nice, thanks
[20:13] <mario_limonciell> no prob
[21:55] <stgraber> Who's ubottu's owner ? We would like it on #ubuntu-testing, we are really missing ubotu there :)
[21:56] <dsas> stgraber:  You need to speak to seveas
[21:59] <_MMA_> stgraber: #ubuntu-ops might be able to help.
[22:00] <stgraber> _MMA_: right
[23:48] <hmuller> I'm looking for a pointer to information that explains the purpose of "build-stamp" in a makefile.  I've searched both the manpage and manual, and googled.
[23:56] <LaserJock> hmuller: I believe it is to make sure that the build only happens once