- Arch-general - lists.archlinux.org

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