[00:01] <foxmulder881> I also agree with Daekdroom, why not just use apt-get for everything in place of Aptitude?
[00:02] <Daekdroom> foxmulder881, I actually believe it should be the other way around.
[00:02] <yofel> foxmulder881: err, we meant use aptitude and get rid of apt-get
[00:02] <foxmulder881> Daekdroom; sorry. Misunderstood. I guess we disagree then! lol
[00:03] <patdk-wk> heh, I hate aptitude's menu crap
[00:03] <patdk-wk> and always use apt-get
[00:03] <foxmulder881> Daekdroom; what's so special about Aptitude?
[00:03] <yofel> foxmulder881: why do you think we should use apt-get? because it has less features?
[00:03] <Daekdroom> foxmulder881, it's "smarter"
[00:03] <yofel> patdk-wk: you don't have to use the curses interface...
[00:03] <Daekdroom> patdk-wk, I hate its interface, but the command line is awesome
[00:03] <foxmulder881> yofel; it does everything required and is simple to use and understand. I personally can't stand Aptitude.
[00:04]  * yofel actually likes the interface...
[00:04] <BUGabundo> errk..
[00:04] <yofel> foxmulder881: err... how are the command line options of aptitude more complicated than the apt-get ones?
[00:04] <BUGabundo> patdk-wk: you ever used aptitude via cli, no ncrusers?
[00:05] <BUGabundo> its more powerful then apt-get
[00:05] <patdk-wk> never knew you could :)
[00:05] <patdk-wk> and haven't seen anything that told me you could
[00:05] <Daekdroom> I actually found out recently aptitude had a ncurses interface.
[00:05] <Daekdroom> Tripped over it by accident a few days ago :P
[00:05] <patdk-wk> everything is aptitude menu stuff, or apt-get
[00:05] <BUGabundo> patdk-wk: aptitude install BLA
[00:05] <BUGabundo> or my fab
[00:06] <BUGabundo> alias aptitudeupgrade='sudo aptitude update ; sudo aptitude safe-upgrade ; sudo aptitude full-upgrade'
[00:06] <bukayoo> patdk-wk: aptitude --help
[00:06] <foxmulder881> So what can Aptitude do that apt-get can't?
[00:06] <foxmulder881> Genuine question.
[00:06] <BUGabundo> aptitude moo
[00:06] <BUGabundo> foxmulder881: resolve some dep messes , for starter?
[00:06] <arand> intelligent dependency solution suggestions
[00:07] <jcastro> citations needed!
[00:07] <BUGabundo> yeah that too
[00:07] <BUGabundo> not that I ever use it
[00:07] <BUGabundo> jcastro: ?
[00:07] <jcastro> "resolve some dep messes , for starter? "
[00:08] <BUGabundo> jcastro: I felt in love with aptitude when we did the kde 3.5->4.x migration
[00:08] <arand> The gain is more like 2MB by the way (tasksel+aptitude), and ONLY if the install is done via ubiquity, d-i will still use it.
[00:08] <BUGabundo> nothing does package dep resolving better then aptitude
[00:08] <foxmulder881> By dep messes I'm assuming you mean general dep error for which apt-get can also fix? Or different.
[00:08] <BUGabundo> apt-get can fix dep fails?
[00:08] <BUGabundo> never did for me
[00:08] <BUGabundo> specially when you have to downgrade a package
[00:09] <arand> So if you use alternate install, you'll always get aptitude, if I've understood things correctly
[00:09] <yofel> -f install can I think, but it never did what I wanted
[00:09] <BUGabundo> lol
[00:09] <BUGabundo> I stop using -f IONs ago
[00:09] <foxmulder881> Yes, -f is what I'm referring to.
[00:09] <jcastro> I don't know what you mean by "dep fail"
[00:09] <BUGabundo> never actually fixes anythig
[00:09] <foxmulder881> Works for me!
[00:10] <yofel> and I'm not sure if apt-get will show you more than one resolution
[00:10] <patdk-wk> I thought -f only fixed the apt-get database of installed crap
[00:10] <patdk-wk> but not fix anything
[00:10] <BUGabundo> jcastro: do you run devel cicle before beta? :p
[00:10] <arand> Hmm, it has fixed countless things for me, but anyways...
[00:10] <jcastro> BUGabundo: yes, for the past 5 years!
[00:10] <BUGabundo> then you should know what I me
[00:10] <BUGabundo> take the X migration going right now
[00:10] <BUGabundo> aptitude won't install anything critical of it
[00:11] <jcastro> apt's been holding it back for me
[00:11] <BUGabundo> apt-get full-upgrade would, no questions asked
[00:11] <jcastro> you mean dist-upgrade?
[00:11] <foxmulder881> What the hell is full-upgrade?
[00:12] <BUGabundo> yes sorry
[00:12] <BUGabundo> the habit of aptitude
[00:12] <foxmulder881> lol
[00:12] <jcastro> i've been running apt-get upgrade every day and it's holding back the packages like it's supposed to
[00:12] <foxmulder881> Apt-get and Aptitude breed different types of lingo!
[00:12] <arand> Well, same questions as aptitude full-upgrade, really, but aptitude tries to keep it sane, and tells you things, apt-get just says here's what I'll do, dowant?
[00:12] <BUGabundo> they do
[00:12] <jcastro> dist-upgrade is for upgrading from one distro release to another
[00:12] <BUGabundo> one of the most confusing one
[00:13] <BUGabundo> is aptitude install also does upgrades
[00:13] <foxmulder881> arand; that's crap.
[00:14] <yofel> just tried to compare safe-upgrade with apt-get upgrade and they already disagree, aptitude will install the new kernel images, apt-get won't
[00:14] <BUGabundo> \o/
[00:14]  * BUGabundo serves a slice of bread with peanut butter to yofel
[00:14] <foxmulder881> yofel; so find out why.
[00:15] <yofel> thanks
[00:15] <Daekdroom> BUGabundo, aptitude install also removes "useless" packages, instead of only suggesting it like apt-get does
[00:15] <yofel> foxmulder881: no reason, apt-get holds the linux meta packages back, while aptitude simply installs the new files they now depend on and upgrades them
[00:15] <foxmulder881> There's always a reason behind it if apt-get fails for some reason. I like to manually get behind the source of problems like that. I don't like applications to do everything for me and not let me know why it went pear-shaped in the first place.
[00:15] <BUGabundo> I would love to see apt be more verbose some times
[00:15] <BUGabundo> then again, we have dselect
[00:15] <jcastro> apt installed the new kernel for me yesterday
[00:15] <arand> jcastro: Hmm, well, it is for operations other than upgrading packages, e.g. removals and new-installs
[00:16] <BUGabundo> Daekdroom: that's debian/ubuntu policy
[00:16] <BUGabundo> has been for one or two cycles
[00:16] <Daekdroom> BUGabundo, but apt-get doesn't do that at all.
[00:16] <Daekdroom> It's aptitude specific
[00:16] <arand> Which I guess once released, is rather irrelevant
[00:16] <BUGabundo> did last time I tried on debian
[00:17] <arand> Daekdroom: apt-get autoremove does.
[00:17] <Daekdroom> arand, yeah, but aptitude does it with only an aptitude install. No specific command for that.
[00:17] <arand> You always have to be more specific with apt-* no holding hands like with aptitude..
[00:17] <BUGabundo> if that was true, based on what synaptic shows as obsolete
[00:18] <BUGabundo> I would have 500 MBs extra free space :)
[00:18] <foxmulder881> arand; that's what I'm trying to say. That's the way I prefer things.
[00:18] <Daekdroom> So we need a package manager that's verbose-esque like aptitude and specific like apt-get?
[00:18] <foxmulder881> I guess so!
[00:19] <arand> Yes, so do I, but I've come to understand that ubuntu will kill my babies, and such is life.
[00:19] <BUGabundo> Daekdroom: dselect
[00:20] <BUGabundo> or go all hardcore, and dpgk
[00:20] <BUGabundo> *dpkg
[00:20] <jcastro> don't use dselect, it will just make you want to kill yourself
[00:20] <foxmulder881> I also like dpkg. But only for purging stuff and if no other deps required. But it is rock soild every time.
[00:20]  * patdk-wk uses dpkg* alot
[00:20] <BUGabundo> jcastro: I was jk, ofc
[00:21] <jcastro> heh
[00:21]  * yofel only uses dpkg if there are .debs to install or --force-* is needed
[00:21]  * Daekdroom doesn't like --force at all
[00:22] <yofel> it's there for a reason, and no, you shouldn't use it without knowing what you're doing
[00:22] <arand> Hmm, building your own packages means a lot of dpkg, and dpkg -L/-S is just crazy useful
[00:22] <yofel> +1
[00:23] <yofel> (forgot about that ^^)
[00:23] <jcastro> BUGabundo: what are you doing tomorrow? Want to help with unity/global menu?
[00:24] <foxmulder881> I'm off for now. Cheers folks. Off to reinstall lucid actually!
[00:24] <arand> That tasksel is going though... not awfully sad about that, it's a beast of messing up a system..
[00:25] <BUGabundo> jcastro: last day of work, before one week vacations mostly offline
[00:25] <BUGabundo> if weather permits
[00:26] <BUGabundo> arand: tasksel is nice
[00:26] <BUGabundo> jcastro: I really should re-test unity
[00:26] <BUGabundo> haven't boot into it since it was out
[00:26] <arand> BUGabundo: IT IS NOT: Bug #574287
[00:26] <jcastro> holla at me when you want to try, I need help testing the global menu!
[00:26] <BUGabundo> arand: LOOOL
[00:26] <BUGabundo> jcastro: okay
[00:27] <BUGabundo> I'll probably _cry_ about the here and StatusNet/twitter
[00:27] <BUGabundo> I even created the SN group for it )
[00:27] <BUGabundo> :)
[00:27] <BUGabundo> identi.ca/group/unity
[00:28] <arand> I still need to test it out on debian, since presumably it's not an ubuntu change inducing that, seems like tasksel and ubuntu-desktop = unfriends...
[00:28] <BUGabundo> ahaha
[00:29] <BUGabundo> only if you clear -desktop task
[00:29] <BUGabundo> duh
[00:30] <arand> BUGabundo: Nope: 1 install openssh, 2 uninstall openssh = removal of half of gnome :/
[00:31] <Daekdroom> What does tasksel do?
[00:31] <BUGabundo> what?!?!
[00:31] <BUGabundo> no can do!
[00:32] <arand> Daekdroom: Install a group of packages meant for a specific task.
[00:32] <BUGabundo> Daekdroom: think like this
[00:32] <BUGabundo> you want to install a LAMP
[00:32] <BUGabundo> it does it all for you
[00:32] <BUGabundo> no need to fetch, apache, mysql, php, etc by hand
[00:33] <BUGabundo> its like a special meta-package
[00:33] <BUGabundo> sooooooo
[00:33] <BUGabundo> anyone can confirm mocp is DOA?
[00:34] <arand> ..google says museum of contemporary photography, hmm..
[00:35] <arand> BUGabundo: mocp who?
[00:52] <Sarvatt> well that stinks, no more 64 bit flash
[00:53] <Sensiva> Sarvatt elaborate please?
[00:54] <Sarvatt> they closed down the beta since it was based on 10 instead of 10.1
[00:54] <Sarvatt> can't download it from their website anymore
[01:12] <cwillu> pokity poke
[01:26] <koshie> Hi
[01:30] <lucitu> Flash crashing in chrome?
[01:36] <arand> lucitu: Has been for ages, I think..
[01:36] <lucitu> arand: only recently
[01:36] <arand> Hmm, well I'm not a chromium user, but I rember it doing that a week or so ago...
[01:37] <lucitu> arand: about 2wks ago when libgtk2.0 was upgraded..had to downgrade to lucid version to work
[01:38] <lucitu> arand: looks like libgtk2.0 will stay that way..
[01:38] <arand> Sarvatt: Hmm, I've got the .so if you want it?
[01:39] <Sarvatt> arand: nah I've got it, thank you though. just a shame they stopped it
[01:40] <arand> lucitu: Hmm, yea, I'm sorry i don't think I can be much help there, but search LP, as is my general-handwavey-response to most things..
[01:40] <arand> I'm off to bed..
[01:49] <cwillu> who can I poke about alsa development?  Rumour has it that the latest alsa has support for some speciality recording hardware that I have, but I haven't had any luck compiling it for 2.6.>28, and it appears that lucid's alsa doesn't have it, even though as far as I can tell it _should_ have it
[01:49] <cwillu> m-audio fast track ultra, 8x8 channel usb
[01:49] <Volkodav> cwillu just compile the latest and see if it works
[01:49] <Volkodav> that's all
[01:50] <cwillu> thanks for reading what I wrote :p
[01:50] <Volkodav> I mean on the later kernels
[01:50] <cwillu> 2.6.>28 == anything newer than 2.6.28
[01:50] <Volkodav> did you try 34 35 ?
[01:50] <cwillu> yes
[01:50] <cwillu> missing symbols
[01:51] <Volkodav> while compiling ?
[01:51] <cwillu> but I can rebuild the kernel itself fine
[01:51] <cwillu> yes
[01:51] <Volkodav> on all kernels or some specifics ?
[01:52] <cwillu> not dead sure I've tried against 2.6.35 yet, hang on (that machine is in the other room, and I haven't installed ssh on it yet)
[01:53] <cwillu> 2.6.34 is the latest I've tried
[01:53] <Volkodav> did you try to compile om maverick or lynx ?
[01:53] <Volkodav> well 35 is in the mainstream ppa rc 2 I believe
[01:53] <cwillu> rc2 isn't, no;  last I checked it only has a source deb
[01:53]  * Volkodav was about to install it too
[01:53] <Volkodav> http://kernel.ubuntu.com/~kernel-ppa/mainline/
[01:54] <cwillu> planning on moving to it on a couple servers as soon as rc3 is available (.35 has a bunch of btrfs fixes that I want, and rc2 has a known btrfs corruption issue)
[01:54] <Volkodav> all 3 debs are there for maverick only on 35 rc2
[01:54] <cwillu> oh, wait, I was looking at the lucid source, yep
[01:54] <Volkodav> Did you read about the regression on 35 ?
[01:55] <cwillu> there's so many, did you mean a particular one?
[01:55] <Volkodav> overall performance speed etc
[01:55] <cwillu> udev and btrfs are what I'm aware of
[01:55] <cwillu> ya, that's a udev issue
[01:55] <cwillu> that phoeronix junk
[01:55] <Volkodav> I would like to tinker btrfs on my SSD
[01:55] <cwillu> afaik, that's already been sorted out
[01:56] <cwillu> you can set up btrfs via dkms easily enough, just haven't bothered yet
[01:56] <cwillu> _requires_ 2.6.35 currently though
[01:56] <Volkodav> is it in the installer option on maverick yet ?
[01:56] <cwillu> no idea;
[01:56] <Volkodav> set up you mean convert ?
[01:56] <cwillu> I've been using it for about a year though
[01:56]  * psusi is quite pleased with ext4 on his ssd... and on the new 1.5 tb wd drive
[01:57] <psusi> anyone wanna test e2defrag? ;)
[01:57] <cwillu> no, I meant to install btrfs modules from git via dkms instead of what's in mainline (given that rc2 has some issues there)
[01:57] <Volkodav> cwillu did you try the snapshot yet on it ?
[01:57] <cwillu> long ago mate :)
[01:57] <Volkodav> oh ok
[01:57] <cwillu> I've been deploying embedded stuff on it for about 8 months
[01:57]  * psusi hopes to get his patch for e2fsck into maverick and lazy_itable_init on by default so it only takes 30 seconds instead of 15 minutes to format a 1.5 tb ext4 partition
[01:58] <cwillu> checksumming is so very handy when you only have crappy sd cards as root drives
[01:58] <Volkodav> how is it different from ZFS dtrace ?
[01:58] <cwillu> haven't used zfs
[01:58] <cwillu> although my impression is that btrfs is on much more solid theoretical footing than zfs
[01:59] <cwillu> we're probably going to have lzo compression in a day or two, raid5 is coming along nicely, etc
[01:59] <Volkodav> well then you have an option of playing with rc2 ot compile your own I guess
[01:59] <cwillu> anyways, back to alsa :p
[01:59] <cwillu> unless you wanna keep talking btrfs :p
[01:59] <Volkodav> how does raid5 plays with ssd s though ?
[01:59] <cwillu> how do you mean?
[01:59] <Volkodav> I heard they had issues on early stages
[02:00] <Volkodav> they simly did not work
[02:00] <cwillu> which raid5?  It's not done yet
[02:00] <psusi> don't work is not an error description...
[02:00] <Volkodav> any raid for that matter with ssd
[02:00] <cwillu> lots of things don't simply don't work, because they haven't been implemented
[02:00] <cwillu> no, that's not true
[02:00] <psusi> drives don't know or care if they are in a raid
[02:01] <psusi> you're not going to be able to TRIM them currently though...
[02:01] <Volkodav> but internally every ssd is already a raid
[02:01] <cwillu> layering btrfs on top of lvm has been troublesome, mainly because lvm didn't pass through barriers properly to the hardware
[02:01] <cwillu> Volkodav, so are most harddrives
[02:01] <psusi> no, an ssd is an ssd
[02:02] <psusi> raid stands for redundant array of inexpensive disks... definitionally impossible for a single disk to be one
[02:02] <Volkodav> every ssd has internal raid controller with bunch of memory in it
[02:02] <cwillu> Volkodav, it's more complicated than that in fact
[02:02] <psusi> no, it has a flash memory controller
[02:02] <cwillu> the controller does much more than most raid controllers do
[02:02] <psusi> that emulates a sata disk
[02:02] <Volkodav> does trimming etc
[02:03] <psusi> no, trimming is something the os does
[02:03] <psusi> or is working towards doing...
[02:03] <cwillu> wear levelling, compaction, etc
[02:03] <Volkodav> os kernel and FS
[02:03] <Volkodav> takes 3 just to trim
[02:03] <cwillu> the performance differences between ssd drives largely comes down to the algorithms in use
[02:03] <psusi> os driver = part of kernel
[02:03] <psusi> err, fs driver rather
[02:04] <Volkodav> cwillu but the bottom line that they are all internally in raid
[02:04] <cwillu> the companies with experience with incremental garbage collection were the first to get decent lasting performance
[02:04] <cwillu> Volkodav, no, the bottom line is that they're apples and oranges
[02:05] <cwillu> you might as well say a system with multiple mounts is a raid
[02:05] <Volkodav> apples ssd who is oranges ?
[02:05] <cwillu> raid
[02:05] <psusi> or a disk with multiple heads... multiple heads do not a raid make... a floppy disk is not a raid...
[02:06] <Volkodav> so there is no difference in setting up ssd or regular harddrive say in raid
[02:07] <cwillu> no, there's big differences
[02:07] <Volkodav> that's all I was saying
[02:07]  * psusi needs to do a thorough check to make sure everything is in order and release a new rev of e2defrag and get someone to sponsor uploading it to maverick universe
[02:07] <cwillu> ... and we keep telling you you're wrong :p
[02:07] <Volkodav> people could not even boot them first
[02:07] <cwillu> Volkodav, ssd drives?  yes, yes they could
[02:08] <cwillu> Before they had ata interfaces in front of them, they weren't at all like block devices at all
[02:08] <cwillu> while raid is a way of taking a bunch of block devices, and ganging them into a single device
[02:09] <Volkodav> they just needed  boot parameter dmraid=true
[02:09] <Volkodav> well back to alsa
[02:09] <cwillu> :p
[02:09] <psusi> dmraid has nothing to do with ssd.. dmraid is bios fake hardware raid support
[02:09] <Volkodav> what are you trying to get to work ?
[02:09] <psusi> really only exists for compatibility with winders
[02:10] <cwillu> piece of hardware called "m-audio fast track ultra"
[02:10] <cwillu> I can get usb id's and such
[02:10] <cwillu> currently only the midi interfaces comes up properly
[02:10] <psusi> hrm.. that reminds me... I need to poke someone about getting the dmraid regression in lucid SRU'd in time for the 10.04.1 respin...
[02:10] <Volkodav> so it is a newer sound card I guess ?
[02:10] <cwillu> Somebody posted usb traces of all the mixer functionality under windows, I was planning on hacking that in, but I need to start with the basic support
[02:11] <cwillu> it's a year or so old, but the others in its family also weren't supported
[02:11] <cwillu> there's been patches floating around, but they're in the changelog for the latest alsa stable
[02:11] <cwillu> and in the source
[02:11] <Volkodav> hmm
[02:11] <Volkodav> may as well patch
[02:12]  * Volkodav just patched exaile 
[02:12] <Volkodav> mini mode is not working
[02:12] <Volkodav> was not*
[02:12] <cwillu> Volkodav, I finding it hard to not say this in a rude fashion
[02:12] <cwillu> Volkodav, but your reading comprehension leaves a little bit to be desired :p
[02:13] <Volkodav> oh all that was for windoze ?
[02:13]  * Volkodav getting focus together
[02:13] <cwillu> case in point :p
[02:13] <cwillu> let's start over
[02:13] <Volkodav> hmm
[02:13] <cwillu> (a) alsa mainline doesn't compile against recent kernels without patches that I can't find
[02:13] <Fudge> does luke chat in here?
[02:14] <cwillu> (b) ubuntu's alsa doesn't seem to be recent enough to include the new drivers
[02:14] <Volkodav> do they exist those patches yet ?
[02:14] <cwillu> (c) I need to be able to compile from some source, so that I can generate patches to send upstream
[02:14] <Volkodav> I would check gentoo forums
[02:14] <Volkodav> ooouf
[02:15] <cwillu> and I will not under any circumstances be installing gentoo on my machines :p
[02:15] <Volkodav> you may find the patches on their forums
[02:15] <Volkodav> I did twice
[02:15] <cwillu> I was hoping to find an alsa maintainer or someone with similar experience, to basically copy their approach to this
[02:16] <cwillu> Volkodav, the problem isn't so much finding a way to make it build, and more finding the _right_ way to make it build
[02:17] <cwillu> if I include patches to build it under 2.6.35, and those don't match what we in debian/ubuntu use, then it makes it harder for me to get support with testing and development, let alone upstreaming
[02:17] <Volkodav> oh we talking  not just the dirty hack to make it work - you want elegant ?
[02:17] <cwillu> The point of the endeavour is to not have magic packages on my system :)
[02:17] <Volkodav> or the alsa type approach
[02:18] <cwillu> the sooner I can upstream it, the sooner I can work on _other_ things which need fixing :)
[02:18] <Volkodav> there must some channel for alsa I think
[02:18] <cwillu> an ubuntu/debian alsa channel?
[02:19] <Volkodav> debian probably be a better shoice
[02:19] <Volkodav> or deb-dev
[02:19] <Volkodav> they have a few dev channels for debian
[02:22] <cwillu> you know, I really wish I would remember sooner alternate nicks that particular people have :p
[02:22] <cwillu> crimsun_, can I poke you for a couple minutes?
[03:14] <psusi> if anyone cares to test the defrag package, a new build is now in my ppa
[03:18] <bukayoo> psusi: wud love to..where is the ppa? am assuming the dev has to be unmounted?
[03:19] <psusi> bukayoo, on launchpad... ppa:psusi/ppa... yes, has to be unmounted, and of course, have a current backup, or otherwise don't care if the data on it is lost... works well for me, but still has a serious possibility of totally destroying all your data ;)
[03:20] <Nitsuga> hello!
[03:20] <Nitsuga> Am I the only one with rhytmbox plugins problems?
[03:21] <bukayoo> psusi: aside from destroyed data, how can I tell if success?  does the % non-contiguous from fsck enough?
[03:21] <psusi> bukayoo, that's one indicator... it has an ncurses interface that shows the disk map too, and has a frag program to check fragmentation of specific files... also you can run the e2freegrag from e2fsprogs to check free space fragmentation
[03:22] <bukayoo> psusi: guessing it shud be zero after?
[03:22] <psusi> also run an e2fsck -f after defrag
[03:22] <psusi> yep
[03:22] <bukayoo> psusi: ok..will try
[03:23] <psusi> it's a little slow creating the relocation map now... changed it to use a double binary tree indexed extent list instead of a double array of block pointers so it can now handle very large disks without many, many gigs of ram, at the expense of some cpu
[03:23] <psusi> will need to do some optimizations to regain startup speed but I can now defrag a 1.5 tb disk with only 2 gigs of ram
[03:24] <psusi> ohh, you should also do a read only pass first with -r to make sure it works
[03:25] <psusi> and depending ont he size of the disk and ram size you might want to add -p and specify a larger buffer pool size than the default 32768 to speed things up
[03:26] <bukayoo> psusi: can I try on a vbox disk?
[03:26] <psusi> sure
[03:27] <bukayoo> psusi: great..i have some junk I can try.
[03:27] <psusi> for my testing I usually just make a test lvm volume and either restore a dump to it or dd a snapshot of my root volume
[03:34] <psusi> and in case the name led you to think otherwise, it does work on ext4
[03:34] <psusi> now
[03:34] <Sensiva> psusi launchpad link please?
[03:36] <psusi> Sensiva, launchpad.net/e2defrag is the project... for the ppa just apt-add-repository ppa:psusi/ppa
[03:36] <bukayoo> psusi: could not determine the filesystem type. pls run the appropriate defragmenter
[03:37] <psusi> bukayoo, ohh... I forgot it even had a generic auto defragger... just run e2defrag instead... I'll have to take a look at the wrapper now
[03:38] <bukayoo> psusi: ok..now working
[03:38] <psusi> it used to support ext, xia, and minix too
[03:41] <psusi> oh weird... looks like the wrapper is just a script that calls file on the dev node and parses its output to decide what the fs is... that doesn't work on actual devices... anymore...
[03:44] <bukayoo> psusi: it's working now..just like pacman..will try later on a real hd bec the virtual disk is clean
[03:44] <psusi> hehe
[03:44] <psusi> good old ascii graphics ;)
[03:45] <psusi> takes you back doesn't it?  I remember using this thing when I first tried slackware back in '95
[03:46] <bukayoo> psusi: yes it does..I see some 'B'ad blocks.  what is that?
[03:46] <psusi> probably the journal
[03:46] <psusi> B is just generic for anything that can't be moved
[03:47] <bukayoo> psusi: ok
[03:47] <psusi> no, wait... I made the journal movable....
[03:47] <psusi> hrm....
[03:47] <psusi> how big of a volume is this?  is it freshly formatted?  ext4?  it might be the resize inode...
[03:47] <psusi> but usually that's so small it doesn't show up
[03:48] <bukayoo> psusi: it's an ext4
[03:48] <bukayoo> psusi: where is the image paste bin?
[03:48] <psusi> photobucket?
[03:50]  * psusi wishes Ted, Alex, and Linus hand't given up on this thing
[03:50] <psusi> err, Remmy not Alex
[03:50] <bukayoo> psusi: here is a snapshot  http://imagebin.ca/view/0ABy22N6.html
[03:50] <psusi> ahh, yea, that's the resize inode
[03:51] <psusi> reserves a little space after each block group descriptor table for expansion
[03:53] <bukayoo> psusi: what are the little white dots?  looks like it didn't put them all together?
[03:53] <psusi> free space, see the key? ;)
[03:53] <bukayoo> bundled closer to the front?
[03:53] <psusi> or legend
[03:53] <bukayoo> psusi: ohh..my bad
[03:53] <psusi> by default it tries to locate data in the block group of the owning inode
[03:54] <psusi> if you use the inode priority file option though to assign a high priority to an inode, it will force it to the start of the disk rather than in its native block group
[03:55] <psusi> this is handy for packing all the boot files ureadahead reads at the start of the disk, even if their inodes are scattered around
[03:56] <bukayoo> psusi: if I remember it correctly the windowz defragmenter kind of move them up front..was it windows or norton?
[03:58] <bukayoo> psusi: will try now on a real hd..
[03:59] <bukayoo> psusi: but I think mine boots so fast some stuff aren't ready in time.. always get a fatal: module.dep load failure 3x before it loads properly
[04:02] <psusi> afaik, microsoft licensed diskkeeper, and that just kind of randomly moves fragmented files around until they are not fragmented anymore
[04:03] <psusi> this acts like it started with a completely empty disk, allocating blocks one after the other from left to right until every file on the disk has had blocks allocated... then moves everything from its current position to the new position
[04:05] <psusi> but like I said, it tries to allocate blocks in the same block group as the inode that wants them so they are located near the owning inode
[04:06] <bukayoo> psusi: just for my enlightenment.. I was thinking b4 can I achieve the same if I copy the whole disk out, reformat old disk and then copy back?
[04:10] <psusi> bukayoo, doing that with ext4 will generally result in low fragmentation, but does not do the same thing since the kernel uses different allocation algorithms
[04:12] <bukayoo> psusi: e2freefrag count error after -  http://imagebin.ca/view/kOdpoy.html
[04:13] <psusi> run e2fsck -f first after defrag
[04:14] <psusi> right now defrag does not update the free blocks count in the superblock if it ends up allocating/freeing blocks for the extent tree so it can end up wrong... fsck will fix that easily.. that's on my todo list
[04:15] <bukayoo> psusi: here is the e2freefrag after http://imagebin.ca/view/xdeqNNm6.html
[04:16] <psusi> yep, that looks about what I've come to expect
[04:17] <bukayoo> psusi: here is the before - http://imagebin.ca/view/KgLIOZ.html
[04:17] <psusi> you can get larger than 2gb free space chunks if you up the flex_bg factor when you mkfs too with mke2fs -G x... the default is 32 which gives the 2gb maxium contiguous free space
[04:18] <bukayoo> psusi: ok..but remember this is a vbox virtual disk
[04:19] <bukayoo> created by vbox
[04:21] <bukayoo> psusi: anyway thnks for the nice tool..will try on real hd. will let you know
[04:21] <psusi> make sure you backup first ;)
[04:24] <ZykoticK9> have the xserver-xorg-video-* files been kept back for a while now?  I've just installed so am curious if it's been like this for a while already?  (I'm happily using "sudo aptitude safe-upgrade")
[04:24] <psusi> and it was originally written by Theodore Tso, Remmy Card, and Linus Torvalds... they just abandoned it ages ago and I'm bringing it back to life ;)
[04:25] <psusi> of course it will probably be rendered obsolete in a year or two by e4defrag, but hey... was interesting to work on and gives us something to use in the mean time
[04:26] <psusi> and hell, I might even port it to work on ntfs
[04:26] <psusi> and fat32
[04:27] <bukayoo> psusi: definitely..what is e4defrag?  the newer version from these trio?
[04:27] <psusi> defragger supposedly being written from scratch to do online defrag of ext4
[04:27] <psusi> using ioctls built into the kernel rather than directly mucking with the disk
[04:28] <psusi> it has the advantage of being able to work on a mounted fs, and be safe by going through the journal... but since it has to allocate a new file, then atomically swap blocks, I doubt it will ever be as fast or be able to pack files as well as e2defrag
[04:28] <psusi> or optimize free space
[04:29] <psusi> if you loose power in the middle of an e2defrag, your screwed ;)
[04:29] <bukayoo> psusi: i wud think so.unless you stop all procs writing to it
[04:31] <bukayoo> psusi: i used to work with tandem and had to stop procs so to increase max extents of file near max
[04:31] <psusi> the really nifty thing about e2defrag is that you can build a priority list from the ureadahead pack file and pass it to e2defrag so it packs all those files sequentially at the start of the disk to speed up boot time... I don't see e4defrag ever being able to do that
[04:33] <psusi> ext4's delayed allocation, extents, and multiblock allocator really does a fantastic job of minimizing fragmentation
[04:34] <psusi> even for bit torrenting, which usually results in horrible fragmentation... ext4 keeps it contiguous as long as the torrent app uses fallocate() to tell it how big the file is going to be up front...
[04:35] <psusi> and even if it does't, ext4 still seems to do a pretty good job
[04:35] <cwillu> psusi, there's no reason an online defragmenter couldn't do all the same things though
[04:36] <cwillu> with the possible exception of dealing with a near full filesystem,
[04:36] <psusi> cwillu, I'm not sure how it could... the way it is designed now, it has to create a new file, force it to allocate blocks, then swap those blocks with the file it is trying to defragment... doesn't really have a way to analyze all files on the fs at once, including the free space
[04:37] <psusi> e4defrag that is
[04:38] <bukayoo> plus with all processes doing IO to the disk
[04:39] <bukayoo> it's like cleaning a kitchen with the cooks still at it
[04:40] <psusi> of course, e2defrag doesn't care if the fs is 99.9% full, it will defrag it just fine ;)
[04:40] <cwillu> psusi, the ioctl's don't give any control over location?
[04:41] <bukayoo> I always tell windowz user to stop screen savers, anti-virus, as much processes before doing defrag
[04:41] <psusi> cwillu, as I understand it, the new ioctls just allow e4defrag to request that the kernel atomically swap the blocks between two files.. so it creates a dummy donor file first, hopes that it is allocated some contiguous blocks, then swaps with the file it is trying to defrag, then deletes the donor
[04:42] <ZykoticK9> psusi, sorry side question - do you happen to know if Transmission observes fallocate() as you noted above?  i have run into issue with fragmentation on drives with ext3/4 when used with torrents.  I was under the impression the only way to "defrag" was to copy everything to another media, delete the origional, then copy everything back.
[04:42] <cwillu> so all you'd need is a call to attempt to make a file of a given size at a given location, and you're laughing :)
[04:43] <psusi> ZykoticK9, I believe it does... from what I have seen transmission results in little to no fragmentation on ext4... ext3 is a different story
[04:43] <ZykoticK9> psusi, thanks
[04:43]  * cwillu looks forward to more fancy user-space tools for btrfs
[04:51] <psusi> be nice when btrfs is actually stable and well supported
[04:52] <psusi> in the mean time I'm waiting for the new lvm tools to get merged into maverick so we can use lvm to take snapshots, test upgrading, and be able to revert if things to wrong
[04:54] <bukayoo> psusi: is the 4096 block size now the std? with smaller files this may be too big?
[04:54] <psusi> bukayoo, 4k block size has been pretty standard for many years now...
[04:56] <psusi> I actually wish ext supported > 4k blocks... seems there are some bugs in the kernel that prevent it from working
[04:57] <psusi> my 1.5 tb disk wastes far too much space on unused inodes, and allocation bitmaps that would be reduced with a larger block size
[04:57] <bukayoo> psusi: I guess if you use it for big files like multimedia, a much bigger blk size wud help
[04:58] <bukayoo> less 'swiss cheese'
[04:59] <psusi> the main problem with ext4 is that you end up having a good deal of space used by the block allocation bitmaps, and the maxium size of a block group is 128mb... and the default is to allocate 8192 inodes per block group, which leas to far more than anyone could ever need on tb+ size disks
[05:00] <psusi> you can reduce the allocated inodes at mkfs time with -E largefile or largefile4
[05:01] <psusi> but then you are still wasting space on the allocation bitmaps
[05:02] <psusi> I need to check on how the 64 bit feature is coming along... that will allow much larger block groups..
[05:02] <bukayoo> agreed
[05:03] <bukayoo> got to go.nice talking to you psusi
[05:03] <psusi> but now the wife says it's bed time... night
[09:16] <BUGabundo_remote> raises the sales,row to south!
[10:05] <arand> Now the floodgates of xserver seems to have opened ./
[10:11] <BUGabundo_remote> they are?
[10:50] <foxmulder881> Can someone here help me with something quickly?
[10:50] <BUGabundo_remote> shoot
[10:52] <foxmulder881> Not related to Maverick, but Lucid, sorry. But guys in #ubuntu are a bit ditsy at the moment. I upgraded Lucid today in tty1 via apt-get and noticed a few message stating "unattended upgrades...". Any idea what that is all about or is it just normal messages from something?
[10:55] <foxmulder881> No ideas!!! :-(
[10:56] <foxmulder881> Perhaps I'll reinstall again tomorrow morning and try upgrade via aptitude and see how it goes.
[11:29] <cwillu> foxbuntu, from a terminal, use "do-release-upgrade"
[11:29] <cwillu> too late now of course, but ya
[11:29] <cwillu> or did you mean it was already lucid, and you just applied new updates?
[11:29] <cwillu> er, nvm
[11:29] <cwillu> that'll teach me to not show parts
[11:51] <BUGabundo_remote> cwillu hum no, foxbuntu is still here
[11:53] <cwillu> BUGabundo_remote, has foxbuntu said anything recently?
[11:53] <cwillu> as opposed to a certain other fox
[11:53] <cwillu> tab complete fail :p
[11:54] <cwillu> because the target is no longer in the room
[11:58] <BUGabundo_remote> ahh
[12:52] <zniavre> hello
[12:52] <zniavre> im trying rgba option with 10.10 it works quite well
[12:53] <zniavre> some of you experienced some bug with panels and rgba activated ?
[13:00] <DrHalan> trying the new x
[13:00] <DrHalan> seems to work :)
[13:00] <DrHalan> but gnome-power-manager stilll doesnt -.-
[13:01] <ripps> Does anybody know how to remove the battery indicator? I'm on a desktop, so a battery inidcator is pointless
[13:02] <DrHalan> ripps: annoys me too.
[13:02] <DrHalan> normally you can set taht in the energy properties
[13:02] <DrHalan> but i guess its a bug
[13:03] <ripps> I also can't remove the bluetooth applet.
[13:03] <ripps> That one doesn't annoy me as much, as I do have a bluetooth.
[13:03] <gnomefreak76> remove the applet-indicator should do it, but shhhh im not here
[13:05] <DrHalan> am i the olny one not getting past gdm?
[13:06] <gnomefreak76> useing nvidia?
[13:08] <DrHalan> im suing virtualbox
[13:08] <DrHalan> when gdm comes up it says gnome-power-manager couldnt be started or something like that
[13:09] <gnomefreak76> most likely not but i dont have it loading on start up
[13:09]  * gnomefreak76 not very good with this away thing
[13:10] <DrHalan> hows that gnomefreak?
[13:10] <DrHalan> can i just remove it?
[13:10] <gnomefreak76> DrHalan: i shouldnt be here
[13:10] <gnomefreak76> DrHalan: i wouldnt remove it
[13:11] <BUGabundo_remote> DrHalan: there's and vb pacakage on hold due to X migration
[13:11] <BUGabundo_remote> if you forced it to install, maybe that's why you got a broken GDM
[13:11] <DrHalan> well gdm works i can seee login but there an indicator on the top right that says that gnome-power-manager couldnt be started
[13:11] <DrHalan> and when i try to login x crashes
[13:17] <shadeslayer> hey all :D
[13:17] <shadeslayer> anyone using kubuntu?
[13:17] <BUGabundo_remote> nope
[13:17] <shadeslayer> i cant seem to find the show desktop plasmoid
[13:24] <shadeslayer> any ideas?
[13:32] <mfraz74> quickaccess plasmoid has been updated
[13:32] <shadeslayer> mfraz74: yes :)
[13:32] <shadeslayer> mfraz74: does it work now?
[13:33] <mfraz74> no
[13:34] <mfraz74> unless i need to logout and log back in
[13:34] <shadeslayer> mfraz74: hmm..
[13:34] <DrHalan> thre were some packages missing its working now :9
[13:34] <shadeslayer> mfraz74: plasma crashes ?
[13:34] <DrHalan> there iwll be another upgrade to 1.9 right?
[13:35] <mfraz74> shadeslayer: yes, background goes black and the refreshes
[13:38] <mfraz74> how do i find out if the new version is the one i'm using?
[14:13] <h00k> IdleOne: :)
[14:26] <Ian_corne> gwibber update BUGabundo_remote
[14:27] <h00k> IdleOne: I had a bunch of xserver updates actually install with a safe-upgrade yesterday
[14:29] <cwillu> !info binutils
[14:29] <Ian_corne> Something is still conflicting with nvidia-current
[14:30] <Pici> The bot is only updated once or twice a day, so you may not see your updated pacakges in there.
[14:30] <cwillu> who, me?
[14:31] <BUGabundo_remote> Ian_corne: fyi I run daily ppa
[14:31] <Pici> cwillu: you're not a bot, are you?
[14:31] <cwillu> Pici, I just poked a bot
[14:31] <BUGabundo_remote> yes Pici, cwillu is a domestic bot
[14:31] <BUGabundo_remote> I tried to make him do the place of roomba
[14:31] <BUGabundo_remote> but he just scarted garbish
[14:32]  * cwillu starts breaking a stick into toothpicks, scattering them as he goes
[14:32] <cwillu> sanity check:  a kernel built with binutils 2.20 won't have modules loadable on a system with binutils 2.19?
[14:33] <cwillu> or something like that?
[14:33] <cwillu> trying to figure out why somebody's kernel builds stopped being usable, my current theory is that he started building for maverick, and that broke his lucid builds
[14:38] <Ian_corne> BUGabundo_remote: ok
[14:46] <Ian_corne> Anyone know of a ppa for freeciv?
[14:47] <psusi> Ian_corne: it's in the main repo
[14:48] <bukayoo> hello psusi
[14:48] <psusi> o/
[14:48] <bukayoo> psusi: just did a defrag on a data drive and the results are great
[14:49] <patdk-wk> psusi, making progress on that still?
[14:49] <psusi> patdk-wk: yea... just made a new release last night with a build in my ppa
[14:50] <bukayoo> psusi: yes here is the results http://imagebin.ca/view/F-2z5lZv.html
[14:50] <patdk-wk> where's it at? :)
[14:50] <psusi> and just fired off an email to the motu mailing list asking for review and sponsorship
[14:50] <psusi> launchpad.net/e2defrag, ppa:psusi/ppa
[14:50]  * patdk-wk has been hiding in +1 cause this channel is too noisy :)
[14:51] <bukayoo> psusi: from 35% non-contiguous to zero
[14:52] <BUGabundo_remote> wow
[14:52] <BUGabundo_remote> that's impressive t
[14:52] <Ian_corne> psusi: yes but not good enough :p
[14:52] <patdk-wk> oh, and I thought I was reading #ubuntu :)
[14:52] <Ian_corne> well not far enough
[14:52]  * BUGabundo_remote slaps patdk-wk
[14:52] <patdk-wk> I noticed when BUG said something :)
[14:53] <psusi> bukayoo: wow, you had 35% to start?
[14:54] <psusi> Ian_corne: what do you mean?
[14:54] <bukayoo> psusi: yes and that's an ext4 fs..expected bec I do a lot of rw to it..multimedia files and lots of vbox vdi files
[14:54] <psusi> bukayoo: is this an old ext3 fs?
[14:55] <bukayoo> psusi: nope it's a new ext4 from the start
[14:55] <Ian_corne> psusi: that 2.2.1 is released
[14:55] <psusi> hrm... I wouldn't expect to see that much fragmentation on ext4... especially with plenty of free space
[14:56] <psusi> Ian_corne: ohh, you mean freeciv just made a brand new release?  yea, it will take a while for someone to package and upload
[14:57] <Ian_corne> Well could be they maintained one
[14:57] <Ian_corne> themselves
[14:57] <Ian_corne> some developers do :)
[15:04] <psusi> bukayoo: how long did that take by the way?  if you have the memory you can speed it up by giving it more buffer pool to play with.. it defaults to only using 32mb... giving it 256 or 512 megs can help a good bit
[15:05] <bukayoo> psusi: I think about 30-40 mins?
[15:05] <psusi> outch
[15:06] <bukayoo> psusi: I have 6gig RAM
[15:07] <bukayoo> will do next time..however the other data drive about the same size has only .6% non-contiguous..can't explain why.. do the same amt of rw
[15:10] <wizard__> I'm using indicator-applet-appmenu but it only works for VLC, and nothing else.  Is anyone else experienceing this, or is it just me?  No other apps, no matter which ones I try (Ive tried dozens) it only works for VLC.
[15:27] <cwillu> !info ardour
[15:27] <gnomefreak> this is just great. no graphics and TTY is very very small
[15:27] <gnomefreak> even upstream drivers work
[15:28] <yofel> hm?
[15:28] <patdk-wk> /dev/sde: 943/715520 files (39.8% non-contiguous), 131174728/183143646 blocks
[15:28] <patdk-wk> that is just normal ext3, it's still karmic
[15:29] <gnomefreak> i can barely see the text in all the TTYs. it is due to nvidia not building against updated X
[15:29] <gnomefreak> agians kernel sorry
[15:29] <patdk-wk> hmm, strange, that disk only contains movies, that where copied there, an rsync from another drive
[15:29] <patdk-wk> wonder why it's so fragmented
[15:29] <patdk-wk> as no files where deleted or modified
[15:30] <yofel> gnomefreak: tried nvidia 256?
[15:30] <yofel> works fine here
[15:31] <yofel> I'm trying to rebuild the package for new X though
[15:31] <gnomefreak> .me tries PPA
[15:31] <yofel> I have it from x-updates
[15:31] <yofel> won't install with X1.8
[15:32] <gnomefreak> earlier it said it was removing nvidia-173 and -common but trying to install them says it is newest. but im trying PPa right now
[15:33] <gnomefreak> ?
[15:33] <gnomefreak> 256?
[15:34] <yofel> nvidia-current:
[15:34] <yofel>   Installed: 256.29-0ubuntu1~xup
[15:34] <yofel>   Candidate: 256.29-0ubuntu1~xup
[15:34] <Sarvatt> thanks for reminding me i need to rebuild that
[15:34] <gnomefreak> yofel: from our archives?
[15:34] <yofel> gnomefreak: no, x-updates ppa
[15:34] <yofel> Sarvatt: np ;)
[15:35] <Sarvatt> uploading now
[15:36] <yofel> thanks
[15:36] <gnomefreak> yofel: im still doiong them. but looking at policy it show install and canadte being 0.2.23 but i guess because it is still downloading
[15:36] <Sarvatt> nvidia-graphics-drivers shouldn't be providing an ABI in the first place, its compatible with multiple ones
[15:36] <gnomefreak> Sarvatt: rebuild what? im scared :/
[15:36] <gnomefreak> ah
[15:38] <patdk-wk> psusi, Failed to fetch http://ppa.launchpad.net/e2defrag/ppa/ubuntu/dists/maverick/main/binary-amd64/Packages.gz  404  Not Found
[15:38] <psusi> patdk-wk: don't think it build for maverick... just lucid
[15:39] <patdk-wk> oh heh
[15:39] <patdk-wk> on the launchpad page it said only maverick :)
[15:39] <patdk-wk> so that is where I attempted to try it :)
[15:40] <gnomefreak> now i just hope nvidia-current 256.29 works with my card
[15:40] <Sarvatt> what card?
[15:41] <gnomefreak> nvidia 6200
[15:41] <Sarvatt> nope :(
[15:41] <Sarvatt> and nvidia-173 doesn't work with 1.8 yet last I checked
[15:41] <bjsnider> support starts at the 6k series
[15:41] <gnomefreak> any other bad news i should know :(
[15:42] <gnomefreak> maybe i can go back to upstream drivers since the X updates
[15:42] <gnomefreak> updatees from PPA
[15:42] <Sarvatt> oh sorry, it might
[15:43] <Sarvatt> could you use nvidia-current before?
[15:43] <gnomefreak> Sarvatt: what about the 185?
[15:43] <Sarvatt> could you ever use it?
[15:43] <gnomefreak> Sarvatt: no drivers worked. i filed a bug on it
[15:43] <Sarvatt> if so you can, they didn't drop any older cards since 173
[15:43] <gnomefreak> not in last month
[15:43] <BUGabundo_remote> nvidia-current:  Installed: 195.36.24-0ubuntu1
[15:43] <knittl> hi guys
[15:44] <Sarvatt> BUGabundo_remote: you rebuild that? the one in the archive wont let you upgrade X stuff
[15:44] <gnomefreak> BUGabundo_remote: you rnot using PPA and that package didnt work for me either but i have nothing to lose but to try it
[15:45] <knittl> anyobdy interested in helping me fix my recurring sound problems with flash?
[15:45] <BUGabundo_remote> Sarvatt: gnomefreak: that's plain maverick archive for me
[15:45] <BUGabundo_remote> its on hold due to X upgrades
[15:45] <BUGabundo_remote> works nicely for me
[15:46] <knittl> in soundsettings i can see which streams are playing, and firefox [alsa-plugin] flickers there
[15:46] <Sarvatt> BUGabundo_remote: if you purge nvidia-current you can upgrade everything :)
[15:46] <BUGabundo_remote> I'm even scared for once the builds are all done... seem ill be without X for a while, again, this cycle
[15:46] <BUGabundo_remote> guess ill be testing nouveua again :)
[15:46] <gnomefreak> do X updates like i did and nvidia gets removed but i figured since ive been on upstream drivers it would hurt me. damn was i ever wrong
[15:46] <BUGabundo_remote> Sarvatt: will I still have an working blob for 3D?
[15:46] <gnomefreak> nouveua didnt work for me either
[15:48] <Sarvatt> just use x-updates for a few hours and ppa-purge -p x-updates ubuntu-x-swat after if you dont like the 256 drivers, i'm trying to get nvidia uploaded to the archive now
[15:48] <Sarvatt> well nvidia-current that works with maverick is still waiting to build in there
[15:50] <BUGabundo_remote> Sarvatt: I'm in no hurry :)
[15:50] <BUGabundo_remote> once its ready, ill update
[15:50] <gnomefreak> Sarvatt: will the nvidia-glx-180 work?
[15:50] <BUGabundo_remote> or better, my system will
[15:50] <Sarvatt> nvidia-glx-180 hasn't been a package in years
[15:51] <gnomefreak> its in maverick as a dummy package for the 195 drivers ir the 185 driver
[15:51] <Sarvatt> just empty transitional packages
[15:51] <patdk-wk> heh, working systems are so overrated :)
[15:51] <Sarvatt> yeah
[15:52] <BUGabundo_remote> yep
[15:52] <BUGabundo_remote> tell me about it
[15:52] <gnomefreak> my upstream drivers are 195* but wont build against kernel or X i dont recall
[15:52] <Sarvatt> only using blobs on development releases is nuts :)
[15:52] <BUGabundo_remote> I spent , last cycle, more time in #-x then in here
[15:53] <Sarvatt> could be worse, you could be using fglrx :)
[15:53] <BUGabundo_remote> ahahahahaha
[15:53] <BUGabundo_remote> don't remind me
[15:54] <BUGabundo_remote> I have my bros laptop in karmic still
[15:54] <BUGabundo_remote> want to upgrade it, but after the horror stories I hear, its better like it is now
[15:54] <gnomefreak> its not building against the kernel mods. im wondering if i can use a lower kernal
[15:55] <yofel> BUGabundo_remote: dd the HDD, upgrade and dd the image back when it fails?
[15:55] <Sarvatt> BUGabundo_remote: 195 builds against the maverick kernel for you?
[15:57] <BUGabundo_remote> Sarvatt: yep
[15:57] <BUGabundo_remote> all but 2.6.23
[15:57] <Sarvatt> ok tseliot is uploading nvidia-* soon :)
[15:58] <BUGabundo_remote> which I was using cause of desktop couch bug
[15:58]  * BUGabundo_remote is afraid
[15:58] <gnomefreak> good maybe we will have it in next day or 2.
[15:58] <yofel> 23? you mean 33
[15:58] <BUGabundo_remote> doh
[15:58] <BUGabundo_remote> follow mouse, not eyes
[15:58] <Sarvatt> BUGabundo_remote: oh, wonder why it doesn't work for gnomefreak
[15:59] <gnomefreak> Sarvatt: any idea what is wrong with the ISOs?
[15:59] <Sarvatt> what's wrong with them?
[15:59] <gnomefreak> upstream drivers wont build
[16:00] <gnomefreak> Sarvatt: the current alternate they are only there for a day and take 2 days off. when they are there they are oversized
[16:00] <Sarvatt> no space?
[16:00] <gnomefreak> 704mb  but tis known they are oversized
[16:00] <Sarvatt> they've been screwed up for the past few days while X was getting sorted
[16:00] <gnomefreak> Sarvatt: ah ok that is a good reason
[16:00] <BUGabundo_remote> nvidia 5400mG
[16:00] <Sarvatt> before that there was another problem but i forgot what it was
[16:00] <BUGabundo_remote> I thk
[16:01] <Sarvatt> there should be one from today though?
[16:01] <gnomefreak> Sarvatt: past week they have not even been there most days
[16:01] <patdk-wk> hmm, ok installed ppa, installed e2defrag
[16:01] <gnomefreak> Sarvatt: todays is oversized when i looked ~3 hours ago
[16:01] <patdk-wk> have readme files, and stuff, and e2freefrag
[16:01] <Sarvatt> yeah todays should be the first since monday
[16:01] <patdk-wk> but there is no *defrag* program on my machine :(
[16:02] <BUGabundo_remote> 01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce 8400M G] (rev a1)
[16:02] <BUGabundo_remote> silly me
[16:02] <BUGabundo_remote> don't even recall my own hw
[16:02] <BUGabundo_remote> too many machines to know :S
[16:02] <gnomefreak> the 173 wont build against kernel
[16:02] <gnomefreak> patdk-wk: there should be one in the archives
[16:03] <Sarvatt> things got held up because none of us working on the X packages this time could upload to main and its over 50 packages :(
[16:03]  * gnomefreak may drop to another kernel or use my Lucid install for a while since i have to check email
[16:05] <gnomefreak> eh ISOs are not really important atm
[16:06] <Sarvatt> nouveau doesn't work for ya?
[16:06] <gnomefreak> Sarvatt: no they didnt
[16:06] <gnomefreak> iw ill try again in a few
[16:06] <Sarvatt> gnomefreak: you removed the nvidia drivers first?
[16:07] <gnomefreak> s/iw ill/1 will
[16:07] <gnomefreak> Sarvatt: apt did that for me :)
[16:07] <gnomefreak> Sarvatt: i am running a few things atm but i will try soon
[16:08] <Sarvatt> ah, if it doesn't work a bug would be appreciated if possible, need to get that fixed
[16:08] <gnomefreak> be back in a few, Sarvatt i dont recall bug # but i did file one. my Lp page should have it in reported bugs section
[16:08] <Sarvatt> ah alrighty will check
[16:08] <Sarvatt> ~gnomefreak?
[16:09] <gnomefreak> that should give you everything if not i will add to it when i can just comment on bug so if i switch to Lucid i will know
[16:09] <gnomefreak> Sarvatt: yes
[16:09] <gnomefreak> .:11:00:05:. <      gnomefreak > Sarvatt: the current alternate they are only there for a day and take 2 days off. when they are there they are oversized
[16:09] <gnomefreak> damn that is odd
[16:10] <gnomefreak> i was playing with mouse pleae ignore that
[16:11] <patdk-wk> in the *archives*?
[16:11] <patdk-wk> I did a, find / -name '*defrag*'
[16:11] <patdk-wk> and it couldn't find one
[16:12] <patdk-wk> oh, it didn't install fro mthe ppa :(
[16:12] <gnomefreak> patdk-wk: try apt-cache search defrag it should bring up some
[16:12] <patdk-wk> e2defrag - ext[234] filesystem defragmenter
[16:12] <patdk-wk> that is what I installed
[16:12] <patdk-wk> thought it was from the ppa
[16:12] <patdk-wk> cause it installed the ppa
[16:12]  * patdk-wk is really confused now
[16:13] <gnomefreak> running the search c0ommand searches PPA and normal archives
[16:13] <patdk-wk> deb http://ppa.launchpad.net/e2defrag/ppa/ubuntu lucid main
[16:14] <gnomefreak> libnids1.21
[16:14] <patdk-wk> Maintainer: Phillip Susi <psusi@cfl.rr.com>
[16:14] <patdk-wk> Architecture: amd64
[16:14] <patdk-wk> Version: 0.75
[16:14] <patdk-wk> Depends: file
[16:14] <patdk-wk> Filename: pool/main/d/defrag/e2defrag_0.75_amd64.deb
[16:14] <patdk-wk> libnids?
[16:14] <gnomefreak> patdk-wk: Lucid is not in this challen
[16:14] <patdk-wk> I know
[16:14] <patdk-wk> why I was confused we where talking about it, but it wouldn't install on maverick
[16:14] <patdk-wk> and I was talking to psusi :)
[16:15] <gnomefreak> he wasnt talking to you ;)
[16:15] <Sensiva> psusi Do you know any resources that talks about fragmentation in ext* filesystems?
[16:15] <patdk-wk> it's irc
[16:16] <patdk-wk> people are always afk :)
[16:16] <patdk-wk> but if you don't explain, well, it's pointless to just wait :)
[16:16]  * gnomefreak tries to be. ill be back ina few going to try something
[16:16] <psusi> Sensiva: google?  there's one article that I've seen tossed about on the ubuntu forums that is not too horrible ;)
[16:17] <BUGabundo_remote> patdk-wk: apt-cache policy e2defrag
[16:17] <BUGabundo_remote> will tell you the source of the install
[16:17] <BUGabundo_remote> archive or ppa
[16:17] <Sensiva> ty
[16:18] <psusi> patdk-wk: it won't install on maverick eh?  hrm...
[16:18] <patdk-wk> maverick was the 404 not found error
[16:18] <patdk-wk> on lucid it installs
[16:18] <patdk-wk> but there is no e2defrag program
[16:18] <patdk-wk> just /usr/share/doc/e2defag files
[16:19] <psusi> dpkg -L defrag... should be there
[16:19] <patdk-wk> using amd64 version
[16:19] <patdk-wk> nope
[16:20] <psusi> think it's in sbin
[16:20] <patdk-wk> add-apt-repository ppa:e2defrag/ppa
[16:20] <patdk-wk> apt-get update, apt-get install e2defrag
[16:22] <psusi> patdk-wk: it's in /usr/sbin...
[16:23] <patdk-wk> root@oplex960-1:/usr/sbin# ls *defrag*
[16:23] <patdk-wk> ls: cannot access *defrag*: No such file or directory
[16:24] <patdk-wk> now e2freefrag is in there
[16:24] <psusi> then the package isn't installed?
[16:24] <psusi> that's part of e2fsprogs
[16:24] <patdk-wk> e2defrag is installed
[16:24] <yofel> patdk-wk: 'dpkg -L e2defrag | pastebinit'
[16:25] <patdk-wk> http://e2defrag.pastebin.com/rHsqva0B
[16:25] <patdk-wk> I was just doing that
[16:25] <yofel> odd
[16:25] <psusi> what's apt-get policy say?  you got version 0.77 right?
[16:25] <patdk-wk> invalid operation
[16:26] <psusi> err, apt-cache policy
[16:26] <patdk-wk> 0.75 :(
[16:26] <patdk-wk> slow mirrors?
[16:27] <yofel> ppas aren't mirrored
[16:27] <psusi> ppas aren't mirroed afaik
[16:27] <patdk-wk> I didn't think so
[16:27] <BUGabundo_remote> patdk-wk: apt-cache policy e2defrag | pastebinit
[16:27] <patdk-wk> http://pastebin.com/9YZmhLQf
[16:27] <yofel> not yet published maybe?
[16:27] <psusi> it's published according to the ppa page, and someone else managed to install it just fine
[16:27] <BUGabundo_remote> maybe
[16:27] <yofel> hm
[16:27] <patdk-wk> I'm on amd64 though
[16:28] <patdk-wk> where they?
[16:28] <psusi> dunno, but I am as well
[16:28] <psusi> and I just downloaded the binary package and checked, and the files are in there... https://launchpad.net/~psusi/+archive/ppa/+packages
[16:29] <psusi> ohh, you aren't using my ppa
[16:29] <psusi> you're using the e2defrag group ppa...
[16:29] <patdk-wk> oh?
[16:30] <psusi> I guess I should have uploaded it there but I just used my personal one
[16:31] <psusi> yea, it says launchpad.net/e2defrag/ppa/ubuntu... should be /psusi
[16:31] <psusi> apt-add-repository ppa:psusi/ppa
[16:31] <patdk-wk> ok, it's loaded
[16:31] <psusi> and the package is just defrag again, not e2defrag
[16:31] <patdk-wk> and working now :)
[16:32] <patdk-wk> too many different ppa's :)
[16:35] <patdk-wk> defently needs more colors :)
[16:35] <psusi> hehe
[16:36] <patdk-wk>  it's so much slower without -r
[16:36]  * patdk-wk files a bug report
[16:36] <psusi> lol
[16:38] <patdk-wk> it's also on an encrypted block device
[16:39] <psusi> I hope you aren't running it on data you don't want to loose ;)
[16:39] <patdk-wk> it's a nightly backups of my colo server
[16:39] <patdk-wk> I have it backed up on other machines also
[16:40] <psusi> throwing more buffer space at it can speed things up too
[16:40] <patdk-wk> didn't see an option for that
[16:40] <psusi> -p
[16:40] <patdk-wk> ok, it wasn't an option in -h :)
[16:41] <psusi> ohh, yea, that's probably out of date... read the man page ;)
[16:41] <patdk-wk> when it gets done :)
[16:41] <patdk-wk> control-c, q, esc, doesn't work to stop it :)
[16:41] <psusi> yea, stopping it would be bad ;)
[16:41] <patdk-wk> so it's not a safe defrag?
[16:42] <psusi> if it gets interrupted, kiss your fs goodby
[16:42] <psusi> nope
[16:42] <patdk-wk> I would defently make it safe, duplicate the blocks
[16:42] <patdk-wk> update inode info to new blocks
[16:42] <patdk-wk> then if power goes out in the middle your good
[16:42] <patdk-wk> does slow it down some, but not much
[16:43] <psusi> it was made to be fast rather than safe... it updates all of the inodes first, then starts relocating the blocks in the largest contiguous chunks it can to minimize seeking
[16:43]  * patdk-wk marks it down as evil defrag :)
[16:43] <psusi> actually it would slow it down a good deal...
[16:43] <patdk-wk> must take ones own protective measures before hand :)
[16:44] <psusi> hence the make a full backup first warning ;)
[16:44]  * patdk-wk wonders if he should try it on a 500gig drive with >60M inodes used
[16:45] <psusi> the default 32 meg buffer pool doesn't lend itself to minimizing seeks very well on modern disks... does quite a bit better with a larger pool
[16:46] <psusi> I actually just wrote a patch to reduce memory usage with lots of free inodes... right now it allocates an array of ints for the inode order map... one for each inode, which is a few hundred mb on a 1.5 tb disk... also iirc an int ends up being 8 bytes on amd64 when inode numbers are only 32 bit anyhow
[16:47] <psusi> so I just changed it to use a __u32 and only allocate as many as there are USED inodes
[16:47] <ActionParsnip> hey guys
[16:48] <ActionParsnip> is there an equiv to ALT+F2 in UNE maverick ?
[16:48] <ActionParsnip> doesn't seem to fly
[16:50] <patdk-wk> hmm, up to 10gigs moved now
[16:51] <psusi> it also tries very hard to only move a given block once.. which means it writes a block to its new location, first reading the old data to rescue it from being overwritten if needed.. so if you crash at that point, the rescued data is only in ram and so is lost
[16:52] <patdk-wk> 4.6M inodes, using 90megs of ram
[16:52] <psusi> a larger pool would definately have helped ;)
[16:52] <ActionParsnip> does anyone use the netbook edition? Seems a bit weird
[16:53] <patdk-wk> I only have 12gigs of ram, 10gigs free :)
[16:54] <BUGabundo_remote> *only*
[16:54] <psusi> mmmm..... 6 gig buffer pool...... it could do sequential reads for minutes at a time before seeking to write
[16:55] <patdk-wk> I build vm's on this machine
[16:55] <patdk-wk> so I need lots of memory, then I don't :)
[16:55] <ActionParsnip> where is alt+f2 :(
[16:58] <patdk-wk> hmm, it on the last part
[16:58] <patdk-wk> all seq
[16:58] <psusi> it's kinda funny watching iotop when you give it a large buffer pool.... you see max read io for a while.... then max write io for a while...
[16:59] <patdk-wk> I'm doing about 32MB/s read and write on iotop
[16:59] <psusi> I should have it check how much free ram you have and up the default buffer pool size automatically if you don't specify it
[16:59] <patdk-wk> half of free ram?
[16:59] <psusi> sounds good
[17:00]  * patdk-wk wonders if free ram should include buffers + cache
[17:00] <psusi> problem is if it tries to use too much, it could end up being killed in the middle by the OOM killer
[17:00] <patdk-wk> I guess it should
[17:00] <psusi> yes, it should
[17:00] <patdk-wk> they haven't put in the kernel patch so programs can protect themselfs from OOM?
[17:00] <patdk-wk> I thought I saw that years ago?
[17:00] <patdk-wk> I know it was floating around in v2.0
[17:01] <psusi> I think there's some way to change the oom priority yea, so it will try to kill other things instead
[17:01] <patdk-wk> but I haven't payed much attention to the kernel since 2.2
[17:01] <psusi> but you still don't want to run out of memory
[17:01] <patdk-wk> alloc, lock, stop-oom
[17:01] <patdk-wk> should be good enough
[17:01] <psusi> yea, I suppose I could lock the pages....
[17:02] <patdk-wk> lock from swapping :)
[17:02] <patdk-wk> and if <512megs ram free, keep buffer small?
[17:03] <patdk-wk> ok, it's done
[17:03] <psusi> now e2fsck -f
[17:03] <patdk-wk> it left 4 things not sorted
[17:03] <psusi> what do you mean?
[17:03] <patdk-wk> all the *data* blocks are in a line
[17:03] <patdk-wk> except 4 of them
[17:03] <patdk-wk> well, 4 clusters
[17:04] <psusi> it tries to locate blocks in the block group of the owning inode, so it can leave some gaps
[17:04] <psusi> if some block groups don't have many or large inodes
[17:05] <patdk-wk> http://www.maneshi.com/gallery/v/Users/sysadm/Screenshot-root_oplex960-1_+-etc-apt-sources_list_d.png.html
[17:06] <patdk-wk> fsck -f was clean before
[17:06] <patdk-wk> Inode 140789 has out of order extents
[17:06] <patdk-wk> 	(invalid logical block 28672, physical block 8323072, len 32768)
[17:06] <psusi> ruh-roh
[17:06] <patdk-wk> clear?
[17:06] <Ian_corne> :p
[17:06] <patdk-wk> I guess so, since I don't care :)
[17:06] <psusi> no, stop it and umm.... let me ssh in ;)
[17:07] <patdk-wk> too late
[17:07] <psusi> or e2image
[17:07] <patdk-wk> Pass 1: Checking inodes, blocks, and sizes
[17:07] <patdk-wk> Inode 140789 has out of order extents
[17:07] <patdk-wk> 	(invalid logical block 28672, physical block 8323072, len 32768)
[17:07] <patdk-wk> Clear<y>? yes
[17:07] <patdk-wk> Inode 140789 has out of order extents
[17:07] <patdk-wk> 	(invalid logical block 61440, physical block 8355840, len 26624)
[17:07] <psusi> damn... need to analyze it with debugfs
[17:07] <patdk-wk> Clear<y>? yes
[17:07] <patdk-wk> Inode 140789, i_blocks is 955296, should be 255648.  Fix<y>? yes
[17:07] <patdk-wk> ^C/dev/mapper/udisks-luks-uuid-5c1a5a03-8ab0-4c2c-9ce3-e0bf9f901e3d-uid1000: e2fsck canceled.
[17:07] <patdk-wk> I'm sure there are more wrong
[17:07] <patdk-wk> it wsa just getting started :)
[17:08] <patdk-wk> or maybe not
[17:08] <patdk-wk> running fsck -f again
[17:08] <patdk-wk> Block bitmap differences:  -(1522279--1527172) -(1540096--1560756) -(1581088--1597410) -(1606657--1630207) -(1638607--1660633)
[17:08] <patdk-wk> Fix<y>?
[17:08] <patdk-wk> still want in?
[17:08] <psusi> yea, may as well fix that
[17:08] <psusi> the bitmap is now wrong because it freed those blocks in the first step
[17:09] <patdk-wk> ok
[17:09] <psusi> the question is, how/why did defrag screw up the extent tree...
[17:09] <patdk-wk> I'll not do that again
[17:09] <patdk-wk> this is ext3 though, I didn't tink it's converted to ext4
[17:09] <patdk-wk> so there shoulnd be any?
[17:09] <psusi> hrm.... fsck seems to think there's extents there....
[17:10] <patdk-wk> Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
[17:10] <patdk-wk> it does
[17:10] <patdk-wk> so guess it got converted (cause I didn't do it)
[17:11] <psusi> hrm... is that inode a 3 gig file?
[17:12] <patdk-wk> how would I check?
[17:12] <patdk-wk> but I doubt it, it's a backup of a mailspool
[17:12] <psusi> debugfs /dev/foo and ncheck 140789
[17:12] <psusi> to get the name of the file
[17:13] <patdk-wk> 467meg access.log
[17:13] <psusi> I did test it with a 4 gig dvd image file on the fs once and ran into problems with unallocated extents... but thought I fixed it
[17:14] <psusi> it is 467 meg now, or was before? :)
[17:14] <patdk-wk> will sync it from the colo and find out :)
[17:15] <psusi> you did say yes to e2fsck to fix the block count right?
[17:15] <patdk-wk> yep :(
[17:16] <patdk-wk> 489m on the colo
[17:16] <patdk-wk> actually 466megs on the colo
[17:16] <psusi> hrm... wonder if it was horribly fragmented before and somehow screwed up shrinking the size of the extent tree after defragging...
[17:16]  * patdk-wk notes it grew?
[17:18] <patdk-wk> hmm, it sounds like a believe able size
[17:18] <patdk-wk> freebsd vs linux is rounding megs dfferently
[17:19] <psusi> I'll have to look up that error message in the e2fsck sources and figure out exactly what it decided was wrong... but that's for later.. it's lunch time!
[17:20] <patdk-wk> overrated :)
[17:29] <BUGabundo_remote>  aptitude -v moo
[17:29] <BUGabundo_remote> There really are no Easter Eggs in this program.
[17:32] <ActionParsnip> BUGabundo_remote: sl is kinda like an easter egg
[17:33] <yofel> meh, kde sure is broken, desktop settings don't survive a logout :/
[17:33] <h00k> silly x, why did you die
[17:33] <BUGabundo_remote> yofel: don't turn it of then
[17:34] <yofel> BUGabundo_remote: settings, not effects
[17:34] <yofel> it resets the  background to default and doesn't display any widgets after login
[17:35] <geser> BUGabundo_remote: try adding more 'v' to that aptitude call :)
[17:35] <BUGabundo_remote> I know geser
[17:35] <BUGabundo_remote> -vvvv
[17:36]  * BUGabundo_remote is getting kicked
[17:36] <BUGabundo_remote> $ aptitude -vvvvv moo
[17:36] <BUGabundo_remote> All right, you win.
[17:36] <BUGabundo_remote>                                /----\
[17:36] <BUGabundo_remote>                        -------/      \
[17:36] <BUGabundo_remote>                       /               \
[17:36] <BUGabundo_remote>                      /                |
[17:36] <BUGabundo_remote>    -----------------/                  --------\
[17:36] <BUGabundo_remote>    ----------------------------------------------
[17:36]  * BUGabundo_remote hides
[17:36] <yofel> What is it?  It's an elephant being eaten by a snake, of course.
[17:36] <yofel> :P
[17:36] <yofel> haven't tried that in a while :D
[17:37] <ActionParsnip> i hope you guys have sl installed CHOO-WOO
[17:37] <yofel> heh
[17:53] <crimsun_> cwillu: what do you need?
[17:55] <knittl> what abotu all this xserver-xorg-video-* stuff?
[17:55] <knittl> remove -all an -tseng?
[17:56] <crimsun_> what about it?
[17:57] <knittl> can i remove those two packages or do i have to wait until it resolves itself?
[17:58] <knittl> hm oh, dist-upgrade will keep everything else back and remove them. that's stupid
[17:58] <knittl> so … back to waiting?
[18:02] <crimsun_> -all is a meta; it's fairly unimportant
[18:02] <crimsun_> you're quite unlikely to be using -tseng
[18:03] <knittl> i guess there's some dependency missing
[18:03] <crimsun_> if you don't mind reinstalling -all afterward (i.e., being proactive in tracking dependencies as they're updated), there's no reason to hold back the needed driver
[18:03] <crimsun_> if you're at all unsure, you'll want to hold off updating
[18:03] <knittl> dist-upgrade will not upgrade any packages, it will only remove two, so it doesn't make sense
[18:04] <knittl> seems like nvidia-current is the culprit
[18:23] <psusi> alright, yuo win?  lol...
[18:44] <BUGa_vacations> and so it beggins :|
[18:47] <h00k> hrm?
[18:48] <patdk-wk> hell :)
[18:55] <psusi> patdk-wk: if you can reproduce that problem and get me an e2image file before and after, I should be able to debug it
[18:55] <patdk-wk> before and after the defrag?
[18:56] <psusi> yea
[18:56] <patdk-wk> ok, but I am leaving on work trip tonight, and won't be back for a week
[18:56] <patdk-wk> so it will be alittle bit :)
[18:56] <psusi> or hell, just before should be enough... I should be able to run defrag on it myself and get the same result ;)
[18:57] <patdk-wk> e2image makes a copy of the fs?
[18:57] <patdk-wk> oh, just the fun stuff
[18:57] <psusi> sort of... it just includes the inodes... no normal data
[18:57] <patdk-wk> just non-block data
[18:57] <psusi> yea
[18:58] <psusi> I don't care what is in the blocks, just where they were
[19:00] <patdk-wk> fun
[19:00] <patdk-wk> 1.1G in normal
[19:00] <patdk-wk> and 69G in raw mode
[19:01] <psusi> pipe it to bzip2 like the man page suggests... it's mostly zeroes so will compress down quite well
[19:01] <patdk-wk> well, there is no point to doing a raw dump over a normal
[19:01] <patdk-wk> I am comparing how both methods compress though
[19:04] <patdk-wk> well, -r is horrible :(
[19:04] <patdk-wk> the none -r one compressed to 9.3megs
[19:05] <patdk-wk> the -r compressed one is at 73megs is still growing
[19:11] <patdk-wk> ya, it is taking gzip forever and it's still not done and it's so much bigger :(
[19:11] <psusi> damn... you have many used inodes I guess...
[19:11] <patdk-wk> only 5M
[19:12] <psusi> each one needs about a kb in the image file so... ;)
[19:12] <patdk-wk> but it's the -r that is the issue
[19:12] <patdk-wk> probably cause it's dumping empty ones too
[19:13] <patdk-wk> just dumping a normal one, then compress, makes it nice and small :)
[19:13] <psusi> without -r it just doesn't bother including the directories and extent trees
[19:13] <patdk-wk> ah :(
[19:13] <patdk-wk> oh well, will just have to let it go
[19:19]  * psusi tries creating a 3 tb zero volume and then a 5 gig snapshot of it with lvm to end up with a thin provisioned gigantic virtual disk
[19:33] <jcastro> I am looking for volunteers who have a lucid machine and are testing the unity ppa, if you want to help please join me in #ayatana!
[19:35] <BUGa_vacations> I would .... but I'm depressed
[19:44] <patdk-wk> ya, vacations suck
[20:01] <uga> Anyone found that after upgrading to maverick, the intel gfx card does only 50fps?
[20:01] <uga> I've digged google ,bug reports, etc, but nothing found
[20:02] <uga> (glxgears test)
[20:02] <Ian_corne> uga: where do you see this 50 fps
[20:02] <Ian_corne> aha
[20:02] <Ian_corne> i'll check
[20:02] <uga> it says around 200 frames in 5s
[20:02] <uga> and glxinfo seems to say everything is correct
[20:02] <Daekdroom> uga, what does glxinfo | grep OpenGL say?
[20:02] <Ian_corne> grep -i
[20:03] <uga> OpenGL vendor string: Tungsten Graphics, Inc
[20:03] <uga> OpenGL renderer string: Mesa DRI Intel(R) 965Q GEM 20100328 2010Q1
[20:03] <uga> OpenGL version string: 2.1 Mesa 7.8.1
[20:03] <Ian_corne> installing mesa-utils :)
[20:03] <Ian_corne> 261 frames in  5 seconds
[20:03] <Ian_corne> 144
[20:03] <uga> yes, sounds as bad as mine
[20:04] <uga> iirc, this card used to be better at it?
[20:04] <psusi> oh wow, that freed up a ton of ram...
[20:04] <crdlb> uga: have you tried a real 3d app?
[20:04] <uga> such as=?
[20:04] <Daekdroom> What bugs me is the OpenGL vendor string: Tungsten Graphics, Inc
[20:04] <crdlb> uga: an OpenGL game?
[20:04] <patdk-wk> what?
[20:05] <uga> crdlb: no, this is not a gaming machine. I'm mostly concerned about effects rendering etc
[20:05] <Ian_corne> $ glxinfo | grep OpenGL | pastebinit
[20:05] <Ian_corne> http://pastebin.com/wfbavGUQ
[20:05] <psusi> patdk-wk: you talking to me?
[20:05] <patdk-wk> ya
[20:05] <uga> crdlb: not a single game installed (work box ;))
[20:05] <Ian_corne> compiz is disabled
[20:05] <Ian_corne> openarena is a good test
[20:06] <Ian_corne> but my eee won't run that :p
[20:06] <Ian_corne> uga: if you just upgraded, chances are you have the new xserver
[20:06] <Daekdroom> It seems it's using the gallium driver over classic mesa.
[20:06] <Ian_corne> at least, I do
[20:06] <uga> ah
[20:07] <psusi> patdk-wk: it was computing the average location of each inode's data blocks to assist in sorting the inode optimization order... so that a higher numbered inode that happens to have most of its data blocks earlier on the disk than a lower number inode, it would optimize the higher number inode first to keep its data blocks before the other one rather than swap them
[20:07] <crdlb> uga: you're using maverick on your work box? ;)
[20:07] <uga> crdlb: after I did heavy testing at home, yes
[20:07] <psusi> patdk-wk: this used 4 bytes of ram to hold the average position of every possible inode on disk... which adds up when you have 60 million possible inodes on a 1 tb disk ;)
[20:07] <uga> this is a good time for an upgrade....
[20:07] <uga> crdlb: unfortunately my home box runs on nvidia
[20:07] <psusi> I don't think that feature is actually very useful so I tore it out...
[20:08] <Daekdroom> Good lord, uga, I'm a fan on bleeding edge and I'm afraid to use Maverick
[20:08] <crdlb> uga: I hope you realize it will probably break several times before now an release, right? :)
[20:08] <Daekdroom> I'm waiting for the API freeze + 2 days or so.. Less likely to break after then
[20:08] <kroson> hi everyone what is the default nvidia driver that maverick is using?
[20:08] <Daekdroom> kroson, nouveau
[20:08] <kroson> tks
[20:08] <psusi> patdk-wk: went from using ~400 megs of ram to defrag a 1tb fs to 175
[20:08] <patdk-wk> psusi it would probably be much more useful to do that by directory
[20:08] <patdk-wk> then per inode
[20:08] <kroson> Daekdroom: what version? 3d-enabled? mesa classic or gallium?
[20:08] <kroson> tks
[20:08] <uga> crdlb: I know, I know... I can work on vi and gcc though. I just need a working xorg and a virtualbox mostly ;)
[20:08] <patdk-wk> and group all inodes per directory together
[20:08] <crdlb> it's barely even an alpha
[20:09] <Daekdroom> kroson, well, about that I don't know..
[20:09] <uga> it was the best time for an upgrade, and I always test changes at home before doing anything at workplace
[20:09] <Daekdroom> kroson, but I believe 2-D only, classic Mesa.
[20:09] <patdk-wk> well, I'm outtahere
[20:09] <kroson> ok tks
[20:09] <kroson> xD
[20:09] <uga> I had a few probs with booting, but nothing unsolvable
[20:09] <crdlb> uga: I hope your hardware at home is identical ...
[20:09] <uga> hehe
[20:10] <Daekdroom> You should also test any updates at home before updating over work..
[20:10] <Daekdroom> O.o
[20:10] <uga> yups, that's my initial plan
[20:10] <uga> if I didn't upgrade today, I'd not upgrade till next year
[20:11] <uga> as I said, I can survive with no desktop, as far as I have vi and a simple Xorg window ;P
[20:12] <uga> (and if everything fails, restore / in about 30 mins)
[20:12] <kroson> will 10.10 include the new gnome 3.0?
[20:12] <Daekdroom> kroson, yes, just not Gnome Shell
[20:12] <kroson> ok fine
[20:12] <kroson> if i test maverick i will get the latest version of gnome right?
[20:13]  * uga reads on about gallium...
[20:14]  * psusi wonders just how large of a thin provisioned disk he can make with lvm.... an exebyte?  hrm...
[20:18] <nperry> Wow, that was a smooth X transation!
[20:18] <nperry> All went fine
[20:20] <nperry> Hmmmmm, Moc doesn't seem to be working :/
[20:30] <siimo> the maverick meercat boot cd kernels panics with sync hd(0,0) or something.. basically it cant recognize my hdd/partitions...
[20:31] <ActionParsnip> yo yo yo
[20:31] <siimo> =/
[20:32] <psusi> siimo: sounds like your grub config is messed up and not loading the initrd
[20:32] <ActionParsnip> is the app bar on the left the new gnome desktop design in maverick?
[20:32] <siimo> psusi: this is off the boot cd though
[20:32] <siimo> http://us.archive.ubuntu.com/ubuntu/dists/maverick/main/installer-i386/current/images/netboot/mini.iso
[20:32] <siimo> ^
[20:34] <uga> Ian_corne: strangely, openarena tests dont' seem too bad
[20:34] <uga> although I can run it only under 640x480
[20:35] <uga> is it that the mesa api got deprecated or something? =)
[20:37] <Ian_corne> I have no idea
[20:38] <Ian_corne> altho since 2.6.28 intel graphics have been bad
[20:39] <ActionParsnip> Ian_corne: works fine here
[20:39] <Ian_corne> what works fine?
[20:39] <ActionParsnip> Mobile 945GM
[20:39] <ActionParsnip> intel vga
[20:40] <Ian_corne> It works
[20:40] <Ian_corne> but doesn't perform as well as it should
[20:41] <ActionParsnip> Ian_corne: not had an issue here personally. I read that some intel chips can get a boost with som package or somesuch
[20:41] <ActionParsnip> was on omg ubuntu of all places
[20:45] <yofel> IMHO the intel performance got worse again with xserver 1.8, at least it does feel so on my 945GME
[20:46] <yofel> and since updating X I can't enable a bunch of kwin effects anymore
[20:46] <h00k> I hope that Unity gets some sort of better application launcher than just opening the folder :|
[20:48] <crimsun_> h00k: heh, I just background the executable invocation in a terminal emulator ;)
[20:48] <vish> h00k: expecting ponies , i see
[20:48] <uga> ActionParsnip: Ian_corne: I tested a mcahine I have here, same gfx card, but still not upgraded... it does >500fps easily
[20:48] <uga> on glxgears
[20:48] <uga> tahts' around 10 times as much
[20:49] <crdlb> yes, but glxgears only tells you how fast it runs glxgears
[20:49] <h00k> !pony
[20:49] <h00k> d'aw.
[20:49] <uga> crdlb: is a 17fps score in openarena good?
[20:49] <h00k> vish: not ponies, just something decent :(
[20:49] <h00k> crimsun_: Yes, that does work, it's kind of a pain
[20:50] <uga> crdlb: glxgears is a pretty basic test
[20:50] <crdlb> uga: certainly not, but I have no idea what the drivers on lucid could do with that gpu
[20:50] <crimsun_> h00k: absolutely. OTOH, I'm a terminal emulator person mainly, so it's no sweat.
[20:51] <uga> crdlb: that's what I just told you. around 2100 frames in 5s in lucid
[20:51] <uga> vs 200frames in 5s for maverick
[20:51] <crdlb> uga: I don't care about glxgears on lucid, only openarena on lucid
[20:51] <uga> ah well
[20:51] <uga> I can't go and install openarena everywhere on my work machines  I'm afraid
[20:52] <uga> and I don't think the main issue about a desktop is openarena anyway
[20:52] <h00k> crimsun_: and it's nice if you know the name of what you want to run
[20:52] <uga> but wehen dektop effects get disabled bececause checks say it's slow, that's trouble
[20:52] <crdlb> although 50fps is below vsync even, so my guess is that there really is a performance regression
[20:52] <ActionParsnip> so is the left hand bar thing the default in gnome desktop or is it a remnant of the netbook
[20:53] <uga> doing more tests...
[20:54] <h00k> crimsun_: for instance, I don't know what executable to call for 'Appearance' or 'network connections'
[20:54] <h00k> etc,
[20:54] <Ian_corne> gnome-appearence-properties
[20:54] <Ian_corne> :p
[20:55] <duffydack> Ive added the unity ppa in maverick, all updated and installed unity, yet its not showing up in the login menu.  Its ok on my lucid netbook
[20:56] <ActionParsnip> duffydack: does the ppa have a maverick entry?
[20:57] <h00k> duffydack: unity is in the normal repository
[20:57] <h00k> duffydack: in maverick, you don't have to install the ppa
[20:57] <duffydack> Ah...
[20:57] <h00k> duffydack: and for me, unity launched along with netbook-launcher on the Netbook Edition session, I just disabled netbook-launcher
[20:59] <h00k> duffydack: YRMV
[21:00] <Ian_corne> YMMV?
[21:00] <Ian_corne> or what does YRMV mean?
[21:00] <duffydack> also.. im using the touch the light theme (see omgubuntu) and its got the buttons on the right, and I have used the gconftool-2 --set "/apps/metacity/general/button_layout" --type string "close,minimize,maximize" command to set to the left which it has, but the "menu" is still on the right, how do I get rid.
[21:00] <Ian_corne> your result may vary?
[21:01] <h00k> Your results may vary
[21:04] <duffydack> nevermind... ok I still cant see unity.. i have removed the ppa and removed the package...and reinstalled
[21:32] <delac> can anyone tell if Meerkat will reintroduce settings for Indicator  Applet Session? (I'm mostly concerned about the "don't ask password" setting)
[22:05] <z0rt|work> the new netbook remix gui is interesting
[22:05] <BUGa_depressed> unity?
[22:06] <BUGa_depressed> yes it is
[22:06] <BUGa_depressed> very very fast too
[22:06] <ripps> Something's up with the latest updates. After about an hour, everything starts to segfault and my desktop slow crashes
[22:06] <z0rt|work> i like the root terminal application
[22:06] <BUGa_depressed> ripps: let me check, also go look in syslog and kernel log please
[22:07] <h00k> I've had x die completely twice today
[22:08] <BUGa_depressed> metacity?
[22:08] <BUGa_depressed> yeah, there's something frisky there
[22:08] <h00k> no, x. I get bumped out to a GDM
[22:08] <BUGa_depressed> also exaile will render X deade
[22:08] <h00k> It's happened opening new dialogs, it seemed
[22:08] <ripps> BUGa_depressed: http://pastebin.com/MyiwPvbr
[22:08] <ripps> I can't even a browser now.
[22:09] <BUGa_depressed> ripps: nothing in the upgrade queue that would cause that
[22:09] <BUGa_depressed> did you force X upgrades?
[22:09] <BUGa_depressed> they are on hold until everything is build
[22:09] <BUGa_depressed> [ 2992.238827] gnome-about[10950]: segfault at 695cb ip 00fadaac sp bfa81464 error 4 in ld-2.12.so[fa4000+1c000]
[22:09] <BUGa_depressed> WOW
[22:09] <h00k> mine ended up upgrading on the netbook which is probably why I keep dying.
[22:09] <BUGa_depressed> gnome-about segphauting?
[22:09] <ripps> BUGa_depressed: I downgraded from xorg-edger
[22:10] <ripps> but I'm completely maverick now
[22:10] <BUGa_depressed> ripps: you can use ppa-purge or what ever its name
[22:10] <BUGa_depressed> does a lot good work to downgrade packages
[22:10] <ripps> BUGa_depressed: that's how I did it :P
[22:10] <BUGa_depressed> cool
[22:10] <BUGa_depressed> can you try to reinstall gnome-about?
[22:10] <BUGa_depressed> or isntall dbg packages for it
[22:11] <BUGa_depressed> and start it in gdb
[22:11] <BUGa_depressed> to trace the cause
[22:11] <ripps> BUGa_depressed: yeah, but even notify-send isn't working. That has nothing to do with gnome
[22:11] <BUGa_depressed> humm
[22:12] <BUGa_depressed> what is under it?
[22:12] <BUGa_depressed> libc?
[22:12] <BUGa_depressed> lol
[22:12] <BUGa_depressed> again?!
[22:12] <ripps> BUGa_depressed: I have a nautilus backtrace hold on a sec
[22:12] <ripps> BUGabundo: http://pastebin.com/yTXjyh9u
[22:12]  * BUGabundo prepares to install a bunch of gdbsym packages
[22:13] <BUGabundo> #8  0x00110857 in _start () from /lib/ld-linux.so.2
[22:13] <BUGabundo> humm
[22:13] <BUGabundo> IO ?
[22:13] <Ian_corne> lol @ __PRETTY_FUNCTION__
[22:13] <BUGabundo> ripps: boot from livecd and fsck
[22:13] <BUGabundo> something is messing your file discretpor queues
[22:13] <ripps> BUGabundo: okay, see ya in a little while
[22:14] <BUGabundo> either disc or faulty mem
[22:14] <Ian_corne> you can fsck on a live system too
[22:14] <BUGabundo> do a memcheck while you are on it
[22:14] <Ian_corne> just not fixing stuff
[22:14] <Ian_corne> to check
[22:14] <BUGabundo> Ian_corne: yah
[22:14] <BUGabundo> but live would be sanner
[22:14] <BUGabundo> last time I had a online check
[22:14] <BUGabundo> fsck decided to rearrenge some indexs
[22:14] <BUGabundo> leaving me with a dead system
[22:15] <Ian_corne> lo
[22:15] <BUGabundo> and 200GB of data to recover
[22:15] <BUGabundo> and it didn't even changed the FS
[22:15] <BUGabundo> it was just the file index table
[22:15] <Daekdroom> fsck can't save.
[22:15] <Daekdroom> Real life experience.
[22:15] <BUGabundo> seems both of them got corrupt
[22:16] <BUGabundo> dropping the laptop 1,5mts from the air and kick it, tend to do that to discs
[22:16] <Daekdroom> SSD or HDD?
[22:16]  * BUGabundo goes back to watching Ip Man 2 movie
[22:16] <BUGabundo> eheh hdd... I wish for ssd
[22:16] <BUGabundo> been waiting for it for a few months
[22:27] <ripps> BUGabundo: I'm back, and there's nothing wrong with my filesystem
[22:27] <ripps> fsck said it was clean
[22:27] <BUGabundo> nor memory ?
[22:28] <BUGabundo> did you force the fsck ?
[22:28] <BUGabundo> $ sudo fsck.ext4 -fDv /dev/sda1
[22:28] <BUGabundo> :p
[22:28] <BUGabundo> well then... it beats me! fire apport and file a bug :)
[22:28] <ripps> no... I didn't know I needed to. Besides, everything is working now.
[22:28] <BUGabundo> ahh so you hadn't rebooted yet?
[22:29] <ripps> BUGabundo: no, I've been to livecd, and now I'm back in normal boot
[22:29] <ripps> I tried a fsck from livecd and it said all my linux filesystems were clean
[22:30] <guntbert> ripps: did you force the check with -f ?
[22:30] <BUGabundo> lololol
[22:30]  * BUGabundo hears an echo
[22:30] <ripps> no... should I go do that? I didn't know it was necessary.
[22:31] <BUGabundo> ripps: the FS may be corrupt and fsck table test still thinks its clean
[22:31] <BUGabundo> since you did a clean shutdown
[22:31] <BUGabundo> no flags were set
[22:31] <ripps> *sigh* be back in a sec
[22:31] <BUGabundo> the -f will actually check the entire FS
[22:31] <BUGabundo> its just precasionary messure
[22:31] <BUGabundo> and he is gone
[22:32] <BUGabundo> I bet he will take longer then a sec
[22:32] <BUGabundo> even longer then 600 secs
[22:32] <BUGabundo> :D
[22:32] <guntbert> BUGabundo: amen
[22:48] <BUGabundo> wb ripps
[22:49] <BUGabundo> that was fast
[22:50] <ripps> BUGabundo: yep, only problem was superblock mount time
[22:50] <BUGabundo> not bad
[22:50] <BUGabundo> well, if it happens again, let us know
[22:51] <ripps> I did optimize the disk with -D though, so hopefully things will work better
[22:52] <BUGabundo> heeh
[22:52] <BUGabundo> you can use tune2fs too
[22:52] <BUGabundo> even on a mounted system
[22:53] <BUGabundo> there's a nifty options that do improve the OS
[22:53] <BUGabundo> response