"Drew DeVault" <sir@cmpwn.com> writes:

> Also would like to see the big Ceph changes land in community:
>
> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33752

Drew, you made my smile a lot. Ceph on Alpine? Seriously? Wow, I am
impressed! (*)

That is one thing we failed at some years ago, because the packages were
practically unusable and is actually the reason why we switched to
ceph/rook about 1 year ago from Devuan/Ceph Native.

Hey Nate,

Natanael Copa <ncopa@alpinelinux.org> writes:

> Hi!
>
> I will start work on setting up the builders for 3.17 release this
> week. This means that significant changes to the toolchain and
> bootstrap packages (eg make, binutils, gcc, bison, autoconf, automake,
> cmake etc) needs to happen within a few days or they will have to be
> postponed to after 3.17 release.

one question from my side: is there any chance that we move the

Hey Alice,

"alice" <alice@ayaya.dev> writes:

> On Tue Aug 9, 2022 at 11:22 AM CEST, Nico Schottelius wrote:
>>
>> I verified three times that the content is correct - is it possible that
>> not every app linked against openssl actually loads the configuration
>> file?
> seems some don't. i was naive..

Same same ...

Hey Alice,

"alice" <alice@ayaya.dev> writes:

> On Tue Aug 9, 2022 at 10:25 AM CEST, Nico Schottelius wrote:
>> I am using openconnect to connect to "highly secure" networks
>> that. Highly secure means: corporate managed, specific access and
>> traffic policies, 2FA. It however does not mean: up-to-date software or
>> Open Source Software. It's rather the opposite: these are proprietary,
>> closed source systems with upgrade cycles of "only if need be", usually
>> done if there is a CVE out there.
> certainly, i'm aware of the general background, and guessed as much :) i
> just don't think it's a good idea for other people to be affected by

Hey Sören,

thanks a lot for the quick fix. I have just upgraded to 9.01-r2 and it
indeed fixes the problem, much appreciated - I can get back to work!

Sunny greetings from Switzerland,

Nico

Sören Tempel <soeren@soeren-tempel.net> writes:

> Hi Nico,
>

Hey Alice,

thanks for investigating and maybe a bit background from my side to put
the issue into context:

I am using openconnect to connect to "highly secure" networks
that. Highly secure means: corporate managed, specific access and
traffic policies, 2FA. It however does not mean: up-to-date software or
Open Source Software. It's rather the opposite: these are proprietary,
closed source systems with upgrade cycles of "only if need be", usually
done if there is a CVE out there.

So in a nutshell, it is almost impossible to change the systems within a

Hey Nate,

is it possible that this upgrade broken openconnect?

Since an apk upgrade -a on edge I am facing this one:

--------------------------------------------------------------------------------
POST https://portal.somewhere.com/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux
Connected to [....]:443
SSL negotiation with portal.techcorpapps.com
SSL connection failure
9069B3F2667F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:ssl/statem/extensions.c:879:
Failed to open HTTPS connection to portal.techcorpapps.com

Hey Daniel,


"Daniel F. Dickinson" <dfdpublic@wildtechgarden.ca> writes:

> Hi all,
>
> TL;DR I'm starting an 'experiment' with 'less is more' automation via
> tiny-cloud and **no** Packer or Terraform, and no cloud-init, python
> (and therefore Ansible), et al on the client side, and would appreciate
> any development advice in so doing. [...]

as a cloud provider I can only say I really support such

Hey Tomas,

I have to say I find this an interesting idea, because at ungleich we
also sometimes have the need to run glibc based apps, which at the
moment, we simply run inside containers.

I see multiple paths here and before even diving deeper into the topic,
I would like to understand which one you are suggesting:

- a) Adding glibc support as an add-on/additionally to musl
     While some things need to be clarified (which is libc.so...), most
     things could stay the same and there would simply be an additional
     libc installed and available.

Natanael Copa <ncopa@alpinelinux.org> writes:
> [...]
> So the suggestion is to simply use the latest version of the contributor covenant:
> https://www.contributor-covenant.org/version/2/1/code_of_conduct/
>
> What do you think? Is this something could use? Is it good enough?

Sounds very good to me, covers all important points and has a proper
license to use.

Cheers,

Nico