- Arch-general - lists.archlinux.org

[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

[arch-general] [xmonad] Screenshot of all workspaces?
by Nick Stepa 07 May '10

07 May '10

Hello all! I use xmonad and want to make screenshot of all workspaces at once. How can I do it? Plz don`t say: "For each workspace - switch to it and use scrot" (=

4 3

[arch-general] [signoff] kernel26-lts 2.6.32.12-1
by Tobias Powalowski 07 May '10

07 May '10

Hi guys, first try of lts bump to .32 series: - udev-compat is not needed anymore for this kernel - updated lts config to this kernel series - lzma compression is now used With this LTS release, i want to provide binary kernel modules too. Shall the binary modules be part of [core] then too, if the kernel26 module is there too? Thanks for feedback and input. Please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[arch-general] Is preload really working ??
by Nilesh Govindarajan 07 May '10

07 May '10

Hi, I'm running preload since about two months, but I haven't seen any improvement in program startup times especially firefox, which I launch and close every now and then. -- Nilesh Govindarajan Site & Server Administrator www.itech7.com मेरा भारत महान ! मम भारत: महत्तम भवतु !

9 12

[arch-general] about arch
by Juan Diego Tascón 06 May '10

06 May '10

Good day amigos, I was reading the "about" page (http://www.archlinux.org/about/) in the archlinux website and I noticed that this line is a little outdated: "Arch also offers an [unsupported] section in the Arch Linux User Repository (AUR), which contains over 9,000 build scripts" It should say "over 21.000 build scripts". And one more question: is there a proposed starting date or a proposed selection procedure or just additional information for the Junior Developer scheme? I sent an email to Allan (@archlinux.org) the day it opened but I have not received any reply yet, I am starting to think that I sent it to the wrong email address. Have a nice day. Chao.

7 7