- Arch-general - lists.archlinux.org

Re: [arch-general] [arch-dev-public] Bug Day - Saturday 21st March
by Allan McRae 21 Mar '09

21 Mar '09

Allan McRae wrote: > On Saturday the 21st of March we will be holding a bug day to combat > the ever increasing number of reports in our bug tracker. We will > clear outdated reports, fix/implement those that already have patches > provided or are trivial to fix/implement and discuss the pros and cons > of implementing some feature requests. A rough TODO list that you can > add to is on the wiki (http://wiki.archlinux.org/index.php/Bug_Day_TODO) > > Please join us in #archlinux-bugs on irc.freenode.net during the 21st > of March. We live in many different timezones, so hopefully a dev will > be present at all times during the day. Just a reminder about the bug day today/tommorrow (depending on time zone). We are down to 650 bugs already (from ~680 a week ago). Allan

1 0

[arch-general] what about ELF rpath in Arch Linux?
by Gerardo Exequiel Pozzi 21 Mar '09

21 Mar '09

Hi, (first: sorry my very bad english) I see that many executables and libraries in Arch Linux don't take care about rpath in package creation step. Then when executed, the ld-linux will find libraries first in the rpath , and if fails will go to search in the cache ld.so.cache, instead of directly search here) So for example if you execute the... setfacl/getfacl/chacl (in package from core/acl, and this is the only package in [core] that have this issue with binaries) will find in libs in varius incorrects paths for example: $ readelf -d /usr/bin/getfacl | grep RPATH 0x0000000f (RPATH) Library rpath: [/home/thomas/arch/repos/core/base/acl/pkg/usr/lib] $ LD_DEBUG=libs setfacl 10323: find library=libacl.so.1 [0]; searching 10323: search (*** stripped here same paths below... ***) (RPATH from file setfacl) 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/i686/sse2/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/i686/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/sse2/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/tls/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/i686/sse2/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/i686/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/sse2/libacl.so.1 10323: trying file=/home/thomas/arch/repos/core/base/acl/pkg/usr/lib/libacl.so.1 10323: search cache=/etc/ld.so.cache 10323: trying file=/lib/libacl.so.1 10323: The issue here is for example if a user "thomas" in my system, create a libacl.so.1 in any of these paths, the setfacl will use them insteads of the correct libacl.so.1, and if the libacl.so.1 from thomas contain a malicious code, the user that execute it are in problem :(, root for example. OK managing rpath at build time vary from package to package, some that uses autotools/libtool, the configure script, have a --disable-rpath for controling this behavior, and other don't have. Others require rpath at build time to linking executables from the same source, and other always hardcore it (gcc -Wl,--rpath...), etc, etc. In libtool, can change a M4 macro to don't use rpath for example. There is a simple tool, to remove rpath from ELF files called chrpath [#1] (seems that cmake build system can use an aproach based on chrpath to delete rpath from ELF) For example: # /bin/ls -l /usr/bin/setfacl -rwxr-xr-x 1 root root 25052 2008-02-26 13:23 /usr/bin/setfacl # chrpath -d /usr/bin/setfacl # /bin/ls -l /usr/bin/setfacl -rwxr-xr-x 1 root root 25052 2009-03-20 01:06 /usr/bin/setfacl # LD_DEBUG=libs setfacl 11033: find library=libacl.so.1 [0]; searching 11033: search cache=/etc/ld.so.cache 11033: trying file=/lib/libacl.so.1 And now is correct and secure. The minor problem here, _and don't make much sense_ is that will do some aditionals system calls open() and stat64() for each inexistent libs on loading. Many others have /usr/lib (and many many others paths) as rpath, then when execute will look for the first library that need to load at /usr/lib/tls/i686/sse2:/usr/lib/tls/i686:/usr/lib/tls/sse2:/usr/lib/tls:/usr/lib/i686/sse2:/usr/lib/i686:/usr/lib/sse2 (and these are removed from search path for next libs), and then for all libs will look first in /usr/lib if fails do a /etc/ld.so.cache search The rpath is important when managing many versions of the same libs with same soname, for example for debuging/testing purposes. For example i see googling that in some distros (like Debian[s]) and in some BSDs the rpath is removed from all ELF files, except that in that is necessary required. Then my question: what is the position of arch-dev-team about rpath? (remember: don't take this as a mail as feature request, is just one question) Thanks in advance, I hope not to have bothered with this. Good Luck! / ¡Buena suerte! [#1] chrpath: The original home don't work http://directory.fsf.org/project/chrpath/ i use a debian mirror in my pkgbuild http://aur.archlinux.org/packages.php?ID=24818 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

3 3

[arch-general] Routing Problems with Wifi Link 5100
by Thomas Bohn 20 Mar '09

20 Mar '09

Hello, I use an Intel Wifi Link 5100 in my eeePC 1000H, since it appears to me the better card compared to the rt2860 which came with ther computer. But even this card is not w/o problems. After a while (can't really tell how long this while is) I have problem to access websites or get the RSS feeds or even update my pacman databases. But other sites worked without problems, e.g. I could browse through the Firefox addons but I couldn't install them and I couldn't access www.heise.de but www.apple.com worked a little bit. I could resolve the hosts w/o problems and I could ping www.heise.de w/o an error. After a reboot everything went back to normal, turning off the wifi card or reconnecting wasn't enough though. Linux proton 2.6.28-ARCH #1 SMP PREEMPT Tue Mar 17 06:42:43 UTC 2009 i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux The only thing I could find in the logs is this (every 30 minutes): --- dhcpcd[4841]: wlan0: renewing lease of 192.168.1.101 dhcpcd[4841]: wlan0: acknowledged 192.168.1.101 from 192.168.1.1 dhcpcd[4841]: wlan0: leased 192.168.1.101 for 3600 seconds --- I hope someone can help me. Thomas

1 0

[arch-general] smbd cannot be killed
by Sergey Manucharian 20 Mar '09

20 Mar '09

Hi folks, I've posted a message about a samba issue I'm experiencing on the samba community forum. The issue itself is not relevant to this list, but the bottom line is that I cannot restart samba - several instances of smbd continue running and even "kill -9 smbd" doesn't help... I have to restart the server in such cases, which is not good idea for the domain controller. The below is what samba people talk: > If kill -9 does not help, you have a kernel problem. There > have been kernels with broken inotify that leads to runaway > smbd processes chewing CPU. You might want to try > notify:inotify = false > or upgrade your kernel. May it be true? Did anybody experience such things? Thanks, Sergey

1 0

[arch-general] Away - Inactive
by Andrea Scarpino 20 Mar '09

20 Mar '09

Hi ML, I'll be in Milan from 21th March to 27th March, and I'll be without my laptop for this time :( Also I think I'll not have a connection to check my mailbox. Anyone can edit my PGBUILDs to do an upgrade or fix some bugs. Good work to all. Cheers -- Andrea `BaSh` Scarpino Arch Linux Developer

1 0

Re: [arch-general] [arch-dev-public] Scim and arphic fonts update in [testing]
by Eric Bélanger 19 Mar '09

19 Mar '09

On Tue, Mar 10, 2009 at 12:45 PM, Firmicus <Firmicus(a)gmx.net> wrote: > Eric Bélanger a écrit : >> On Fri, Feb 27, 2009 at 10:59 PM, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: >> >>> Hi all, >>> >>> I've just updated several scim-related packages. They are in the >>> [testing] repo. The updated packages are: >>> >>> anthy >>> libchewing >>> libhangul >>> scim >>> scim-anthy >>> scim-chewing >>> scim-tables >>> uim >>> scim-uim (no update, just rebuild against uim 1.5.5) >>> >>> As I don't use these packages (I believe no dev use them either), I >>> could only do minimal testing. It would be nice if users of these >>> packages test them and report if they work properly or if there are >>> problems with them. >>> >>> I've also updated (in [testing] repo) the Arphic fonts: >>> ttf-arphic-ukai and ttf-arphic-uming >>> >>> There are two points about these fonts: >>> >>> 1. According to upstream: >>> "This release contains Firefly's Bitmap fonts. The Bitmap fonts are available >>> for 11, 12, 13, 14, 15 and 16 pixel and currently cover Big5 and GB2312. >>> HKSCS is currently not supported as there are many more characters missing. >>> So, for Big5 and GB2312 characters the bitmap glyphs should improve the >>> rendering, but for all other characters, the rendering is the same like >>> without bitmap glyphs." >>> >>> I might be nice to get comments about someone using these fonts to see >>> if the ttf-fireflysung package is indeed no longer needed >>> (http://bugs.archlinux.org/task/8951) >>> >>> 2. The updated ttf-arphic-* packages in testing provide the fonts as >>> a TrueType Collection, i.e. the fonts come in 4 flavors (CN, HK, TW >>> and TW MBE), with different glyph shapes according to the preferred >>> shapes in each region (more info here: >>> http://www.freedesktop.org/wiki/Software/CJKUnifonts/Download) As a >>> result TeX users will encounter trouble using this font. The >>> following programs/libraries are known to not fully support TTC files >>> and can usually only use the first fontface of the TTC: >>> - jdk and openjdk6 >>> - imlib2 and applications which use imlib2. >>> >>> Again, I and probably none of the devs don't use these fonts so >>> feedback from users would be nice. >>> >>> Eric >>> >>> >> >> Did anyone had time to test them yet? >> >> Eric >> >> > I just tested scim to input Chinese with pinyin method and it works > fine. I don't use the other scim-related pkgs. I have tested the Arphic > fonts rather superficially, but at first sight they are just ok (tested > in gedit and with xetex). > > NB: These TTC fonts won't be a problem for XeTeX users (xetex is part of > texlive-core), and other TeX users actually use the Postscript versions > of the same fonts that come with texlive-lang-cjk. > > F > I received other testers' reports by personnal email or the bug tracker (there was a couple of very minor bugs that were fixed last week: a scim problem with java clients and gnome-panel is now an optdepends for uim) and everything seems to be working fine. I've just moved the packages in extra. If there are problems, submit a bug report. Thanks to all the testers.

1 2

Re: [arch-general] [aur-general] Arch's Vim Failings & Solution Suggestions
by Daenyth Blank 19 Mar '09

19 Mar '09

On Thu, Mar 19, 2009 at 10:54, Andrei Thorp <garoth(a)gmail.com> wrote: > Hello, fellow Archers. > > Recently, I had a question about Vim, so I went to the #vim channel in > IRC. I was doing something > that should be working, but it wasn't. Surprisingly, the question came > up, "Are you on Arch?" > > Turns out that several of the peolpe I most respect in the #vim IRC > channel are very unhappy with the quality of Arch's Vim package. One > even (jokingly?) asked if they could officially not support Arch in > the channel, which I found somewhat alarming. I suggested that we > should instead help improve the Arch package. > > I hate to pick on people, but according to the generally kind folks on > IRC, the Vim package for Arch has quite a few issues, and the > maintainer hasn't addressed some outstanding bugs in quite a long > while. > > As some of you may know, James Vega (jamessan) is an outstanding Vim > user and the Debian package maintainer for Vim. I asked him to send me > what he saw as the problems with the Arch package, and he was kind > enough to send along some suggestions. They are attached in this > forward. > > Thank you, > > -Andrei Thorp > > ---------- Forwarded message ---------- > From: James Vega <jamessan(a)debian.org> > Date: Thu, Mar 19, 2009 at 2:29 AM > Subject: Arch's Vim failings > To: garoth(a)gmail.com > > > Andrei, > > Thanks for being receptive to trying to address the issues in Arch's Vim > packaging. Below are the major points that stand out. > > 1) gvim package: Shipping an /etc/gvimrc which, due to the order that > Vim loads rc files, overrides any settings in the user's ~/.vimrc. > Considering that some users make the conscious decision to keep all > their settings in their ~/.vimrc instead of using both ~/.vimrc and > ~/.gvimrc, this is at the very least annoying. More in depth > discussion is contained in the nearly year old, unfixed bug[0] about > this issue. > > 2) vi package: The package is built such that the resulting vi binary > reads its config from the completely non-standard ~/.virc. > Presumably this is to allow different configurations for the > different feature-sets avaiable in vi vs. vim packages. Fortunately, > Vim has methods to deal with this already such as being able to check > what name was used to invoke Vim[1] and explicitly checking for > feature support[2]. > > 3) vi, vim, and gvim packages: Explicitly building Vim with $VIMRUNTIME > == $VIM by specifying "--with-global-runtime=/usr/share/vim" to > configure. This doesn't need to be specified to configure as it will > be set to the correct directory on its own. If they insist on > specifying it, the directory should be /usr/share/vim/vimXY (where XY > is Vim's version number -- 72 for current Vim). > > This manifests various problems, the most noticeable being that the > 'runtimepath' option in Vim has /usr/share/vim listed twice, thus > causing runtime files to be sourced twice and causing duplicate > information when using common scripting methods for discovering files > in the runtimepath[3]. > > -- > James > GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan(a)debian.org> > > [0] - http://bugs.archlinux.org/task/10303 > [1] - if v:progname == 'vi' > [2] - if has('cscope') > [3] - globpath(&rtp, 'colors/*') > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAknB5lcACgkQDb3UpmEybUCg6ACgjRFE4YnrbEGMq8uY51CZqRis > xZsAnjbOC4BsAv/hYG9hcfmbogJLdLtX > =HJf3 > -----END PGP SIGNATURE----- > I don't have a whole lot to add to this, except that it seems like a good idea to confer with the vim developers to raise the quality of the package. I would file a bug report on the Arch tracker. (Also sending to arch-general, so this gets more exposure)

1 0

[arch-general] community/gtk-engine-murrine 0.90.2-1 borked
by Damjan Georgievski 19 Mar '09

19 Mar '09

it seems that the community/gtk-engine-murrine package has been updated to the gtk2 version in testing/ so that now all GTK apps are with the standard ugly Win95 look, and complain that: (gtk-chtheme:5522): Gtk-WARNING **: GModule (/usr/lib/gtk-2.0/2.10.0/engines/libmurrine.so) initialization check failed: Gtk+ version too old (micro mismatch) don't do this please :) -- damjan

2 1

[arch-general] Include sbcl sources with a fixed system path
by Daniel White 18 Mar '09

18 Mar '09

Presently the pathname translation for "SYS" is '/tmp/sbcl/trunk/src/sbcl-1.0.24/'. This kind of makes it hard for 'M-.' to work well in slime. This patch for the PKGBUILD generates a modified core with the translation for "SYS" changed to the '/usr/share/sbcl-source/'. Basically it means that we can put the 'src' and 'contrib' directories form the sbcl sources in '/usr/share/sbcl-source/' and the various source lookup functions in sbcl and slime will work. This was inspired from Debian's changes to support the common-lisp-controller which also happens to update the pathname translations. The big question is whether or not it is worth splitting the source into a new package (sbcl-source). With the source included it comes to around 13Mb. Either way the modified core won't cause a problem since the path is already wrong. -- Daniel White

2 2

[arch-general] On rolling release system and its benefits.
by Ali H. Caliskan 18 Mar '09

18 Mar '09

Hi, I've been using Arch since few months and I enjoy using it everyday that goes by. However, during that time, while helping Arch users on the forum, I've encountered some issues concerning upgrades and broken packages. I personally think Arch is stable and well maintained compared to other big distros, but that's a rolling release stability, that lasts only few days or weeks. What I would like Arch developers is to extend the rolling release into a snapshot release of an entire list of officially maintained packages, comprising both core and extra branches. At least it would be a great way of using Arch for 5 to 6 moths and then upgrade to a next snapshot release. I'm not talking about stable releases, just a snapshot of a rolling state. Snapshot releases does also benefit the natural need of closing bugs. Not to mention, it does make it easy to maintain orphaned packages as well. Regards, Ali

4 4