- Arch-general - lists.archlinux.org

[arch-general] 2 Killer kde4 dark themes - DR you listening??
by David C. Rankin 21 Jan '10

21 Jan '10

Guys, I stumbled into 2 cool looking dark kde4 themes while tweaking an existing theme so I thought I would pass them along for any others that like dark themes ... like DR. The themes are dark gradient themes: BlueGold color-theme: http://www.3111skyline.com/download/dt/kde4/color-schemes/DcrBlueGold.colors screenshot: http://www.3111skyline.com/download/ss/kde4/DcrBlueGold.jpg BlackGold color-theme: http://www.3111skyline.com/download/dt/kde4/color-schemes/DcrBlackGold.colo… screenshot: http://www.3111skyline.com/download/ss/kde4/DcrBlackGold.jpg (note: the screenshots were from within E16) For the corresponding dark colors for all your kde4 editors (kwrite, kate, quanta), just add the following to your ~/.kde4/share/config/kateschemarc: [kate-kwrite-dark] Color Background=26,26,26 Color Highlighted Bracket=228,180,94 Color Highlighted Line=36,36,36 Color Icon Bar=113,113,112 Color Line Number=167,167,167 Color MarkType1=228,180,94 Color MarkType2=255,0,0 Color MarkType3=255,255,0 Color MarkType4=255,0,255 Color MarkType5=160,160,164 Color MarkType6=0,255,0 Color MarkType7=255,0,0 Color Selection=47,87,133 Color Tab Marker=115,115,115 Color Template Background=204,204,204 Color Template Editable Placeholder=204,255,204 Color Template Focused Editable Placeholder=102,255,102 Color Template Not Editable Placeholder=255,204,204 Color Word Wrap Marker=76,76,76 Font=DejaVu Sans Mono,8,-1,5,50,0,0,0,0,0 then in an editor, choose Settings -> Configure Editor -> Fonts & Colors and then change the "Schema:" (at the top) and the "Default schema for Kate/Kwrite:" (at the bottom) and the editor window color will not complement the dark theme. Enjoy! -- 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

7 10

[arch-general] Quoting of E-mails
by Steve Holmes 20 Jan '10

20 Jan '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 I've been seeing some very passionate pleeds in posts lately concerning top-posting of replies. I, for one, don't really mind seeing top-posted e-mails like that because I can see the reply quickly and if the thread is current in my mind, I don't have to re-read the old stuff over and over again. Nothing annoys me more than haveing to page through five generations of past messages in a single thread to get all the way to the bottom just to have a single line of text say something like "Thank you" or "I agree" or whatever. The only thing that makes bottom-posting, like this bareable to me at all is Mutt's 'S' command which takes the cursor down to the unquoted text for much quicker reading. If bottom-posting is so passionately desirable, then may I suggest people trim down the history of a thread to the most recent 1 or 2 generations back. Or maybe even better, just reply with no quoting and and briefly summarize the quoted context. Yeah, I realize quoting past context is more work. I just find that when people top-post, I can seem to get through the mud a lot faster. Of course interlacing replies with quoted text makes a lot of sense when you have multiple issues or questions being asked. Anyway, just my thoughts, not trying to war or any of that, just trying to see the proes and cons of e-mail styles. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAktL+5AACgkQWSjv55S0LfEQ4ACgxr5OkA9AMsezDU6ynhNmHj4Y 9mYAnjwZIcgCUHB0yo6Gu8ScCIj4awfD =90j9 -----END PGP SIGNATURE-----

21 28

[arch-general] Deluge is missing one dependency
by Felipe Tanus 20 Jan '10

20 Jan '10

Hi all, When running deluge from a terminal, i got the following output: [fotanus@Yoda ~]$ deluge [ERROR ] 00:07:58 ui:146 No module named chardet Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/deluge/ui/ui.py", line 127, in __init__ from deluge.ui.gtkui.gtkui import GtkUI File "/usr/lib/python2.6/site-packages/deluge/ui/gtkui/__init__.py", line 1, in <module> from gtkui import start File "/usr/lib/python2.6/site-packages/deluge/ui/gtkui/gtkui.py", line 79, in <module> from connectionmanager import ConnectionManager File "/usr/lib/python2.6/site-packages/deluge/ui/gtkui/connectionmanager.py", line 49, in <module> import deluge.ui.common File "/usr/lib/python2.6/site-packages/deluge/ui/common.py", line 45, in <module> import chardet ImportError: No module named chardet [ERROR ] 00:07:58 ui:147 There was an error whilst launching the request UI: gtk [ERROR ] 00:07:58 ui:148 Look at the traceback above for more information. [fotanus@Yoda ~]$ I guess it's missing the "python-chardet" dependency. Once i installed, everything worked out. []'s -- Felipe de Oliveira Tanus E-mail: fotanus(a)gmail.com Blog: http://www.itlife.com.br Site: http://www.inf.ufrgs.br/~fotanus/ ----- "All we have to decide is what to do with the time that is given us." - Gandalf

2 2

[arch-general] Adding new partition to system from unpartitioned space - any reason to not use ext4??
by David C. Rankin 19 Jan '10

19 Jan '10

Guys, This is just a quick request to make sure I don't screw myself playing with new technology. I have a server 5 existing ext3 partitions on a dmraid array with several hundred gig of unpartitioned space. I have created the new partition and I'm about the create the filesystem. With ext4 now available, is there any reason I shouldn't go ahead and create the filesystem as ext4? It will simply be another data partition to supplement /home that was created rather small to begin with. Any thoughts or gotchas on using ext4 instead of ext3 for this?? -- 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

5 7

[arch-general] dmraid wiki wrong on chroot proceedure??
by David C. Rankin 19 Jan '10

19 Jan '10

Guys, I was helping someone on installing grub and I noticed the following on: http://wiki.archlinux.org/index.php/Installing_with_Fake_RAID under "Install Grub" that does not look correct: # mount -o bind /dev /mnt/dev # mount -t proc none /mnt/proc # mount -t sysfs none /mnt/sys # chroot /mnt /bin/bash That should be: # mount -o bind /dev /mnt/dev # mount -o bind /proc /mnt/proc # mount -o bind /sys /mnt/sys # chroot /mnt /bin/bash shouldn't it?? I know there wasn't a sysfs involved the last time I did this. -- 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

3 3

[arch-general] [signoff] wicd-1.7.0-1
by Daniel Isenmann 19 Jan '10

19 Jan '10

Hi, there is a new version of wicd in [testing]. In the past there were always problems in upgrading wicd, so I have decided to put it in [testing] first. Please test it and give me some signoffs. Big changelog: 1.7.0: Changes for Packagers: - Wicd now supports a -k option, which should be run by the init script when the daemon is stopped to release the DHCP lease but should not be run on a restart of the daemon. - The ability has been added to split Wicd's components into multiple directories. Use --gtk, --cli, --curses, and --daemon to setup.py configure to specify the locations of the respective components. - The preferred way to run the GTK UI is now to use wicd-gtk, not wicd-client. wicd-gtk is a new addition to 1.7 that will never run wicd-curses. wicd-client will automatically decide to run wicd-curses if there is no X session available. Major Changes: - Connection information is available by right clicking the tray icon - Can set the hostname per network for all DHCP clients - urwid 0.9.9 is now supported - Added wicd-cli, a command line interface for use in scripts - Global scripts are now passed parameters specifying the network Minor Changes: - Support for only displaying notifications using -o to wicd-client - Reconnecting now works when measuring signal strength in dBm - ESSIDs made of numbers now work properly - All valid wpa_supplicant drivers are now displayed - Wired network is now displayed while scanning wireless networks - Added wicd-gtk, a command to always and only run the GTK UI - Marked ioctl backend not supported - Use dhcpcd-bin on Debian instead of dhcpcd script Daniel

5 4

[arch-general] [signoff] kernel26-lts-2.6.27.44-1 & kernel26-lts-headers-2.6.27.44-1
by Tobias Powalowski 19 Jan '10

19 Jan '10

Hi guys, latest bugfix release. http://bugs.archlinux.org/task/17791 # Added UTS_NAMESPACE support Please signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

Re: [arch-general] [arch-dev-public] [signoff] psmisc-22.10-1
by Eric Bélanger 18 Jan '10

18 Jan '10

On Wed, Jan 13, 2010 at 11:30 PM, Dan McGee <dpmcgee(a)gmail.com> wrote: > On Wed, Jan 13, 2010 at 11:25 AM, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: >> Minor upstream update. Please test and signoff. > Signoff i686 > Anyone (dev or user) for x86_64?

2 2

[arch-general] new Allegro
by Matěj Týč 18 Jan '10

18 Jan '10

Hello, there is new Allegro version out and I have modified abs's PKGBUILD to fit. They use cmake now, so it looks different. The new version should be 100% compatible with the current one. Cheers, Matej

2 2

[arch-general] Startup scripts
by Tom 18 Jan '10

18 Jan '10

I was just forced to waste 10 min of my life because of arch-linux-way 'of doing things'. *rant mode on* Let me elaborate, for quite some time now, I've been unappeased by the way arch-linux handles the boot-up process, not so much by how it actually does it (it normally gets the job done) but more the fact that there's little to no obvious way of checking on it when things do go wrong. I've not been able to boot my custom compiled kernels since pathes 32.2 and 32.3, I don't know why, the config is identical to my running 32. I am at a loss. Anyway just now, I rebooted, tested yet another kernel, which failed of course, just to be sat in front of my kms-enabled high-resolution tty1 telling me that my home-partition needed checking after 34 mounts. Nice feature, normally I wouldn't bother, but I was in a hurry, so I hit ctrl-c, and bang 'fsck failed' - well yes it did, because I wanted it to, - dumbass, well I go and hit 'Control-D' to continue, and lo and behold the machine reboots, just to get on my nerves again with the fsck the next round through. I accepted defeat then, and went and made myself a nice hot cup of tee, BUT dear arch community, this is something I hate and find so wrong on so many levels I cannot begin to describe them all, even m$ offered a way to skip these things most of the time...) *rant mode off* Seriously I find the systems behaviour offensive, I should be in control, not some half-baked script. This is exactly the same reason that I had to sit through fsck regulary a while back(2.6.30 or 2.6.31), because of some bug regarding ext4-partitions(the timestamp in future error), not really because of the bug, but because of the inflexibility of arch linux boot up scriptures. Where to go, to file that bug... Tom

8 13

[arch-general] Re-installing whole system without touching configs.
by Javier Vasquez 18 Jan '10

18 Jan '10

Hi, Some time back, while xscreensver was running the system got locked, so that I couldn't log back neither under X, neither under the console. The only solution at hand was to do a hard reset. After such hard reset, the partition for /tmp got corrupted and it had to be repaired. However ever now and then since that incident I get errors when xscreensaver is running, including system freeze. Some times when running the demo application (xscreensaver user interface), in some screen saver applications I get errors in the preview indicating problems with gtk, or some gnome libs and the like, but then the same screen savers after reboot don't give that problem. Notice I've uninstalled xscreensaver and installit back, with no effect... Perhaps important to note is that I'm using ext4 in all partitions. So I have run already "fsck -f" over all partitions, but what's left is to re-install everything... I don't want to do a install from scratch, just want to re-install everything, but not touching the configuration files. Still I want to re-install all packages already installed in the system. Is there a way to do such re-install through pacman? If so, please let me know. Thanks, -- Javier.

5 6

[arch-general] packaging workload / help wanted
by Andreas Radke 16 Jan '10

16 Jan '10

It's time to call for help. I've run into a packaging workload I don't want to handle anymore. Some package groups take damn much time to follow upstream development, other just eat compile time. I don't want to give away completely these package groups for now (maybe later) but I really need help in the longer view. I'd like to work together with a few more people in maintaining package groups. I've already asked internally but got no real helpful response. That's why I want to ask you the community members to help out in some of my packaging tasks. Is anybody interested in helping out in the following package groups? 1) openjdk6 (openjdk7 expected later this year). new coming npplugin needs early testing. 2) OpenOffice and Go-OOo (aka ooo-build). Packaging requires fast hardware. 3) Xfce - I took it all over from Tobias(neri) because he's often not very active. Maybe someone can help here. Xfce 4.8 expected first half this year. 4) Nouveau stack 5) Ati stack - I'm forced to used the free ati drivers but someone else with one or even more Ati cards working together with upstream people would be nice to have aboard. Future KMS will require lots of testing. 5) LinuxPrinting (Cups, foomatic, ghostscript) - always buggy on major releases. Not much work all the other time. Please also check my other major packages. You should be an Arch user for some time and I expect you to know how to package and work together with upstream developers. Please drop me a (private) mail if you are interested. -AndyRTR

1 0

Re: [arch-general] [arch-dev-public] [signoff] xfsprogs-3.1.0
by Tobias Powalowski 14 Jan '10

14 Jan '10

Hi bump to latest version, xfsprogs-3.1.0 (13 January 2010) - Reduce memory usage in xfs_repair by using better data structures. - Add additional checks in xfs_repair to detect freespace btree corruption instead of only rebuilding the btrees. Useful for the no-modify mode. - Fix libhandle to use the right path to issue by-handle ioctls for symbolic links and special files. - Use lazy superblock counters by default. At least kernel 2.6.22 is needed for this feature. - Use physical device sector size if available in mkfs.xfs, so 4K sector devices are handed more gracefully. - Add a German translation, thanks to Chris Leick. - Enable the madvise and mincor commands in xfs_io. - Fix unsafe temporary file creation in xfs_fsr. - Add support for discarding unused space on SSDs or thin provisioned arrays in mkfs.xfs. - Allow linking against libblkid for topology information. - Add symbol versioning for libhandle. - Remove the included RPM and binary tarball built infrastructure. - Various build system improvements. - Small fixes to xfs_db and xfs_io. please signoff both arches, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-general] [signoff] rp-pppoe-3.10-2
by Daniel Isenmann 14 Jan '10

14 Jan '10

Hi, this is just a small fix for FS#13876 -[rp-pppoe] package: .so file in /etc (http://bugs.archlinux.org/task/13876) The kernel-mode plugin is now under /usr/lib/rp-pppoe/rp-pppoe.so and the initial config file /etc/ppp/pppoe.conf has the new path included. Existing config file must be changed to the new path. I can't test it, so please test if everything is working and signoff. Daniel

3 3

[arch-general] gmail and mailing list
by Xavier 13 Jan '10

13 Jan '10

On Tue, Jan 12, 2010 at 7:25 PM, Mauro Santos <registo.mailling(a)gmail.com> wrote: >>> P.S.: As a sidenote: Is it normal/intentional that I don't get my own >>> mails back via the list? Or is this some weird GMail stuff? >> >> It's a gmail issue. >> >> I'm not sure if there is a setting or something like that, but i've >> noticed the same and also heard other people about it. >> >> >> mvg, >> Guus >> > > Same problem here, and they even know about it, they might as well > provide some workaround or option to change it. > > http://mail.google.com/support/bin/answer.py?hl=en&answer=6588 > I don't understand how that is an issue. Why do you want to see your own mails in the inbox ? For each ML I subscribe to, I create a new label and a new filter, and I set it to skip inbox and archive because I do not want ML to clutter my inbox. Much better that way :) But to each his own. That said I think it's always better to have configure options and control.

9 9

Re: [arch-general] [arch-notifications] Orphan Extra package [snes9x] marked out-of-date
by Daenyth Blank 13 Jan '10

13 Jan '10

On Wed, Jan 13, 2010 at 06:29, Arch Website Notification <nobody(a)archlinux.org> wrote: > > * Note: this is an automated message > > <redacted>@gmail.com wants to notify you that the following package may be out > of date: > > Package Name: snes9x > Architecture: i686 > Repository: Extra > (http://www.archlinux.org/packages/extra/i686/snes9x/) > > > The user provided the following additional text: > > http://snes9x.com/phpBB2/viewtopic.php?t=4542 > > > Please add a .install notice using vercmp if the upgrade was from <=1.51 - IMPORTANT NOTICE: The structure of savestates (also known as snapshots / freeze files) is incompatible with older versions! Snes9x 1.52 cannot read the savestates created by 1.51 or older. If no one wants to adopt this I can take it in community.

1 0

[arch-general] building x86_64 packages under qemu?
by Chris Brannon 13 Jan '10

13 Jan '10

Is there any reason why building x86_64 packages under qemu-system-x86_64 would be a bad idea? It is a little slow, but it is usable. Plus, qemu has a curses interface. -- Chris

6 7

[arch-general] Away from my PC -> away from bugtracker.
by Gerardo Exequiel Pozzi 13 Jan '10

13 Jan '10

Hello all I will be away from now for about two or more weeks. I recently surfered an small irritation on my eyss, so I can not stay on my PC :( Leaving the bugtracker in their hands, I hope to be with you again soon. Best regards. Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

4 5

[arch-general] KMS and external monitor resolution
by André Ramaciotti da Silva 13 Jan '10

13 Jan '10

Hi all, I'm sorry if it has already been discussed here, but I couldn't find anything with the keywords I was using. I even had a bad time choosing this message subject. I bought a new, bigger monitor to use with my notebook. I've already configured X, but sometimes I like to write on the tty (there are less distractions there) and I'm having a little problem with it. The native resolution of the notebook screen is 1280x800 and the native resolution of the external monitor is 1920x1080, so when I'm on the tty, the external monitor uses only a box on the top left side with a size of 1280x800. What I would like to do is turn off the notebook monitor and use only the external monitor with its native resolution, without, of course, messing with my X setup, as it's already set. I'm using a Intel GMA965 with KMS. TIA Bye, Andre

2 2

[arch-general] arch-dev-public on dcron 4.3 and logrotate
by Jim Pryor 12 Jan '10

12 Jan '10

On Tue, Jan 12, 2010 at 04:28:40PM -0500, Paul Mattal wrote: > On 01/12/2010 04:16 PM, Eric Bélanger wrote: > >>>As the dcron logging is now managed by syslog-ng, it shouldn't provide > >>>a /etc/logrotate.d/crond. Instead, we should release a new syslog-ng > >>>package with /var/log/crond.log added to the list of logfiles being > >>>taken care of in its /etc/logrotate.d/syslog-ng. We could add, at the > >>>same time, the other logfiles created by syslog-ng but currently > >>>ignored in the log rotation: > >>> > >>>/var/log/lpr.log > >>>/var/log/uucp.log > >>>/var/log/news.log > >>>/var/log/ppp.log > >>>/var/log/debug.log > >>>/var/log/acpid.log > >>> > >>>Am I missing something? Any objections, comments? > >> > >>Actually, that sounds backwards to me. If cron isn't installed, we > >>have no log file. It makes sense to me - if pkgA adds more log files > >>that get big, it should also provide its own logrotate file. > > > >I guess it depends how you see it. The way I see it is that it's > >syslog-ng who creates the file and appends to it so it should be > >responsible for the rotation as well. Plus, we use the missingok > >option so if the file is missing, it just skips it whithout even > >issuing an error message. So no harm is done. > > I can see both sides of this, but in essence, it seems like it's > syslog-ng which ultimately decides the filename-- if syslog-ng.conf > is changed to log cron output to another file, it's syslog-ng that > decides where they go. So I think I agree with Eric that syslog-ng > should be responsible for the rotating the files it determines > should exist in its default configuration. > > I'll wait a while to hear from others before doing anything directly > to address this. Yes, the logrotate script was needed when dcron didn't use syslog. And I'll leave it in the release tarballs "extra" folder as an example for users who continue to use dcron that way. But on my own system I have syslog logging the cron output to "cron.log" not "crond.log": from /etc/syslog-ng.conf: destination d_cron { file("/var/log/cron.log"); }; filter f_cron { facility(cron) or program("rsnapshot"); }; log { source(src); filter(f_cron); destination(d_cron); }; And I have /var/log/cron.log handled by my /etc/logrotate.d/syslog-ng script: /var/log/[..lots of logs, including cron.log..] { missingok sharedscripts postrotate /bin/kill -HUP `cat /var/run/syslog-ng.pid 2>/dev/null` 2> /dev/null || true endscript } I can appreciate arguments both ways myself, but for my own use found it easiest to just ignore the dcron-supplied logrotate script and edit it into my syslog-ng logrotate script. -- profjim(a)jimpryor.net dcron developer

1 0

Re: [arch-general] [arch-dev-public] [signoff] mkinitcpio 0.5.28-1
by Evangelos Foutras 12 Jan '10

12 Jan '10

On 12/01/2010 11:03 πμ, Thomas Bächler wrote: > I think what we have now in the kill-klibc branch might actually boot in > a standard setup (no raid, nfs, lvm, encryption), but I didn't try. I'll > keep you posted. I gave it a try in a VM but it still fails with "Failed to execute /init" like last time (http://i.imgur.com/h6xDu.png) The mkinicpio revision I tried was 54fd032, along with latest mkinitcpio-busybox/trunk. The command used to generate the initramfs image was `./mkinitcpio -g /boot/kernel26.img' from within the cloned Git repository (switched to the kill-klibc branch). Let me know if I can help with further testing.

2 4

Re: [arch-general] [arch-dev-public] [announcement] qemu/qemu-kvm announcement draft
by Simon Boulay 12 Jan '10

12 Jan '10

On 01/09/2010 09:09 PM, Tobias Powalowski wrote: > Am Samstag 09 Januar 2010 schrieb Dan McGee: >> On Sat, Jan 9, 2010 at 11:52 AM, Tobias Powalowski<t.powa(a)gmx.de> wrote: >>> > Yes will change the install message. >>> >>>> Yes there is no mention in the changelogs, really strange. >>>> greetings >>>> tpowa >>> >>> Ok like this? >>> echo ">>> Since kernel 2.6.29:" >>> echo ">>> Qemu package now provides standard qemu with kvm enabled." >>> echo "" >>> echo ">>> PLEASE READ FOR KVM USAGE!" >>> echo ">>> Load the correct KVM module, you will need a KVM capable >>> CPU!" echo ">>> Add yourself to the group 'kvm'." >>> echo ">>> Use 'qemu --enable-kvm' to use KVM." >>> echo "" >>> echo "With the release of qemu and qemu-kvm 0.12.X, the kqemu kernel >>> module" echo "is no longer supported and will be removed from the >>> repositories. You" echo "can safely uninstall it from your system." >> >> Can we put some vercmp checks around messages like this? That way >> people only have to see them once (when they upgrade the first time to >> a 0.12.x version for the second message). The first message should >> really be a post_install message. >> >> And with all that said, why are there two packages in extra if "qemu >> package now provides standard qemu with kvm enabled"? >> >> -Dan >> > Yes sure i can add those vercmp stuff. > qemu and qemu-kvm is different. > qemu-kvm is only for kvm while qemu provides much more machines to emulate. I'm not sure about that. Both seems to share the same code for machine emulation; only the kvm stuff is different. In fedora 12, they build kvm and qemu-system-xxx from qemu-kvm 0.11. But I don't know how this will evolve in the future. If qemu and qemu-kvm are used for different purposes, one may need to install both apps side by side but that's not possible in archlinux. I see two ways to handle that: 1. Permit the installation of both applications at the same time (qemu for system emulation, qemu-kvm for visualization). qemu-kvm executables can be renamed to kvm-xyz. That's what Debian do. 2. Build qemu-kvm with --target="" and all came in the same package. With 0.11, only qemu provided kqemu but as the kqemu support is gone, the second proposition seems to be the way to go. I use this on archlinux for kvm (winXP) and sh or arm emulation without problems since 0.11. Simon. > greetings > tpowa

5 11

[arch-general] Deluge 1.2.0
by Damien Churchill 12 Jan '10

12 Jan '10

I was wondering if it would be possible to add a message, saying the preferred way of running the different user interfaces now is via a deluge-* script, so deluge-gtk, deluge-web and deluge-console, to the post_install() of the package? Damien

2 4

Re: [arch-general] [arch-dev-public] OS News interview
by Xavier 12 Jan '10

12 Jan '10

The common way is to reply on arch-general, so I will include that list in CC now. Thanks for the clarification. So your concern was not about using external binaries, it was about keeping to use outdated Arch programs. That's also a very good point when talking about disadvantages of the rolling release model. It seems most developers answered purely from a developer point of view more than a user one. But I read the answers again and noticed the overlord did mention both sides :) "Aaron Griffin: The biggest problem with the rolling release model is laziness - from upstream developers and Arch users. We try to stay up to date wherever possible, but some upstream developers are slow at adopting new changes. This means we need to do extra work to make their software compatible with new library versions and things of that nature. On the user end, you get people who don't regularly update their system (something we indicate as very important), and you end up with newer software and older libraries on the same system, causing breakages." So I just want to highlight that it's indeed very important to regularly update a Arch system, and it's something that should be made clear when advertising Arch, because it definitely does not fit to everyone. On Tue, Jan 12, 2010 at 5:22 AM, Gregory Eric Sanderson <gzou2000(a)gmail.com> wrote: > Hi Xavier, > > I tried to post an answer to your last message, but since i'm only an > "observer" on the dev list I can't. So I'm transfering directly to you my > answer if ever it might interest you > > ---------- Forwarded message ---------- > From: Gregory Eric Sanderson <gzou2000(a)gmail.com> > Date: Mon, Jan 11, 2010 at 11:20 PM > Subject: Re: [arch-dev-public] OS News interview > To: Public mailing list for Arch Linux development > <arch-dev-public(a)archlinux.org> > > > Actually, that question came from me :-) > > Sorry if the question wasn't clear, I should have phrased it in a different > way. Although my country officiaily has 2 languages, I live in the province > that speaks almost only french, so I don't get much chances practicing my > english. > > The "programs that depend on older libraries who aren't on the system > anymore because of an update" is actually an example that I was trying to > give of a disadvantage that could occur because of the rolling release > model. when I switched full-time to Arch, I din't do system upgrades very > often and It happend regularly that programs would stop to work because they > were linked to libraries who were updated as part of the installation of a > new program. (I hardly get this problem anymore since I upgrade more > regularly now) > > Don't get me wrong, I love the rolling release model. But I was curious to > know what the developers thought of this and if they saw any other > disadvantages or "quirks" that the rolling release model brought > > On Mon, Jan 11, 2010 at 6:59 PM, Xavier <shiningxc(a)gmail.com> wrote: >> >> On Mon, Jan 11, 2010 at 11:22 PM, Allan McRae <allan(a)archlinux.org> wrote: >> > The OS News interview is up: >> > http://www.osnews.com/story/22692/Arch_Linux_Team >> > >> >> Fun interview. Allan's answers are the best, I have to say :) >> >> Some comments : >> - a few formatting issues. like the first reply from Thomas often >> misses a newline. Allan lost his A and became llan and one page. >> >> - whats the difference between these two questions on page 5 : >> What part of the Arch Linux development is the most active? >> Where is development primarily focused for the Arch Linux team (the >> installation, pacman, etc)? >> >> - about this question >> One of the most notable characteristics of Arch is its rolling release >> model, which assures users that they will always have the latest and >> newest version of a program available. Has this model brought any >> noticeable disadvantages (for example: programs that depend on older >> libraries who aren't on the system anymore because of an update)? >> >> I am not sure what the question meant to hint with "programs that >> depend on older libraries who aren't on the system anymore because of >> an update" but that reminded me of several times I tried to run some >> binaries on Arch, and it failed because all libraries were too new. :) > >

1 0

[arch-general] PKGBUILD for extra/cegui
by Rodrigo Amorim Bahiense 11 Jan '10

11 Jan '10

Hi all! I've posted on forum (http://bbs.archlinux.org/viewtopic.php?id=88509) that the package extra/cegui was out of date and then was instructed by Allan to post the modified PKGBUILD on the mailing list. Basically, I just modified the version, the license file location and md5sums. Also, a static reference to old version 0.6.2 to variable $pkgver. ------- pkgname=cegui pkgver=0.7.1 pkgrel=4 pkgdesc="A free library providing windowing and widgets for graphics APIs/engines" arch=(i686 x86_64) url="http://crayzedsgui.sourceforge.net" options=('!libtool') license=("MIT") depends=('pcre' 'expat' 'freetype2' 'libxml2' 'devil' 'freeglut' 'lua' 'silly') [ "$CARCH" = "x86_64" ] && depends=(${depends[@]} 'silly') source=(http://downloads.sourceforge.net/crayzedsgui/CEGUI-$pkgver.tar.gz) build() { cd $startdir/src/CEGUI-$pkgver ./configure --prefix=/usr --sysconfdir=/etc --enable-devil --enable-silly \ --disable-xerces-c --with-default-image-codec=SILLYImageCodec \ --enable-lua make || return 1 make DESTDIR=$startdir/pkg install install -D -m644 doc/COPYING $startdir/pkg/usr/share/licenses/$pkgname/COPYING } md5sums=('0a2815d5204e3c5510884ab62285da97') ------- I didn't check if the old dependencies are still needed, but anyway, that was actually my first pkgbuild. -- Rodrigo

2 3