- Arch-general - lists.archlinux.org

[arch-general] Configure a console font without initrd
by jugree＠lavabit.com 21 Feb '13

21 Feb '13

Hello. I set `KEYMAP' and `FONT' in `/etc/vconsole.conf'. `sudo /usr/lib/systemd/systemd-vconsole-setup' works. But how can I use it after `reboot'? `mkinitcpio.conf' is not an option because I don't use initrd. I tried to add the above line to `/etc/rc.local', but it did not work. Thanks

5 6

[arch-general] A question about handling a system with two wired network interfaces?
by Mike Cloaked 21 Feb '13

21 Feb '13

I have a system with two ethernet sockets on the motherboard, and I have until very recently been finding that my network at random failed to come up during the boot process. I have the ethernet cable plugged into only one of the two sockets, and assign the names to the interfaces as eno1 and eno2 - because left to its own it assigned one of them as name "eno1" and the other to "eth0" or "eth1" at random between boots! I was surprised that it chose ethX at all for the second name, given this is running with the new naming scheme! However following the hints at: https://wiki.archlinux.org/index.php/Udev#Network_device I specify that udev fix the two interface names as eno1 and eno2 - but still the network failed to come up sometimes at boot. It seemed to be pure chance as to whether it came up on any particular boot. I tried both NetworkManager as well as ifplugd/netcfg and both seemed to behave the same way - at any one time I only had one or other scheme for getting the network up. What I then presumed was that although the same two names are always assigned, the hardware mac address to which of the two physical network ports was being assigned was being assigned differently to the two names - i.e. sometimes being en01 and sometimes being eno2. Why this matters is that I assign a static ip address to eno1 only and don't use eno2. This would only be an issue if there was more than one NIC in the system. The system boots really fast as it has SSD drives, which possibly was not allowing enough time for the name assignment, so I then found the advice at: https://wiki.archlinux.org/index.php/Rename_network_interfaces where it suggests editing the systemd unit file for in my case NetworkManager service - which I then did and this finally seems to have fixed the problem though I will still need to boot over a period of days to check if the network comes up "every" time now. The wiki page refers to the network service file, but I applied this to the NetworkManager service file. So the question that I hope someone can answer is whether in the case of multiple NICs in a system the new network names, although the same "set" of names is used for all the cards in the system, will still need this systemd unit file amendment - i.e. adding the two lines: Requires=systemd-udev-settle.service After=systemd-udev-settle.service to the [unit] section in order to get the correct name associated with the same hardware mac address every boot? If someone who understands these things in detail could confirm if my understanding is correct I would appreciate it? Many thanks. -- mike c

2 9

[arch-general] dropping OpenJDK6 by the end of this month
by Andreas Radke 20 Feb '13

20 Feb '13

We will remove the OpenJDK6 packages by the end of this month. All users should move to OpenJDK7 based packages jre7-openjdk/jre7-openjdk-headless/jdk7-openjdk (or the Oracle based JRE/JDK from AUR) very soon. The next OpenJDK7 update will replace openjdk6 on your system. -Andy

1 0

[arch-general] UTC
by Ralf Mardorf 20 Feb '13

20 Feb '13

Hi :) after a reboot there always is an offset of -3600 sec, when running ntpdate. # timedatectl status | grep local RTC in local TZ: yes Warning: The RTC is configured to maintain time in the local time zone. This RTC in UTC, by calling 'timedatectl set-local-rtc 0'. # timedatectl set-local-rtc 1 Failed to issue method call: Input/output error Sometimes I don't get an output when running "timedatectl set-local-rtc 1". # cat /etc/adjtime LOCAL # ls -l /etc/localtime lrwxrwxrwx 1 root root 33 Feb 17 22:35 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin For my old Arch Linux install there wasn't this issue. I suspect I make a mistake, I'm missing something now. I already asked at the German forums, but until now without success: https://bbs.archlinux.de/viewtopic.php?id=23477 FWIW I don't have a Windows installed, this machine is a *NIX multi-boot only. I'm aware about the drawbacks and advantages of both, the usage of UTC and local time and in 10 years I never experienced a drawback using local time. At the moment it's simply more comfortable for me, if I've got local time available for the BIOS. The reason for this should be unimportant for this thread. Regards, Ralf

5 6

Re: [arch-general] linux-tools-meta, why?
by Sébastien Luttringer 20 Feb '13

20 Feb '13

On Wed, Feb 20, 2013 at 1:31 AM, Brock.Zheng <goodmenzy(a)gmail.com> wrote: > Hi all > > I found that package in community, > The pkg has no content. The only file in it's pkg is > a .PKGINFO file: > > $> tar -tf archlinux/community/os/x86_64/linux-tools-meta-3.8-1-x86_64.pkg.tar.xz > .PKGINFO > > Any on know why? > This share purposes of others meta-packages in our repository and others distro. Shortly, it will allow you to follow new split packages addition from linux-tools group. You can find more complete explanation in our wiki[1]. Cheers, [1] https://wiki.archlinux.org/index.php/KDE_Packages#Using_Meta-Packages -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A

1 0

Re: [arch-general] Linux-3.7.3-1-i686 blank screen
by Brian Wood 19 Feb '13

19 Feb '13

Whiskers: > I have installed xf86-video-vesa 2.3.2-2 but while > xf86-video-nouveau > 1.0.6-1 is also installed that seems to be given preference > in the boot > procedure, so I'll remove it and keep my fingers crossed! I experienced similar problems. I wasn't able to start X without xf86-video-nouveau, but had core dumps with it. Now I'm trying an install on another machine with an Intel video card. So far so good, but it hasn't been long enough to tell. I'm new to Arch and have been using another distro for years. Arch has over 60 fewer processes running and less than half as many files in /etc than my old distro had. These things are helpful for me from a sys admin perspective. Thanks for the work done on Arch so far. -- Brian Wood Ebenezer Enterprises - in G-d we trust. http://webEbenezer.net (651) 251-9384

1 0

[arch-general] Linux-3.7.3-1-i686 blank screen
by Whiskers 19 Feb '13

19 Feb '13

I ran pacmatic -Syu last night, which updated the kernel to the version in the subject. This afternoon, the system started to boot normally but the display went blank before the login prompt appeared (I boot to a text login) so I was unable to use the system. I used my original installation disc to boot, and was able to follow the Wiki instructions (accessed using a different computer) to run chroot and downgrade the kernel to 3.6.11-1, and the system is now running again. An 'unconfirmed' bug is listed at <https://bugs.archlinux.org/> but this seems to relate to vlc segfaulting with the new kernel, so I don't know if that's the same problem affecting me. -- -- ^^^^^^^^^^ -- Whiskers -- ~~~~~~~~~~

6 12

[arch-general] Default directory for extra modules
by Sergi Pons Freixes 19 Feb '13

19 Feb '13

Hi All, I have the vanilla and the PAE kernels installed, and I use latter as my default for booting. I installed tp_smapi, and the modules are placed on /usr/lib/modules/extramodules-3.7-ARCH/ instead of /usr/lib/modules/extramodules-3.7-pae/, so they are not found. Is there anyway to set where the modules should be installed by default (which should be the current running kernel, resulting from uname). Or do I have to work with the PKGBUILD? Cheers, Sergi

2 1

Re: [arch-general] [arch-dev-public] [RFC] Add Wayland/Weston
by Armin K. 16 Feb '13

16 Feb '13

On 02/12/2013 05:51 PM, Tom Gundersen wrote: > On Tue, Feb 12, 2013 at 5:42 PM, Andreas Radke <andyrtr(a)archlinux.org> wrote: >> Am Sat, 9 Feb 2013 17:35:27 +0100 >> schrieb Andreas Radke <andyrtr(a)archlinux.org>: >> >>> Since cairo will also depend on that libegl then every system will >>> pull in Wayland. Is this really needed? If we can't build it in a >>> different way we directly need to move Wayland to extra. >>> >>> -Andy >> >> Bump. >> >> If we agree that we want to start to support Wayland in Arch we need to >> move Wayland libs to the extra repo. Then I can build Mesa making use >> of it in libegl. This shouldn't harm anything else and wayland libs are >> a pretty small pkg (when we drop the static libs). >> >> So who's going to move it to extra and wants to maintain it there? I >> could build it but will not use it myself anytime soon. > > I'll be happy to maintain Wayland, so I'll take it over and move it to [extra]. > > -t > Hello, and thank you for adding Wayland into Extra. There is now another smaller problem. In order to make use of Wayland with GTK+3, libxkbcommon should be moved into extra first. Can anyone do that? Lot of GTK+3 apps can be ran in Weston using GDK_BACKEND=wayland.

7 8

Re: [arch-general] [arch-dev-public] mesa packaging, libGL handling
by Armin K. 15 Feb '13

15 Feb '13

On 02/15/2013 08:27 PM, Jan Steffens wrote: > On Fri, Feb 15, 2013 at 8:16 PM, Sven-Hendrik Haase <sh(a)lutzhaase.com> wrote: >> Can't you build them with shared llvm libs? > > Nope, we don't have any. > > Building LLVM with cmake instead of autotools creates them, but that > approach has other problems. > Actualy, you can. Archlinux uses llvm-amdgpu-snapshot which is Tom Stellard's snapshot. In 9.1-devel, --with-llvm-shared-libs is turned on by default if you use --enable-opencl. On the other side, LLVM contains a shared library, enabled by --enable-shared, called libLLVM-<version>.so (ie libLLVM-3.2.so) located in llvm libdir (/usr/lib/llvm in Archlinux) which contains ALL of static libraries linked into ONE SHARED library. On the other hand, you can use CMake and build all of static libraries as shared. The first mentioned works for me very well. I am not sure what's the condition of that in Mesa 9.0 world. But 9.1 should be out in no time, so it shouldn't matter. Note, this is not from Archlinux. I use custom built system with custom built packages $ ldd /usr/lib/dri/r600_dri.so linux-vdso.so.1 (0x00007fffd47ff000) libllvmradeon9.2.0.so => /usr/lib/libllvmradeon9.2.0.so (0x00007fd514ba8000) libffi.so.6 => /usr/lib/libffi.so.6 (0x00007fd5149a0000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007fd514777000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fd51455b000) libdl.so.2 => /lib/libdl.so.2 (0x00007fd514357000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007fd51414b000) libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0x00007fd513f41000) libLLVM-3.2.so => /usr/lib/llvm/libLLVM-3.2.so (0x00007fd51274d000) $ du -sh /usr/lib/dri/r600_dri.so 5.7M /usr/lib/dri/r600_dri.so $ du -sh /usr/lib/gallium-pipe/pipe_r600.so 2.4M /usr/lib/gallium-pipe/pipe_r600.so (no /usr/lib/gbm/pipe_whatever.so anymore, since pipes are shared by gbm and opencl) Compared to 20MB Archlinux ones.

1 0