[00:00] <ccheney> when it ate my data was around 2000 i think, and that bug wasn't fixed until around 2007-2008 timeframe
[00:00] <jdong> no, it's not "patched"
[00:00] <jdong> it's worked around.
[00:00] <crypt-0> so it wont eat my data
[00:00] <jdong> no, I never said that
[00:00] <ccheney> raid doesn't protect you from a filesystem eating your data  :)
[00:00] <crypt-0> (the current versions of XFS in 9.10)
[00:00] <jdong> but fundamentally XFS's journal replay strategy is to zero stale data
[00:00] <ScottK> crypt-0: No one with guarantee any file system won't eat your data
[00:00] <ccheney> jdong: oh ok
[00:00] <crypt-0> i know
[00:00] <ScottK> If they do, run.
[00:00] <jdong> ext3's policy is to leave it stale
[00:01] <jdong> because stale is likely correct
[00:01] <jdong> coming from an enterprise background, XFS's policy is that stale data can constitute privacy leaks
[00:01] <jdong> i.e. it belonged to another file in the past.
[00:01] <crypt-0> well i will be creating a new filesystem soon
[00:01] <ccheney> all i remember well was that my fs was filled with a lot of null filled files
[00:01] <ccheney> large chunks of missing data
[00:02] <crypt-0> its EXT3 or XFS....EXT4 just is not there yet.
[00:02] <jdong> 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] <ccheney> more than i would expect from just the journal unless it was bigger than i would expect
[00:02] <jdong> which is the biggest source of the "XFS nulled my data" complaints
[00:02] <ScottK> ext4 is the default on Karmic.  I think it's a reasonable assumption that it was considered reasonably safe.
[00:02] <jdong> that's since then been "worked around" to happen less frequently
[00:02] <ccheney> 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] <jdong> with that said, I do find XFS like ext4, because of delayed allocation, very aggressively uses the writeback cache
[00:03] <jdong> 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] <jdong> but no filesystem makes any sorts of *guarantee* this won't happen.
[00:03] <ccheney> jdong: with the ext4 fix for the desktop issues it probably won't trigger data loss like that though i would imagine
[00:03] <crypt-0> [bad shutdown] im on a smart UPS
[00:03] <maco> since xfs is older, wouldnt it be "ext4, like xfs..."
[00:03] <jdong> ccheney: delayed allocation still applies.
[00:03] <jdong> maco: eh it's a commutative relationship ;-)
[00:04] <jdong> I'm not gonna trace back to the first filesystem to implement delayed allocation
[00:04] <ccheney> jdong: iirc any rename forces a full flush now though, right?
[00:04] <crypt-0> well are you saying i should avoid XFS?
[00:04] <jdong> crypt-0: that doesn't stop system freezes, etc
[00:04] <ccheney> and those seem to happen all the time on desktop apps, heh
[00:04] <jdong> ccheney: rename definitely places a barrier between old and new
[00:04] <jdong> and to cross the barrier a flush is needed, yes
[00:04] <crypt-0> jdong, i know but i have not *ever* had a system freeze with Linux.
[00:04] <jdong> so either the original or the final file will be there, not in between.
[00:04] <jdong> crypt-0: consider yourself very lucky.
[00:05] <jdong> crypt-0: even on servers I manage I've been in the case of needing to hard-power-cycle against my will
[00:05] <jdong> I'm not saying you shouldn't use XFS.
[00:05] <jdong> I had my primary server on XFS for the past 3 years...
[00:05] <jdong> only recently did I switch it to btrfs to contribute to the testing effort.
[00:06] <jdong> note I do not of course recommend users to do this
[00:06] <crypt-0> 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] <jdong> consider yourself lucky then
[00:06] <jdong> particularly on external USB2 drives (which do not respect barriers)
[00:06] <jdong> and on RAID or LVM devices (which do not respect barriers)
[00:06] <crypt-0> 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] <jdong> a bad shutdown on XFS can corrupt its metadata beyond repair.
[00:07] <jdong> crypt-0: I've always considered XFS a stable filesystem
[00:07] <jdong> note the two caveats that I pointed out
[00:07] <crypt-0> what filesystem do you recommend for RAID-1
[00:07] <jdong> delayed allocation <-> writeback data loss; loss of write barriers <-> full filesystem corruption.
[00:07] <crypt-0> i will be using hardware RAID-1 for my next build
[00:08] <jdong> I do not have a recommendation if no corruption / data loss on hard shutdown is your goal.
[00:08] <crypt-0> and XFS will be on a LVM (encrypted filesystem)
[00:08] <jdong> that's simply not possible without hardware battery backed storage controllers
[00:08] <jdong> (at the very minimum; stable software configuration and ECC'ed RAM above that)
[00:09] <jdong> with that said, you should weigh your risks against the benefits
[00:09] <crypt-0> ext3 seems to handle hard shutdowns well.
[00:09] <jdong> it has a 5 second commit flush
[00:10] <jdong> it also uses physical block journaling
[00:10] <crypt-0> 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] <jdong> 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] <jdong> 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] <crypt-0> EXT3 has always been good to me, and so has XFS
[00:12] <jdong> in the past, ext3 has by far been best to me in resilience to abuse
[00:12]  * ccheney bbl
[00:12] <crypt-0> im just wondering , in your opinion is the XFS throughput worth it?
[00:12] <jdong> what XFS throughput?
[00:12] <jdong> depends on what you're doing.
[00:13] <crypt-0> a lot of DVD rips
[00:13] <jdong> I switched AWAY from XFS for performance reasons
[00:13] <jdong> XFS performs extremely well when your data is comprised of large files (>50MB each)
[00:13] <crypt-0> all legal of course, :)
[00:13] <jdong> XFS performs extremely poorly when your data is comprised of a large number of small files
[00:13] <jdong> the latter tended to be my usecase on that server (a build server)
[00:13] <jdong> 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] <crypt-0> well , when i extract a DVD most of the chapters are over 100MB, and the final raw mpeg is 4GB
[00:14] <crypt-0> the ripped version ends up at arounf 2GB
[00:14] <crypt-0> im plaining on bluray rips which will have a considerably larger size
[00:15] <jdong> XFS is a very reasonable filesystem for that
[00:16] <jdong> just keep my caveats in mind.
[00:16] <crypt-0> but i also have about 60GB of music file sizes 2-100MB per song
[00:16] <micahg> maybe that's why my builds take a while on xfs :)
[00:16] <jdong> micahg: rm -rf is a very bad workcase for XFS
[00:16] <jdong> (1) it spends a lot of time rebalancing the B-tree that will eventually be completely gone anyway
[00:16] <micahg> is there a way to shrink xfs yet?
[00:16] <jdong> (2) Nowadays, it flushes barriers (16-32MB of hardware cache) every couple of transactions
[00:17] <jdong> yay, write 8KB of data, flush out 32MB.
[00:17] <crypt-0> since i will be using 64 bit will that help?
[00:17] <jdong> why does that have any impact?
[00:17] <crypt-0> 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] <crypt-0> so thats it, it has no other impact?
[00:18] <crypt-0> i think ill go ext3...
[00:19] <crypt-0> i should get decent read with any FS with raid-1
[00:19] <crypt-0> and decent write with RAID class drives
[00:19] <jdong> you know that XFS is a 64-bit filesystem even on a 32-bit processor right?
[00:20] <crypt-0> 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] <jdong> right.
[00:20] <jdong> but fragmentation wise you DO want an extent-based filesystem
[00:20] <crypt-0> basically, the filesystem can through a LOT more data at the encoder than the encoder can encode.
[00:21] <crypt-0> but EXT4 is so slow
[00:21] <jdong> umm...
[00:21] <crypt-0> and i have not run into frag-related issues with ext3
[00:21] <jdong> so you choose ext3?
[00:21] <jdong> you've got to be kidding me
[00:21] <crypt-0> i have not tested ext4 that much
[00:21] <jdong> ext3's problem with dealing with large files is fragmentation when dealing with large files.
[00:21] <crypt-0> i use it for /boot
[00:21] <jdong> ext4's primary GOAL is to fix that limitation of ext4
[00:22] <crypt-0> ah
[00:22] <jdong> through extents and delay allocation
[00:22] <jdong> so ext4 is ext3 with better handling of large files.
[00:22] <jdong> and support for larger filesystems
[00:22] <crypt-0> most of my experence with EXT4 has been with /boot
[00:22] <crypt-0> i read that all the ext4 extents can decrease entropy
[00:23] <crypt-0> for disk encryption
[00:23] <crypt-0> but, that is probably NSA level shit paranoia
[00:23] <jdong> I do not have good knowledge of the effects of ext4's disk structure on cryptanalysis
[00:23] <jdong> so I cannot answer one way or another to that :)
[00:24] <jdong> 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] <crypt-0> right
[00:25] <cjwatson> so, wait a sec, you tried out ext4 on /boot and then decided it was slow?
[00:25] <crypt-0> like i said its probably NSA level crap
[00:25] <cjwatson> not the best of test cases :)
[00:25] <crypt-0> well i also used it years ago on an external partition
[00:26] <jdong> considering ext4's lifespan is on the order of "year(s)" ago
[00:26] <jdong> for very small instantiations of the plural...
[00:26] <cjwatson> 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] <jdong> and for the majority of that time features like extents and the mballoc werne't implemented...
[00:26] <jdong> I'd say it's time for you to reevaluate ext4.
[00:26] <cjwatson> don't waste time on vague cryptanalytic worries unless you actually have solid evidence
[00:26] <crypt-0> 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] <jdong> I've found its performance with large files to be comparable if not better than XFS
[00:27] <jdong> but XFS' scalability to the horrendous extremes is unbeatable
[00:27] <jdong> and by that I mean things like 20TB filesystems, 1TB files, etc etc etc
[00:27] <jdong> I don't think that's relevant to you
[00:27]  * maco points at dtchen and yells "spook!"
[00:27] <jdong> I will say that XFS's backup tools (xfsdump) and administration/maintenance tools are far superior to ext*'s
[00:27] <jdong> but I also don't see that terribly relevant to your usecase for storing movie rips
[00:28] <crypt-0> yeah
[00:28] <jdong> 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] <crypt-0> and i use LVMS so i can use a LVM snapshot, or a desynched RAID disk
[00:29] <jdong> xfsdump was an instrumental part of that workflow
[00:29] <jdong> for movies, they're very much write-once-change-many, and don't benefit as much.
[00:30] <crypt-0> " 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] <jdong> lol cjwatson is absolutely correct there :)
[00:30] <crypt-0> yes, the TEMPTEST attacks, i dont live in a EMI shielded cage :)
[00:30] <jdong> and along those lines, there's probably a lot more weak links in your crypto setup than predictable filesystem structures
[00:31] <jdong> s/predictable/uniquely identifiable/
[00:31] <dtchen> there are a lot more "efficient" methods, like clubbing you over the head until you cough up the passphrase
[00:31] <crypt-0> yeah
[00:31] <crypt-0> that was my point
[00:31] <jdong> lol and my system sits on my desk in a dorm room
[00:31] <jdong> if you really want my data, come poison my bootloader while I'm in class.
[00:32] <crypt-0> 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] <crypt-0> yeah
[00:32] <chrisccoulson> crypt-0 - i work in an EMI shielded room :P
[00:33] <crypt-0> 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] <crypt-0> so come get me with a hardware keylogger if you want my data :)
[00:35] <crypt-0> disk encryption, with SHA1/DES is probably good enough privacy for what i do.
[00:36] <kees> chrisccoulson: I work in an accidentally EMI shielded room.
[00:37] <chrisccoulson> kees - how come? the room i work in is not accidentally shielded ;)
[00:37] <crypt-0> 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] <chrisccoulson> i spend a lot of time in a RFI chamber at the moment
[00:37] <chrisccoulson> i don't get to see any daylight ;)
[00:37] <crypt-0> 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] <crypt-0> :P
[00:39] <crypt-0> 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] <crypt-0> it would not be used
[00:40] <spm> I think the root of "assume" is "ass, you, me" :-)
[00:40] <crypt-0> "Local man cought using LimeWire  with TEPMTEST attacks"
[00:40] <crypt-0> true.
[00:41] <crypt-0> i do use an LCD with a shielded cable, i consider it sufficient.
[00:41] <crypt-0> or is it not?
[00:42]  * spm has done successful temptest attacks on PC's with no monitor
[00:42] <crypt-0> blah
[00:42] <crypt-0> what of those attacks are standard with music/movies?
[00:43] <crypt-0> the more you know....the more paranoid you get:)
[00:44] <spm> think outside the square. why use technical if simpler physical or personal attacks are cheaper and more efficient
[00:47] <spm> 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] <kees> chrisccoulson: no clue -- i assume the concrete and lead paint contributes.  :)  I get no radio or cell signal in my basement.  :)
[00:49] <chrisccoulson> kees - yes, the lead paint will probably contribute
[00:55] <crypt-0> spm yes, i have talked to people who have worked Fornesics, music/movies is the very last theing thet care about
[00:57] <crypt-0> of course they always want that "example" , but they would probably target someone using less security ( the average Joe filetrader)
[00:57] <spm> well yes. foreign governments and keeping our soldiers alive was more important than a few execs losing a bmw of roll's
[00:57] <spm> s/of/or/
[00:57] <crypt-0> or the 12 year old girls they have been known to targer lol
[00:57] <crypt-0> target
[00:58] <crypt-0> "Sally just got caught using the evil program LimeWire now her family has to pay 100 million dollars muhahaha"
[00:59] <crypt-0> What im saying is "Can my security be beat? Yes." "Will it be as easy as taking my PC? No."
[01:01] <crypt-0> 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] <crypt-0> :P
[01:01] <crypt-0> anyway
[01:02] <crypt-0> even if 20% of my data was 100% predictable, i dont that would lead to successful cryptanalysis
[01:02] <crypt-0> at least, not at this level.
[01:02] <slangasek> ever the innovators, China has recently melded two of their most important industries to create the first tempest-in-a-teapot technology
[01:03] <crypt-0> lol
[01:03] <crypt-0> China broke WPA2 i believe also, as SAH1
[01:06] <crypt-0> I have also heard and read that the MPIAA/RIAA has swiched to badgering ISPs to badger you
[01:06] <crypt-0> eg
[01:06] <crypt-0> "your isp says stop downloading or else:
[01:07] <crypt-0> instead of "you should have stopped downloading, we are coming to milk you for every cent you are wroth"
[01:08] <crypt-0> nevertheless i find Temptest attacks interesting.
[01:08] <spm> why?
[01:08] <crypt-0> well, i am going to be taking Forensics classes, im still a student
[01:09] <spm> it's amusing watching someone play solitaire (badly)
[01:09] <spm> ahh. right.
[01:09] <crypt-0> my major will probably be networking, but Forensics is nice to have if you are network admin
[01:10] <spm> I'd hope not!! :-)
[01:10] <spm> the idea is to ensure you have very little need to do any forensics.
[01:10] <crypt-0> "Boss: "Joe has been looking at porno and motorcycles all day instead of his work, can you prove it?"
[01:11] <spm> that's not forensics. that's boring. yukky; seriously yucky. and tedious.
[01:11] <crypt-0> yeah
[01:11] <cjwatson> it's also a case where you need to make sure you are on very sound legal ground
[01:11] <spm> 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] <spm> exactly
[01:12] <crypt-0> but form what my professors said....you have to prove they were not ding their work
[01:12] <crypt-0> doing
[01:12] <spm> have been pulled in as an expert witness in one case
[01:12] <spm> jurisdiction?
[01:12] <spm> it all depends.
[01:12] <spm> in the case I was involved in; the "porn" was but one plank of a raft of issues.
[01:12] <cjwatson> 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] <crypt-0> so you have to do port mirroring on their port,i assume a wireshark capture file would be enough
[01:13] <spm> the guys dismissal was upheald over a range of issues; not just one.
[01:13] <spm> err what's wrong qith eg proxy logs? or firewall logs? :-)
[01:13] <spm> why make it hard on yourself? :-)
[01:14] <crypt-0> 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] <crypt-0> firewall logs may not be enough
[01:14] <crypt-0> they should, but not everyone in the jury is a tech guru.
[01:14] <spm> like I said. which jurisdiction. it was plenty for a magistrate for an unfair dismissal case here in australia; ymmv.
[01:15] <crypt-0> USA here
[01:15] <spm> and again; it was only a single part of the 2 day hearing
[01:15] <crypt-0> ah ok
[01:15] <crypt-0> well
[01:15] <crypt-0> here
[01:15] <crypt-0> if you are using school/business computers
[01:16] <crypt-0> the AUP is basically: we can monitor what you are doing and will if we wwant
[01:16] <cjwatson> (please don't use the enter key as punctuation.)
[01:16] <crypt-0> cjwatson, sorry. :)
[01:16] <crypt-0>  
[01:16] <crypt-0> :P
[01:16] <cjwatson> note that AUPs are not necessarily in and of themselves legal
[01:17] <spm> yes; huge levels of "it depends" in this area.
[01:17] <cjwatson> just as simply writing something down in a contract doesn't make it enforceable
[01:17] <crypt-0> Right.
[01:18] <crypt-0> spm, Forensics is also useful foe Intrusion detection on the network.
[01:19] <dtchen> 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] <spm> heh. ignoring that the biggest abusers (ie $$ loss) will be your authorised users?
[01:19] <cjwatson> http://en.wikipedia.org/wiki/Workplace_privacy - brief but to the point
[01:19] <cjwatson> dtchen: we're stopping
[01:19] <crypt-0> anyway, i plan on "downgrading" my encrypted root partition to AES128 for speed
[01:19] <cjwatson> dtchen: well - for lucid, anyway. hardy-karmic PPAs will keep building for lpia
[01:19] <dtchen> cjwatson: thanks
[01:20] <ajmitch> 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] <crypt-0> dtchen, yeah pulseaudio has its issues, had trouble with playing UrbanTerror
[01:20] <crypt-0> and the sound
[01:20] <dtchen> crypt-0: that isn't pulse; that's alsa-plugins.
[01:21] <crypt-0> but it is "fixed" in a fourm o found somewhere
[01:21] <dtchen> we don't sync the "hw ptr" properly
[01:21] <crypt-0> oh
[01:21] <crypt-0> wel
[01:21] <dtchen> unfortunately it is *extremely* dependent on the audio hardware and kernel configuration
[01:21] <cjwatson> ajmitch: that'll happen along the line
[01:21] <crypt-0> wait....the fourms said to force it to use pulse
[01:22] <cjwatson> ajmitch: I don't believe it's possible to do it yet, because other parts of the removal are not complete
[01:22] <crypt-0> anyway it works.
[01:22] <dtchen> 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] <crypt-0> im very disappointed in amarok 2.0x
[01:22] <ajmitch> cjwatson: I don't think many people will look there for what architectures are supported anyway
[01:22] <crypt-0> dtchen, yes.
[01:23] <crypt-0> but you guys have nothing to do with the development of amarok
[01:23] <cjwatson> ajmitch: I'm in no rush; we have 4+ months
[01:23] <crypt-0> you merely package it
[01:23] <crypt-0> i still use 1.4 it rocks :D
[01:25] <crypt-0> 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] <crypt-0> i have been using xts-benbi
[01:31] <dtchen> crypt-0: experimental in an LTS is essentially a no-go.
[01:33] <crypt-0> it seems pretty solid, the documentation of cryptsetup says for XTS use : xts-plain but
[01:33] <crypt-0> > Is the XTS kernel module still experimental?
[01:33] <crypt-0> It is marked as experimental, but it seems correct and stable.
[01:33] <crypt-0> > Also, how do you recommend using it for LUKS cypher-name-xts-plain?
[01:33] <crypt-0> I recommend aes-xts-benbi
[01:33] <crypt-0> benbi is 'big endian narrow block index', it gives each 16 byte block a
[01:33] <crypt-0> number. ('plain' is a little endian sector count, which is not standard
[01:34] <crypt-0> for narrow block cipher modes like lrw and xts)
[01:34] <crypt-0> Greetings,
[01:34] <crypt-0> Rik.
[01:34] <crypt-0> that was an email to Rik Snel <rik@snel.it>
[01:35] <crypt-0> he manages the XTS kernel module i believe
[01:35] <crypt-0> and here is another mail
[01:35] <cjwatson> crypt-0: I'm not really interested in changing it; feel free to take it up with Debian
[01:36] <crypt-0> cjwatson, inst cbc-essiv secure enough?
[01:36] <crypt-0> is that what you are saying?
[01:36] <crypt-0> it is secure and stable enough.
[01:36] <cjwatson> I'm saying that I'm not interested in changing it, and that you should feel free to take it up with Debian
[01:37] <cjwatson> I do not want to go diving down a crypto rat-hole for ages - I have too much else to do
[01:37] <crypt-0> oh ok
[01:38] <cjwatson> 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] <crypt-0> cjwatson, do you believe cbb-essiv is secure enough for most uses (keep three letter agency out please)
[01:38] <crypt-0> *cbc
[01:38] <cjwatson> have I not already sufficiently dodged the question? :)
[01:38] <crypt-0> hehe
[01:39] <cjwatson> I don't want to spend the time investigating, and I trust the people who made the decision in Debian
[01:39] <crypt-0> yeah, after all an experimental kernel module that does crypto math can compromise a encrypted system
[01:39] <cjwatson> I do not want to make an authoritative statement on something I haven't investigated myself
[01:40] <crypt-0> so while the mode itself is believed more secure, it is more often from what i read the implementation that breaks.
[01:41] <cjwatson> 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
[01:41] <cjwatson> that way, at least we have the same problems
[01:41] <crypt-0> Right.
[01:41] <crypt-0> IMHO TrueCrypt uses the XTS kernel module
[01:42] <cjwatson> that's as may be
[01:42] <crypt-0> i mailed the TrueCrypt developers, with no response.
[01:42] <crypt-0> wait...thet do use it, along with dm-mod
[01:43] <cjwatson> 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] <crypt-0> because the xts module is never loaded unless i open a TC volume.
[01:44] <crypt-0> 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] <crypt-0> So when cbc-essiv attacks come out, users can switch.
[01:45] <crypt-0> Is it possible to default to cbc-essiv, and at last make XTS an option?
[01:46] <crypt-0> like "warning xts unsupported"
[01:46] <crypt-0> like universe repos
[01:46] <cjwatson> -> d-i developers
[01:47] <cjwatson> upstream, please
[01:47] <crypt-0> From what i recall XTS , and a few people using customized crypto installers are the only ones using XTS.
[01:47] <crypt-0> huh?
[01:47] <cjwatson> please take your query upstream
[01:47] <crypt-0> does Debian have an irc channel
[01:47] <cjwatson> Google
[01:47] <crypt-0> :P lazy
[01:47] <cjwatson> but mail will be more productive
[01:48] <crypt-0> ok
[01:48] <crypt-0> well i have mails from a lot of developers
[01:48] <fbond> Hi.  Is the Packages file in an APT repository supposed to be UTF-8 encoded?
[01:48] <crypt-0> and would be happy to forward to them to people willing to listen
[01:49] <fbond> I've found a package description that appears to be Latin-1 encoded.
[01:49] <cjwatson> 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] <crypt-0> even got a mail from Schneier lol
[01:49] <cjwatson> or at least sound security research on weaknesses.
[01:49] <cjwatson> *relevant to the case at hand*
[01:50] <cjwatson> fbond: that's a bug, yes
[01:50] <crypt-0> "
[01:50] <crypt-0> AFAIK, there haven't been new discoveries with respect to the safety
[01:50] <crypt-0> of CBC. However, as it was never that great in the first place,
[01:50] <crypt-0> switching to something new is desirable."
[01:51] <fbond> cjwatson: But is it a bug in the package?  I mean, would Ubuntu retroactively correct Packages.gz for an old package version?
[01:51] <crypt-0> that is from Clemens Fruhwirth, whom i believe introduced ESSIV to the Linux kernel.
[01:51] <fbond> (The package in question is doc-linux-html-pt in hardy, not hardy-updates.)
[01:51]  * crypt-0 shuts up
[01:51] <cjwatson> crypt-0: I'm ignoring further discussion on the subject in this channel. Sorry.
[01:52] <cjwatson> fbond: we wouldn't retroactively correct hardy/Packages.gz, no, and UTF-8-soundness across the board is relatively recent
[01:52] <crypt-0> cjwatson, Can you point me a little closer to the debian developers than google, anyone specific in mind?
[01:52] <cjwatson> I already gave you the keywords "Debian installer">
[01:52] <cyphermox> crypt-0, usually, they live on the OFTC network :)
[01:53] <cjwatson> cyphermox: 01:47 <cjwatson> but mail will be more productive
[01:53] <cjwatson> sigh. apparently they don't teach research these days ... off to bed, anyway
[01:53] <cyphermox> indeed, but the mail is easy to find :)
[01:53] <cyphermox> cjwatson, good night
[01:54] <fbond> cjwatson: If I'm writing code that parses Packages.gz for older releases, what can I assume about character encodings?
[01:54] <cjwatson> fbond: nothing, I'm afraid
[01:54] <fbond> cjwatson: Ouch.  Okay, thanks.
[01:54] <cjwatson> 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] <fbond> cjwatson: Okay.  I'm surprised there's not control field that makes it explicit.
[01:55] <cjwatson> by the time the problem was recognised it was easier to just switch to UTF-8
[01:56] <fbond> cjwatson: Okay, makes sense.  Thanks for your help.
[01:56] <Keybuk> 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] <fbond> Keybuk: Yeah, I'll just try UTF-8, then fall back on Latin-1.  After that, I'll give up.
[02:06] <slangasek> Keybuk: did MoM fail again, or is it taking a really long time to update?
[02:06] <Keybuk> IOError: [Errno 13] Permission denied:
[02:06] <Keybuk> +'/srv/patches.ubuntu.com/unpacked/d/dovecot/1:1.2.8-1/.pc/dovecot-drac.patch/sr
[02:06] <Keybuk> +c/plugins/drac/Makefile'
[02:07]  * Keybuk adds dovcecot to the blacklist
[02:14] <slangasek> ... permission denied?
[02:17] <Keybuk> slangasek: yeah
[02:17] <Keybuk> silly package must have no readable permission on files in its tar file
[02:18] <slangasek> which will be a v3-generated tarball, probably related to the quiltiness of it
[02:18] <slangasek> bugger
[02:18] <Keybuk> dovecot is in bzr anyway
[02:19] <Keybuk> not always
[02:19] <Keybuk> some upstreams fuck up too
[02:19] <slangasek> well, .pc/dovecot-drac.patch/ is fairly telling
[02:27] <Keybuk> aww
[02:27] <Keybuk> oem-config kept HAL on the CD
[03:12] <slangasek> 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] <persia> slangasek: Sure.  I'll do that now.
[03:18] <slangasek> cheers
[03:22] <slangasek> tjaalton: how close are we to having installable xorg again?
[06:24] <tjaalton> 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] <slangasek> tjaalton: all the CD builds have been failing because it's not; just got a fresh one on mythbuntu right now
[06:26] <tjaalton> slangasek: what's missing?
[06:27] <slangasek> checking
[06:27] <tjaalton> I know that the server failed to build on sparc and powerpc, but that shouldn't hold things back?
[06:29] <slangasek> tjaalton: xserver-xorg-input-all isn't installable, and that's in the seeds
[06:29] <siretart> morning folks
[06:29] <slangasek> tjaalton: not installable because evdev, synaptics, vmmouse all have the wrong ABI, I think?
[06:29] <slangasek> and wacom
[06:30] <tjaalton> slangasek: no they should be built, at least i386 works here
[06:30]  * maco takes this as warning not to upgrade to lucid yet
[06:30] <tjaalton> and wacom was dropped
[06:30] <maco> tjaalton: dropped? for the moment, or...?
[06:31] <tjaalton> maco: yes, the current one doesn't build, and xf86-input-wacom isn't packaged yet
[06:31] <slangasek> tjaalton: ah; my mirror is one revision out of date, let me jab it
[06:31] <tjaalton> maco: dropped from input-all
[06:31] <maco> tjaalton: but will come back, right?
[06:32] <tjaalton> maco: of course, with proper capability-based hotplug
[06:32] <maco> i mean, support for wacom devices isnt just going to go *boom*?
[06:32] <maco> ok
[06:32] <maco> just checking
[06:35] <slangasek> tjaalton: ah; the new xorg is only just installed on amd64 in the current publisher run
[06:36] <tjaalton> slangasek: yeah, I noticed the build-backlog was hours long when I uploaded that..
[06:36] <slangasek> so, all fixed with the next pulse
[06:36] <tjaalton> great
[06:36] <slangasek> (I assume)
[06:36] <siretart> slangasek: if you have a spare minute, could you assist me please with drafting an educated answer on the last paragraph of http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/100538
[06:36] <slangasek> siretart: hmm, probably not this evening, sorry
[06:37] <siretart> okay, thanks anyway
[07:17] <slangasek> ttx: morning
[07:17] <ttx> slangasek: o/
[07:18] <slangasek> ttx: do you know offhand if eucalyptus is moving to cglib 2.2 in the lucid timeframe?  Debian has removed cglib2.1 as obsolete
[07:18] <ttx> slangasek: no I don't. But i can ask.
[07:19] <slangasek> ok - do you need a mail or bug or anything?
[07:19] <ttx> slangasek: I should be able to drive that from here, thx
[07:20] <pitti> Good morning
[08:01] <dholbach> good morning
[08:25] <pitti> cjwatson: would you mind doing a d-i upload against 2.6.32-7?
[08:40] <crypt-0> pitti, i last saw cjwatson speek in the channel at 20:56
[08:40] <crypt-0> it is 03:40 here now
[08:40] <pitti> crypt-0: he'll pick it up when he wakes up
[08:41] <crypt-0> i should probably crawl into bed
[08:41] <crypt-0> pitti, ok :)
[08:42] <crypt-0> pitti, while you are here is it worth installing the 2.6-16 kernel updates
[08:42] <crypt-0> i did not see anything very critical in the upstream changes.
[08:42] <pitti> they'll come through -updates anyway sooner or  later
[08:43] <crypt-0> yes they are waiting to be installed
[08:43] <crypt-0> but i dont like rebooting
[08:43] <crypt-0> maybe ill use Ksplice
[08:43] <pitti> no hurry
[08:44] <crypt-0> http://www.ksplice.com/uptrack/
[08:44] <crypt-0>  Ubuntu 9.10
[08:44] <crypt-0>     	Free for Ubuntu 9.10 Karmic—download now
[08:44] <crypt-0>   
[08:44] <crypt-0>   
[08:44] <crypt-0>      Ubuntu 9.04
[08:44] <crypt-0>     	Free for Ubuntu 9.04 Jaunty—download now
[08:45] <crypt-0> whoh, sorry for that big paste
[08:45] <crypt-0> pitti, i want to test ksplice
[08:46] <crypt-0> babye since it is already in a .deb package bulit for 9.04, 9.10 and "comming soon" for 8.04 it can be added to unverse?
[08:46] <dnivra_> i'm trying to understand how the sudo application works. I compiled it using DEB_BUILD_OPTIONS="noopt nostrip debug" debuild -b -us -uc. but when I run it in gdb, I get the error "cannot find threads: generic error". the binary that i compiled works fine. what is exactly wrong?
[08:46]  * crypt-0 goes to bed
[08:51]  * pitti unbreaks usb-creator
[08:54] <dholbach> kirkland: can you comment on bug 493243?
[09:02] <dnivra_> i'm trying to understand how the sudo application works. I compiled it using DEB_BUILD_OPTIONS="noopt nostrip debug" debuild -b -us -uc. but when I run it in gdb, I get the error "cannot find threads: generic error". the binary that i compiled works fine. what is exactly wrong?
[09:03] <dnivra_> also where exactly is this function "verify_user()" in check.c of source of sudo defined. didn't find it in the source files at all
[10:04] <cjwatson> pitti: yup, will do shortly, thanks
[10:04] <pitti> cjwatson: good morning! thanks
[10:08] <cjwatson> Keybuk: I still can't reproduce that extract failure
[10:08] <cjwatson> Keybuk: ah, but it's not an extract failure, it's files in .pc being unreadable - quilt does like to do that
[10:10] <cjwatson> Keybuk: i.e. nothing to do with the tarballs as such - I wonder if it would be worth just forcing at least mode 444 on everything
[10:10] <cjwatson> (modulo umask)
[10:11] <cjwatson> or, I wonder if .pc should be ignored
[10:11] <cjwatson> it's not as if you actually want to merge it
[10:19] <free> mvo: hey!
[10:20] <free> mvo: just wanted to let you know that I couldn't reproduce that problem with failing APT channels, so it might have been something transient
[10:20] <cjwatson> mdz: do you have the list admin password for developer-membership-board@? it has some things in its queue which are relevant, and my .listadmin.ini doesn't seem to know its password
[10:24] <free> mvo: I have another (unrelated) question though, it looks like the RELEASE_UPRADER_ALLOW_THIRD_PARTY env variable for enabling non-official sources is available only from jaunty on, right? I wondering if there is any chance to have it ever backported at some point
[10:26] <mdz> cjwatson: I don't think so
[10:26] <mdz> cjwatson: iirc Keybuk set it up
[10:29] <mvo> free: hello! thanks for letting me know. backport> yes, but it might be simpler than that, is it for the launchpad PPA ?
[10:29] <mvo> free: what url does that have?
[10:30] <free> mvo: well, in this moment I'd need it for a PPA, to test the upgrade process against our RC landscape-client packages (not yet uploaded to Lucid or SRU-ed)
[10:30] <free> mvo: but in general it's an option we would like to expose to our users in the UI
[10:31] <free> mvo: like a checkbox
[10:31] <free> mvo: https://launchpad.net/~landscape/+archive/ppa this is the PPA with the packages
[10:35] <mvo> free: please try adding https://launchpad.net/~landscape/+archive/ppa  to mirrors.cfg (that is a file in the downloaded dist-upgrader.tar.gz)
[10:37] <free> mvo: thanks for the tip!
[10:38] <mvo> free: with that, it hopefully just works :)
[10:38] <free> mvo: is there are wishlist bug open for backporting the allow_third_party feature? if not I might open one
[10:39] <free> mvo: I guess so, but it involves adding code to the landscape client just for that (which isn't great), and it solves only this case
[10:39] <mvo> free: do you need more than the LP ppa there? i mean, is it useful indepedant of this?
[10:39] <mvo> free: if you need it for more, than just file a bug
[10:39] <mvo> please
[10:39] <free> mvo: hhm, I'm thinking to customers who might need to enable their repos
[10:39] <free> mvo: I don't have any real request though
[10:40] <free> mvo: so it might just be fine actually, because we support it for >=jaunty
[10:40] <free> mvo: I'll probably open a bug if we get some real request from somebody, thanks for now
[10:40] <mvo> free: ok, sounds good
[10:46] <dholbach> hey free
[10:46] <dholbach> free: we didn't manage to meet in Berlin :)
[10:46] <free> dholbach: hey!
[10:46] <free> dholbach: yeah, I'm back to Italy :/
[10:47] <dholbach> free: I hope you had a good time
[10:47] <free> dholbach: pretty much, a love the city, hope to come back soon
[10:47] <dholbach> nice :)
[10:47]  * dholbach hugs free
[10:48] <free> :)
[10:52] <mdz> Keybuk: I just had fsck run on 3 filesystems (/, /home and /space). once / and /home were complete, it went ahead and booted up to gdm while /space continued in the background
[10:52] <mdz> this was way cool. is that how it is supposed to work though?
[10:52] <ion> mdz: That’s intentional. If you want the system to wait for /space’s fsck, add bootwait to its fstab options.
[10:53] <mdz> ion: what I actually want is for squid to wait until /space is mounted before it starts, because that's where my cache lives
[10:53] <mdz> I suppose that will require upstartifying squid
[10:54] <ion> mdz: Yeah. start on all-filesystems, or something like that.
[11:01] <LucidFox> doko, are you planning to sync/merge llvm from Debian? I specifically hope to see the llvm-source package, to sync clang from Debian after that.
[11:09] <pitti> cjwatson: hm, d-i failed with "udev-udeb: Depends: libgudev-1.0-0 (>= 147) but it is not installable"
[11:09] <pitti> weird
[11:10] <cjwatson> pitti: yeah, udev misbuild by the looks of things
[11:11] <cjwatson> surely the udeb shouldn't use gudev :)
[11:11] <pitti> oh, that means that it's looking for a libgudev-1.0-0 .udeb
[11:12] <cjwatson> yes, because objects in udev-udeb are linked against libgudev
[11:12] <cjwatson> this is not supposed to be the case
[11:13]  * pitti builds local udev version and checks
[11:21] <cjwatson> pitti: odd though, I don't see any offending objects there
[11:21] <pitti> hm, neither do I
[11:23] <cjwatson> pitti: I'm happy to figure it out
[11:24] <pitti> cjwatson: I'm almost done with unbreaking X.org, then I can help with this, too
[11:24] <cjwatson> no point in us duplicating work :)
[11:30] <cjwatson> pitti: I see the problem
[11:35] <cjwatson> pitti: (note that my commit doesn't *entirely* fix it, so please don't upload - still working on another bit)
[11:36] <pitti> cjwatson: understood; thanks!
[11:38] <cjwatson> pitti: judgement call: add a new libudev0-udeb package, or remove input_id from udev-udeb?
[11:39] <pitti> cjwatson: I'd say the latter
[11:39] <pitti> we only need it for xorg right now really
[11:39] <cjwatson> oh, I'd been very slightly inclined towards the former on the grounds that we might need it in the future, but not inclined enough to argue the point :)
[11:39] <pitti> unless d-i relies on persistent input device names (which would be very unlikely)
[11:39] <cjwatson> it certainly doesn't right now
[11:39] <cjwatson> ok, I'll remove it
[11:40] <cjwatson> so the previous commit is technically moot for d-i, but correct anyway - otherwise things built against only libudev0 will be pulling in dependencies on libgudev-1.0-0
[11:43] <cjwatson> I dunno, this is irritating to remove in the packaging
[11:43] <davmor2> pitti: I'm having issues on todays live iso getting an ip address from my router
[11:43] <pitti> davmor2: oh, I get that in vmware, too
[11:43] <pitti> so it's not just me
[11:43] <cjwatson> pitti: hmm, sorry to ask a question and then ignore the answer, but I think I'm going to create libudev0-udeb anyway - it's a lot less hassle in the packaging, and will probably avoid problems later
[11:44] <davmor2> pitti: I'll install and see if it's still an issue
[11:44] <pitti> cjwatson: heh; sure, sounds fine
[11:44] <pitti> davmor2: does ubiquity actually work for you? this morning it just crashed, but then I couldn't report it because of the lack of networking
[11:44] <pitti> davmor2: (still on my list to report)
[11:45] <cjwatson> probably no need, should be fixed in bzr, assuming it just crashed immediately
[11:45] <davmor2> no crashed
[11:45] <pitti> cjwatson: some TypeError AFAIR
[11:45] <cjwatson> pitti: yeah, that's fixed
[11:45] <pitti> tried to check a file and probably got None
[11:45] <pitti> nice, thanks
[11:45] <cjwatson> no - it tried to check 'file' (the builtin), rather than 'f'
[11:45] <pitti> aah
[11:46] <StevenK> cjwatson: Bah, I keep doing that too. :-/
[11:52] <davmor2> pitti: someone beat you to reporting it bug 492873
[11:56] <cjwatson> pitti: do you think it'll be ok if I upload udev?
[11:56] <pitti> cjwatson: sure, why not?
[11:56] <cjwatson> pitti: or are you still working on it?
[11:56] <pitti> no, I'm done
[11:56] <pitti> (in fact, I didn't touch it)
[11:56] <pitti> cjwatson: the xorg keyboard stuff was a change in xorg-server
[11:56] <cjwatson> ok
[11:58] <cjwatson> pitti: uploaded; would you do the honours with binary NEW when it arrives?
[11:59] <pitti> my pleasure :) I'll watch it
[11:59] <pitti> won't make the publisher run in 4 minutes though, I'm afraid
[12:33] <pitti> I noticed the buildd situation -- what happened?
[12:33] <pitti> all but one were already disabled over the weekend
[12:33] <ogra> seems libdap kills them with some kind of make -j <hugenumber> call
[12:33] <pitti> and that was tried on all of those?
[12:34] <apw> cjwatson, pitti did i see one of you looking at a bug where the kernel post inst was not being run as a result of lost /etc/something config options, got a reference to the bug?  damned if i can find it
[12:34] <ogra> when they were reset yesterday libdap was scored in a way that it wouldnt be attempted soon
[12:34] <cjwatson> apw: not I, I think
[12:34] <ogra> but apparently it came back
[12:34] <apw> may have been slagasek
[12:34] <ogra> pitti, very likely, yes ...
[12:35] <ogra> its quite odd because we cant build livefses either ... all of the archive is out of sync on arm :/
[12:35] <pitti> apw: hm, I didn't hear that; the closest I've come across recently is that the new kernel wasn't booted because someone edited menu.lst
[12:35] <ogra> and the livefs builder has a mksquashfs bug i cant reproduce without having the packages :/
[12:36]  * pitti hugs ogra
[12:36] <ogra> thanks :)
[12:37] <maco> apw: /etc/kernel-img.conf?
[12:37] <apw> yeah thats the file
[12:38] <maco> apw: bug 470265 ?
[12:38] <pitti> ogra: I tried to revieve imbe; let's see whether that works
[12:38] <pitti> ogra: no, sorry, immediately failed again; seems it needs a reboot or so
[12:38] <ogra> pitti, lamont is on it, the armel machines do reboot
[12:38] <apw> maco, thats the one i was thinking of, thanks
[12:38] <ogra> pitti, they need someone in the DC to power cycle them manually
[12:39] <ogra> (they dont come back automatically, you need someone to press the power button)
[12:39] <amitk> pitti: I would like to get the patches into powertop from upstream. They haven't made a new release yet.
[12:39] <pitti> amitk: in fact, we have had a synced powertop for a very long time, but in late karmic we got a bug fix
[12:40] <pitti> amitk: sure, that seems fine
[12:40] <amitk> pitti: we need some stuff from powertop git to tell us about disk wakeups and HDA audio states
[12:40] <pitti> amitk: I remember that we talked about this at UDS
[12:40] <maco> amitk: oooh lovely
[12:40] <pitti> amitk: no problem at all if they are already upstream
[12:40] <apw> amitk, i think those patches you requested are in the current kernel
[12:41] <amitk> apw: I know. I got those patches merged in the lucid kernel. Now I need to get the tool updated to use the new kernel interface :)
[12:41] <apw> amitk, i know you know you asked for them, i didn't know you knew you had them out there in the wild
[12:41] <amitk> lol
[12:42] <amitk> ok
[12:42] <pitti> amitk: want to do the powertop update yourself?
[12:42] <amitk> pitti: I'll take a stab at it
[12:42] <pitti> amitk: I guess easiest is to "make dist" git head and use that as a new orig.tar.gz
[12:43] <pitti> (easier than backporting patches individually and messing with autoconf)
[12:43] <amitk> pitti: ok, that is exactly the kind of tip I was looking for ;)
[12:43] <pitti> amitk: let me know if you need help (I'll be away for some 30 mins for lunch, but I'll read backscroll)
[12:45] <amitk> pitti: thanks!
[12:47] <lamont> how do I get firefox to either (1) quit dying with SEGV, and/or (2) stop STEALING FOCUS when it pops up a window, finishes rendering a page,  or all those other things that I really don't care that it's done?
[12:48] <ogra> lamont, use chromium instead ?
[12:48] <ogra> :)
[12:48]  * ogra thinks he saw more people with chromium than with FF at UDS
[12:49] <lamont> ogra: uh... no.
[12:49] <cody-somerville> I find chromium has rendering issues.
[12:49] <ogra> not for me ... but the URL bar search function is far behind FF
[12:50] <cody-somerville> Besides having very weird/ugly fonts
[12:50] <ogra> hmm, i cant agree ... but then i use driod as my default font everywhere
[12:51] <cody-somerville> I can't seem to select sans-serif for sans-serif in Chromium.
[12:51] <jussi01> chromium has lots of black boxes when I scroll currently... its fun :)
[12:52] <cody-somerville> and it uses Times New Roman by default for serif and Arial for sans-serif
[12:52] <jussi01> ogra: Have to agree with you about the chromium at uds thing
[12:52] <ogra> cody-somerville, hmm, i just changed it to sans, works fine here
[12:53] <artir> the rendering issues are gone with latest update
[12:53] <cody-somerville> ogra, sans-serif
[12:53] <ogra> cody-somerville, thats the same, no ?
[12:53] <artir> also happened to me, i though it was xorg's problem
[12:53] <cody-somerville> ogra, nope
[12:54] <jussi01> artir: my black boxes? or something else?
[12:54] <artir> yep
[12:54] <ogra> cody-somerville, i dont have sans-serif in *any* font selector ...
[12:54] <cody-somerville> ogra, It shows up in Firefox show.
[12:54] <ogra> cody-somerville, only "Sans"
[12:54] <pitti> amitk: oh, in case you wonder, I'd avise to call the new upstream version 11.1+git20091208
[12:54] <jussi01> artir: updating now, thanks for the heads up
[12:54] <amitk> pitti: ack
[12:55] <artir> also with the chromium-daily ppa? :)
[12:55] <ogra> thats what i use here
[12:55] <artir> it's doesn't look like daily, it's quite stable, no fun
[12:55] <ogra> and apart from the fact that url bar searching doesnt really work with searching for fragments of the url, its working flawless for everything
[12:57] <artir> i only miss greasemonkey
[12:58] <cody-somerville> ogra, http://people.canonical.com/~cody-somerville/sans-serif-firefox.png
[12:59] <ogra> cody-somerville, yes, i belive you, whats the difference ? looks like something hardcoded in FF
[12:59] <ogra> and i would guess it defaults to fontconfigs Sans
[12:59] <cody-somerville> ogra, I dunno but fonts look a hell of a lot better in Firefox then chromium.
[12:59] <ogra> not for me, they really look the same here
[13:00] <cody-somerville> How can Times New Roman look like Serif?
[13:00] <ogra> probably i have better displays :)
[13:00] <cody-somerville> I wouldn't call Times New Romans looking like Serif a trait of a superior display :P
[13:00] <jussi01> ogra: mind if I pm a minute?
[13:01] <ogra> jussi01, i have to be in a meeting now ...
[13:01] <jussi01> ogra: fine, Ill getyou later then :)
[13:01] <ogra> jussi01, fine afterwards though
[13:01] <jussi01> ogra: eta?
[13:01] <ogra> 1h or so
[13:01] <ogra> (or watch #ubuntu.meeting ;) )
[13:02] <jussi01> ok, thanks. get you then :)
[13:02] <ogra> s/./-/
[13:14] <amitk> Keybuk: around? Need to talk about automated boot tests...
[13:36] <Riddell> cjwatson: did your Qt arm changes get anywhere?  I have an upload for Qt due
[13:37] <cjwatson> Riddell: been building all night and still going
[13:38] <cjwatson> Riddell: let me get you a diff ...
[13:43] <pgraner> cjwatson: quick question, just did a upgrade to lucid from Karmic and X failed to update, in face the xwerver-xorg package is no long on they system, known issue?
[13:45] <Wazzzaaa> Im not sure but try: /topic #ubuntu+1
[13:45] <Wazzzaaa> it says something about broken xorg
[13:46] <pitti> pgraner: with dist-upgrade or update-manager? do you have logs in /var/log/dist-upgrade/ ?
[13:47] <cjwatson> xorg was uninstallable for a bit
[13:47] <cjwatson> input/video driver abi desync
[13:47] <cjwatson> not sure if that's fixed yet
[13:47] <pgraner> Pici: dist-upgrade and yes I have the log
[13:47] <pitti> it should be fine right now
[13:47] <seb128> read what dist-upgrade wants to do before give the ack to uninstall things ;-)
[13:47] <mvo> pgraner: could you please mail me the log?
[13:48] <pitti> hah, mvo has a hilight on "upgrade" :)
[13:48] <mvo> I do ;)
[13:48] <pgraner> cjwatson: trying to install xserver-xorg gives me xserver-xorg-input-all & evdev won't/can't be installed
[13:48] <seb128> the issue is that all drivers didn't get rebuild yet for the new xserver...
[13:48] <pgraner> mvo: sure
[13:48] <mvo> this is why I got so many more gray hair :/
[13:48] <pitti> but yeah, with dist-upgrade this will happen very often -- just don't do the upgrade if it wants to remove half of your system
[13:48] <cjwatson> you sure you're up to date? xserver-xorg-input-all isn't listed in the automatic uninstallable check
[13:48] <cjwatson> and what pitti said
[13:48] <mvo> pgraner: all the stuff in /var/log/dist-upgrade/* please :)
[13:48] <pitti> wacom was removed from -all yesterday (which is one uninstallable bit)
[13:49] <cjwatson> and 'chdist apt-get lucid-i386 install xserver-xorg-input-all' works for me right now
[13:49] <pitti> ^ me 2
[13:49] <pgraner> mvo: ok I fibbed, I just went to /var/log/dist-upgrade and the dir is empty
[13:51] <mvo> pgraner: oh, sorry. I misread then. if it was a apt-get dist-upgrade, then there'is no log information on why this was done (u-m keeps a copy of the why)
[13:53] <pgraner> mvo: no worries, looks like switching the mirror from the "fastest" to archive.u.c is fixing it. Mirror lag
[13:53] <mvo> ok
[13:57] <ion> The following packages will be REMOVED: xserver-xorg-input-wacom{a}. I wonder if i could help fix lucid’s wacom support – or is someone working on that?
[14:02] <pitti> davmor2: network-manager problem> ah, got it; it's a dhcp3-client/apparmor problem; sudo aa-complain dhclient3 fixes it
[14:02] <pitti> (I got some violations in dmesg)
[14:02] <pitti> it stumbles over /rofs again
[14:02] <pitti> I thought we disabled AA on the live system for that reason, seems that doesn't work any more
[14:02] <pitti> I'll have a look later on
[14:03] <cjwatson> pitti: ev's already on it
[14:03] <cjwatson> (#ubuntu-installer)
[14:03] <davmor2> pitti: works fine from an alternate install
[14:03] <pitti> ah
[14:03] <pitti> seems that half of the things I plan today are already being looked at :)
[14:03] <davmor2> pitti: surely you're not complaining :)
[14:03] <pitti> heh
[14:04] <pitti> kees, cjwatson, mdz, Keybuk, sabdfl: we'll do a DMB meeting today again?
[14:05] <mdz> pitti, I have the same conflict I had for the previous one :-/
[14:05] <pitti> kirkland: I have no trouble ssh'ing from kvm into the host, but I don't see how to ssh in, since there is no iface configured for this; is there a trick to get a virtual iface on the host?
[14:06] <mdz> pitti, ssh out, port forward back ;-)
[14:07] <kirkland> pitti: hi
[14:07] <kirkland> pitti: what's the ip of your kvm guest?  10.0.2.2?
[14:07] <pitti> kirkland: right
[14:07] <pitti> mdz: nice, trying that
[14:07] <Daviey> pitti: if you are using bridged networking (default), you won't get a dedicated interface tied to it from the host.
[14:08] <ev> pitti: slight correction, discussion on the apparmor thing is in #ubuntu-release
[14:08] <pitti> kirkland: sorry, that's the kvm gateway
[14:08] <pitti> ev: ah, thanks; reading backscroll
[14:08] <siretart`> sudo dhclient eth0 - dhclient: error loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory - is this problem already known? what package is the culprit?
[14:09] <kirkland> pitti: right, so you have to have bridged networking to initiate connections from the outside to get to a guest
[14:09] <siretart`> this is from today's lucid live cd
[14:09] <pitti> siretart`: see above and #ubuntu-release; apparmor getting in the way
[14:09] <kirkland> pitti: there's a couple of ways to do this ...  you can use virt-manager, or virsh
[14:09] <siretart`> pitti: oh, nice. thanks!
[14:09] <kirkland> pitti: or you can use sudo + a bridged networking script i can show you
[14:14] <pitti> mdz: yay, that works
[14:14] <pitti> kirkland: got it to work with -R 2222:10.0.2.15:22
[14:15] <cjwatson> pitti: I think we should have the DMB meeting today anyway - we're accumulating a backlog
[14:15] <pitti> cjwatson: agreed
[14:17] <ScottK> cjwatson: Any news on the overnight qt4-x11 build for armel?
[14:17] <cjwatson> ScottK: still running, was just about to feed Riddell the diff ...
[14:17] <ScottK> OK.  Thanks.
[14:17] <ogra> overnight ??
[14:17] <ogra> heh
[14:18] <cjwatson> not the fastest of builds
[14:18] <cjwatson> Riddell,ScottK: http://paste.ubuntu.com/337275/
[14:18] <ogra> yeah
[14:19] <ogra> that more than half of the official armel buildds are dead wont help either ...
[14:19] <cjwatson> makes no difference in my case, I'm using jocote
[14:20] <ogra> no, but for ScottK it will ...
[14:20] <ogra> it wont build before A1
[14:20] <ScottK> ogra: I was planning on retrying all of KDE as soon as we hit the freeze.
[14:20] <ScottK> ;-)
[14:21] <ogra> ScottK, please dont, we dont even have the basic packageset yet
[14:21] <ScottK> ogra: I was kidding.
[14:21] <ogra> phew :)
[14:21] <ogra> :)
[14:21] <ogra> you got me
[14:21] <ion> Oh, wacom works after all. Nice.
[14:23] <pitti> ion: oh? I thought it wouldn't even install right now?
[14:24] <ogra> pitti, i bet evdev makes it work
[14:25] <ion> I wonder how to check which driver xorg users for wacom?
[14:25] <pitti> ion: should be in /var/log/Xorg.0.log
[14:25] <pitti> ion: right now we don't have udev rules which assign the wacom driver
[14:25] <pitti> so it must be evdev
[14:25] <pitti> so I suppose some features are just missing
[14:25] <cjwatson> james_w: I checked out lp:ubuntu/elilo and ran 'bzr merge-package lp:debian/elilo'. It appeared to work but it only seems to have merged the packaging, not the upstream changes (e.g. 'bzr di -rancestor:lp:debian/elilo' shows a bunch of lines removed from ChangeLog). Did I do something wrong?
[14:26] <ogra> it likely configures it as mouse
[14:26] <cjwatson> james_w: should be repeatable if you go back to r17
[14:26] <pitti> ogra: *nod*
[14:26] <cjwatson> james_w: revision 2.1.4 is marked [merge] but doesn't have any other visible parents in this tree, which is a little alarming
[14:27] <ion> pitti: Yeah, i can’t find the information from the log. http://pastebin.com/f6468dc84
[14:28] <ion> Now to find out what kind of udev rules to add for calibration. I used to have http://heh.fi/hal_fdi_policy/wacom.fdi
[14:29] <ogra> wow, thats impressive
[14:29] <ion> Oh, click doesn’t work with wacom. It’s “unable to handle keycode 333”.
[14:29] <ogra>     2.875489] (II) "Wacom ISDv4 93": Configuring as tablet
[14:30]  * ogra wouldnt have expected that
[14:30] <pitti> ion: are you using the karmic/lucid -wacom package or xorg-edgers?
[14:30] <pitti> it seems to recognize the tablet fine by and large
[14:30] <ion> pitti: I’m using lucid, and the latest upgrade deleted the -wacom package.
[14:31] <pitti> ion: oh, btw, would you mind doing "udevadm info --export-db" and put it into a pastebin?
[14:31] <pitti> ion: I'm curious whether my input_id udev bit detects the tablet as such
[14:31] <ion> pitti: http://pastebin.com/faecdfef
[14:32] <pitti> ID_INPUT_TABLET=1
[14:32] <pitti> perfect
[14:32] <pitti> ion: cheers
[14:32] <pitti> x11_driver=evdev
[14:32] <pitti> yup, evdev
[14:32] <ion> Ah
[14:33] <pitti> ion: see /lib/udev/rules.d/66-xorg-synaptics.rules
[14:34] <pitti> ion: you can use the very same x11_options as in the fdi file, and select by ENV{ID_INPUT_TABLET}=="?*"
[14:34] <pitti> synaptics did the same
[14:34] <ion> Ah, thanks. I was just about to ask if ENV{x11_options.Foo} is supported, didn’t notice the synaptics file.
[14:35] <pitti> ion: in theeeory it should work
[14:35] <pitti> ion: but I assume that it'll only actually work with the wacom driver?
[14:35]  * pitti has no clue about wacom, sorry
[14:36] <pitti> kees: you're chairing DMB today?
[14:37] <ion> Ah, good point.
[14:38] <ion> So, Option "Calibration" "min-x max-x min-y max-y" for evdev. Let’s try that.
[14:41] <pitti> xorg.conf FTW: )
[14:41] <kirkland> pitti: yeah, that's also good
[14:48] <tjaalton> ogra: btw, what were the issues with using evdev for touchscreens? IIRC calibration was one, or a lack of a tool for that?
[14:48] <ogra> tjaalton, evdev only works with touchscreens that are supported by udbtouchscreen in the kernel
[14:48] <ogra> *usbtouchscreen
[14:48] <ogra> there are only very few
[14:49] <tjaalton> hmm
[14:49] <tjaalton> ok
[14:49] <ogra> usbtouchscreen sets a specific TOUCHSCREEN parameter on the device afaik
[14:49] <tjaalton> how does evtouch make it work=?
[14:49] <ion> pitti: http://heh.fi/xorg/udev/66-xorg-wacom.rules handles calibration. Now if click only worked. :-)
[14:50] <ogra> it hooks in on a higher level
[14:50] <ogra> though thats obsolete anyway now that hal is gone
[14:50] <pitti> ion: sweet
[14:51] <pitti> ion: out of interest, how did you figure out the values? is there a program for it?
[14:51] <pitti> ion: do you see anything in xev if you click?
[14:51] <tjaalton> ogra: do the non-usb devices show up in udev?
[14:52] <ion> pitti: wacom-tools has wacomcpl which would handle calibration graphically, but it has been broken since the HAL migration. I just found the values with manual experimentation.
[14:52] <pitti> bryce, tjaalton: I'm actually quite surprised that waco mdevies c already work so well with -evdev (see  ion ^); so the wacom driver just adds some extra functionality like those clicks, etc.?
[14:52] <ogra> tjaalton, depends ... non USB as in serial surely dont, non USB as in PS/2 depend on the driver ...
[14:52] <tjaalton> pitti: yes, evdev includes some support but wacom has all the bells and whistles
[14:53] <ogra> tjaalton, all touchscreens i own are usb ones but not supported by usbtouchscreen ... they just show as /dev/input7eventX
[14:54] <ion> pitti: Nothing from xev, just (WW) "Wacom ISDv4 93": unable to handle keycode 333 in Xorg.0.log.
[14:54] <tjaalton> ogra: so that's a kernel bug then?
[14:54] <pitti> ion: so I guess that counts as "bells and whistles" then
[14:54] <ogra> not sure
[14:55] <ion> 331 for the second button, which is mapped to middle mouse button by default in the wacom driver.
[14:55] <ogra> i donbt know if the devices *can* even be supported by usbtouchscreen
[14:56] <ion> The default calibration for the stylus panel is almost correct by default. The default calibration for the touch panel seems to be a copy of the stylus panel calibration, and it needed a big change.
[15:03] <tjaalton> ogra: apparently it supports at least serial penmount devices
[15:03] <tjaalton> so it's not just usb
[15:04] <ogra> you mean evtouch evdev or what ?
[15:04] <tjaalton> the kernel
[15:04] <tjaalton> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/input/touchscreen/Kconfig;h=8cc453c85ea704d42ee8411d232c31193e8212e1;hb=baf4974e496957681403d4bf74a3274ed3f85277
[15:05] <tjaalton> anyway, gotta run
[15:06] <ion> pitti: Is evdev able to provide click pressure information? If not, that’s an essential functionality provided by the wacom driver.
[15:06] <robbiew> ev: ping
[15:07] <pitti> ion: in theory yes (there's an ABS_PRESSURE value)
[15:07] <pitti> ion: in practice, no idea
[15:07] <pitti> it should be like an axis
[15:07] <ev> robbiew: pong; home
[15:08] <ion> pitti: How about tilt? My wacom doesn’t provide that information, just curious.
[15:09] <pitti> ion: all I can say is that the evdev interface defines ABS_TILT_{X,Y}
[15:09] <pitti> but of course it's up to the driver to actually implement it
[15:10] <ion> Yeah, the interface was what i meant. As long as the interface supports it, it shouldn’t be too big an issue to implement the missing functionality in the evdev driver. It’s just data that comes from /dev/input/eventN in addition to position information etc.
[15:15] <ion> Yay for MPX. Now if my window manager just supported it. :-P
[15:25] <apw> mvo, as you probabally realised my update-manager -d upgrade completed fine ...
[15:29] <mvo> apw: great, thanks
[15:34] <pgraner> pitti: apport-collect just crashed
[15:44] <Kano> the current live image is really funny... did somebody try: sudo dhclient?
[15:44] <Kano> libc.so.6 is not found
[15:44] <pitti> pgraner: any details? screen output, etc.?
[15:44] <pitti> Kano: already being discussed and in progress
[15:48] <bdrung> mdz: with with tools can i readout the acpi sensor data?
[15:50] <mdz> bdrung: yes, there are procfs and sysfs interfaces
[15:59] <Al2O3> anyone here a USB PPC on mac developer?  I have a question or two.
[16:08] <pgraner> pitti: sorry got distracted here you go: http://pastebin.ubuntu.com/337368/
[16:10] <pitti> pgraner: ah, that's actually bug 385811
[16:12] <hedkandi> yo!
[16:12] <hedkandi> hi there is cjw around?
[16:12] <hedkandi> cjwatson: hello!
[16:12] <cjwatson> hedkandi: hey, you left before I could correct my mistake last night
[16:13] <hedkandi> sorry!
[16:13] <hedkandi> what's the latest version?
[16:13] <cjwatson> hedkandi: two paragraphs back in the standard, section 6.5.7 para 1
[16:13] <cjwatson> hedkandi: "If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined."
[16:14] <cjwatson> hedkandi: thus, n >> 32 when n is a 32-bit type is simply invalid C, and the compiler is entitled to do anything it likes
[16:14] <hedkandi> exactly
[16:14] <hedkandi> that is what I was seeing
[16:14] <cjwatson> so the right answer is, don't do that :)
[16:14] <hedkandi> I was actually getting n>>(m%32)
[16:15] <LaserJock> is there anybody from the CC around?
[16:15] <hedkandi> which is another way of writing n>>(m&0x1f)
[16:15] <Pici> LaserJock: #ubuntu-community-team is usually where they hang out.
[16:15] <hedkandi> cjwatson, well it's interesting
[16:15] <LaserJock> Pici: ah, awesome, thanks
[16:16] <hedkandi> cjwatson, I didn't expect that, I've always assumed that you get 0's as you initially stated
[16:16] <hedkandi> cjwatson, but you don't
[16:16] <hedkandi> cjwatson, I notice you didn't know this gotcha either.
[16:17] <cjwatson> hedkandi: not offhand, I outsource that sort of knowledge to the standard
[16:17] <hedkandi> I presume that the C99 standard is the same as C++
[16:17] <cjwatson> you presume incorrectly!
[16:17] <cjwatson> C99 is the 1999 revision of the C standard
[16:17] <hedkandi> I outsource that kind of knowledge
[16:17] <cjwatson> it isn't C++
[16:17] <cjwatson> :-)
[16:17] <hedkandi> so what does the C++ standard say?
[16:18] <hedkandi> does gcc run to the c99 standard?
[16:20] <hedkandi> cjwatson, I notice you run the "ubuntu-devel" list
[16:24] <hedkandi> where's he gone?
[16:24] <cjwatson> yeesh, I do several things, not just sit by #ubuntu-devel ;-)
[16:24] <ScottK> Probably busy doing actual work.
[16:25] <cjwatson> if you install the gcc documentation package, the info documentation has a lot of stuff about how gcc follows standards. the answer is not straightforward
[16:25] <cjwatson> I am not a C++ standards person, and have no particular desire to become one :)
[16:28] <mdz> kees, cjwatson, pitti, Keybuk, sabdfl: http://pastebin.com/f653dfa1c
[16:28] <hedkandi> cjwatson, I was just installing ubuntu and it says in the installation
[16:28] <mdz> (please review)
[16:28] <hedkandi> "let us know about your ubuntu experience: ubuntu.com/community"
[16:29] <hedkandi> and I have been to that url, and I can't find any way to "let us know about your ubuntu experience"
[16:29] <mdz> that's not an ideal link for feedback
[16:29] <hedkandi> mdz, well that's not my fault is it?
[16:29] <mdz> hedkandi: nobody said it was, relax :-)
[16:29] <pitti> mdz: looks great, thank you
[16:30] <hedkandi> It also says "we want ubuntu to work as well for you as possible"
[16:30] <hedkandi> hahaha
[16:30] <hedkandi> but seriously....
[16:30] <hedkandi> cjwatson, how shall I "let us know about your ubuntu experience"
[16:31] <cjwatson> I think that that text is a bug
[16:31] <hypera1r> nothing is bug free nowadays eh
[16:31] <cjwatson> (I didn't write it)
[16:32] <hedkandi> okay I'll file it as a bug then
[16:32] <hedkandi> in launchpad, and I'll say you agree it's a bug
[16:32] <cjwatson> the correct package would be ubiquity-slideshow-ubuntu
[16:33] <cjwatson> hedkandi: that said, at the left of that page, there's a link labelled "Report a Problem"
[16:34] <hedkandi> indeed and it sent me on to ubuntu-devel mailing list which is run by cjw
[16:35] <cjwatson> I moderate that list, yes
[16:35] <hedkandi> so would you like me to "let us know about your ubuntu experience" on that list then?
[16:35] <cjwatson> but the first link there ("bug reporting tutorial") has directions on reporting bugs
[16:36] <cjwatson> no; read the text around the links
[16:36] <hedkandi> ok
[16:36] <cjwatson> "Features and policy discussions should be discussed on ...", "Development ideas should be discussed on ..."
[16:36] <cjwatson> the basic problem is that people have lots of different kinds of feedback, not all of which are appropriate for a single place
[16:40] <hedkandi> well what category would you put "let us know about your ubuntu experience in" then?
[16:41] <hedkandi> I'm just doing what I was asked to do by the ubuntu installer
[16:41] <geser> is sync processing somehow on hold? (or I'm just impatient?)
[16:41] <hedkandi> More specifically, I'm asking "how do I let them know about my ubuntu experience"?
[16:42] <hedkandi> well you can think about that.
[16:43] <hedkandi> I have a different problem to ask about.
[16:43] <hedkandi> CHANGE OF TOPIC
[16:43] <hedkandi> I just installed package grub from karmic, and I think I have a bug in it
[16:44] <hedkandi> I'll put it in a pastebin
[16:44] <geser> is there a way to figure out why a package got demoted to universe? (before I file a bug to move it back as it's needed as a build-dependency in main)
[16:45] <hedkandi> http://pastebin.com/d1b5dc56b
[16:45] <hedkandi> it doesn't seem to operate
[16:52] <cjwatson> geser: not in general - it's usually just because it fell out of the seeds
[16:53] <cjwatson> wow, hedkandi is the least patient person ever
[17:13]  * cjwatson observes a file called ;! added in ubuntu-meta 1.175, and wonders if pitti is engaging in some interesting developer security experiments? :-)
[17:13] <pitti> cjwatson: argh, looks like some vim spewage
[17:14] <pitti> the kind of thing that mistyping :w! :q would leave behind or so
[17:14] <cjwatson> yeah :) I'm nuking it
[17:14] <cjwatson> I do that kind of thing all the time, really
[17:14] <pitti> thanks for cleaning up :)
[17:45] <kees__> mdz: DMB email looks good to me
[17:46] <dmb> ?
[17:46] <dmb> can i help you sir?
[17:46] <mdz> dmb, different DMB, I'm afraid
[17:46] <dmb> :P
[17:46] <mdz> cjwatson, any comments on the developer membership board email?
[18:01] <james_w> urgh, cjwatson: thanks for your bug report. Nasty bug.
[18:03] <cjwatson> james_w: do you want it as a proper bug somewhere?
[18:03] <james_w> cjwatson: just filing it myself
[18:04] <cjwatson> ah, thanks, sorry
[18:04] <james_w> unless you want the karma?
[18:06] <james_w> bug 494123
[18:08]  * apw tried to update and finds a collision between kdelibs5 and ibnepomukqury5
[18:13] <cjwatson> james_w: I will live without :)
[18:13] <james_w> cjwatson: you could fix it, that probably gets more karma ;-)
[18:14] <cjwatson> ok, I'll have a look when I have some network bandwidth again
[18:16] <james_w> nah, I was just kidding
[18:16] <james_w> tests are running now to confirm the one-line fix passes
[18:17] <ccheney> yipee, i just read about the new feature in 2.6.32 making it 'slower' but causing systems from completely freezing on write
[18:17]  * ccheney was having that problem with karmic last night
[18:18]  * ccheney may upgrade his systems to lucid soon in that case
[19:47] <Keybuk> pitti: I've noticed one thing since the HALsectomy of X
[19:47] <Keybuk> when resuming from suspend, I can type my passphrase *straight away*
[19:47] <Keybuk> no silly 2-3s of no input devices
[19:49] <mneptok> "I'm sorry, Dave. I can't locate the keyboard right now. Why don;t you take a stress pill?"
[19:54] <slangasek> Keybuk: yes, this is an expected side-effect and the reason that I was nagging bryce as actively as I was ;)
[19:54] <ogra> do we need to add a "sleep 3" to not trash user experience here ?
[19:55] <slangasek> God no
[19:55] <ogra> :)
[19:57] <Keybuk> slangasek: though I have noticed xkbcomp has come back
[19:57] <slangasek> oop
[19:57] <slangasek> s
[19:58] <slangasek> Keybuk: hey, so I've got a solution to rc2 not waiting for localhost
[19:58] <slangasek> and it's fugly
[19:58] <slangasek> do you want to review it before I commit to bzr? :)
[19:59] <Keybuk> sure
[20:05] <slangasek> Keybuk: http://paste.ubuntu.com/337524/
[20:05] <Keybuk> slangasek: will fail to switch runlevels ever again
[20:06] <Keybuk> as each runlevel change will spin waiting for the loopback to come up
[20:06] <Keybuk> (why the pre-start btw?)
[20:06] <slangasek> Keybuk: no, that's precisely what the pre-start addresses... :)
[20:06] <Keybuk> how does the pre-start address that?
[20:06] <Keybuk> it doesn't do anything
[20:06] <slangasek> one job to capture the loopback event and wrap it as a job status; the other job watches for this job to be up and doesn't continue until it is
[20:06] <Keybuk> it's the same as not having one
[20:07] <Keybuk> though your sick and twisted idea, gives me a better one
[20:07] <slangasek> uhoh :)
[20:08] <syn-ack> Alright, lets give this another try, shall we?
[20:09] <Keybuk> hmm, no, my idea doesn't work either
[20:10] <Keybuk> why not add "and net-device-up IFACE=lo" to the rc-sysinit.conf file ?
[20:10] <slangasek> Keybuk: do you understand what I'm doing here, then?  I haven't changed the 'start on' condition, so runlevel changes will still work, they just all wait until loopback is started before processing anything
[20:10] <slangasek> hmm
[20:10] <Keybuk> slangasek: yes, though you don't need that pre-start at all
[20:10] <Keybuk> slangasek: but I don't want to do it that way, the entire point is to get rid of sick while loops like that
[20:11] <slangasek> what would you do instead of the pre-start?
[20:11] <Keybuk> slangasek: nothing
[20:11] <slangasek> yes, I realize that's the /point/, but it doesn't /work/ :)
[20:11] <slangasek> looking at the rc-sysinit, though
[20:11] <syn-ack> Bingo
[20:11] <slangasek> I think the reason I avoided that was that conceptually, rcS should /not/ block on loopback
[20:11] <syn-ack> jjohansen, Workie workie
[20:11] <Keybuk> slangasek: in practice it probably should
[20:12] <Keybuk> since bringing up the loopback used to be one of the very first things we did in rcS
[20:12] <Keybuk> so things in rcS probably assumed it
[20:12] <slangasek> I haven't found anything that does; but if you prefer that, I think it's an acceptable approximation
[20:12] <Keybuk> yeah I much prefer that
[20:12] <Keybuk> aside note, all processes are optional in Upstart
[20:13] <Keybuk> you can have a job that just has "start on ... " and "stop on ..."
[20:13] <jjohansen> syn-ack: good
[20:13] <slangasek> Keybuk: ah, ok
[20:13] <syn-ack> jjohansen, Thanks again, if you'd like I don't mind testing out your mainlines.
[20:13] <Keybuk> (or just "description" if you really like <g>)
[20:14] <jjohansen> syn-ack: I'll take all the testing I can get
[20:14] <jjohansen> thanks
[20:14] <syn-ack> Good deal. I have to thank Paul van der does for pointing me to you.
[20:17] <jjohansen> ah, nice to know.  Just poke me if you hit any problems
[20:17] <slangasek> Keybuk: ok, will test to confirm and push to bzr (and for SRU)
[20:17] <ion> Or just an empty file. :-P
[20:18] <Keybuk> ion: I don't think it allows an empty file
[20:18] <ion> Oh, ok
[20:19] <Keybuk> it might
[20:19] <Keybuk> apparently it does
[20:19] <Keybuk> shows what I know ;)
[20:39] <apw> slangasek, thanks for the feedback on the nfs-kernel-server patch.  i've updated the patch and attached it to the bug.  perhaps you could check it over at your leisure: bug #493145
[20:56] <bgamari> Shouldn't gfortran now be an alternative for f77?
[20:56] <bgamari> If I'm not mistaken, g77 was deprecated in favor of gfortran
[20:57] <jdstrand> slangasek: hey-- I've got an ntp security update I'd like to upload to lucid. should I wait til friday or can I still get it in?
[21:46] <slangasek> apw: just to be sure - "2005" means this symbol is definitely present in the hardy kernel?  (Have you checked this?)
[21:46] <apw> i have not checked ... /me looks
[21:47] <slangasek> jdstrand: ntp> looks like a good thing to have in ASAP, please go ahead (if it's going to get done today)
[21:48] <apw> slangasek, the commit which makes that variable a global was in v2.6.15-rc1
[21:48] <slangasek> ok, cool
[21:48] <apw> though i wasn't expecting that change to go back before lucid
[21:48] <apw> ahh debian?
[21:50] <slangasek> apw: debian; and having the kernel server not fail to restart during package upgrades from hardy
[21:50] <slangasek> s/kernel/nfs/
[21:51] <apw> yeah sneaky
[21:52] <jdstrand> slangasek: oh yes, it'll be done today. it's... uploaded just now :)
[21:52] <jdstrand> slangasek: thanks!
[21:57] <slangasek> apw: uploaded, thanks!
[21:57] <apw> slangasek, thank you
[22:52] <jcastro> chrisccoulson: thanks for pointing the transmission dev to me for bug control.
[22:52] <chrisccoulson> hey jcastro
[22:52] <chrisccoulson> did he contact you then?
[22:52] <jcastro> yep, I got him squared away
[22:53] <chrisccoulson> i just suggested yesterday that he should perhaps apply now :)
[22:53] <jcastro> already approved him based on his history
[22:53] <jcastro> I have an unrelated question for you since I have you here.
[22:53] <chrisccoulson> jcastro - excellent, thanks :)
[22:53] <chrisccoulson> fire away ;)
[22:53] <jcastro> I have an upstream that depends on hal, I would like to point him in the right direction to move away from hal, I need to point him to ... ?
[22:54] <chrisccoulson> it depends what it uses HAL for
[22:54] <jcastro> detecting cameras, the upstream is Shotwell
[22:54] <Amaranth> gphoto?
[22:54] <jcastro> http://yorba.org/shotwell/ these guys
[22:55] <chrisccoulson> it could possibly use gphoto for accessing cameras
[22:55] <chrisccoulson> but GVFS already has a gphoto backend, making camera devices available via GIO (which is what f-spot does, I think)
[22:58] <chrisccoulson> it seems that f-spot can also access cameras directly via gphoto
[23:01] <ccheney> so if you don't want people filing bugs on your ppa it won't show your ppa at all?
[23:01]  * ccheney is confused
[23:02] <ccheney> ah nm it calls it 'external downloads' now apparently
[23:02] <jcastro> ccheney: are you back on OOo this cycle?
[23:02] <ccheney> jcastro: yea
[23:02] <seb128> jcastro, you are a C# hater aren't you? ;-)
[23:02] <seb128> jcastro, trying to get f-spot replaced now? ;-)
[23:02] <jcastro> OOo upstream report is kind of hurting
[23:02] <jcastro> seb128: no, I met them at guadec and they want to get into universe. :D
[23:02] <seb128> oh good
[23:03] <jcastro> seb128: have you tried it lately? they've really come along
[23:03] <jcastro> and gthumb has been pretty brutal now too
[23:03] <seb128> dunno if you have seen this guy suggesting replacing f-spot for lucid
[23:03] <jcastro> I saw the thread.
[23:03] <seb128> no I didn't
[23:03] <seb128> I should
[23:03] <seb128> but same reply than for banshee
[23:03] <ccheney> jcastro: yea i need some community people to help with OOo, have lots of stuff to do and several hundred new bugs as well
[23:03] <seb128> now is not good time for tech changes
[23:03] <chrisccoulson> i have to admit defeat now, and say that i don't know if you can use gphoto for detecting camera devices, or whether you need to use some other mechanism
[23:03] <jcastro> I appreciate the passion but tbh this kind of thing needed to be done during UDS.
[23:03] <jcastro> I agree
[23:04]  * ccheney will be working on firefox as well this cycle
[23:04] <jcastro> chrisccoulson: I'll settle for telling them to ask someone at GNOME what to do. :D
[23:04] <jcastro> ccheney: let's link up tomorrow, I'd like to help round people up
[23:04] <chrisccoulson> jcastro - gphoto is the safe option, i'm sure
[23:04] <chrisccoulson> and gvfs can mount these cameras anyway :)
[23:04] <jcastro> seb128: I will respond to them after I respond to the shotwell guys
[23:05] <ccheney> jcastro: ok
[23:07] <jcastro> seb128: tbh a healthy photo deathmatch for +1 would be great
[23:07] <chrisccoulson> heh, gksudo doesn't like the client-side decorated GTK
[23:07] <seb128> chrisccoulson, somebody commented on the bug saying that too
[23:08] <seb128> chrisccoulson, did you run into the issue or just read the bug comment?
[23:08] <chrisccoulson> ah, i haven't checked that yet
[23:08] <chrisccoulson> gksudo crashes with a BadWindow X error
[23:08] <seb128> kenvandine, ^
[23:08] <seb128> rickspencer3, ^ not pushing client side = good move
[23:08] <chrisccoulson> i havent looked at it further yet, as I've got other stuff I need to get done first
[23:08] <chrisccoulson> yeah, it seems like it's a bit too crack-ful right now
[23:08] <rickspencer3> yeah
[23:09] <rickspencer3> I would have thought that the developers had tested it a tad more by now
[23:09] <rickspencer3> but I guess that's why you need breadth
[23:09] <rickspencer3> anyway, PPA and call for testing was certainly the right call
[23:09] <chrisccoulson> definately
[23:09] <chrisccoulson> if only there was a good venue for testers to report bugs to PPA packages :)
[23:10] <seb128> chrisccoulson, how come we are not using #ubunt-desktop btw?
[23:10] <seb128> #ubuntu-desktop
[23:10] <seb128> bratsche is there
[23:10] <chrisccoulson> seb128 - good question
[23:10] <chrisccoulson> i've got no idea how i ended up in here ;)
[23:10] <seb128> it's all jcastro's fault
[23:10] <chrisccoulson> lol
[23:10] <seb128> I though we were on #ubuntu-desktop
[23:10] <chrisccoulson> me too
[23:11] <jcastro> me three
[23:11] <seb128> ;-)
[23:16] <ccheney> grr ppa description field now strips out all returns. :(
[23:16] <ccheney> when editing it shows them but strips them for display
[23:17] <ccheney> er not exactly, it seems to have non-determinstic behavior
[23:17] <ccheney> sometimes it displays it wrong without the returns for some reason
[23:18]  * ccheney stops looking at it before it breaks again
[23:28] <maxb> Whenever update-manager runs debconf, I get an error: "Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit ...." - can anyone point me in any useful debugging avenues?
[23:33] <kees> james_w: the gawk bzr history seems broken (it does not show my upload for karmic) ...
[23:33] <james_w> kees: gawk had problems importing later versions
[23:34] <james_w> so it's out of date
[23:34] <kees> james_w: how do I detect/report these kinds of things?
[23:35] <james_w> http://package-import.ubuntu.com/failures/.bzr/failures/ shows the current list of failures
[23:35] <james_w> reporting a bug on the LP 'udd' project will get me to look at it though
[23:36] <dipponaught> how do i use apport-retrace without logging into launchpad (so theres no "mess ups")?
[23:38] <kees> james_w: ok, next up, "john" is not on that list, but fails to get anything to merge from squeeze.  :)
[23:39] <maxb> james_w: Also, almost all of the zero-byte files have gone... except python-defaults. What's the case there?
[23:40] <james_w> maxb: I told it to import them all, lool has asked me to do something special with python-defaults
[23:40] <james_w> he has some more debian history, so I'm going to do that one a bit more by-hand
[23:40] <james_w> was that the one that you had created -unofficial branches for?
[23:41] <maxb> yes
[23:41] <maxb> hence being quite interested in some official ones :-)
[23:53] <james_w> kees: john will be available to merge in a few minutes
[23:53] <james_w> apologies for the hassle
[23:56] <kees> james_w: np, when I looked at it closely, it's a sync.
[23:56] <kees> james_w: how about "smarty" ?
[23:56] <kees> also not listed in failures.
[23:56] <james_w> same issue?
[23:56] <james_w> i.e. debian out of date, not Ubuntu
[23:56] <kees> yeah
[23:57] <kees> the merge-package reported "ERROR: Nothing to merge."
[23:59] <james_w> kees: smarty will be available for merge in a few