[00:00] when it ate my data was around 2000 i think, and that bug wasn't fixed until around 2007-2008 timeframe [00:00] no, it's not "patched" [00:00] it's worked around. [00:00] so it wont eat my data [00:00] no, I never said that [00:00] raid doesn't protect you from a filesystem eating your data :) [00:00] (the current versions of XFS in 9.10) [00:00] but fundamentally XFS's journal replay strategy is to zero stale data [00:00] crypt-0: No one with guarantee any file system won't eat your data [00:00] jdong: oh ok [00:00] i know [00:00] If they do, run. [00:00] ext3's policy is to leave it stale [00:01] because stale is likely correct [00:01] coming from an enterprise background, XFS's policy is that stale data can constitute privacy leaks [00:01] i.e. it belonged to another file in the past. [00:01] well i will be creating a new filesystem soon [00:01] all i remember well was that my fs was filled with a lot of null filled files [00:01] large chunks of missing data [00:02] its EXT3 or XFS....EXT4 just is not there yet. [00:02] with that said, "older" XFS did have a nasty case where the "cp a b; mv b a" atomic-modify workflow could result in "a" being entirely stale on bad shutdown [00:02] more than i would expect from just the journal unless it was bigger than i would expect [00:02] which is the biggest source of the "XFS nulled my data" complaints [00:02] ext4 is the default on Karmic. I think it's a reasonable assumption that it was considered reasonably safe. [00:02] that's since then been "worked around" to happen less frequently [00:02] jdong: i bet i saw that or something similar to that, because it seemed much more than just what would fit in a journal [00:03] with that said, I do find XFS like ext4, because of delayed allocation, very aggressively uses the writeback cache [00:03] and a bad shutdown on a modern system with a boatload of RAM can easily result in hundreds of MB of unwritten data to be tossed out [00:03] but no filesystem makes any sorts of *guarantee* this won't happen. [00:03] jdong: with the ext4 fix for the desktop issues it probably won't trigger data loss like that though i would imagine [00:03] [bad shutdown] im on a smart UPS [00:03] since xfs is older, wouldnt it be "ext4, like xfs..." [00:03] ccheney: delayed allocation still applies. [00:03] maco: eh it's a commutative relationship ;-) [00:04] I'm not gonna trace back to the first filesystem to implement delayed allocation [00:04] jdong: iirc any rename forces a full flush now though, right? [00:04] well are you saying i should avoid XFS? [00:04] crypt-0: that doesn't stop system freezes, etc [00:04] and those seem to happen all the time on desktop apps, heh [00:04] ccheney: rename definitely places a barrier between old and new [00:04] and to cross the barrier a flush is needed, yes [00:04] jdong, i know but i have not *ever* had a system freeze with Linux. [00:04] so either the original or the final file will be there, not in between. [00:04] crypt-0: consider yourself very lucky. [00:05] crypt-0: even on servers I manage I've been in the case of needing to hard-power-cycle against my will [00:05] I'm not saying you shouldn't use XFS. [00:05] I had my primary server on XFS for the past 3 years... [00:05] only recently did I switch it to btrfs to contribute to the testing effort. [00:06] note I do not of course recommend users to do this [00:06] well, i have had *hardware* related system freezes....like when i boot my external HD at school and someone bumps it....still XFS does not get corrupted [00:06] consider yourself lucky then [00:06] particularly on external USB2 drives (which do not respect barriers) [00:06] and on RAID or LVM devices (which do not respect barriers) [00:06] jdong, so with the current versions of the XFS tolls and kernel module in 9,10 would you consider XFS a stable filesystem? [00:06] a bad shutdown on XFS can corrupt its metadata beyond repair. [00:07] crypt-0: I've always considered XFS a stable filesystem [00:07] note the two caveats that I pointed out [00:07] what filesystem do you recommend for RAID-1 [00:07] delayed allocation <-> writeback data loss; loss of write barriers <-> full filesystem corruption. [00:07] i will be using hardware RAID-1 for my next build [00:08] I do not have a recommendation if no corruption / data loss on hard shutdown is your goal. [00:08] and XFS will be on a LVM (encrypted filesystem) [00:08] that's simply not possible without hardware battery backed storage controllers [00:08] (at the very minimum; stable software configuration and ECC'ed RAM above that) [00:09] with that said, you should weigh your risks against the benefits [00:09] ext3 seems to handle hard shutdowns well. [00:09] it has a 5 second commit flush [00:10] it also uses physical block journaling [00:10] im on battery backup (UPS, my apps are stable, and if the UPS runs of battery it tells the PC to power off ) [00:10] which increases the hamming distance between valid codewords. [00:11] * ccheney personally likes to stay with what the most users run, as its generally best tested [00:11] if you are so confident your hardware will not flake, you should use any stable marked filesystem that best handles your workload from a performance and maintenance standpoint. [00:11] EXT3 has always been good to me, and so has XFS [00:12] in the past, ext3 has by far been best to me in resilience to abuse [00:12] * ccheney bbl [00:12] im just wondering , in your opinion is the XFS throughput worth it? [00:12] what XFS throughput? [00:12] depends on what you're doing. [00:13] a lot of DVD rips [00:13] I switched AWAY from XFS for performance reasons [00:13] XFS performs extremely well when your data is comprised of large files (>50MB each) [00:13] all legal of course, :) [00:13] XFS performs extremely poorly when your data is comprised of a large number of small files [00:13] the latter tended to be my usecase on that server (a build server) [00:13] and sometimes XFS could take minutes where ext* would take seconds [00:13] * RAOF wished he lived somewhere where dvd rips were legal. [00:14] well , when i extract a DVD most of the chapters are over 100MB, and the final raw mpeg is 4GB [00:14] the ripped version ends up at arounf 2GB [00:14] im plaining on bluray rips which will have a considerably larger size [00:15] XFS is a very reasonable filesystem for that [00:16] just keep my caveats in mind. [00:16] but i also have about 60GB of music file sizes 2-100MB per song [00:16] maybe that's why my builds take a while on xfs :) [00:16] micahg: rm -rf is a very bad workcase for XFS [00:16] (1) it spends a lot of time rebalancing the B-tree that will eventually be completely gone anyway [00:16] is there a way to shrink xfs yet? [00:16] (2) Nowadays, it flushes barriers (16-32MB of hardware cache) every couple of transactions [00:17] yay, write 8KB of data, flush out 32MB. [00:17] since i will be using 64 bit will that help? [00:17] why does that have any impact? [00:17] XFS is a 64-bit file system. It supports a maximum file system size of 8 binary exabytes minus one byte, though this is subject to block limits imposed by the host operating system. On 32-bit Linux systems, this limits the file and file system sizes to 16 binary terabytes. [00:18] so thats it, it has no other impact? [00:18] i think ill go ext3... [00:19] i should get decent read with any FS with raid-1 [00:19] and decent write with RAID class drives [00:19] you know that XFS is a 64-bit filesystem even on a 32-bit processor right? [00:20] but now that i think about it, the bottleneck is not the HD as much it is the DVD reader and CPU for encoding [00:20] right. [00:20] but fragmentation wise you DO want an extent-based filesystem [00:20] basically, the filesystem can through a LOT more data at the encoder than the encoder can encode. [00:21] but EXT4 is so slow [00:21] umm... [00:21] and i have not run into frag-related issues with ext3 [00:21] so you choose ext3? [00:21] you've got to be kidding me [00:21] i have not tested ext4 that much [00:21] ext3's problem with dealing with large files is fragmentation when dealing with large files. [00:21] i use it for /boot [00:21] ext4's primary GOAL is to fix that limitation of ext4 [00:22] ah [00:22] through extents and delay allocation [00:22] so ext4 is ext3 with better handling of large files. [00:22] and support for larger filesystems [00:22] most of my experence with EXT4 has been with /boot [00:22] i read that all the ext4 extents can decrease entropy [00:23] for disk encryption [00:23] but, that is probably NSA level shit paranoia [00:23] I do not have good knowledge of the effects of ext4's disk structure on cryptanalysis [00:23] so I cannot answer one way or another to that :) [00:24] but my intuition from my informal experience with the subject is that it's probably not something you should be too concerned about [00:25] right [00:25] so, wait a sec, you tried out ext4 on /boot and then decided it was slow? [00:25] like i said its probably NSA level crap [00:25] not the best of test cases :) [00:25] well i also used it years ago on an external partition [00:26] considering ext4's lifespan is on the order of "year(s)" ago [00:26] for very small instantiations of the plural... [00:26] more or less the first thing my security lecturer taught me at university: "if a class 3 attacker is out to get you, you're toast anyway" [00:26] and for the majority of that time features like extents and the mballoc werne't implemented... [00:26] I'd say it's time for you to reevaluate ext4. [00:26] don't waste time on vague cryptanalytic worries unless you actually have solid evidence [00:26] NTFS uses extents....and i dont see fully-encrypted winblows machines getting their encryption broken [00:26] * dtchen chuckles at the NSA fud [00:26] I've found its performance with large files to be comparable if not better than XFS [00:27] but XFS' scalability to the horrendous extremes is unbeatable [00:27] and by that I mean things like 20TB filesystems, 1TB files, etc etc etc [00:27] I don't think that's relevant to you [00:27] * maco points at dtchen and yells "spook!" [00:27] I will say that XFS's backup tools (xfsdump) and administration/maintenance tools are far superior to ext*'s [00:27] but I also don't see that terribly relevant to your usecase for storing movie rips [00:28] yeah [00:28] one of the requirements of my XFS server involved storing home-ish directories for highly active users and that demanded nightly incremental backups, online, while files are changing... [00:28] and i use LVMS so i can use a LVM snapshot, or a desynched RAID disk [00:29] xfsdump was an instrumental part of that workflow [00:29] for movies, they're very much write-once-change-many, and don't benefit as much. [00:30] " more or less the first thing my security lecturer taught me at university: "if a class 3 attacker is out to get you, you're toast anyway" if i was worried about three letter agencies, i probably would not even use a computer :) [00:30] lol cjwatson is absolutely correct there :) [00:30] yes, the TEMPTEST attacks, i dont live in a EMI shielded cage :) [00:30] and along those lines, there's probably a lot more weak links in your crypto setup than predictable filesystem structures [00:31] s/predictable/uniquely identifiable/ [00:31] there are a lot more "efficient" methods, like clubbing you over the head until you cough up the passphrase [00:31] yeah [00:31] that was my point [00:31] lol and my system sits on my desk in a dorm room [00:31] if you really want my data, come poison my bootloader while I'm in class. [00:32] if your being hunted by a three letter agency they are going to decrypt you based on your EMI, or log your keystrokes via EMI, etc [00:32] yeah [00:32] crypt-0 - i work in an EMI shielded room :P [00:33] i do use disk encryption, i do use a thoubrive for /boot with the GRUB MBR on it...but that is where i draw the line [00:34] so come get me with a hardware keylogger if you want my data :) [00:35] disk encryption, with SHA1/DES is probably good enough privacy for what i do. [00:36] chrisccoulson: I work in an accidentally EMI shielded room. [00:37] kees - how come? the room i work in is not accidentally shielded ;) [00:37] one of my professors said one of the same things about if your being hunted by 3 letter agencies....for downloading music and movies or ripping them he basically said you just have to be faster then the other guy [00:37] i spend a lot of time in a RFI chamber at the moment [00:37] i don't get to see any daylight ;) [00:37] lol [00:37] * spm has done tempest attacks. it's pretty cool stuff. [00:38] * crypt-0 drills holes in your wall and starts picking up your keystrokes with an acoustic keylogger [00:38] :P [00:39] the one that gets me as "almost practical" is sniffing your screen, but there is too much time and effort involved in that i assume under normal circumstances [00:40] it would not be used [00:40] I think the root of "assume" is "ass, you, me" :-) [00:40] "Local man cought using LimeWire with TEPMTEST attacks" [00:40] true. [00:41] i do use an LCD with a shielded cable, i consider it sufficient. [00:41] or is it not? [00:42] * spm has done successful temptest attacks on PC's with no monitor [00:42] blah [00:42] what of those attacks are standard with music/movies? [00:43] the more you know....the more paranoid you get:) [00:44] think outside the square. why use technical if simpler physical or personal attacks are cheaper and more efficient === asac_ is now known as asac [00:47] tbh tho. those agencies ahve far bigger fish to fry. there's nothing you can do to stop them if they really want your stuff. but a simplistic risk analysis would suggest - "you" have zip of value they're interested in. they have the capability; they just don't care. [00:48] chrisccoulson: no clue -- i assume the concrete and lead paint contributes. :) I get no radio or cell signal in my basement. :) === robbiew is now known as robbiew_ [00:49] kees - yes, the lead paint will probably contribute [00:55] spm yes, i have talked to people who have worked Fornesics, music/movies is the very last theing thet care about [00:57] of course they always want that "example" , but they would probably target someone using less security ( the average Joe filetrader) [00:57] well yes. foreign governments and keeping our soldiers alive was more important than a few execs losing a bmw of roll's [00:57] s/of/or/ [00:57] or the 12 year old girls they have been known to targer lol [00:57] target [00:58] "Sally just got caught using the evil program LimeWire now her family has to pay 100 million dollars muhahaha" [00:59] What im saying is "Can my security be beat? Yes." "Will it be as easy as taking my PC? No." [01:01] the real question is who cares enough to mount Temptest attacks on me, and i believe no one does, as i dont live in China [01:01] :P [01:01] anyway [01:02] even if 20% of my data was 100% predictable, i dont that would lead to successful cryptanalysis [01:02] at least, not at this level. [01:02] ever the innovators, China has recently melded two of their most important industries to create the first tempest-in-a-teapot technology [01:03] lol [01:03] China broke WPA2 i believe also, as SAH1 [01:06] I have also heard and read that the MPIAA/RIAA has swiched to badgering ISPs to badger you [01:06] eg [01:06] "your isp says stop downloading or else: [01:07] instead of "you should have stopped downloading, we are coming to milk you for every cent you are wroth" [01:08] nevertheless i find Temptest attacks interesting. [01:08] why? [01:08] well, i am going to be taking Forensics classes, im still a student [01:09] it's amusing watching someone play solitaire (badly) [01:09] ahh. right. [01:09] my major will probably be networking, but Forensics is nice to have if you are network admin [01:10] I'd hope not!! :-) [01:10] the idea is to ensure you have very little need to do any forensics. [01:10] "Boss: "Joe has been looking at porno and motorcycles all day instead of his work, can you prove it?" [01:11] that's not forensics. that's boring. yukky; seriously yucky. and tedious. [01:11] yeah [01:11] it's also a case where you need to make sure you are on very sound legal ground [01:11] http://www.stedee.id.au/web_proxy_log_usage_forensics_and_analysis <== wrote that for sage-au years ago; then blogged the same. [01:11] exactly [01:12] but form what my professors said....you have to prove they were not ding their work [01:12] doing [01:12] have been pulled in as an expert witness in one case [01:12] jurisdiction? [01:12] it all depends. [01:12] in the case I was involved in; the "porn" was but one plank of a raft of issues. [01:12] crypt-0: depending on local law, you might find yourself the subject of a countersuit for invasion of privacy ... like I say, if you find yourself in that position, you might want to have taken legal advice in advance [01:13] so you have to do port mirroring on their port,i assume a wireshark capture file would be enough [01:13] the guys dismissal was upheald over a range of issues; not just one. [01:13] err what's wrong qith eg proxy logs? or firewall logs? :-) [01:13] why make it hard on yourself? :-) [01:14] well i recall my profs saying, you need evidence that is hard enough to go to court with, because you may have to [01:14] firewall logs may not be enough [01:14] they should, but not everyone in the jury is a tech guru. [01:14] like I said. which jurisdiction. it was plenty for a magistrate for an unfair dismissal case here in australia; ymmv. [01:15] USA here [01:15] and again; it was only a single part of the 2 day hearing [01:15] ah ok [01:15] well [01:15] here [01:15] if you are using school/business computers [01:16] the AUP is basically: we can monitor what you are doing and will if we wwant [01:16] (please don't use the enter key as punctuation.) [01:16] cjwatson, sorry. :) [01:16] [01:16] :P [01:16] note that AUPs are not necessarily in and of themselves legal [01:17] yes; huge levels of "it depends" in this area. [01:17] just as simply writing something down in a contract doesn't make it enforceable [01:17] Right. [01:18] spm, Forensics is also useful foe Intrusion detection on the network. [01:19] are we still building explicitly for lpia given the dropping of the arch? (maybe a dumb question...I've been under a rock debugging linux and pulse issues) [01:19] heh. ignoring that the biggest abusers (ie $$ loss) will be your authorised users? [01:19] http://en.wikipedia.org/wiki/Workplace_privacy - brief but to the point [01:19] dtchen: we're stopping [01:19] anyway, i plan on "downgrading" my encrypted root partition to AES128 for speed [01:19] dtchen: well - for lucid, anyway. hardy-karmic PPAs will keep building for lpia [01:19] cjwatson: thanks [01:20] someone who has access needs to remove lpia from the bottom of https://edge.launchpad.net/ubuntu/lucid [01:20] * ajmitch doesn't know where to file that bug [01:20] dtchen, yeah pulseaudio has its issues, had trouble with playing UrbanTerror [01:20] and the sound [01:20] crypt-0: that isn't pulse; that's alsa-plugins. [01:21] but it is "fixed" in a fourm o found somewhere [01:21] we don't sync the "hw ptr" properly [01:21] oh [01:21] wel [01:21] unfortunately it is *extremely* dependent on the audio hardware and kernel configuration [01:21] ajmitch: that'll happen along the line [01:21] wait....the fourms said to force it to use pulse [01:22] ajmitch: I don't believe it's possible to do it yet, because other parts of the removal are not complete [01:22] anyway it works. [01:22] crypt-0: what, using libsdl1.2debian-pulseaudio as a workaround? sure, that's a *workaround*. it doesn't at all address the fundamental bug. [01:22] im very disappointed in amarok 2.0x [01:22] cjwatson: I don't think many people will look there for what architectures are supported anyway [01:22] dtchen, yes. [01:23] but you guys have nothing to do with the development of amarok [01:23] ajmitch: I'm in no rush; we have 4+ months [01:23] you merely package it [01:23] i still use 1.4 it rocks :D [01:25] another question: Are you going to stick with the cbc-essiv mode for the default crypto installer, or for the next release try the xts-benbi mode (supposed to be more secure, but the module is still experimental) [01:26] i have been using xts-benbi === fagan_ is now known as fagan [01:31] crypt-0: experimental in an LTS is essentially a no-go. === dktrkranz is now known as Guest23053 [01:33] it seems pretty solid, the documentation of cryptsetup says for XTS use : xts-plain but [01:33] > Is the XTS kernel module still experimental? [01:33] It is marked as experimental, but it seems correct and stable. [01:33] > Also, how do you recommend using it for LUKS cypher-name-xts-plain? [01:33] I recommend aes-xts-benbi [01:33] benbi is 'big endian narrow block index', it gives each 16 byte block a [01:33] number. ('plain' is a little endian sector count, which is not standard [01:34] for narrow block cipher modes like lrw and xts) [01:34] Greetings, [01:34] Rik. [01:34] that was an email to Rik Snel [01:35] he manages the XTS kernel module i believe [01:35] and here is another mail [01:35] crypt-0: I'm not really interested in changing it; feel free to take it up with Debian [01:36] cjwatson, inst cbc-essiv secure enough? [01:36] is that what you are saying? [01:36] it is secure and stable enough. [01:36] I'm saying that I'm not interested in changing it, and that you should feel free to take it up with Debian === Guest23053 is now known as dktrkranz [01:37] I do not want to go diving down a crypto rat-hole for ages - I have too much else to do === dktrkranz is now known as Guest35967 [01:37] oh ok [01:38] if somebody else from the d-i team wants to investigate it, determine that it's sound, make sure all the necessary tools support it, do the installer integration, and flip the default, they can feel free [01:38] cjwatson, do you believe cbb-essiv is secure enough for most uses (keep three letter agency out please) [01:38] *cbc [01:38] have I not already sufficiently dodged the question? :) [01:38] hehe [01:39] I don't want to spend the time investigating, and I trust the people who made the decision in Debian [01:39] yeah, after all an experimental kernel module that does crypto math can compromise a encrypted system [01:39] I do not want to make an authoritative statement on something I haven't investigated myself [01:40] so while the mode itself is believed more secure, it is more often from what i read the implementation that breaks. [01:41] and I would much rather simply leave the defaults at the same values they are in Debian, rather than going solo on something that the Ubuntu installer team does not have extensive experience of === Guest35967 is now known as dktrkranz [01:41] that way, at least we have the same problems [01:41] Right. [01:41] IMHO TrueCrypt uses the XTS kernel module [01:42] that's as may be [01:42] i mailed the TrueCrypt developers, with no response. [01:42] wait...thet do use it, along with dm-mod [01:43] but our installer shares really rather a lot more with the Debian installer than it does with TrueCrypt. Like I say, if you really think it's wrong (not just speculating), feel free to contact the Debian installer developers [01:43] because the xts module is never loaded unless i open a TC volume. [01:44] Well, for now as long as the module is experimental, and there no significant attacks on cbc-essiv, there is no rush. On the other hand, if no one uses the module, then it will probably always be experimental. [01:45] So when cbc-essiv attacks come out, users can switch. [01:45] Is it possible to default to cbc-essiv, and at last make XTS an option? [01:46] like "warning xts unsupported" [01:46] like universe repos [01:46] -> d-i developers [01:47] upstream, please [01:47] From what i recall XTS , and a few people using customized crypto installers are the only ones using XTS. [01:47] huh? [01:47] please take your query upstream [01:47] does Debian have an irc channel [01:47] Google [01:47] :P lazy [01:47] but mail will be more productive [01:48] ok [01:48] well i have mails from a lot of developers [01:48] Hi. Is the Packages file in an APT repository supposed to be UTF-8 encoded? [01:48] and would be happy to forward to them to people willing to listen [01:49] I've found a package description that appears to be Latin-1 encoded. [01:49] Nobody's interested in mails from developers saying "use my stuff"; it is self-evident that they think that or they would not be developing it. :-) In order for anyone to be worried about cbc-essiv, you need evidence of cryptanalytic attacks. [01:49] even got a mail from Schneier lol [01:49] or at least sound security research on weaknesses. [01:49] *relevant to the case at hand* [01:50] fbond: that's a bug, yes [01:50] " [01:50] AFAIK, there haven't been new discoveries with respect to the safety [01:50] of CBC. However, as it was never that great in the first place, [01:50] switching to something new is desirable." === DktrKranz is now known as Guest62390 [01:51] cjwatson: But is it a bug in the package? I mean, would Ubuntu retroactively correct Packages.gz for an old package version? [01:51] that is from Clemens Fruhwirth, whom i believe introduced ESSIV to the Linux kernel. [01:51] (The package in question is doc-linux-html-pt in hardy, not hardy-updates.) [01:51] * crypt-0 shuts up === Guest62390 is now known as DktrKranz [01:51] crypt-0: I'm ignoring further discussion on the subject in this channel. Sorry. [01:52] fbond: we wouldn't retroactively correct hardy/Packages.gz, no, and UTF-8-soundness across the board is relatively recent [01:52] cjwatson, Can you point me a little closer to the debian developers than google, anyone specific in mind? [01:52] I already gave you the keywords "Debian installer"> [01:52] crypt-0, usually, they live on the OFTC network :) [01:53] cyphermox: 01:47 but mail will be more productive [01:53] sigh. apparently they don't teach research these days ... off to bed, anyway [01:53] indeed, but the mail is easy to find :) [01:53] cjwatson, good night [01:54] cjwatson: If I'm writing code that parses Packages.gz for older releases, what can I assume about character encodings? [01:54] fbond: nothing, I'm afraid [01:54] cjwatson: Ouch. Okay, thanks. [01:54] fbond: in practice it's probably either UTF-8 or ISO-8859-1, but the odd bit of ISO-8859-2 wouldn't entirely surprise me [01:55] cjwatson: Okay. I'm surprised there's not control field that makes it explicit. [01:55] by the time the problem was recognised it was easier to just switch to UTF-8 [01:56] cjwatson: Okay, makes sense. Thanks for your help. [01:56] though it also wouldn't surprise me if the number of fields that don't match UTF-8 is small enough to special-case them [01:57] Keybuk: Yeah, I'll just try UTF-8, then fall back on Latin-1. After that, I'll give up. [02:06] Keybuk: did MoM fail again, or is it taking a really long time to update? [02:06] IOError: [Errno 13] Permission denied: [02:06] +'/srv/patches.ubuntu.com/unpacked/d/dovecot/1:1.2.8-1/.pc/dovecot-drac.patch/sr [02:06] +c/plugins/drac/Makefile' [02:07] * Keybuk adds dovcecot to the blacklist [02:14] ... permission denied? [02:17] slangasek: yeah [02:17] silly package must have no readable permission on files in its tar file [02:18] which will be a v3-generated tarball, probably related to the quiltiness of it [02:18] bugger [02:18] dovecot is in bzr anyway [02:19] not always [02:19] some upstreams fuck up too [02:19] well, .pc/dovecot-drac.patch/ is fairly telling [02:27] aww [02:27] oem-config kept HAL on the CD [03:12] dtchen, persia, luisbg: could one of you drop cl-pdf from the ubuntustudio-font-meta deps? It's removed from Debian, so I'm removing it from lucid [03:12] slangasek: Sure. I'll do that now. [03:18] cheers [03:22] tjaalton: how close are we to having installable xorg again? === LucidFox_ is now known as LucidFox === dendro-afk is now known as dendrobates === asac_ is now known as asac [06:24] slangasek: looks like it's installable, at least dist-upgrade doesn't want to purge any packages here. the blobs need updates though, and wacom will have to wait until next week [06:26] tjaalton: all the CD builds have been failing because it's not; just got a fresh one on mythbuntu right now [06:26] slangasek: what's missing? [06:27] checking [06:27] I know that the server failed to build on sparc and powerpc, but that shouldn't hold things back? [06:29] tjaalton: xserver-xorg-input-all isn't installable, and that's in the seeds [06:29] morning folks [06:29] tjaalton: not installable because evdev, synaptics, vmmouse all have the wrong ABI, I think? [06:29] and wacom [06:30]