[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 10 new packages in last 24 hours * 1 known bad package * 0 packages not accepting signoffs * 10 fully signed off packages * 43 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 (10 total) == * gzip-1.5-3 (i686) * gzip-1.5-3 (x86_64) * lirc-1:0.9.0-37 (i686) * nvidia-313.18-3 (i686) * nvidia-304xx-304.64-4 (i686) * vim-7.3.798-1 (i686) * lirc-1:0.9.0-37 (x86_64) * nvidia-313.18-3 (x86_64) * nvidia-304xx-304.64-4 (x86_64) * vim-7.3.798-1 (x86_64) == Incomplete signoffs for [core] (11 total) == * btrfs-progs-0.20rc1.1-1 (i686) 0/2 signoffs * gzip-1.5-3 (i686) 0/2 signoffs * linux-3.7.6-1 (i686) 1/2 signoffs * linux-lts-3.0.62-1 (i686) 1/2 signoffs * openssh-6.1p1-5 (i686) 1/2 signoffs * perl-5.16.2-3 (i686) 1/2 signoffs * syslinux-5.01-1 (i686) 1/2 signoffs * btrfs-progs-0.20rc1.1-1 (x86_64) 0/2 signoffs * gzip-1.5-3 (x86_64) 1/2 signoffs * linux-lts-3.0.62-1 (x86_64) 1/2 signoffs * perl-5.16.2-3 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (32 total) == * hwdetect-2013.02-1 (any) 0/2 signoffs * seabios-1.7.2-1 (any) 1/2 signoffs * cabal-install-1.16.0.2-2 (i686) 0/2 signoffs * ghc-7.6.2-1 (i686) 0/2 signoffs * haskell-http-4000.2.7-1 (i686) 0/2 signoffs * haskell-mtl-2.1.2-2 (i686) 0/2 signoffs * haskell-network-2.4.1.0-1 (i686) 0/2 signoffs * haskell-parsec-3.1.3-2 (i686) 0/2 signoffs * haskell-random-1.0.1.1-4 (i686) 0/2 signoffs * haskell-text-0.11.2.3-2 (i686) 0/2 signoffs * haskell-transformers-0.3.0.0-3 (i686) 0/2 signoffs * haskell-zlib-0.5.4.0-1 (i686) 0/2 signoffs * lirc-1:0.9.0-37 (i686) 0/2 signoffs * nvidia-313.18-3 (i686) 0/2 signoffs * nvidia-304xx-304.64-4 (i686) 0/2 signoffs * qemu-1.3.1-2 (i686) 0/2 signoffs * vim-7.3.798-1 (i686) 0/2 signoffs * cabal-install-1.16.0.2-2 (x86_64) 0/2 signoffs * ghc-7.6.2-1 (x86_64) 0/2 signoffs * haskell-http-4000.2.7-1 (x86_64) 0/2 signoffs * haskell-mtl-2.1.2-2 (x86_64) 0/2 signoffs * haskell-network-2.4.1.0-1 (x86_64) 0/2 signoffs * haskell-parsec-3.1.3-2 (x86_64) 0/2 signoffs * haskell-random-1.0.1.1-4 (x86_64) 0/2 signoffs * haskell-text-0.11.2.3-2 (x86_64) 0/2 signoffs * haskell-transformers-0.3.0.0-3 (x86_64) 0/2 signoffs * haskell-zlib-0.5.4.0-1 (x86_64) 0/2 signoffs * lirc-1:0.9.0-37 (x86_64) 0/2 signoffs * nvidia-313.18-3 (x86_64) 0/2 signoffs * nvidia-304xx-304.64-4 (x86_64) 0/2 signoffs * qemu-1.3.1-2 (x86_64) 1/2 signoffs * vim-7.3.798-1 (x86_64) 0/2 signoffs == Completed signoffs (10 total) == * e2fsprogs-1.42.7-1 (i686) * iproute2-3.7.0-1 (i686) * lvm2-2.02.98-3 (i686) * e2fsprogs-1.42.7-1 (x86_64) * iproute2-3.7.0-1 (x86_64) * linux-3.7.6-1 (x86_64) * lvm2-2.02.98-3 (x86_64) * openssh-6.1p1-5 (x86_64) * openvpn-2.3.0-1 (x86_64) * syslinux-5.01-1 (x86_64) == All packages in [testing] for more than 14 days (4 total) == * lvm2-2.02.98-3 (i686), since 2012-11-03 * lvm2-2.02.98-3 (x86_64), since 2012-11-03 * openvpn-2.3.0-1 (i686), since 2013-01-21 * openvpn-2.3.0-1 (x86_64), since 2013-01-21 == Top five in signoffs in last 24 hours == 1. arodseth - 18 signoffs 2. bisson - 8 signoffs 3. thomas - 2 signoffs
[arch-dev-public] KDE 4.10 enters [testing]
It's true: KDE 4.10 packages are now available in [testing]. See the upstream announcement[1] for more info about this major release. Another KDE module has moved to git: kdegames. As side effect the packages libkdegames and libkmahjongg replace kdegames-libkdegames and libkdegames- libkmahjongg respectively. Also there's a new game named picmi. The printer applet in kdeutils has been removed and replaced by print-manager, which also provides a KCM module. Finally, a new dictionary runner and a new set of qml wallpapers are shipped too. The kdeartwork-aurorae package has been removed from the KDE SC. This release introduce two soname bump: * libkipi.so.9 - libkipi.so.10 * libkdcraw.so.21 - libkdcraw.so.22 As side digikam and kipi-plugins need to be rebuild, but the current version in [extra] doesn't work with KDE 4.10. We'll switch to the first RC of digikam 3.0.x ASAP. Please report any packaging bug to our bug tracker. Upstream bugs go upstream. Note: someone could have some trouble when updating or installing a fresh KDE, if so try with `pacman -S testing/kde`. Have a nice Kupdate! [1] http://kde.org/announcements/4.10/ -- Andrea Arch Linux Developer
Re: [arch-dev-public] KDE 4.10 enters [testing]
On Wednesday 06 February 2013 11:30:25 you wrote: It's true: KDE 4.10 packages are now available in [testing]. See the upstream announcement[1] for more info about this major release. Another KDE module has moved to git: kdegames. As side effect the packages libkdegames and libkmahjongg replace kdegames-libkdegames and libkdegames- libkmahjongg respectively. Also there's a new game named picmi. The printer applet in kdeutils has been removed and replaced by print-manager, which also provides a KCM module. Finally, a new dictionary runner and a new set of qml wallpapers are shipped too. The kdeartwork-aurorae package has been removed from the KDE SC. This release introduce two soname bump: * libkipi.so.9 - libkipi.so.10 * libkdcraw.so.21 - libkdcraw.so.22 As side digikam and kipi-plugins need to be rebuild, but the current version in [extra] doesn't work with KDE 4.10. We'll switch to the first RC of digikam 3.0.x ASAP. Please report any packaging bug to our bug tracker. Upstream bugs go upstream. Note: someone could have some trouble when updating or installing a fresh KDE, if so try with `pacman -S testing/kde`. Have a nice Kupdate! [1] http://kde.org/announcements/4.10/ I forgot to say that kdelibs uses udisks2 now. -- Andrea Arch Linux Developer
[arch-dev-public] JAVA_HOME in systemd
Hi all, I should have posted this a long time ago as suggested by Andy. Basically I would like some advice from the systemd gurus on how to provide a common place to set JAVA_HOME in systemd service files. As you know all Java apps need JAVA_HOME to be set. But as systemd service files do not inherit the shell's environment, all Java service files will need to declare a Environment=JAVA_HOME=/lib/jvm/java-7-openjdk. Needless to say that this is hardcoding the path and if one wants to change it for another JVM, he/she will have to fix all service files. Hence I was thinking about a common EnvironmentFile to hold this value once and for all. I know these EnvironmentFile _should_ be avoided but I think we are in a case where it could be tolerated. All Java service file could then just refer to it throught EnvironmentFile=/the/path/to/this/file. Also it could be parsed by /etc/profile.d/jre.sh to set the shell's environment. So is there a simpler to do that in systemd? Or does this sound ok to you? Also if it sounds OK, is there a standard place to put systemd environment files like such? Thanks -- Guillaume
Re: [arch-dev-public] JAVA_HOME in systemd
Am 06.02.2013 11:50, schrieb Guillaume ALAUX: Hence I was thinking about a common EnvironmentFile to hold this value once and for all. I know these EnvironmentFile _should_ be avoided but I think we are in a case where it could be tolerated. All Java service file could then just refer to it throught EnvironmentFile=/the/path/to/this/file. This seems like the only way. Such a file would however make all java runtimes conflict, unless you find a very clever way around it. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
Regardless of the outcome of symlink vs. fix hardcoded values, could the vi package be dropped? If people wish to configure sudo before installing their preferred vi-compatible editor with pacman, EDITOR=nano visudo can be used. - Alexander
Re: [arch-dev-public] JAVA_HOME in systemd
[2013-02-06 11:59:22 +0100] Thomas Bächler: Am 06.02.2013 11:50, schrieb Guillaume ALAUX: Hence I was thinking about a common EnvironmentFile to hold this value once and for all. I know these EnvironmentFile _should_ be avoided but I think we are in a case where it could be tolerated. All Java service file could then just refer to it throught EnvironmentFile=/the/path/to/this/file. This seems like the only way. Such a file would however make all java runtimes conflict, unless you find a very clever way around it. You can always have each Java runtime provide a different file, and include all of them in each Java service file using EnvironmentFile=-/path/to/java/runtime/number/one EnvironmentFile=-/path/to/java/runtime/number/two etc. -- Gaetan pgp394krGQLs3.pgp Description: PGP signature
Re: [arch-dev-public] JAVA_HOME in systemd
On Wed, Feb 6, 2013 at 1:58 PM, Gaetan Bisson bis...@archlinux.org wrote: You can always have each Java runtime provide a different file, and include all of them in each Java service file using EnvironmentFile=-/path/to/java/runtime/number/one EnvironmentFile=-/path/to/java/runtime/number/two etc. You can also pass a wildcard expression, avoiding hardcoding several files, maybe like this: EnvironmentFile=-/etc/java-runtime.d/* EnvironmentFile=-/etc/java-runtime Needs testing, but could allow the user to set a default runtime via symlink. Alternatively, just EnvironmentFile=/etc/java-runtime and create this symlink at post_install of every java-runtime, if it doesn't exist already. To be tidy, post_remove then deletes the file if java-runtime.d doesn't exist anymore.
[arch-dev-public] JAVA_HOME in systemd
-- Forwarded message --
From: Leonidas Spyropoulos artafi...@gmail.com
Date: 6 February 2013 14:52
Subject: Re: [arch-dev-public] JAVA_HOME in systemd
To: guilla...@archlinux.org
On Wed, Feb 6, 2013 at 1:36 PM, Jan Steffens jan.steff...@gmail.com wrote:
On Wed, Feb 6, 2013 at 1:58 PM, Gaetan Bisson bis...@archlinux.org wrote:
You can always have each Java runtime provide a different file, and
include all of them in each Java service file using
EnvironmentFile=-/path/to/java/runtime/number/one
EnvironmentFile=-/path/to/java/runtime/number/two
etc.
You can also pass a wildcard expression, avoiding hardcoding several files,
maybe like this:
EnvironmentFile=-/etc/java-runtime.d/*
EnvironmentFile=-/etc/java-runtime
Needs testing, but could allow the user to set a default runtime via symlink.
Alternatively, just EnvironmentFile=/etc/java-runtime and create this symlink
at post_install of every java-runtime, if it doesn't exist already.
To be tidy, post_remove then deletes the file if java-runtime.d
doesn't exist anymore.
I can't send to mailing list as I am not a dev / TU.
Isn't it possible to detect the JDK on runtime? Getting it from the
java command? (or the javac command)
--
Caution: breathing may be hazardous to your health.
#include stdio.h
int main(){printf(%s,\x4c\x65\x6f\x6e\x69\x64\x61\x73);}
Re: [arch-dev-public] JAVA_HOME in systemd
On 6 February 2013 15:08, Guillaume ALAUX guilla...@archlinux.org wrote:
-- Forwarded message --
From: Leonidas Spyropoulos artafi...@gmail.com
Date: 6 February 2013 14:52
Subject: Re: [arch-dev-public] JAVA_HOME in systemd
To: guilla...@archlinux.org
On Wed, Feb 6, 2013 at 1:36 PM, Jan Steffens jan.steff...@gmail.com wrote:
On Wed, Feb 6, 2013 at 1:58 PM, Gaetan Bisson bis...@archlinux.org wrote:
You can always have each Java runtime provide a different file, and
include all of them in each Java service file using
EnvironmentFile=-/path/to/java/runtime/number/one
EnvironmentFile=-/path/to/java/runtime/number/two
etc.
You can also pass a wildcard expression, avoiding hardcoding several files,
maybe like this:
EnvironmentFile=-/etc/java-runtime.d/*
EnvironmentFile=-/etc/java-runtime
Needs testing, but could allow the user to set a default runtime via symlink.
Alternatively, just EnvironmentFile=/etc/java-runtime and create this symlink
at post_install of every java-runtime, if it doesn't exist already.
To be tidy, post_remove then deletes the file if java-runtime.d
doesn't exist anymore.
I can't send to mailing list as I am not a dev / TU.
Isn't it possible to detect the JDK on runtime? Getting it from the
java command? (or the javac command)
--
Caution: breathing may be hazardous to your health.
#include stdio.h
int main(){printf(%s,\x4c\x65\x6f\x6e\x69\x64\x61\x73);}
The point is to enable the user to statically set which JRE must be
used. Detecting it at each java app runtime would not be ideal.
And I'd also rather not have to list all potential JRE in all java
systemd files.
Creating a symlink at post_install if it does not already exist looks
nice to me.
Re: [arch-dev-public] JAVA_HOME in systemd
On Feb 6, 2013 3:09 PM, Guillaume ALAUX guilla...@archlinux.org wrote:
On 6 February 2013 15:08, Guillaume ALAUX guilla...@archlinux.org wrote:
-- Forwarded message --
From: Leonidas Spyropoulos artafi...@gmail.com
Date: 6 February 2013 14:52
Subject: Re: [arch-dev-public] JAVA_HOME in systemd
To: guilla...@archlinux.org
On Wed, Feb 6, 2013 at 1:36 PM, Jan Steffens jan.steff...@gmail.com
wrote:
On Wed, Feb 6, 2013 at 1:58 PM, Gaetan Bisson bis...@archlinux.org
wrote:
You can always have each Java runtime provide a different file, and
include all of them in each Java service file using
EnvironmentFile=-/path/to/java/runtime/number/one
EnvironmentFile=-/path/to/java/runtime/number/two
etc.
You can also pass a wildcard expression, avoiding hardcoding several
files,
maybe like this:
EnvironmentFile=-/etc/java-runtime.d/*
EnvironmentFile=-/etc/java-runtime
Needs testing, but could allow the user to set a default runtime via
symlink.
Alternatively, just EnvironmentFile=/etc/java-runtime and create this
symlink
at post_install of every java-runtime, if it doesn't exist already.
To be tidy, post_remove then deletes the file if java-runtime.d
doesn't exist anymore.
I can't send to mailing list as I am not a dev / TU.
Isn't it possible to detect the JDK on runtime? Getting it from the
java command? (or the javac command)
--
Caution: breathing may be hazardous to your health.
#include stdio.h
int main(){printf(%s,\x4c\x65\x6f\x6e\x69\x64\x61\x73);}
The point is to enable the user to statically set which JRE must be
used. Detecting it at each java app runtime would not be ideal.
And I'd also rather not have to list all potential JRE in all java
systemd files.
Creating a symlink at post_install if it does not already exist looks
nice to me.
The symlink seems reasonable to me. It would be nice if all the
distros/upstreams could agree on a scheme though as this does not sound
Arch/systemd specific.
Cheers,
Tom
