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

[arch-dev-public] Proposal for a new organisation structure
by Christian Rebischke 03 Jun '19

03 Jun '19

Hello everybody, ---------------------------- DISCLAIMER: Sorry for the huge mail, I didn't thought it would get so long. If you feel attacked/angry or whatever about it, take a deep breath before you answer. I hope for a constructive discussion without personal attacks. ---------------------------- inspired by the last thread about moving proprietary software to community, our general problem of getting more people involved in Arch Linux and the (for me) chaotic organisation structure and hierarchy I would like to propose a discussion about changes. Please don't see this thread as an attack on your current position or whatever. I would like to propose a more democratic, simplified and more contribution friendly approach for our current hierarchy and organisation structure. At the moment we have the following three Groups (If I miss something feel free to correct me): - Devs - Trusted Users - Support Staff These three groups have the following 'features' and tasks: - Devs: - Tasks: The developers care about [core] and [extra] repositories, they form a direction for the whole project 'arch linux' and they seem to have a veto-permission for TU decisions. Furthermore they have access on most infrastructure and they are maintaining/developing the core software like pacman. Some devs also care about trademarks, legal requests and finance or community events. - How to be a developer?: The developers will decide in a non public and secrete ritual who is worthy to be a developer. The process is unclear. - Trusted Users: - Tasks: The trusted users care about the [community] repository, somehow some TUs have more tasks like: security team involvement, wiki administration, infrastructure administration, maintainership of software projects and other infrastructure projects like docker images, reproducible builds etc. Furthermore they care mostly about the package quality in the AUR (eg. answering submitted requests...) - How to be a trusted user?: It's well documented, we have rules for misbehavior, rules for applying, guidelines for moving packages into community and more. - Support Staff: - Tasks: They do various tasks like infrastructure administration, wiki administration, bug wrangling, software contribution, forum moderators, security team, but they have no access to any repository. - How to be a support staff: It's unclear, mostly a new contributor just knows the right people and does the right thing at the right time and get somehow acknowledged by developers or TUs for their work. Ok, I hope this gives a good overview over all three groups. Besides these groups, we have also people in more than of these groups. Anthraxx is for example listed as (dev,tu and support staff) on our website, I am listed as (tu and support staff) and so on. So what is my actual proposal. Well my proposal is to simplify the whole organisational structure, tear down bureaucracy, tear down 'walls' and unify the community and make it easier for 'outsiders' to contribute to the project we all love. Therefore I would like to propose a discussion around the following things: 1. Simplified repositories Currently we have [core], [extra] and [community]. These three repositories are there, because they have grown to this structure over time. At the moment I don't see any real meaning for the split of [core] and [extra]. So one suggestion would be to either: - merge [extra] and [core] - or use [extra] for a new purpose, like for example a proprietary repository, for all proprietary software. (I know that this is not possible for all packages, because we have binary blobs in device drivers and kernel modules). 2. Repository access At the moment a TU can access all packages inside of the [community] repository. Therefore they are able to modify packages in a good or bad manner. This can have nice effects and bad effects, how the past has shown to use, such as: - rapid updates in case of security vulnerabilities (good effect) - updates of packages, because somebody thought it needs an update, but the real reason for the delay was a bug inside of the new version of a software (bad effect) 3. Organisation structure Depending on the repository access, we could reduce our organisation structure to just two groups: Devs and maintainers (a similar approach to big distributions like Debian). Devs could still have the 'superpower' for caring about infrastructure and legal/finance stuff and the group of trusted users and support staff would merge to one group of maintainers. With person-related access to package repositories we could tear down the whole repository structure to one, maybe two, repositories and we could give co-maintainership an actual meaning (permission to modify a foreign package). 4. More transparency At the moment the recruiting process for developers is pretty unclear, as well as the actual decision making inside of the developers group, veto permissions and other things. This leads to a 'they vs/with us' thinking and makes it difficult to increase contribution in the community. Therefore I would like to propose more transparency for all groups who are involved in Arch Linux development and more communication between devs and TUs. At the moment the devs will mostly say:"Ok, this is a TU thingie, so I don't need to get involved in this question regarding TU rules or rules for community or anything else". It would be also nice to form an actual roadmap (yes.. I know.. we are not a company, but a roadmap or overview over all current projects inside of our community would be nice). This way it would be also easier to contribute for 'outsiders'. Sorry for the huge mail, I didn't thought it would get so long. If you feel attacked/angry or whatever about it, take a deep breath before you answer. I hope for a constructive discussion without personal attacks. Best regards and many thanks for reading the whole mail, shibumi / chris

7 11

[arch-dev-public] bringing vivaldi browser to community
by Ike Devolder 02 Jun '19

02 Jun '19

3 years have passed since I first proposed to bring vivaldi into community. Now there is a clear differentiation between what vivaldi offers out-of-the box compared to other browsers. Vivaldi offers a ton of customisation features out of the box, and is also able to just use the chrome/ium addons from the chrome webstore. Personally I'm using vivaldi as my main browser since somewhere in 2015 (shortly after the first beta was released) and the key features no other browser currently offers are: - webpanels - quick commands - tabtiling - tabstacking - tabbar positioning I'll bring it in the same way as with opera, where you have the webbrowser + separate packge with libffmpeg.so to allow the playback of proprietary formats like mp4.

4 9

[arch-dev-public] GCC 9 removed from [testing]
by Bartłomiej Piotrowski 02 Jun '19

02 Jun '19

Hi all, I just deleted GCC 9 and related packages from [testing] due to the filesystem corruption bug when bcache is used[1]. You will have to -Syuu your systems. People hungry for breakage can install it from [gcc9] repo I uploaded to pkgbuild.com: [gcc9] Server = https://pkgbuild.com/~bpiotrowski/gcc9/ Bartłomiej

3 5

[arch-dev-public] Create guidelines regarding SIMD instructions/x86 extensions
by Filipe Laíns 25 May '19

25 May '19

Hello, Currently there are no guidelines stating which x86 extensions (ex. SSE2, SEE3, SSE4, AVX, etc.) we support. This is a bit problematic since it lets compilers do what they want and possible generate code that can't run on some systems. Even though this is an issue, it's not complete anarchy, at least yet! Just kidding :p. The vast majority of our native packages are compiled with GCC and we do default to `-mtune=generic` which is good but not optimal. `-mtune=generic` tells GCC to compile for a generic processor so it's up to GCC to decide which architecture extensions would compose a generic processor. I haven't been able to find any documentation on what x86 extensions are enabled for a "generic" processor but I was able to track them down to MMX, SSE (or KNI) and SSE2. Being undocumented they could change at any time so I don't think we should rely on `-mtune=generic`. What I propose is to define a set of x86 extensions to support and make all compilers default to that if possible. I am fine with MMX, SSE and SSE2 but they should be *our* choice, not GCC's. This begs the question, would such approach be doable? So I ask the compiler maintainers to please check if this would be possible. I would also like to explore the idea of adding an "high performance" architecture which would be able to make use of SSE{,2,3,4,4.1,4.2} and AVX, which seem to be the standard for newer processors (>=2013). This would only be available for packages that do high performance computing (ex. openblas, sdrangel, etc.). Any thoughts on this? Thanks, Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2

4 10

[arch-dev-public] Dropping nvidia-340xx series
by Giancarlo Razzolini 17 May '19

17 May '19

Hi All, As you might be aware, this last kernel broke (again) the nvidia-340xx driver. Usually when this happens, it delays our kernel or we end up pushing a kernel without the driver. We have to wait on nvidia to fix it or we have to use patches that are not always trivial, nor there is enough people working on them. Up until four months ago, however, I was always testing this on actual hardware. But, that machine do not have a monitor on it anymore. And, the card itself is troublesome, it sometimes make the whole machine crash when it heats. Having said this, I'm going to orphan the package in a couple of weeks, if nobody is interested in maintaining it. But, I would propose this package get dropped to the AUR so someone with the actual hardware can maintain it. P.s: Ironically I used the (almost) exact subject Felix use almost 3 years ago when proposing this. Cheers, Giancarlo Razzolini

2 1

[arch-dev-public] TeXLive 2019 packages in [testing]
by Rémy Oudompheng 12 May '19

12 May '19

Hello, TeXLive 2019 packages have been added to [testing] This includes a rebuild of packages which depend on libsynctex as there is a soname bump (evince, qpdfview, zathura). Please notify me if you see anything wrong. Regards, Rémy;

1 0

[arch-dev-public] nodejs 12 removed from [community-testing]
by Felix Yan 07 May '19

07 May '19

Binary packages do not build as nan doesn't support the new version yet [1]. nodejs 11.15.0 has been pushed to [community] instead. [1] https://github.com/nodejs/nan/issues/849 -- Regards, Felix Yan

1 0

[arch-dev-public] Away until May 11
by Christian Hesse 03 May '19

03 May '19

Hello everybody, I am on vacation until May 11. I have my notebook and a lte router with me, but I am not sure what my spare time and quality of internet connectivity will look like. Feel free to touch my packages if required. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 0

[arch-dev-public] Dropping Qt4
by Antonio Rojas 29 Apr '19

29 Apr '19

Hi all, Now that mumble has been ported to Qt5, I think it's time to finally drop Qt4, which has been EOL for 4 years. Most stuff that still depends on it has been dead upstream for many years. Here is a full list of applications (not libraries or plugins, which can be dropped once applications are gone): clementine - Qt5 port exists in git for years but no release - some distros ship a git snapshot, there's also the strawberry Qt5 fork fbreader - There's a patch to port to Qt5 in AUR https://aur.archlinux.org/packages/fbreader-qt5/ freemat - Last released 6 years ago, there seems to be a Qt-free version at https://sourceforge.net/p/freemat/code/HEAD/tree/branches/FreeMat5/ but with no activity for 2 years gebabbel - Last released >10 years ago, gpsbabel already provides a Qt5 UI gnuradio - Qt UI can be disabled until it is ported hydrogen - Qt5 beta version (>1 year old) available keepassx{,2} - We have keepass and keepassxc already launchy - Qt5 fork available at https://github.com/Slesa/launchy/ openssh-askpass - can actually be compiled with Qt5 qmpdclient - Last released 8 years ago, many alternatives available tipp10 - Qt5 fork available at https://gitlab.com/a_a/tipp10/ tuxcards - Last released 9 years ago, many alternatives available v4l2ucp - Last released 9 years ago I propose to move those who can to Qt5 forks, and disable the Qt5 bits (if possible) or completely drop the other ones. Any objections?

4 3

[arch-dev-public] Unmaintained packages from Dan
by Jelle van der Waa 28 Apr '19

28 Apr '19

Hi all, We have some packages which used to be maintained by toofishes which he no longer seems to take care of. So if anyone is willing to maintain these packages, please adopt them, if they need to be moved to [community] for a TU, ping me. The packages are: * munin{,-node} * numactl * irqbalance * cvsps * csope * nilfs-tools (I added myself as co-maintainer but I don't really use it) Also look at the bugtracker for old bugs, munin for example has a bunch

2 1