~trylletre

Recent activity

Re: Build failure while cross-compiling to aarch64 on x86_64. (scripts/bootstrap.sh failure) 6 days ago

From alice to ~sircmpwn/alpine-devel

On Fri Aug 12, 2022 at 8:20 PM CEST, Karel Gardas wrote:
> On Fri, Aug 12, 2022 at 3:15 PM alice <alice@ayaya.dev> wrote:
>  >   openssl3-libs-static (no such package):
> > >     required by: .hostdepends-apk-tools-20220812.110325[openssl3-libs-static]
> > aha, missed this one. fixed now.
> >
>
> Indeed, thanks for fixing this. Anyway, here is another one, probably
> if not my own mistake:
nope, this one is probably
https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10069

make sure APORTSDIR= is set to the actual aports directory (i guess),
the most likely cause of this error is the .rootbld-repositories not

Re: Build failure while cross-compiling to aarch64 on x86_64. (scripts/bootstrap.sh failure) 6 days ago

From alice to ~sircmpwn/alpine-devel

On Fri Aug 12, 2022 at 1:27 PM CEST, Karel Gardas wrote:
> So even with edge as a host and master branch of aports the bootstrap
> still fails. However it's probably going furthest anyway:
>
> OK: 0 MiB in 0 packages
> >>> make: Updating the main/aarch64 repository index...
> >>> make: Signing the index...
> .]0;..]0;abuild-aarch64: apk-tools.>>> apk-tools: Building
> main/apk-tools 2.12.9-r6 (using abuild 3.9.0-r5) started Fri, 12 Aug
> 2022 13:03:25 +0200
> >>> apk-tools: Checking sanity of /home/karel/src/aarch64-aports/main/apk-tools/APKBUILD...
> >>> apk-tools: Analyzing dependencies...
> ERROR: unable to select packages:
>   .hostdepends-apk-tools-20220812.110325:

Re: Build failure while cross-compiling to aarch64 on x86_64. (scripts/bootstrap.sh failure) 7 days ago

From alice to ~sircmpwn/alpine-devel

On Fri Aug 12, 2022 at 12:29 AM CEST, Karel Gardas wrote:
> Hello,
>
> a new user here. I've installed a 3.16 x86_64 VM here and have been
> attempting to use that to cross-compile some package to aarch64
> platform. The problem is that script/bootstrap.sh is not working well
> for me.
>
> Platform: up-to-date 3.16 on amd64
> aports: updated hour ago
> command line: CBUILDROOT=$HOME/sysroot-aarch64 time
> ./src/aarch64-aports/scripts/bootstrap.sh aarch64
>
> The aports repo is cloned into ./src/aarch64-aports dir here. Also

Re: OpenSSL 3 pushed to git master 9 days ago

From alice to ~sircmpwn/alpine-devel

On Tue Aug 9, 2022 at 11:22 AM CEST, Nico Schottelius wrote:
>
> 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

Re: OpenSSL 3 pushed to git master 9 days ago

From alice to ~sircmpwn/alpine-devel

On Tue Aug 9, 2022 at 10:34 AM CEST, Nico Schottelius wrote:
>
> 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!
note that the next upgrade to -r3 has this reverted again (back to
openssl3)- you would need to edit the openssl.cnf after that.

>
> Sunny greetings from Switzerland,
>
> Nico
>

Re: OpenSSL 3 pushed to git master 9 days ago

From alice to ~sircmpwn/alpine-devel

On Tue Aug 9, 2022 at 10:25 AM CEST, Nico Schottelius wrote:
>
> 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.
certainly, i'm aware of the general background, and guessed as much :) i

Re: OpenSSL 3 pushed to git master 10 days ago

From alice to ~sircmpwn/alpine-devel

On Tue Aug 9, 2022 at 9:47 AM CEST, alice wrote:
> On Mon Aug 8, 2022 at 9:59 PM CEST, Nico Schottelius wrote:
> >
> > Hey Nate,
> >
> > is it possible that this upgrade broken openconnect?
>
> the actual issue is that openssl3 does not allow insecure renegotiation.
> see, for instance:
> https://www.ibm.com/mysupport/s/question/0D50z000062ktWGCAY/why-ssl-handshake-fails-with-unsafe-legacy-renegotiation-disabled?language=en_US
>
> a quick look via sslscan at the domain indicates it is using tls1.1 and
> tls1.2, and: 
>

Re: OpenSSL 3 pushed to git master 10 days ago

From alice to ~sircmpwn/alpine-devel

On Mon Aug 8, 2022 at 9:59 PM CEST, Nico Schottelius wrote:
>
> Hey Nate,
>
> is it possible that this upgrade broken openconnect?

the actual issue is that openssl3 does not allow insecure renegotiation.
see, for instance:
https://www.ibm.com/mysupport/s/question/0D50z000062ktWGCAY/why-ssl-handshake-fails-with-unsafe-legacy-renegotiation-disabled?language=en_US

a quick look via sslscan at the domain indicates it is using tls1.1 and
tls1.2, and: 

 TLS Fallback SCSV:

Re: Does alpine violate rust's trademark? 29 days ago

From alice to ~sircmpwn/alpine-devel

On Mon Jul 18, 2022 at 6:46 PM CEST, Wolf wrote:
> Hello,
>
> I would like to inquire about the `community/rust' package. After
> reading this [0] fun debate bug thread over at debian bug tracker, I've
> started to wonder what is the state of this in alpine.
>
> It looks like at least some of the patches in community/rust do not fall
> under any of these categories (from [1]):
>
>  - porting the software to a different architecture
>  - fixing local paths
>  - adding patches that have been released upstream
>  - adding patches that have been reported upstream, provided that the

Re: Downgrading of x264-libs? a month ago

From alice to ~sircmpwn/alpine-devel

yeah, i think you got it. the instructor system must've not had an -a passed for a while, and apk kept the 'big' version, up until the 'downgraded' version was forcefully pulled in due to the new soname (164). solved :)