- Arch-general - lists.archlinux.org

[arch-general] High fragmentation rate with ext4?
by Cá Vàng 11 Jun '09

11 Jun '09

Hello everyone! As linux 2.6.30 is out, I decided to migrate my data partition to ext4. Hoping for better performance and less fragmentation. But, after format it with "mkfs.ext4 - largefile /dev/..." and copy all the file back to the partition, I got whooping number of 30% non-contiguous files! Then I reformat it with reserved block set to 10% (-m 10), still got the same fragment rate :-( Okay, so I try it again, this time with ext3, then I do a "mount -a" to remount all the partitions, copy some files (size between 2 MBs~40 MBs) back in, guess what? This is the result of fsck: 81 inodes used (0.07%) 69 non-contiguous files (85.2%) Then I remember that "mount -a" mount the partition as ext4 (since I haven't changed my fstab yet), okay, so I format it again, and mount it with "mount -t ext3 ....", copy some files in and this is the result: 81 inodes used (0.07%) 9 non-contiguous files (11.1%) Still not as good as it was before, but much better than the 85.2 rate above. So is this a bug? Does anyone have this problem? My e2fsprogs version is 1.41.5-2

1 1

Re: [arch-general] KDE4.3 Beta - Rocks, still a bit rough, but very usable as a primary desktop
by David C. Rankin 10 Jun '09

10 Jun '09

On Wednesday 10 June 2009 11:21:01 you wrote: > David C. Rankin wrote: > > If you have been in the same > > holding-pattern lately in your thinking about kde4 as well -- I bet you > > will be pleasantly surprised as well ;-) > > Thanks for the heads up. I'll have to give it a shot one of these days. > > Clearly I'm not going to be able to remain on KDE3 for much longer, as > no one's going to be doing new development on any of the apps. > > DR Yep DR, that's the boat I find myself in. From what I can tell now, KDE4 will be a good follow on to KDE3. 30 days ago, I would have ... and I did ... tell you it wasn't anything other than some pipe dream from the gaming crowd with cute names like plasmoids and widgets scattered through it that took more time to keep running that it allowed to get work done. But as more apps were built against the kde4 runtime base that broke kde3 functionality and as more and more apps moved exclusively too the kde4 base, it was inevitable I would have to go kicking and screaming to kde4 or some other desktop altogether. The screw-up, that will go down in history as the worst transition strategy ever, was the roll-out or force-out of kde4 long before it was ready for public use. (June 2008 to roll-out 4.04 in 'alpha' state as the default choice for a desktop by suse? What where they smoking?) First few releases of 4.1 were just as bad. No one in the 'general "linux-user"' category should have ever been faced with having that as a desktop when the kde3 alternative was near flawless. No wonder so much of the community has the mindset that kde4 is "broken", "not ready", "unstable", etc... Hell, it was. If it had just remained under development until where it is now, and then been rolled out as an "alternative" KDE version in the major distros, then I guarantee you the community response to KDE4 would have been fantastic and with a fanatical desire to see the next release. As it was done, there is still a large percentage of the user base that won't touch it with a 10 foot pole until KDE3 is no longer available. That's the true cost of an early push of an unready desktop on the community. You have half the crowd completely lose confidence in a beloved desktop and the direction the developers have taken. As I said earlier in the thread. It is now ready and is now usable as a primary desktop with no more than the run-of-the-mill bugs that need to be squashed. To have pushed it out the door a year ago as a default choice for a desktop was sheer stupidity. It was as smart as if GM and Chrysler suddenly decided to put out nothing but 3-wheeled cars as the policy that would save their financial futures and lift them out of bankruptcy. But now, with 4.3beta, KDE4 is usable, and even enjoyable, by the general linux user, so it is time to roll up the sleeves, dive in, and each send in their dozen or so clean up bugs to kde.org and then we can look forward to a great kde4.3 release. (which is something we should have been able to look forward to as a 4.1 release, but for the premature release;-) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

2 1

[arch-general] emacs toolbar icons disappeared
by prad 10 Jun '09

10 Jun '09

problem on kdemod - blank icons with little x's in them. the usual icons just disappeared suddenly. reinstalling emacs didn't bring them back. this issue was brought up on the archlinux forums: http://bbs.archlinux.org/viewtopic.php?id=69825 but no resolution seemed to be reached. -- In friendship, prad ... with you on your journey Towards Freedom http://www.towardsfreedom.com (website) Information, Inspiration, Imagination - truly a site for soaring I's

1 0

[arch-general] libgweather
by Baho Utot 09 Jun '09

09 Jun '09

I am trying to build libgweather and I have this error PKGBUILD: line 24: gtkdocize: command not found What is gtkdocize and where do I find it?

4 8

[arch-general] install packages using links?
by clemens fischer 09 Jun '09

09 Jun '09

Hi, Whenever I install autotools-aware programs from source, they don't go into /usr/local as is customary, but into their own directory called /opt/<package>/<version>, and then files in /opt/<package>/<version>/{{s,}bin,man} etc. get symlinked into their counterparts in /usr/local. I am using spill[1] for this. Thus, for gpp-2.24, which is a preprocessor like cpp(1) sporting modifiable syntax, the result is: /usr/local/bin/gpp -> /opt/gpp/2.24/bin/gpp* /usr/local/man/man1/gpp.1 -> /opt/gpp/2.24/man/man1/gpp.1 The advantage is easy to see: you can always see what package some file belongs to, and removing a package is as simple as removing matching links and the installation directory. All files belonging to a package are in one place. spill(8) automates package installation and management, but this can be done manually as well. Would going this route for arch-linux packages be seen as an improvement? [1] http://www.rpcurnow.force9.co.uk/spill/ clemens PS: I originally sent this to arch-dev-public@, but obviously I can subscribe to that list while not qualified to post.

7 13

[arch-general] Weird OpenOffice Disappearing Menu and Toolbar Text?
by David C. Rankin 09 Jun '09

09 Jun '09

Listmates, I have run into a strange issue with openoffice in Arch. I am using kdemod3 on my Toshiba x86_64 laptop. All Arch packages have been synced and are up to date. The graphics are provided by the radeonhd driver on an ATI M690 (x1200) chipset. In openoffice writer, when you hover over the "style" "font" or "size" combo boxes in the main toolbar, the text in the combo box disappears. The combo box display literally goes blank. If you activate the combo box to see the list of styles, fonts, etc.., the text is then visible. However, when you move your mouse up and down the list, the text under your cursor disappears as well. I have also noticed the same behavior with the pull-down menu text although to a lesser extent. Usually with the menus, only the last 1 or 2 menu entries disappears when a mouseover happens. I have tried with and without compiz - no difference. Has anyone else seen this behavior. It's a very frustrating issue to try and work with blanks in your toolbar. I am also cc'ing this to the radeonhd list in case it is related to the driver. I have the same setup (same laptop) with suse 11.0 with the same openoffice version, but all is fine there. I am trying to determine whether this is an Arch package issue, an openoffice issue, or a radeonhd issue. Since oo works fine on suse 11.0 with the fglrx driver, I think we can eliminate it being an oo issue. That leave the potential of it being an Arch package issue or a radeonhd issue. I don't know how to test to determine which it is. Can anybody think of a test that could be run to narrow it down? I will switch to the radeon driver and test, but beyond that, I can't think of anything else to try. Any thoughts? --- Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

6 10

Re: [arch-general] [arch-dev-public] ruby 1.9.1 enters [testing] - breaks gvim
by Emmanuel Benisty 09 Jun '09

09 Jun '09

On Sun, Jun 7, 2009 at 11:47 AM, Allan McRae<allan(a)archlinux.org> wrote: > Hi all, > > I have built ruby-1.9.1 for [testing]. As far as I can tell, the only > thing that is broken is gvim. A dev who uses that will want to look into > fixing it... I hear there is a patch floating around for ruby-1.9 support > but not sure if it is now included upstream. You can always use IgnorePkg > until it is fixed. > > (Lets see if gvim users complain more than the ruby users have...) FTR, it breaks vim too here. vim: error while loading shared libraries: libruby.so.1.8: cannot open shared object file: No such file or directory

3 3

[arch-general] Light-weight SMTP "server"
by Magnus Therning 08 Jun '09

08 Jun '09

Any good suggestions for a light-weight SMTP server? All email goes off-box to my ISP for remote delivery, I don't require any local delivery. Things like exim/sendmail/postfix feels like overkill. It would even be enough if all that's available is something like an /usr/lib/sendmail executable. Is there something suitable and light-weight? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

6 14

[arch-general] ArchWiki TOC translated to pt_BR
by Lucas Salies Brum 08 Jun '09

08 Jun '09

I translate this page, but I'm beginner, I would like to review. http://wiki.archlinux.org/index.php/Table_of_Contents_(Portugu%C3%AAs_do_Br… Thank you.

1 0

Re: [arch-general] [arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3
by Gerardo Exequiel Pozzi 07 Jun '09

07 Jun '09

Thomas Bächler wrote: > Going into testing in a few minutes: > > mkinitcpio changes: > - Finally fix a bug where required HID modules were missing > - Add a new COMPRESSION option that accepts gzip, lzma and bzip2 > parameters (gzip is the default, the others are only supported on > 2.6.30 and later) > - Add a new poll_device function that waits for a block device to > appear. This is used in the init function and the resume hook, with > rootdelay as a maximum timeout (default to 10 seconds) > - Remove the unmaintained and untested modload hook > - Remove the runtime filesystems hook > - Rework the code that checks whether a root device has been found, > don't reboot when exiting the emergency shell, but try to continue. > - Due to the new poll_device behaviour, the usb and fw runtime hooks > are no longer required, remove them > - Parse arguments to init properly, using the "$@" parameter from the > commandline the kernel generated - also needs the new fix in the > latest kinit from testing (this allows us to use init=/bin/sh again) > - Adjust for the latest filesystem/module-init-tools changes > - Fix an autodetection bug that would sometimes omit some filesystems > Many thanks. The tests was done on VirtualBox (both i686 and x86_64 architectures), because in my real machine use a custom kernel without initramfs. * Images generations are OK. * Boot OK normal and fallback images (default config). * Also boot fine with the "init=/bin/bash" argument and "init=/sbin/init" > cryptsetup changes: > - Use poll_device when waiting for the encrypted device and the > (optional) key container device (default to rootdelay), added > conflicts=(mkinitcpio<0.5.25) > - Add a warning if the deprecated root= syntax is used on the commandline > Not tested it. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0