Recent activity

Re: Renaming master branch in aports.git to edge? 18 days ago

From Natanael Copa to ~alpine/devel

On Mon, 15 Jun 2020 18:34:04 -0600
Ariadne Conill <ariadne@dereferenced.org> wrote:

> Hello,
> With all of the discussion about github renaming their default branch from 
> "master" to "main", it occured to me that the "master" branch in aports.git 
> reflects Alpine's rolling release "edge" repositories.
> Discussion of the semantics behind the terminology aside, I think it would be 
> more transparent if we renamed "master" to "edge."  This would cause the edge 
> repositories to be aligned with an obviously-named branch in aports.git, which 
> seems like it would be helpful in general, verses having a special case for 
> master == edge and release branches being named after their version numbers.

Re: Moderation in IRC channels 22 days ago

From Natanael Copa to ~alpine/devel

On Thu, 11 Jun 2020 19:47:34 -0600
Ariadne Conill <ariadne@dereferenced.org> wrote:

> Hello,
> Lately we have had some moderation issues in #alpine-linux which result from 
> the current moderators of that channel being in Europe time.
> It would behoove us to add additional folks with moderation access to the 
> channels, so we can deal with this 24x7.

Agree. this is urgent.

> In the interim, it has been suggested to add the freenode-staff user to the 

Re: team-maintained packages 25 days ago

From Natanael Copa to ~alpine/devel

On Tue, 9 Jun 2020 09:26:07 -0300
Timothy Legge <timlegge@gmail.com> wrote:

> I am willing to help out with Perl packages.  I have not ventured much
> further at this point.

Very nice!

I think this illustrates the value of having teams or SIGs (special
interest group).



Re: team-maintained packages 25 days ago

From Natanael Copa to ~alpine/devel

On Tue, 9 Jun 2020 07:42:26 -0400
Will Sinatra <wpsinatra@gmail.com> wrote:

> Would the teams cover single packages, or rather large concepts?

Depends on the need, but I'd guess teams make more sense for larger
concepts, like documentation, infra, kernel, toolchain, GNOME.

Some teams may be unrelated packages (like developer relations), while
others may be about maintaining a group of packages (for example kernel)

The idea is to create teams as the need for them shows up.

> Would there be for instance a lisp team in charge of all lisp packages, or

Re: team-maintained packages 26 days ago

From Natanael Copa to ~alpine/devel

On Mon, 08 Jun 2020 11:12:13 +0200
Rasmus Thomsen <oss@cogitri.dev> wrote:

> On Mon, 2020-06-08 at 10:59 +0200, Natanael Copa wrote:
> > On Mon, 08 Jun 2020 02:13:49 -0600
> > Ariadne Conill <ariadne@dereferenced.org> wrote:
> > 
> > [...]
> >   
> > > > From an APKBUILD perspective, the maintainer line would look like
> > > > this:    
> > > 
> > > # Maintainer: Alpine KDE team <  
> > > https://gitlab.alpinelinux.org/groups/kde>  

Re: team-maintained packages 26 days ago

From Natanael Copa to ~alpine/devel

On Mon, 08 Jun 2020 02:13:49 -0600
Ariadne Conill <ariadne@dereferenced.org> wrote:

> Hello,
> Now that Gitlab is deployed and in place, it is possible to have teams as 
> groups in gitlab, such as the core group[1].
> As many maintainers and developers collaborate on packages anyway, I believe 
> it is useful to formalize this arrangement.
> Accordingly, I believe that we should allow Gitlab groups to own packages to 
> achieve that.  A Gitlab group can be assigned issues in the issue tracker, and 
> can have designated "owners" of the group.  Groups are also publicly viewable.  

Re: regenerate APKINDEX 30 days ago

From Natanael Copa to ~alpine/users

On Wed, 3 Jun 2020 23:25:11 -0700
amc252 <amc252@gmail.com> wrote:

> By mistake I erased the latest /ver/cache/apk/APKINDEX file and now when I lst the installed packages, the list is imcomplete. Is there a way to regenerate a new APKINDEX? 

apk update

if you mean the installed packages database, (/lib/apk/db/installed)
and you still have your /etc/apk/world intact, then you can do: `apk
fix` to reinstall the packages.


Alpine 3.12.0 released a month ago

From Natanael Copa to ~alpine/announce

We are pleased to announce the release of Alpine Linux 3.12.0, the first in
the v3.12 stable series.

New features and noteworthy new packages

* Initial support for mips64 (big endian).
* Initial support for D programming language.

Significant updates

* Linux 5.4.43
* GCC 9.3.0

Can we drop armhf (armv6) after v3.12? a month ago

From Natanael Copa to ~alpine/devel


Can we drop the armhf architecture after 3.12 release?

It means that we will continue support armfh with 3.12 for two mor
years, but edge and next release 3.13 will be without armhf.

This means that we effectively drop support for Raspberry pi 1 and
raspberry pi zero which are armv6. This is also the hardware we have
kernel for.

The reason is that there are increasing number of issues that are not
fixed upstream. For example:

Alpine 3.12.0 release candidate 1 is out a month ago

From Natanael Copa to ~alpine/devel


The first release candidate for 3.12 is out. Please help test!

Details on what is new in 3.12:
(Thank you Leo and Cogitri!)

If you find any issues with the release candidate, then please file an
issue with the details, and set the milestone to 3.12.0. Please use
also this milestone for merge requests that are critical for 3.12.0