Re: [arch-dev-public] Long out of date packages

[Guillaume Alaux]

On Thu, Oct 20, 2016 at 3:46 PM, Sven-Hendrik Haase  wrote:
> openvdb is updated as part of the boost rebuild.
>
> On Thu, Oct 20, 2016 at 3:03 PM, Allan McRae  wrote:
>> On 20/10/16 22:25, Florian Pritz via arch-dev-public wrote:
>>>
>>> allan:
>>> extra/x86_64/fakechroot
>>
>> Updating this breaks the pacman testsuite (due to a fakechroot bug...).

I will take care of `openjfx` (hopefully soon) so please do not remove it.

[arch-dev-public] Orphaning community packages terminator and keybinder2

[Guillaume Alaux]

Hi there,

I wanted to let you know that I am orphaning community package
terminator along with its dependencies libkeybinder2 and
python2-keybinder2.

I haven't used these in years now. If anyone is interested in maintaining them…

Guillaume

Re: [arch-dev-public] Rethinking our CA certificate setup

[Guillaume Alaux]

On 26 August 2014 21:15, Jan Alexander Steffens jan.steff...@gmail.com wrote:
 On Sun, Aug 24, 2014 at 11:47 AM, Jan Alexander Steffens
 jan.steff...@gmail.com wrote:
 Hi guys,

 I'm currently at FrOSCon with Pierre and an expert from CAcert.org and
 we're thinking of changes to our certificate setup.


 The current issues are:
 - Mozilla NSS uses its own root store and not /etc/ssl/certs
 - ca-certificates ships outdated Mozilla roots
 - Shipping additional roots outside ca-certificates is difficult,
 requiring patching /etc/ca-certificates.conf


 To solve these issues, we thought of making the following changes:

 - Attach NSS to p11-kit so it uses our root store (easily done by
 replacing /usr/lib/libnssckbi.so with a symlink to p11-kit-proxy.so)
 - Patch the update-ca-certificates script to read
 /etc/ca-certificates/conf.d instead of /etc/ca-certificates.conf
 - Split the current Mozilla roots from the NSS package in the
 ca-certificates format, shipping
 /etc/ca-certificates/conf.d/mozilla.conf
 - Create a package shipping the CAcert.org roots in a similar way
 - Ship the update-ca-certificates script in a ca-certificates-utils
 package, which the certificate packages depend on
 - ca-certificates becomes a metapackage depending on the -mozilla and
 -cacert packages

 Comments are welcome. Unless we get objections, we're going to start
 making these changes. Hopefully we can be done today and push the
 result to [testing].

 Greetings,
 Jan

 Firefox isn't quite happy yet with the change, see
 https://bugs.archlinux.org/task/41689: Addons fail to install or
 update.

 It seems this is due to Firefox depending on NSS internals -
 specifically, addons must be signed by certificates validated by the
 built-in trusted root store, which is matched by name.

 Fedora was affected as well: 
 https://bugzilla.redhat.com/show_bug.cgi?id=966424
 Upstream report, arguing for the check to be removed:
 https://bugzilla.mozilla.org/show_bug.cgi?id=880269

 Now we can:
 a. Patch p11-kit to rename the store; the easy way.
 b. Patch Firefox and Thunderbird and SeaMonkey to not require the name
 to match; the hard way, and the one Fedora chose.
 c. Revert the change that links NSS to p11-kit; rather not, as it
 makes it really hard to control the root store.

 Opinions?


Hi Pierre, hi Jan,

So the ca-certificates-utils from testing (20140923-5) declares a
provides and conflict on ca-certificates-java. Unfortunately jre
and jdk packages use a init-jks-keystore script provided by
ca-certificates-java but not ca-certificates-utils. This scripts
only computes file /etc/ssl/certs/java/cacerts which is actually also
computed by update-ca-trust.

So I could just make jre and jdk packages depend on
ca-certificates-utils and then ca-certificates-java could be
dropped: is that the whole plan?

Re: [arch-dev-public] Rethinking our CA certificate setup

[Guillaume ALAUX]

On 16 November 2014 16:13, Jan Alexander Steffens
jan.steff...@gmail.com wrote:
 On Sun, Nov 16, 2014 at 3:54 PM, Guillaume Alaux guilla...@alaux.net wrote:
 So the ca-certificates-utils from testing (20140923-5) declares a
 provides and conflict on ca-certificates-java. Unfortunately jre
 and jdk packages use a init-jks-keystore script provided by
 ca-certificates-java but not ca-certificates-utils. This scripts
 only computes file /etc/ssl/certs/java/cacerts which is actually also
 computed by update-ca-trust.

 So I could just make jre and jdk packages depend on
 ca-certificates-utils and then ca-certificates-java could be
 dropped: is that the whole plan?

 Yes. Since p11-kit can construct the Java cert store and
 update-ca-trust always does so, ca-certificates-java becomes obsolete.

Excellent. I am going to rebuild OpenJDK7 and 8 and will push them to
testing then.

[arch-dev-public] OpenJDK 8 packages from testing pulled back

[Guillaume ALAUX]

OpenJDK 8 packages with bad version numbers (8.u20.b23) were pushed to
[testing]. New packages are now available (8.u11). Unfortunatly as new
package version is lower than the faulty one, pacman should yield the
following when updating:

 warning: jdk8-openjdk: local (8.u20.b23-1) is newer than testing (8.u11-1)
 warning: jre8-openjdk: local (8.u20.b23-1) is newer than testing (8.u11-1)
 warning: jre8-openjdk-headless: local (8.u20.b23-1) is newer than
testing (8.u11-1)

To sort this out, please manually install all 3 packages:

 # pacman -S jre8-openjdk jre8-openjdk-headless jdk8-openjdk
 warning: downgrading package jre8-openjdk (8.u20.b23-1 = 8.u11-1)
 warning: downgrading package jre8-openjdk-headless (8.u20.b23-1 = 8.u11-1)
 warning: downgrading package jdk8-openjdk (8.u20.b23-1 = 8.u11-1)
 resolving dependencies...
 looking for inter-conflicts...

 Packages (3): jdk8-openjdk-8.u11-1  jre8-openjdk-8.u11-1
jre8-openjdk-headless-8.u11-1

 Total Download Size:33.34 MiB
 Total Installed Size:   131.77 MiB
 Net Upgrade Size:   -0.30 MiB

 :: Proceed with installation? [Y/n] y
 […]

Guillaume

Re: [arch-dev-public] OpenJDK 8 packages from testing pulled back

[Guillaume Alaux]

On 16 August 2014 17:12, Andrea Scarpino and...@archlinux.org wrote:
 On Aug 16, 2014 2:32 PM, Guillaume ALAUX guilla...@archlinux.org wrote:

 OpenJDK 8 packages with bad version numbers (8.u20.b23) were pushed to
 [testing]. New packages are now available (8.u11).

 Thank you Guillaume, great work! What about the doc package?

Yes, forgot about the source package, so one should:

 # pacman -S jre8-openjdk jre8-openjdk-headless jdk8-openjdk openjdk8-src

@Andrea: I'm working on adding the -doc package.

Re: [arch-dev-public] Fwd: [arch-general] Java 8

[Guillaume Alaux]

On 22 April 2014 20:58, Guillaume Alaux guilla...@alaux.net wrote:
 On 6 April 2014 23:10, Guillaume Alaux guilla...@alaux.net wrote:
 On 31 March 2014 13:38, Guillaume Alaux guilla...@alaux.net wrote:

 On 30 March 2014 20:46, Guillaume Alaux guilla...@alaux.net wrote:
  On 30 March 2014 20:39, Andrea Scarpino and...@archlinux.org wrote:
  On Sun 30, March 20:03:51 Guillaume Alaux wrote:
  You might be talking about icedtea-web [0], the browser plugin that
  enables some Java interpretation inside browsers? This is yet another
  project provided by the IcedTea team.
 
  Indeed. Thank you for the clarification.
 
  Could you provide an openjdk8 package without IcedTea? Isn't necessary 
  to put
  that in the repos, just to test what would be missing/broken.
 
  Cheers
 
  --
  Andrea
  Arch Linux Developer
 
  Sure! I will need to finish it first of course and will let you know.
  Should not be long. I do not expect much breakerage if any.
 
  Also I asked on the IcedTea ML to get an idea of when they think this
  release could happen.

 Ok so answer from IcedTeam team [0] is they should relase Hopefully
 in the next month. It depends how involved the security errata is next
 month.

 I am thus going to keep on working on a package *without IceTea* in
 case we want to test/release it and prepare one *with IcedTea* ready
 when this release is out.

 [0] 
 http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-March/026974.html

 --
 Guillaume

 So as previously announced, here is an early version of OpenJDK 8
 without IcedTea [0]. Sources of the package can be found here [1]. It
 is currently split into `jre8-openjdk` and `jdk8-openjdk` that
 currently declare a conflict with other JRE/JDK packages (I am working
 on an simple way to enable installation of multiple Java
 environments). Any tests feedback by those of you interested would be
 appreciated (I have just noticed I forgot man pages for JRE binaries
 on this package - will be fixed).

 Thanks

 [0] https://dev.archlinux.org/~guillaume/openjdk8-noicedtea/
 [1] 
 https://github.com/galaux/aurpkgs/tree/444d7df9ad91842fd595f220becddfbaa8894c4b/java8-openjdk

 --
 Guillaume


 Split versions of JRE/JRE-headless/JDK for both architectures are
 available here [0] for testing. Sources available here [1].

 [0] https://dev.archlinux.org/~guillaume/openjdk8-noicedtea/
 [1] https://github.com/galaux/aurpkgs/tree/master/java8-openjdk

 --
 Guillaume


Hello,

For people interested, here are the last versions of the java
providing package I have been working on recently:

http://pkgbuild.com/~guillaume/repos/jdk/

Packages in this repo are:
  - OpenJDK Java 8 packages (without IcedTea)
  - OpenJDK Java 7 packages (with IcedTea)
  - Oracle Java 8 packages (from binary tarballs - written as a proof
of concept for other Java vendors)
  - meta package to enable installation of all the previous java packages

None of these packages conflict with any other. This is intended in
order to support multiple Java environment version as well as vendors.
They all rely on a link /usr/lib/jvm/java-default-runtime that can
point at any of these java home. One can either (un)set this link
manually or use a rather trivial script 'archlinux-java' provided by
'java-runtime-headless'.

As a reminder, one can use the provided – totally unsupported – repo
by adding the following on pacman.conf:

[galaux_jdk]
SigLevel = Optional TrustAll
Server = http://pkgbuild.com/~guillaume/repos/jdk/$arch

--
Guillaume

Re: [arch-dev-public] Fwd: [arch-general] Java 8

[Guillaume Alaux]

On 6 April 2014 23:10, Guillaume Alaux guilla...@alaux.net wrote:
 On 31 March 2014 13:38, Guillaume Alaux guilla...@alaux.net wrote:

 On 30 March 2014 20:46, Guillaume Alaux guilla...@alaux.net wrote:
  On 30 March 2014 20:39, Andrea Scarpino and...@archlinux.org wrote:
  On Sun 30, March 20:03:51 Guillaume Alaux wrote:
  You might be talking about icedtea-web [0], the browser plugin that
  enables some Java interpretation inside browsers? This is yet another
  project provided by the IcedTea team.
 
  Indeed. Thank you for the clarification.
 
  Could you provide an openjdk8 package without IcedTea? Isn't necessary to 
  put
  that in the repos, just to test what would be missing/broken.
 
  Cheers
 
  --
  Andrea
  Arch Linux Developer
 
  Sure! I will need to finish it first of course and will let you know.
  Should not be long. I do not expect much breakerage if any.
 
  Also I asked on the IcedTea ML to get an idea of when they think this
  release could happen.

 Ok so answer from IcedTeam team [0] is they should relase Hopefully
 in the next month. It depends how involved the security errata is next
 month.

 I am thus going to keep on working on a package *without IceTea* in
 case we want to test/release it and prepare one *with IcedTea* ready
 when this release is out.

 [0] 
 http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-March/026974.html

 --
 Guillaume

 So as previously announced, here is an early version of OpenJDK 8
 without IcedTea [0]. Sources of the package can be found here [1]. It
 is currently split into `jre8-openjdk` and `jdk8-openjdk` that
 currently declare a conflict with other JRE/JDK packages (I am working
 on an simple way to enable installation of multiple Java
 environments). Any tests feedback by those of you interested would be
 appreciated (I have just noticed I forgot man pages for JRE binaries
 on this package - will be fixed).

 Thanks

 [0] https://dev.archlinux.org/~guillaume/openjdk8-noicedtea/
 [1] 
 https://github.com/galaux/aurpkgs/tree/444d7df9ad91842fd595f220becddfbaa8894c4b/java8-openjdk

 --
 Guillaume


Split versions of JRE/JRE-headless/JDK for both architectures are
available here [0] for testing. Sources available here [1].

[0] https://dev.archlinux.org/~guillaume/openjdk8-noicedtea/
[1] https://github.com/galaux/aurpkgs/tree/master/java8-openjdk

--
Guillaume

Re: [arch-dev-public] clean up home folders brynhild

[Guillaume Alaux]

On 9 April 2014 22:22, Laurent Carlier lordhea...@gmail.com wrote:
 Le mercredi 9 avril 2014, 19:29:19 Ionuț Bîru a écrit :
 Hey guys,

 Just ordered our new build server. Since now we have 2x240G SSD(not a lot
 of storage space), I want to do raid1 and I want to rsync /home very fast

 :D.

 Please delete whatever you don' t need from /home. With this occasion, I'm
 going to delete all the inactive trusted and developers accounts.

 You can remove mychroots dir from my home dir.

 ++
 --
 Laurent Carlier
 ArchLinux Developer
 http://www.archlinux.org

Done. Too many old packages were sitting on my home dir anyway… :)

Re: [arch-dev-public] Fwd: [arch-general] Java 8

[Guillaume Alaux]

On 31 March 2014 13:38, Guillaume Alaux guilla...@alaux.net wrote:

 On 30 March 2014 20:46, Guillaume Alaux guilla...@alaux.net wrote:
  On 30 March 2014 20:39, Andrea Scarpino and...@archlinux.org wrote:
  On Sun 30, March 20:03:51 Guillaume Alaux wrote:
  You might be talking about icedtea-web [0], the browser plugin that
  enables some Java interpretation inside browsers? This is yet another
  project provided by the IcedTea team.
 
  Indeed. Thank you for the clarification.
 
  Could you provide an openjdk8 package without IcedTea? Isn't necessary to 
  put
  that in the repos, just to test what would be missing/broken.
 
  Cheers
 
  --
  Andrea
  Arch Linux Developer
 
  Sure! I will need to finish it first of course and will let you know.
  Should not be long. I do not expect much breakerage if any.
 
  Also I asked on the IcedTea ML to get an idea of when they think this
  release could happen.

 Ok so answer from IcedTeam team [0] is they should relase Hopefully
 in the next month. It depends how involved the security errata is next
 month.

 I am thus going to keep on working on a package *without IceTea* in
 case we want to test/release it and prepare one *with IcedTea* ready
 when this release is out.

 [0] 
 http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-March/026974.html

 --
 Guillaume

So as previously announced, here is an early version of OpenJDK 8
without IcedTea [0]. Sources of the package can be found here [1]. It
is currently split into `jre8-openjdk` and `jdk8-openjdk` that
currently declare a conflict with other JRE/JDK packages (I am working
on an simple way to enable installation of multiple Java
environments). Any tests feedback by those of you interested would be
appreciated (I have just noticed I forgot man pages for JRE binaries
on this package - will be fixed).

Thanks

[0] https://dev.archlinux.org/~guillaume/openjdk8-noicedtea/
[1] 
https://github.com/galaux/aurpkgs/tree/444d7df9ad91842fd595f220becddfbaa8894c4b/java8-openjdk

--
Guillaume

Re: [arch-dev-public] Fwd: [arch-general] Java 8

[Guillaume Alaux]

On 30 March 2014 20:46, Guillaume Alaux guilla...@alaux.net wrote:
 On 30 March 2014 20:39, Andrea Scarpino and...@archlinux.org wrote:
 On Sun 30, March 20:03:51 Guillaume Alaux wrote:
 You might be talking about icedtea-web [0], the browser plugin that
 enables some Java interpretation inside browsers? This is yet another
 project provided by the IcedTea team.

 Indeed. Thank you for the clarification.

 Could you provide an openjdk8 package without IcedTea? Isn't necessary to put
 that in the repos, just to test what would be missing/broken.

 Cheers

 --
 Andrea
 Arch Linux Developer

 Sure! I will need to finish it first of course and will let you know.
 Should not be long. I do not expect much breakerage if any.

 Also I asked on the IcedTea ML to get an idea of when they think this
 release could happen.

Ok so answer from IcedTeam team [0] is they should relase Hopefully
in the next month. It depends how involved the security errata is next
month.

I am thus going to keep on working on a package *without IceTea* in
case we want to test/release it and prepare one *with IcedTea* ready
when this release is out.

[0] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-March/026974.html

--
Guillaume

[arch-dev-public] Fwd: [arch-general] Java 8

[Guillaume ALAUX]

Hi devs,

A new major version of Java went out recently [0]: OpenJDK 8 but we
do not have a package for it (for the following reason) and some
Archers are asking questions [1] or flagging our openjdk7 package as
out of date:

All Linux distros - including Arch - build OpenJDK using the IcedTea
project [2]. Its goal is to cleanly build OpenJDK from Oracle, bring
some more feature and it **was** also to re-implement closed source
parts. I expected IcedTea to quickly release a version for OpenJDK8
but it seems this is not their first priority [3] (which I totally
understand). Nowadays there is no closed source part anymore in
OpenJDK, and the license is clearly GPL with classpath exception
which is a standard in the Java world.

I have been working on a package based on OpenJDK8 built from source
but without IcedTea that I think would fit to our repos. I still have
some work for it to be released but I would be in favor of pushing
this OpenJDK without IcedTea to extra until IcedTea v3.0 stable is
out and could be used to build/augment our package.

Any thought/objection/remark about?

[0] http://mail.openjdk.java.net/pipermail/announce/2014-March/000166.html
[1] https://mailman.archlinux.org/pipermail/arch-general/2014-March/035700.html
[2] http://icedtea.classpath.org
[3] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-March/026727.html

--
Guillaume


-- Forwarded message --
From: Guillaume ALAUX guilla...@archlinux.org
Date: 29 March 2014 01:02
Subject: Re: [arch-general] Java 8
To: General Discussion about Arch Linux arch-gene...@archlinux.org


On 28 March 2014 18:30, Caleb Cushing xenoterrac...@gmail.com wrote:

 I'm just wondering what the plan is, if any,  for getting java 8
 packages into arch?

 --
 Caleb Cushing

 http://xenoterracide.com

 Calendar:
 https://www.google.com/calendar/embed?src=xenoterracide%40gmail.comctz=America/Chicago

Hello,

There is no official Java 8 package in Arch Linux because the OpenJDK
we provide uses the IcedTea [0] but unfortunately IcedTea has no
stable version available **yet** for Java 8. More details about
IcedTea roadmap here [1]. So the plan (for me at least) is to wait for
IcedTea 3.0 that will support Java 8. Shipping a vanilla OpenJDK8
into extra (possibly from the binaries provided by Oracle) could be an
option in the meantime.

[0] http://icedtea.classpath.org/wiki/Main_Page
[1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-March/026727.html

--
Guillaume

Re: [arch-dev-public] Fwd: [arch-general] Java 8

[Guillaume Alaux]

On 30 March 2014 11:46, Andreas Radke andy...@archlinux.org wrote:

 Am Sun, 30 Mar 2014 11:21:25 +0200
 schrieb Guillaume ALAUX guilla...@archlinux.org:

  Hi devs,
 
  A new major version of Java went out recently [0]: OpenJDK 8 but we
  do not have a package for it (for the following reason) and some
  Archers are asking questions [1] or flagging our openjdk7 package as
  out of date:
 
  All Linux distros - including Arch - build OpenJDK using the IcedTea
  project [2]. Its goal is to cleanly build OpenJDK from Oracle, bring
  some more feature and it **was** also to re-implement closed source
  parts. I expected IcedTea to quickly release a version for OpenJDK8
  but it seems this is not their first priority [3] (which I totally
  understand). Nowadays there is no closed source part anymore in
  OpenJDK, and the license is clearly GPL with classpath exception
  which is a standard in the Java world.
 
  I have been working on a package based on OpenJDK8 built from source
  but without IcedTea that I think would fit to our repos. I still have
  some work for it to be released but I would be in favor of pushing
  this OpenJDK without IcedTea to extra until IcedTea v3.0 stable is
  out and could be used to build/augment our package.
 
  Any thought/objection/remark about?

 How about using icedtea master bzr shots to build openjdk8 until they
 publish a release?

 -Andy

I should have mentionned: I tried that. It turns out the last
pre-release of IcedTea points at source tarballs (hotspot, jaxp,
corba, ...) that are not available anymore. One solution there could be
to get in touch with IcedTea and ask them to put these tarballs back
or create a new pre-release. Or to create our own tarballs. This
should not be too long to get all this to build.

Re: [arch-dev-public] Fwd: [arch-general] Java 8

[Guillaume Alaux]

On 30 March 2014 14:23, Allan McRae al...@archlinux.org wrote:
 On 30/03/14 21:36, Guillaume Alaux wrote:
 On 30 March 2014 11:46, Andreas Radke andy...@archlinux.org wrote:

 Am Sun, 30 Mar 2014 11:21:25 +0200
 schrieb Guillaume ALAUX guilla...@archlinux.org:

 Hi devs,

 A new major version of Java went out recently [0]: OpenJDK 8 but we
 do not have a package for it (for the following reason) and some
 Archers are asking questions [1] or flagging our openjdk7 package as
 out of date:

 All Linux distros - including Arch - build OpenJDK using the IcedTea
 project [2]. Its goal is to cleanly build OpenJDK from Oracle, bring
 some more feature and it **was** also to re-implement closed source
 parts. I expected IcedTea to quickly release a version for OpenJDK8
 but it seems this is not their first priority [3] (which I totally
 understand). Nowadays there is no closed source part anymore in
 OpenJDK, and the license is clearly GPL with classpath exception
 which is a standard in the Java world.

 I have been working on a package based on OpenJDK8 built from source
 but without IcedTea that I think would fit to our repos. I still have
 some work for it to be released but I would be in favor of pushing
 this OpenJDK without IcedTea to extra until IcedTea v3.0 stable is
 out and could be used to build/augment our package.

 Any thought/objection/remark about?

 How about using icedtea master bzr shots to build openjdk8 until they
 publish a release?

 -Andy

 I should have mentionned: I tried that. It turns out the last
 pre-release of IcedTea points at source tarballs (hotspot, jaxp,
 corba, ...) that are not available anymore. One solution there could be
 to get in touch with IcedTea and ask them to put these tarballs back
 or create a new pre-release. Or to create our own tarballs. This
 should not be too long to get all this to build.


 You can just use the bzr source directly in the PKGBUILD, even providing
 a revision for consistent builds.

 Allan


Yes. Downside is: Each IcedTea minor version requires a set of source
tarballs of several components (jdk, corba, jaxp, ...) each at a precise
mercurial changeset. These are not available anymore. I could pull
each mercurial repo (5 repos AFAIK), create each tarball and make them
available on ftp.

So that would make a pre-release version of OpenJDK+IcedTea in our
repos. Would this be pushed to testing or extra? Are we in favor of
this compared to a General Availability vanilla OpenJDK?

Re: [arch-dev-public] Fwd: [arch-general] Java 8

[Guillaume Alaux]

On 30 March 2014 15:14, Pierre Schmitz pie...@archlinux.de wrote:
 Am 30.03.2014 11:21, schrieb Guillaume ALAUX:
 I have been working on a package based on OpenJDK8 built from source
 but without IcedTea that I think would fit to our repos. I still have
 some work for it to be released but I would be in favor of pushing
 this OpenJDK without IcedTea to extra until IcedTea v3.0 stable is
 out and could be used to build/augment our package.

 Any thought/objection/remark about?

 So this OpenJDK would then be identical to what Oracle offers as binary
 download? What do the IceTea patches provide then? If in doubt I would
 applayy our don'T patch policy and ship whatever we get from upstream.

 Greetings,

 Pierre

 --
 Pierre Schmitz, https://pierre-schmitz.com

The result would resemble the one provided by Oracle as binary download yes.

 What do the IceTea patches provide then?
They are fixes that the IcedTea team wishes upstream would accept and
cleanup of the build system (such as stop using shipped libraries and
use system ones). See the list of patches [0].

 If in doubt I would applayy our don'T patch policy and ship whatever we get 
 from upstream
**We** (Arch Linux) do not patch anything here. We are just wondering
which way to go between:
1- build from upstream OpenJDK by Oracle (the build process and result
are kind of dirty, it builds against included libraries that are
shipped afterwards - libpng, libjpeg, ...)
2- build from upstream OpenJDK by Oracle AND upstream IcedTea on a
pre-release version (are we OK with a pre-release on our repos? This
could go to testing?)
3- ship an already built by Oracle binary version (not in favor of
this one - this is what is in AUR as jdk and jre)
4- do not ship Java 8 at all and wait for IcedTea8 stable to come out (when?)

[0] http://icedtea.classpath.org/wiki/IcedTea_Patches_for_OpenJDK_8

Re: [arch-dev-public] Fwd: [arch-general] Java 8

[Guillaume Alaux]

On 30 March 2014 19:38, Andrea Scarpino and...@archlinux.org wrote:
 On Sun 30, March 16:14:17 Guillaume Alaux wrote:
 **We** (Arch Linux) do not patch anything here. We are just wondering
 which way to go between:
 1- build from upstream OpenJDK by Oracle (the build process and result
 are kind of dirty, it builds against included libraries that are
 shipped afterwards - libpng, libjpeg, ...)
 2- build from upstream OpenJDK by Oracle AND upstream IcedTea on a
 pre-release version (are we OK with a pre-release on our repos? This
 could go to testing?)
 3- ship an already built by Oracle binary version (not in favor of
 this one - this is what is in AUR as jdk and jre)
 4- do not ship Java 8 at all and wait for IcedTea8 stable to come out
 (when?)

 I'd say to go for 1), I don't use IcedTea at all and I guess very few people
 do these days. And maybe those could use jre from AUR until icedtea8 is out.

 --
 Andrea
 Arch Linux Developer

You might be talking about icedtea-web [0], the browser plugin that
enables some Java interpretation inside browsers? This is yet another
project provided by the IcedTea team.

[0] http://icedtea.classpath.org/wiki/IcedTea-Web

Re: [arch-dev-public] Fwd: [arch-general] Java 8

[Guillaume Alaux]

On 30 March 2014 20:39, Andrea Scarpino and...@archlinux.org wrote:
 On Sun 30, March 20:03:51 Guillaume Alaux wrote:
 You might be talking about icedtea-web [0], the browser plugin that
 enables some Java interpretation inside browsers? This is yet another
 project provided by the IcedTea team.

 Indeed. Thank you for the clarification.

 Could you provide an openjdk8 package without IcedTea? Isn't necessary to put
 that in the repos, just to test what would be missing/broken.

 Cheers

 --
 Andrea
 Arch Linux Developer

Sure! I will need to finish it first of course and will let you know.
Should not be long. I do not expect much breakerage if any.

Also I asked on the IcedTea ML to get an idea of when they think this
release could happen.

[arch-dev-public] Away for a week

[Guillaume Alaux]

Hi folks,

I will be in the Alps next week so I don't expect to have any good
connection nor time to do any packaging related stuff. As usual, feel free
to take care of any of my package. Thanks.

See you!

Guillaume

Re: [arch-dev-public] drift between repo packages and ABS

[Guillaume Alaux]

On 24 January 2014 18:36, Maxime Gauduin aluc...@gmail.com wrote:
 On Fri, Jan 24, 2014 at 5:45 PM, Dave Reisner d...@falconindy.com wrote:

 On Sat, Jan 25, 2014 at 12:42:24AM +0800, Felix Yan wrote:
   cgminer - makedepends
 
  I was using CARCH hacks to make i686 and x86_64 having different
 makedepends,
  maybe this was the cause.

 Yep, probably why it showed up on my list. Sorry for the noise.

  Anyway, turns out the only one additional makedepend (yasm) was not
 needed
  anymore since some versions ago, so removed that line. Now it should
 work :)

 Thanks!


 As for liblightdm-qt{4,5} pkgdescs, I had mistakenly made them arrays in
 the split package functions, now fixed.

 Cheers,
 --
 Maxime


 antlr2 - pkgdesc
Noted. I obviously forgot about this. Will take care of it. Thanks!

Re: [arch-dev-public] Orphaning Wireshark

[Guillaume Alaux]

On 18 October 2013 11:48, Timothy M. Redaelli
timothy.redae...@gmail.com wrote:

 On 10/18/2013 11:24 AM, Bartłomiej Piotrowski wrote:
 [cut]

  Nothing depends on wireshark, so it can safely go to community.
 
  Moved.

 Adopted, thanks

 --
 Timothy M. Redaelli
 Arch Linux Trusted User


Pleased to see someone wants to take care of it. Let me know if you
have questions about previous decisions made for this package.

Re: [arch-dev-public] Artwork Team?

[Guillaume Alaux]

On 6 October 2013 04:11, Gaetan Bisson bis...@archlinux.org wrote:
 [2013-10-06 11:46:49 +1000] Allan McRae:
 On 05/10/13 14:06, Gaetan Bisson wrote:
  I understand that we are supposed to be the upstream on this, but since
  no developer or trusted user has shown interest in maintaining these
  packages, why not let users do it? Things like desktop manager themes
  could be improved by the community. Ultimately if neither official Arch
  packagers or users care, those packages could just be plain removed...

 I have had an email pointed out that these artworks carry our TM and we
 may want to consider the consequences of not controlling them ourselves.

 We control the artworks, but do we also need to control the window
 manager themes that use them? And the packages that include them?

 Anyway, I'm fine with anyone but me adopting this. :)

 --
 Gaetan

I'd be in favor of keeping the WM agnostic (archlinux-artwork,
archlinux-wallpaper) ones in official repos for trademark reasons but
I'm confortable with the Slim and LXDM ones going to AUR.

Anyway: none of these 4 pakages seems to be an orphan anymore so that
could put an end to this discussion :)

Re: [arch-dev-public] rc.d files, unmaintained packages - and the quality of our repositories

[Guillaume Alaux]

On 16 July 2013 17:50, Ionut Biru ib...@archlinux.org wrote:
 On 07/16/2013 02:39 PM, Gaetan Bisson wrote:
 [2013-07-16 13:12:19 +0200] Thomas Bächler:
 However, now netcfg has been readded to community in the exact same
 state as the package that was originally removed:

 * It does not work properly with systemd.
 * There is no init system in our repositories that it works with.
 * It actually re-added rc.d files to our repositories, although we had a
 TODO list recently to explicitly remove those (and btw, they depend on
 files that no longer exist in our repositories, like /etc/rc.d/functions
 and /etc/rc.conf).

 I am really confused about the decision to re-add this and I am
 seriously considering if we should talk about stricter guidelines for
 adding packages and - in particular - the quality of our packages.

 I doubt guidelines would help. It should be pretty obvious to any
 responsible packager that re-adding a deprecated package violating
 recent TODO lists is a bad idea. If we really need to spell this out
 (with an exhaustive list of obvious things responsible developers should
 not do), then we have bigger problems.

 In this particular case, we should hear what Connor has to say and make
 sure (one way or another) that this type of problem will not happen
 again.


 Release the Kraken!

 http://www.youtube.com/watch?v=2OlCnPKr4Q8

 --
 Ionuț


FYI I have just built and pushed a rc.d free version of tomcat6 so you
can cross it out of the (Kraken) list.

--
Guillaume

[arch-dev-public] Orphaning Wireshark

[Guillaume ALAUX]

Hi everyone,

As the title says, I am going to orphan Wireshark. I do not use it on
a regular basis which makes it complicated for me to make decisions on
whether to implement this or that for this package. Plus it is far
away from my Java skills!

If anyone is interested, help yourself. If no one steps forward I
could also move it to community.

Have fun,

Guillaume

Re: [arch-dev-public] Packages still containing rc.d scripts

[Guillaume Alaux]

On 5 June 2013 13:34, Lukas Fleischer archli...@cryptocrack.de wrote:
 On Wed, Jun 05, 2013 at 01:06:59PM +0200, Lukas Fleischer wrote:
 On Wed, Jun 05, 2013 at 08:55:14PM +1000, Gaetan Bisson wrote:
  [2013-06-05 12:44:03 +0200] Andrea Scarpino:
   On Wednesday 05 June 2013 12:37:54 Lukas Fleischer wrote:
I saw an updated version of bluez in [testing] that no longer contains
these files. Can someone please have a look at ntp, tomcat6, x11vnc,
couchdb and wesnoth?
  
   I guess that those have been updated on trunk only.
 
  That's indeed what I did with my packages (including ntp and x11vnc);
  there is no hurry to push this to the repos that I can see...

 Well, it is a bit inconsistent to rebuild all but 5 packages in our
 repositories. Also, I just wanted to make sure that people double-check
 their packages. If all of these still contain rc.d scripts due to
 removing them on trunk only, I am fine with that (as long as none of the
 packages in question are only updated once every decade).

 Ok, looks like all of them are fine -- apart from couchdb.

 Sergej: Could you please check that the rc.d script is removed when
 upgrading to 1.3.0? Maybe you just forgot to rebuild 1.2.2-3 after
 adding the rc.d change to the PKGBUILD.


 
  --
  Gaetan

  extra/tomcat6
yes: already done in trunk. Will be shipped with next release that
should not be long now.

Re: [arch-dev-public] Proposal to change the nvidia-utils package to allow for better bumblebee integration

[Guillaume Alaux]

Tu as essayé Bumblebee?


On 13 March 2013 18:06, Sven-Hendrik Haase s...@lutzhaase.com wrote:

 On 13.03.2013 12:59, Alexander Rødseth wrote:
  +1 Sounds reasonable.
 
  But, is there a way to achieve the same result without using a helper
 package?
 
 I don't know. It would be appreciated but I don't know how that could be
 done. I most certainly don't want magic in nvidia-utils post_install().

Re: [arch-dev-public] Please provide Info for my talk!

[Guillaume Alaux]

On 25 February 2013 10:26, Tom Gundersen t...@jklm.no wrote:
 On Mon, Feb 25, 2013 at 12:17 AM, Allan McRae al...@archlinux.org wrote:
 @Tom: I will ping you with what I got...  In fact, you can also have a
 copy of my talk!

 Thanks!

 Disappointingly, I only have responses from 4 devs, 2 TU and 2 users.

 :(

 Disappointingly, I only have responses from 4 devs, 2 TU and 2 users.
Do you mean you think some people have some commit access but did not
(take the time to) answer or do you mean you thought more people had
commit access?

Re: [arch-dev-public] JAVA_HOME in systemd

[Guillaume ALAUX]

On 6 February 2013 15:46, Tom Gundersen t...@jklm.no wrote:
 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

Someone [0] proposed a clean/clever solution.

What about a symlink /usr/lib/jvm/default-java pointing to the
required runtime environment? Each Java runtime would need to check if
this link already exists. If not then just create it to point at the
newly installed JRE, if it already exists then just warn the user
about it and how to modify it.

Systemd service files could then use
'Environment=JAVA_HOME=/usr/lib/jvm/default-java' or if they wish use
a specific one.

[0] http://stackoverflow.com/a/663726

[arch-dev-public] JAVA_HOME in systemd

[Guillaume ALAUX]

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

[arch-dev-public] JAVA_HOME in systemd

[Guillaume ALAUX]

-- 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

[Guillaume ALAUX]

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] Nymeria Migration Guide for extra

[Guillaume Alaux]

On 20 January 2013 20:37, Florian Pritz bluew...@xinu.at wrote:
 Just for you to know we do not have read rights on /mnt/old_home/gerolde

 Fixed



Hello !

We should update the wiki page [0].

Could anybody give me write access to these pages or do it please?

Thanks

[0] https://wiki.archlinux.org/index.php/DeveloperWiki:HOWTO_Be_A_Packager

Re: [arch-dev-public] Nymeria Migration Guide for extra

[Guillaume Alaux]

On 20 January 2013 18:31, Florian Pritz bluew...@xinu.at wrote:
 Hi,

 We finally migrated extra to nymeria, here's a quick check list how to
 get things working again:

 Host name: nymeria.archlinux.org
 User name: same as archweb login name

 RSA fingerprint: cd:26:69:1a:7c:7f:bd:bd:42:4f:d7:ee:27:37:27:b4
 DSA fingerprint: 11:a3:e7:27:9c:6d:8f:42:be:7c:31:93:05:1e:ad:36
 ECDSA fingerprint: 6e:8b:ce:e4:74:92:3d:c2:67:9a:2f:8f:66:8b:96:e1

 Migration:

  - dbscripts is in /srv/repos/svn-pacakges/dbscripts and there is a
 symlink /packages for easier access. community also got /community now.

  - authorized ssh keys have been migrated, user names have been changed
to match archweb login names.

  - fix your ~/.ssh/config so the user name is correct (only needed for
running dbscripts)

  - your old home from gerolde is available in
 /mnt/old_homes/gerolde/$user. Please only copy what you need and leave
 or remove the rest. /mnt/old_homes will be erased in a few weeks/months.

  - update devtools to 20130120 or newer

  - run the following for all checkouts:
 svn relocate svn+ssh://gerolde.archlinux.org/srv/svn-packages 
 svn+ssh://svn-packa...@nymeria.archlinux.org/srv/repos/svn-packages/svn

  - do the same on pkgbuild.com if you use svn there

  - You might have to recreate some dirs in ~/staging. core, extra and
 testing are already there.

  - If you add a new ssh key to ~/.ssh/authorized_keys it can take up to
 15 minutes before the key is added to the list of authorized keys for
 the svn-{packages,community} user.

 You will only have an account on nymeria if you were marked active in
 archweb and in the dev group.

 If something is broken please tell Pierre or me via mail or IRC.


Hi,

Thanks for this.

Just for you to know we do not have read rights on /mnt/old_home/gerolde

--
Guillaume

Re: [arch-dev-public] adm and log groups

[Guillaume ALAUX]

On 10 November 2012 19:46, Jan Steffens jan.steff...@gmail.com wrote:

 The meaning of these two groups (adm and log) seems to be
 identical. Both allow read access to system logs, except adm is used
 by journald and log by syslogd (and tomcat, apparently).

 Wouldn't it make sense to do away with one?

Hi,

That's fine by me. If log is to be removed I could probably use adm
for tomcat then.

--
Guillaume

Re: [arch-dev-public] remaining items in the systemd TODO

[Guillaume Alaux]

On 26 September 2012 21:59, Tom Gundersen t...@jklm.no wrote:
 Hi guys,

 As our gnome 3.6 packages will be depending on systemd and are
 scheduled to be released in the not too distant future, I thought it
 might make sense to try and finish up as many service files as
 possible before that time.

 In our TODO list there are about 50 packages with rc scripts, but
 without systemd service files. I'll be going over all the orphans in
 [extra] tonight, but that still leaves quite a few.

 Could those of you with outstanding items in the TODO list please have
 a look and indicate if they are still intending to do it themselves,
 or if they need some guidance, or if they prefer someone else to do
 it?

 Cheers,

 Tom

Hi Tom, Hi all,

As for package tomcat: this version will not be supported by upstream
after September 30rd. So I intend to drop it in 3 days. No real need
to migrate it to systemd then.

--
Guillaume

Re: [arch-dev-public] Time to go

[Guillaume Alaux]

On Jun 5, 2012 2:36 PM, Andrea Scarpino and...@archlinux.org wrote:

 On Tuesday 05 June 2012 08:31:41 Paul Mattal wrote:
  It's been an exciting ride with you all. I came on to help launch the
  AUR in 2005, and we changed the Arch world forever.
 
  I encourage the new folks to think boldly and put your efforts and
  persistence into making the world better, one incremental improvement at
  a time-- and remember to have fun along the way!

 A big thank you for your amazing work, Paul.

 And good luck for everything you want :)

 Best Regards

 --
 Andrea

Bye Paul!

We have never really had the occasion to work together but it is always a
bit sad to hear someone leave.

Anyway. Have fun. :)

Guillaume

Re: [arch-dev-public] clucene to extra / drop lucene?

[Guillaume Alaux]

On 3 June 2012 14:18, Andreas Radke andy...@archlinux.org wrote:

 The upcoming LibreOffice 3.6.x drops the dependency on (java) lucene
 2.9.x. We can drop java lucene from our repos if nobody
 else wants to take over the maintainership of java lucene in the future.

 I'd like to bring in clucene from community and fix a missing feature.
 But I'm not familiar with it. So I'd be glad if someone else would pick
 it up in extra repo. Anyone going to do this?

 -Andy

 PS: current build failure with clucene from community:

 checking which clucene to use... external
 checking for CLUCENE... yes
 checking for CLucene/analysis/cjk/CJKAnalyzer.h... no
 configure: error: Your version of libclucene has contribs-lib missing.
 Error running configure at ./autogen.sh line 187.

Hi,

I would gladly adopt (java) lucene.

--
Guillaume

Re: [arch-dev-public] clucene to extra / drop lucene?

[Guillaume Alaux]

On 3 June 2012 14:18, Andreas Radke andy...@archlinux.org wrote:
 The upcoming LibreOffice 3.6.x drops the dependency on (java) lucene
 2.9.x. We can drop java lucene from our repos if nobody
 else wants to take over the maintainership of java lucene in the future.

 I'd like to bring in clucene from community and fix a missing feature.
 But I'm not familiar with it. So I'd be glad if someone else would pick
 it up in extra repo. Anyone going to do this?

 -Andy

 PS: current build failure with clucene from community:

 checking which clucene to use... external
 checking for CLUCENE... yes
 checking for CLucene/analysis/cjk/CJKAnalyzer.h... no
 configure: error: Your version of libclucene has contribs-lib missing.
 Error running configure at ./autogen.sh line 187.

Hi,

I would gladly adopt (java) lucene.

[arch-dev-public] New Java library packages

[Guillaume ALAUX]

Hello,

I would like to create some new packages in [extra]. They are all
core Java libraries (JARs). I say core because they are all basic
libraries used by a lot of Java projects.

I am posting here to see if someone has something to say against
officially supporting these in Arch and also so that devs/TUs who
maintain Java apps know they could officially rely on these libs.

Here is a first list based on what *I* would need for 'apache-ant'
(names are as used by upstream projects. I plan to prepend them with
'java-')

- activation.jar
- bcel.jar (already pushed in extra as 'java-bcel')
- bsf.jar
- gnumail.jar
- inetlib.jar
- jdepend.jar
- log4j-1.2.jar
- xml-resolver-1.2.jar
- commons-net.jar
- jsch.jar

Some are in the AUR but on various states (some OOD, orphans, adopted by me).

--
Guillaume

Re: [arch-dev-public] Broken packages in [extra]

[Guillaume Alaux]

I will have a look at the ones I maintain.

Re: [arch-dev-public] Developer/TU key signing

[Guillaume ALAUX]

On 11/25/2011 02:27 PM, Ionut Biru wrote:
 Hi,
 
 my arch master key is available [1] with fingerprint 44D4 A033 AC14 0143
 9273  97D4 7EFD 567D 4C7E A887.
 
 Every packager please do:
 
 1) reply this email in the mailing list, include gerolde/sigurd username
 and sign your reply using your gpg key.
 2) name at least one package you already signed.
 
 [1] https://dev.archlinux.org/~ibiru/ionut_AT_master-key.archlinux.org
 
 

account: guillaume
package: java-commons-daemon

-- 
Guillaume



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Finalizing the package signing process

[Guillaume ALAUX]

On 30 October 2011 22:47, Daniel Isenmann daniel.isenm...@gmx.de wrote:
 On Sun, 30 Oct 2011 21:58:35 +0100
 Tom Gundersen t...@jklm.no wrote:

 On Sun, Oct 30, 2011 at 9:38 PM, Daniel Isenmann
 daniel.isenm...@gmx.de wrote:
  I don't think signing remotely is going to be possible, also I
  don't see the point of it. We anyway have to download the package
  in order to test it, so we wouldn't really gain anything.
 
  Not all packages have to be tested, e.g. a large rebuild against a
  new library version which you are sure that nothing is broken in
  your pakage and only needs new linking against the new library.
  That's only as an example.

 But surely you will eventually download and install it? That said, I
 guess there will be cases where it would be useful to not immediately
 have to download the package (even if I'm struggling to imagine atm).

 Sure. I will do that. But mainly I build the packages not at home and
 that's my main problem. But I will try the method with your small
 script, thanks for that.


  I use a script to download, sign and upload signature, then I test
  the package locally before pushing it to the repos.
 
  Mind if you can provide the script. Such a helper script would help
  a lot.

 Sure, it is based on something given to me by another dev on IRC
 (forgot who). Hopefully they won't sue me for copyright infringement
 ;-)

 It will leave the packages in /tmp for you to test, so you might want
 to remember to delete them afterwards.

 #!/bin/bash

 DIR=`mktemp -d /tmp/signpkg.${1}.X`
 pushd ${DIR}
 scp pkgbuild.com:svn-packages/$1/trunk/*.pkg.tar.xz .
 for i in *.pkg.tar.xz; do
 #  gpg --detach-sign --use-agent -u $KEY $i
   gpg --detach-sign --use-agent $i
 done
 scp *.pkg.tar.xz.sig pkgbuild.com:svn-packages/$1/trunk/
 popd

 Thanks for that...

 Daniel


Just in case it can help, I also made a script [0] that updates the
svn tree from alderaan to a local tree and rsync the remote packages
to a local folder.

I then just need to install, test and if OK I can extrapkg
'blahblahblah'  from my local machine.

It also works with community packages.

(Don't forget the configuration file [1] if you want to test)

[0] https://raw.github.com/galaux/scripts/master/duppkgbuild/duppkgbuild
[1] https://raw.github.com/galaux/scripts/master/duppkgbuild/duppkgbuild.conf

--
Guillaume

Re: [arch-dev-public] [arch-general] gnutls 3.0.0 pushed to testing

[Guillaume ALAUX]

On 08/14/2011 09:10 PM, Ionut Biru wrote:
 On 08/14/2011 10:06 AM, Jan Steffens wrote:
 On Sat, Aug 13, 2011 at 7:04 AM, Andreas Radkea.ra...@arcor.de  wrote:
 We've just moved the gnutls 3.0.0 rebuilds to testing. Please check if
 anything is broken and report bugs or give us your ok to move them all
 to extra/community.

 -Andy


 (Reposting on dev-public because I didn't notice the recipient_)

 telepathy-gabble is broken (segfaults) and I'm pretty sure it's
 gnutls' fault.

 #0  0x756dc7f0 in ?? () from /lib/libc.so.6
 #1  0x756d6735 in memmove () from /lib/libc.so.6
 #2  0x75a17999 in g_memdup () from /usr/lib/libglib-2.0.so.0
 #3  0x004e3899 in wocky_tls_session_push_func
 (user_data=0x7e01a0, buffer=0x8921b0, count=4294967269) at
 wocky-tls.c:1192
 #4  0x76e800c5 in _gnutls_writev_emu (session=0x88f9d0,
 fd=0x7e01a0, giovec=0x7fffd710, giovec_cnt=3) at
 gnutls_buffers.c:322
 #5  0x76e8016e in _gnutls_writev (session=0x88f9d0,
 giovec=0x7fffd710, giovec_cnt=3) at gnutls_buffers.c:349
 #6  0x76e808de in _gnutls_io_write_flush (session=0x88f9d0) at
 gnutls_buffers.c:564
 #7  0x76e80e02 in _gnutls_handshake_io_write_flush
 (session=0x88f9d0) at gnutls_buffers.c:679
 #8  0x76e85947 in _gnutls_send_handshake (session=0x88f9d0,
 bufel=0xb40440, type=GNUTLS_HANDSHAKE_FINISHED) at
 gnutls_handshake.c:1133
 #9  0x76e84916 in _gnutls_send_finished (session=0x88f9d0,
 again=0) at gnutls_handshake.c:667
 #10 0x76e8925b in _gnutls_send_handshake_final
 (session=0x88f9d0, init=1) at gnutls_handshake.c:2600
 #11 0x76e89f02 in _gnutls_handshake_common (session=0x88f9d0)
 at gnutls_handshake.c:2822
 #12 0x76e885e4 in gnutls_handshake (session=0x88f9d0) at
 gnutls_handshake.c:2342
 #13 0x004e1a3e in wocky_tls_session_try_operation
 (session=0x7e01a0, operation=WOCKY_TLS_OP_READ) at wocky-tls.c:386
 #14 0x004e35a9 in wocky_tls_session_read_ready
 (object=0x818c90, result=0x85c920, user_data=0x7e01a0) at
 wocky-tls.c:
 #15 0x76578929 in ?? () from /usr/lib/libgio-2.0.so.0
 #16 0x7659010c in ?? () from /usr/lib/libgio-2.0.so.0
 #17 0x759fa29d in g_main_context_dispatch () from
 /usr/lib/libglib-2.0.so.0
 #18 0x759faa78 in ?? () from /usr/lib/libglib-2.0.so.0
 #19 0x759fb0ba in g_main_loop_run () from
 /usr/lib/libglib-2.0.so.0
 #20 0x76bbe04f in tp_run_connection_manager () from
 /usr/lib/libtelepathy-glib.so.0
 #21 0x00431e81 in gabble_main (argc=1, argv=0x7fffdea8) at
 gabble.c:177
 #22 0x00431b09 in main (argc=1, argv=0x7fffdea8) at main.c:28

 Look at that count=4294967269 buffer length, that can't be right. Of
 the three giovecs used, the first two have 4294967269 length, the
 third one has a more sane 53.
 
 As a workaround now i enabled openssl backend in extra and removed the
 gnutls one from testing.
 
 But we really need to fix this properly by reporting upstream. Have you
 done it?
 

Hello,

Wireshark looks OK.

-- 
Guillaume



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] away 15 - 21 of August

[Guillaume ALAUX]

Hi all,

I will be away from 15 to 21 of August with no internet connection.

Feel free to update my packages if needed.

-- 
Guillaume



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] New packages for OpenJDK7

[Guillaume ALAUX]

Hi everyone,

Following the general availability of OpenJDK7 (and community's
jre/jdk), I updated openjdk6 PKGBUILD for OpenJDK7 (thanks Andy for
letting me have a look at that).

Just like the current openjdk6, these packages are based on OpenJDK7 to
which we add the IcedTea code that enable building with free tools and
add some more open source stuff.

The only new thing (apart from version 6 - 7) is the fact that files
are splitted into 'jre7-openjdk' and 'jdk7-openjdk' (and openjdk7-src).

These packages are not 'final' so not currently available in a repo but
here:

  http://dev.archlinux.org/~guillaume/openjdk7/

I am away on holidays next week so I won't be able to answer any email
but suggestions are welcome ; feedback also.

-- 
Guillaume



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] [signoff] shadow-4.1.4.2-4

[Guillaume ALAUX]

On Sat, 29 Jan 2011 11:55:30 +0100
Gaetan Bisson bis...@archlinux.org wrote:

 [2011-01-27 00:05:45 +0200] Ionuț Bîru:
  implemented FS#21391.
  
  is needed because  consolekit 0.4.2 changed the default policy and
  expects that a third party to authorize the user. That works out of
  the box with graphically login managers as GDM/KDM/LXDM.
  
  Note that ck-launch-session hack is still needed in ~/.xinitrc.
  
  Tested with gnome and xfce and mounting/reboot/shutdown works.
  
  exec ck-launch-session gnome-session
  exec ck-launch-session xfce-session
 
 I can sign off this package for simple use on i686 (no consolekit).
 

Signoff 64

-- 
Guillaume


signature.asc
Description: PGP signature

Re: [arch-dev-public] Developer public_html down?

[Guillaume ALAUX]

On 13 February 2011 10:34, Tobias Powalowski t.p...@gmx.de wrote:

 Hi guys
 i can't access http://dev.archlinux.org/~tpowa
 anymore
 any idea why it doesn't work?

 greetings
 tpowa
 --
 Tobias Powalowski
 Archlinux Developer  Package Maintainer (tpowa)
 http://www.archlinux.org
 tp...@archlinux.org

Hi Tobias,

I can access it. Maybe it's back up now?

--
Guillaume

Re: [arch-dev-public] [signoff] openssh-5.8p1-1

[Guillaume ALAUX]

On Fri, 2011-02-04 at 08:42 +0100, Gaetan Bisson wrote:
 Hi all,
 
 OpenSSH 5.8 has just been released as a security update on 5.7; see the
 Changelog below. Nothing but the version numbers and checksums changed
 in the PKGBUILD of openssh-5.8-p1-1, which I just put in [testing].
 
 Please test and signoff so we can move this as quickly as possible.
 
 Cheers.
 

All good here!

Signoff x86_64.

--
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] openssh-5.7p1-1

[Guillaume ALAUX]

On Wed, 2011-01-26 at 11:24 +0100, Gaetan Bisson wrote:
 [2011-01-26 11:14:30 +0100] Tobias Powalowski:
  So I would say, enable at least PAM again in default config.
 
 I do not understand why.
 
 I am a bit more confident in the ability of openssh upstream devs to
 configure their software as I am in Gentoo/Fedora's.
 
 PAM is only required for advanced kinds of authentication, so it seems
 quite logical to me that users would have to enable it themselves.
 

I think we are dealing with 2 issues here:
  - do we ship the default upstream config file?
  - if answer to previous is No then which option do we set as default?

We reverted back to the upstream conf to follow the Arch idea. We
implicitly say Power user, do your job when installing a SSH server. I
understand your concern about minimum security but user should know how
to configure an openSSH server if they need one. And if they don't maybe
let's add an secure example in the wiki.

--
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] openssh-5.7p1-1

[Guillaume ALAUX]

On Wed, 2011-01-26 at 11:38 +0100, Gaetan Bisson wrote:
 [2011-01-26 11:29:56 +0100] Guillaume ALAUX:
  We reverted back to the upstream conf to follow the Arch idea. We
  implicitly say Power user, do your job when installing a SSH server. I
  understand your concern about minimum security but user should know how
  to configure an openSSH server if they need one. And if they don't maybe
  let's add an secure example in the wiki.
 
 Just to clarify: The default sshd_config from upstream *is* secure.
 
 We are just talking about enabling (or not) features by default.
 

 Just to clarify: The default sshd_config from upstream *is* secure.
Agree

 We are just talking about enabling (or not) features by default.
I think we should leave it as is but I don't really mind.
--
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] openssh-5.7p1-1

[Guillaume ALAUX]

On Mon, 2011-01-24 at 13:09 +0100, Gaetan Bisson wrote:
 Hi everyone,
 
 OpenSSH 5.7 has just been released. Due to Guillaume's work on this
 package, the upgrade was quite straightforward and openssh-5.7p1-1 is
 now in [testing]. All tests pass on both architectures.
 
 Enjoy your shiny new ECDSA keys!
 
 (And then please signoff.)
 
 -- 
 Gaetan
 
 
 Changes since OpenSSH 5.6
 =
 
 Features:
 
  * Implement Elliptic Curve Cryptography modes for key exchange (ECDH)
and host/user keys (ECDSA) as specified by RFC5656. ECDH and ECDSA
offer better performance than plain DH and DSA at the same equivalent
symmetric key length, as well as much shorter keys.
  
Only the mandatory sections of RFC5656 are implemented, specifically
the three REQUIRED curves nistp256, nistp384 and nistp521 and only
ECDH and ECDSA. Point compression (optional in RFC5656) is NOT
implemented.
  
Certificate host and user keys using the new ECDSA key types are
supported - an ECDSA key may be certified, and an ECDSA key may act
as a CA to sign certificates.
 
ECDH in a 256 bit curve field is the preferred key agreement
algorithm when both the client and server support it. ECDSA host
keys are preferred when learning a host's keys for the first time,
or can be learned using ssh-keyscan(1).
  
  * sftp(1)/sftp-server(8): add a protocol extension to support a hard
link operation. It is available through the ln command in the
client. The old ln behaviour of creating a symlink is available
using its -s option or through the preexisting symlink command
 
  * scp(1): Add a new -3 option to scp: Copies between two remote hosts
are transferred through the local host.  Without this option the
data is copied directly between the two remote hosts. 
 
  * ssh(1): automatically order the hostkeys requested by the client
based on which hostkeys are already recorded in known_hosts. This
avoids hostkey warnings when connecting to servers with new ECDSA
keys, since these are now preferred when learning hostkeys for the
first time.
 
  * ssh(1)/sshd(8): add a new IPQoS option to specify arbitrary
TOS/DSCP/QoS values instead of hardcoding lowdelay/throughput.
bz#1733
 
  * sftp(1): the sftp client is now significantly faster at performing
directory listings, using OpenBSD glob(3) extensions to preserve
the results of stat(3) operations performed in the course of its
execution rather than performing expensive round trips to fetch
them again afterwards.
 
  * ssh(1): atomically create the listening mux socket by binding it on
a temporary name and then linking it into position after listen() has
succeeded. This allows the mux clients to determine that the server
socket is either ready or stale without races. stale server sockets
are now automatically removed. (also fixes bz#1711)
 
  * ssh(1)/sshd(8): add a KexAlgorithms knob to the client and server
configuration to allow selection of which key exchange methods are
used by ssh(1) and sshd(8) and their order of preference.
 
  * sftp(1)/scp(1): factor out bandwidth limiting code from scp(1) into
a generic bandwidth limiter that can be attached using the atomicio
callback mechanism and use it to add a bandwidth limit option to
sftp(1). bz#1147
  
 BugFixes:
 
  * ssh(1)/ssh-agent(1): honour $TMPDIR for client xauth and ssh-agent
temporary directories. bz#1809
 
  * ssh(1): avoid NULL deref on receiving a channel request on an unknown
or invalid channel; bz#1842
 
  * sshd(8): remove a debug() that pollutes stderr on client connecting
to a server in debug mode; bz#1719
 
  * scp(1): pass through ssh command-line flags and options when doing
remote-remote transfers, e.g. to enable agent forwarding which is
particularly useful in this case; bz#1837
 
  * sftp-server(8): umask should be parsed as octal
 
  * sftp(1): escape '[' in filename tab-completion
 
  * ssh(1): Typo in confirmation message.  bz#1827
 
  * sshd(8): prevent free() of string in .rodata when overriding
AuthorizedKeys in a Match block
 
  * sshd(8): Use default shell /bin/sh if $SHELL is 
 
  * ssh(1): kill proxy command on fatal() (we already killed it on
clean exit);
 
  * ssh(1): install a SIGCHLD handler to reap expiried child process;
bz#1812
 
  * Support building against openssl-1.0.0a
 
 Portable OpenSSH Bugfixes:
 
  * Use mandoc as preferred manpage formatter if it is present, followed
by nroff and groff respectively.
 
  * sshd(8): Relax permission requirement on btmp logs to allow group
read/write
 
  * bz#1840: fix warning when configuring --with-ssl-engine
 
  * sshd(8): Use correct uid_t/pid_t types instead of int. bz#1817
 
  * sshd(8): bz#1824: Add Solaris Project support.
 
  * sshd(8): Check is_selinux_enabled for exact return code since it can
apparently return -1 under some conditions.

Signoff 

Re: [arch-dev-public] Update tomcat from 5.5 to 6.0?

[Guillaume ALAUX]

On Sun, 2011-01-16 at 10:54 +0100, Rémy Oudompheng wrote:
 On 2011/1/14 Ionuț Bîru ib...@archlinux.orgwrote :
  i'm for this situation too. just update tomcat to he newest stable version
  and drop the old stable.
 
 Then I fear we actually have to package Tomcat 7, not Tomcat 6.
 

Well actually Tomcat doesn't use the usual versionning scheme. ie
version n doesn't deprecate version n-1. Instead each version is the
implementation of a version of the Servlet/JSP specifications.

The Tomcat team provides this table:

http://tomcat.apache.org/whichversion.html

Users can refer to it when trying to figure out which Tomcat version
they should use depending on the Servlet/JSP their webapp uses.

That is why you won't find any upstream info on which tomcat version is
the stable one that should be used in any case. 

FYI the first stable Tomcat 7 version (7.0.6) went out 3 days ago
(stable here means the dev team didn't call it -beta nor -alpha):

http://archive.apache.org/dist/tomcat/tomcat-7/

This is also why I would be in favor of keeping tomcat 5.5 in an
official repo. What about Tomcat 7?
-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

[arch-dev-public] Update tomcat from 5.5 to 6.0?

[Guillaume ALAUX]

Hi everyone,

User servernyc (gmail) flagged extra/tomcat as out-of-date and asked:
where is tomcat 6? any reason for 5.5 still?

I unflagged it as our tomcat package is currently from the 5.5 branch
and is up to date on its branch but still his question is relevant. I
think it is high time to make the move. Both branches 5.5 [0] and 6 [1]
are widely used and considered stable.

(I am currently working on both tomcat 5.5 and tomcat 6.0 packages built
from source with dependencies extracted)

So the feature request is Update tomcat from 5.5 to 6.0. Has anyone
got something against it?
If no-one has, how to proceed regarding package names?

  - Rename tomcat to tomcat5? (careful because the 5.0 branch
existed [2])
   OR
  - Rename tomcat to tomcat5.5?

AND
  - Use tomcat for 6.0 branch?
   OR
  - Create tomcat6 for 6.0 branch?

[0] http://tomcat.apache.org/download-55.cgi
[1] http://tomcat.apache.org/download-60.cgi
[2] http://archive.apache.org/dist/tomcat/tomcat-5/

--
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Update tomcat from 5.5 to 6.0?

[Guillaume ALAUX]

On Fri, 2011-01-14 at 20:48 +0100, Guillaume ALAUX wrote:
 Hi everyone,
 
 User servernyc (gmail) flagged extra/tomcat as out-of-date and asked:
 where is tomcat 6? any reason for 5.5 still?
 
 I unflagged it as our tomcat package is currently from the 5.5 branch
 and is up to date on its branch but still his question is relevant. I
 think it is high time to make the move. Both branches 5.5 [0] and 6 [1]
 are widely used and considered stable.
 
 (I am currently working on both tomcat 5.5 and tomcat 6.0 packages built
 from source with dependencies extracted)
 
 So the feature request is Update tomcat from 5.5 to 6.0. Has anyone
 got something against it?
 If no-one has, how to proceed regarding package names?
 
   - Rename tomcat to tomcat5? (careful because the 5.0 branch
 existed [2])
OR
   - Rename tomcat to tomcat5.5?
 
 AND
   - Use tomcat for 6.0 branch?
OR
   - Create tomcat6 for 6.0 branch?
 
 [0] http://tomcat.apache.org/download-55.cgi
 [1] http://tomcat.apache.org/download-60.cgi
 [2] http://archive.apache.org/dist/tomcat/tomcat-5/
 
 --
 Guillaume

Forgot to link the bugtracker issue I opened in that intention:
https://bugs.archlinux.org/task/22424
-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

[arch-dev-public] [signoff] openssh 5.6p1-2

[Guillaume ALAUX]

Gaëtan (vesath) and I took care of some Arch bugs.

PKGBUILD cleaned

Arch Bug fixes:
  - FS#20191 - upstream config files modified on install
  sshd_config and ssh_config are not modified anymore

  - FS#19213 - sshd ignores /etc/nologin, when loging with key
  Modified etc/pam.d/sshd for this feature

  - FS#22366 - Add --with-libedit compile option to PKGBUILD
  Added dependency to libedit / require libedit to be moved to core

  - FS#17138 - startup scripts should check pid files more closely
  etc/rc.d/sshd fixed (thanks remy)

  - FS#20998 - runtime config file is not part of backup array
  added file to array

Please signoff both architectures.

Thanks.
-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

[arch-dev-public] Move libedit from extra to core for openssh dependency

[Guillaume ALAUX]

Hello,

As stated in this bug report [0] sftp lacks TAB completion and history
through UP and DOWN arrows because of missing libedit dependency.

Some devs already posted positively about the move. Has anyone got
something against it?

BTW I'm also reviewing bugs related to openssh so please feel free to
post on bug reports if needed.

[0] http://bugs.archlinux.org/task/22366
-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] adding hunspell-xx packages

[Guillaume ALAUX]

On Thu, 2010-12-30 at 19:06 +0100, Andreas Radke wrote:
 Am Thu, 30 Dec 2010 16:06:15 +0100
 schrieb Andreas Radke a.ra...@arcor.de:
 
  hunspell-de is alive.
 
 hunspell-en as well. same for
 hyphen-de (we already had hyphen-en from the hyphen split pkg)
 mythes-de and
 mythes-en.
 
 Feel free to add more languages sets (hunspell/hyphen/mythes) you need.
 Always check whether 
 Fedora (http://pkgs.fedoraproject.org/gitweb/) or 
 OpenOffice (http://wiki.services.openoffice.org/wiki/Dictionaries)
 has a more recent version.
 
 Now we need to rebuild OOo/LibO and Mozilla packages to make use of
 them. AUR and Community packages may need fixes for the proper file
 locations.
 
 -Andy

Hi,

hunspell-fr, hyphen-fr and mythes-fr in testing.

Thanks Ionut!

-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] cryptsetup 1.2.0-1

[Guillaume ALAUX]

On Thu, 2010-12-23 at 23:28 +0100, Thomas Bächler wrote:
 Upstream update, please sign off.
 
 From the announcement:
 
 Changes since version 1.1.3
 
 Important changes
 ~
 
  * Add text version of *FAQ* (Frequently Asked Questions) to distribution.
 
  * Add selection of random/urandom number generator for luksFormat
  (option --use-random and --use-urandom).
 
  (This affects only long term volume key in *luksFormat*,
  not RNG used for salt and AF splitter).
 
   You can also set the default to /dev/random during compilation with
   --enable-dev-random. Compiled-in default is printed in --help output.
 
   Be very careful before changing default to blocking /dev/random use here.
 
  * Fix *luksRemoveKey* to not ask for remaining keyslot passphrase,
  only for removed one.
 
  * No longer support *luksDelKey* (replaced with luksKillSlot).
   * if you want to remove particular passphrase, use *luksKeyRemove*
   * if you want to remove particular keyslot, use *luksKillSlot*
 
  Note that in batch mode *luksKillSlot* allows removing of any keyslot
  without question, in normal mode requires passphrase or keyfile from
  other keyslot.
 
  * *Default alignment* for device (if not overridden by topology info)
  is now (multiple of) *1MiB*.
  This reflects trends in storage technologies and aligns to the same
  defaults for partitions and volume management.
 
  * Allow explicit UUID setting in *luksFormat* and allow change it later
  in *luksUUID* (--uuid parameter).
 
  * All commands using key file now allows limited read from keyfile using
  --keyfile-size and --new-keyfile-size parameters (in bytes).
 
  This change also disallows overloading of --key-size parameter which
  is now exclusively used for key size specification (in bits.)
 
  * *luksFormat* using pre-generated master key now properly allows
  using key file (only passphrase was allowed prior to this update).
 
  * Add --dump-master-key option for *luksDump* to perform volume (master)
  key dump. Note that printed information allows accessing device without
  passphrase so it must be stored encrypted.
 
  This operation is useful for simple Key Escrow function (volume key and
  encryption parameters printed on paper on safe place).
 
  This operation requires passphrase or key file.
 
  * The reload command is no longer supported.
  (Use dmsetup reload instead if needed. There is no real use for this
  function except explicit data corruption:-)
 
  * Cryptsetup now properly checks if underlying device is in use and
  disallows *luksFormat*, *luksOpen* and *create* commands on open
  (e.g. already mapped or mounted) device.
 
  * Option --non-exclusive (already deprecated) is removed.
 
 Libcryptsetup API additions:
 
  * new functions
   * crypt_get_type() - explicit query to crypt device context type
   * crypt_resize() - new resize command using context
   * crypt_keyslot_max() - helper to get number of supported keyslots
   * crypt_get_active_device() - get active device info
   * crypt_set/get_rng_type() - random/urandom RNG setting
   * crypt_set_uuid() - explicit UUID change of existing device
   * crypt_get_device_name() - get underlying device name
 
  * Fix optional password callback handling.
 
  * Allow to activate by internally cached volume key immediately after
  crypt_format() without active slot (for temporary devices with
  on-disk metadata)
 
  * libcryptsetup is binary compatible with 1.1.x release and still
  supports legacy API calls
 
  * cryptsetup binary now uses only new API calls.
 
  * Static compilation of both library (--enable-static) and cryptsetup
  binary (--enable-static-cryptsetup) is now properly implemented by common
  libtool logic.
 
  Prior to this it produced miscompiled dynamic cryptsetup binary with
  statically linked libcryptsetup.
 
  The static binary is compiled as src/cryptsetup.static in parallel
  with dynamic build if requested.
 
 Other changes
 ~
  * Fix default plain password entry from terminal in activate_by_passphrase.
  * Initialize volume key from active device in crypt_init_by_name()
  * Fix cryptsetup binary exit codes.
0 - success, otherwise fail
1 - wrong parameters
2 - no permission
3 - out of memory
4 - wrong device specified
5 - device already exists or device is busy
  * Remove some obsolete info from man page.
  * Add more regression tests for commands.
  * Fix possible double free when handling master key file.
  * Fix pkg-config use in automake scripts.
  * Wipe iteration and salt after luksKillSlot in LUKS header.
  * Rewrite file differ test to C (and fix it to really work).
  * Do not query non-existent device twice (cryptsetup status
 /dev/nonexistent).
  * Check if requested hash is supported before writing LUKS header.
  * Fix problems reported by clang scan-build.
 

And signoff i686 too.

-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

[arch-dev-public] extra/progsreiserfs duplicate of core/reiserfsprogs?

[Guillaume ALAUX]

Hello,

Correct me if I'm wrong but it looks like extra/progsreiserfs
(0.3.0.5-5) is an old duplicate of core/reiserfsprogs (3.6.21-3).

I search for reasons in mailing list archives for having both but found
none.

Nb: Old extra/progsreiserfs PKGBUILD [1] pulls a tarball from
ftp.archlinux.org. Let's remember to remove the tarball if we get rid of
the package.

[1]
http://repos.archlinux.org/wsvn/packages/progsreiserfs/trunk/PKGBUILD
-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] cryptsetup 1.2.0-1

[Guillaume ALAUX]

On Thu, 2010-12-23 at 23:28 +0100, Thomas Bächler wrote:
 Upstream update, please sign off.
 
 From the announcement:
 
 Changes since version 1.1.3
 
 Important changes
 ~
 
  * Add text version of *FAQ* (Frequently Asked Questions) to distribution.
 
  * Add selection of random/urandom number generator for luksFormat
  (option --use-random and --use-urandom).
 
  (This affects only long term volume key in *luksFormat*,
  not RNG used for salt and AF splitter).
 
   You can also set the default to /dev/random during compilation with
   --enable-dev-random. Compiled-in default is printed in --help output.
 
   Be very careful before changing default to blocking /dev/random use here.
 
  * Fix *luksRemoveKey* to not ask for remaining keyslot passphrase,
  only for removed one.
 
  * No longer support *luksDelKey* (replaced with luksKillSlot).
   * if you want to remove particular passphrase, use *luksKeyRemove*
   * if you want to remove particular keyslot, use *luksKillSlot*
 
  Note that in batch mode *luksKillSlot* allows removing of any keyslot
  without question, in normal mode requires passphrase or keyfile from
  other keyslot.
 
  * *Default alignment* for device (if not overridden by topology info)
  is now (multiple of) *1MiB*.
  This reflects trends in storage technologies and aligns to the same
  defaults for partitions and volume management.
 
  * Allow explicit UUID setting in *luksFormat* and allow change it later
  in *luksUUID* (--uuid parameter).
 
  * All commands using key file now allows limited read from keyfile using
  --keyfile-size and --new-keyfile-size parameters (in bytes).
 
  This change also disallows overloading of --key-size parameter which
  is now exclusively used for key size specification (in bits.)
 
  * *luksFormat* using pre-generated master key now properly allows
  using key file (only passphrase was allowed prior to this update).
 
  * Add --dump-master-key option for *luksDump* to perform volume (master)
  key dump. Note that printed information allows accessing device without
  passphrase so it must be stored encrypted.
 
  This operation is useful for simple Key Escrow function (volume key and
  encryption parameters printed on paper on safe place).
 
  This operation requires passphrase or key file.
 
  * The reload command is no longer supported.
  (Use dmsetup reload instead if needed. There is no real use for this
  function except explicit data corruption:-)
 
  * Cryptsetup now properly checks if underlying device is in use and
  disallows *luksFormat*, *luksOpen* and *create* commands on open
  (e.g. already mapped or mounted) device.
 
  * Option --non-exclusive (already deprecated) is removed.
 
 Libcryptsetup API additions:
 
  * new functions
   * crypt_get_type() - explicit query to crypt device context type
   * crypt_resize() - new resize command using context
   * crypt_keyslot_max() - helper to get number of supported keyslots
   * crypt_get_active_device() - get active device info
   * crypt_set/get_rng_type() - random/urandom RNG setting
   * crypt_set_uuid() - explicit UUID change of existing device
   * crypt_get_device_name() - get underlying device name
 
  * Fix optional password callback handling.
 
  * Allow to activate by internally cached volume key immediately after
  crypt_format() without active slot (for temporary devices with
  on-disk metadata)
 
  * libcryptsetup is binary compatible with 1.1.x release and still
  supports legacy API calls
 
  * cryptsetup binary now uses only new API calls.
 
  * Static compilation of both library (--enable-static) and cryptsetup
  binary (--enable-static-cryptsetup) is now properly implemented by common
  libtool logic.
 
  Prior to this it produced miscompiled dynamic cryptsetup binary with
  statically linked libcryptsetup.
 
  The static binary is compiled as src/cryptsetup.static in parallel
  with dynamic build if requested.
 
 Other changes
 ~
  * Fix default plain password entry from terminal in activate_by_passphrase.
  * Initialize volume key from active device in crypt_init_by_name()
  * Fix cryptsetup binary exit codes.
0 - success, otherwise fail
1 - wrong parameters
2 - no permission
3 - out of memory
4 - wrong device specified
5 - device already exists or device is busy
  * Remove some obsolete info from man page.
  * Add more regression tests for commands.
  * Fix possible double free when handling master key file.
  * Fix pkg-config use in automake scripts.
  * Wipe iteration and salt after luksKillSlot in LUKS header.
  * Rewrite file differ test to C (and fix it to really work).
  * Do not query non-existent device twice (cryptsetup status
 /dev/nonexistent).
  * Check if requested hash is supported before writing LUKS header.
  * Fix problems reported by clang scan-build.
 

Works like a charm.

Signoff x86_64.

-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] coreutils-8.8-1

[Guillaume ALAUX]

On 23 December 2010 04:20, Allan McRae al...@archlinux.org wrote:
 Upstream update.  Mostly a bug fix release to fix issues with sort.

 I removed ac_cv_func_openat=no from the configure line as that seems to be
 a work-around needed for a very old version of coreutils building under
 fakeroot, perhaps with an old glibc.  Given we no longer build under
 fakeroot, that should not be needed.  I believe the original issue was with
 a bug in rm -r and that still works, so hopefully this is all good...
  Also, the test suite still passes.  If anyone can remember the exact
 details of why this was needed, it would be good to check I have not caused
 a regression here.

 Signoff both.


 Upstream NEWS:

 * Noteworthy changes in release 8.8 (2010-12-22) [stable]

 ** Bug fixes

  cp -u no longer does unnecessary copying merely because the source
  has finer-grained time stamps than the destination.

  od now prints floating-point numbers without losing information, and
  it no longer omits spaces between floating-point columns in some cases.

  sort -u with at least two threads could attempt to read through a
  corrupted pointer. [bug introduced in coreutils-8.6]

  sort with at least two threads and with blocked output would busy-loop
  (spinlock) all threads, often using 100% of available CPU cycles to
  do no work.  I.e., sort  big-file | less could waste a lot of power.
  [bug introduced in coreutils-8.6]

  sort with at least two threads no longer segfaults due to use of pointers
  into the stack of an expired thread. [bug introduced in coreutils-8.6]

  sort --compress no longer mishandles subprocesses' exit statuses,
  no longer hangs indefinitely due to a bug in waiting for subprocesses,
  and no longer generates many more than NMERGE subprocesses.

  sort -m -o f f ... f no longer dumps core when file descriptors are
 limited.

 ** Changes in behavior

  sort will not create more than 8 threads by default due to diminishing
  performance gains.  Also the --parallel option is no longer restricted
  to the number of available processors.

 ** New features

  split accepts the --number option to generate a specific number of files.




Signoff x86_64.

--
Guillaume

Re: [arch-dev-public] [signoff] libcap 2.19-2

[Guillaume ALAUX]

On 23 December 2010 02:51, Stéphane Gaudreault steph...@archlinux.org wrote:
 * Tidy up PKGBUILD
 * Rebuild of old package

 Please signoff both.
 Thanks

 Stéphane


Checked several packages that rely on libcap: looks OK.

Signoff x86_64.

--
Guillaume

Re: [arch-dev-public] [signoff] subversion 1.6.15-1

[Guillaume ALAUX]

On 21 December 2010 18:18, Dan McGee dpmc...@gmail.com wrote:
 On Sun, Dec 19, 2010 at 11:18 AM, Paul Mattal p...@mattal.com wrote:
 At long last, subversion 1.6.15-1 is ready for signoff. Especially since
 it's been a long time since I've updated this package, try some
 probably-unique things you do with svn and see if they give you any trouble.

 Full changelist is below. No substantive changes to the PKGBUILD.

 Nothing super unique, but svn seems to be working OK for updates to
 things and some arch packaging stuff for both architectures.

 -Dan


+1 here for x86_64.

--
Guillaume

[arch-dev-public] Fwd: [aur-general] [signoff] rpcbind 0.2.0-3

[Guillaume ALAUX]

I think jwbirdsong meant to post his signoff on arch-general.

--
Guillaume




-- Forwarded message --
From: jwbirdsong jwbirds...@jwbirdsong.homelinux.com
Date: 23 December 2010 15:15
Subject: Re: [aur-general] [arch-dev-public] [signoff] rpcbind 0.2.0-3
To: (AUR) aur-gene...@archlinux.org
Cc: jwbirdIMAP jwbirds...@jwbirdsong.homelinux.com


On 12/20/2010 11:40 AM, Andreas Radke wrote:
 Minor fix: add missing man page for rpcinfo
 https://bugs.archlinux.org/task/21271

 Please sign off.

 -Andy


If you'll take user signoff...
Signoff both arches

Re: [arch-dev-public] [signoff] dnsutils-9.7.2.P3-1

[Guillaume ALAUX]

On 23 December 2010 17:19, Ionuț Bîru ib...@archlinux.org wrote:
 On 12/21/2010 12:52 PM, Gaetan Bisson wrote:

 Hi all,

 A minor upstream update of dnsutils is in [testing].

 Please signoff for both arches.


 signoff i686

 --
 Ionuț


Signoff x86_64

--
Guillaume

Re: [arch-dev-public] [signoff] libpcap 1.1.11-2

[Guillaume ALAUX]

On Sun, 2010-12-19 at 16:42 +0100, Andreas Radke wrote:
 - PKGBUILD cleanup
 - drop the unneeded static library
 - fix abs build https://bugs.archlinux.org/task/21643
 - add missing sh dependency
 
 Please sign off.
 
 -Andy

Signoff x86_64 (for 1.1.*1*-2 ;) ).

-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] diffutils-3.0-2

[Guillaume ALAUX]

On 9 December 2010 19:12, Gaetan Bisson bis...@archlinux.org wrote:

 [2010-12-09 09:31:11 -0500] Stéphane Gaudreault:
  * Rebuild of old package
  * Tidy up PKGBUILD

 signoff i686

 --
 Gaetan

Signoff x86_64

--
Guillaume

Re: [arch-dev-public] [signoff] procinfo-ng-2.0.304-2

[Guillaume ALAUX]

On 10 December 2010 00:24, Eric Bélanger snowmanisc...@gmail.com wrote:
 Hi,

 procinfo-ng-2.0.304-2 is in testing for core rebuild and to fix source url.
 Please test and signoff.

 Eric


Signoff x86_64

--
Guillaume

Re: [arch-dev-public] [signoff] nano 2.2.6-1

[Guillaume ALAUX]

On Mon, 2010-11-29 at 20:33 +0100, Andreas Radke wrote:
 The 2.2.5-2 build with fixed deps didn't move to core. Maybe because an
 i686 signoff was missing.
 
 A new release is out. Please sign off now both arches.
 
 -Andy
 
 2010.11.22 - GNU nano 2.2.6 Pimp my BBS wants you to go to 
   www.desertbus.org and donate a few bucks for the great 
   Child's Play Charity!  This is just a small release to 
   update a bug where restricted mode was not particularly 
   restricted since key bindings were introduced. It also 
   signals the return of win32 builds which now feature 
   nanorc support; please see the FAQ for details of how
   to enable it, this feature is a bit of a kludge for
   now. Remember that when all else fails, USE SPACE JUMP.

Basic things work here.

Signoff x86_64

-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] usbutils-0.91-2

[Guillaume ALAUX]

On Sun, 2010-11-28 at 14:24 +0100, Tobias Powalowski wrote:
 Hi guys,
 fixed depend to correct libusb1
 please signoff both arches
 
 greetings
 tpowa

I see the -3 (instead of -2 you are mentionning) in testing. So I can
signoff x86_64 for this -3 !
-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] O'Reilly book: Making Software

[Guillaume ALAUX]

On 22 November 2010 19:39, Aaron Griffin aaronmgrif...@gmail.com wrote:
 My boss just brought this book over to my desk. It's one of those
 theory books that's all about measuring lines of code and whatnot.

 But the reason he brought it over, is Chapter 8: Beyond Lines of
 Code: Do We Need More Complex Metrics?. Two pages in, it begins with:

 **Measuring the Source Code**
 We have selected for our case study the ArchLinux software
 distribution (http://archlinux.org), which contains thousands of
 packages, all open source. ArchLinux is a lightweight GNU/Linux
 distribution whose maintainers refuse to modify the source code
 packaged for the distribution, in order to meet the goal of
 drastically reducing the time that elapses between the official
 release of a package and its integration into the distribution.
 ...
 Because of the size of ArchLinux, using it as a case study gives us
 access to the original source code of thousands of open source
 projects, through the build scripts used by ABS (see Example 8-1)

 The chapter goes on with statistics and all that junk. They're not
 studying Arch, but using Arch as a launch pad for getting large
 amounts of open source source code for analysis. The numbers are
 interesting:

 The ArchLinux repositories contained 4096 packages (as of April 2010),
 with some of the packages being different versions of the same
 upstream project. After removing different versions, we obtained a
 sample of 4015 packages, containing 1272748 source code files. Among
 all those files, 576511 were written in C. However, there were
 repeated files. In the overall sample, only 776573 were unique files;
 in the C subsample, only 338831 were unique files. From these unique C
 files, 212167 were nonheader files and 126664 were header files.


Great! Proud to see Arch here :) The author might also be an Archer,
who knows. BTW I also like the idea of your boss coming to give you
the book like Oh and there this O'Reilly book about some of the stuff
you do

--
Guillaume

Re: [arch-dev-public] [signoff] gawk-3.1.8-2

[Guillaume ALAUX]

On Sun, 2010-11-21 at 16:10 +1000, Allan McRae wrote:
 On 20/11/10 22:37, Stéphane Gaudreault wrote:
  * Rebuild of old package
  * Tidy up PKGBUILD
  * Fix FS#17312
 
  Please signoff both.
  Thanks
 
 
 Signoff i686,
 Allan

Basic behavior work.

Signoff x86_64
-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] libusb-0.1.12-5

[Guillaume ALAUX]

On Fri, 2010-11-19 at 16:21 +0100, Andrea Scarpino wrote:
 - use package()
 - remove from base group
 - use tar.xz
 
 please signoff both
 

Tested with 3 different USB devices and no problem so far.

Signoff x86_64

-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] less-436-2

[Guillaume ALAUX]

On Fri, 2010-11-19 at 22:23 -0500, Stéphane Gaudreault wrote:
 * Rebuild of old package
 * Tidy up PKGBUILD
 * Added pcre as dependency
 
 Please signoff both.
 Thanks
 
 Stéphane

Signoff x86_64

-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] which-2.20-4

[Guillaume ALAUX]

On Sat, 2010-11-20 at 07:34 -0500, Stéphane Gaudreault wrote:
 * Rebuild of old package
 * Tidy up PKGBUILD
 
 Please signoff both.
 Thanks
 
 Stéphane

Signoff x86_64
-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] initscripts-2010.07-2 and wireless_tools-29-4

[Guillaume ALAUX]

On Sat, 2010-11-20 at 12:55 +0100, Pierre Schmitz wrote:
 Hi all,
 
 I rebuild both packages due to core cleanup/rebuild. I have also moved
 the file /etc/conf.d/wireless from wireless_tools to initscripts, where
 it really belongs. Future versions of initscripts might remove support
 for wireless/network then.
 
 Please sign off,
 
 Pierre
 

Signoff x86_64 for both packages.

-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] procps 3.2.8-2

[Guillaume ALAUX]

On Fri, 2010-11-19 at 23:00 -0500, Eric Bélanger wrote:
 Hi,
 
 
 I've applied several patches from Red Hat to fix misc bugs.  The bug #
 referred below are for the Red Hat bug tracker unless otherwise
 specified. Please test and signoff.
 
 *** Fixed/ updated man pages. Close Arch bug: FS#18623 - [procps]
 3.2.8-1 man page lacks indentation
 
 - top man page isn't formatted properly with groff 1.20.1
 groff-top-manpage.patch
 
 # '-l' option of 'free' documented
 procps-3.2.7-free-hlmem.patch
 
 #435453 - errors with man -t formatting of ps man page
 procps-3.2.7-ps-man-fmt.patch
 
 #244960 - ps manpage formatted incorrectly
 procps-3.2.7-psman.patch
 
 #296471 - update top man page
 procps-3.2.7-top-manpage.patch
 
 *** Applied several patches to fix CPU handling in top. Close Arch
 bug: FS#21461 - [procps] top: failed /proc/stat read
 
 #185994 - error when using Single Cpu = Off option
 procps-3.2.7-top-cpu0.patch
 
 # 174619 - workaround for reliable Cpu(s) data in the first loop
 procps-3.2.7-top-env-cpuloop.patch
 
 # 186017 - Top Cpu0 line never updates on single processor machine
 procps-3.2.7-top-remcpu.patch
 
 *** Misc bug fixes
 
 # 134516 - ps ignores /proc/#/cmdline if contents 2047 bytes
 procps-3.2.7-longcmd.patch
 
 #475963: slabtop -o should display the info once
 procps-3.2.7-slabtop-once.patch
 
 #440694 - strange text after selecting few field
 procps-3.2.7-top-clrscr.patch
 
 # 140975 - top corrupts screen when sorting on first column
 procps-3.2.7-top-sorthigh.patch
 
 # 183029 - watch ignores unicode characters
 procps-3.2.7-watch-unicode.patch
 
 # 234546 - 'w' doesn't give correct information about what's being run.
 procps-3.2.7-w-best.patch
 
 #548711 -  [abrt] crash in procps-3.2.8-3.fc12
 procps-3.2.8-setlocale.patch
 
 # bug in showing threads fixed
 procps-3.2.8-threads.patch

Signoff x86_64

-- 
Guillaume


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] [signoff] dialog-1.1_20100428-2

[Guillaume ALAUX]

On 6 October 2010 16:27, Allan McRae al...@archlinux.org wrote:
 Include C developmental headers and library (FS#21033)

 Signoff both,
 Allan


I have just played a bit with some options but everything seems to be all right.

Signoff x86_64

--
Guillaume

Re: [arch-dev-public] [signoff] logrotate-3.7.9-1

[Guillaume ALAUX]

On 30 September 2010 17:44, Allan McRae al...@archlinux.org wrote:
 Upstream update.

 Signoff both,
 Allan.


Signoff x86_64

--
Guillaume

Re: [arch-dev-public] Putting the process of adding new mirrors on hold

[Guillaume ALAUX]

On 30 September 2010 11:41, Roman Kyrylych roman.kyryl...@gmail.com wrote:
 Currently we have almost 90 active mirrors in the official mirror list
 and new requests for becoming an official mirror are appearing quite often.
 However, not all mirrors are good ones (outdated, incomplete, admins
 don't respond, etc).
 I marked inactive many of them during past months (including about 20
 during FrOSCon),
 and will continue to do this until all of the mirrors meet the requirements.

 22 mirrors that are in the official list did not move to the 2-tier scheme 
 yet,
 which means we do not know where do they sync from,
 admins did not respond or there is no known email address of the admin.
 These will be removed from the list very soon.
 If you are using some mirror that was removed from the list recently
 and you know how to contact the admin - let me know.

 Considering the fact that there is no package signing support yet
 I don't see a reason why we should have that many mirrors,
 especially when they don't meet the requirements.

 Recently I had to defer some requests to become an official mirror
 from some private sites. I apologize that this caused a frustration of
 their admins
 and hope that the reasons are understandable.

 To make this fair to everyone I'm thinking about (temporary) putting
 the process of adding new mirrors on hold.

 --
 Roman Kyrylych (Роман Кирилич)


Hi Roman,

On the mirrors list page [1] I see 56 untiered mirrors. May we
know which are the 22 you mention?
Just say so if you would like some help trying to get in touch with
some mirror admins.

For instance I see these French or Belgian mirrors :
These 2 were removed from the mirrorlist
  -ftp.belnet.be
  -ftp.free.fr

And this one is 3 weeks old and untiered:
  -mir1.archlinux.fr

I could try to mail them in French...

[1] http://www.archlinux.org/mirrors/

--
Guillaume

Re: [arch-dev-public] [signoff] tzdata 2010m-1

[Guillaume ALAUX]

On 28 September 2010 19:36, Andreas Radke a.ra...@arcor.de wrote:
 New timezone pkg upstream release. Please signoff.

 -Andy

 Changes:

 The files...
        ftp://elsie.nci.nih.gov/pub/tzcode2010m.tar.gz
 ...and...
        ftp://elsie.nci.nih.gov/pub/tzdata2010m.tar.gz
 ...are now available; these reflect the Hong Kong, Vostok, and zic.c
 changes circulated recently on the time zone mailing list.

                                --ado


Hi Andreas,

Signoff x86_64

--
Guillaume

Re: [arch-dev-public] [signoff] man-pages 3.27-1

[Guillaume ALAUX]

On 28 September 2010 19:04, Andreas Radke a.ra...@arcor.de wrote:
 Upstream update. Please signoff (any arch).

 -Andy

  Changes in man-pages-3.27 

 Released: 2010-09-22, Nuernberg


 Contributors
 

 The following people contributed notes, ideas, or patches that have
 been incorporated in changes in this release:

 caishux...@gmail.com
 Denis Barbier bou...@gmail.com
 Denis Silakov sila...@ispras.ru
 der Mouse mo...@rodents-montreal.org
 Jan Kratochvil  jan.kratoch...@redhat.com
 Jim Belton jim.bel...@gmail.com
 Jiri Olsa jo...@redhat.com
 KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
 Mark Hills m...@pogo.org.uk
 Matthew Flaschen matthew.flasc...@gatech.edu
 Michael Kerrisk mtk.manpa...@gmail.com
 Ozgur Gurcan ozgur.gur...@lpp.polytechnique.fr
 Petr Baudis pa...@suse.cz
 Remi Denis-Courmont r...@remlab.net
 Tanaka Akira a...@fsij.org
 Tim Stoakes t...@stoakes.net
 W. Trevor King wk...@drexel.edu
 Yuri Kozlov yu...@komyakino.ru

 Apologies if I missed anyone!


 New and rewritten pages
 ---

 sigevent.7
    Petr Baudis, Michael Kerrisk
        New page to centralize description of sigevent structure
            Several interfaces use this structure. Best to centralize
 the common details in one place. Content taken from the existing
            timerfd_create.2 and mq_open.3 pages, with additions by
            Petr Baudis and Michael Kerrisk.


 Newly documented interfaces in existing pages
 -


 Global changes
 --

 _exit.2
 brk.2
 chdir.2
 chmod.2
 chown.2
 chroot.2
 clock_nanosleep.2
 getdtablesize.2
 gethostname.2
 getpagesize.2
 getsid.2
 killpg.2
 mknod.2
 mknodat.2
 posix_fadvise.2
 pread.2
 readlink.2
 setpgid.2
 setpgid.2
 setreuid.2
 sigaltstack.2
 stat.2
 symlink.2
 sync.2
 truncate.2
 vfork.2
 wait.2
 wait4.2
 a64l.3
 abs.3
 acos.3
 acosh.3
 asin.3
 asinh.3
 atan.3
 atan2.3
 atanh.3
 atoi.3
 cbrt.3
 ceil.3
 clock_getcpuclockid.3
 copysign.3
 cos.3
 cosh.3
 dirfd.3
 div.3
 dprintf.3
 ecvt.3
 erf.3
 erfc.3
 exp.3
 exp2.3
 expm1.3
 fabs.3
 fdim.3
 fexecve.3
 ffs.3
 floor.3
 fma.3
 fmax.3
 fmemopen.3
 fmin.3
 fmod.3
 fpclassify.3
 frexp.3
 fwide.3
 gamma.3
 gcvt.3
 getcwd.3
 getdate.3
 getgrent.3
 gethostid.3
 getpass.3
 getpwent.3
 getsubopt.3
 getw.3
 hypot.3
 ilogb.3
 insque.3
 isalpha.3
 isgreater.3
 iswblank.3
 j0.3
 j0.3
 ldexp.3
 lockf.3
 log.3
 log10.3
 log1p.3
 log2.3
 logb.3
 lrint.3
 lround.3
 mbsnrtowcs.3
 mkdtemp.3
 mkstemp.3
 mktemp.3
 modf.3
 mq_receive.3
 mq_send.3
 nan.3
 nextafter.3
 posix_fallocate.3
 posix_memalign.3
 pow.3
 printf.3
 qecvt.3
 random.3
 realpath.3
 remainder.3
 remquo.3
 rint.3
 rint.3
 round.3
 scalb.3
 scalbln.3
 scanf.3
 siginterrupt.3
 signbit.3
 sigset.3
 sin.3
 sinh.3
 sqrt.3
 stpcpy.3
 stpncpy.3
 strdup.3
 strdup.3
 strnlen.3
 strsignal.3
 strtod.3
 strtol.3
 strtoul.3
 tan.3
 tanh.3
 tgamma.3
 trunc.3
 ttyslot.3
 ualarm.3
 usleep.3
 wcpcpy.3
 wcpncpy.3
 wcscasecmp.3
 wcsdup.3
 wcsncasecmp.3
 wcsnlen.3
 wcsnrtombs.3
 wprintf.3
    Michael Kerrisk
        Add/fix/update feature test macro requirements in SYNOPSIS
            Various changes to:
            * Update feature test requirements to note changes in
              recent glibc releases
            * Correct errors in feature test macro requirements
            * Add feature test macro requirements to pages where
              the requirements were not previously stated.

 accept.2
 clone.2
 dup.2
 fallocate.2
 pipe.2
 readahead.2
 sched_setaffinity.2
 unshare.2
 CPU_SET.3
 endian.3
 euidaccess.3
 fexecve.3
 getpt.3
 getpw.3
 getumask.3
 getutmp.3
 gnu_get_libc_version.3
 makedev.3
 matherr.3
 mbsnrtowcs.3
 memfrob.3
 pthread_attr_setaffinity_np.3
 pthread_getattr_np.3
 pthread_setaffinity_np.3
 pthread_tryjoin_np.3
 tcgetsid.3
 wcscasecmp.3
 wcsncasecmp.3
 wcsnlen.3
 wcsnrtombs.3
 wcswidth.3
 rtld-audit.7
    Michael Kerrisk
        SYNOPSIS: Add reference to feature_test_macros(7)
            These pages specify feature test macros in the function
            prototypes. Add a reference to feature_test_macros(7),
            so that readers are pointed to the information that
            feature test macros must be defined before including
            *any* header file.

 clock_nanosleep.2
 clock_getcpuclockid.3
 getnetent_r.3
 getprotoent_r.3
 getrpcent_r.3
 getservent_r.3
 sigwait.3
    Michael Kerrisk
        RETURN VALUE: Note that positive error numbers are listed in
 ERRORS

 fcntl.2
 intro.2
 open.2
 poll.2
 ftw.3
 intro.3
 matherr.3
 system.3
 tmpnam.3
 unix.7
    Michael Kerrisk
        Note that feature test macros must be defined before *any*
 includes Programmers often make the mistake of including a feature test
            macro only after having already included some header files.
            This patch adds some text at opportune places to remind
            programmers to do things the right way.

 index.3
 stpcpy.3
 strcasecmp.3
 strcat.3
 

Re: [arch-dev-public] [signoff] bzip2-1.0.6-1

[Guillaume ALAUX]

On 21 September 2010 14:31, Ionuț Bîru ib...@archlinux.org wrote:
 Hi,
 fixing https://bugs.archlinux.org/task/20901

 Changelog:

 Version 1.0.6 removes a potential security vulnerability, CVE-2010-0405, so
 all users are recommended to upgrade immediately.

 --
 Ionuț


Signoff 64

--
Guillaume

Re: [arch-dev-public] [signoff] mlocate-0.23.1-1

[Guillaume ALAUX]

On 21 September 2010 10:14, Gaetan Bisson bis...@archlinux.org wrote:
 signoff i686


Signoff 64

--
Guillaume

Re: [arch-dev-public] tcp_wrappers- does anyone actually use it?

[Guillaume ALAUX]

On 9 September 2010 19:39, Dan McGee dpmc...@gmail.com wrote:
 Guys,

 For the umpteenth time today I stared at ssh wondering why it wasn't
 accepting incoming connections until I remembered about tcp_wrappers
 junk, and put the standard sshd : ALL : allow line in hosts.allow.

 Does anyone use this for anything useful at all?

 1. The package is now at version 7.6-12 (clearly it is getting a lot
 of upstream attention)
 2. We have 11 patches applied to the package
 3. It is inferior to iptables-based filtering
 4. It is not very transparent

 Discussion welcome, but I am raising a vote to remove this dependency
 from packages currently using it (hopefully this is possible for all
 21 of them, http://www.archlinux.org/packages/core/x86_64/tcp_wrappers/)
 and eventually remove it from core and the repositories.

 -Dan

Well, I must say it gave me headaches several times especially when
trying to figure out how to get openldap (and sshd) to work!
 4. It is not very transparent
+1

FYI it looks like we use the ipv4 only version whereas there is the
ipv6-enabled :
ftp://ftp.porcupine.org/pub/security/index.html
ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz
ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6-ipv6.4.tar.gz

So we are not even up to date nor ipv6-compatible !

Adding your other comments, I would vote for a removal of the
dependencies. Maybe we can still keep the package in our repos in case
someone explicitly want to use it (in that case we could provide de
ipv6 version too).

--
Guillaume

Re: [arch-dev-public] tcp_wrappers- does anyone actually use it?

[Guillaume ALAUX]

On 10 September 2010 14:38, Dan McGee dpmc...@gmail.com wrote:
 On Fri, Sep 10, 2010 at 2:12 AM, Guillaume ALAUX
 guilla...@archlinux.org wrote:
 On 9 September 2010 19:39, Dan McGee dpmc...@gmail.com wrote:
 Guys,

 For the umpteenth time today I stared at ssh wondering why it wasn't
 accepting incoming connections until I remembered about tcp_wrappers
 junk, and put the standard sshd : ALL : allow line in hosts.allow.

 Does anyone use this for anything useful at all?

 1. The package is now at version 7.6-12 (clearly it is getting a lot
 of upstream attention)
 2. We have 11 patches applied to the package
 3. It is inferior to iptables-based filtering
 4. It is not very transparent

 Discussion welcome, but I am raising a vote to remove this dependency
 from packages currently using it (hopefully this is possible for all
 21 of them, http://www.archlinux.org/packages/core/x86_64/tcp_wrappers/)
 and eventually remove it from core and the repositories.

 -Dan

 Well, I must say it gave me headaches several times especially when
 trying to figure out how to get openldap (and sshd) to work!
 4. It is not very transparent
 +1

 FYI it looks like we use the ipv4 only version whereas there is the
 ipv6-enabled :
 ftp://ftp.porcupine.org/pub/security/index.html
 ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz
 ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6-ipv6.4.tar.gz

 So we are not even up to date nor ipv6-compatible !

 Adding your other comments, I would vote for a removal of the
 dependencies. Maybe we can still keep the package in our repos in case
 someone explicitly want to use it (in that case we could provide de
 ipv6 version too).

 The last updated added the ipv6 patch, so you might want to check your words.

 Keeping the package in the repos does no good; it is a shared library
 that is most often linked in at compile-time so it needs to be present
 if compiled in, and if not, it won't even be looked at.

 -Dan


 The last updated added the ipv6 patch, so you might want to check your words.
Right! My bad.

--
Guillaume

Re: [arch-dev-public] [signoff] sudo-1.7.4.p4

[Guillaume ALAUX]

On 9 September 2010 07:30, Allan McRae al...@archlinux.org wrote:
 Upstream security fix release:

 This release fixes a security issue with respect to the handling
 of sudo's -g command line option when -u is also specified.  The
 flaw may allow an attacker to run commands as a user that is not
 authorized by the sudoers file.  For more details, see:
    http://www.sudo.ws/sudo/alerts/runas_group.html

 Some quick signoffs would be good...

 Signoff both,
 Allan

signoff i686

--
Guillaume


--
Guillaume

Re: [arch-dev-public] [signoff] man-pages 3.26-1

[Guillaume ALAUX]

On 7 September 2010 21:31, Andreas Radke a.ra...@arcor.de wrote:
 Upstream update + include again some section 2 pages that were part of
 module-init-tools in the past. Fixes #20645.

 -Andy

  Changes in man-pages-3.26 

 Released: 2010-09-04, Munich


 Contributors
 

 The following people contributed notes, ideas, or patches that have
 been incorporated in changes in this release:

 Alexander Shishkin virtu...@slind.org
 Brian Sutin brian.su...@hs.utc.com
 Denis Barbier bou...@gmail.com
 Guillem Jover guil...@hadrons.org
 Jianhua Li jhl...@gmail.com
 Linus Nilsson lajn...@gmail.com
 Lenaic Huard lenaic.hu...@laposte.net
 m...@mcrowe.com
 Martin Schulze j...@infodrom.org
 Maxin John maxin.j...@gmail.com
 Michael Kerrisk mtk.manpa...@gmail.com
 Nicholas Hunt nh...@cs.washington.edu
 Peng Haitao pen...@cn.fujitsu.com
 Peter Stuge pe...@stuge.se
 Przemyslaw Szczepaniak przemyslaw.szczepan...@imgtec.com
 Scott Walls sawa...@umich.edu
 TAN Yee Fan tanye...@comp.nus.edu.sg
 Wu Fengguang fengguang...@intel.com
 Yitzchak Gale g...@sefer.org
 Yuri Kozlov yu...@komyakino.ru

 Apologies if I missed anyone!

 Newly documented interfaces in existing pages
 -

 eventfd.2
    Michael Kerrisk
        Document EFD_SEMAPHORE
            Document the EFD_SEMAPHORE flag, added in kernel 2.6.30.
            Also restructured some parts of the text to fit with the
            addition of the EFD_SEMAPHORE text.


 Global changes
 --

 getaddrinfo.3
 getipnodebyname.3
 st.4
    Michael Kerrisk
        s/logical OR/bitwise OR/


 Changes to individual pages
 ---

 clock_nanosleep.2
    Michael Kerrisk
        Fix discussion of return value when interrupted by a signal

 epoll_ctl.2
    Yuri Kozlov
        Small fix to types in data structures

 eventfd.2
    Alexander Shishkin
        Clarified close-on-exec behavior

 madvise.2
    Michael Kerrisk
        Improve discussion of MADV_SOFT_OFFLINE

 mkdir.2
    Michael Kerrisk
        Add EMLINK error to ERRORS

 mq_getsetattr.2
 mq_close.3
 mq_getattr.3
 mq_notify.3
 mq_send.3
 mq_unlink.3
    Lnac Huard
        Fix return type in SYNOPSIS (s/mqd_t/int/)

 recv.2
 send.2
    Michael Kerrisk
        Remove obsolete reference to glibc version in NOTES

 recv.2
 send.2
    Nicholas Hunt
        Adjust type shown for msg_controllen to glibc reality
            This patch fixes the type of msg_controllen in the struct
 msghdr definition given in send.2 and recv.2 to match the definition in
            glibc and the kernel.

 select.2
    Michael Kerrisk
        Update NOTES on old glibc pselect()
            Make it clear that modern glibc uses the kernel pselect()
            on systems where it is available.
            See https://bugzilla.kernel.org/show_bug.cgi?id=14411

 statfs.2
    Guillem Jover
        Fix copy  paste error for __SWORD_TYPE definition

 sysfs.2
    Michael Kerrisk
        Clarify that this syscall is obsolete.
            And strengthen recommendation to use /proc/filesystems
 instead.

 write.2
    Michael Kerrisk
        Add EDESTADDRREQ error

 a64l.3
    Peng Haitao
        Fix error in NOTES, s/a64l/l64a/

 error.3
    Linus Nilsson
        Change perror to strerror in DESCRIPTION of error()

 mq_send.3
    Michael Kerrisk
        Fix EAGAIN description (s/empty/full)

 initrd.4
    Yuri Kozlov
        Fix IP address in explanation of NFS example

 tzfile.5
    Michael Kerrisk
        Add information on version 2 format timezone files
            Updated using information from the tzcode 2010l release at
            ftp://elsie.nci.nih.gov/pub.
            (It's an open question whether or not a version of tzfile.5
            should live independently in man-pages. It was added to the
            man-pages set many years ago. For now, I'll follow a
            conservative course that causes least pain to downstream,
            by continuing to maintain a separate copy in man-pages.)

            See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594219


Signoff i686
I also confirm #20645 is fixed here

--
Guillaume

Re: [arch-dev-public] [signoff] udev-162-1

[Guillaume ALAUX]

On 8 September 2010 10:02, Tobias Powalowski t.p...@gmx.de wrote:
 Am Montag 06 September 2010 schrieb Thomas Bächler:
 Am 05.09.2010 11:05, schrieb Tobias Powalowski:
  Hi guys,
  udev 16
  
  Bugfixes.
 
  greetings
  tpowa

 Signoff 64.
 anyone else i686?

 --
 Tobias Powalowski
 Archlinux Developer  Package Maintainer (tpowa)
 http://www.archlinux.org
 tp...@archlinux.org


Sorry I thought I had already done it

signoff i686

--
Guillaume

Re: [arch-dev-public] [arch-general] [signoff] openvpn 2.1.3-1

[Guillaume ALAUX]

On 7 September 2010 23:13, Florian Pritz bluew...@server-speed.net wrote:
 On 06.09.2010 08:36, Thomas Bächler wrote:
 Upstream update, please sign off.


 i686 signoff

 --
 Florian Pritz -- {flo,bluewi...@server-speed.net



And signoff x86_64 !

--
Guillaume