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

[arch-dev-public] Can anyone take nvidia-390xx?
by Sven-Hendrik Haase 23 Feb '20

23 Feb '20

I don't run nvidia-390xx on any of my devices. I would appreciate it if somebody could take those drivers. I will continue maintaining the mainline nvidia package.

2 1

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

06 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] Orphaning adapta-kde and merlin tree
by Bruno Pagani 27 Nov '18

27 Nov '18

Hi there, I’m orphaning two set of packages that I no longer use: – adapta-kde/kvantum-theme-adapta split package: very low maintenance, especially since upstream Adapta is stalled; – merlin and its dependencies: cppo, dune, merlin, ocaml-biniou, ocaml-easyformat, ocaml-yojson. Those have required some time to publish and maintain, but things are stabilizing on dune side and for instance DESTDIR is now supported so all those PKGBUILD can now be simplified. Please let me know if you are interested, else I will consider dropping them back to AUR. Regards, Bruno

1 1

[arch-dev-public] Rebuilding old packages (2016)
by Jelle van der Waa 11 Nov '18

11 Nov '18

Hi all, There are rebuilds ongoing for packages build before 2017-01-01, this *should* add PIE and the newer BUILDINFO format to these old packages. And uncovers some build failures, which should be fixed and I will make a todolist for. Note, that we still not have PIE for everything :-( Packages without PIE are listed here, note that Haskell will require some research to enable PIE. Golang/Rust packages also require special treatment. [1] [1] http://pkgbuild.com/~jelle/repro_sec_status.txt -- Jelle van der Waa

2 3

[arch-dev-public] Arch Linux Cloud Images (virtualbox and Qemu)
by Christian Rebischke 07 Nov '18

07 Nov '18

Hello everybody, Some months ago Bartlomiej had the awesome idea to generate qemu and virtualbox images as well. Afterwards we had a small discussion about this topic in #archlinux-projects. I would like to refresh this discussion and move it to this mail thread. So, our vagrant boxes are building automatically and without issues for a few months now. I could just generate virtualbox and qemu images as side products monthly, but I have no idea how we would release them. Another big topic is security. The vagrant images are at the moment not signed and seems like vagrantcloud doesn't support this either. This doesn't mean that we shouldn't sign our qemu or virtualbox images. We could just generate an automated cloud image signing key (only for this purpose) of course and automatically sign the images with that key. Problem with this is: If our build server ever get pwned the person will have these keys for signing cloud images as well. Any opinion about this? In my humble opinion I would be fine with a signing key that follows only this particular purpose. Another idea would be to move the whole production process to a physical server behind a firewall that is physical accessible by one or more Arch Linux Developers. I really would like to push this forward. Any comments? Chris

4 4

[arch-dev-public] TU application process
by Christian Rebischke 06 Nov '18

06 Nov '18

Hello everybody, First of all, the following mail has nothing to do with the last two TU applications, it's a general view on the current TU application process. I would like to propose a new process for TU applications due to several reasons: 1. I have the feeling that most sponsors are not aware of the responsibility of sponsoring a new TU candidate. There is more to do than just approving their application. Candidates should get advice for and after the application process. This includes: * learning how to sign mails * getting feedback for their PKGBUILDs from their sponsoree * getting advice for building packages correctly via makechrootpkg wrappers * getting help for the post-application-process, when the candidate has been accepted. * directing the new candidates to our IRC channels or mailinglist for community intergration. 2. I have the feeling that most TUs only vote, because of our new stricter bylaws. 3. I miss more TU contribution in TU application processes as well. I guess the reasons for the points above are missing time or missing mood for actively participating in the discussion. Therefore I would like to suggest some modifications to our TU application process. Here are some ideas from a discussion we had last night in the TU IRC channel: 1. Establishing a TU council, that get elected a certain time slot. The members of this council are responsible for accepting or rejecting a TU. Every TU can still sponsor or suggest a candidate, but the voting process will be done in this council only. The council should consist out of very active TUs and devs, who are known for a good package quality. 2. Establishing a 2-sponsors-rule instead of the current policy of one sponsor. 3. <your suggestion here> Best regards from Germany chris / shibumi

7 10

[arch-dev-public] New permissions on ArchWiki
by Alad Wenter 02 Nov '18

02 Nov '18

Hi everyone, New user groups have been deployed to the wiki (thanks to Dario and Bluewind [1]), and I've started migrating DeveloperWiki and the developer accounts accordingly. More information on the groups can be found at [2]; I will give a short summary below. 1) DeveloperWiki pages can now be edited by the "cosysop" group, the former group for wiki maintainers. It is a weaker form of "sysop" or the group meant for purely administrative tasks such as deletion of pages. As such, I have added the "cosysop" group to developer wiki accounts. To avoid extraneous permissions on the wiki where they would otherwise not be required, "sysop" rights were removed from these accounts if present. If for some reason you still require the "sysop" right, please send me an email off-list. User rights may be viewed under [3]. 2) The "cosysop" and "sysop" groups are distinct from the "roles" as we commonly know them. In particular, every TU is now part of the "archtu" group, every staff member of the "archstaff" group, and every developer part of the "archdev" group. These groups in themselves have no additional permissions, and serve for easy identification of staff members on the wiki. 3) When groups are changed on a wiki account, the owner is notified with an email that his user page has changed. [4] However, no changes are visible in the history. This appears to be a bug in MediaWiki. If there are further questions, please let me know. Alad [1] https://github.com/archlinux/archwiki/pull/20 [2] https://wiki.archlinux.org/index.php/ArchWiki:Access_levels_and_roles [3] https://wiki.archlinux.org/index.php/Special:UserRights [4] https://ptpb.pw/2rj0

1 0