- Arch-dev-public - lists.archlinux.org

[arch-dev-public] fortran modules and gfortran version
by Stéphane Gaudreault 02 Apr '13

02 Apr '13

I am sending here because this could require intervention for some packages and also to discuss a solution to prevent the problem in the future. Sometimes with newer versions of GCC there is a change in the version for Fortran modules which is incompatible with older versions. All packages providings Fortran modules (usually .mod files) must be rebuilt when the module version is bumped. A possible solution to identify those packages could be to provide a Fortran module ABI number in our gfortran PKGBUILD and force packages with .mod files to explicitly depend on it. Any thoughts on this? Cheers, Stéphane --- Example with gfortran 4.8.0 and the openmpi package build with a previous version : # cat test_mpi_fmodule.f90 program test USE mpi end program test # mpif90 test_mpi_fmodule.f90 test_mpi_fmodule.f90:2.4: USE mpi 1 Fatal Error: Cannot read module file 'mpi.mod' opened at (1), because it was created by a different version of GNU Fortran

1 0

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 02 Apr '13

02 Apr '13

=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 2 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 9 fully signed off packages * 21 packages missing signoffs * 4 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (2 total) == * pyalpm-0.6-1 (i686) * pyalpm-0.6-1 (x86_64) == Incomplete signoffs for [core] (1 total) == * linux-3.8.5-1 (i686) 1/2 signoffs == Incomplete signoffs for [extra] (15 total) == * archboot-2013.03-5 (any) 0/2 signoffs * cifs-utils-6.0-1 (i686) 0/2 signoffs * lirc-1:0.9.0-40 (i686) 0/2 signoffs * lm_sensors-3.3.3-2 (i686) 0/2 signoffs * nvidia-313.26-3 (i686) 0/2 signoffs * nvidia-304xx-304.84-2 (i686) 0/2 signoffs * pyalpm-0.6-1 (i686) 0/2 signoffs * samba-4.0.4-1 (i686) 0/2 signoffs * cifs-utils-6.0-1 (x86_64) 0/2 signoffs * lirc-1:0.9.0-40 (x86_64) 0/2 signoffs * lm_sensors-3.3.3-2 (x86_64) 1/2 signoffs * nvidia-313.26-3 (x86_64) 0/2 signoffs * nvidia-304xx-304.84-2 (x86_64) 0/2 signoffs * pyalpm-0.6-1 (x86_64) 0/2 signoffs * samba-4.0.4-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (5 total) == * netctl-0.8-1 (any) 0/2 signoffs * ldb-1.1.15-1 (i686) 0/2 signoffs * tevent-0.9.18-1 (i686) 0/2 signoffs * ldb-1.1.15-1 (x86_64) 0/2 signoffs * tevent-0.9.18-1 (x86_64) 0/2 signoffs == Completed signoffs (9 total) == * pacman-4.1.0-1 (i686) * syslinux-5.01-2 (i686) * systemd-200-1 (i686) * wpa_actiond-1.4-1 (i686) * linux-3.8.5-1 (x86_64) * pacman-4.1.0-1 (x86_64) * syslinux-5.01-2 (x86_64) * systemd-200-1 (x86_64) * wpa_actiond-1.4-1 (x86_64) == All packages in [testing] for more than 14 days (4 total) == * syslinux-5.01-2 (x86_64), since 2013-02-25 * syslinux-5.01-2 (i686), since 2013-02-25 * wpa_actiond-1.4-1 (i686), since 2013-02-27 * wpa_actiond-1.4-1 (x86_64), since 2013-02-27 == Top five in signoffs in last 24 hours == 1. foutrelis - 2 signoffs 2. allan - 2 signoffs 3. bisson - 1 signoffs

1 0

[arch-dev-public] [RFC] default sysctl settings
by Tom Gundersen 01 Apr '13

01 Apr '13

Hi guys, As you may have noticed systemd ships a default sysctl config file as of v199 (/usr/lib/sysctl.d/50-default.conf). Rather than also ship an Arch-specific one (/etc/sysctl.conf), should we try to unify the two? I had a look a the differences: 1) kernel.sysrq: We set it to 'off', systemd enables the sync command (which should be safe). 2) net.ipv4.ip_forward We disable this, which is already the default in the kernel. 3) net.ipv4.tcp_syncookies We enable this. Are we sure this is the right thing to do by default? There appears to be lots of warnings about it. 4) net.ipv6.conf.all.forwarding We disable this. It appears to be disabled by default, or am I reading it wrong? In addition to these, systemd sets the following: kernel.core_uses_pid = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 fs.protected_hardlinks = 1 fs.protected_symlinks = 1 Are we happy with that? Cheers, Tom

3 3

[arch-dev-public] Proposal to change the nvidia-utils package to allow for better bumblebee integration
by Sven-Hendrik Haase 01 Apr '13

01 Apr '13

I propose a change to the nvidia-utils that is as follows: 1. Move all libs to /usr/lib/nvidia 2. Create nvidia-utils-helper package that only adds a /etc/ld.so.conf.d/nvidia file containing "/usr/lib/nvidia" 3. make nvidia-utils depend on nvidia-utils-helper Reasoning: A while back, I asked aur-general what they thought about putting bumblebee into [community] [0]. The responses were few but positive. So now I want to actually get this working. The suggested changes will enable me to integrate bumblebee without having to create a nvidia-utils-bumblebee package which would essentially duplicate all the data that is in the nvidia-utils package to begin with I'd like to keep it simple and not create nvidia-utils-bumblebee and lib32-nvidia-utils-bumblebee. Instead we can do with just a simple helper package. At the same time, we could delete a bunch of nvidia-utils packages on AUR. A new package "bumblebee" that I'd add would conflict/provide nvidia-utils-helper but wouldn't contain the ld.so.conf.d file. This would mean that the nvidia libs wouldn't get used by default on an optimus system but instead would need to be explicitly loaded (as is wanted). The transition should be seamless for all other users on non-nvidia systems. I know there was a proposal by an nvidia employee a while back to make changes to the nvidia upstream driver package as well as mesa that would enable inherent coexistence of mesa-libgl and nvidia-utils but I asked that employee and he said there had been no progress on that proposal. So here we stand. [0] https://mailman.archlinux.org/pipermail/aur-general/2013-March/022295.html

6 9

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 01 Apr '13

01 Apr '13

=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 2 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 17 fully signed off packages * 21 packages missing signoffs * 4 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (2 total) == * pacman-4.1.0-1 (i686) * pacman-4.1.0-1 (x86_64) == Incomplete signoffs for [core] (3 total) == * linux-3.8.5-1 (i686) 1/2 signoffs * pacman-4.1.0-1 (i686) 0/2 signoffs * pacman-4.1.0-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [extra] (13 total) == * archboot-2013.03-5 (any) 0/2 signoffs * cifs-utils-6.0-1 (i686) 0/2 signoffs * lirc-1:0.9.0-40 (i686) 0/2 signoffs * lm_sensors-3.3.3-2 (i686) 0/2 signoffs * nvidia-313.26-3 (i686) 0/2 signoffs * nvidia-304xx-304.84-2 (i686) 0/2 signoffs * samba-4.0.4-1 (i686) 0/2 signoffs * cifs-utils-6.0-1 (x86_64) 0/2 signoffs * lirc-1:0.9.0-40 (x86_64) 0/2 signoffs * lm_sensors-3.3.3-2 (x86_64) 1/2 signoffs * nvidia-313.26-3 (x86_64) 0/2 signoffs * nvidia-304xx-304.84-2 (x86_64) 0/2 signoffs * samba-4.0.4-1 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (5 total) == * netctl-0.8-1 (any) 0/2 signoffs * ldb-1.1.15-1 (i686) 0/2 signoffs * tevent-0.9.18-1 (i686) 0/2 signoffs * ldb-1.1.15-1 (x86_64) 0/2 signoffs * tevent-0.9.18-1 (x86_64) 0/2 signoffs == Completed signoffs (17 total) == * binutils-2.23.2-1 (i686) * gcc-4.8.0-1 (i686) * glibc-2.17-4 (i686) * libtool-2.4.2-8 (i686) * linux-api-headers-3.8.4-1 (i686) * syslinux-5.01-2 (i686) * systemd-200-1 (i686) * wpa_actiond-1.4-1 (i686) * binutils-2.23.2-1 (x86_64) * gcc-4.8.0-1 (x86_64) * glibc-2.17-4 (x86_64) * libtool-2.4.2-8 (x86_64) * linux-3.8.5-1 (x86_64) * linux-api-headers-3.8.4-1 (x86_64) * syslinux-5.01-2 (x86_64) * systemd-200-1 (x86_64) * wpa_actiond-1.4-1 (x86_64) == All packages in [testing] for more than 14 days (4 total) == * syslinux-5.01-2 (x86_64), since 2013-02-25 * syslinux-5.01-2 (i686), since 2013-02-25 * wpa_actiond-1.4-1 (i686), since 2013-02-27 * wpa_actiond-1.4-1 (x86_64), since 2013-02-27 == Top five in signoffs in last 24 hours == 1. bisson - 6 signoffs 2. dreisner - 2 signoffs

1 0

[arch-dev-public] Default DEBUG_CFLAGS/CXXFLAGS provided with pacman 4.1
by Jan Alexander Steffens 31 Mar '13

31 Mar '13

With pacman 4.1 just around the corner, we'll be getting support for split debug information soon. I would like to recommend "-gdwarf-4 -fvar-tracking-assignments" as our default debug flags in makepkg.conf. These flags should allow for better debug information in the presence of optimization (less <value optimized out>; see man gcc). Thoughts?

6 8

[arch-dev-public] rc.d init files package
by Ionut Biru 31 Mar '13

31 Mar '13

Hello, We (the place where I work) have some customers that run arch as their primary os and I would like to create a package that contains rc.d init files that were dropped until now. I know this idea was discussed in the past and a lot of our users liked the idea but until now nobody stepped up. Let me know what you guys want me to support and i'll add it into my package. -- Ionuț

6 5

[arch-dev-public] BIND10? No, thanks.
by Gaetan Bisson 31 Mar '13

31 Mar '13

Hi guys, Currently we use the BIND code base in two packages: - dnsutils from [core] provides basic DNS query tools; - bind from [extra] is the actual name server. With the new BIND10 release, the ISC really outdid themselves: all formerly standalone tools have been merged and rewritten as a python script which uses bindings to the new libb10-* series of libraries that are shared with the name server. Python being such a boring dependency, they introduced another three: botan, log4cplus, and boost! That mostly means two things: - We cannot keep splitting dnsutils and bind anymore. - I do not want to maintain these packages any further. We already have ldns in [core], a much better written (and sane) DNS library which includes query tools that are near drop-in replacements for BIND's: use `drill` instead of `dig`, etc. So I suggest: - Any package relying on dnsutils and its tools (dig, host, nslookup) be ported to use ldns instead - should be straightforward in most cases. - We ditch dnsutils and bind out of our repos, unless somebody finds them fun and wants to maintain them in [extra] or [community]. Comments or suggestions are welcome. Cheers. -- Gaetan

11 31

[arch-dev-public] Signoff report for [testing]
by Arch Website Notification 31 Mar '13

31 Mar '13

=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 6 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 16 fully signed off packages * 52 packages missing signoffs * 4 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (6 total) == * lirc-1:0.9.0-40 (i686) * nvidia-313.26-3 (i686) * nvidia-304xx-304.84-2 (i686) * lirc-1:0.9.0-40 (x86_64) * nvidia-313.26-3 (x86_64) * nvidia-304xx-304.84-2 (x86_64) == Incomplete signoffs for [core] (2 total) == * linux-3.8.5-1 (i686) 1/2 signoffs * systemd-200-1 (i686) 1/2 signoffs == Incomplete signoffs for [extra] (45 total) == * archboot-2013.03-5 (any) 0/2 signoffs * akonadi-1.9.1-3 (i686) 0/2 signoffs * avogadro-1.1.0-4 (i686) 0/2 signoffs * boost-1.53.0-2 (i686) 0/2 signoffs * cifs-utils-6.0-1 (i686) 0/2 signoffs * ekiga-4.0.1-2 (i686) 0/2 signoffs * enblend-enfuse-4.0-10 (i686) 0/2 signoffs * hugin-2012.0.0-4 (i686) 0/2 signoffs * kdeedu-kig-4.10.1-2 (i686) 0/2 signoffs * libkolabxml-0.8.3-2 (i686) 0/2 signoffs * libpst-0.6.54-4 (i686) 0/2 signoffs * libtorrent-rasterbar-1:0.16.9-2 (i686) 0/2 signoffs * licq-1.7.1-3 (i686) 0/2 signoffs * lirc-1:0.9.0-40 (i686) 0/2 signoffs * lm_sensors-3.3.3-2 (i686) 0/2 signoffs * lyx-2.0.5.1-3 (i686) 0/2 signoffs * mkvtoolnix-6.1.0-2 (i686) 0/2 signoffs * nvidia-313.26-3 (i686) 0/2 signoffs * nvidia-304xx-304.84-2 (i686) 0/2 signoffs * samba-4.0.4-1 (i686) 0/2 signoffs * source-highlight-3.1.7-5 (i686) 0/2 signoffs * vigra-1.9.0-2 (i686) 0/2 signoffs * xsd-3.3.0-8 (i686) 0/2 signoffs * akonadi-1.9.1-3 (x86_64) 0/2 signoffs * avogadro-1.1.0-4 (x86_64) 0/2 signoffs * boost-1.53.0-2 (x86_64) 0/2 signoffs * cifs-utils-6.0-1 (x86_64) 0/2 signoffs * ekiga-4.0.1-2 (x86_64) 0/2 signoffs * enblend-enfuse-4.0-10 (x86_64) 0/2 signoffs * hugin-2012.0.0-4 (x86_64) 0/2 signoffs * kdeedu-kig-4.10.1-2 (x86_64) 0/2 signoffs * libkolabxml-0.8.3-2 (x86_64) 0/2 signoffs * libpst-0.6.54-4 (x86_64) 0/2 signoffs * libtorrent-rasterbar-1:0.16.9-2 (x86_64) 0/2 signoffs * licq-1.7.1-3 (x86_64) 0/2 signoffs * lirc-1:0.9.0-40 (x86_64) 0/2 signoffs * lm_sensors-3.3.3-2 (x86_64) 1/2 signoffs * lyx-2.0.5.1-3 (x86_64) 0/2 signoffs * mkvtoolnix-6.1.0-2 (x86_64) 0/2 signoffs * nvidia-313.26-3 (x86_64) 0/2 signoffs * nvidia-304xx-304.84-2 (x86_64) 0/2 signoffs * samba-4.0.4-1 (x86_64) 0/2 signoffs * source-highlight-3.1.7-5 (x86_64) 0/2 signoffs * vigra-1.9.0-2 (x86_64) 0/2 signoffs * xsd-3.3.0-8 (x86_64) 0/2 signoffs == Incomplete signoffs for [unknown] (5 total) == * netctl-0.8-1 (any) 0/2 signoffs * ldb-1.1.15-1 (i686) 0/2 signoffs * tevent-0.9.18-1 (i686) 0/2 signoffs * ldb-1.1.15-1 (x86_64) 0/2 signoffs * tevent-0.9.18-1 (x86_64) 0/2 signoffs == Completed signoffs (16 total) == * binutils-2.23.2-1 (i686) * gcc-4.8.0-1 (i686) * glibc-2.17-4 (i686) * libtool-2.4.2-8 (i686) * linux-api-headers-3.8.4-1 (i686) * syslinux-5.01-2 (i686) * wpa_actiond-1.4-1 (i686) * binutils-2.23.2-1 (x86_64) * gcc-4.8.0-1 (x86_64) * glibc-2.17-4 (x86_64) * libtool-2.4.2-8 (x86_64) * linux-3.8.5-1 (x86_64) * linux-api-headers-3.8.4-1 (x86_64) * syslinux-5.01-2 (x86_64) * systemd-200-1 (x86_64) * wpa_actiond-1.4-1 (x86_64) == All packages in [testing] for more than 14 days (4 total) == * syslinux-5.01-2 (x86_64), since 2013-02-25 * syslinux-5.01-2 (i686), since 2013-02-25 * wpa_actiond-1.4-1 (i686), since 2013-02-27 * wpa_actiond-1.4-1 (x86_64), since 2013-02-27 == Top five in signoffs in last 24 hours == 1. foutrelis - 15 signoffs 2. allan - 10 signoffs 3. bpiotrowski - 4 signoffs 4. andyrtr - 2 signoffs

1 0

[arch-dev-public] core build report - gcc-4.8 toolchain
by Allan McRae 31 Mar '13

31 Mar '13

Here are the current build failures in [core] when using the gcc-4.8 toolchain Old: FAIL: curl FAIL: isdn4k-utils FAIL: libtirpc FAIL: net-tools FAIL: ppl New: FAIL: iproute2 lnstat.c: In function 'build_hdr_string': lnstat.c:169:30: error: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess] memset(th.hdr[i], 0, sizeof(th.hdr[i])); ^ cc1: all warnings being treated as errors FAIL: libcap library gets installed to /usr/lib64 - ??? FAIL: lilo gcc -E -C -traditional -DLILO_ASM -o common.s common.h as86 -0 -a -w -l first.lis -o first.o first.s a0006 00000000> This file is part of the GNU C Library. ***** opcode expected...................................^ ***** illegal label.....................................^ ...

1 1