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

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

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

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

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

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

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

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

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

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

[arch-dev-public] i686 and SSE2

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

[arch-dev-public] gitpkg Helper

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

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

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

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

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] Shadowing i686, round 1

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

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

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

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

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

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

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.

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

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 fro

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

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

Re: [arch-dev-public] ImageMagick 7

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 +0000, Jan Alexander Steffens via > arch-dev-public escribió: > > > Hi list, > > > > if nobody objects I would like to

[arch-dev-public] ImageMagick 7

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.

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

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

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

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

[arch-dev-public] Raise default inotify limits

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

[arch-dev-public] Remove CAcert root certs

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,

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

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

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

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

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

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

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

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] libx11/xorgproto dependency

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

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

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

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

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:

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

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

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

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

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

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.

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

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.

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

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

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

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

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

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

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

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