Hi,

we have changed the version number from YYYYMMDD to 0.ABI_gitYYYYMMDD, i.e. to include the ABI version in pkgver. Now it’s more clear when the dependent packages should be rebuilt/upgraded.

https://gitlab.alpinelinux.org/alpine/aports/-/commit/a180db09f3b271548ca42478f2c6d27c2abe2f70

Jakub

On 7/5/22 10:50 PM, Mogens Jensen wrote:
> Hello,
> 
> While updating multiple Alpine edge systems that hadn't been updated
> for a few days, I noticed that x264-libs was being downgraded on one
> of them. As there are no logging for package operations, I can't tell

> 2. If you are not already using tools like shellcheck / shellfmt and or
> shell unit tests in your CI, do you have objections to such being added?

Every time someone opened a merge request in my projects to fix for “bugs” detected by shellcheck, the vast majority of them were completely unnecessary changes that at best only made the code less readable, at worst introduced bugs.
Mostly done by people who have little knowledge of the shell and just blindly apply what shellcheck throws at them without understanding it. Shell is a very context-sensitive, ambiguous and messy “language”, which makes it extremely hard to create a reliable linter for it. That’s why shellcheck doesn’t and cannot work as good as linters for normal languages – you would need a deeper analysis than what shellcheck does.

That said, shellcheck is undoubtedly useful for the author as an aid when writing the shell script, but not as an automated tool for enforcing generic set of rules.

Jakub J.

On 6/30/22 8:16 AM, Daniel F. Dickinson wrote:
> Hello,
> 
> I've noticed some issues with the Alpine shell script libraries (one

> There is the possibility to allow an unintended (remote) login or local privilege expansion by unlocking users in apk-executed scripts.

No, if the user already exists, then adduser(8) does nothing.

> Are you aware of this situation in Alpine and happy with it?

I’m not. I’d prefer a declarative approach – needed users/groups declared in APKBUILD, so abuild can check if they meet some requirements, and also to be easily auditable. However, it doesn’t bother me enough to actually do the job and implement it…
And even this would not prevent package maintainers from doing stupid things, such as making some directory group-writable for www-data to allow running some PHP app with Apache mod_php like in ’90s instead of using php-fpm (with an unique user for each app)…

Jakub

On 6/18/22 12:00 PM, Markus Kolb wrote:
> Hello,
> 

Hi,

> I don't agree that admin should be required to manually create directories with correct permissions.

Me neither.

>> There could be provided an output to the user during the installation about the changes.
> apk doesn't do notifications.

That’s not entirely true, we use post-upgrade scripts to inform users (print messages to stderr) about important changes when upgrading packages. It’s not ideal though.

> Logging in alpine is in a shit state because openrc doesn't really implement logging properly.

I don’t know how do you define proper logging implementation, but maybe you don’t know about `output_log` and `error_log` parameters. You can use it to “redirect” stdout/stderr to syslog using logger(1) command. See kresd.initd [1] for example.

On 3/16/22 8:41 PM, Tassilo Horn wrote:
> Jakub Jirutka <jakub@jirutka.cz> writes:
> 
>> BTW, for you, as the upstream, it would make sense to define
>> profile.release with at least `lto = true`.
> 
> Indeed, I've now set `lto = "thin"` for both dev an release which
> reduces the binary size of the debug builds by quite a lot.
> 
> Without LTO:
> 
> --8<---------------cut here---------------start------------->8---
> swayr on  main [!] is 📦 v0.15.0 via 🦀 v1.59.0
> ❯ du -h target/debug/swayr{,d}

On 3/16/22 8:14 AM, Tassilo Horn wrote:
> Jakub Jirutka <jakub@jirutka.cz> writes:
>> I have a new patch for you in git@git.sr.ht:~jirutka/swayr, branch
>> optimize-size:
>>
>>     This reduces size of the swayr binary by ~57 %. It doesn't affect the
>>     size of the swayrd binary because swayrd uses regex.
>>     
>>     When building with lto = true, opt-level = "z" and panic = "abort" on
>>     Alpine Linux: swayr 1 294 kiB -> 554 kiB
> 
> Interesting.  For me, the size of target/release/swayr has only shrunk
> from 4.3 MB to 4.2 MB with that patch so I guess the default cargo
> options are not the ones you are using.

Hi Tassilo,

I have a new patch for you in git@git.sr.ht:~jirutka/swayr, branch
optimize-size:

    This reduces size of the swayr binary by ~57 %. It doesn't affect the
    size of the swayrd binary because swayrd uses regex.
    
    When building with lto = true, opt-level = "z" and panic = "abort" on
    Alpine Linux: swayr 1 294 kiB -> 554 kiB

Bye,
Jakub

On 2022-01-30 15:02, Jakub Jirutka wrote:
> Wait a moment, I just found a bug, I’ve accidentally removed
> the layout placeholder. I’ll push fix shortly.

Okay, I pushed fix git@git.sr.ht:~jirutka/swayr, branch
truncation (https://git.sr.ht/~jirutka/swayr/log/truncation).

Jakub

Wait a moment, I just found a bug, I’ve accidentally removed
the layout placeholder. I’ll push fix shortly.

Jakub

Hi Tassilo,

I’ve tested 0.13.0-beta.0 and it works great.

Thanks,
Jakub