- Arch-general - lists.archlinux.org

[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

[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

9 15

Re: [arch-general] [arch-dev-public] Fixing licenses / sources
by Gerardo Exequiel Pozzi 17 Mar '09

17 Mar '09

> The list : > http://wiki.archlinux.org/index.php/User:Snowman/License_Rebuild_TODO > > Eric Hi Eric, I made a list of 90 extra-packages from your list, that also have bad mandir Please see here: http://bugs.archlinux.org/task/13765#comment41164 Both isdn4k-utils and xinetd from core have bad mandir. Take care. Yahoo! Cocina Recetas prácticas y comida saludable http://ar.mujer.yahoo.com/cocina/

3 3

[arch-general] [signoff] kernel26 2.6.28.8-1
by Tobias Powalowski 17 Mar '09

17 Mar '09

Hi guys, new kernel adresses the following things: - bump to latest version fixed: http://bugs.archlinux.org/task/13717 please signoff for both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-general] weird messages
by David Rosenstrauch 16 Mar '09

16 Mar '09

My server's been getting a load of weird messages in my dmesg and log files recently: Mar 16 06:38:27 darsys9 kernel: ata4: EH complete And sometimes also: Mar 16 06:38:27 darsys9 kernel: ata4: EH pending after 5 tries, giving up Anyone know what this is about and/or if there's some recent upgrade that might be causing it? I googled up some info about it (including a thread about it on the Arch forum), but all the info I could find is older and says that (at the time) the cause was a particular kernel version, and that upgrading the kernel would make it go away. But as I'm up-to-date with the current kernel, that's obviously not the issue now. Any info appreciated! TIA, DR

2 1