~graywolf

~graywolf/public-inbox

Last active a month ago
View more

Recent activity

Re: [PATCH abuild] Add new lines around the checksums in APKBUILD 21 days ago

From Wolf to ~sircmpwn/alpine-devel

Hello,

could I get some feedback on this patch?



Thank you,
W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

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

From Wolf to ~sircmpwn/alpine-devel

Hello,

On 2020-06-15 18:34:04 -0600, Ariadne Conill wrote:
> 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.

While in comparison to the master->main change, this one would actually
make sense and would reflect the repo naming, at the same time there
are probably lot of scripts and places that assume it's called master.

In my opinion in this case practicality/convention trumps correctness.

Re: How to protect repository's private key? 27 days ago

From Wolf to ~sircmpwn/alpine-devel

On 2020-06-13 16:52:42 -0500, Maxwell Rees wrote:
> [..]
> the strategy you describe is basically what I have encoded in software
> that I've been developing called APK Foundry.
> [..]

Is that somewhere available so that I can take a peek? Searching for
`APK Foundry' gave be bunch of android-related pages.

> It sounds like abuild-gzsplit needs to be fixed then; you should file
> an issue on alpine/abuild.git. 

I've done that already [0] :) . The issue is that abuild-gzsplit
explicitly checks for names of entries [1], which broke when they were

How to protect repository's private key? 27 days ago

From Wolf to ~sircmpwn/alpine-devel

Hello,

I'm trying to setup (well, actually update to 3.12) my private
repository for alpine packages and I'm facing issues with how to protect
repository signing key from rogue software.

For example, if some shady code is executed as part of a Makefile or
something, it does by default have read access to repository private key
(and it can therefore extract it). I would like to prevent that.

In 3.11, I was using fake dummy key in the build container,
abuild-gzsplit and abuild-sign with the real key which worked fairly
well. However, that is not possible in 3.12 since abuild-gzsplit is
broken there.

[PATCH abuild] Add new lines around the checksums in APKBUILD a month ago

From Wolf to ~sircmpwn/alpine-devel

In order to make diffs more tidy and the APKBUILD overall more visually
pleasing, new lines are added after opening and before closing quote,
turning

sha512sums="HASH  foo
HASH  bar"

into

sha512sums="
HASH  foo
HASH  bar
"
[message trimmed]

APKBUILD: Changing style of sha512sum line a month ago

From Wolf to ~sircmpwn/alpine-devel

Hello,

currently checksum in APKBUILD looks likes


sha512sums="3abec24495b22ec10649865c7ce7c3271224c7d25c0647b43f3c177b7ccb45d4c5c593f8c89d8bc8eac85ae5dc737f9960827587912dd527bb96100304a7d480  deluge-2.0.3.tar.xz
8ab11f87ddf62a7cba2d2783eec2c439fdc416e5d165ac6b510a9818c28573df32ef408bb16ca61d93b27bb5090782f5b4005a4ad50cfa9fa6dfb869aa2be57c  10-python38-logging.patch"


I would like to propose turning it into


sha512sums="
3abec24495b22ec10649865c7ce7c3271224c7d25c0647b43f3c177b7ccb45d4c5c593f8c89d8bc8eac85ae5dc737f9960827587912dd527bb96100304a7d480  deluge-2.0.3.tar.xz

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

From Wolf to ~sircmpwn/alpine-devel

Hello,

On 2020-05-29 05:08:32 +0000, Mogens Jensen wrote:
> [..]
> 
> Most of them lives as small headless servers or do embedded work, so
> as already suggested in this thread, maybe there is a middel ground
> of not supporting problematic UI stuff?

I would like to express that I also believe approach like this would be
reasonable. Providing just the reasonable subset of packages (so no Qt).

Of course I do not know how much work does doing it like this actually
save.

Re: [PATCH acme-client-portable] Add missing include in compat.c a month ago

From Wolf to ~graywolf/public-inbox

On 2020-05-24 23:35:45 +0200, Ruud van Asseldonk wrote:
> 
> > In the end it was not as trivial as I would hope so, but I've got it
> > working.
> 
> Looking at nixpkgs.yml, it indeed looks like a bit of a hassle. In
> https://man.sr.ht/builds.sr.ht/compatibility.md#nixos it says that NixOS is
> actually supported natively, perhaps that will allow a simpler config?

Hm, I should learn to RTFM. Thank you, the manifest is much easier on
the eyes now :)

W.

Re: How to report bugs from command line? a month ago

From Wolf to ~sircmpwn/alpine-devel

On 2020-05-24 16:55:27 +0200, Rasmus Thomsen wrote:
> FWIW there's something similiar for merge requests too now, see 
> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests .

Sadly it does not seem to work:



Subject: [Rejected] [PATCH] Add acme-client



Unfortunately, your email message to GitLab could not be processed.

Re: How to report bugs from command line? a month ago

From Wolf to ~sircmpwn/alpine-devel

Hello,

On 2020-05-24 16:55:27 +0200, Rasmus Thomsen wrote:
> [..]
>
> you can create an account on https://gitlab.alpinelinux.org and then
> navigate to https://gitlab.alpinelinux.org/alpine/aports/-/issues.
> There should be a "Email a new issue to this project" link at the very
> bottom of that page. You can then follow the steps in the dialogue that
> pops up in order to send bug reports to Alpine by email.

Cool, that seems to work nicely.

> FWIW there's something similiar for merge requests too now, see