[12:24] <xivulon> hi cking,
[12:24] <xivulon> thanks a lot, that looks like great work
[12:24] <xivulon> I replied in #204133
[12:28] <cking> xivulon: I added the syncs on the loopback so that ext3 dirty writes are forced through to the ntfs below. Without it, there will be latency between ext3 writes and the final write to the device
[12:29] <cking> xivulon: The ntfs-3g debdiffs need pushing into Intrepid too. Not sure if that's my domain.
[12:32] <xivulon> cking, for intrepid I think the best route is to have the patch upstream directly
[12:32] <xivulon> I have already notified szaks
[12:32] <xivulon> szaka
[12:32] <cking> xivulon: Thanks - that makes my life easier :-)
[12:33] <cking> xivulon: Can you take it from here - do some testing on a Windows box and verify it works 100% correctly - and then see if the patch goes upstream too?
[12:33] <xivulon> as for nested writes, aren't only the journal flushes relevant? I would assume that once the nested ext3 tries to write to the journal it will go through ntfs-3g which will in turn writ to disk
[12:33] <xivulon> that is whether the nested ext3 is mounted with -o sync or not
[12:34] <xivulon> but provided that ntfs-3g is mounted with -o sync
[12:34] <xivulon> or at least that is my understanding
[12:35] <xivulon> cking, sure I will do the testing, and modify related packages (lupin/wubi/initramfs accorddingly)
[12:35] <xivulon> only need clarification on the above question
[12:36] <cking> xivulon: ext3 journal writes will be flushed straight through to the device if ntfs-3g has the -syncio mount option. However, if you want extra resiliance to make sure writes get flushed immediately then I recommend -o sync on the loop too
[12:36] <cking> It's a kind of performance vs reliability tradeoff 
[12:37] <xivulon> any idea of the performance hit for that?
[12:38] <cking> My tests showed -o sync on the loop was 1/3 to 1/2 slower. But I did just raw block write tests using dd. Normal usage may differ.
[12:39] <xivulon> hm so it's on the heavy side
[12:39] <cking> cking: A lot of the time data is being read and not written, and so real case usage may not see a significant impact. That's why it's worth testing in a real world Windows box test just to see
[12:40] <xivulon> that is an easy test, only involves changing the boot parameters and upgrading ntfs-3g
[12:40] <cking> xivulon: the sysctl hacks are fairly poor performance hit too, so Wubi users will probably not see much of an difference 
[12:41] <cking> ..and the benefit is that removing the sysctl hacks mean than external devices like USB disks will perform well with the sysctl hacks removed
[12:43] <cking> xivulon: I suspect that testing this is the only way to see if it's a usable solution with respect to performance. ntfs-3g is a performance hit which is something we are stuck wth
[12:43] <cking> ..but at least we can tweak the loopback sync or no sync option.
[12:44] <xivulon> cking thanks a lot that is great, I'll take care from here on
[12:44] <cking> xivulon: I need to go - I have some stuff that needs attending to. Keep me posted.
[12:44] <xivulon> will do
[12:44] <cking> great
[13:03] <LimCore> hi
[13:03] <LimCore> how about addiging ubuntu packages for kernel.org vanilla kernels?  like say   linux-kernel.org-stable  and  linux-kernel.org-prepatch.  No ubuntu patches so  1) easy to package  2) good for people working on kernel development/testing
[13:09] <xivulon> cking any reason why the option is called syncio as opposed to sync?
[13:31] <cking> xivulon: sync is a non ntfs-3g option that can get passed through as a mount option to mount, but it's currently ignored by fuse - hence I added a syncio option which won't clash with fuse 
[13:31] <xivulon> I see, thanks
[13:32] <cking> cking: one day sync may be honoured correctly by fuse, which may make syncio redundant
[17:05] <mkrufky> how do i just build the linux-ubuntu-modules?  im getting my patch ready and just want to confirm im not missing any dependencies
[17:05] <rtg> mkrufky: use 'debuild -b' to check build dependencies.
[17:05] <mkrufky> ok, cool
[17:05] <mkrufky> thanks
[17:06] <rtg> mkrufky: note that it only checks dependencies for the arch under which you are building.
[17:06] <rtg> but you should be OK with LUM.
[17:06] <mkrufky> i dont think that would matter in my case
[17:07] <mkrufky> i just want to make sure i didnt omit any new headers
[17:07] <rtg> mkrufky: are you building both x86 and x86_64?
[17:07] <mkrufky> i been building within the linuxtv.org hg repo
[17:07] <mkrufky> the code is safe for both x86 and x86_64 -- i test on both machine types using the linuxtv.org tree
[17:08] <rtg> that seems sufficient
[17:08] <Kano> did somebody delete intrepid-lum.git?
[17:08] <rtg> Kano: it got folded into the Intrepid kernel package
[17:09] <Kano> like for 2.6.22?
[17:10] <rtg> Kano: there is no LUM for Intrepid. All of those modules are now residing in the ubuntu-intrepid.git and are built along with the kernel.
[17:11] <Kano> there was it 2 days ago
[17:11] <rtg> Kano: change is good.
[17:11] <cking> change is frequent
[17:12] <Kano> where is the firmware then?
[17:12] <rtg> Kano: I think its all in LRM now
[17:12] <Kano> not good, lrm is a crap package
[17:13] <rtg> Kano: its undergone serious surgery. a face lift of massive proportions.
[17:14] <Kano> also when you enable madwifi you have to disalbe ath5k, thats clear or not?
[17:14] <rtg> Kano: dunno. its a work in progress. BenC is in the drivers seat.
[17:15] <Kano> ath5k is free variant of madwifi (ath_pci)
[17:15] <rtg> Kano: I even know the guy that wrote ath5k.
[17:16] <Kano> do you own a card for it
[17:16] <rtg> Kano: only in mini-PCI form factor.
[17:17] <Kano> well that does not matter the form factor, you can try it, thats all needed
[17:18] <Kano> maybe i create my own package from the ubuntu-firmware part
[17:19] <Kano> will you revert the gpl only usb exports to make avm usb drivers work?
[17:19] <rtg> Kano: against the author's wishes? Thats highly unlikely.
[17:20] <Kano> well it is not forbidden or?
[17:21] <Kano> i dislike when a new kernel supports less hardware
[17:21] <rtg> Kano: I'm not qualified to say, but no one at Ubuntu is going to do it.
[17:24] <Kano> will you change the alsa-base package for options snd-pcsp index=-2? or does pcsp not install in front of other sounddrivers for you?
[17:25] <rtg> Kano: perhaps you could suggest it to BenC. I'm not working on Intrepid right now.
[17:26] <Kano> i guess more kanotix users test your new kernels as ubuntu users ;)
[17:27] <Kano> i added already a blacklist to my module-init-tools for snd-aw2
[17:28] <Kano> but several users have problems with sound order, so guess i will patch alsa-base
[17:28] <mkrufky> rtg: i have my first version of the lum patch ready -- can you take a look?  this just adds the new files, still needs to be integrated into your build  ﻿http://linuxtv.org/~mkrufky/lum/add-hvr950q-to-lum.patch
[17:32] <rtg> mkrufky: for LUM you enable configs in debian/config/${arch}. Kconfig won't do much.
[17:33] <mkrufky> ok
[17:34] <mkrufky> ...any chance you can just fix this patch up, so that i'll know what to do for all future patches?
[17:37] <rtg> mkrufky: echo "CONFIG_VIDEO_AU0828=m" >> debian/config/i386 ? Its no more complicated then that. Just add your config macros to the appropriate arches (I assume just i386 and amd64)
[17:37] <mkrufky> ah, ok cool
[17:37] <mkrufky> :-)
[17:37] <mrec__> BenC: ah well I would have had something sure 
[17:40] <mrec__> BenC: it would be nice if someone could have a look at: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/230877
[17:48] <cjwatson> BenC: could you please move isofs back to storage-core-modules (from fs-core-modules)? it makes a lot more sense there even though it's the only filesystem module there, because the rest of fs-core-modules isn't needed in the cdrom initrd
[17:53] <mkrufky> rtg: i updated the patch at the same location -- i think it's good to go now
[17:55] <rtg> mkrufky: if you've built it and tested successfully, then email the patch to the kernel team mailing list.
[17:57] <mkrufky> ok
[18:14] <BenC> cjwatson: done
[18:14] <Kano> BenC: do you want my alsa-base fix?
[18:14] <Kano> or dont you have the problem with snd-pcsp?
[18:15] <BenC> there is a problem, but I've no idea what your fix is
[18:15] <Kano> well i changed the rules
[18:15] <Kano> to add a new index=-2
[18:16] <BenC> isn't that something we can add into module-init-tools?
[18:16] <Kano> well there i added a blacklist for snd_aw2
[18:17] <Kano> but thats basically another problem
[18:17] <Kano> for snd-pcsp there is only a alsa order problem
[18:18] <BenC> cjwatson: do you think we really need scsi-tape block driver in d-i at all?
[18:19] <BenC> cjwatson: do you know of anyone doing installs from tape? :)
[18:26] <Kano> BenC: look into query for alsa-driver (alsa-base source package) hack
[18:27] <zul> BenC: I like being retro ;)
[18:28] <Kano> hmm have to put in my ati card to test ati 8-6 ;)
[18:35] <BenC> grrr...you should not need anything other than build-essential to do a source only upload
[20:12] <Kano> BenC: can you rename dm-raid4-5 to dm-raid45 like it is in current hardy
[21:11] <cjwatson> BenC: scsi-tape doesn't sound necessary
[21:12] <cjwatson> BenC: module-init-tools is not involved in d-i
[21:12] <cjwatson> at least not in any relevant way
[21:12] <cjwatson> 18:15 <BenC> there is a problem, but I've no idea what your fix is
[21:12] <cjwatson> BenC: what's the problem?
[21:13] <BenC> cjwatson: that was to Kano
[21:13] <BenC> Kano: I don't want to rename it away from what upstream had it
[21:13] <cjwatson> oh, right, sorry
[21:14] <BenC> Kano: possibly had an alias, but keep the module name the same
[21:14] <Kano> BenC: just rename the target then dmraid can autoload it
[21:15] <BenC> I don't want to change upstream's naming
[21:15] <Kano> i checked with modinfo, the module in -19 kernel IS renamed
[21:15] <Kano> you have to
[21:15] <BenC> I don't have to
[21:15] <Kano> to fix the dmraid issue
[21:15] <Kano> look into hardy changelog
[21:15] <BenC> I'll investigate, but I'm not going to just haphazardly change the upstream naming
[21:16] <Kano> well the nameing in the patch is wrong as it can not be found by dmraid
[21:16] <BenC> in what patch?
[21:16] <BenC> I downloaded the actual source from upstream
[21:17] <BenC> if something is inconsistent, I need upstream to make a decision, otherwise I'm fighting a long drawn out battle
[21:17]  * BenC recalls tar's bzip2 command line argument as a good example
[21:18] <rtg> BenC: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/220493
[21:19] <rtg> BenC: probably ought to get the dmraid user space tools to use the right module name.
[21:21] <BenC> rtg: sounds like the right way
[21:22] <BenC> hmm...there's definitely a dead server on the us.archive.ubuntu.com round-robin
[21:23] <rtg> BenC: you know, I've had problems off and on today also. I finally just went to rookery to get bits.
[21:28] <BenC> rtg, Kano: Uploaded a new dmraid package that uses raid4-5
[21:29] <BenC> raid4-5 sounds better anyway...like "4 or 5" rather than "forty five"
[21:38] <Kano> BenC: when you change dmraid then add the new module to initramfs
[22:56]  * kees makes flushing noise -- stable kernel updates are going out to soyuz...
[22:56] <kees> rtg: ^^ I finished my last-minute boot-testing-of-dak-builds
[22:56] <elmo> aiee
[22:56] <kees> elmo: ?
[23:12] <pwnguin> I'm thinking about moving a bug from wacom-tools to linux, but I need some guidance on triage
[23:13] <pwnguin> the wiki mentions like three teams to assign to when marking confirmed
[23:13] <pwnguin> but i also found a ubuntu-kernel-usb
[23:13] <pwnguin> is that dead?
[23:16]  * pwnguin reads harder