- Arch-general - lists.archlinux.org

[arch-general] Is fcitx must executed under a chinese locale?
by adrian sun 17 May '12

17 May '12

Hi buddy, I am using fcitx for inputting chinese words. I got a problem. If I change my locale to en_US.UTF-8, I can not invoke FCITX by pressing the 'CTRL+Space'. After I changed my locale to zh_CN.UTF-8, FCITX worked well. The question is can I use FCITX under the english locale? if I can, how to configure it? I read the english wiki of fcitx and it says I should check my locale. https://wiki.archlinux.org/index.php/Fcitx Well, only if I change locale to chinese, FCITX works. For some reasons, I dont want to work under a chinese environment. I find a little difference on wikis that chinese wiki says I can work under english locale, but the way I tried didn't work. Any idea or solution? Thanks!!! Adrian.

3 5

[arch-general] Console font not working anymore
by "Jérôme M. Berger" 17 May '12

17 May '12

Hi, Following a system update, I noticed that the console font is not set anymore (I can't tell how recent this is since I don't go to the console everyday). After some judicious editing of /etc/rc.d/functions (to remove a 2>/dev/null and add a sleep so that I can see the error messages) and some googling, I found that the issue was due to the framebuffer not being initialized. I now have two issues: First issue: how can I find the right value for the vga= option? According to https://wiki.archlinux.org/index.php/GRUB#Framebuffer_resolution there are three ways, none of which work: - GRUB recognized value -> does not list my monitor resolution (1920x1080) and the other 16:9 codes listed (1280x720) appear to be wrong since they result in a distorted display; - hwinfo --framebuffer -> does not show anything. I looked through the full hwinfo output without options, but there didn't seem to be anything framebuffer related there; - vbetest -> does not work in 64 bits. Second issue: when I activate the framebuffer with some default resolution (say 1024x768 vga=773), the font is set properly, but it is not kept: a few seconds after setting the font, the screen resolution changes and the font goes back to the default. Once the computer has finished booting, if I log in as root, source /etc/rc.conf and /etc/rc.d/functions, then call set_consolefont manually, the console fonts are set properly and kept until I reboot. I have a fully up to date 64bits Arch install. The relevant hardware is: - CPU: Athlon 64X2 3800+ - Graphic card: ATI Radeon HD 4350 - Monitor: Samsung SyncMaster P2370 Thanks in advance, Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger(a)jabber.fr

3 3

[arch-general] error installing package that relies on soprano (k9copy)
by D. R. Evans 16 May '12

16 May '12

When I try to install k9copy, I receive the following error message: :: Retrieving packages from extra... error: failed retrieving file 'soprano-2.7.5-1-i686.pkg.tar.xz' from ftp.archlinux.org : Given file does not exist 1. Is this a packaging error of some kind (presumably in the k9copy package)? 2. Is there something I can do to allow me to avoid this problem and install k9copy? Doc -- Web: http://www.sff.net/people/N7DR

3 3

[arch-general] Timing issues when decrypting a USB drive during boot (/etc/crypttab)
by Julius Adorf 14 May '12

14 May '12

Hello, Recently, I tried to automatically unlock an encrypted external USB hard drive on Arch Linux. I have done this by inserting an appropriate entry into /etc/crypttab. I chose the device to be unlocked by cryptsetup with a key file by UUID. Unfortunately, the unlocking failed at boot time ("device does not exist or access denied"). After some debugging via /etc/rc.sysinit, I found out that it is a timing issue and the USB drive which is a couple of years old was not ready yet at the time the /etc/crypttab was read and processed. A similar issue has been reported here: https://bbs.archlinux.org/viewtopic.php?id=137467 For now, I have inserted a workaround into /etc/rc.local which unlocks the disk after an initial delay. This is still programming by coincidence; I wonder whether there is any better (i.e. reliable) solution to this problem? Best, Julius

6 8

[arch-general] broken zip after upgrade
by Arno Gaboury 13 May '12

13 May '12

Dear list, after a whole bunch of fresh upgrades yesterday, 2012/05/12, I can not unzip with File Roller (default app), with expanding tar.gz still working. Here are the two error messages: */There is no command installed for Zip archive files. Do you want to search for a command to open this file?/* Then I click on search command button, it brings a new window: */There was an internal error trying to search for applications: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.PackageKit was not provided by any .service files/* I have no certitude, but I suspect the outdated polkit 0.104 could be the culprit. There is a new 0.105 version since a few weeks on the website: http://cgit.freedesktop.org/polkit/snapshot/polkit-0.105.tar.gz Following instructions, I was able to build it fine, but I don't want to make install on my system, as I understand it is a good way to break it. I decided to create a package following the Archwiki. Here is my PKGBUILD file : /*# $Id$ # Maintainer: Jan de Groot <jgc(a)archlinux.org> pkgname=polkit pkgver=0.105 pkgrel=2 pkgdesc="Application development toolkit for controlling system-wide privileges" arch=(i686 x86_64) license=('LGPL') url="http://www.freedesktop.org/wiki/Software/PolicyKit" depends=('glib2' 'pam' 'expat') makedepends=('intltool' 'gtk-doc' 'gobject-introspection') replaces=('policykit') options=('!libtool') source=(http://cgit.freedesktop.org/polkit/snapshot/$pkgname-$pkgver.tar.gz) md5sums=('ad070a194d444fa89f627fd54a124fad') build() { cd $pkgname-$pkgver autoconf ./autogen.sh make } check() { cd $pkgname-$pkgver make -k check } package() { cd $pkgname-$pkgver make DESTDIR="$pkgdir" install install -m644 "$srcdir/polkit.pam" "$pkgdir/etc/pam.d/polkit-1" }*/ I corrected the old 0.104 one according to the new changes. I have problem with md5sums, and have no real idea how to write the numbers. makepkg returns an error : /*Validating source files with md5sums... polkit-0.105.tar.gz ... FAILED*/ So 2 questions : how to deal with this md5sums error? Once this issue is solved, can I makepkg and install on my system, whitout breaking anything? TY for any help.

4 6

[arch-general] wallpaper for 1920x1080 screens.
by Boris Le Ninivin 12 May '12

12 May '12

Hi everyone. I've made this wallpaper http://borisln.deviantart.com/art/Archlinux-Wallpaper-1-300929958 since I didn't find any red wallpaper which pleased me, big enough for my screen in the official package, nor on Google images. It's licensed under creative commons BY-SA, so if one wants to put it in the official archlinux-wallpaper package, feel free to do so :) Also, if anyone has any remarks or anything to say about it, I'm all ears. Have a nice day!

9 15

[arch-general] FS#29803 - Kernel 3.3.4-2 panic
by Fabiano Furtado Pessoa Coelho 12 May '12

12 May '12

Hi, Following Dave's comment (https://bugs.archlinux.org/task/29803) I've generated my initramfs, reinstalling the linux package: pacman -S linux What can I do to fix this problem? Thank you!!!

5 7

[arch-general] standards on AUR content
by Ruslan Nabioullin 11 May '12

11 May '12

I believe that there should be more comprehensive, clear, and explicit standards on what content is allowed to be installed by an AUR package. There already exist two guidelines [1]: 1. usefulness: "Make sure the package is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission." 2. IP, content type (?) restrictions: "For most cases, everything is permitted, as long as you are in compliance with the licensing terms of the software..." The former is acceptable because "usefulness" is inherently subjective. The latter does state an important restriction regarding IP, but implicitly assumes that only software is permissible for AUR packages, when in fact there exist packages within the AUR which install only non-executable data. I believe that it is overall community consensus that such packages are permissible as long as they install documentation for a particular software package, a set of *closely*-related software packages, or the Archlinux distro as a whole (e.g., offline Archlinux wiki), and that documentation not directly applicable to the aforementioned, any standards (e.g., FHS, OFM), and any books (e.g., Pro Git) are outside the scope of the AUR. Any ideas? Do these proposed standards accurately reflect community consensus? [1] https://wiki.archlinux.org/index.php/Arch_User_Repository -Ruslan -- Ruslan Nabioullin rnabioullin(a)gmail.com

2 2

[arch-general] drop slim in favor of lightdm
by Christian Hesse 09 May '12

09 May '12

Hello everybody, slim has some known security weaknesses (for example it has no separate greeter process thus the graphical interface is running with super user privileges) and a lot of open bugs. Additionally it does not support latest packages (consolekit and friends) out of the box. Though lately the SVN got some commits and a new version has been released the arch package has not been updated since it was flagged out of date in February. I propose to drop slim from [extra] and replace it with lightdm and lightdm-gtk-greeter. This is a very active project with responsive upstream developer. Security is a key feature and it integrates with latest desktop techniques really well. The AUR package for lightdm has 259 votes at the time of writing. Any thoughts on that? -- main(a,b){char*/* Schoene Gruesse */c="B?IJj;M" "EHCX:;";for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}

13 16

Re: [arch-general] [arch-projects] netcfg status?
by Thomas Bächler 09 May '12

09 May '12

Am 09.05.2012 16:38, schrieb Jouke Witteveen: > The latest version is in testing for no more than five days now. I > sent a mail regarding the move to core: > http://mailman.archlinux.org/pipermail/arch-projects/2012-April/002765.html > Not much has happened since and I am quite confident in the state of > the code. Some things are a bit hacky still, but it shouldn't be worse > than it has always been. The main issue at the moment is the wiki. I > am not against moving to core by the end of the week. Alright, the end of the week it is then (unless major bugs occur).

1 0