On Mon, 2022-09-12 at 14:09 +0000, Ruck, Maximilian wrote:
> Hi all,
> 
> I am new to Alpine Linux and was checking out the Patch Workflow
> Documentation in the Wiki. However I am
> struggling to follow through on my local machine. Currently I am
> trying to apply the patches after installing 
> the pwclient. Therefore I followed the instructions on
> https://patchwork.alpinelinux.org/.
> 
> I tried to setup the pwclient. According to the instructions given
> and the info in the pwclient doc 
> (
> https://patchwork.readthedocs.io/projects/pwclient/en/latest/configura

> On 16 Feb 2022, at 14:52, Sören Tempel <soeren@soeren-tempel.net> wrote:
> 
> However, there have been occasional discussions on IRC if Alpine should switch from GCC
> to Clang anyhow. Maybe this yet another argument for this switch?

I’m currently creating a Linux distribution similar to Alpine in spirit but it’s based on a fully LLVM environment (not even libgcc or binutils) and I can tell you that it’s a total nightmare.

Many packages use gcc extensions and do not compile fine under clang. Even though I strongly advise clang as default compiler, it still requires a non neglecting patch sets.

— 
David

> On 16 Feb 2022, at 11:27, Drew DeVault <sir@cmpwn.com> wrote:
> 
> I think that we should have a greater variety of cross compiler
> toolchains available in aports, providing in reach repo at least enough
> cross-compilers to build Alpine for any target supported by a stable
> Alpine release.
> 
> Thoughts?

clang is by itself a cross-compiler. basically one can setup an environment by grabbing a minirootfs and extract alpine packages itself and then using appropriate command line options you’re pretty much done:

clang --sysroot=/alpine-aarch64 -target alpine-aarch64-linux-musl -fuse-ld=lld test.c -o test

> On 26 Dec 2021, at 17:52, Adnan Maolood <me@adnano.co> wrote:
> 
> Hello,
> 
> I installed Alpine Linux on a laptop with NVMe storage today using the
> new cryptsetup installer. Upon rebooting, the root filesystem failed to
> mount. I eventually realized that the nvme feature needed to be enabled
> in mknitfs.conf and the initramfs needed to be rebuilt in order to boot
> from NVMe storage.
> 
> In order to improve the experience for new Alpine Linux users, I think
> that the nvme feature should be automatically detected and added to

On Mon, May 03, 2021 at 12:37:15PM +0200, Jakub Jirutka wrote:
> Hi David,
> 
> I mostly agree with you, but I think that 2 weeks is too long time

I think this could be discussed but two weeks can be very short too. If
someone is on a vacation it may not have any kind of time to review a
merge request depending on the change.

Perhaps we can set a number of timeout depending on the nature of the
merge request.

> That’s specifically why a maintainer should always add documentation
> comments into APKBUILD! If you, as a maintainer, have a knowledge of

Hi there,

I'm the maintainer of several packages inside the aports tree (mostly in
gaming and audio).

For several times now, I figured out that some of my packages were
modified without my approval nor notifications. To my understanding it
looks like there are no policy regarding what Alpine developers should
do when a merge request is submitted by someone else than the maintainer
itself.

It's definitely fine that someone else provide a merge request for a
package that it is not maintaining, that's the power of opensource
world. It's no longer okay when the maintainer has no words to say, no

Le 20/07/2020 à 17:21, Rasmus Thomsen a écrit :
> Hello list,
> 
> I've recently started working on a gitlab bot for aports (although it
> can be used for any repo which uses the same labels etc. as aports), so
> we can automate some review tasks (and can avoid repeating ourselves),
> so we can get more productive things done :)
> 
> Currently it can do the following things:
> 
> 1) Mark/Unmark MRs with failing/sucessful CI with the label "status:mr-
> build-broken"

Honestly I dislike this. Sometimes I push to GitLab especially to take

On Tue, Apr 21, 2020 at 12:16:47AM +0300, Consus wrote:
> What makes the situation even more complicated is that by default all
> mail is coming to your inbox. And there is no standard protocol across
> mail clients

Yes, there is one it's called Sieve [0]. I personally use sieve-connect
to edit my rules from command line.

[0]: https://en.wikipedia.org/wiki/Sieve_(mail_filtering_language)

-- 
David

On Sat, Apr 18, 2020 at 03:48:25AM +0000, Ariadne Conill wrote:
> This lead to Drew DeVault proposing that Alpine use his Sourcehut platform
> for mailing lists, which we have used for the past 8 months.  Initially,
> this was seen as a good solution for the original problems we were having
> with the ezmlm-based setup, but some have discontinued using the mailing
> lists, in some cases leaving the project entirely due to issues the
> Sourcehut software has processing HTML e-mail, which caused incompatibility
> with popular e-mail clients such as the Android GMail client and the iOS
> EMail client, as well as differences in behavior verses the earlier mailing
> list system involving the Sourcehut solution not mailing a copy of the
> message back to its author.

I personally use mlmmj [0], it's pretty minimalist and simple to use.
Could be nice to use to replace this one at least for other lists. And

Le 06/04/2020 à 11:12, Shiz a écrit :
> 
> 
>> On Apr 6, 2 Reiwa, at 11:06, David Demelier <markand@malikania.fr> wrote:
>>
>> Le 06/04/2020 à 10:45, M Farkas-Dyck a écrit :
>>> On 06/04/2020 12:31 am, Shiz wrote:
>>>> I’ve always been of the opinion that if one wanted to do this,
>>>> it makes more sense to symlink /usr to / than the other way around.
>>> That's also fine with me. I agree having /usr/ point to / makes more sense, but worried others (the Alpine team in particular) might consider it too heterodox, having /share and /local and /include and such ☺
>>
>> I actually tried that for my distribution and it's a big PITA.
>>
>> There are too many software that think /usr is the appropriate place and therefore requires huge amount of patches to work. Not mentioning that lots of broken custom build script fails to configure if a prefix is set to / or empty.