At first, It’s my project depends on utmps service, I search the web and ask
the mail list, there
is no available rpm packages for utmps. I think I can build it and share it to
others. So I start this venture.
My initial goal is simple: get utmps works for my project and share it to the
> On Apr 10, 2024, at 22:30, Laurent Bercot wrote:
>
> Please note that this list isn't meant for real-time debugging.
> If you want real-time help, please join IRC (#s6 on OFTC), that's what
> it is for.
Thanks for the reminder. I will check it if possible.
>
> Looks like your scandir isn't
Please note that this list isn't meant for real-time debugging.
If you want real-time help, please join IRC (#s6 on OFTC), that's what
it is for.
Apr 10 22:06:53 rpm-builder s6.systemd-boot[15235]: s6-supervise s6-svscan-log:
warning: unable to spawn ./run (waiting 60 seconds): No such
>
> Laurent:
> Could you tell me how to verify s6-svscan works well as there is nothing in
> log.
I got the log, it keeps report the following message every minute, any
suggestion?
[packager@rpm-builder rpmbuild]$ sudo journalctl -f -u s6.service
Apr 10 22:05:01 rpm-builder systemd[1]:
I prefer this way. Some packages prefer s6 as their process supervisor,
some
packages prefer systemd. With the help of s6 rpm package, other rpm
packages
who depend on s6 can install their service in s6’s service directory.
We just pave
for the community, the choice is in their hands.
> On Apr 10, 2024, at 17:56, Laurent Bercot wrote:
>
> - Do you want to start an empty supervision tree at boot, and then
> have the service manager (probably systemd, here) populate it with various
> symlinks to service directories as it brings services up?
I am not sure how to let systems
Since your s6-svscan doesn't run as pid 1, you don't need a finish or a
crash script. Not creating the .s6-svscan directory at all is good: the
default behaviour is suitable for running s6-svscan as a normal service.
The answer to the rest of your questions implies policy decisions. In
other
Got your point, I will prepare a boot script for s6-svcan, prepare the scandir
in that script. Thanks.
Wang
> On Apr 10, 2024, at 15:36, Guillaume Perréal wrote:
>
> Well, I am not discussing whether using /run/service or not is the way to go.
> I am trying to point out that altering the
Well, I am not discussing whether using /run/service or not is the way
to go.
I am trying to point out that altering the content of a volatile file
system in the pre/post install scripts of the package may be useless.
--
Guillaume
Le 2024-04-10 à 07 h 17, ericwq...@qq.com a écrit :
On alpine
On alpine linux, s6 use /run/service as scandir.
On Redhat like linux distribution, we can discuss the best place for scandir.
> On Apr 10, 2024, at 13:14, Guillaume Perréal wrote:
>
> In some distributions, /run is a tmpfs so its content is lost on
> shutdown/reboot. If this is the case here,
Hello,
In some distributions, /run is a tmpfs so its content is lost on
shutdown/reboot. If this is the case here, does it make sense to alter
its content on pre-install/post-uninstall phases ? (Or have I
misunderstood something ?)
--
Guillaume.
Le 10/04/2024 à 04:58, ericwq...@qq.com a
About s6-svscanboot, I tried the following solution:
1. The only remain part is creating scandir (here is /run/service) at the
pre-install phase.
2. Don’t create ./.s6-svscan directory, according to s6 doc:
"If the ./.s6-svscan control directory does not exist, s6-svscan creates it. “
3. Don’t
Thanks for your reply. It helps me a lot. Hoël, I have the same thought as
yours, just need confirmation from upstream.
> On Apr 9, 2024, at 07:24, Laurent Bercot wrote:
>
> As Hoël said, it's a legacy script, for very old installations that need
> to upgrade. It could probably be removed. In
I notice s6-svscanboot is the start script for s6-svscan. I am not an execline
expert, but I can see that s6-svscanboot prepare log directories and start
s6-svscan. If systemd provides log service for s6-svscan. Do we need
s6-svscanboot for rpm package?
No, you don't.
As I said in a
Hi,
Am Tue, Apr 09, 2024 at 06:40:36AM +0800 schrieb qi wang:
The next question is about s6.pre-install, s6.pre-upgrade script. they do the
same thing (setup catchlog user/group), why we need s6.pre-upgrade script if
the previous installation already setup the catchlog user/group?
Probably
I notice s6-svscanboot is the start script for s6-svscan. I am not an execline
expert, but I can see that s6-svscanboot prepare log directories and start
s6-svscan. If systemd provides log service for s6-svscan. Do we need
s6-svscanboot for rpm package?
The next question is about
Thanks for your advice and help.
> On Apr 6, 2024, at 19:00, Laurent Bercot wrote:
>
> - removing all the other files than the sources.
> - making a suitable unit file to start s6-svscan.
> - taking advantage of the fact that systemd, unlike openrc, has a logging
> mechanism, so you don't need
One last question: do we need the s6-openrc rpm package? I know systemd is more
popular for Redhat and Fedora. Any suggestion?
I doubt anyone is going to run openrc on Fedora. If you're going to
package
s6 for a given distribution, you should integrate it properly with that
distribution,
Currently, s6 rpm packages is almost done, except s6-openrc package, all the
other s6 rpm package has the same contents as the alpine package. There is also
some point I need help from this mail list:
1. Try to verify pre-install and pre-upgrade script works for s6 rpm packages.
2. Try to
Let me check the alternatives system first.
> On Apr 4, 2024, at 01:08, Laurent Bercot wrote:
>
> Then it looks like the correct way to proceed, if Eric can coordinate with
> the maintainers of the filesystem and bash packages.
On Wed, Apr 03, 2024 at 01:43:14PM +, Laurent Bercot wrote:
> > There have been some discussions, starting at Fedora, about unifying
> > the bin and sbin directories:
> > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
>
> Ha. 25 years later, they understand that the separation
RHEL and Fedora have an alternatives system:
* https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
* https://www.linux.org/docs/man8/alternatives.html
Then it looks like the correct way to proceed, if Eric can coordinate
with
the maintainers of the filesystem and bash
On 04/03, Laurent Bercot wrote:
> If rpm doesn't have an alternatives system to get the useless binaries out
> of the way, and if /usr/sbin is unusable, then there's nothing left but
> "add another directory to the global PATH", which is super invasive.
RHEL and Fedora have an alternatives
There have been some discussions, starting at Fedora, about unifying
the bin and sbin directories:
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
Ha. 25 years later, they understand that the separation makes no sense,
and *just* when we were going to use that silly separation to
On Tue, Apr 02, 2024 at 09:05:53AM +0800, ericwq...@qq.com wrote:
> > On Apr 2, 2024, at 06:25, Laurent Bercot wrote:
> >
> > If the default PATH has /usr/sbin before /usr/bin for all users, then the
> > best thing is probably to install cd, umask and wait into /usr/sbin. It's
> > not exactly
Yes, --enable-multicall is used.
> On Apr 2, 2024, at 19:19, Laurent Bercot wrote:
>
> Does that mean you're using --enable-multicall? You can, it's just surprising
> for a distribution that uses glibc and doesn't care much about size. :)
Yes, --enable-multicall is used.
> On Apr 2, 2024, at 19:19, Laurent Bercot wrote:
>
> Does that mean you're using --enable-multicall? You can, it's just surprising
> for a distribution that uses glibc and doesn't care much about size. :)
After check the installed package of execline on alpine. I choose to
install main part of execline to /usr/bin.
Create /usr/sbin directory, create relative symbol link for cd, umask
and wait to /usr/bin/execline.
Does that mean you're using --enable-multicall? You can, it's just
After check the installed package of execline on alpine. I choose to install
main part of execline to /usr/bin.
Create /usr/sbin directory, create relative symbol link for cd, umask and wait
to /usr/bin/execline.
# rebuild the conflicted files (filesystem, bash package) in /usr/sbin
mkdir -p
Two options:
1. Move the conflicted files: cd, umask and wait to /usr/sbin, while keep the
others in /bin directory.
2. Install all of them to /usr/sbin directory.
Which one is better?
Wang qi.
> On Apr 2, 2024, at 06:25, Laurent Bercot wrote:
>
> If the default PATH has /usr/sbin before
Sure.
> On Apr 2, 2024, at 06:25, Laurent Bercot wrote:
>
> No, /usr/local is reserved, as the name implies, for local installations:
> packaged software cannot use it.
>
> If the default PATH has /usr/sbin before /usr/bin for all users, then the
> best thing is probably to install cd, umask
Got that, thanks.
> On Apr 2, 2024, at 06:32, Laurent Bercot wrote:
>
> And yes, since execline-provided cd, umask and wait, when called via a
> PATH search (not that a shell will ever do that, but execvp() can), will
> substitute themselves to Fedora-provided POSIX binaries, it is necessary
>
And yes, since execline-provided cd, umask and wait, when called via a
PATH search (not that a shell will ever do that, but execvp() can), will
substitute themselves to Fedora-provided POSIX binaries, it is necessary
to build execline with --enable-pedantic-posix in order to prevent
trouble
[packager@rpm-builder etc]$ env | grep PATH
PATH=/home/packager/.local/bin:/home/packager/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
I guess /user/local/bin or /usr/local/sbin is our first choice? Do we need
--enable-pedantic-posix for /usr/local/bin or /usr/local/sbin?
Luckily, Fedora provides the following default PATH for us. Where the first two
directories is provided by packager user’s .bashrc. Other path are provided by
/etc/profile (system default).
[packager@rpm-builder etc]$ env | grep PATH
On Mon, Apr 01, 2024 at 12:46:27PM +, Laurent Bercot wrote:
> This means that your execline package cannot run execline scripts that
> use cd, umask or wait. It may work for you, but it is not suitable as a
> general audience package.
Certainly. I avoid RedHat-like systems except when
In my (admittedly ugly) package, I simply delete execline's `cd' and
`umask'; `wait' is renamed to `execline-wait', just like `execline-cd'
and `execline-umask' (which are not conflicting and so not deleted).
This means that your execline package cannot run execline scripts that
use cd, umask
file /usr/bin from install of execline-2.9.4.0-1.fc39.x86_64 conflicts
with file from package filesystem-3.18-6.fc39.x86_64
file /usr/bin/cd from install of execline-2.9.4.0-1.fc39.x86_64
conflicts with file from package bash-5.2.26-1.fc39.x86_64
file /usr/bin/umask from
On Mon, Apr 01, 2024 at 07:26:22PM +0800, qi wang wrote:
> Could you provide some suggestion? Or does anyone has some experience
> on that?
In my (admittedly ugly) package, I simply delete execline's `cd' and
`umask'; `wait' is renamed to `execline-wait', just like `execline-cd'
and
Yes, skalibs, execline are different projects. The GitHub site is just a
central and temporary place to hold the spec files.
For skalibs project, I build 4 rpm packages: skalibs, skalibs-devel,
skalibs-devel-static, skalibs-doc.
skalibs-devel depends on skalibs. Just follow the aports
Laurent:
It seems that execline will install files to /bin. On fedora, it will conflict
with other packages:
[packager@rpm-builder rpmbuild]$ sudo rpm -ivh
~/rpmbuild/RPMS/x86_64/execline-2.9.4.0-1.fc39.x86_64.rpm
Verifying... # [100%]
Yes, skalibs, execline are different projects. The GitHub site is just a
central and temporary place to hold the spec files.
For skalibs project, I build 4 rpm packages: skalibs, skalibs-devel,
skalibs-devel-static, skalibs-doc.
skalibs-devel depends on skalibs. Just follow the aports
On Mon, Apr 01, 2024 at 09:09:52AM +, Laurent Bercot wrote:
> I haven't looked in detail, but I'm not sure why you want everything
> in one single RPM.
The packages he makes are not monolithic; the package by me, noted in
earlier messages, is monolithic, due to historical reasons and a lack
I haven't looked in detail, but I'm not sure why you want everything
in one single RPM.
skalibs, utmps, execline and s6 are different projects. A package
should
be one project, not a set of projects. A package manager will handle
dependencies between packages and install all the rpms that
Today, execline rpm package is ready now.
The following is the directory of rpmbuild.
[packager@rpm-builder rpmbuild]$ tree
.
├── BUILD
├── BUILDROOT
├── RPMS
│ └── x86_64
│ ├── execline-2.9.4.0-1.fc39.x86_64.rpm
│ ├── execline-devel-2.9.4.0-1.fc39.x86_64.rpm
│
45 matches
Mail list logo
