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

[arch-dev-public] Arch Conf
by David Runge 12 Dec '18

12 Dec '18

Fellow Archers! Some of us (in #archlinux-conf) are thinking of organizing an event for our community: A new Arch Conf! We would like to do a conference (earliest in the 2nd half of 2019), that concentrates on our internal community: The developers, trusted users and support staff. Most of us have never met in real life, which would in itself be quite nice to change. However, we also have many issues and challenges to tackle in Arch Linux. Doing a dedicated conference (in the scope of two days) again [1] seems to be a good starting point! As many of us live somewhere in central Europe, countries such as Germany have been taken into consideration. We looked at some free and paid locations in Berlin and Hamburg and Delft (The Netherlands), but nothing is decided yet. We are currently trying to figure out options for sponsorship, as we would also like to be able to (help) fly in developers from further away (without compromising). For this we would like to get more input from you. We were thinking of involvement for topics e.g. from the DevOps and security teams, but also more broad subjects, such as package repositories, bug tracker, wiki, etc. An Arch Conf will of course not only require involvement in the form of presentations and workshops, but volunteers to help prepare and handle a potential location and the event itself. Also, there should be video streaming (e.g. the VOC [2] offers free services for free software conferences) for those that can't be there. We would like to get some input from all of you regarding time, space and scope :) [1] https://web.archive.org/web/20130313105945/http://www.archlinux.ca/archcon2… [2] https://c3voc.de/ -- https://sleepmap.de

3 2

[arch-dev-public] Access to CNCF community cluster
by Bartłomiej Piotrowski 12 Dec '18

12 Dec '18

Few months ago I asked on arch-dev whether we would like to ask for access to Cloud Native Computing Foundation cluster, which we could use to experiment with automated package builds (or anything else really). Following no response I actually did so anyway[1] and I have been invited to CNCF organization on packet.net, where we can spawn new dedicated machines for fun and profit. Obvious caveat is that we are guests and shouldn't abuse it; less obvious one is that packet.net does not support Arch out-of-the-box but it can be achieved via PXE and cloud-init (currently residing in AUR?). I just realized I never communicated this properly so here it is. Let me know if there's anything you would like to try. Bartłomiej [1] https://github.com/cncf/cluster/issues/85

2 1

[arch-dev-public] HEADS UP: Qt 5.12 in [testing]
by Antonio Rojas 06 Dec '18

06 Dec '18

The usual reminder that, due to Qt's ABI versioning, any Qt application built against 5.12 will depend on it, so it will need to stay in testing until Qt itself moves.

1 0

[arch-dev-public] Bug Day
by Jelle van der Waa 03 Dec '18

03 Dec '18

Hi All, I propose we hold another (in)famous bug day on the first weekend of January i.e. 5th and 6th of January. To start the new year with a cleaned up bug tracker. -- Jelle van der Waa

2 2

[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

[arch-dev-public] .gnuog owned by root when using devtools in first place
by NicoHood 13 Oct '18

13 Oct '18

I ran extra-x86_64-build on a new system with an uninitialized gnupg keyring. I think it was responsible for creating a .~/gnupg directory, but with root privilegs. I chowned it to my user, it is all good now. Maybe the script could be improved to check if the gnupg keyring was initialzed or not, to prevent such issues. I was confused in the first place. ~Nico

2 1