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

[arch-dev-public] Dropping glee and clalsadrv
by David Runge 26 Dec '17

26 Dec '17

Hi all, I've been working through the list of packages, formerly maintained by speps (some of which are pro-audio things). I found at least two, that should be deleted (more to come probably): * clalsadrv - superseeded by zita-alsa-pcmi * glee - upstream dead, unmaintained for more than five years The first has no packages depending on it and the second only electricsheep, which also seems quite half-dead. Probably nothing, that should be lingering in [community]. @Eric Bélanger: Are you okay with dropping electricsheep? Best, David -- https://sleepmap.de

1 1

[arch-dev-public] away from packaging duties until ~Feb '18
by Dave Reisner 15 Dec '17

15 Dec '17

Hi friends, Between the holidays as well as business trips next week and in mid January, I don't expect to have much time to pay attention to packaging duties. Stepping away for a month+ also gives me the opportunity to reduce the time I'm spending at a keyboard and nurse some RSI aggravation that I've been carrying for the past few weeks. Cheers, Dave

1 0

[arch-dev-public] Heads up: Qt 5.10 in [testing]
by Antonio Rojas 08 Dec '17

08 Dec '17

Qt 5.10 is now in [testing]. Note that, due to Qt symbol versioning schema, every Qt application automatically gets a dependency on the minor Qt version it was compiled against, so Qt applications compiled against [testing] will have to wait in testing until Qt itself moves. Keep this in mind if you plan to push any Qt application to testing.

1 0

[arch-dev-public] Packaging tasks on hold
by Alad Wenter 07 Dec '17

07 Dec '17

Hi all, Due to a continuously increasing workload this semester, my life has been very busy and I haven't been able to attend to my [community] packages as much as I'd like to. (in particular, neomutt which has been outdated since a month). As such, anyone willing to is more than welcome to update my packages. (if you would like to make more elaborate changes, let me know ahead of time via email. I am not available on IRC due to the same time constraints.) I'll still be around to handle AUR requests and handle issues on the wiki. Best wishes, Alad

1 0

[arch-dev-public] ImageMagick 7
by Jan Alexander Steffens 02 Dec '17

02 Dec '17

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

2 3

[arch-dev-public] Replace Gentoo mime-types with Fedora mailcap?
by Jan Alexander Steffens 23 Nov '17

23 Nov '17

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

3 3

[arch-dev-public] Merging multilib toolchain with [core]
by Bartłomiej Piotrowski 23 Nov '17

23 Nov '17

Hi, For a long time we have been maintaining multilib-enabled gcc package separately under [multilib] repo. Compilation takes a lot and usually it falls behind because I forget to keep it in sync with [core]. I propose to merge it with core/gcc instead and split lib32-gcc-libs. The latter would be moved to [core] due to dbscripts inability to maintain split packages in multiple repositories. On the same note, the same would happen to lib32-glibc. Any objections? Bartłomiej

4 3

[arch-dev-public] Switching the bugtracker to Bugzilla
by Jelle van der Waa 20 Nov '17

20 Nov '17

It's time to switch our to something which is maintained and can be extended to our wishes. Flyspray isn't actively maintained, has had several security issues [1] [2]. It seems to be time to move on, and Bugzilla is one of the more active and maintained bugtrackers out there. Used by several big projects such as Gnome, LLVM and Mozilla. One of the benefits of moving would be the possibility of default assignees per 'component'. # Migration There are several options for migrating the bug history to Bugzilla and a few options are under debate. (input welcome) * No migration at all * Migrate open bugs * Migrate open bugs and auto-closing them * Migrate all bugs * Migrate all bugs and auto-closing them In either case, I believe it would be nice to "archive" the current bugtracker and make it read only. # User migration User migration should be possible as well, except migrating the password, a mass password reset would be wise. Since I'm not sure what kind of old hashing method / salt flyspray uses. # Migration Projects Bugzilla has a concept of products with components, so for all our packages we can create a component counterpart. It should be possible to auto-assign bugs with the pkgname <-> maintainer information from archweb. Possible products would be. # Products * Arch packages (core/extra or split this up) * Community packages (community) * Pacman * AURWeb * Keyring * Archweb (new) * Arch VM / Docker images (new) * Release engineering Input would be welcome, on what we should migrate from flyspray and what products we should define. [1] https://github.com/Flyspray/flyspray/releases/tag/v1.0-rc6 [2] https://github.com/Flyspray/flyspray/releases/tag/v1.0-rc4 -- Jelle van der Waa

11 14

[arch-dev-public] Resigning as TU
by Evangelos Foutras 17 Nov '17

17 Nov '17

For a long time I have been inactive in TU matters (i.e.: handling AUR requests, looking into TU applicants, and overseeing community contributions in general). Due to this, I feel it's proper to let go of my TU title. No heartfelt goodbyes, since my involvement in Arch remains unchanged. (On a related note, where did the last 9 years go?!)

1 0

[arch-dev-public] [draft] The end of i686 support
by Bartłomiej Piotrowski 06 Nov '17

06 Nov '17

Following 9 months of [deprecation period][1], support for the i686 architecture effectively ends today. By the end of November, i686 packages will be removed from our mirrors and later from the packages archive. For users unable to upgrade their hardware to x86_64, an alternative is a community maintained fork named [Arch Linux 32][2]. See their website for details on migrating existing installations. [1]: https://www.archlinux.org/news/phasing-out-i686-support/ [2]: https://archlinux32.org/

6 8