Re: [arch-dev-public] News draft: libtraceevent>=5.9-1 update requires manual intervention

[Jan Alexander Steffens via arch-dev-public]

On Mon, Oct 26, 2020 at 2:16 PM Sébastien Luttringer  wrote:
> On Sat, 2020-10-24 at 23:27 +0200, Sébastien Luttringer wrote:
> >
> > Sure, I didn't know that rule. It's written somewhere or well known habit?
> >
> Jan?

Sorry; I don't think it's written down anywhere; it's just what
I did last time. It helps us (and users of [*testing], who are
encouraged to subscribe to arch-dev-public) make sure that the
draft is actually correct.

Re: [arch-dev-public] News draft: libtraceevent>=5.9-1 update requires manual intervention

[Jan Alexander Steffens via arch-dev-public]

On Wed, Oct 21, 2020 at 3:20 AM Sébastien Luttringer via
arch-dev-public  wrote:
>
> The libtraceevent package prior to version 5.9-1 was missing
> a soname link. This has been fixed in 5.9-1, so the upgrade will
> need to overwrite the untracked files created by ldconfig. If you get any
> of these errors
>
> libtraceevent: /usr/lib/libtraceevent.so.1 exists in filesystem
>
> when updating, use
>
> pacman -Syu --overwrite usr/lib/libtraceevent.so.1
>
> to perform the upgrade.
>
>
> Sébastien "Seblu" Luttringer

Was libtraceevent 5.9 never in [community-testing]?

Next time, please release the affected package to [*testing] together
with the draft.

Re: [arch-dev-public] Autumn extra cleaning

[Jan Alexander Steffens via arch-dev-public]

On Tue, Oct 6, 2020 at 8:34 PM Morten Linderud via arch-dev-public
 wrote:
> - libnice:
> heftig: gst-plugins-bad-libs, gst-plugin-opencv, gst-plugins-bad
> - shared-color-targets:
> heftig: gnome-color-manager

Adopted.

Re: [arch-dev-public] Autumn extra cleaning

[Jan Alexander Steffens via arch-dev-public]

On Mon, Oct 5, 2020, 07:16 Sven-Hendrik Haase via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> adwaita-icon-theme (Jan can you just take this?)

graphene
> gstreamer
> gtksourceview4
> gupnp-igd
> libnma


Adopted.

[arch-dev-public] News draft: ghostpcl>=9.53.2-2 and ghostxps>=9.53.2-2 updates require manual intervention

[Jan Alexander Steffens via arch-dev-public]

The ghostpcl and ghostxps packages prior to version 9.53.2-2 were missing
a soname link each. This has been fixed in 9.53.2-2, so the upgrade will
need to overwrite the untracked files created by ldconfig. If you get any
of these errors

ghostpcl: /usr/lib/libgpcl6.so.9 exists in filesystem
ghostxps: /usr/lib/libgxps.so.9 exists in filesystem

when updating, use

pacman -Syu --overwrite /usr/lib/libgpcl6.so.9,/usr/lib/libgxps.so.9

to perform the upgrade.

[arch-dev-public] [PATCH 2/2] makepkg.conf: Update our default FLAGS

[Jan Alexander Steffens (heftig) via arch-dev-public]

From: "Jan Alexander Steffens (heftig)" 

I recently read [Fedora's documentation on build flags][1] and I think
they have some useful ideas.

1. Move -D_FORTIFY_SOURCE=2 from CPPFLAGS to CFLAGS using -Wp:
   Unfortunately, there are still build systems (e.g. CMake, homegrown
   Makefile rules) which use CFLAGS but not CPPFLAGS. Ultimately, we can
   cover more code with this workaround.

2. -fexceptions:
   Slight hardening of C programs making use of automatic variable
   cleanup or pthread_cancel. Cost should be negligible.

3. -fstack-clash-protection:
   Hardening of large stack allocations. Cost should be negigible.

   We need to patch clang to ignore this, like we once did for -fno-plt.

4. -fcf-protection:
   Hardening which makes code compatible with Intel CET. Increases code
   size a bit but cost should be negligible.

   No processors supporting it are available yet, but the linker only
   marks binaries for CET when all code is compatible, so we could get a
   head-start on this.

5. -fasynchronous-unwind-tables:
   Generates DWARF unwinding information that doesn't get stripped.
   Increases binary size a bit.

   Should make sure tools like perf and gdb can unwind the stack
   completely even without debug symbols. This makes the debugger more
   useful if you only have debug symbols for some frames, since frames
   without symbols can no longer break unwinding.

6. -Wp,-D_GLIBCXX_ASSERTIONS:
   Enables some assertions in libstdc++. Hardening similar to
   _FORTIFY_SOURCE.

7. -grecord-gcc-switches:
   Useful information to record. But since we don't use `debug` yet,
   won't affect us much.

[1]: 
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md
---
 PKGBUILD |  2 +-
 makepkg.conf | 12 +++-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/PKGBUILD b/PKGBUILD
index 846a970..ed1d492 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -27,7 +27,7 @@ 
source=(https://sources.archlinux.org/other/pacman/$pkgname-$pkgver.tar.gz{,.sig
 sha256sums=('bb201a9f2fb53c28d011f661d50028efce6eef2c1d2a36728bdd0130189349a0'
 'SKIP'
 '3353f363088c73f1f86a890547c0f87c7473e5caf43bbbc768c2e9a7397f2aa2'
-'d113252f97f019a13541237a4f4c7fbe9ffd0c3e71ecd7cd8d5d227b378819ab')
+'3818559af64c11d9cda127ae75e48e5f8780bbe71513f5a3c484c38eb16a2b71')
 
 
 build() {
diff --git a/makepkg.conf b/makepkg.conf
index a277503..c8c917e 100644
--- a/makepkg.conf
+++ b/makepkg.conf
@@ -36,16 +36,18 @@ CARCH="x86_64"
 CHOST="x86_64-pc-linux-gnu"
 
 #-- Compiler and Linker Flags
-CPPFLAGS="-D_FORTIFY_SOURCE=2"
-CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
-CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
+#CPPFLAGS=""
+CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
+-fstack-clash-protection -fcf-protection -fasynchronous-unwind-tables \
+-Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS"
+CXXFLAGS="$CFLAGS"
 LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
 #RUSTFLAGS="-C opt-level=2"
 #-- Make Flags: change this for DistCC/SMP systems
 #MAKEFLAGS="-j2"
 #-- Debugging flags
-DEBUG_CFLAGS="-g -fvar-tracking-assignments"
-DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
+DEBUG_CFLAGS="-g -grecord-gcc-switches -fvar-tracking-assignments"
+DEBUG_CXXFLAGS="-g -grecord-gcc-switches -fvar-tracking-assignments"
 #DEBUG_RUSTFLAGS="-C debuginfo=2"
 
 #
-- 
2.27.0

[arch-dev-public] [PATCH 1/2] makepkg.conf: Change default compression to .zst (fast)

[Jan Alexander Steffens (heftig) via arch-dev-public]

From: "Jan Alexander Steffens (heftig)" 

Most people create packages from the AUR for local installation. This
allows these packages to be created more quickly.
---
 PKGBUILD | 2 +-
 makepkg.conf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/PKGBUILD b/PKGBUILD
index 8566270..846a970 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -27,7 +27,7 @@ 
source=(https://sources.archlinux.org/other/pacman/$pkgname-$pkgver.tar.gz{,.sig
 sha256sums=('bb201a9f2fb53c28d011f661d50028efce6eef2c1d2a36728bdd0130189349a0'
 'SKIP'
 '3353f363088c73f1f86a890547c0f87c7473e5caf43bbbc768c2e9a7397f2aa2'
-'9c769f13c09a6f24c393a9762474eded2f269d8966e7764d9160d62232a7919b')
+'d113252f97f019a13541237a4f4c7fbe9ffd0c3e71ecd7cd8d5d227b378819ab')
 
 
 build() {
diff --git a/makepkg.conf b/makepkg.conf
index d8bf59e..a277503 100644
--- a/makepkg.conf
+++ b/makepkg.conf
@@ -132,7 +132,7 @@ DBGSRCDIR="/usr/src/debug"
 COMPRESSGZ=(gzip -c -f -n)
 COMPRESSBZ2=(bzip2 -c -f)
 COMPRESSXZ=(xz -c -z -)
-COMPRESSZST=(zstd -c -z -q -)
+COMPRESSZST=(zstd -c -T0 -)
 COMPRESSLRZ=(lrzip -q)
 COMPRESSLZO=(lzop -q)
 COMPRESSZ=(compress -c -f)
-- 
2.27.0

Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages

[Jan de Groot]

Andreas Radke via arch-dev-public schreef op 2020-06-26 08:39:

We have to choose if we want simple

makedepends=('xorg-font-utils') or
makedepends=('xorg-mkfontscale' 'xorg-bdftopcf' 'xorg-font-util')

Sure we can drop the meta package "xorg-font-utils" entirely but it
simply covers all possible makedependencies to simplify packagers life.
We should add another ToDo list to either fully remove the
metapackage if we agree to do so or at least move it to a
makedependency. Check all those packages that still depend on it at
runtime probably all wrong:
https://www.archlinux.org/packages/extra/any/xorg-font-utils/


The description says "transitional". The reason it exists is because it 
used to contain all utils it depends on. Since we have way too many font 
packages in the repository that depend on it, we decided to make a 
transitional package, which would get deleted some day when no fonts 
depend on it anymore.


Please kill it together with this change.

Re: [arch-dev-public] Reproducible builds progress report #3

[Jan Alexander Steffens via arch-dev-public]

On Sat, May 30, 2020 at 11:09 PM Jelle van der Waa  wrote:

> I would recommend everyone to stop using gitlab to pull patches as the
> output of the patches changes over time due to the encoding of the git
> version number. So it's best to just svn add those, Github does not have
> this issue.
>

In case anyone didn't know, you can also add `.patch` to the URL of a
GitLab MR or a GitHub PR. This gives you the entire series of patches as a
single file. Of course, you should still add the file to SVN.

Re: [arch-dev-public] Dropping pangox-compat

[Jan Alexander Steffens via arch-dev-public]

Sounds good; thanks!

On Tue, Apr 28, 2020 at 4:17 PM Jan de Groot  wrote:

> Hello,
>
> I would like to drop pangox-compat. Reasons:
> 1. it does not compile with pango 1.44
> 2. the current compiled package links fine, but does not render any text
> when used with pango 1.44
> 3. upstream has archived the source and doesn't support it anymore
> 4. People care about 1. but not about 2. -> library only exists because
> software links to it
>
> So far we have only a few packages depending on it:
> - gtkglext (direct dependency, gdk_gl_font_use_pango_font* functions,
> removed in git master)
> - gtkmathview (direct dependency, libraries linking to it not used by
> abiword)
> - gambas3-gb-gtk-opengl (pulled in through gtkglext, no further
> relations)
>
> Todo:
> - patch gtkglext to remove API depending on pangox-compat, already
> packaged, not uploaded yet
> - drop gtkmathview parts that depend on pangox-compat (Abiword needs the
> libxml2 module, nothing else)
> - rebuild gambas3 (is in staging for ICU rebuild now)
>
> Any objections?
>

[arch-dev-public] Dropping pangox-compat

[Jan de Groot]

Hello,

I would like to drop pangox-compat. Reasons:
1. it does not compile with pango 1.44
2. the current compiled package links fine, but does not render any text 
when used with pango 1.44

3. upstream has archived the source and doesn't support it anymore
4. People care about 1. but not about 2. -> library only exists because 
software links to it


So far we have only a few packages depending on it:
- gtkglext (direct dependency, gdk_gl_font_use_pango_font* functions, 
removed in git master)
- gtkmathview (direct dependency, libraries linking to it not used by 
abiword)
- gambas3-gb-gtk-opengl (pulled in through gtkglext, no further 
relations)


Todo:
- patch gtkglext to remove API depending on pangox-compat, already 
packaged, not uploaded yet
- drop gtkmathview parts that depend on pangox-compat (Abiword needs the 
libxml2 module, nothing else)

- rebuild gambas3 (is in staging for ICU rebuild now)

Any objections?

[arch-dev-public] News draft: nss>=3.51.1-1 and lib32-nss>=3.51.1-1 updates require manual intervention

[Jan Alexander Steffens via arch-dev-public]

The nss and lib32-nss packages prior to version 3.51.1-1 were missing a
soname link each. This has been fixed in 3.51.1-1, so the upgrade will need
to overwrite the untracked files created by ldconfig. If you get any of
these errors

nss: /usr/lib/p11-kit-trust.so exists in filesystem
lib32-nss: /usr/lib32/p11-kit-trust.so exists in filesystem

when updating, use

pacman -Syu --overwrite /usr/lib\*/p11-kit-trust.so

to perform the upgrade.

Re: [arch-dev-public] Proposal to remove PyGTK

[Jan de Groot]

Balló György via arch-dev-public schreef op 2020-03-13 10:56:

Hi all,

I would propose to remove PyGTK from the official repositories. PyGTK
was used to create GTK2 applications in python2. It's deprecated and
unmaintained since 2011 in favor of PyGObject, and does not receive any
fixes since then.

 ...


Any objections?



We can't keep supporting unmaintained software for ages. Pygtk is one of 
those projects that keeps python2 in our repos, so I think it's best to 
update/patch projects to a version that uses PyGobject and remove 
features or drop the remaining packages that still depend on pygtk.


Go for it!

[arch-dev-public] News draft: firewalld>=0.8.1-2 update requires manual intervention

[Jan Alexander Steffens via arch-dev-public]

The firewalld package prior to version 0.8.1-2 was missing the compiled
python modules. This has been fixed in 0.8.1-2, so the upgrade will need to
overwrite the untracked pyc files created. If you get errors like these

firewalld:
/usr/lib/python3.8/site-packages/firewall/__pycache__/__init__.cpython-38.pyc
exists in filesystem
firewalld:
/usr/lib/python3.8/site-packages/firewall/__pycache__/client.cpython-38.pyc
exists in filesystem
firewalld:
/usr/lib/python3.8/site-packages/firewall/__pycache__/dbus_utils.cpython-38.pyc
exists in filesystem
...many more...

when updating, use

pacman -Suy --overwrite /usr/lib/python3.8/site-packages/firewall/\*

to perform the upgrade.

Re: [arch-dev-public] libx11/xorgproto dependency

[Jan Alexander Steffens via arch-dev-public]

On Sat, Dec 21, 2019 at 12:42 PM David Runge  wrote:

> I'd go for b) as to me it seems the more correct approach (and doesn't
> require introducing further packages). Additionally, it is reflected in
> the package guidelines [1].
>

Unfortunately I think the guideline isn't very clear on what it means. It
is thus:

Build system of program A wants libraries B and C.
Library B depends on C.
You should add both B and C to A's depends.

But if the build system of program A wants only library B, you should not
add C to A's depends.

We now have many packages that want libx11 but say nothing about *proto,
yet they now need xorgproto as a makedepend.
Even worse, this extends further downstream, and packages building against
GTK now also need a makedepend on xorgproto.
I made a rough estimation and end up at ~3500 packages that are now broken.

Grepping for 'Requires:.*\wproto' through my local pkg-config files, these
packages directly reference a *proto and should have a dep on xorgproto:

libice
libx11
libxau
libxaw
libxcomposite
libxcursor
libxdamage
libxdmcp
libxext
libxfixes
libxfont2
libxft
libxi
libxinerama
libxkbfile
libxmu
libxrandr
libxrender
libxres
libxss
libxt
libxtst
libxv
libxxf86vm

Re: [arch-dev-public] libx11/xorgproto dependency

[Jan Alexander Steffens via arch-dev-public]

On Sat, Dec 21, 2019 at 12:18 PM Allan McRae via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> On 21/12/19 7:31 pm, Evangelos Foutras via arch-dev-public wrote:
> > Downstream consumers of libx11 shouldn't have to know and account for
> > libx11's headers/pkg-config files referencing xorgproto. A
> > libx11-devel package would depend on xorgproto. Since there's no
> > separate -devel package, the dependency stays with the regular libx11
> > package.
>
> This matches my opinion on the matter.
>

Ditto. (a) and (c) are the technically correct solutions, and I prefer (a).

Unless we want to start a distro-wide effort of splitting out -devel
packages, that is.

Re: [arch-dev-public] cleanup dead Xorg packages | news draft

[Jan Alexander Steffens via arch-dev-public]

On Thu, Dec 19, 2019, 23:35 Andreas Radke via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> when updating, use:
> `pacman -Rdd libdmx libxxf86dga && pacman -Syu`
>

Shouldn't we suggest -Rc instead of -Rdd here?

>

Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine

[Jan Alexander Steffens via arch-dev-public]

On Tue, Aug 13, 2019 at 9:04 AM Bartłomiej Piotrowski via arch-dev-public <
arch-dev-public@archlinux.org> wrote:
> I'd go with updating all packages to ship the converted files.
> Cluttering /usr with untracked files doesn't sound good.

Yeah, I agree. I think we should package convert_dict from the Chromium
sources as a new package to makedepend on.

Assuming that WebEngine will not be the only consumer of .bdic
dictionaries, how about putting them in /usr/share/bdic, and then either
patching sources to use that dir or linking whatever engine-specific
dictionaries there?

We could also put them with the other dictionaries into
/usr/share/hunspell, assuming that won't cause problems.

Re: [arch-dev-public] Drop ekiga?

[Jan de Groot]

On Fri, 2019-06-07 at 16:55 +0200, Sven-Hendrik Haase via arch-dev-
public wrote:
> Since I actually use it but don't care enough to start maintaining
> it, I'd
> appreciate it if you could try bumping it first and then drop it if
> that
> turns out to break other stuff.

I tried to bump Ekiga to git master, progress so far:
- needs "recent" (2016) versions of Opal and ptlib (2.16.3 prerelease
from git)
- current ptlib is patched for OpenSSL 1.1 support, upstream has no
support for 1.1 and is not planning to support it either (ticket closed
as notabug/wontfix)
- SSL code in ptlib has changed a lot, patch no longer applies,
applying by hand is not enough
- OpenSuSE has a patch which is half-finished and doesn't compile

Things are not looking good for Ekiga. I don't have any plans to revert
to OpenSSL 1.0 to get this working.

[arch-dev-public] Drop ekiga?

[jan]

Hello,

I would like to drop Ekiga. The software hasn't seen a release in years, the
git master branch has some active development now and then, but a release
for Ekiga5 is not near (though upstream stated the software itself is ready
enough to release v5 a year ago).

Alternative is to bump Ekiga to git master and hope it doesn't have too much
bugs.

Issue that gets fixed: one package less that depends on gconf
Issue that remains: Ekiga still depends on deprecated and unmaintained
versions of Opal/ptlib

Regards,
Jan de Groot

Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd

[Jan Alexander Steffens via arch-dev-public]

On Sun, Mar 24, 2019 at 7:35 PM Robin Broda via arch-dev-public
 wrote:
> The required changeset is, i think:
> PKGEXT='.pkg.tar.zst'
> COMPRESSZST=(zstd -c -T0 -18 -)

When we implement this, I would say we go with "zstd -c -T0 -" in
pacman's makepkg.conf and "zstd -C -T0 -18 -" in the configs shipped
with devtools.

I think users that build their own local packages are more likely to
benefit from fast compression. Anyone building with makechrootpkg for
distribution gets the high compression level.

Re: [arch-dev-public] rename lcms -> lcms1

[jan]

Christian Hesse schreef op 2018-09-14 21:18:

Hello everybody,

we have packages lcms (which provides lcms 1.x) and lcms2. The former 
is
flagged out-of-date every now and then for version 2.x... I would like 
to
rename the package to lcms1 with replace and provide for lcms. Any 
concerns?


I don't think we should rename. Kill the package instead. The software 
is unmaintained upstream and probably several security issues exist.


Most packages that still depend on lcms1 can be changed to lcms2 without 
patches. For packages that need patches, Debian has those and otherwise 
we should just remove the software together with lcms1.

[arch-dev-public] Remove CAcert root certs

[Jan Alexander Steffens via arch-dev-public]

Hi list,

I completely agree with https://bugs.archlinux.org/task/59690 and would
like to remove the ca-certificates-cacert package from our repos and our
default providers. The ca-certificates package will lose the depends and
gain a replaces and conflicts on -cacert.

Any objections?

Greetings,
Jan

[arch-dev-public] Raise default inotify limits

[Jan Alexander Steffens via arch-dev-public]

Hi list,

I would like to add a sysctl.d/10-arch.conf file to filesystem with the
following content:

# Raise inotify resource limits
fs.inotify.max_user_instances = 1024
fs.inotify.max_user_watches = 524288

To fix https://bugs.archlinux.org/task/47830 and other issues; e.g. "flow",
used for JS development, runs a cache daemon that silently malfunctions and
uses old source file content when it cannot create any more watches.

Any objections?

Greetings,
Jan

Re: [arch-dev-public] Removing 'orphan' python2 modules

[jan]

Jelle van der Waa schreef op 2018-06-27 21:35:

Hi All,

Our repository contains a lot of python2 modules which are required by
any package in the repository. I'd like to propose to remove these
modules pre-emptively since they serve no purpose and python2 is dead.
We should strive to be a modern distro, so promoting Python3 should be 
a

big part of it :)


Please reply if you have objections.

A list of modules / programs can be obtained as following or viewed 
here

[1]

$ pacman -Sqs python2 > list
$ expac -S '%n %N' -l ' ' - < list | awk NF==1

[1] http://pkgbuild.com/~jelle/python2_modules.txt


Python 2.7 is supported until 2020, that's 18 months from now. I agree 
that we should limit the orphaned python2 modules as much as possible, 
but please don't kill the ones that are built from a split package that 
also builds python3 packages. This would mean removing the python2 parts 
from the PKGBUILD, moving the python2 part to AUR and create a lot of 
duplicated effort when updating these packages.

[arch-dev-public] Replacing pkg-config with pkgconf

[Jan Alexander Steffens via arch-dev-public]

I want to replace pkg-config with pkgconf, an implementation that's
actively maintained.

https://github.com/pkgconf/pkgconf/

pkgconf is reportedly both faster and has saner behavior.

For example, right now `pkg-config --exists OpenEXR` fails if glu is not
installed, since OpenEXR has a "private" dependency on glu.
However, `pkg-config --libs OpenEXR` works since pkg-config ignores private
dependencies here.

Private dependencies are relevant for static linking, analogous to a shared
library's DT_NEEDED tags.
`pkg-config --static --libs OpenEXR` lists the libraries necessary to
statically link OpenEXR.

pkgconf is more consistent and follows private dependencies only if
--static is given, regardless of whether --libs or --exists is used.

pkgconf is in use by at least FreeBSD, NetBSD, Fedora and Mageia; so we
wouldn't be the first ones making the switch.

There's already a package in [community] owned by demize. I would make some
adjustments before releasing it to [testing].

Any objections?

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Jan Alexander Steffens via arch-dev-public]

On Sun, Mar 11, 2018 at 1:43 AM Eli Schwartz via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> While we are at it, someone has seen fit to create some arbitrary meson
> wrapper called "arch-meson" (note we have never shipped an arch-cmake
> nor an arch-configure, nor an arch-setup-py nor even an arch-make etc.),
> which aside for being somewhat magical also most certainly sets
> --buildtype release
>
> I distinctly remember this being something we do not want to support in
> makepkg due to us being fundamentally opposed to the end result where
> e.g. Debian packaging has magic in every which direction and you have to
> have a degree in Debian packaging plus go spelunking through addons
> provided by six or seven packages just to figure out how the actual
> build system for packages is being configured and run.
>

It's not magical. This doesn't even compare to dpkg-buildpackage's hooks
and buildsystem handling, which changes behavior drastically based on
what's installed and what the source tree looks like.

arch-meson is just a wrapper providing some defaults. You don't use the
wrapper, you don't get the defaults.

For that matter, I'm all for putting an arch-configure helper into our
autoconf package. I've had all kinds of issues because builds forgot to set
or mishandled some installation directory option from autoconf's general
set. We should avoid having to repeat the same options over and over.

I *know* that meson's buildtype=plain does the sane thing and delegates
> to the environment *FLAGS (or rather, the makepkg.conf *FLAGS and
> OPTIONS=(debug) if specified).
>

I did not use plain because meson handles languages other than C and C++.
Our FLAGS override the buildtype arguments anyway. We get the best of both
worlds.

We can move arch-meson's buildtype to debugoptimized as soon as we start
building debug packages.

Re: [arch-dev-public] Package group between repositories

[Jan Alexander Steffens via arch-dev-public]

On Thu, Jan 4, 2018 at 5:53 PM Balló György via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> Then if it's okay, I would like to add the following [community] packages
> to groups based on upstream sources:
> - gnome-boxes (gnome)
> - gnome-multi-writer (gnome-extra)
> - gnome-recipes (gnome-extra)
> - gnome-software (gnome)
> - parole (xfce4-goodies)
> - simple-scan (gnome)
>

Please don't add gnome-software to the gnome group, at least not without
removing packagekit support.

Re: [arch-dev-public] ImageMagick 7

[Jan Alexander Steffens via arch-dev-public]

On Sat, Dec 2, 2017 at 9:08 PM Antonio Rojas via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> El Sat, 02 Dec 2017 19:53:10 +, Jan Alexander Steffens via
> arch-dev-public escribió:
>
> > Hi list,
> >
> > if nobody objects I would like to start an upgrade to ImageMagick 7.
> >
> > The plan is:
> > - Split imagemagick into (libmagick imagemagick imagemagick-doc).
> > - Add imagemagick6, split into (libmagick6 imagemagick6). No docs.
> >
> > libmagick and libmagick6 contain the parallel-installable libraries.
> >
> > imagemagick and imagemagick6 conflict with each other, containing the
> > tools, the perl module and the conflicting build files.
> >
> > We'll need some rebuilds, of course.
> >
> > Thoughts?
>
> Will imagemagick6 (the tools) still be needed after we ship IM7? I'd
> rather not ship two versions of the tools if that's possible.
>

That's the question. I'm not even sure (but more confident) that we need
libmagick6. I have the complete set ready, but we can still drop the
packages that we later determine are not needed.

[arch-dev-public] ImageMagick 7

[Jan Alexander Steffens via arch-dev-public]

Hi list,

if nobody objects I would like to start an upgrade to ImageMagick 7.

The plan is:
- Split imagemagick into (libmagick imagemagick imagemagick-doc).
- Add imagemagick6, split into (libmagick6 imagemagick6). No docs.

libmagick and libmagick6 contain the parallel-installable libraries.

imagemagick and imagemagick6 conflict with each other, containing the
tools, the perl module and the conflicting build files.

We'll need some rebuilds, of course.

Thoughts?

Greetings,
Jan

Re: [arch-dev-public] Replace Gentoo mime-types with Fedora mailcap?

[Jan Alexander Steffens via arch-dev-public]

On Thu, Nov 23, 2017 at 1:23 AM Giancarlo Razzolini <
grazzol...@archlinux.org> wrote:

> Em novembro 22, 2017 17:24 Jan Alexander Steffens via arch-dev-public
> escreveu:
> > After seeing bug 54977[1] I've been investigating where our
> /etc/mime.types
> > comes from, and it's apparently from Gentoo[2] and hasn't been updated
> > since Oct 2012.
>
> I was not aware we had such old mime.types file. By the way, this .jpe bug
> always
> intrigued me, but no to the point of chasing it down.
>
> >
> > I would like to propose replacing mime-types with mailcap from Fedora[3],
> > which is still maintained; it fixes the above bug. It also provides
> > /etc/nginx/mime.types (conflicts with upstream NGINX, but defines many
> more
> > types) and /etc/mailcap (not used by anything we have?).
> >
> > Thoughts? Objections? Should we also use the mailcap NGINX mime.types?
>
> I'm not sure if NGINX mime.types has anything that is required for it to
> function
> properly. I can look into this, but if it doesn't, then both me and
> Bartłomiej, can
> strip upstream's on our respective packages. How does fedora handles it?
>

AFAICT Fedora ships the NGINX mime.types in a separate package that's part
of a dep chain involving the rest of NGINX. I already have packages ready
that remove the mime.types and add a dependency on mailcap.

[arch-dev-public] Replace Gentoo mime-types with Fedora mailcap?

[Jan Alexander Steffens via arch-dev-public]

After seeing bug 54977[1] I've been investigating where our /etc/mime.types
comes from, and it's apparently from Gentoo[2] and hasn't been updated
since Oct 2012.

I would like to propose replacing mime-types with mailcap from Fedora[3],
which is still maintained; it fixes the above bug. It also provides
/etc/nginx/mime.types (conflicts with upstream NGINX, but defines many more
types) and /etc/mailcap (not used by anything we have?).

Thoughts? Objections? Should we also use the mailcap NGINX mime.types?

[1]: https://bugs.archlinux.org/task/54977
[2]: https://packages.gentoo.org/packages/app-misc/mime-types
[3]: https://pagure.io/mailcap/tree/master

Re: [arch-dev-public] Drop sqlite2 and webkitgtk{,2}

[Jan Alexander Steffens via arch-dev-public]

On Sun, Jun 25, 2017 at 11:51 AM Balló György via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> I think we can drop sqlite2 and webkitgtk{,2} from the official
> repositories now.
>
> sqlite2 was replaced by sqlite 3. The last application which still use it
> is Freevo, which was last released in 2009, and is currently unmaintained.
>
> webkitgtk{,2} has many CVEs[1][2], and was replaced by webkit2gtk. The last
> application which still use it is GNUCash, which is still maintained by
> upstream, but unlikely to get ported to gtk3 soon, porting is not started
> yet.[3]
>

Oh, finally. Thanks for keeping track of this. It gets a big +1 from me.

[arch-dev-public] OpenSSL 1.0 - take 3

[jan]

Since moving on to OpenSSL 1.1 and introducing a compatibility package
openssl-1.0 (which isn't compatible), we still have FS#53836 [1] open.

 

I want to propose another openssl-1.0 rebuild that restores binary
compatibility with non-free software and Debian Jessie (jessie-backports) by
packaging OpenSSL 1.0.2 with 1.0.0 soname and 1.0.0 versioned symbols.

At this moment I don't care about an openssl-1.0.2 package that ships
libssl.so.1.0.2 like Debian does in unstable/testing at the moment, when
non-free software catches up with that we can introduce such a package
later.

 

Any objections? If not, let's make a new rebuild list and fix this.

Re: [arch-dev-public] Kernel 4.11 status

[Jan Alexander Steffens via arch-dev-public]

On Fri, May 5, 2017 at 8:29 AM Tobias Powalowski via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> Problematic with 4.11, license needs to be patched I don't think this is
> legal.
> http://rglinuxtech.com/?p=1935


We could patch the kernel to make the needed symbols non-GPL instead. That
at least sounds less problematic (IANAL).


> - vhba-module
>

Added a patch to trunk.


> Your opinion on pushing this to [testing].
>

Since I have an Optimus laptop, I'm interested in keeping the nvidia driver
functional...

Re: [arch-dev-public] Remaining TODO lists - Part 1: Packages with missing sources

[Jan Alexander Steffens via arch-dev-public]

On Sun, Mar 26, 2017 at 3:51 AM Allan McRae  wrote:

> The "Packages with missing sources" list [1] was created more than six
> months ago (2016-08-09).  These packages are either genuinely no longer
> have an upstream source, or are just sitting unmaintained in our repos.
>

I set 'archboot' to completed (it was building fine) and fixed the
'license' sources.

Re: [arch-dev-public] OpenSSL 1.1.0

[Jan de Groot]

On Thu, 2017-03-02 at 20:06 +0100, Lukas Fleischer wrote:
> On Thu, 02 Mar 2017 at 07:05:44, Lukas Fleischer wrote:
> > What is the plan for packages where upstream is dead or reluctant
> > to
> > migrate to OpenSSL 1.1.0 (see e.g. [1])? Are we going to ship a
> > legacy
> > openssl-compat (or libressl) package for a while?
> 
> It seems like there already is an openssl-1.0 package [1]. This makes
> everything much easier. Thanks.
> 
> [1] https://www.archlinux.org/packages/?q=openssl-1.0

To use this package you need to set PKG_CONFIG_PATH=/usr/lib/openssl-
1.0/pkgconfig. If your package doesn't use PKG_CONFIG_PATH to look for
openssl you'll have to manually add -I/usr/include/openssl-1.0 to
CFLAGS and -L/usr/lib/openssl-1.0 to LDFLAGS.

Also, make sure that your resulting package uses the correct library.
You don't want to link to two different versions of OpenSSL. An example
 where this happens is ptlib/opal, Opal will happily compile against
OpenSSL 1.1 while ptlib is compiled against 1.0 if no changes are made
to opal.

[arch-dev-public] Dropping cdrkit, replacing with cdrtools

[Jan de Groot]

Since we're dropping dead packages, I have one package remaining on the
"missing sources" todo list: cdrkit.

Given the fact that Debian has forked an old cdrtools release, applied
some patches and then abandoned the project completely, I would like to
remove it and replace it with the original software which is still
developed.

cdrtools is already in community, so it only needs a move to extra.
It's already a drop-in replacement for cdrkit, so we can handle the
dependencies later.

Last note: only thing that keeps me from moving this right now is the
maintenance. The current maintainer in community has maintained this
package for 5 years with regular updates and does a good job
maintaining his packages. It would be nice if he could continue
maintaining the package, but I think it's good to have mkisofs and
cdrecord in extra instead of community. Any thoughts about this?

Re: [arch-dev-public] Phasing out webkitgtk{,2}

[Jan Alexander Steffens via arch-dev-public]

On Wed, Jan 18, 2017 at 11:42 PM Jan Alexander Steffens <
jan.steff...@gmail.com> wrote:

> To protect our users we should try to limit the packages using
> webkitgtk(2)., with the goal of eventually getting rid of it completely. I
> propose making a TODO that covers all these packages, with the following
> policy:
>
>- If it can be updated to webkit2gtk, do so.
>- Otherwise, if WebKit is an optional dependency, build without it.
>- Otherwise, consider removing the package, especially if it's a
>browser.
>
> Fedora is working on this too (with a deadline in mid-March), so this bug
tree might be of interest:

https://bugzilla.redhat.com/showdependencytree.cgi?id=1375784

Re: [arch-dev-public] Phasing out gstreamer0.10

[jan]

Balló György via arch-dev-public schreef op 2017-01-19 02:18:

Beside to WebkitGTK+, GStreamer 0.10 is unmaintained too. [1] The last
release was in 2012. Most of the applications are already ported to
GStreamer 1. The last major user is wxGTK, but an upstream patch is
available for GStreamer 1 support. [2]

Currently the following packages depending on GStreamer 0.10:





[1]
https://lists.freedesktop.org/archives/gstreamer-announce/2013-March/000273.html
[2] https://github.com/wxWidgets/wxWidgets/pull/225


I'm already working on this. The upstream pull for wxwidgets is included 
in wxgtk 3.x in Debian and Fedora. I managed to backport this patch to 
wxgtk2.8 and wxpython2.8, so we could fix those if we want.

Re: [arch-dev-public] Phasing out gstreamer0.10

[Jan Alexander Steffens via arch-dev-public]

On Thu, Jan 19, 2017 at 2:18 AM Balló György via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> I think we could try to get rid from gstreamer0.10, so I propose to make a
> TODO for these packages, similar to webkitgtk:
>- If it can be updated to GStreamer 1, do so.
>- Otherwise, if GStreamer is an optional dependency, build without it.
>- Otherwise, consider removing the package.
>
> What do you think?
>

 Yeah, I agree.

There is other old Gnome cruft that I would love to get rid of, such as
gnome-vfs:
gnome-vfs
├─drivel
├─gnome-commander
├─gnome-vfs-perl
│ ├─gnome-perl
│ │ └─shutter
│ └─perlpanel
├─gnome-vfs-sharp
│ ├─gnome-sharp
│ │ └─monodevelop
│ │   └─monodevelop-debugger-gdb
│ └─libgnome-sharp
│   ├─gconf-sharp-peditors
│   │ └─gnome-sharp
│   ├─gnome-sharp
│   ├─lat
│   └─mono-tools
├─gnome-vfsmm
│ └─libgnomeuimm
│   └─gcdmaster
├─gobby
├─kompozer
│ ├─kompozer-i18n-ca
│ ├─kompozer-i18n-cs
│ ├─kompozer-i18n-da
│ ├─kompozer-i18n-de
│ ├─kompozer-i18n-eo
│ ├─kompozer-i18n-es-es
│ ├─kompozer-i18n-fi
│ ├─kompozer-i18n-fr
│ ├─kompozer-i18n-hsb
│ ├─kompozer-i18n-hu
│ ├─kompozer-i18n-it
│ ├─kompozer-i18n-ja
│ ├─kompozer-i18n-ko
│ ├─kompozer-i18n-lt
│ ├─kompozer-i18n-nl
│ ├─kompozer-i18n-pl
│ ├─kompozer-i18n-pt-br
│ ├─kompozer-i18n-pt-pt
│ ├─kompozer-i18n-ru
│ ├─kompozer-i18n-sl
│ ├─kompozer-i18n-uk
│ ├─kompozer-i18n-zh-cn
│ └─kompozer-i18n-zh-tw
├─libgnome
│ ├─cellwriter
│ ├─libbonoboui
│ │ ├─libgnomeui
│ │ │ ├─alleyoop
│ │ │ ├─etherape
│ │ │ ├─gnome-alsamixer
│ │ │ ├─gnome-commander
│ │ │ ├─gnome-hearts
│ │ │ ├─gnome-perl
│ │ │ ├─grip
│ │ │ ├─gtetrinet
│ │ │ ├─lablgtk2
│ │ │ ├─libgnome-sharp
│ │ │ ├─libgnomeuimm
│ │ │ ├─python2-egg
│ │ │ │ └─gnome-python-extras
│ │ │ ├─python2-libgnome
│ │ │ │ ├─gnome-python
│ │ │ │ │ └─gnome-python-desktop
│ │ │ │ └─soundconverter
│ │ │ └─vmoviedb
│ │ └─python2-bonobo
│ │   ├─gnome-python
│ │   └─python2-libgnome
│ ├─libgnomemm
│ │ └─libgnomeuimm
│ ├─netactview
│ └─stardict
└─python2-gnomevfs
  ├─gnome-python
  ├─python2-gnomedesktop
  │ └─gnome-python-desktop
  ├─python2-libgnome
  └─python2-totem-plparser
└─gnome-python-desktop


And orbit2:
orbit2
├─libbonobo
│ ├─gobby
│ ├─libgnome
│ │ ├─cellwriter
│ │ ├─libbonoboui
│ │ │ ├─libgnomeui
│ │ │ │ ├─alleyoop
│ │ │ │ ├─etherape
│ │ │ │ ├─gnome-alsamixer
│ │ │ │ ├─gnome-commander
│ │ │ │ ├─gnome-hearts
│ │ │ │ ├─gnome-perl
│ │ │ │ │ └─shutter
│ │ │ │ ├─grip
│ │ │ │ ├─gtetrinet
│ │ │ │ ├─lablgtk2
│ │ │ │ ├─libgnome-sharp
│ │ │ │ │ ├─gconf-sharp-peditors
│ │ │ │ │ │ └─gnome-sharp
│ │ │ │ │ │   └─monodevelop
│ │ │ │ │ │ └─monodevelop-debugger-gdb
│ │ │ │ │ ├─gnome-sharp
│ │ │ │ │ ├─lat
│ │ │ │ │ └─mono-tools
│ │ │ │ ├─libgnomeuimm
│ │ │ │ │ └─gcdmaster
│ │ │ │ ├─python2-egg
│ │ │ │ │ └─gnome-python-extras
│ │ │ │ ├─python2-libgnome
│ │ │ │ │ ├─gnome-python
│ │ │ │ │ │ └─gnome-python-desktop
│ │ │ │ │ └─soundconverter
│ │ │ │ └─vmoviedb
│ │ │ └─python2-bonobo
│ │ │   ├─gnome-python
│ │ │   └─python2-libgnome
│ │ ├─libgnomemm
│ │ │ └─libgnomeuimm
│ │ ├─netactview
│ │ └─stardict
│ └─python2-gnomevfs
│   ├─gnome-python
│   ├─python2-gnomedesktop
│   │ └─gnome-python-desktop
│   ├─python2-libgnome
│   └─python2-totem-plparser
│ └─gnome-python-desktop
└─pyorbit
  └─python2-bonobo

[arch-dev-public] Phasing out webkitgtk{,2}

[Jan Alexander Steffens via arch-dev-public]

Hello list,

WebkitGTK+ 2.4 has been unmaintained for quite a while, and lots of CVEs
have accumulated. The last release fixing CVEs, 2.4.10, only fixed about
half the vulnerabilities known, and that release was only made because
2.4.9 was broken with GTK+ 3.20, and Evolution quickly needed a working
HTML renderer.

For more information about the WebKit situation, take a look at
https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/

We currently have the following packages depending on webkitgtk:

webkitgtk
├─balsa
├─eclipse-common
│ ├─eclipse-cpp
│ ├─eclipse-java
│ ├─eclipse-jee
│ └─eclipse-php
├─empathy
├─geary
├─gnome-web-photo
├─gtkpod
├─liferea
├─midori
├─uzbl-core
│ └─uzbl-browser
│   └─uzbl-tabbed
├─variety
├─webkitgtk-sharp
│ └─sparkleshare
└─xombrero

And, for webkitgtk2:

webkitgtk2
├─atril
├─boinc
├─codeblocks
├─dwb
├─geany-plugins
├─gnucash
├─gphpedit
├─guitarix2
├─java-openjfx
│ └─pdfsam
├─java-openjfx-doc
├─java-openjfx-src
├─luakit
├─midori-gtk2
├─moneymanagerex
├─osmo
├─pan
├─perl-gtk2-webkit
├─python2-deepin-utils
│ └─python2-deepin-ui
│   ├─deepin-game
│   └─deepin-music
├─pywebkitgtk
│ ├─python2-deepin-ui
│ ├─python2-deepin-utils
│ ├─python2-jswebkit
│ │ └─deepin-game
│ └─screenlets
│   └─screenlets-pack-basic
├─surf
└─webkit-sharp
  ├─blam
  └─mono-tools

To protect our users we should try to limit the packages using
webkitgtk(2)., with the goal of eventually getting rid of it completely. I
propose making a TODO that covers all these packages, with the following
policy:

   - If it can be updated to webkit2gtk, do so.
   - Otherwise, if WebKit is an optional dependency, build without it.
   - Otherwise, consider removing the package, especially if it's a browser.

Thoughts?

Greetings,
Jan

Re: [arch-dev-public] Shadowing i686, round 1

[jan]

Giancarlo Razzolini schreef op 2016-12-14 14:47:
Em dezembro 13, 2016 19:02 Jan Alexander Steffens via arch-dev-public 
escreveu:


A bit +1 from me for dropping i686 sooner rather than later. The less 
I

have to care about it the better.



+1 about dropping i686 support entirely. Even though you can find 
working i686
hardware, specially on other countries, I just don't think it is 
compelling

reason for keeping it.

Cheers,
Giancarlo Razzolini


It's not about the hardware. Anything that can run x86_64 can also run 
i686.


I still use i686 hardware that is incapable of supporting x86_64 (Core 
Duo), would be sad to see support getting dropped. On the other hand, 
archlinux should focus on x86_64. At this moment we just build and 
commit i686 packages, nobody actually runs any tests with i686. At this 
moment there's a wide community maintaining ARM packages for archlinux, 
probably i686 should do the same in the near future.


Also, if it's about legacy hardware, why i686 and not just i586 instead? 
i686 is not about performance anyways.

Re: [arch-dev-public] Shadowing i686, round 1

[Jan Alexander Steffens via arch-dev-public]

On Mon, Dec 12, 2016 at 9:51 PM Bartłomiej Piotrowski <
bpiotrow...@archlinux.org> wrote:

> In September we discussed upgrading the default -march value for
> packages to include SSE2 (and possibly more instructions). I think the
> general consensus was that we don't agree what we should do and we just
> left the problem intact.
>
> Semi-necrobumping that thread, I want to bring back one proposal – let's
> deprecate i686 architecture. All my machines at home and work are
> x86_64. Building i686 packages is a chore I'm less and less willing to
> do, and I boot up a 32-bit virtual machine only if bug has been reported
> against that architecture. No, I don't do even smoke tests – I assume
> that i686 works if x86_64 does. (Don't beat me up too hard for that.)
>
> To back up my idea, our completely unreliable pkgstats data says that
> 8.53% came from i686 installs, but only a little over 4% is incompatible
> with amd64. Obviously there is no way to verify this data, but I suspect
> that these numbers are even lower in the reality. We're just wasting our
> time.
>
> I'd like to set a certain date of dropping i686 completely. During that
> time, community and/or interested packagers could come up with either
> automated build solution, making it "tier 2" architecture. Otherwise it
> would just die of natural cause.
>
> Let's see where we end up this time.
>
> Bartłomiej
>

A bit +1 from me for dropping i686 sooner rather than later. The less I
have to care about it the better.

Re: [arch-dev-public] Changing compilation flags

[Jan Alexander Steffens via arch-dev-public]

On Tue, Dec 13, 2016 at 10:37 AM Allan McRae  wrote:

> That commit shows they disabled it for one package.
>

It shows they disabled it for Linux, but  it also mentions that i386 is
untested because PIE has not been enabled for that architecture at all.

Re: [arch-dev-public] Changing compilation flags

[Jan Alexander Steffens via arch-dev-public]

On Mon, Oct 24, 2016 at 5:56 AM Allan McRae  wrote:

> Hi all,
>
> The results from the test-sec-flags [1] suite are in.  Many thanks to
> those that wrote this and those that submitted results.  I'm not going
> to list the summaries here, but the results show that at worst enabling
> a bunch of security flags in our packages will have a <1% impact on
> performance (and more likely a fraction of a percent).
>
> That means we will add all of these to our default CFLAGS/LDFLAGS etc.
> The changes are:
>
> 1) building gcc to enable PIE by default
> 2) add -z,now to LDFLAGS
> 3) and -fno-plt and -fstack-check to our CFLAGS
>
> Adding PIE means that programs get loaded at a random address,
> preventing an attacker from manipulating global data or hijacking
> control by reusing code.  Without this, ASLR is ineffective.  Enabling
> this by default in our compiler (there is a configure flag) means we
> will need to rebuild all packages with static libraries (which should be
> a fairly limited set).
>
> Adding -z,now to LDFLAGS disables lazy loading.  This means all function
> symbols are loaded at startup (with minor performance hit), but that
> means our RELRO support will make everything ro instead of some of the
> things.  Doing this enables us to use -fno-plt in our CFLAGS, which is a
> run-time optimisation allowing faster use of libraries.
>
> Adding -fstack-check to our CFLAGS guarantees stack overflows aren't
> exploitable.
>
> Note that any of these flags can be disabled in a PKGBUILD if really
> needed...  But if that is the case, bug reports should be filed.
>
>
> Given an assumed lack of objection, I will enable the build flags in our
> pacman.conf and rebuild gcc to enable pie and put them in [staging] at
> the end of this week (what better way to celebrate Halloween).  We will
> need a new devtools release then too.  Then the packages with static
> libraries will need rebuilt.
>
> After that, I would like to see [core] completely rebuilt, and audited
> to ensure our CFLAGS/LDFLAGS are actually being used in the build.
>
> Cheers,
> Allan
>

Will this affect i686 as well? According to this commit (
https://github.com/zen-kernel/zen-kernel/commit/cc701dc61a7187e9dfc300ad6ec3b7a677dc4717)
at least Ubuntu seems to have skipped that for now.

[arch-dev-public] gitpkg Helper

[Jan Alexander Steffens via arch-dev-public]

Reposting this here as it might be of interestest to my fellow maintainers.
It's already installed on soyuz.

On Mon, Nov 28, 2016 at 5:26 PM Levente Polyak 
wrote:

In fact we already had several discussions in the IRC about this topic
and what I mentioned above was always sufficient to justify getting rid
of it. The only reason we don't yet have a TODO list to switch away from
#tag= is simply lack of time (but its still on my todo list besides
getting a TODO list for git:// sources).

If a remember correctly either heftig or JGC has created a convenience
script to update a PKGBUILDs values, maybe they share it with us :)


I did, and it's tracked here now:
https://git.archlinux.org/infrastructure.git/tree/roles/archbuild/files/gitpkg

Made from cardboard and duct tape. Use with care. May eat your babies for
breakfast.

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

[jan]

jgc:
extra/x86_64/libxml++-docs
extra/x86_64/libxml++
extra/any/ttf-dejavu
extra/x86_64/libproxy
extra/x86_64/gnumeric


Please don't kill these. They still get active maintenance but I haven't 
gotten into these yet.


libxml++ is not out of date, the "new version" is a new ABI/API which is 
not compatible with any package that uses libxml++ at the moment. I can 
flag it as not out of date, but someone will flag it again tomorrow.


gnumeric is one version behind, I have a PKGBUILD ready (using the new 
gnome git stuff), but it doesn't build because gnumeric depends on 
deprecated features of gnome-common that have been removed over a year 
ago.


libproxy and ttf-dejavu are also one version behind, they will get 
updated soon.

[arch-dev-public] cdrkit and mod_fastcgi maintenance

[Jan de Groot]

At this moment there's two of my packages on the todo list "Packages
with missing sources": cdrkit and mod_fastcgi.

Both packages are abandoned projects: no development, websites
completely dead and source files can only be downloaded from other
distributions.

I would like to drop both packages and replace them with replacements
that get active development:

mod_fastcgi can be replaced with mod_fcgid (in extra) or mod_proxy_fcgi
(included in apache package). mod_fcgid can't connect to external
sockets like php-fpm, but mod_proxy_fcgi can do that.

cdrkit can be replaced with the original version which is cdrtools (in
community).

[arch-dev-public] i686 and SSE2

[Jan Alexander Steffens via arch-dev-public]

I recently ran into a problem again because Rust understands "i686" to
imply up to SSE2; "i586" is supposed to be used for older processors. The
Firefox build system now uses "i586", our Rust only has "i686", and our
i686 as GCC understands it is something in-between Rust's interpretations.

We also have other packages that require SSE2 on i686; I recall WebkitGTK;
removing SSE2 support here would mean removing the JIT, increasing
compatibility but slowing down JavaScript massively. I've also heard that
Go, Ruby and Chromium are similarly affected.

I brought this up with Allan and he was in support of "upgrading" our i686
to include SSE2. Are you in favor?

Would "-march=pentium-m" be best way of doing this? It seems simple, but
are there other effects we don't want? Perhaps "-march=pentium-m
-mtune=generic" or "-march=i686 -mtune=generic -msse -msse2" would work
better.

Should we leave the situation as-is? I.e. only some functionality requires
SSE2. There's no way to tell until you run into a SIGILL.

Should we enforce no SSE2 on i686? Can we even do that?

I also wish we had some data on SSE2 support across i686 machines. Perhaps
we should upgrade pkgstats to record *all* the cpuflags? We would gain data
for future decisions, too.

Re: [arch-dev-public] New TeXLive 2016 packages in [testing]

[Jan Alexander Steffens via arch-dev-public]

On Mon, Jun 20, 2016 at 12:45 AM Rémy Oudompheng <
arch-dev-public@archlinux.org> wrote:

> I have published new TeXLive packages for the 2016 release in [testing].
> The structure of the packages has been left unchanged (e.g. no introduction
> of pacman hooks).
>

I noticed that there's an mktexlsr hook now, but texlive-bin still runs it
post_install and post_upgrade.

Perhaps you should add "Target = usr/bin/mktexlsr" to the hook? Then it
will run after texlive-bin install and upgrade, too.

Also, please keep the output of the hooks clear—only errors should be
reported. For the mktexlsr script, remove the echo and the -v flag from rm
in the mktexlsr script. Perhaps the commands it calls also need to be
quieted (via arguments or redirects), but don't do so if it suppresses all
errors, too. The font map hook needs a similar treatment.

Thanks for your work on TeXLive!

Re: [arch-dev-public] Moving repos to nymeria - possibly some interruption of service

[Jan Alexander Steffens via arch-dev-public]

Actually, the right command would be:

svn relocate svn+ssh://svn-packages@nymeria svn+ssh://svn-packages@repos ||
svn relocate svn+ssh://svn-community@nymeria svn+ssh://svn-community@repos

Which should relocate the repo properly, no matter which type.

On Mon, Jun 13, 2016 at 7:54 PM Sven-Hendrik Haase  wrote:

> Attention: I'm doing one last sync now from nymeria and then I'm disabling
> it. Moving repos to orion now.
>
> You all need to do this:
>
> community: svn relocate svn+ssh://
> svn-commun...@repos.archlinux.org/srv/repos/svn-community/svn
> packages: svn relocate svn+ssh://
> svn-packa...@repos.archlinux.org/srv/repos/svn-packages/svn
>
> The DNS will be pointing to orion in a bit. If it doesn't work yet and
> you're impatient, you can use orion.archlinux.org as the host.
>
> I'm disabling all user accounts on nymeria now.
>
> On Sat, Jun 4, 2016 at 8:52 PM, Florian Pritz via arch-dev-public <
> arch-dev-public@archlinux.org> wrote:
>
> > On 01.06.2016 09:51, Sven-Hendrik Haase wrote:
> > > Signing my message. Also, of course the topic is wrong. We're moving
> > > FROM nymeria TO orion.
> >
> > Just a quick update: Given gudrun crashed the other day we have put this
> > move on hold and are now working on clearing out gudrun first.
> >
> > We'll send another mail once this move will happen. Just continue
> > packaging stuff like always unless we tell you not to.
> >
> > Florian
> >
> >
>

Re: [arch-dev-public] Hooks rebuild #1

[Jan Alexander Steffens]

On Apr 27, 2016 2:36 PM, "Allan McRae"  wrote:
>
> We are ready to start the first hooks rebuild.  This rebuild covers
> packages using these hooks:
>
> update-desktop-database
> update-mime-database
> install-info
> glib-compile-schemes
> gtk-update-icon-cacne/xdg-icon-resource
> gconf
> gio-querymodules
>
> Each rebuild requires the install file updated to remove these commands.
>
> No need to use staging/testing for this rebuild (except [core] packages).
>
> GO!

It seems libvirt just lost its systemd-tmpfiles call even though it's not
on the list. Were any other packages similarly affected?

Re: [arch-dev-public] Hooks rebuild #1

[Jan Alexander Steffens]

On Thu, Apr 28, 2016 at 12:09 AM, Anatol Pomozov
 wrote:>
> And one more note: there are a lot of packages that have a dependency
> to "desktop-file-utils/gtk-update-icon-cache/..."
> package because the tools were used in *.install file. With the hook
> these dependencies are needed anymore.
> Please look at the dependency list of the packages you update and
> clean it up if needed.

No, dependencies ensure the hook is available.

Re: [arch-dev-public] Consensus: DKMS modules

[Jan Alexander Steffens]

On Wed, Apr 13, 2016 at 2:05 PM, Jan Alexander Steffens
<jan.steff...@gmail.com> wrote:
> Please don't add modules for -zen to the repos. They create a maintenance
> burden I don't want to support. Let -zen users use DKMS; they never had any
> prebuilt modules anyway.

That said, if the module is interesting enough and GPL-compatible,
I'll import it into the ZEN tree (Liquorix users would then get it,
too). I've done this with vhba-module and tp_smapi way back when.

Re: [arch-dev-public] Consensus: DKMS modules

[Jan Alexander Steffens]

On Wed, Apr 13, 2016 at 12:14 PM, Ike Devolder  wrote:
> To get this discussion back on the right track I'm going to build the
> binary modules for virtualbox. Sébastien and myself already discussed
> what will be done so relatively soon those binary modules will be back.
>
> My plan is now to provide the virtualbox modules for -arch -lts and
> -zen. I think -grsec will be the exception since there are probably
> protections in there that will block some modules to even build.
>
> And when everyone is happy again we probaly should proceed to provide
> dkms for all out-of-tree modules alongside the binary modules. That
> would benefit everyone and offer the greatest amount of choice. People
> using custom kernels can use dkms and have everything working that way
> and people using one of the kernels available in the repo's can choose
> if they want dkms or binary. Everyone wins.

Please don't add modules for -zen to the repos. They create a maintenance
burden I don't want to support. Let -zen users use DKMS; they never had any
prebuilt modules anyway.

Re: [arch-dev-public] C++ ABI bump rebuild

[Jan Alexander Steffens]

On Sat, Dec 5, 2015 at 7:52 AM, Allan McRae  wrote:
> The build will start as soon as I get gcc ready.

How will we handle multilib during this rebuild?

[arch-dev-public] hardening-wrapper

[Jan Alexander Steffens]

Hi,

I was quite surprised today that gcc suddenly started defaulting to
-fstack-check. After some confusion and a bit of exploration, it turned out
that hardening-wrapper, which came as a makedep with python, was
responsible.

It is quite unfortunate that hardening-wrapper unexpectedly alters
system-wide compiler behavior.

In addition, since makepkg layers ccache in front of hardening-wrapper,
ccache will now miss compiler updates.

IMO it should be a makedepend on any package. If we want to harden our
packages we can do this via makepkg.conf or adjusting CFLAGS in the
PKGBUILD, not supposedly-per-package system-wide hacks. Thoughts?

Greetings,
Jan

Re: [arch-dev-public] [arch-events] FrOSCon 2015

[Jan Alexander Steffens]

On Wed, Aug 19, 2015 at 7:59 PM, Pierre Schmitz pie...@archlinux.de wrote:
 On 02.06.2015 17:39, Pierre Schmitz wrote:

 Hi all,

 I did not get any feedback yet. Is there any interest to meet up at
 FrOSCon?


 Hi there,

 the conference starts this Saturday. If anybody else wants to join us in the
 dev room, drop me a mail so you can add you to the list of participants.

I'll be there.

Re: [arch-dev-public] CFLAGS

[Jan Alexander Steffens]

On Mon, Jul 27, 2015 at 6:15 AM, Allan McRae al...@archlinux.org wrote:
 We have a couple of bugs open about our CFLAGS.

 1) https://bugs.archlinux.org/task/44361 -Remove the no-op
 --param=ssp-buffer-size=4 switch from CFLAGS
 Since we moved from -fstack-protector to -fstack-protector-strong, this
 paramater is unused and can be removed.

 2) https://bugs.archlinux.org/task/44362 - Add -fstack-check
 Read more about this here:
 https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html
 This is essentially a no-op for most code, so should have no real
 performance hit.  I can not find any benchmarks to demonstrate that though.

 This would mean:
 CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 -fstack-check

 Opinions?

Seems sound given our focus on IA32 (don't know about other
architectures). +1 from me.

[arch-dev-public] Fwd: Non-core kernel

[Jan Alexander Steffens]

Greetings, friends,

I recently noticed we have community/linux-grsec. Do we have a stance
on additional kernels? I vaguely remember some stigma against it but
not the details. Maybe I'm completely wrong.

If it is agreeable, I would like to bring the ZEN kernel[1] into
either [extra] or [community]. I co-maintain this kernel fork and
currently release packages into my personal repository[2].

I use this kernel on all three of my Linux machines: A Schenker S413
(Clevo W740SU) ultrabook, a Zotac EI750 workstation and an ASUS Eee
Box B202 internet gateway. None use out-of-tree modules.

ZEN follows the same stable versions as core/linux but merges in a few
additional features and drivers. It also carries a handful of fixes
and performance tweaks. The BBS topic[2] lists the major differences.
The configuration of my builds is mostly identical to core/linux.
There are no packages of out-of-tree modules for this kernel and I
would not add any to our repositories.

Talking to Allan revealed that we once had a number of patch sets.
However, apparently this lead to problems with sorting out
kernel-specific bugs. My response would be getting people to reproduce
with core/linux (which should be easier thanks to the mostly-identical
config) and sending them to ZEN's issue tracker if they have
ZEN-specific bugs.

Qapla' batlh je! qatlho',
Jan

[1]: https://github.com/zen-kernel/zen-kernel
[2]: https://bbs.archlinux.org/viewtopic.php?id=117157

Re: [arch-dev-public] Fwd: Non-core kernel

[Jan Alexander Steffens]

On Sun, Jul 19, 2015 at 8:37 PM, Johannes Löthberg
johan...@kyriasis.com wrote:
 Not arguing against this at all, but was wondering if there have been
 attempts to get the zen things merged upstream?

All the big features come from other upstreams. For example, BFQ is
not merged because the kernel maintainers want it as a patch to CFQ,
not a separate scheduler. AUFS is not merged because it's a huge
spaghetti mess (and we now have overlayfs). What remains are tweaks
for PC usage that conflict with Linux' generalism. Gotta run good on
that big iron.

Re: [arch-dev-public] Building in a clean chroot

[jan]

 -Oorspronkelijk bericht-
 Van: arch-dev-public [mailto:arch-dev-public-boun...@archlinux.org]
 Namens Johannes Löthberg
 Verzonden: donderdag 25 juni 2015 18:58
 Aan: Doug Newgard
 CC: Public mailing list for Arch Linux development
 Onderwerp: Re: [arch-dev-public] Building in a clean chroot
 
 On 25/06, Doug Newgard wrote:
 I had two somewhat related bug reports recently. One of made it obvious
 that the
 packager wasn't building in a chroot. The second one was for a missing
 makedepends on a package that was added to the repo less than a day
 earlier. I
 figured this one might be from a dirty chroot, but after contacting the
 maintainer, it turns out he doesn't build in a chroot for any architecture
 packages.
 
 So here we have two people packaging for the repos building outside of
 chroots.
 Where there's two, there's probably more that just haven't been
 discovered yet.
 I inquired about this on IRC and was told there is no written policy, they 
 just
 thought it was understood by all. Is this then something that's currently 
 left
 to the maintainer's discretion? Is it policy and just not written? Is it
 something that should be written policy?
 
 
 It's considered highly recommended but there's no firm policy for it,
 though I agree that there likely should be.

IMHO we should require building in chroots. We have infrastructure for this.

Requiring chroots would be a step closer to 
https://bugs.archlinux.org/task/43407

Re: [arch-dev-public] Merging dnsutils and bind

[Jan de Groot]

On zo, 2015-06-07 at 19:09 +0200, Sébastien Luttringer wrote:
 Hello,
 
 This merge was suggested to me on IRC; dnsutils is out-of-date since 
 a
 long time.
 
 I don't know if there was a good reason to keep them separated. I
 currently planing to keep two packages and merging sources.
 
 Objections?

Go ahead with the merge. dnsutils was split from bind because of bind
10.x.

Re: [arch-dev-public] Dropping vi and adding vim-minimal to the installation image

[Jan Alexander Steffens]

On Wed, Apr 22, 2015 at 12:03 AM, Evangelos Foutras
evange...@foutrelis.com wrote:
 On 22/04/15 00:49, Allan McRae wrote:
 I think the symlink is very important.  And I am very against VIsudo
 calling anything other than vi by default.  Unless you rename it nanosudo.

 The problem is that vim is not provided in [core] and cannot be part of
 a base installation. We can't make an editor from [extra] the default.

 I'm open to suggestions, but consider that nano is the only remaining
 editor in [core]. (And it will work fine as a fallback editor.)

If that's your condition I'm for bringing vim-minimal into [core].
Leave the other vim variants in [extra].

Re: [arch-dev-public] Moving gnutls to [core]

[Jan Alexander Steffens]

On Wed, Dec 10, 2014 at 10:46 PM, Gaetan Bisson bis...@archlinux.org wrote:
 I'd like to move gnutls and its dependencies (libtasn1, nettle, p11-kit)
 to [core] so gnupg can link against it; that'll enable HKPS support.

p11-kit and its dependency libtasn1 have already been moved as they
are dependencies of ca-certificates-utils.

Furthermore, nss and its dependencies nspr and sqlite have been moved
as ca-certificates-mozilla is a dependency of ca-certificates. (This
also opens up the possibility of building curl against nss).

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

[Jan Alexander Steffens]

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.

[arch-dev-public] Dropped ncurses from [testing]

[Jan Alexander Steffens]

Hi,

I dropped the ncurses prerelease version from [testing]. It had an
annoying problem with tmux and the screen* terminfos that resulted in
standout (reverse) being rendered as italic.

Jan

Re: [arch-dev-public] Realtime group and possible helper package

[Jan Alexander Steffens]

On Wed, Nov 12, 2014 at 9:14 AM, Rashif Ray Rahman sc...@archlinux.org wrote:
 I am looking to provide support for a 'realtime' group, for use with
 not just audio/video but any other/future applications of real-time.

 The 'audio' group will remain for backward compatibility,
 indefinitely. I can therefore either create the new group or users
 have to do it.

 If I choose to create the group then I'd have to do it from within a
 package since multiple other packages are affected (jack*).

 --[ background ]--
 Historically, the audio group for real-time multimedia has served two 
 purposes:

 1. Permissions for real-time scheduling (i.e. PAM)
 2. Permissions for device access (e.g. FireWire, RTC, HPET)

 This new group relates mostly to (1). In the event the 'audio' group
 proves to be a problem for devices, the new group can be used.

 This means that a jack user will be in both the 'audio' and 'realtime'
 groups in this new scheme.
 --[ background ]--

 If nobody objects I'll go ahead and create a new package that creates
 the new group and configures the relevant permissions.

The approach of handing out real-time permissions via group or even to
individual users isn't secure, as even the minimum RT priority of 1
can be used to DOS the system. We really want something else for
future applications. Perhaps we can push systemd into adding a TODO to
gain something similar to realtimekit for use by both applications and
systemd user services.

Re: [arch-dev-public] Dropping logrotate from core/base

[Jan Alexander Steffens]

On Thu, Oct 16, 2014 at 3:30 PM, Pierre Schmitz pie...@archlinux.de wrote:

 Hi,

 I just pushed a logrotate package to testing that is no longer part of the 
 base group. This also means that this package can be moved from core to extra.

 Any objections? I am not sure about e.g. wtmp faillog etc. So I might just 
 need to revert that change.

wtmp and btmp need to be rotated. Other services (notably here: cups,
nginx, apache, libvirt, postgresql, samba) also expect to have their
logfiles rotated. I believe we should continue to install *and run*
logrotate by default until we can get rid of wtmp and btmp and move
services to use journal or syslog.

Re: [arch-dev-public] [RFC] New package: vte3-2.90

[Jan Alexander Steffens]

On Mon, Sep 29, 2014 at 5:45 AM, Anatol Pomozov
anatol.pomo...@gmail.com wrote:
 This is the best thing we can do now. I briefly looked at vte 0.38 and
 found that it contains *a lot* of API changes. It requires non-trivial
 patches to port sakura and other applications. Let's leave the task of
 API porting to the apps developers.

Well, at least in the apps I ported the API changes weren't that
difficult to adapt to. But, they weren't dedicated terminal
applications. IIRC features were removed where the best we could do
would be stubbing them out.

On another note, I wouldn't be opposed to using this opportunity to
flip our package names around, so we'll have vte2, vte2.90 and vte.
Or, if we want to match the library names, vte, vte2_90 and vte-2.91.
Or maybe some other combination. In any case, vte3 isn't really the
right name.

Re: [arch-dev-public] [RFC] New package: vte3-2.90

[jan]

On 2014-09-29 08:35, Jan Alexander Steffens wrote:

On Mon, Sep 29, 2014 at 5:45 AM, Anatol Pomozov
anatol.pomo...@gmail.com wrote:
This is the best thing we can do now. I briefly looked at vte 0.38 
and
found that it contains *a lot* of API changes. It requires 
non-trivial
patches to port sakura and other applications. Let's leave the task 
of

API porting to the apps developers.


Well, at least in the apps I ported the API changes weren't that
difficult to adapt to. But, they weren't dedicated terminal
applications. IIRC features were removed where the best we could do
would be stubbing them out.

On another note, I wouldn't be opposed to using this opportunity to
flip our package names around, so we'll have vte2, vte2.90 and vte.
Or, if we want to match the library names, vte, vte2_90 and vte-2.91.
Or maybe some other combination. In any case, vte3 isn't really the
right name.


Note that the whole reason for vte-common (the pty helper binary) is 
not an issue anymore with latest vte3 anymore. Upstream has deprecated 
it and disabled the build by default, I enabled it for now, but when we 
disable it again, the binary can move to the vte2 package.


I'm not very happy with having 2 outdated copies of vte in our repos 
though, it's another old library that will not receive any maintenance 
at all. I only want to package the older version in our repos if someone 
can assure me that it will stay active for only 6 months, after that it 
should disappear from repos and all applications that haven't been 
ported should die together with it.

[arch-dev-public] [gnome-unstable] is ready to move

[Jan Alexander Steffens]

Patched the last holes last night. I think we're ready to move
[gnome-unstable] to [testing].

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

[Jan Alexander Steffens]

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?

Re: [arch-dev-public] perf-trace missing due to a dependency on libaudit

[Jan Alexander Steffens]

On Wed, May 7, 2014 at 4:11 PM, Daniel Micay danielmi...@gmail.com wrote:
 RBAC also allows quite a bit of auditing with the grsecurity audit
 infrastructure. You can audit attempts to make use of a certain path,
 capability, IP protocol, etc. Of course, this assumes you have a basic
 working RBAC policy for tacking on allowed + audited policies or
 disallowed + audited policies. So CONFIG_AUDIT=Y is a lot less useful.

I'm sad that AUDIT was disabled. It provided /proc/self/loginuid,
which I used in my shell scripts.

loginuid is also used by glibc's getlogin(3), which now no longer
works unless the user is logged in on their terminal. In managed X
sessions that's often not the case, resulting in bugs like
https://bugs.archlinux.org/task/40975 .

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

[Jan Alexander Steffens]

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

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

[Jan Alexander Steffens]

On Sun, Aug 24, 2014 at 12:06 PM, Gaetan Bisson bis...@archlinux.org wrote:
 [2014-08-24 11:47:56 +0200] Jan Alexander Steffens:
 - 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

 So we'd have three ca-certificates-* packages?

 If this is this only to allow users to remove the bundles (mozilla or
 cacert) they do not trust, then couldn't we instead just keep everything
 in one package; simply putting the files

 /etc/ca-certificates/conf.d/{mozilla,cacert}.conf

 in the backup array would allow anyone to override them, so disabling a
 bundle would also be super easy...

 Other than the fragmentation of packages (my new pet gripe), your plan
 sounds great!

I don't want to stick either update-ca-certificates or the CAcert.org
certificates into the NSS PKGBUILD, so we will have at least two
PKGBUILDs and three packages involved here:

ca-certificates/PKGBUILD:
- sources: Debian ca-certificates, CACert.org certificates
- pkgnames: ca-certificates

nss/PKGBUILD:
- sources: Mozilla NSS
- packages: nss ca-certificates-mozilla

Since Debian and CACert.org aren't really related, I wanted to do
another split. -cacert and -mozilla both provide packages; the rest is
infrastructure. One could conceive of other provider packages. So our
proposed setup is:

ca-certificates/PKGBUILD:
- sources: Debian ca-certificates
- pkgnames: ca-certificates ca-certificates-utils

ca-certificates-cacert/PKGBUILD:
- sources: CACert.org certificates
- pkgnames: ca-certificates-cacert

nss/PKGBUILD:
- sources: Mozilla NSS
- pkgnames: nss ca-certificates-mozilla

The package ca-certificates is empty and just depends on -mozilla and
-cacert to ensure a sane default setup.
The package ca-certificates-utils provides ca-certificates, so a
minimum install with no certificate provider packages is possible.

Re: [arch-dev-public] Packages added to todo list 'glew 1.11 rebuild'

[Jan de Groot]

On di, 2014-08-19 at 09:13 +0900, Gaetan Bisson wrote:

 What the ?!?
 
 You know that's not how this is supposed to work, right?
 
 It's the second time in two days hugin is broken because of people
 updating a dependency without checking for soname bumps and pushing
 straight to [extra].
 
 Is it really that hard?
 

GLEW is broken in a special way: it doesn't provide the .so.1 library,
so applications link against .so.1.11 or .so.1.10 instead. This is not
something you would detect when running checkpkg (common sense says to
ignore soname changes which are not in the first digit).

Anyways, before rebuilding a lot of shit, please check what's wrong with
GLEW, you can do the rebuild all over again when this is fixed.

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

[Jan Alexander Steffens]

On Sat, Aug 16, 2014 at 2:31 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). 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

Note that this also affects openjdk8-src if you have it installed.

Re: [arch-dev-public] SVN Cleanup

[Jan de Groot]

On di, 2014-08-05 at 23:04 +1000, Allan McRae wrote:

 
 Do it.  Can you check they all made it to the AUR too?
 
 A

AUR makes no sense when those packages were killed because nothing needs
it anymore. Why would you put something like xf86-video-i810 in AUR if
it doesn't build since the day it was removed?

Re: [arch-dev-public] linux 3.16 in [testing]

[Jan Alexander Steffens]

On Mon, Aug 4, 2014 at 12:58 PM, Tobias Powalowski
tobias.powalow...@googlemail.com wrote:
 It's also worth mentioning that we no longer change the default
 console loglevel to 4 (= quiet). This makes the boot screen a bit
 noisy which is solvable with the 'quiet' kernel argument.
 CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4

 so no change here.

Wrong; that setting doesn't affect the default console log level, but
the log level used for printk statements without a level. It also
defaults to 4.

In order to make quiet the default you need to patch it again.
However, note that the CONSOLE_LOGLEVEL_DEFAULT define was moved to
include/linux/printk.h.

Re: [arch-dev-public] [arch-general] [draft] xorg-server 1.16 is now available

[Jan Alexander Steffens]

On Fri, Jul 25, 2014 at 6:53 PM, Leonid Isaev lis...@umail.iu.edu wrote:
 Forcing X to run as root via Xwrapper.config does help, but neither this file
 nor /etc/X11/X11 are part of the package. Is it possible to at least have the
 latter directory in xorg-server?

/etc/X11/X11/Xwrapper.config seems wrong. Laurent, can you please
check if it can be altered to use /etc/X11/Xwrapper.config?

Re: [arch-dev-public] [RFC] Moving mail away from gerolde

[Jan de Groot]

On wo, 2014-06-25 at 23:44 +0200, Sébastien Luttringer wrote:
 I tend to think that a different machine than nymeria would be a
 better
 option to isolate our mail functions from package management on our
 infrastructure.

The whole reason for splitting Gerolde and Gudrun years ago was because
our server was hacked through a web application it was running and
integrity of our repositories was at risk because of that.

The reason for our split mail setup is that we didn't want to have the
mailman http interface running on Gerolde, so mailman had to move to
gudrun. I won't accept moving stuff to nymeria that executes CGI
binaries through a webserver.

Re: [arch-dev-public] providing grsecurity in [community]

[Jan de Groot]

On zo, 2014-04-20 at 11:12 +0200, Sébastien Luttringer wrote:
 We use closed-source components on our computer everyday (BIOS,
 firmwares) because we trust hardware provider like Nvidia.
 I wouldn't says that people who have Nvidia cards and run Nvidia
 drivers
 are in an inherently insecure situation.
 
 There are features in grsec which can be useful even with an Nvidia
 module (hide others users process, restricted ipc, etc).

The problem with Nvidia and grsecurity is that Nvidia doesn't test their
drivers on grsecurity kernels. With grsecurity you alter the way the
kernel works. If this alters the kernel in any way that the Nvidia
binary driver doesn't expect, you'll end up with something that makes
your system unstable.

Supporting Nvidia on vanilla kernels is a challenge now and then because
of the incompatible changes done in each version, but maintaining it for
a grsecurity patched kernel is even harder.

Re: [arch-dev-public] Updating webkitgtk2 to 2.2.5 (or later)

[Jan Alexander Steffens]

On Mon, Feb 24, 2014 at 12:52 AM, Jan Alexander Steffens
jan.steff...@gmail.com wrote:
 On Fri, Feb 21, 2014 at 6:39 PM, Jan Alexander Steffens
 jan.steff...@gmail.com wrote:
 I would like to update our GTK2 build of libwebkit. Having a seriously
 outdated browser engine with who knows as many bugs and
 vulnerabilities isn't quite optimal.

 So far we've kept it at version 1.10.2 because that's the last version
 still supporting GStreamer 0.10. Having both GStreamer 0.10 and 1.0 in
 the same process is not possible.

 For the update to happen, packages using both webkitgtk2 and
 gstreamer0.10 would have to be patched OR removed. As far as I can
 tell this affects the following packages:

 banshee (Fedora has a patch)
 emesene
 miro

 I intend to go ahead this weekend.

 New webkitgtk2 and patched banshee is now in [testing]. Sadly, both
 emesene [1] and miro [2] seem to be unmaintained and the bugs [3][4]
 don't show any progress, either.

 [1]: https://github.com/emesene/emesene
 [2]: https://github.com/pculture/miro
 [3]: https://github.com/emesene/emesene/issues/1537
 [4]: http://bugzilla.pculture.org/show_bug.cgi?id=19716

Ronald, I want to move the new version to [extra] and drop both miro
and emesene.
As maintainer of the latter two I wanted to give you another chance to object.

Re: [arch-dev-public] Upgrading Apache to 2.4

[Jan de Groot]

Pierre Schmitz schreef op 27.02.2014 13:04:


I did push a rebuild PHP into [staging]. I had to add a hack to keep 
the

non-ZTS build that can only be used with the prefork MPM. For some
reason PHP devs thought it would be a good idea to base a PHP compile
time option on the stat of an Apache runtime config. Some day we might
just drop mod_php; I cant think of any sane usage of this SAPI. Am I
correct that Apache can now use FastCGI without third-party modules?

Anyway, I suggest in the end we should post an announcement on the 
front

page. IMHO that install message is not really needed then, but that
might be debatable.



FastCGI is possible with mod_proxy_fcgid and mod_fcgid, but this has 
some side-effects:

- mod_fcgid can't connect to php-fpm
- mod_proxy_fcgid doesn't pass DOCUMENT_ROOT to php-fpm, so you would 
have to setup weird rules or multiple php-fpm pools for every vhost


Since mod_fastcgi still works with some patching there's not a big 
issue at this moment.


I don't see real need for mod_php either, when I initially tested 
Apache 2.4 it was giving weird issues. I replaced the mod_php setups 
with mod_fastcgi + php-fpm a while ago. Though fastcgi adds some extra 
overhead, the event MPM brings much more advantages that makes it worth 
switching.
IMHO mod_php with ZTS is not a good alternative, it adds additional 
overhead and you're still not sure that 3rd party libraries won't screw 
thread safety.

Re: [arch-dev-public] Updating webkitgtk2 to 2.2.5 (or later)

[Jan Alexander Steffens]

On Fri, Feb 21, 2014 at 6:39 PM, Jan Alexander Steffens
jan.steff...@gmail.com wrote:
 I would like to update our GTK2 build of libwebkit. Having a seriously
 outdated browser engine with who knows as many bugs and
 vulnerabilities isn't quite optimal.

 So far we've kept it at version 1.10.2 because that's the last version
 still supporting GStreamer 0.10. Having both GStreamer 0.10 and 1.0 in
 the same process is not possible.

 For the update to happen, packages using both webkitgtk2 and
 gstreamer0.10 would have to be patched OR removed. As far as I can
 tell this affects the following packages:

 banshee (Fedora has a patch)
 emesene
 miro

 I intend to go ahead this weekend.

New webkitgtk2 and patched banshee is now in [testing]. Sadly, both
emesene [1] and miro [2] seem to be unmaintained and the bugs [3][4]
don't show any progress, either.

[1]: https://github.com/emesene/emesene
[2]: https://github.com/pculture/miro
[3]: https://github.com/emesene/emesene/issues/1537
[4]: http://bugzilla.pculture.org/show_bug.cgi?id=19716

[arch-dev-public] Updating webkitgtk2 to 2.2.5 (or later)

[Jan Alexander Steffens]

I would like to update our GTK2 build of libwebkit. Having a seriously
outdated browser engine with who knows as many bugs and
vulnerabilities isn't quite optimal.

So far we've kept it at version 1.10.2 because that's the last version
still supporting GStreamer 0.10. Having both GStreamer 0.10 and 1.0 in
the same process is not possible.

For the update to happen, packages using both webkitgtk2 and
gstreamer0.10 would have to be patched OR removed. As far as I can
tell this affects the following packages:

banshee (Fedora has a patch)
emesene
miro

I intend to go ahead this weekend.

Re: [arch-dev-public] : Updating webkitgtk2 to 2.2.5 (or later)

[Jan Alexander Steffens]

On Fri, Feb 21, 2014 at 9:14 PM, Jan de Groot j...@jgc.homeip.net wrote:
 Did you think about compiling without gstreamer support completely?
 I don't think ancient software still using gtk2 would be using audio and 
 video tags.

We have regular browsers using webkitgtk2 (dwb, midori, surf, uzbl). I
thought that we'd rather keep media support in these.

[arch-dev-public] Freetype 2.5.1 in [testing]

[Jan Alexander Steffens]

This release has changed the location of most header files.

Theoretically nothing should change, since build systems are supposed
to get the includedir via freetype-config or pkg-config, while sources
are supposed to first #include ft2build.h and then include other
files via macros, e.g. #include FT_FREETYPE_H.

But as we all know the situation de facto is often different, so I'm
giving you a chance to test and comment before moving freetype2 to
[extra]. I'll also be making build tests with some randomly chosen
packages which depend on it.

Would be nice if I could get signoffs, even though Freetype isn't
destined for [core].

Re: [arch-dev-public] Abiword package

[Jan de Groot]

On zo, 2013-10-27 at 19:13 +0100, Giovanni Scafora wrote:
 Hi there,
 
 I am no longer interested in maintaining the abiword package.
 Is there anyone who wants to keep it?

Shouldn't be an issue for me. I'm also maintaining gnumeric and some
dependencies for abiword. I already started working on abiword 3.0 a
week ago, but didn't finish it.

Re: [arch-dev-public] Proposal for a new virtual package: polkit-authentication-agent

[Jan de Groot]

On za, 2013-10-05 at 00:43 +0200, Balló György wrote:
 Hi,
 
 I would like to propose a new virtual package called
 'polkit-authentication-agent'.

IMHO polkit authentication agents should be just as default as an X
server. We don't depend on xorg-server for graphical applications
either.

GNOME includes one by default, KDE includes one by default.
xfce4-session should just depend on one.

As for providing it: makes no sense. gnome-shell could provide one, but
if you use xfce and have gnome-shell, you'll never get to use the polkit
agent in gnome-shell.

Re: [arch-dev-public] Git

[Jan Alexander Steffens]

On Fri, Oct 4, 2013 at 6:15 PM, Alexander Rødseth rods...@gmail.com wrote:
 Now, if I may, here's how your decisions on how you set up a git repo
 in place of svn affect us.  Right now, with the svntogit providing a
 merged repo of all the packages in two places (core/extra in one,
 community in another) allows me to simply poll the two git repos for
 changes and operate on that changeset.  This means that when packages
 get added, removed, or modified, I'm able to see everything that takes
 place.  If each package was to be split into its own git repo, I would
 need to devise some (potentially ugly) solution to scrape all of the
 current repos from somewhere, match them against what I know to exist,
 add packages (repos) that just got created and delete packages (repos)
 that just got removed, then further correlate which pacman repo each
 belongs to, if repos have changed, etc.  It would also require that I
 either find some way to determine which package git repos changed and
 only poll them, or potentially have to poll the ~4500 git repos that
 would exist individually.  In short, I don't know how I would
 accomplish this off the top of my head, and it could be a massive pain
 to implement.

To clarify, the individual git repos are just for tracking individual
package development. There still would be a central git repo
maintained by our dbscripts which reflects the status of all our
pacman repos. Either by using
submodules pointing at tagged commits in the individual git repos, or,
if submodules don't work out well, by copying the state of those tags,
maybe using git-subtree.

 My two cents toward the repo structuring would be to follow the same
 structure that is in place now with svntogit: have a packages.git that
 contains core and extra, which Arch developers have access to change,
 and a community.git that contains community, which devs and TUs have
 access to change.  Unless there is some overbearing need to
 individually delegate write access per package, individual git repos
 per package seems like it would be more of an administrative headache
 than it is worth (aside from destroying my current development model
 for Arch Linux ARM).  Should you decide to use a service like github,
 a combined package repo also means that community-generated pull
 requests are also combined, allowing more people to be notified of
 changes, submit their input, or merge changes when someone is on
 vacation.  A combined repo also means that you can delegate a
 'testing' branch to contain all the testing versions of all the
 packages, allowing one to push/pull to all of the testing packages in
 one move, or merge a large set of changes back to stable, without
 having to go through and do the same operation on multiple git repos
 (I'm specifically thinking of things like the Gnome and KDE package
 sets).  One could potentially create a 'gnome-testing' branch, do all
 the changes and builds based on that branch, then when it's ready
 merge that branch back into stable and you're done.

When moving changes from testing to stable, the individual git repos
are not touched at all. They only track package versions, not which
pacman repos they are in (if any). Moving happens inside dbscripts,
which only needs to update the pacman repos and the central git repo
mentioned above.

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

[Jan Alexander Steffens]

On Fri, Oct 4, 2013 at 11:38 PM, Gaetan Bisson bis...@archlinux.org wrote:
 [2013-10-04 20:37:38 +0200] Balló György:
 Or why don't we have an official Artwork Team who maintain these packages?

 So just like a regular dev/TU, except restricted to artwork packages?
 That makes very little sense to me...

 If no dev/TU wants to maintain them, let them find carers in the AUR.

 --
 Gaetan

I don't think these packages should be in the AUR, given that they
just repackage content from our FTP for access via pacman.

Whenever someone uploads new artwork to our FTP, they should also
update these packages. Otherwise, they are pretty much zero
maintenance.

Re: [arch-dev-public] Rewriting dbscripts (packagers should read this!)

[Jan Alexander Steffens]

On Tue, Oct 1, 2013 at 11:25 AM, Massimiliano Torromeo
massimiliano.torro...@gmail.com wrote:
 This will lead to having thousands of tags in the repo.
 Does anyone have any experience with git repositories with so many tags?
 I am thinking about possible performance issues since I don't think this is
 typical git usage.

I assume we will use one git repo per PKGBUILD. The amount of tags
should stay manageable.

Putting all the packages into one repo would create too much
merge/rebase contention. Using branches to separate the packages would
mean we'd lose the use of branches to manage development, say adding a
new linux stable release in [core] while the next major release cooks
in [testing]. That has historically been rather painful in our setup,
and making it easier would also help us with staging larger projects
like GNOME releases without hindering [extra] maintenance.

In any case, git got a lot better lately in dealing with many refs.

Re: [arch-dev-public] Dropping mplayer2

[Jan Alexander Steffens]

On Fri, Sep 27, 2013 at 2:55 PM, Bartłomiej Piotrowski b...@bpiotrowski.pl 
wrote:
 I'd like to drop mplayer2 from our repositories. The last commit has
 been made in the end of April and upstream failed to make new release
 during last 3 years. While it's possible to keep it in repositories, I
 don't see any reason to do so.

 I recommend switching to community/mpv (which is a great replacement
 with even better performance) or vanilla mplayer from [extra].

I'm using mplayer-vaapi for its VAAPI support. However, classic
mplayer and its vaapi fork suffer from a bug that prevents them from
contacting dual-IPv4/v6 hosts via IPv6; they try to interpret the v4
address as a v6 one (padding with zeroes), instead of using the actual
v6 address.

Neither mplayer2 nor mpv seem to support vaapi output. mpv depends on
libva, but does not link against it.

Seems there's just no good one for me.

[arch-dev-public] Brynhild disk failure

[Jan de Groot]

Don't know if anyone noticed so far, but dmesg on this box has some
kernel traces from unreadable sectors and disk resets, and after a few
of those the disk got kicked out of md1, so this server is basically
running single-disk now.

Re: [arch-dev-public] [RFC] moving libtxc_dxtn from [community] to [extra]

[jan]

On 18.07.2013 10:44, Laurent Carlier wrote:

Le lundi 15 juillet 2013 12:57:29 Laurent Carlier a écrit :

Le lundi 15 juillet 2013 12:00:48 vous avez écrit :
Since at least mesa 9.0, support for patented S3TC compressed 
texture is
available through the external library libtxc_dxtn 
(lib32-libtxc_dxtn for

multilib)

To avoid such bug report [0], i would like to move libtxc_dxtn in 
[extra]
and add it as a dependency of xf86-video-{ati,intel,nouveau} 
packages.


Just noticed a mistake:

it's {ati,intel,nouveau}-dri and not xf86-video-{ati,intel,nouveau} 
packages

Any objections ?

[0]: https://bugs.archlinux.org/task/36062


I will push this with mesa-9.1.5 update



I did raise my concerns, but somehow the mailinglist didn't post my 
message (guess the message is stuck in moderation queue).


Anyways: libtxc_dxtn is no longer maintained and code has only been 
tested on i686. Do you really want to add such a dependency to packages 
like intel-dri, ati-dri and nouveau-dri? I would rather suggest an 
optdepend or add optdepends to games that need this library.

Also, there's a reason why Mesa doesn't include this stuff.

Re: [arch-dev-public] [core] build failures - 2013-06-27

[Jan de Groot]

On do, 2013-06-27 at 14:15 +1000, Allan McRae wrote:
 FAIL:  glib2 (automake-1.14 incompatibility)

Fixed, it was some timestamp issue (glib2 doesn't need automake to
build)

Re: [arch-dev-public] Integrity Check i686: core, extra, community 14-06-2013

[Jan Alexander Steffens]

On Fri, Jun 14, 2013 at 4:09 PM, Thomas Bächler tho...@archlinux.org wrote:
 Am 14.06.2013 16:04, schrieb repoma...@archlinux.org:
 Repo Hierarchy for Dependencies
 -
 core/grub-common depends on extra/freetype2 (488 extra (make)deps to pull)
 core/grub-common depends on extra/fuse (488 extra (make)deps to pull)
 core/grub-efi-i386 depends on extra/efibootmgr (488 extra (make)deps to pull)
 core/grub-efi-x86_64 depends on extra/efibootmgr (488 extra (make)deps to 
 pull)
 core/nfs-utils depends on extra/sqlite (488 extra (make)deps to pull)

 What happened here? [core] was once self-contained, now it isn't - and
 fixing that would blow it up considerably. Do we no longer care?

IMO freetype2 should be moved to optdepends (only required for
grub-mkfont, which is only run manually), while efibootmgr should be
moved into [core].