- Arch-general - lists.archlinux.org

[arch-general] Removing padevchooser and paman
by Jan Steffens 10 May '10

10 May '10

I would like to remove these two packages from community and move them to unsupported (AUR). Both are marked as obsolete by upstream[1] and weren't updated since 2007. padevchooser is a notification area app that allows choosing default sinks and sources, as well as starting some other PulseAudio applications. It has been obsoleted by pavucontrol, which also allows much finer control over sink and source usage. paman is a diagnostic tool that provides information similar to "pacmd list", as well as allowing control of stream volumes (provided by pavucontrol) and playing samples from the cache (pacmd play-sample). Your thoughts? 1: http://pulseaudio.org/wiki/PerfectSetup

4 7

[arch-general] extra/hibernate-script out of date -> new version
by Guillaume ALAUX 10 May '10

10 May '10

Hi everyone, As stated by "mrbrich" in this thread [1], package extra/hibernate-script [2] is out of date (old version 1.99 ; new version should be 2.0). I made this new one [3] that installs fine but I can't test it. Could anyone using it give it a try please? Thanks Guillaume ALAUX [1] http://bbs.archlinux.org/viewtopic.php?id=95899 [2] http://www.archlinux.org/packages/extra/i686/hibernate-script/ [3] http://archlinux.alaux.net/hibernate-script-2.0-2.src.tar.gz

3 5

Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
by Marek Otahal 10 May '10

10 May '10

On Sunday 09 of May 2010 15:55:17 Pierre Schmitz wrote: > On Sat, 8 May 2010 00:04:43 +0200, Dieter Plaetinck <dieter(a)plaetinck.be> > > wrote: > > On Sun, 02 May 2010 17:49:13 +0200 > > > > Pierre Schmitz <pierre(a)archlinux.de> wrote: > >> This new kernel just exports some additional symbols for aufs2 which > >> was updated to a new snapshot. This should hopefully fix some issues > >> with the .33 kernel and aufs. Related aufs packages are: aufs2 > >> 2.6.33_20100425-2 and aufs2-util 20100422-1 > >> > >> In addition to regular sign-off some feedback about aufs would be > >> nice; especially if you use archiso. > > > > http://build.archlinux.org/isos/archlinux-2010.05.07-netinstall-i686.iso > > boots fine on my system. signoff i686. > > > > once i have rebuilt images (with correct copyright statement) i will > > let the community test, then you'll have a bit more feedback about how > > well it works ;) > > > > Dieter > > It seems to be fine in x86_64 and the aufs bugs are confirmed to be fixed > with this version. So, I'll move these to core/extra. Hello, please just test a bit more the new kernel, I have just rebooted to the new 2.6.33.3-2 kernel and got kernel panic on Init: ..something about missing symbols, failed exec and 52 - I didn't take notes of that and don't know if it's logged somewhere (?) I'm using [testing], i686, and encrypted disk, but this probably occurred before this. I'll retest when I have time.. Anybody else experiencing this? Thanks and have a nice day Mark -- Marek Otahal :o)

7 13

[arch-general] PKGBUILD contributor, maintainer, author...
by Andre "Osku" Schmidt 09 May '10

09 May '10

Hello Arch, i'm doing (for fun) a PKGBUILD parser in javascript, and now as i was testing it with random PKGBUILD files from AUR, i noticed that there is more than one way people use to define authors... (/usr/share/PKGBUILD.proto shows only "Contributor") till now i've found: - Contributor - Maintainer - Author so i wonder what others should i parse ? or could you/we make a standard ? cheers .andre

7 7

[arch-general] Err... Why is gvim now conflicting with vim?
by David C. Rankin 09 May '10

09 May '10

Guys, I have had vim and gvim installed side by side for 6 months+, today during update, pacman wanted to remove vim because it now conflicts with gvim. So I removed gvim and updated. What is the conflict? Why a conflict now when there hasn't been one in the past? Just checking... -- 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

25 29

[arch-general] audacious segfaults; can debug because of dependencies
by Frédéric Perrin 08 May '10

08 May '10

Hello list, I tried audacious for a change this morning, but it segfaulted on visualisation change[1]. From the look of the backtrace[2], and seeing that glib was updated a couple of days ago, a simple rebuild of the package should be sufficient. I would normally have submitted that to the bug tracker, but didn't as : - it requires login to a web interface; - I can't test the suggested fix as audacious' PKGBUILD has a depends on audacious-plugins, and audacious-plugins has a makedepends on audacious. 1. - Steps to reproduce : - start playing a webradio, it happened with the MP3 flux from frequence3.fr - right click on the interface, select "Visualisation / Type de visualisation", try each one in order then back to the first one, "Analyseur". 2. % gdb audacious [...snip...] (gdb) run Starting program: /usr/bin/audacious [Thread debugging using libthread_db enabled] [New Thread 0xb718ab70 (LWP 12470)] [New Thread 0xb5f4fb70 (LWP 12471)] [New Thread 0xb492bb70 (LWP 12472)] [New Thread 0xb3fffb70 (LWP 12473)] [Thread 0xb3fffb70 (LWP 12473) exited] [New Thread 0xb3fffb70 (LWP 12474)] [Thread 0xb3fffb70 (LWP 12474) exited] [New Thread 0xb3fffb70 (LWP 12475)] [New Thread 0xb373fb70 (LWP 12476)] [New Thread 0xb2f1eb70 (LWP 12477)] [Thread 0xb2f1eb70 (LWP 12477) exited] [Thread 0xb373fb70 (LWP 12476) exited] [Thread 0xb3fffb70 (LWP 12475) exited] [New Thread 0xb3fffb70 (LWP 12478)] [New Thread 0xb373fb70 (LWP 12479)] [New Thread 0xb2f1eb70 (LWP 12480)] [Thread 0xb492bb70 (LWP 12472) exited] Program received signal SIGSEGV, Segmentation fault. 0xb618d444 in ui_vis_expose () from /usr/lib/audacious/General/skins.so (gdb) bt #0 0xb618d444 in ui_vis_expose () from /usr/lib/audacious/General/skins.so #1 0xb7c6d1f4 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #2 0xb7a55b99 in g_type_class_meta_marshal () from /usr/lib/libgobject-2.0.so.0 #3 0xb7a57252 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #4 0xb7a66b75 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0 #5 0xb7a6f593 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #6 0xb7a6f9b6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #7 0xb7d9ec46 in gtk_widget_event_internal () from /usr/lib/libgtk-x11-2.0.so.0 #8 0xb7c6ba41 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #9 0xb7ae1d51 in _gdk_window_process_updates_recurse () from /usr/lib/libgdk-x11-2.0.so.0 #10 0xb7ae1cfd in _gdk_window_process_updates_recurse () from /usr/lib/libgdk-x11-2.0.so.0 #11 0xb7b13a04 in _gdk_windowing_window_process_updates_recurse () from /usr/lib/libgdk-x11-2.0.so.0 #12 0xb7add63c in gdk_window_process_updates_internal () from /usr/lib/libgdk-x11-2.0.so.0 #13 0xb7adf3f7 in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0 #14 0xb7adf47b in gdk_window_update_idle () from /usr/lib/libgdk-x11-2.0.so.0 #15 0xb7abcbc8 in gdk_threads_dispatch () from /usr/lib/libgdk-x11-2.0.so.0 #16 0xb7f3b041 in g_idle_dispatch () from /usr/lib/libglib-2.0.so.0 #17 0xb7f3ef72 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #18 0xb7f3f750 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #19 0xb7f3fdfb in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #20 0xb7c6a439 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #21 0xb618323e in skins_init () from /usr/lib/audacious/General/skins.so #22 0x08056e3c in ?? () #23 0xb786cb96 in __libc_start_main () from /lib/libc.so.6 #24 0x08050a21 in ?? () -- Fred

1 0

[arch-general] Arch Linux release Schedule
by Keith Hinton 08 May '10

08 May '10

Hi all. I remember way back when Aaron G posted about how Arches goal would be to release every four months or so to keep up with regular kernel releases and frequent ISO images. However, I remember the last official Iso was in August of 2009. I am not saying that that is bad or anything. I am curious why there hasn't been a release since that time period? I never figured that out. I did send an email to our fine Arch Linux leader using a GMail address-and am curious if that address just isn't checked? I did send Aaron some other interesting emails of late as well. But I haven't received anything-though being a leader of a project such as Arch Linux must take up a lot of time. Take care! Regards, --Keith

5 5

[arch-general] [signoff] kernel26 2.6.33.3-2 (and aufs2)
by Pierre Schmitz 07 May '10

07 May '10

This new kernel just exports some additional symbols for aufs2 which was updated to a new snapshot. This should hopefully fix some issues with the .33 kernel and aufs. Related aufs packages are: aufs2 2.6.33_20100425-2 and aufs2-util 20100422-1 In addition to regular sign-off some feedback about aufs would be nice; especially if you use archiso. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre

4 3

Re: [arch-general] [arch-dev-public] Redefining [testing] and a new [staging] repo
by Ray Kohler 07 May '10

07 May '10

On Fri, May 7, 2010 at 1:40 PM, Pierre Schmitz <pierre(a)archlinux.de> wrote: > On Fri, 7 May 2010 12:13:33 -0500, Aaron Griffin <aaronmgriffin(a)gmail.com> > wrote: >> So in effect, it seems we're saying the same things, except I am using >> REPO_NAME="foo-rebuild" for each rebuild "foo", and you are using >> REPO_NAME="staging" for *all* rebuilds. > > Somehow yes, but the detail is quite important. But a already existing > repo will make things a lot easier. Maybe its worth to manually create a > separate repo but probably not for just a few. We also sometimes upload > packages somewhere to share or let others grab them from our home dirs on > gerolde. Such a repo would simplify this and induce a general work flow for > e.g. rebuilds. > > But still, the main intention is to make testing more usable to get more > feedback and in turn have less bugs in core/extra. > >> This can already be done, the staging dir just needs to be added to the >> server. >> >> It would, however, need to be excluded from rsync if you want that. > > Sure, the implementation of this is a peace of cake: mostly a mkdir and > maybe adding some shortcuts to devtools and dbscripts to have something > like stagingpkg and staging2extra etc.. This makes me wonder, what about the TUs and [community-testing]? The current use of that repo would make it seem sensible to rename it to [community-staging] instead, since it's rare there's anything in there but in-progress rebuilds. Or should there be a pair of [community-testing] and [community-staging]? Sorry about adding complexity to this, as I realize that makes it less likely that it actually gets implemented...

2 1

Re: [arch-general] [arch-dev-public] Redefining [testing] and a new [staging] repo
by Ray Kohler 07 May '10

07 May '10

On Fri, May 7, 2010 at 12:44 PM, Pierre Schmitz <pierre(a)archlinux.de> wrote: > Hi all, > > here is another crazy idea I was thinking about for some days. This should > improve our overall package quality and simplify our work flow. The > problem > with out current [testing] repository are these: > * it is only used by very few people. Most of the times we don't get much > feedback until packages are moved to core or extra > * it is often in a inconsistent state; especially during incomplete so > name bump rebuilds > * sometimes packages are known to be broken or unstable > > On the other side we are sometimes in need of some intermediate > repository. For example single people stack a pile of packages in their > home dirs until they can be moved to a repo at once. We have also seen > temporary repos like jpng to manage larger rebuilds. > > My idea is to redefine the testing repo and introduce a new staging one. > (remember the good old days? ;-)) > With the implementation of the package pooling moving packages between > repos can be done with nearly no overhead. So ideally > we should be able to use testing more often, even for a very short period > like a > day. > > proposal for [testing] > * never push any known-to-be-broken packages here (for example incomplete > rebuilds) > * candidates for core are put here > * ideally new builds of important/critical packages or major rebuilds can > be put here to test them by a larger audience. > * don't put any package in here which are never meant to be moved to > core/extra. (like experimental alpha software etc.) > > proposal for [staging] > * this repo should only used by devs and tus > * it is not meant to be used on a production system > * it should only be enabled in a packages build environment (chroot) > * this could be even excluded from outbound rsync. Due to package pooling > packages would still be propagated. And moving those packages to other > repos will be "instantly". > > Summing things up more packages should be passed through testing, more > users should be able to use testing without breaking their systems and we > don't have to make them reading the high traffic arch-dev-public list. We > also should be able to collaborate more in packaging: Dev A puts a new lib > into [staging] and another one can start rebuild other packages using that > lib. Another common use case would be large builds like KDE we usually > start packaging one week before release. Till now those were put into > users' staging dirs and the other devs had to manually download them, > create a local repo and install them. > > So, what do you think about this idea? Even though I'm just a user, I'd like to add my support to this idea. I even considered proposing it myself less than a month ago. I run [testing], since I want to contribute to finding problems before they reach [core] and [extra], but I don't like having to deal with [testing] having rebuilds in it. I have never broken my systems by a bad package in [testing] but have unfortunately pulled incomplete rebuilds a few times now. I guess the point of this post is to show that there is at least one user who cares enough about this idea to speak up for it. I suspect there are others who don't run [testing] now who would begin doing so if this plan were implemented.

3 2