Arch-dev-public November 2017

arch-dev-public@lists.archlinux.org

17 participants
8 discussions

[arch-dev-public] Improving overall experience for contributors
by Bartłomiej Piotrowski 07 Feb '19

07 Feb '19

Hi all, Spending some time outside the regular Arch circles, I realized that the way we "outreach" potential contributors is at least imperfect. One of the problems I keep hearing about is that there is no clear place where potential contributors could start. Sure, some things seem obvious to us: take care of some wiki article or adopt orphan AUR packages. It isn't actually that easy. Not everyone is interested in editing or maintaining random packages, and while there is plenty to do, how someone new could know it? We could use help not only with existing projects like archweb, pyalpm or namcap, but also with development of new code (for example a maintainable rebuild automation) and infrastructure side (which is in fact too generic term that could be better described). I am totally in love with What can I do for Mozilla?[1] which is open source, so why not steal this wonderful idea? But it also means we need a way to communicate with people interested in helping us: at least an IRC channel and new mailing list. Another thing that I heard in last few months isthat it is actually hard for potential TU candidates to find a sponsor. While I believe it is perfectly fine to e-mail few potential sponsors to ask for opinion, throwing random messages at people doesn't sound really appealing. In my humble opinion, we should rethink the way we recruit people and probably introduce fine-grained permissions to dbscripts that would allow to limit new maintainers to limited set of packages. We should also lower our expectations towards candidates. At least once we rejected one for some stupid reason (no fingerpointing here, I'm not saint either), leaving packages they wanted to adopt virtually orphan. It's better to help amn inexperienced packager gain experience than voting no, really; to be brutally honest, quite a lot of packaging work we are handling doesn't have much in common with rocket science. I also wanted to touch mailing lists vs GitHub vs Gitlab topic but we will tackle it another time. Your thoughts? Bartłomiej [1] https://whatcanidoformozilla.org/

8 11

[arch-dev-public] New build server in Singapore
by Bartłomiej Piotrowski 04 Apr '18

04 Apr '18

Hi all, for those of you that are living closer to Asia than Europe, there is new build server available, located in Singapore. It is considerably less beefy than soyuz, but should be okay for regular builds. All packagers should be able to ssh into it with username and the key used on other servers. The address is sgp.pkgbuild.com. You can compare fingerprints below: SHA256:f9VrDpIpOHvgWk+OXXRG+VMvJlbs577YFZfyxPtXKqU (ED25519) SHA256:fDdeGInsD764tfnGCbNIPH69L4k7mNs98ttFpTOv01U (RSA) SHA256:MsoXUmTXowWcPb4gma3U60Po0/5sTT5Fg+oM8bWIIUE (ECDSA) It also hosts a mirror available at https://sgp.mirror.pkgbuild.com Enjoy, Bartłomiej

3 4

[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

[arch-dev-public] aurweb 4.6.0 release preparations
by Lukas Fleischer 03 Nov '17

03 Nov '17

Hi, Since the AUR ToS documents are still being reviewed and I do not expect any major progress within the next couple of weeks, I would like to release 4.6.0 before the documents are polished (against my original plans to synchronize the aurweb release with the ToS release). Apart from proper ToS support, the current development version includes some nice features such as Markdown support in comments as well as some bug fixes. There is one change, namely commit d9883ee (mkpkglists: Generate a list of user names, 2017-08-01), which might be a bit controversial as-is. It extends the public interface to provide a list of user names (just the account names, no real name). Some members of our team expressed their concerns with making such a change without informing all registered users. Therefore, I would like to send an automated email to all registered AUR accounts, informing them on the change and giving them the chance to opt-out of the feature by deleting their accounts (all accounts with any kind of activity already reveal their user names, so people potentially concerned about making their user name publicly visible do not need their accounts anyway). Here is a draft: Dear AUR user, The next aurweb release, which will be released on 2017-12-03, includes a public interface to obtain a list of account names of all registered users. This means that, starting on 2017-12-03, your user name (only the account name you specified when registering, not your real name) will be visible to the general public. If you do not agree to this change, please delete your account by logging into the AUR web interface, going to your account details page and clicking the account deletion link before 2017-12-03. Thanks for using the AUR! The AUR Development Team If have any objections/improvements, please let me know. Regards, Lukas

3 4

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Arch-dev-public November 2017