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

[arch-dev-public] Archweb migration
by Jelle van der Waa 08 Feb '19

08 Feb '19

Hi All, Tommorow night (CET) I will update archweb (archlinux.org) to Python 3. We've already tested it on a staging server and it seems to work well so tommorow I'll update it on our main server. This will mean that archlinux.org will be unavailabe for ~ 30 minutes since the upgrade requires some manual work with removing and creating a new virtualenv. -- Jelle van der Waa

1 1

[arch-dev-public] Improving overall experience for contributors follow up
by Jelle van der Waa 06 Feb '19

06 Feb '19

Hi, I still believe we should take some initiative on thse issues. What we have so far is: - Getting involved page, not sure where it's linked from? Only findable on the wiki. [1] Which links to a nice list of projects with an already dedicated irc channel and mailing lists. (I was not even aware of #archlinux-projects). But does anyone ever find this page? I think we should at least link it from archlinux.org. - The mozilla idea, I'm up for it? Should we host it under whatcanidofor.archlinux.org? Note that this also requires some effort from the team's side. We should however keep our bugtracker tidy and maybe label "new contributor" tickets since this is quite crucial to get new people in. I however have also some thoughts on things which these days have no tickets, but could be worked on for example: - revamping the Ruby guidelines. They should be as nice as the Python ones - Hardening our custom systemd services and creating bugs with patches, for example grafana has hardening applied now. [5] - Man pages for more devtools binaries. I'm quite sure others others have such projects on their mind which are not publicly findable yet. (sogrep to devtools for example) [1] https://wiki.archlinux.org/index.php/Getting_involved [2] https://wiki.archlinux.org/index.php/DeveloperWiki:Projects [3] https://github.com/archlinux/archweb/issues [4] https://github.com/archlinux/pyalpm/issues [5] https://git.archlinux.org/svntogit/community.git/tree/trunk/grafana.ser= vice?h=3Dpackages/grafana P.S. sorry for splitting up into a new thread, but it seems replying makes spamassasian mark my reply to the thread as spam. -- Jelle van der Waa

3 2

[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] Away until Feb 11
by Bartłomiej Piotrowski 25 Jan '19

25 Jan '19

Hi all, I'm trying to run away from winter so I'll be away starting Wednesday. I will be partially available via IRC/e-mail but I don't plan to do any packaging. Bartłomiej

1 0

[arch-dev-public] FOSDEM 2019
by Morten Linderud 24 Jan '19

24 Jan '19

Yo! Last year at FOSDEM we where quite a few members from the Arch team present, and I though it would be nice to have a dinner together! My suggestion is to do it Friday around 18:00 then head for the beer event at delirium afterwards. To make it managable I'll cap the attendees to 15 people. Priority for members of the Arch team (developers, trusted users and support staff) and any free spots after this can be taken by anyone interested :) Please send an email so I have some ability to keep track. If Friday does not fit for some people in the team, please write if saturday or sunday fits better. If multiple people arrive super late we could move things around, or have multiple dinners! Restaurant suggestions are also welcome! (I have CC'ed arch-dev-public since I don't actually know how many people watch arch-events. Sorry for the noise!) -- Morten Linderud PGP: 9C02FF419FECBE16

5 5

[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