On Thu, 17 Sep 2020 17:34:52 +0000
Mogens Jensen <mogens-jensen@protonmail.com> wrote:

> Hi,
> 
> In diskless mode total amount of RAM is equally split between / and
> /dev/shm. How do I increase size of / and reduce size of /dev/shm?
> 

You increase the size of / with the boot option `rootflags=size=...`

For /dev/shm, I'm not sure.

On Thu, 27 Aug 2020 15:27:22 +0200
Rasmus Thomsen <oss@cogitri.dev> wrote:

> On Thu, 2020-08-27 at 13:20 +0000, Francesco Colista wrote:
> > 27 agosto 2020 14:49, "Leonardo" <rnalrd@gmail.com> wrote:
> > 
> >    
> > > So what should be the approach? I see:
> > > 
> > > 1. let the developer choose between supervised/unsupervised daemon
> > > 
> > > 2. provide two init scripts, supervised and unsupervised
> > > 
> > > 3. provide an "hybrid" init script which has a configurable user

On Fri, 21 Aug 2020 18:51:44 -0600
Ariadne Conill <ariadne@dereferenced.org> wrote:

> > Maybe we can solve it with dependencies and provides instead, with
> > ifupdown-ng with the highest priority.  
> 
> I have no objection to making it a direct dependency of openrc at 
> release time.


How about we do something like this. We make 3 different packages with
provides=ifupdown:

ifupdown-ng (highes provides_priority)

On Thu, 20 Aug 2020 14:33:53 -0600
Ariadne Conill <ariadne@dereferenced.org> wrote:

> Hello,
> 
> On 2020-08-20 11:04, Sören Tempel wrote:
> > Hello,
> > 
> > OpenRC ships a program called supervise-daemon(8) which is capable of
> > starting daemons and restarting them if they crash. Contrary to
> > start-stop-daemon, it does not rely on PID files instead the started
> > daemon is a child process of supervise-daemon.
> > 
> > Some Alpine OpenRC services already use supervise-daemon(8) (e.g.

On Thu, 20 Aug 2020 19:04:45 +0200
Sören Tempel <soeren@soeren-tempel.net> wrote:

> Hello,
> 
> OpenRC ships a program called supervise-daemon(8) which is capable of
> starting daemons and restarting them if they crash. Contrary to
> start-stop-daemon, it does not rely on PID files instead the started
> daemon is a child process of supervise-daemon.
> 
> Some Alpine OpenRC services already use supervise-daemon(8) (e.g.
> unbound, xdm, wpa_supplicant, …). I was recently wondering if we want to
> migrate busybox-initscripts to using supervise-daemon too and was
> pointed to some comments in the GitLab issue tracker which critique use

On Thu, 20 Aug 2020 22:54:17 -0600
Ariadne Conill <ariadne@dereferenced.org> wrote:

> Hello,
> 
> On 2020-08-20 05:16, Ariadne Conill wrote:
> > Hello,
> > 
> > On 2020-07-28 09:36, Ariadne Conill wrote:
> > [...]  
> >> * If ifupdown is dropped from BusyBox, the difference in install size
> >> requirement is only 8KB.  
> > 
> > It is now up to 13KB, but you get a lot for that 20 KB.

On Mon, 17 Aug 2020 10:14:30 +0200
Rasmus Thomsen <oss@cogitri.dev> wrote:

> Hello list,
> 
> I was curious about how we should best handle CVEs for packages written
> in languages like Go or Rust, where we may not package (all)
> dependencies and dependencies are instead fetched during build and
> then statically linked into the resulting binary. Should we add CVE
> info to Rust packages when a crate they depend on has a CVE? Not noting
> it at all seems suboptimal, but adding CVE info for something that
> didn't affect the package at all (e.g. because it didn't use the part
> of the crate that had the CVE) doesn't seem great either.

On Thu, 9 Jul 2020 11:51:20 +0200
spam@ipik.org wrote:

> Dear Natanael,
> 
> Have you come to a definitive conclusion on this particular matter?
> Thank you for consideration and feedback.

Hi, sorry late response. As Ariadne said, we will keep armhf for now,
but do it on a best effort basis. It means that if some package breaks
on armhf we will need help from upstream or other contributor to fix it
or the package will be removed from armhf repo.

-nc

On Fri, 7 Aug 2020 10:52:29 +0200
"Xavier B." <somenxavier@posteo.net> wrote:

> Hi,
> 
> I have a machine (x86) which has 32-bit UEFI. I can be install debian and arch in it [https://hwswbits.blogspot.com/2015/03/getting-linux-on-minix-neo-z64.html] modifying installation script. Is alpine linux prepared for that case or I have to modify somehow the distro? Any hints?
> 
> Thanks in advance,
> Xavier

Short answer: I dont think its tested, but it is possible you could run it 32 bit.

Alternatively you could wget the 32bit grub package from 64bit alpine
and extract the gruia32.efi file and copy it to grubx64.efi similar to

On Tue, 28 Jul 2020 09:36:13 -0600
Ariadne Conill <ariadne@dereferenced.org> wrote:

> Hello,

Hi,

> 
> At present, Alpine uses BusyBox ifupdown as default network device manager, 
> and a few additional 'addon' packages which provide additional scripts that 
> interact with ifupdown.
> 
> We additionally provide Debian ifupdown and, more recently, ifupdown-ng as 
> alternatives.