~jirutka

Recent activity

Re: Please reply to this email to re-license your prior Alpine wiki contributions 5 days ago

From Jakub Jirutka to ~sircmpwn/alpine-devel

I, Jakub Jirutka, hereby re-license my contributions to the Alpine Linux wiki under the username jirutka under the terms of the CC-BY-SA license.

On 1/14/22 9:15 AM, Drew DeVault wrote:
> All future wiki contributions now use the CC-BY-SA license. However,
> existing contributions cannot be re-licensed without the consent of the
> copyright owner.
> 
> If you consent to having your wiki contributions distributed under the
> terms of CC-BY-SA, please reply to this email with the following
> template:
> 
> I, <your name>, hereby re-license my contributions to the Alpine Linux
> wiki under the username <your wiki username> under the terms of the
> CC-BY-SA license.

Re: v3.15 builders bootstrapped 3 months ago

From Jakub Jirutka to ~sircmpwn/alpine-devel

Hi,

I’m sorry, but there’s one change I have to do (because know one did it so far): upgrade Ruby from 2.7 to 3.

Next time I would appreciate informing about the freeze period in advance.

Jakub J.

On 10/16/21 8:07 PM, Kevin Daudt wrote:
> Hello all,
> 
> The v3.15 builders have all been bootstrapped. This means no large
> changes affecting the toolchain or ABI breaking changes should be pushed
> anymore to main. Once the builders start working on community, it will

Re: [3.14.1] is missing kernel module 4 months ago

From Jakub Jirutka to ~sircmpwn/alpine-devel

Hi,

I support this; if you need a minimal memory footprint, then Alpine’s stock kernels are really not a good choice – it’s better to build your own with just the modules you need. You can copy linux-lts aport, modify it for your needs and use it to build your own kernel package.

Jakub

On 9/12/21 12:07 PM, Wolf wrote:
> Hi,
> 
> On 2021-09-09 10:01:21 +0300, Oleksiy Vilny wrote:
>>    We have a need to control APC UPS from within virtual environment
>> and would really like to avoid solution with non -virt Alpine flavour
>> because of hard memory limits we have. Trying to keep virtual machine
>> memory footprint as low as possible we have to use -virt flavour.

Re: Maintainer merge-request policy needed 8 months ago

From Jakub Jirutka to ~sircmpwn/alpine-devel

Hi David,

I mostly agree with you, but I think that 2 weeks is too long time (consider security fixes). However, now I wanted to comment on something else from your email.

> The upstream team develop projects separately but they are still coupled together and that's specifically why a maintainer should always have the final word.

That’s specifically why a maintainer should always add documentation comments into APKBUILD! If you, as a maintainer, have a knowledge of some non-standard/unexpected and non-obvious thing important for the future upgrades, you should document it (for example [1]). Also, if some dependencies are tightly coupled, you should specify the required version range (e.g. `depends="foo>=3.5.0"` or `depends="foo=~3.5.5"`).

Maintainers should share important knowledge (comments in APKBUILD) and document all non-obvious changes (commit messages), not keep it for themselves.

Jakub J.

[1]: https://gitlab.alpinelinux.org/alpine/aports/-/blob/1652cb6a8c604406ec9fd525b9cd4a80185b9558/community/kea/APKBUILD#L6-8

Re: [3.15] System change proposal: rename the Alpine 3.15 release to Alpine 15 9 months ago

From Jakub Jirutka to ~sircmpwn/alpine-devel

Hi,

I completely agree with ncopa. I don’t see any real value in this change, actually the opposite.

Dropping the major version number would be unreasonable; it’s not meaningless and it’s actually a good thing that we don’t increment it too often. We may need or want to introduce some major breaking change in the future (for example, dropping FHS in favour of /package hierarchy) that will require a bit complicated upgrade path. In such case, incrementing the major number, that has not changed in the recent years, clearly communicate to the users (and various automation scripts) that there’s some important change.

>> Yes, to be brutally honest, this is an entirely marketing-related thing, and there is no technical benefit either way. However, this versioning scheme is more aligned with other Linux distributions.

I think that this speaks for itself… Do you really wanna waste precious time of volunteers on such meaningless thing, that has zero benefit for the users, just because it “sounds better” and “others do it too”? Really?!
Don’t get me wrong, I’m not against changes per se and I understand the value of marketing, but I see very low marketing value here, (semi-)technical drawback (mentioned above), breaking unknown number of automation scripts and workload to fix stuff, update documentations etc. All in all, negatives predominate. Also, I hope that we all agree that technical reasons should have always the highest priority.

Akso as ncopa said, there are tons of much more important tasks to do that would have actually positive benefits.

Jakub J.

Re: Alpine 3.13.0 release candidate 3 is out 1 year, 12 days ago

From Jakub Jirutka to ~sircmpwn/alpine-devel

Hi,

I’ve tried to boot fresh Alpine 3.13 on OpenNebula (QEMU) and VMware (proprietary crap), and upgrade 3.12.3 to 3.13.0_rc3. I didn’t notice any problem. However, I don’t use official ISO images nor setup scripts, I have my own created using [1].

Jakub J.

[1]: https://github.com/alpinelinux/alpine-make-vm-image

On 1/8/21 6:16 PM, Natanael Copa wrote:
> Hi!
> 
> I have tagged the third release candidate for alpine 3.13.0.
> 
> This includes some significant improvements and code cleanups in the

Re: Use of supervise-daemon in Alpine 1 year, 1 month ago

From Jakub Jirutka to ~sircmpwn/alpine-devel

Hi,

can you please all stop *forcing* supervise-daemon in init scripts and let the users decide what supervisor they wanna use in the corresponding conf file? As a few people have already written here, OpenRC’s supervise-daemon is not very reliable and has bad defaults. And yet, there are already 126 init scripts with *forced* `supervisor=supervise-daemon`, i.e. the users cannot choose a different supervisor or not supervisor at all without editing the init script (which is not good).

If the init script is written correctly (the command does *not* daemonize itself, `command_background=yes`) and there’s no `supervisor` set (!), the user can just create or edit the corresponding `/etc/conf.d/<svcname>` and add `supervisor=supervise-daemon` to use supervise-daemon instead of the default start-stop-daemon. Or you might predefine `supervisor=supervise-daemon` in the conf file; the user still can change it without any worries about upgrades.

RTFM http://manpages.org/openrc-run/8

Best regards,
Jakub J.

On 9/2/20 9:01 AM, Jean-Louis Fuchs wrote:
> Hi
> 

Re: /usr merge 1 year, 9 months ago

From Jakub Jirutka to ~sircmpwn/alpine-devel

Hi,

I fully support getting rid of useless / and /usr dichotomy (finally!) and agree with Shiz about moving /usr/* into / and making /usr a symlink to /, as well as with the provided arguments. I’d like to also emphasize this one: “I’d personally prefer to rather decide this on technical arguments” – instead of freedesktop suggestions or what others do, which is absurd when we consider that most others adopted systemd…

Jakub J.

On 4/6/20 10:57 AM, Shiz wrote:
> 
> 
>> On Apr 6, 2 Reiwa, at 10:39, Rasmus Thomsen <oss@cogitri.dev> wrote:
>>
>> Hello,
>>
>> I think it makes sense to roll with what other distros do and what

Re: Proposed change: drop busybox iproute2, always use real iproute2 1 year, 10 months ago

From Jakub Jirutka to ~sircmpwn/alpine-devel

Hi,

I strongly disagree with this proposal. I never had any problem with busybox’s iproute2, not even on systems that acts as a router. I believe that busybox’s iproute2 is sufficient for most of the users. Others can always install real iproute2. It’s the same as with coreutils.

Jakub

On 3/20/20 8:29 AM, Ariadne Conill wrote:
> Hello,
> 
> I would like to propose that we drop busybox iproute2, in favor of
> always using real iproute2.
> 
> The primary reasons are:
> 

Re: [alpine-devel] Proposal: Multi-Arch matrix builds on travis-ci 3 years ago

From Jakub Jirutka to ~sircmpwn/alpine-devel

Hi,

I'm sorry to say that, but you're kinda reinventing the wheel. This 
exact approach is already used in [alpine-chroot-install], which is used 
e.g. for building static binaries in [apk-tools] repository.

I didn't use it in aports intentionally, because it's *very* slow. Many 
aports would fail to build due to exceeding the time limit (50 minutes) 
and it would significantly increase waiting time for all builds (due to 
exhausted job queue).

This is not the way to go. The better way is to migrate to a self-hosted 
CI with builders on various architectures. For example sr.ht proposed by 
Drew DeVault looks very promising.