March 2009 - Arch-general - lists.archlinux.org

[arch-general] gran paradiso crashes permanently
by Markus Krell 21 Mar '09

21 Mar '09

Hi arch users out there, since a few weeks, my firefox crashes permanently. I disabled all three Add Ons, i had installed, but still no difference. Really annoying, so is there any possibility to find out why firefox crashes, often a few minutes after starting? Launched from shell, firefox detaches directly, so i dont know where to look first. Version is up to date: 3.0.7-1 Thx for any answers. Markus

5 10

[arch-general] Ruby gem packaging guidelines
by Daenyth Blank 21 Mar '09

21 Mar '09

I've made a draft of some packaging guidelines for ruby gems; anyone care to comment or expand them? http://wiki.archlinux.org/index.php/Ruby_Gem_Package_Guidelines

3 5

[arch-general] texlive-core errors
by Henri Häkkinen 21 Mar '09

21 Mar '09

Hello. I have some problems with installing LaTeX. Here is the output of `pacman -S texlive-core`: :: Retrieving packages from extra... t1lib-5.1.2-2-i686 838.9K 87.9K/s 00:00:10 [#####################] 100% gd-2.0.35-1 175.9K 52.8K/s 00:00:03 [#####################] 100% libsigsegv-2.4-1 9.9K 69.7K/s 00:00:00 [#####################] 100% texlive-bin-2008-3-i686 14.4M 97.5K/s 00:02:32 [#####################] 100% texlive-core-2008.1... 54.1M 86.5K/s 00:10:40 [#####################] 100% checking package integrity... (5/5) checking for file conflicts [#####################] 100% (1/5) installing t1lib [#####################] 100% (2/5) installing gd [#####################] 100% (3/5) installing libsigsegv [#####################] 100% (4/5) installing texlive-bin [#####################] 100% Optional dependencies for texlive-bin psutils t1utils perl (5/5) installing texlive-core [#####################] 100% updating the filename database... done creating the fontmap files with updmap... done Error: `pdftex -ini -jobname=etex -progname=etex -translate-file=cp227.tcx *etex.ini' failed Error: `pdftex -ini -jobname=pdfetex -progname=pdfetex -translate-file=cp227.tcx *pdfetex.ini' failed Error: `pdftex -ini -jobname=pdftex -progname=pdftex -translate-file=cp227.tcx *pdfetex.ini' failed Error: `xetex -ini -jobname=xetex -progname=xetex -etex xetex.ini' failed ############################################################################### fmtutil: Error! Not all formats have been built successfully. Visit the log files in directory /usr/share/texmf-var/web2c for details. ############################################################################### This is a summary of all `failed' messages and warnings: `pdftex -ini -jobname=etex -progname=etex -translate-file=cp227.tcx *etex.ini' failed `pdftex -ini -jobname=pdfetex -progname=pdfetex -translate-file=cp227.tcx *pdfetex.ini' failed `pdftex -ini -jobname=pdftex -progname=pdftex -translate-file=cp227.tcx *pdfetex.ini' failed `xetex -ini -jobname=xetex -progname=xetex -etex xetex.ini' failed creating all formats... done. (logs are under /usr/share/texmf-var/web2c/<engine>/<formatname>.log) ------------------------------------------------------------------ PLEASE read the TeXLive documentation at http://wiki.archlinux.org/index.php/TeXLive ------------------------------------------------------------------ Optional dependencies for texlive-core perl ruby ghostscript psutils -- Henri Häkkinen

2 2

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