[arch-dev-public] Transparency report May 2020

[Levente Polyak via arch-dev-public]

# Transparency report May 2020


## Staff

### TU addition

We are happy to welcome Frederik aka freswa among the Trusted Users [0].
Some of you may already know him as one of our bug wranglers where he
joined forces in February 2020.


## Packaging

### Go

The Go package guidelines [1] have been overhauled and in conjunction
the go-pie package has been removed [2]. The major difference is a new
set of CGO/GOFLAGS that ensure all our distro flags are respected
appropriately, leading to Go binaries with RELRO, PIE and fortify
hardening. A to-do list to reflect these changes is pending.

### CMake

The CMake package guidelines [3] have been created which describe some
important bits to consider when packaging software using cmake. Most
notably appropriate release type option that may otherwise have
undesired effects, removal of non required RPATH usage as well as some
convenience options to build in subdirectories without manually creating
them. As CMake still does not respect CPPFLAGS itself, which results in
fortify hardening being ignored, a temporary patch [4] has been added to
circumvent this misbehavior, a to-do list to reflect these changes is
pending.


## Reproducible builds

You may have noticed a couple of large rebuilds that occurred recently.
These fixed issues of non-reproducible file ordering with old versions
of makepkg. This and other hard work by the team improving our tooling
and fixing packaging issues has resulted in 96% of [core] being
reproducible, and 90% of [extra]. You can see the status of which
packages are reproducible here [5]. A full progress report can be found
on the corresponding thread [6] on arch-dev-public.

We have set up a fleet of three rebuilderd [7] runners to continuously
test our distributed repository packages and populate our status page
[8]. Some integration into archweb to indicate the current
reproducibility status is planned.


## Infrastructure

### GitLab

We're in the process of switching our Git hosting from our custom cgit
instance to GitLab! We created https://gitlab.archlinux.org [9] and have
started moving some projects. We'll continue moving projects onto GitLab
and will then get rid of our cgit instance.

Users can currently not collaborate with us on GitLab as we still need
to get some monitoring in place to make sure we can keep a close eye on
usages to ward off abuse. However, we're planning on doing this soon and
then we'll open up GitLab to everyone. Finally you can collaborate on
Arch like it's 2020!

We're also going to use GitLab for other things such as bug tracker
(instead of Flyspray), Kanban board (instead of Kanboard), and service
desk (for GDPR requests and such).

### Single-sign-on/Keycloak

Arch operates many different services - all of which with their own
login systems and account databases. This is not ideal from a security
and convenience standpoint. We'd like to enforce the same security
requirements for all users while also allowing everyone to use the same
account to log in to all of our services. It'll also finally allow you
to use 2-factor authentication for all Arch services.

We still have a long way to go here in terms of integrating all services
via SAML/OIDC and figuring out how to let users continue using their old
accounts.

### SVN to Git migration

The git migration plans have been picked up again, and started working
towards a proof-of-concept implementation [9]. This would allow
packagers to avoid the SVN mono repository and manage each package as a
separate git repository, and facilitate some modernization of our
current tooling.
More information about the plans and implementation will hit the
[arch-dev-public] list in the upcoming week.


## Projects

### Archiso

The archiso project has been moved [10] to Arch Linux' GitLab instance
[11]. Furthermore over the past weeks smaller and larger fixes found
their way into the repository. In the future all merge requests and
releases will be handled via GitLab. CI integration and more elaborate
test suites are still being developed to ensure a more robust setup for
our monthly release images and any custom use cases.

### Pacman

Initial support for parallel downloads landed in the pacman [12] code
base, requiring large changes to the codebase. Many patches providing
the finishing to this feature have been submitted. Once the code churn
around this feature request has slowed, we will make a beta release for
wider testing.
Additionally, one obscure area of non-reproducility in packages was
discovered through the Arch Linux reproducible builds effort, and
subsequently fixed in makepkg. Furthermore, the move from using
autotools to meson for the pacman build system was completed. Discussion
is ongoing on moving the pacman codebase to the Arch Linux GitLab
instance, with initial CI setup being added to the codebase.


## SPI

For the upcoming SPI annual report 2019, a section about some of Arch
Linux achievements has been assembled to represent our project. A link
to 

Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS

[Levente Polyak via arch-dev-public]

On 5/14/20 9:46 AM, Morten Linderud wrote:
> On Thu, May 14, 2020 at 09:39:58AM +0200, Levente Polyak via arch-dev-public 
> wrote:
>>> At the end of the month I'll make a todo with the remaining packages 
>>> depending
>>> on `go-pie`.
>>>
>>> The complete future Go PKGBUILD is attached to this email below.
>>>
>> PS: shouldn't we look into Go getting those flags as well? The Go
>> compiler itself doesn't have RELRO and fortified sources :)
> 
> Because everything, sadly, breaks. I'd much rather try look into 
> reproducibility
> before actually caring about binary hardening.
> 
> If we PIE compile the test suite upstream fails quite badly. Evidently 
> upstream
> doesn't test the go compiler with PIE/RELRO enabled. Unsure if they care at 
> all
> even. If we also try define `CGO_CFLAGS` we end up with errors like:
> 
> /usr/include/features.h:397:4: error: #warning _FORTIFY_SOURCE requires 
> compiling with optimization (-O) [-Werror=cpp]
> 
> `-buildmode=pie` is also going to land you in trouble with the race detection 
> in
> their test suite.
> 
> So not quite there yet for the compiler itself.
> 


/o\ @ upstream

not sure what else to say :P

If you wanna take an adventure in the future, feel invited to ping me
for the ultimate quest to explore the rabbit hole in detail and maybe at
least get RELRO or something.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS

[Levente Polyak via arch-dev-public]

On 5/13/20 10:16 PM, Morten Linderud via arch-dev-public wrote:
> 
> If there are no objections, I'll probably merge the guidelines this weekend
> section-by-section to make the wiki admins happy. The new package should land
> sometime nextweek.
> 

Awesome, thanks a lot this is a great step to improve the security of Go
applications on a binary level.


> At the end of the month I'll make a todo with the remaining packages depending
> on `go-pie`.
> 
> The complete future Go PKGBUILD is attached to this email below.
> 
PS: shouldn't we look into Go getting those flags as well? The Go
compiler itself doesn't have RELRO and fortified sources :)

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] libx11/xorgproto dependency

[Levente Polyak via arch-dev-public]

On December 21, 2019 9:41:46 AM GMT+01:00, Andreas Radke via arch-dev-public 
 wrote:
>With this move I've "fixed" libx11 no more depending at runtime on
>xorgproto package. I think no headers belong to an end user system and
>the libx11 library itself doesn't depend on it. But we also ship
>libx11-devel part inside the package and this indead depends on
>xorgproto headers. The libx11 .pc file clearly wants to have the
>headers
>installed. In the past it was enough to include libx11 to also pull in
>the proto headers at build time. This is now broken. Some devs call
>libx11 broken though only its -devel part is.
>
>After some discussion on IRC these solution are possible:
>
>a) revert to make libx11 depend again on xorgproto headers. This is the
>pragmatic way and would not need any further work. It just installs
>header files to the user system that aren't needed in any way there. So
>we did in the past and I don't really like it as it's not correct to
>me.
>
>b) stay with changed libx11 and add xorgproto to packages that check
>for any of its headers. This needs to be done to an amount of ~300
>packages when hitting build errors over the next time.
>
>c) go an unusual way here and split libx11 into libx11, libx11-devel
>depending on xorgproto and maybe even libx11-xcb. This is the way
>distros go that support splitting libraries. It's probably the
>technical correct solution but will also require packages to
>makedepend on libx11-devel and save us no work.
>
>Other distributions have chosen what they prefer. That a decision that
>needs to be done downstream.
>
>I'd like to have either solution b) or c) in Arch to have a clear
>and more "transient" build time dependency. I guess it may help us
>also in the future when moving some day away from Xorg to its
>successor.
>But if majority wants solution a) back I'm fine reverting this change.
>
>Please vote.
>
>-Andy



I'm voting for b) or c).
If there aren't really any further deps, personally to me it doesn't really 
matter
too much to combine them, however for compile additions I prefer independence.
btw we also have xorg-server-devel

Cheers
Levente

[arch-dev-public] Information about the base meta-package

[Levente Polyak via arch-dev-public]

Q: Why has this been implemented so suddenly?
A: That's a good question, while we have discussed this topic multiple
   times in the past and also issued a concrete proposal to arch-dev-
   public (plus its follow-up summary) no further steps were taken to
   get something testable. However, during arch-conf in Berlin, the
   general enthusiasm and acceleration of the group was so strong, that
   we have warp-10 driven this task. We acknowledge that this could have
   been handled more carefully, but in the spirit of arch-conf please
   excuse us and bear with us. For instance, we could have noticed
   during a test phase the consequences of not having systemd-
   sysvcompat. For the time being, we have added it to the base package
   as the implications were not explicitly desired and discussed
   beforehand, however that topic will be covered in a follow-up.

Q: Why has the group been superseded by a meta-package?
A: The difference with the new base package is that this defines the
   level at which we tell you, you have modified your system
   sufficiently that you break it, you bought it -- it is your
   responsibility to debug issues caused by your overriding basic
   assumptions of the system.
   This has theoretically already been the case before this change as

   packages in the old `base` group were expected to be installed by a
   lot of packages. On the other hand, it has never explicitly been
   stated that this indeed is a requirement. The consequence is that
   packages may potentially misbehave or fail to properly install.

   Following this reasoning, it's a very natural choice to use a meta-
   package. It allows us to reflect changes (additions or removals) in
   the required package set straight on user installs with the next
   system upgrade which allows preserving the consistency of those
   assumptions. A simple example would be the systemd package, no matter
   what use-case you have (like a tiny container) we assume you must
   have systemd installed as its being relied on (sysusers, tmpdirs,
   etc.).

Q: Why has it been shrunk down and doesn't contain $package anymore?
A: The base meta-package is meant to be the lowest common denominator
   across different use-cases like desktop usage, bare-metal server or
   container runtime and therefore defines the foundation people can
   build their desired environment upon. The old base group did not just
   contain too many unnecessary packages for us to reasonably be able to
   call it the lowest common denominator, it was also inconsistent (for
   example it shipped reiserfsprogs but not btrfs-progs).

   After reflecting on all of the feedback so far, it also became quite
   clear that the old base group was kind of misused as a poor man's
   installer. There is nothing wrong with such a use case per se, but if
   there is a desire to solve this on our side, we should find the
   optimal solution instead of just sticking to some legacy. Be it an
   actual installer, something like a base-extras group, or nothing at
   all, it is out of scope here, but we should look into it separately
   -- so maybe its a bit of xkcd#1172.

Q: Why couldn't we just add a new package and leave the base group as it
   was?
A: The primary reason is that base (as the name indicates) shall be the
   minimal foundation and denominator of different use-cases. If we
   would introduce anything other than 'base' to fulfill this job, like
   base-system, base-minimal, base-foundation, or whatever one could
   come up with, it wouldn't get the point across as clearly as the name
   'base' itself. The historic knowledge is mostly responsible for our
   bias here, but it is clearly easier to grasp the intention compared
   to the difference between having `base` and `base-minimal`.

Q: Should we update the dependencies of our packages to depend on base
   instead of on its members?
A: Nothing has changed in that regard and there is no strict rule for do
   or don't yet. This is in general more related to the topic of
   transitive dependencies which needs to be discussed eventually. My
   recommendation is to just keep the members that are a first-level
   dependency because there is absolutely no point in making every
   single package in the universe depend on the base meta-package.
   However, it can be correct, clean and useful to list your first-level
   dependencies explicitly instead of not at all.

Q: What happens next, are there any plans?
A: The most important part was getting this abstract out to provide
   information and aid in resolving some of the confusion. The next
   steps will include multiple follow-up topics to iterate over and
   decide case by case -- for example how we want to handle systemd-
   sysvcompat and other topics that emerged.


cheers



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Retiring as a Trusted User

[Levente Polyak via arch-dev-public]

On 10/2/19 11:10 AM, Florian Pritz via arch-dev-public wrote:
> Hi,
> 
> I no longer have the time necessary to properly handle actual TU duties
> so I am retiring my TU hat. I will still continue maintaining some
> packages I have in [community] via my developer hat.
> 
> That said, I'd like to orphan some of them too. If anyone is interested
> in taking over one of these packages (and its dependencies), please feel
> free to adopt it and tell me so that I can orphan it.
> 
> asciidoc
> filezilla libfilezilla
> gcolor2
> gmrun
> obconf
> openbox
> openshot libopenshot libopenshot-audio
> pydf
> slock
> tipp10
> vimpager
> xplc
> zim
> 
> Florian
> 

Hey Florian,

I could take care of:

asciidoc
filezilla libfilezilla
vimpager

feel free to stay packager if you can afford a bit of time sometimes,
more is better.

cheers,
Levente

Re: [arch-dev-public] Follow-up on the “Proposal: minimal base system”

[Levente Polyak via arch-dev-public]

On March 18, 2019 8:39:45 AM GMT+01:00, "Bartłomiej Piotrowski via 
arch-dev-public"  wrote:
>The previous discussion doesn't answer (or even if it does, I don't
>care
>to re-read it at this point) if the idea behind the new metapackage is
>to be implicit dependency of all packages or just optional thing like
>base group always was.
>
>Currently maintainers either put actual dependencies into depends=(),
>including glibc if something dynamically links to libc.so or assume
>that
>base is group expected to be present on every installation, which I
>wholeheartedly disagree with, because I can just instead use Slackware
>if I weren't caring about dependency system.
>


I don't quite see why we are pulling together two topics into one, implicit or 
no implicit dependencies are NOT depending on the metapackage in any mean. It's 
just a consistent and proper way to handle dependencies of that base. It is 
free to exist with or without explicit dependencies.
I frankly am on the no imicit dependency front and my packages depend on glibc 
as well still I want to make that base a properly dependency handles meta 
package. As we are drifting up here to the transitive dependencies topic let it 
be separated from the original topic, base is about the foundation for a system 
but as metapackage to have actually meaningful dependency handling of that set. 
Implicit dependencies are something else.

Cheers
Levente

Re: [arch-dev-public] Follow-up on the “Proposal: minimal base system”

[Levente Polyak via arch-dev-public]

On March 17, 2019 11:13:31 PM GMT+01:00, Gaetan Bisson via arch-dev-public 
 wrote:
>[2019-03-17 19:07:23 +0100] Bruno Pagani via arch-dev-public:
>> This is a follow-up on the last month discussion about a “minimal
>base
>> system”.
>
>Creating a new thread removed from the discussion we had a month ago
>just makes it so much harder for all of us to remember what everyone's
>arguments and counter-arguments were. Please do not do this. For my
>part, I thought we had reached consensus with Allan's message:
>
>   
> https://lists.archlinux.org/pipermail/arch-dev-public/2019-February/029471.html
>
>Summary: You propose what you want your new group to be (metapackage,
> list of dependencies, etc.) and we adopt this as the new base.
>
>If that is not satisfactory to you, please reply to that specific
>message and say why. That would have been far more constructive than
>your present message which rehashes some of the discussion we've
>already
>had and adds new questions I have no idea where you're going with.
>


I thought so too, also don't really see why we need a different set than the 
one already proposed but curious to hear.
I just didn't went any further yet to give more 
time for people to potentially talk about 
something not yet mentioned. I don't quite see
why we are facing something very time critical 
here so it's fine to wait a bit and give people
enough room to feel comfortable with this
whole change. 

Cheers,
Levente

Re: [arch-dev-public] Proposal: minimal base system

[Levente Polyak via arch-dev-public]

On 2/12/19 11:55 PM, Allan McRae wrote:
> On 13/2/19 8:17 am, Levente Polyak via arch-dev-public wrote:
>> On 2/12/19 7:16 PM, Gaetan Bisson via arch-dev-public wrote:
>>> [2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
>>>> Just in case it wasn’t clear, my answer would have been mostly the same
>>>> as Eli’s.
>>>>
>>>> So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do
>>>> you have further comments/questions regarding this, does the existence
>>>> of the base group alongside the arch/minimal-system now makes sense or
>>>> would you still prefer to go without it?
>>>
>>> Allan and I have both stated that we don't want to introduce a new group
>>> since we believe it would be highly redundant with base.
>>>
>>> Nothing new has been said since our last messages except Eli's post
>>> which argues that the base group is largely inadequate in its current
>>> state. This further supports our proposal that base should be improved
>>> instead of introducing a new group.
>>>
>>> So I really don't see what arguments could have changed our minds...
>>> It's also strange to me how you can concur with Eli's post without
>>> agreeing with our conclusions.
>>>
>>> To go forward I suggest you propose a clear definition of the perfect
>>> "minimal system" group you'd want to have, along with a proposed list of
>>> packages. When consensus is reached, we adopt this list of packages for
>>> base and put this definition on the wiki.
>>>
>>> Cheers.
>>>
>>
>> To make it as short as possible, the idea is not just to strip down the
>> base group further but primarily to not use a group in the first place.
>> It should be replaced with something that is consistent within itself
>> over the whole lifetime of the system.
>> Groups are the wrong tool for such a set: you explicitly install all
>> those packages so they won't automatically be mark as not-required
>> anymore once removed from that group, as well as new additions are not
>> consistent during the lifetime of the system.
> 
> We are clear about that.  Call it a group or metapackage or whatever,
> the objection is having the current base and the new "group" at the same
> time.
> 
> A
> 

Sure, then we are on the same page now. The wording here is just
important as, at least for me, it gets totally confusing what we are
exactly talking about if we start mixing metapackages and groups while
discussing possible steps.
Personally I'm totally fine with just nuking the rest of the group out
of orbit and possibly extend the wiki with some of those recommended
packages.
I totally understand the fear of introducing "confusion and duplication"
so I'm fine with just having a proper defined set and nothing further.

Cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Proposal: minimal base system

[Levente Polyak via arch-dev-public]

On 2/12/19 7:16 PM, Gaetan Bisson via arch-dev-public wrote:
> [2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
>> Just in case it wasn’t clear, my answer would have been mostly the same
>> as Eli’s.
>>
>> So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do
>> you have further comments/questions regarding this, does the existence
>> of the base group alongside the arch/minimal-system now makes sense or
>> would you still prefer to go without it?
> 
> Allan and I have both stated that we don't want to introduce a new group
> since we believe it would be highly redundant with base.
> 
> Nothing new has been said since our last messages except Eli's post
> which argues that the base group is largely inadequate in its current
> state. This further supports our proposal that base should be improved
> instead of introducing a new group.
> 
> So I really don't see what arguments could have changed our minds...
> It's also strange to me how you can concur with Eli's post without
> agreeing with our conclusions.
> 
> To go forward I suggest you propose a clear definition of the perfect
> "minimal system" group you'd want to have, along with a proposed list of
> packages. When consensus is reached, we adopt this list of packages for
> base and put this definition on the wiki.
> 
> Cheers.
> 

To make it as short as possible, the idea is not just to strip down the
base group further but primarily to not use a group in the first place.
It should be replaced with something that is consistent within itself
over the whole lifetime of the system.
Groups are the wrong tool for such a set: you explicitly install all
those packages so they won't automatically be mark as not-required
anymore once removed from that group, as well as new additions are not
consistent during the lifetime of the system.

Cheers.



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] Proposal: minimal base system

[Levente Polyak via arch-dev-public]

# Proposal

There is no strict definition of what a minimal Arch Linux system
installation must contain. However in reality we mostly don’t add any
packages that are in the base group as a dependency to other packages,
which basically makes it a hard requirement.

The current way of defining a minimal system via a group is non-optimal
for the following reasons:

- A group can’t enforce installation of packages when being extended or
  modified
- The current base group contains lots of unneeded packages
- Manually getting rid of some of the packages may result in broken deps

To overcome the disadvantages, a better way to handle a strictly defined
set would be a simple virtual base-system package that depends on the
bare minimum of what we define as given and required. This virtual
package can be changed/extended and every installation will pull it in
during the next system upgrade.

Everything that won’t be part of base-system needs to be added as a
dependency to all requiring packages; alternatively don't omit any first
level runtime dependencies at all.

This package should only depend on strictly required explicit packages
to get a working minimal Arch Linux system.

The proposed end result is:
- base: convenient helper group for quickly getting a working system
  when installing, must include the new base-system package
- base-system: package defining the minimum dependencies for a working
  base runtime

Possible candidates for the virtual package:

 Base requirements:
- filesystem
- gcc-libs
- glibc
- bash
- coreutils

 Distro requirements:
- licenses
- pacman
- systemd

 Some POSIX tools
- coreutils
- file
- findutils
- gawk
- grep
- procps-ng
- sed
- tar
- gettext
- pciutils
- psmisc
- shadow
- util-linux
- bzip2
- gzip
- xz

 Some networking tools
- iputils
- iproute2


## Alternative

Another approach would be, assuming we want to properly support tiny
containers, to reduce the above list even further to a bare minimum of
running pacman and not omit any further 1st level runtime dependencies
in our packages.

## Short summary

Required:
- Use a virtual package instead of a group for the bare minimum

Option 1:
- Define a base-system virtual package as a required set of packages
  containing something like a POSIX interactive runtime environment

Option 2:
- Reduce the set even further to aid tiny containers and don't omit any
  other 1st level runtime dependency in packages
- We could additionally still have a smaller set for a POSIX interactive
  runtime environment for convenience



PS: Please focus on the abstract before bikeshedding whether single
packages should or should not be added

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Away for two weeks

[Levente Polyak via arch-dev-public]

On 10/5/18 8:40 PM, Sven-Hendrik Haase wrote:
> On Fri, Oct 5, 2018 at 8:30 PM Jelle van der Waa  wrote:
> 
>> Hi all,
>>
>> I'll be away for two weeks without a laptop so I won't be able to do any
>> packaging. Feel free to update my packages or fix my open bugs ^_^
>>
>> If there is something really urgent, I should be able to reply via
>> e-mail.
>>
>> --
>> Jelle van der Waa
>>
> 
> You go on vacation... without your laptop?! D:
> 

Sounds like horrible vacation to me :P

anyway, have fun :)



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] [RFC] Remove svn propset id's

[Levente Polyak via arch-dev-public]

On 8/29/18 10:23 PM, Jelle van der Waa wrote:
> Most of our PKGBUILDs svn propset's break reproducible builds and the
> pkgbuild_sha256sum in the BUILDINFO file. When building a package before
> commiting the PKGBUILD the propset $Id will differ since the $Id is set on
> commit.
> 
> This has a few implications, pkgbuild_sha256sum is useless and we can't
> reproduce packages due to the BUILDINFO not matching. Also the reproduce tool
> uses ASP to retrieve the PKGBUILD and therefore can't verify that it got the
> correct PKGBUILD (it relies on pkgbuild_sha256sum).
> 
> To resolve this issue we could simply remove the propset id's, since for
> me, although not sure about others they don't seem particulary useful.
> 
> The proof that the sha256sums's don't match:
> 
> $ extra-x86_64-build
> $ grep sha256 .BUILDINFO
> pkgbuild_sha256sum = 
> 8748d60d2c782f477cb7e692a3dad30be90491cdc13fe8951340da4c0bc7f19e
> $ $repopkg
> 
> $ sha256sum PKGBUILD
> d8ab51a983026dd4a6e2f48e9dc66177eca8cf6c1c0ffefb950b093db299e304  PKGBUILD
> 
> # The git checkout
> 
> [jelle@helium][/tmp/bar/community/python-psutil/trunk]%sha256sum PKGBUILD
> ce7f1e68a3b426412a24f46016817d30721860c8ef6b3d0a2dddac8ff2448b84  PKGBUILD
> 
> [jelle@helium][/tmp/bar/community/python-psutil/trunk]%diff PKGBUILD 
> /tmp/python-psutil/trunk/PKGBUILD
> 1c1
> < # $Id$
> ---
>> # $Id: PKGBUILD 375007 2018-08-28 17:24:26Z jelle $
> 

I know there are some people who like them because $reason, but even
with svn its not rocket science to get the last author.

+1 from me because on top of your reason:

- IMO such meta data belongs to the repo history and not the file
  content itself.

- we will purge it anyway if we finally finish the transition to git


cheers,
Levente



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] EOL openjdk 9 (+ prepare to phase out java7)

[Levente Polyak via arch-dev-public]

Hi folks,

I gonna nuke openjdk 9 from the repos, its EOL already and n nothing
depends on it.

Please prepare for phasing out java 7 soonish via a TODO list. If you
have packages depending on 7, please pro-actively check if those work
with java 10 (or optionally 8 as thats LTS).

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] github ci migration from travis-ci.org to travis-ci.com

[Levente Polyak via arch-dev-public]

Hi folks,

As already announced in the devops IRC I started migrating out projects
to travis-ci.com via support requests. For that to work both CI's need
to be active for all projects that need a migration otherwise its stuck
in nirvana (so please don't remove any).

I have already successfully migrated arch-securoty-tracker to the new
platform, Next will be archweb and others.

Once a project is successfully migrated, the old travis-ci.org CI rights
can be revoked. I remove them from the migrated projects as well.

cheers,
Levente

Re: [arch-dev-public] Unit tests for python packages

[Levente Polyak via arch-dev-public]

On April 18, 2018 11:53:01 AM GMT+02:00, Baptiste Jonglez 
 wrote:
>Hi,
>
>Does anyone have experience with unit tests for python packages?  It's
>really useful to spot missing runtime dependencies, but it's a pain to
>get
>to work.
>
>Here is what I saw:
>
>1) just running "python -m unittest discover" or "nosetests" or
>equivalent
>  in the check() function does not work, because the package is not yet
>   installed (so all imports will fail)
>
>2) setuptools is supposed to have a unittest integration such that
>   "python setup.py test" should work out of the box, but in my case it
>   never finds any tests to run
>
>3) I've seen some more... "creative" solutions :)
>https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python-coverage#n28
>
>So far, the only working solution I found is playing with PYTHONPATH:
>
>cd "$srcdir/$pkgname-$pkgver/tests"
>export PYTHONPATH="$srcdir/$pkgname-$pkgver/src"
>python -m unittest discover
>
>But it's a hack, and it probably won't work with things like 2to3.
>
>Any better ideas?
>Baptiste


If you use a build function there shouldn't be any problems like 2to3 while 
running tests, everything should be converted / build and generated for the use 
of tests.
For certain upstream test setups there won't be much you can do other then 
PYTHONPATH but as mentioned with a build function it should always work.
You can give python-pytest-runner a go, it does proper resolution while running 
"python setup.py test" but requires certain ways the whole test suites are 
wired.

Cheers
Levente 

Re: [arch-dev-public] Boost looking for new maintainer

[Levente Polyak via arch-dev-public]

On March 20, 2018 4:55:16 PM GMT+01:00, Robin Broda via arch-dev-public 
 wrote:
>On 03/20/2018 02:36 PM, Bartłomiej Piotrowski via arch-dev-public
>wrote:
>> Hi team,
>> 
>> As I'm absolutely the worst with C++, none of my packages depend on
>> boost and I've spent enough nights terrified of its build system
>quirks,
>> I'll be orphaning it soon. Feel free to adopt it in archweb.
>> 
>> Bartłomiej
>> 
>
>If you're willing to drop it to [community] i'll gladly adopt it.
>
>Rob

Well I pretty much love cpp and boost and have multiple packages depending on 
it, if nobody here feels butt hurt or robbed I would happily adopt it. I don't 
fear sleepless nights and I explicitly welcome everyone to propose sane changes 
now or in future, working together is key to success :D

Cheers
Levente 

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Levente Polyak via arch-dev-public]

On March 13, 2018 2:07:31 PM GMT+01:00, Bruno Pagani via arch-dev-public 
 wrote:
>Le 13/03/2018 à 13:42, Antonio Rojas via arch-dev-public a écrit :
>
>> El martes, 13 de marzo de 2018 11:23:07 (CET) Bruno Pagani via
>arch-dev-public escribió:
>>> Some projects seems to default to Debug instead of None… So should
>we
>>> specify a BUILD_TYPE of None instead of Release?
>>>
>> Not sure if it's a good idea to systematically override the build
>type when it has been explicitely set by upstream. Some projects may be
>doing so for good reasons. Although explicitely setting it to Debug in
>a release tarball seems odd, do you have any example of such a project?
>
>
>The one I had in mind:
>https://github.com/Unidata/netcdf-c/blob/master/CMakeLists.txt#L122
>
>Release tarball is the same, they don’t change anything w.r.t. CMake in
>release tarball. Maybe it’s just one project and all other Arch Linux
>packages are not affected, but dropping BUILD_TYPE automatically at
>repo
>scale does not seems a good idea. I would prefer a todo list with
>instructions on checking what BUILD_TYPE and more importantly FLAGS
>where actually used by the build, even if I know you would rather have
>avoided one.


I think a TODO and checking flags would be a good idea, I also encountered 
similar things and even somehow ignoring flags fully but provide custom 
switches to set them.
If we touch this on a distro scale anyway, now would be a good time to ensure 
our distro FLAGS are indeed set for cmake stuff as we expect. Obviously there 
are weird things going on in some of them :p

Cheers,
Levente 

Re: [arch-dev-public] Orphaned packages

[Levente Polyak]

On August 20, 2017 3:13:18 PM GMT+02:00, "Sébastien Luttringer" 
 wrote:
>Hello,
>
>I orphaned several packages I don't use anymore. The following have no
>more
>maintainer, so if nobody is interested, I will move them to AUR.
>- unifi
>- rxvt-unicode
>- laptop-detect
>- python-docutils
>- quilt
>- rblcheck
>Cheers,
>
>


I'm happy to maintain rxvt-unicode, I will adopt it today in the evening. 

Cheers, 
Levente

Re: [arch-dev-public] Bringing Multipath TCP kernel (linux-mptcp) to [community]

[Levente Polyak]

On June 11, 2017 12:47:07 AM GMT+02:00, Baptiste Jonglez 
 wrote:
>At that point, Multipath TCP is mostly useful to researchers and
>tinkerers, because both ends of a TCP connection need to run the
>modified
>kernel (otherwise, it just falls back to regular TCP).
>
>However, I still think it would be useful in [community]:
>
>1) One nice use-case is link aggregation, where you basically tunnel
> traffic over a Multipath TCP connection.  You may want to build such a
>   tunnelling system with Arch.
>


That there may be useful things provided by multipath per say is out of 
question, it's more how useful it is to package yet another kernel into the 
repository. It's very much an edge case variant at this point (as you pointed 
out yourself).


>2) Not everybody has the resources to build a kernel (time, CPU,
>memory, disk...)
>


If you're a researcher or thinker you will somehow manage to compile a kernel 
from the AUR and the resources to do so are not really that high. 


>So, I would say the project is active and focused on the long term.
>There have been minor releases in-between these major releases, to
>integrate bugfixes and update to latest stable kernel.  For instance,
>v0.91.2 was based on linux 4.1.35.
>


Which is quite ancient actually. Also the mentioned support includes handling 
of vulnerabilities by our security team. Each kernel, especially when not in 
sync with neither LTS nor the default, creates overhead when handling and 
researching patches and vulnerabilities as they are part of the official 
repositories. 
This can get pretty cumbersome and personally I don't quite see the 
justification fur the additional burden it creates.
My humble opinion is that multipath sounds nice but belongs into the AUR rather 
then into our repository.


Cheers, 
Levente 

[arch-dev-public] libpsl support for wget and curl (moving libpsl to [core])

[Levente Polyak]

Hi,

I would like to move libpsl[0] to [core] and, if no objections arise,
rebuild wget and curl against it. Doing so will protect against some
problems related to insufficient checking of TLDs (f.e. [1]).

Q: What is libpsl?
A: A C library to handles the Public Suffix List [0]. It was created
   out of wget itself and turned into a library so others (like curl)
   could benefit from it.

Q: What does it protect against?
A: - "supercookies" -> cookie checking, cookie domain verification
   - "super domain certificates" -> overly permissive hostname matching

Q: What does upstream recommend?
A: Both, curl and wget, advocate the use of libpsl in their projects if
   available [2][3].

Q: How big is this package?
A: Not even noticeable, 41K while packed (tar.xz) and 92K unpacked.


cheers,
Levente

[0] https://github.com/rockdaboot/libpsl
[1] https://lists.gnu.org/archive/html/bug-wget/2014-03/msg00093.html
[2] http://git.savannah.gnu.org/cgit/wget.git/commit/?id=854ebbf4ddad
[3] https://github.com/curl/curl/commit/e77b5b7453c1e8ccd7ec



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Long out of date packages

[Levente Polyak]

On 10/20/2016 02:25 PM, Florian Pritz via arch-dev-public wrote:
> 
> I'll start slowly dropping packages to AUR in a few weeks.
> 

Well I'm not 100% sure but do you mean the already orphan packages or
all not required packages?
Most likely there is lot of stuff they will be dropper later on... but I
think they should first be orphaned before we start doing that.

Purely speaking about the "movable to AUR" (not the required) packages,
but I would instantly pick up: avidemux, reaver, httpie, python-irc if
they would be orphan.

maybe some of the useful stuff from that list would be picked up by
others too?


> anthraxx:
> community/x86_64/powerdns-recursor
> community/any/gufw
> 

Ups, I forgot powerdns-recursor in the [testing] repository, the
package is in that repo for quite a while. will move when arriving at home.

gufw requires more work and new dependencies + testing. It was an orphan
package and I picked that up like aprox. 1.5 weeks ago to mark that i
start working on that topic. Will accelerate and to that asap.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature