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

[arch-dev-public] Mishandle of the 'Use gpg signatures and https sources' TODO list
by Filipe Laíns 24 Jan '19

24 Jan '19

Hello, In the process of updating the 'Use gpg signatures and https sources' TODO list, packages which weren't using https in their 'url' field were also added. This changes were reversed and a new TODO list was opened. Sorry for the trouble. Thanks, Filipe Laíns 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2

1 0

[arch-dev-public] Mongodb and SSPL
by Morten Linderud 18 Jan '19

18 Jan '19

Yo! As probably some of you have realized, there is a discussion regarding mongodb and the relicense from AGPLv3 to SSPLv1. RedHat has dropped it from their repository[1], and Debian is assumed to follow suit[2]. This is mostly due SSPL not being considered a free-license. It is currently being reviewed by OSI for inclusion, but it is not looking bright currently[3]. The OSI discussion is for SSPLv2, but it's my understanding that they are essentially the same license with some fixups. Obviously, we don't care about the license being free nor OSI compliant. We only care if we are allowed to redistribute or not. Link to the current license text as of mongodb release 4.0.5: https://github.com/mongodb/mongo/blob/r4.0.5/LICENSE-Community.txt There is nothing in the SSPLv1 license text that prohibits us from distributing mongodb. There are however special requirements in the license we have to abide if we want to distribute modified source code. Currently the PKGBUILD does a few sed's in the source to build it. I believe this constitutes as modified source code under "0. Definitions". To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work. Under section "5. Conveying Modified Source Versions" the most relevant part for us is section "a)". a) The work must carry prominent notices stating that you modified it, and giving a relevant date. Which means we need to give some heads-up that the source is changed. The next section is "6. Conveying Non-Source Forms" where I am unsure what applies to us. One way to distribute the modified source is required, where 5 possible options are listed. I think "d)" fits us, where we can host a source package on `source.archlinux.org`. But I'm frankly a bit unsure what the entire paragraph entails for us. Some more input on this section would be great. The bugreport FS#61394 is already submitted requesting a license change from AGPLv3 to SSPLv1, so we should probably figure this out before changing the license appropriately[5]? -- Morten Linderud PGP: 9C02FF419FECBE16 [1]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-be… [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915537#15 [3]: https://opensource.org/LicenseReview122018 [4]: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=pack… [5]: https://bugs.archlinux.org/task/61394

3 3

[arch-dev-public] [rb-general] Arch Linux reproducible package archives
by Eli Schwartz 13 Jan '19

13 Jan '19

In the effort to have reproducible builds, it is important to have availability of all dependent packages listed in the .BUILDINFO description of a built package. Due to previous efforts within Arch Linux, we do have a daily snapshot of the repos, but this could potentially result in missing packages if they were added and then removed during the course of a single day, and thus never showed up in a snapshot. I'm happy to say that this past Friday, I have upgraded the dbscripts to automatically archive every built package as a core part of our repository release scripts. Additionally, the dbscripts will now check each package before allowing it to be uploaded, to ensure that all installed packages in the .BUILDINFO are actually available. If a package is not available then the update will be rejected. For more details, see https://git.archlinux.org/dbscripts.git/commit/?id=f11a038c43270a70eafdba34… Of course, none of this guarantees that a package can be reproducibly built. However, it does ensure that we know exactly what input went into building the package, and paves the way for tools which utilize these dependent packages to test a package for reproducibility. Happy packaging! :) -- Eli Schwartz Bug Wrangler and Trusted User

1 0

[arch-dev-public] Ongoing rebuilds; keep [staging] clear
by Evangelos Foutras 10 Jan '19

10 Jan '19

The following rebuilds will be taking place in the following days: - readline - mariadb - boost - exiv2 - libidn2 - poppler Please avoid starting any new rebuilds until these are done.

1 0

[arch-dev-public] Looking for maintainer for mkinitcpio/a-i-s
by Dave Reisner 17 Dec '18

17 Dec '18

Hi, I'm finding myself lacking these days in both time and motivation to continue maintenance of both mkinitcpio and arch-install-scripts. Is anyone interested in taking these over? Both projects are fairly stable, but bugs do crop up as the rest of the OS evolves. dR

4 3

[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