*** Bug 173457 has been marked as a duplicate of this bug. ***

*** Bug 173458 has been marked as a duplicate of this bug. ***

Oh. I'm sorry for the duplicates. I entered the bug from a Windows machine with
explorer. We all know how good that is ;-)

Trying to use Source: tag for downloading the source:

http://initng.thinktux.net/download/initng-0.4.0.tar.gz

results in "ERROR 404: Not Found."

Source URL should probably be:
http://initng.thinktux.net/download/v0.4/initng-0.4.0.tar.gz ? :-)

Also i see in that directory 0.4.2 is out, is there a specific reason for using
0.4.0, or just an old spec file?

Lastly a dos2unix of the spec file would be nice :-)

First ideas :
 - The correct download URL is
http://initng.thinktux.net/download/v0.4/initng-0.4.0.tar.gz (you forgot the
v0.4 dir)
 - where can I find Patch0 ?
 - The BuildRoot is not the preferred one 
   (http://fedoraproject.org/wiki/PackagingGuidelines#BuildRoot)
 - 'CFLAGS="$RPM_OPT_FLAGS"' after 'make' is not necessary, this variable is
exported in the shell
 - replace all "/etc" by "%{_sysconfdir}"
 - replace all "/usr/share" by "%{_datadir}"
 - since you use "grubby" in %post, you have to add "Requires(post): mkinitrd"
 - never echo anything in %post (or other scriptlets)
 - you may want to run the scriptlet only on fresh install, not on upgrade. Look
at the beginning of http://fedoraproject.org/wiki/ScriptletSnippets for how to
do that.
 - replace '/usr/share/doc/initng-%{version}/*' in %files by
   '%doc %{_datadir}/doc/initng-%{version}' (%doc because it is documentation,
and remove the /* at the end to own the initng-%{version} directory

Created attachment 121169 [details]
Modified spec file

Cleaned up spec file quite a bit, attached new version to bug, changes:

* Thu Nov 17 2005 Chris Chabot <chabotc> - 0.4.2-1
- Cleaned up '-' in changelog
- New upstream version
- Modified Source to Source0, and changed to download URL
- Changed BuildRoot to fedora adviced/standard format
- Changed setup to setup -q
- Modified to use {_sysconfdir} and {_datadir}
- Temporary disabled %Patch0, not included in source & can't find in download
dir
- added if [ $1 = 1 ] to %post

Definatly not complete yet, but a step in the right direction :-)

rpmlint says:
]# rpmlint /usr/src/redhat/RPMS/i386/initng-0.4.0-3.i386.rpm 
E: initng binary-or-shlib-defines-rpath /lib/initng/libalso.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libbashlaunch.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libchdir.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libchroot.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libcpout.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libcritical.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libdepend.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libdparser.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libenvparser.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libfind.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libfstat.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libhistory.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libinitctl.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libiparser.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/liblast.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libnetprobe.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libngc2.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libpause.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libpidfile.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libreload.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/librenice.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/librespawn.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/librlparser.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libsimplelauncher.so
['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libstcmd.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libstdout.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libsuid.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libsyncron.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libsyslog.so ['//lib']
E: initng binary-or-shlib-defines-rpath /lib/initng/libunneeded.so ['//lib']
E: initng binary-or-shlib-defines-rpath /sbin/initng ['//lib']
W: initng devel-file-in-non-devel-package /lib/libinitng.so
W: initng non-conffile-in-etc /etc/pcmcia/network
E: initng non-executable-script /etc/pcmcia/network 0644
E: initng postin-without-ldconfig /lib/libinitng.so.0.0.0
E: initng library-without-ldconfig-postun /lib/libinitng.so.0.0.0
W: initng dangerous-command-in-%post cp

Woops small correction in %changelog entry, didn't update to new upstream
version, 0.4.2 seems to be missing a lot of configure tools (like install-sh),
so ended up staying with 0.4.0

Mock build with the new spec file, build cleanly

Needs work:
* BuildRequires: fedora-release should not be included
  (wiki: PackagingGuidelines#Exceptions)
* Missing SMP flags. If it doesn't build with it, please add a comment
  (wiki: PackagingGuidelines#parallelmake)
* The package should contain the text of the license
  (wiki: PackageReviewGuidelines)
* Missing ldconfig in %post and %postun
* The doc in installed in /usr/share/doc/initng-0.4.0/initng. The last dir is
superfluous
* Own /etc/initng and /lib/initng
* Typo for -disable-rpath. It's --disable-rpath with two dashes.
* Don't echo anything in %post
* /lib should be replaced by %{_lib} (which is different on 64bit systems)

(In reply to comment #4)
> Source URL should probably be:
> http://initng.thinktux.net/download/v0.4/initng-0.4.0.tar.gz ? :-)

Yep. I'll fix that.

> Also i see in that directory 0.4.2 is out, is there a specific reason for using
> 0.4.0, or just an old spec file?

I didn't succeed in building 0.4.2, that's the reason. It's in initng bugzilla,
so hopefully I'll be able to build 0.4.3

> Lastly a dos2unix of the spec file would be nice :-)

Oops. I'm having hectical days, last time I used my own Fedora home computer was
a couple of days ago. This spec file passed through the M$ machines at my work
before ending up at the web. The original file has correct linefeeds...

/Daniel

(In reply to comment #5)
>  - where can I find Patch0 ?

At the hd of my home computer ;-) I'll put a srpm up here as soon as I get a
chance...

>  - The BuildRoot is not the preferred one 
>    (http://fedoraproject.org/wiki/PackagingGuidelines#BuildRoot)
>  - 'CFLAGS="$RPM_OPT_FLAGS"' after 'make' is not necessary, this variable is
> exported in the shell
>  - replace all "/etc" by "%{_sysconfdir}"
>  - replace all "/usr/share" by "%{_datadir}"
>  - since you use "grubby" in %post, you have to add "Requires(post): mkinitrd"

Ok, I'll fix all this.

>  - never echo anything in %post (or other scriptlets)

Ok. Is there any other good way of pointing the users attention to stuff like this?

>  - you may want to run the scriptlet only on fresh install, not on upgrade. Look
> at the beginning of http://fedoraproject.org/wiki/ScriptletSnippets for how to
> do that.
>  - replace '/usr/share/doc/initng-%{version}/*' in %files by
>    '%doc %{_datadir}/doc/initng-%{version}' (%doc because it is documentation,
> and remove the /* at the end to own the initng-%{version} directory

Ok, I'll look at this too. Thanks for the feedback!

(In reply to comment #9)
> * Missing ldconfig in %post and %postun

Is this really needed? Nothing in the package is really used until after a
reboot anyway.

> * Typo for -disable-rpath. It's --disable-rpath with two dashes.

This is no typo. This is because I've fiddled around with the darn rpath stuff a
lot and couldn't get it to work, and finally I thought maybe it should just be
one dash. However, whatever I put there I get the rpmlint errors about rpath
anyway. Anyone knows what to do about this?

> Is there any other good way of pointing the users attention to stuff like this?

I'd say to put that in a README.Fedora file, and put it in %doc. By convention,
the scriptlets should never output anything (it can crash some front-ends)

> I've fiddled around with the darn rpath stuff a lot and couldn't get it to work

If you cd in the source dir and run 
find -name Makefile.in | xargs grep rpath
you'll see that many Makefiles have rpath hardcoded.

Created attachment 121175 [details]
0.4.0-4 spec file

Ok, after having installed a notepad replacement at the computer at work, I
think I've changed most of what's mentioned above.

Just a notice about the default_runlevels.patch. I can't reach it right now so
it'll stay commented out for now, but what it does is change what runlevels are
enabled by default. It removes system/coldplub (which doesn't work in Fedora
anywah) and adds some others like system/usb.

I guess I'll post an initng bug about the rpath stuff, as it'll have to be fixed
upstreams, right?

Created attachment 121178 [details]
The correct 0.4.0-4 spec file

Sorry. Too much right now.

This is default_runlevels.patch:


--- initng-0.3.5/gen_system_runlevel.orig       2005-11-05 12:41:30.000000000 +0100
+++ initng-0.3.5/gen_system_runlevel    2005-11-05 12:42:56.000000000 +0100
@@ -47,7 +47,13 @@
 system/keymaps
 system/urandom
 system/swap
-system/coldplug
+daemon/dbus
+daemon/dcron
+daemon/anacron
+daemon/hald
+daemon/klogd
+daemon/syslogd
+daemon/portmap
 net/lo" > ${DESTDIR}/etc/initng/system.runlevel

 if [ -x /usr/sbin/readahead ] || [ -x /sbin/readahead ]; then

I've created the patch from your posting, modified the spec file (based on your
latest -4 release), and added ldconfig to %post/%postrun to make gauret happier :-)

I've posted this modified spec file at:
http://www.xs4all.nl/~chabotc/initng.spec

The patch file at:
http://www.xs4all.nl/~chabotc/default_runlevels.patch

And a working src.rpm (including patch file) at:
http://www.xs4all.nl/~chabotc/initng-0.4.0-5.src.rpm

I felt brave and tried it out, and i got a working booting system, and i have to
say booting very fast :-) (Disclaimer: though ofcource it doesn't start/do
everything that regular init does yet so a straight comparisment is imposible)

I hope i was of some help Daniel!

Still a few things to change :
* BuildRequires: fedora-release should not be included
  (wiki: PackagingGuidelines#Exceptions)
* The package should contain the text of the license
  (wiki: PackageReviewGuidelines)
* In the files list, change /lib into %{_lib}
* The package conflicts with pcmcia-cs on the file /etc/pcmcia/network
* I would not have put the /sbin/ldconfig inside the test in %post, but I guess
that's harmless

Created attachment 121219 [details]
Initng 0.4.0-6 spec file

(In reply to comment #19)
> * BuildRequires: fedora-release should not be included
>   (wiki: PackagingGuidelines#Exceptions)

Removed.

> * The package should contain the text of the license
>   (wiki: PackageReviewGuidelines)

According to the guidelines if (and only if) the source package includes the
text of the license(s) in its own file, then it should be shipped. The source
package doesn't. Or am I wrong here?

> * In the files list, change /lib into %{_lib}

Fixed.

> * The package conflicts with pcmcia-cs on the file /etc/pcmcia/network

Ok, I removed the file completely from the package. I guess there is no meaning
shipping it if it's available in another package, right?

> * I would not have put the /sbin/ldconfig inside the test in %post, but I
guess
> that's harmless

Moved it outside the if. Seems more logical to me...

> According to the guidelines if (and only if) the source package includes the
> text of the license(s) in its own file, then it should be shipped. The source
> package doesn't. Or am I wrong here?

There is a COPYING file in the tarball, containing the GPLv2. It would be nice
to include the other doc files too. Just add this line to the top of the %files
list:

%doc COPYING AUTHORS CODING_STANDARDS FAQ NEWS README TODO
(INSTALL is useless since we're using rpm)

Created attachment 121220 [details]
0.4.0-7 spec

(In reply to comment #21)
> There is a COPYING file in the tarball, containing the GPLv2. It would be
nice
> to include the other doc files too. Just add this line to the top of the
%files
> list:
> 
> %doc COPYING AUTHORS CODING_STANDARDS FAQ NEWS README TODO
> (INSTALL is useless since we're using rpm)

Ok, I see. Now fixed.

It seems that the big problem right now (except for the fact that 0.4.2 won't
build at all without modification) is the rpath stuff. I've looked in the
source, and I can't really see where the rpath stuff comes from. It doesn't
help fixing the Makefile.in's since they're generated from Makefile.am's, and I
can't seem to see what's wrong in the Makefile.am's. Anyone here that has more
knowledge in autoconf/automake?

After some more reading up, it seems that the rpath problems _could_ be because
I'm setting _prefix to / in the spec file. I couldn't get stuff installed in the
proper place any other way (since we don't want initng to end up in /usr/sbin),
but if this is the problem I guess someone here has some nice solution about
what to do?

(In reply to comment #23)
> 
> I'm setting _prefix to / in the spec file. [...] I guess someone here has some
> nice solution about
> what to do?

Read info autoconf

You probably want something similar to
%configure --sbindir=/sbin --libdir=/%{_lib}

I confirm that:
%configure --libdir=/%{_lib} --sbindir=/sbin --disable-rpath 
remove the rpath. Thanks Ralf.

A few more things: 
 - please rename the patch to "initng-default-runlevel.patch", to make it appear
side to side with other initng files in the SOURCES dir.
 - in the %files list, the lines beginning with %{_lib} must begin with "/".
(%{_lib} resolves to "lib", not "/lib")
 - remember to own the %{_sysconfdir}/initng and /%{_lib}/initng dirs (just
remove the "/*" at the end of their lines in the %files list.
 - the files installed from the fixes subdir are installed in /usr/sbin instead
of /sbin. If those scripts are needed for booting, the fixes/Makefile.in will
need patching to make it use $(sbindir) instead of $(_prefix)/sbin.

Created attachment 121274 [details]
initng 0.4.4-1 spec file

Ok, now I think most of the stuff is fixed. I noticed though that now some
documentation files ends up in /share/doc/initng-0.4.4/initng. Gotta look at
that when I get time.

Who decides when this package is fit for Fedora extras?

Created attachment 121331 [details]
initng 0.4.4-2 spec file

Ok. Now hopefully everything is fixed. Since I'm stuck at M$ machines at work
I've been unable to test, would be glad if someone else did (I _will_ install
Fedora at work too, thought I'd wait for FC5test1 first).

Created attachment 121341 [details]
Patch to the spec file

Here's a patch with a few modifications :
- commenting the %define _prefix / is not enough, rpm will evaluate it anyway.
I've removed it
- fixed the docs dir problem. We can's use the "%doc COPYING..." macro in the
%files list since it remove the directory, and we have other files to put in
it.
- since there's a file installed in /etc/ifplugd/actions.d, we have to depend
on the ifplugd package. Added it

What do you think of those changes ?

Created attachment 121344 [details]
initng 0.4.4-4 spec file

(In reply to comment #28)
> - commenting the %define _prefix / is not enough, rpm will evaluate it
anyway.
> I've removed it

Oh, thought commenting would be enough. Removed the SysVinit requirement line
as well.

> - fixed the docs dir problem. We can's use the "%doc COPYING..." macro in the

> %files list since it remove the directory, and we have other files to put in
> it.

Ok. I replaced "%{_datadir}/doc" with "%{_docdir}" in the mkdir at line 38 as
well.

> - since there's a file installed in /etc/ifplugd/actions.d, we have to depend

> on the ifplugd package. Added it

Is ifplugd a package that people normally has got installed?

> What do you think of those changes ?

Looks fine to me. Does %{?dist} in the release mean anything useful?

Does this mean we're getting close to finished?

> Is ifplugd a package that people normally has got installed?

Not really. But it's in extras. If you don't want to depend on it, you have to
create an initng-ifplugd package containing those files. In fact, it would be
better. I'll send you a patch.

> Does %{?dist} in the release mean anything useful?

It will be replaced by ".fc4" on FC4, ".fc5" on FC5, etc... This way you can
build for all versions with the same spec file.
http://fedoraproject.org/wiki/DistTag

> Does this mean we're getting close to finished?

We're getting closer with every step... :)
Obviously, packaging an init replacement is not trivial and can take some time
to do it well.

Created attachment 121350 [details]
Patch to split ifplugd support

(In reply to comment #30)
> > Does %{?dist} in the release mean anything useful?
> It will be replaced by ".fc4" on FC4, ".fc5" on FC5, etc... This way you can
> build for all versions with the same spec file.
> http://fedoraproject.org/wiki/DistTag

Oh, nice! Thanks.

> > Does this mean we're getting close to finished?
> We're getting closer with every step... :)
> Obviously, packaging an init replacement is not trivial and can take some time
> to do it well.

Obviously. I'm just eager to see the respons from the community ;-)

Created attachment 121435 [details]
initng 0.4.4-5 spec

Just applied the patch...

I built and installed the package and made the following observations:

1. Since the spec file wants a file "initng-default-runlevel.patch" I downloaded
the file patch mentioned above and renamed the file. This works fine but I get
warnings when building the rpm:
...
Patch #0 (initng-default-runlevel.patch):
+ patch -p1 -b --suffix .default_runlevel -s
patch unexpectedly ends in middle of line
patch unexpectedly ends in middle of line
+ exit 0
...
Maybe the patch needs to be cleaned up so it applies without warnings.

2. During the (shockingly fast! 12sec!) boot process the console font is messed
up but gets fixed about half-way though. The lines that where output until then
stay messed up though which makes debugging a bit hard. There are some error
messages but I can't see which services they belong to due to the font problem.

3. USB isn't set up at all with the current settings and doing a 'ngc -u
system/usb' doesn't work because ist tries to bring up the USB host with
"modprobe usbcore" whereas Fedora seems to alias them as "usb-controller" and
"usb-controller1" on my system.

4. "daemon/xfs" needs to be added to "default.runlevel" or X11 cannot be started.

After these changes I was able to log in as root and call 'ngc -u gdm' which
brought up X nicely.

So far I'm *very* impressed by the results. Great work!

for more convenience, here's a src.rpm with the last spec file :
http://gauret.free.fr/fichiers/rpms/fedora/initng-0.4.4-5.src.rpm
It contains the patch that should fix the problems mentioned above.

(In reply to comment #34)
> 2. During the (shockingly fast! 12sec!) boot process the console font is messed
> up but gets fixed about half-way though. The lines that where output until then
> stay messed up though which makes debugging a bit hard. There are some error
> messages but I can't see which services they belong to due to the font problem.

Yes, this is a problem that we've been trying to solve. For some reason it only
seems to affect Fedora users (and not all of them, I haven't seen this myself).
I'll try to look at this in the weekend if I get time...

> 3. USB isn't set up at all with the current settings and doing a 'ngc -u
> system/usb' doesn't work because ist tries to bring up the USB host with
> "modprobe usbcore" whereas Fedora seems to alias them as "usb-controller" and
> "usb-controller1" on my system.

Hmmm... USB works for me (but then again, I do not use the kernel that comes
with Fedora). Is the usb modules named the same ("usb-controller") in all Fedora
kernels? If that's the case, this is an easy fix...

> 4. "daemon/xfs" needs to be added to "default.runlevel" or X11 cannot be started.

Well, that depends on the settings in Xorg.conf. My X comes up fine with no xfs
running. From what I understand we're trying to get rid of xfs in Fedora, so I
doubt it's a good idea to have it in default runlevel. Or am I wrong?

> So far I'm *very* impressed by the results. Great work!

Good! It's my hope that this will be in Fedora extras some time next week...

I have the same problem with the console font on boot, but I guess it's not
top-priority right now.

Concerning USB, changing the modprobe call to load usb-controller1 in
system/usb.i worked for me. I guess we can patch it to modprobe usb-controller
and usb-controller1, since the output is redirected to dev/null anyway

I've spent some time writing init script to get all the services I'm running in
initng. You'll find them here :
http://gauret.free.fr/fichiers/rpms/fedora/initng/
Not all of them should be added to the rpm, but some of them are useful :
 - audit.i (goes in system/, not daemon/) : launched by default on Fedora
 - cups-config-daemon.i : allows dynamic adding of printers via HAL
 - dhcpd.i : basic daemon
 - httpd.i : apache is called httpd on Fedora
 - init.i : this is a wrapper around legacy init scripts. Call the service as
daemon/init/spamassassin for example, and it will execute
"/etc/init.d/spamassassin start"
 - mDNSResponder.i : implementation of Apple's Rendezvous. Started by default on
Fedora
 - mysql.i : fixed the damon_args and commented out the pid_file which confuses
initng (the started daemon is mysqld_safe, and the pid refers to the first
child, mysqld)
 - named.i : basic daemon
 - postfix.i : basic daemon
 - snmpd : basic daemon
The other scripts (nagios, nvidia-glx, pure-ftpd, shorewall, smartd, ulogd) can
be useful too, it's up to you to decide if you want to include them in the rpm
or not.
This leads me to another question: what is the best way for a package to ship
it's init script ? Surely the ining project cannot ship .i files for every
daemon in the wild. For example, I maintain the pure-ftpd and ulogd rpms, should
I just package them as documentation, or is there a way to make them available
to initng directly ? (I could use triggers, but I've learned that it's evil
*wink Mickael* ). Anybody ?

A few of the services in my "chkconfig --list" list are still missing, and I did
not write a .i file for them yet : nfs server (too complicated for me), kudzu
(I'm afraid of this beast, will write a .i file one day maybe), and readahead
(guess it's not needed anymore :) )

A last question : in a .i file, can a service declare itself as "being_used_by"
? For example, there is an init script for the nvidia driver shipped by
rpm.livna.org, that we cannot include in fedora. But if this script is present,
it should be started before {g,k,x}dm. We can't modify gdm.i to add "use =
nvidia-glx" because it is not part of fedora. Can the nvidia-glx.i file have
some kind of "used_by" directive ?

OK, with the USB fix and the basic init scripts, I think we're getting close to
a first usable Fedora-integrated version of initng. Thanks for the work you've
put into this guys

(In reply to comment #37)
> Concerning USB, changing the modprobe call to load usb-controller1 in
> system/usb.i worked for me. I guess we can patch it to modprobe usb-controller
> and usb-controller1, since the output is redirected to dev/null anyway

Yep, sounds good. I'll see to it that this change gets in the next initng 
release, which I'm guessing is around the corner.

> I've spent some time writing init script to get all the services I'm running 
in
> initng. You'll find them here :
> http://gauret.free.fr/fichiers/rpms/fedora/initng/
> Not all of them should be added to the rpm, but some of them are useful :

Ok, I'll see to it that these daemons (with small changes) gets into initng 
cvs, so we'll have them in next release. I think it's nicer to have them in 
upstreams. Maybe it's a good idea to not release the rpm to extras before next 
initng release?

Firstly, they should be named *.ii, since installation then converts them to .i 
files (which gives possibility to have different stuff for different distros in 
the same service file).

>  - audit.i (goes in system/, not daemon/) : launched by default on Fedora

Looks ok.

>  - cups-config-daemon.i : allows dynamic adding of printers via HAL

Guess I'll put @ signs around the daemon arg. Not really sure what they're for 
though ;-)

>  - dhcpd.i : basic daemon

It's no good depending on net/eth0 or net/eth1. Would a simple require_network 
work? (Why do we need this anyway? My network using dhcp comes up without this)

>  - httpd.i : apache is called httpd on Fedora

Hmmm... It would be nice if initng had a way to put in aliases for services. 
I'll look into that... I'll add this one in the meantime.

>  - init.i : this is a wrapper around legacy init scripts. Call the service as
> daemon/init/spamassassin for example, and it will execute
> "/etc/init.d/spamassassin start"

Nice! And simple! I wonder why nobody thought of this before?

>  - mDNSResponder.i : implementation of Apple's Rendezvous. Started by default 
on
> Fedora

Ok.

>  - mysql.i : fixed the damon_args and commented out the pid_file which 
confuses
> initng (the started daemon is mysqld_safe, and the pid refers to the first
> child, mysqld)

This is a case where we'd put a "#ifd fedora" with without the pid_file in the 
mysqld.ii file.

>  - named.i : basic daemon
>  - postfix.i : basic daemon
>  - snmpd : basic daemon

Ok.

> The other scripts (nagios, nvidia-glx, pure-ftpd, shorewall, smartd, ulogd) 
can
> be useful too, it's up to you to decide if you want to include them in the rpm
> or not.

I guess it won't hurt putting them in as well.

> This leads me to another question: what is the best way for a package to ship
> it's init script ? Surely the ining project cannot ship .i files for every
> daemon in the wild. For example, I maintain the pure-ftpd and ulogd rpms, 
should
> I just package them as documentation, or is there a way to make them available
> to initng directly ? (I could use triggers, but I've learned that it's evil
> *wink Mickael* ). Anybody ?

This has been discussed a lot in initng team. The big hope is that services 
will start to ship their initng scripts as they ship SysVinit scripts today. In 
the meantime I guess we'll have to ship initng with zillions of scripts.

> A few of the services in my "chkconfig --list" list are still missing, and I 
did
> not write a .i file for them yet : nfs server (too complicated for me), kudzu
> (I'm afraid of this beast, will write a .i file one day maybe), and readahead
> (guess it's not needed anymore :) )

The plan is that initng will somehow check what services are on in SysVinit 
upon installation (either by using chkconfig in some way or simply looking 
in /etc/whatever) and enable the corresponding initng services. This project is 
however not even started yet.

> A last question : in a .i file, can a service declare itself 
as "being_used_by"
> ? For example, there is an init script for the nvidia driver shipped by
> rpm.livna.org, that we cannot include in fedora. But if this script is 
present,
> it should be started before {g,k,x}dm. We can't modify gdm.i to add "use =
> nvidia-glx" because it is not part of fedora. Can the nvidia-glx.i file have
> some kind of "used_by" directive ?

I'll suggest this to Jimmy. I guess it wouldn't be any really big thing to add 
this, sounds like a good idea to me...

> OK, with the USB fix and the basic init scripts, I think we're getting close 
to
> a first usable Fedora-integrated version of initng. Thanks for the work you've
> put into this guys

The same. It's really nice working with you!

(In reply to comment #38)
> (In reply to comment #37)
> >  - dhcpd.i : basic daemon
> 
> It's no good depending on net/eth0 or net/eth1. Would a simple require_network 
> work? (Why do we need this anyway? My network using dhcp comes up without this)

dhcpd is a DHCP server, not a client.

(In reply to comment #39)
> > It's no good depending on net/eth0 or net/eth1. Would a simple 
require_network 
> > work? (Why do we need this anyway? My network using dhcp comes up without 
this)
> dhcpd is a DHCP server, not a client.

Hmmm... Sometimes I wonder where my brain is. Never mind me.

(In reply to comment #37)
> A last question : in a .i file, can a service declare itself 
as "being_used_by"
> ? For example, there is an init script for the nvidia driver shipped by
> rpm.livna.org, that we cannot include in fedora. But if this script is 
present,
> it should be started before {g,k,x}dm. We can't modify gdm.i to add "use =
> nvidia-glx" because it is not part of fedora.

But hey! After a closer thought, why can't we? "use =" only means that this 
service will be started after service x if service x is in the runlevel. So 
having "use = nvidia-glx" doesn't really hurt even if there is no nvidia-glx. 
Of course, with this reasoning, nvidia-glx must be added to default runlevel 
upon installation, but it seems better than the alternative. Thoughts?

(In reply to comment #38)
> (In reply to comment #37)
> > Concerning USB, changing the modprobe call to load usb-controller1 in
> > system/usb.i worked for me. I guess we can patch it to modprobe usb-controller
> > and usb-controller1, since the output is redirected to dev/null anyway
> 
> Yep, sounds good. I'll see to it that this change gets in the next initng 
> release, which I'm guessing is around the corner.

I'm not sure if it's a good idea to rely on hardcoded names like
"usb-controller". What if there is an entry for "usb-controller2"? My guess is
that something along these lines would be better:

for i in `cat /etc/sysconfig/hwconf |grep "driver: .*-hcd"|cut -d" " -f2`;do
  /sbin/modprobe $i >/dev/null
done

This should load all necessary host controller modules no matter how they are named.

> After a closer thought, why can't we?

IANAL, but I think that from a purely legal point of view, it's better if Fedora
does not contain references to non-free software (non-free as in patented)
We remove the mp3 code from tarballs before making the SRPM... We shouldn't even
be referring to rpm.li*na.org...
From a higher point of view, it just scales better if a service can say "I
should be started before this one", than if the distro has to take every 3rd
party rpms into account.

(In reply to comment #42) 
> I'm not sure if it's a good idea to rely on hardcoded names like
> "usb-controller". What if there is an entry for "usb-controller2"? My guess is
> that something along these lines would be better:
> [snip]

+1, that looks much better.

I had a couple of free minutes last night and could not resist so I build and
installed initng...

Looks pretty nice to be ready to go in about 8 seconds compared to estimated
30-35 normally.

Here are some toughts so:
 - I do not like rhgb (hence I don't use it ^^) but having something other then
(for the normal desktop user) boring init msg is sure something fedora needs to
have. So I tought maybe adding splashy even for normal boot would be great (and
even better for initng because the initng layout seems to me more confusing for
desktop users then the old init one...) I will see if I can wrap something up on
that matter

- on my first boot initng nfs,xfs,gdm and of course nvidia-glx where missing and
I tought of how switching from old init to initng would impact end users. In my
opinion we should think of a way to make switching smoother ;) So two things
come to mind: Either ship scripts which will be run e.g. as init scripts which
will compare runlevels and add/delete services (being the easier idea) or making
wrappers for service/chkconfig and friends so that changes will be done for
both(all) installed inits...

Other then that everything worked pretty great (except maybe for the shutdown...
but that could be some issue with my nfs as well ^^)

Hmmm, at the end of shutting down the machine I get an error saying that /
cannot be unmounted because it is busy and then a promt to enter my root
password. Any ideas what the problem could be?

I've updated a few scripts:
- cups-config-daemon: wrong dependencies
- shorewall: make it use ulogd if present.
- denyhosts: wrong executable name (denyhosts is shipped with initng IIRC, so we
need a fedora-specific fix)
I've added a patch to the initial.i script, or udevd won't be started. There is
also a patch to usb.i to have it call udevstart after usb is up, or we don't get
/dev/usb/. Only with this can I use my usb printer.

Strange things:
- the man page says that "ngc -j reboot" reboots the system, but if I do that I
get "initng [default]: symbol lookup error: /lib/initng/libstcmd.so: undefined
symbol: initng_set_runlevel", and then a kernel panic as reported above.
- on one reboot, my two network cards were detected in the wrong order (eth0 was
eth1 and vice versa)
- klogd refuses to stop, which make me unable to reboot since initng says "Cant
stop service default, with status FAIL_STOPPING".

Some comments:

* The versioned dependencies

  | Requires: glibc >= 2.3
  | Requires: bash >= 3.0

  are pretty pointless with recent RPM. You (probably) want a certain
  upstream version but such a dependencies can not be expressed with
  rpm anymore because missing epoch are assumed to be '0'; e.g. a
  package 'glibc = 1:2.1' would fulfill the deps above.

  Because every relevant platform (FC3+) has the glibc and bash with
  these versions.


* I would like to avoid the

  | Requires(post): mkinitrd

  dependency. It adds lot of bloat which is not required for core
  initng functionality and might be unwanted in chroot() environments
  like vservers.

  IMO, it should be avoided completely by

  |-        if [ -f /boot/grub/grub.conf ]; then
  |+        if [ -f /boot/grub/grub.conf -x /sbin/grubby ]; then

  or putting it into a '%triggerin -- mkinitrd'


====

* 'ngc --help' produces

  | ...
  |  [-A] --service_dep_on_deep opt  : Print what services me depends on deep
  |  [-b] --service_dep_on_me opt    : Print what dependencies that are depending on me
  | *** buffer overflow detected ***: ngc terminated
  | ======= Backtrace: =========
  | /lib/libc.so.6(__chk_fail+0x41)[0x4f561c45]
  | /lib/libc.so.6(__strcpy_chk+0x0)[0x4f561298]
  | ngc[0x8049011]
  | ngc[0x8049169]
  | ngc[0x80495eb]
  | /lib/libc.so.6(__libc_start_main+0xdf)[0x4f498d5f]
  | ...

  Package was built on FC4.

* system/mountfs.i contains

  |       # /bin/mount all type bind.
  |       /bin/mount -at bind

  This is problematic because:

  a) it does not handle entries like

     | /srv/mnt/var/volatile/cache     /var/cache                      none    bind,nosuid

     There, the -t type is 'none' but not 'bind'. Such a notation
     reflects the underlying mount(2) syscall because 'bind' is a
     mountflag but not a filesystemtype. Writing

     | /bin/mount -at none

     would mount them too.

  b) it will fail for entries like

     | remote:/fs       /srv/fs0   nfs  ...
     | /srv/fs0         /srv/fs1   bind ...

     Because the 'mount -at bind' is buried in complex code, this is
     difficultly to workaround

* system/issue.i creates an /etc/issue with

  | Unknown distribution

  This should be replaced with content of /etc/fedora-release

* there are several places were 'shud' is used instead of 'should'. This
  typo should be fixed

(In reply to comment #47)
> I've updated a few scripts:
> - cups-config-daemon: wrong dependencies
> - shorewall: make it use ulogd if present.
> - denyhosts: wrong executable name (denyhosts is shipped with initng IIRC, so we
> need a fedora-specific fix)

Ok. All your scripts with the above changes are now in initng svn and will be in
0.4.5.

> I've added a patch to the initial.i script, or udevd won't be started.

There is already a fix for this in svn.

>  There is
> also a patch to usb.i to have it call udevstart after usb is up, or we don't get
> /dev/usb/. Only with this can I use my usb printer.

Gosh! This explains why my printer hasn't been working all this time! Thanks!
(now in svn)

> Strange things:
> - the man page says that "ngc -j reboot" reboots the system, but if I do that I
> get "initng [default]: symbol lookup error: /lib/initng/libstcmd.so: undefined
> symbol: initng_set_runlevel", and then a kernel panic as reported above.

This is in initng Bugzilla.

> - on one reboot, my two network cards were detected in the wrong order (eth0 was
> eth1 and vice versa)

Hmmm... Haven't heard of this before. Please file a bug if it happens again!

> - klogd refuses to stop, which make me unable to reboot since initng says "Cant
> stop service default, with status FAIL_STOPPING".

I think there's built in functionality in initng which should kick in an kill
services that refuses to die by themselves. I wonder why it doesn't do that
here. How long did you wait?

http://gauret.free.fr/fichiers/rpms/fedora/initng-0.4.4-5.src.rpm
fails on an x86_64 machine:

* on boot, it gives out
  
  | Will start /sbin/sulogin in a fork(), 
  | initng is paused until fork returns.
  | 
  | Give root password for maintenance
  | (or type Control-D to continue): 


  Probably caused by

  | getpid()                                = 6365
  | open("/lib/initng", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOENT (No such file or directory)
  | fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
  | mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaabc4000
  | write(1, "Will start /sbin/sulogin in a fo"..., 39Will start /sbin/sulogin in a fork(), 


* it creates /lib64 RPATHs

(In reply to comment #48)
> * The versioned dependencies
> 
>   | Requires: glibc >= 2.3
>   | Requires: bash >= 3.0
> 
>   are pretty pointless with recent RPM. You (probably) want a certain
>   upstream version but such a dependencies can not be expressed with
>   rpm anymore because missing epoch are assumed to be '0'; e.g. a
>   package 'glibc = 1:2.1' would fulfill the deps above.

But Fedora doesn't use epochs for neither glibc nor bash, do we? Gauret, what do
you say about this?

> * I would like to avoid the
> 
>   | Requires(post): mkinitrd
> 
>   dependency. It adds lot of bloat which is not required for core
>   initng functionality and might be unwanted in chroot() environments
>   like vservers.

Makes sense to me. But then again, I think it's a question for the rpm building
guru's here ;-)


> * 'ngc --help' produces
> 
>   | ...
>   |  [-A] --service_dep_on_deep opt  : Print what services me depends on deep
>   |  [-b] --service_dep_on_me opt    : Print what dependencies that are
depending on me
>   | *** buffer overflow detected ***: ngc terminated
>   | ======= Backtrace: =========
>   | /lib/libc.so.6(__chk_fail+0x41)[0x4f561c45]
>   | /lib/libc.so.6(__strcpy_chk+0x0)[0x4f561298]
>   | ngc[0x8049011]
>   | ngc[0x8049169]
>   | ngc[0x80495eb]
>   | /lib/libc.so.6(__libc_start_main+0xdf)[0x4f498d5f]
>   | ...

Que? This is really strange! Is it reproducable?

> * system/mountfs.i contains
> 
>   |       # /bin/mount all type bind.
>   |       /bin/mount -at bind
> 
>   This is problematic because:
> 
>   a) it does not handle entries like
> 
>      | /srv/mnt/var/volatile/cache     /var/cache                      none  
 bind,nosuid
> 
>      There, the -t type is 'none' but not 'bind'. Such a notation
>      reflects the underlying mount(2) syscall because 'bind' is a
>      mountflag but not a filesystemtype. Writing
> 
>      | /bin/mount -at none
> 
>      would mount them too.

Ok, I don't know much about these things, but wouldn't that also mount other
things? Most of what needs to be mounted seems to be mounted some lines up...

> * system/issue.i creates an /etc/issue with
> 
>   | Unknown distribution
> 
>   This should be replaced with content of /etc/fedora-release

Are you really using latest release? This is a known bug in earlier versions, I
really thought it was long gone...

> * there are several places were 'shud' is used instead of 'should'. This
>   typo should be fixed

Haha... Well, Jimmy (the author) is heck of a coder, but his english really
sucks. I'll look what I can do in svn ;-)

Created attachment 121518 [details]
initng 0.4.4-6 spec

I added a little crude %post script to check which services are enabled in
SysVinit, and try to enable the same services in initng. This is the first try
and highly experimental. Does it seem like a good idea to do something like
this?

> >   | *** buffer overflow detected ***: ngc terminated
> ...
> Que? This is really strange! Is it reproducable?

It is caused by an strcat() at ngc2.c:553 and/or 556:

530     /* get help */
531     int ngc_hlp(void)
532     {
...
545             char lname[26];
546
547             /* copy name to the new static array */
548             strncpy(lname, row.l, 25);
549
550             switch (row.o)
551             {
552                 case USES_OPT:
553                     strcat(lname, " <opt>");
554                     break;
555                 case REQUIRES_OPT:
556                     strcat(lname, " opt");


(gdb) p row
        deINT_COMMAND,  
  o = REQUIRES_OPT, 
  d = "Print what dependencies that are depending on me deep", '\0' <repeats 47 times>, "

bugzilla mangled the gdb output; at least, row.l is the 23 char sized string
"service_dep_on_me_deep"

(In reply to comment #51)
> But Fedora doesn't use epochs for neither glibc nor bash, do we?

Which doesn't mean we won't have to in the future. I don't think that porting
initng to much older Fedora Core versions is a priority (way too much work for
little benefit), we should focus on the current version and higher.
Those version requirements seem strange to me too. I'd suggest to drop them. The
simpler, the better.

> Makes sense to me. But then again, I think it's a question for the rpm 
> building guru's here ;-)

Which would be Enrico :)
His proposition looks good to me too, except there's a missing "-a" in the test:
[ -f /boot/grub/grub.conf -a -x /sbin/grubby ]

> Que? This is really strange! Is it reproducable?

Same thing here.

I just noticed a reference to denyhosts, which is a package I maintain in
Extras.  How does denyhosts relate to initng?

(In reply to comment #56)
> I just noticed a reference to denyhosts, which is a package I maintain in
> Extras.  How does denyhosts relate to initng?

Initng needs special initscripts, and the one written for denyhosts was calling
/usr/sbin/denyhosts instead of /usr/sbin/denyhosts.py. I just fixed that.

Just noticed another problem in the sniplet posted in comment #53:

The strncpy(3) might not terminate the string so simply increasing
buffer size won't be enough. Instead of, write

| char lname[32];
| ...
| strncpy(lname, row.l, 25);
| lname[25] = '\0';
| ...
| switch (row.o)

in plugins/ngc2/ngc2.c and adjust the '25' some lines below (sorry, I
am too lazy for a patch).

=======

Regarding the %post scriptlet:

I would move its functionality into a separate script which gets
shipped with 'initng' and executed by %post. This would remove
complexity from the spec file and gives the user a way to start the
SysV -> initng conversion manually.


=======


> But Fedora doesn't use epochs for neither glibc nor bash, do we?

Fedora does not ship bash < 3 or glibc < 2.3, neither but deps on bash
and glibc are brought in by autodeps.

Writing the versioned 'Requires: bash > 3.0' is not wrong but I would
not do it.


> >   | Unknown distribution
> >
> >   This should be replaced with content of /etc/fedora-release
>
> Are you really using latest release? This is a known bug in earlier
> versions, I really thought it was long gone...

I use
http://gauret.free.fr/fichiers/rpms/fedora/initng-0.4.4-5.src.rpm and
quick look into SVN shows that there is handling of fedora in
system/issue.ii.


> >      | /bin/mount -at none
> >
> >      would mount them too.
>
> Ok, I don't know much about these things, but wouldn't that also
> mount other things? Most of what needs to be mounted seems to be
> mounted some lines up...

it would mount the pseudofs (e.g. tmpfs, procfs, usbfs, ...)  This
issue is no blocker and can be solved later/upstream, too.

> I would move its functionality into a separate script which gets shipped with 
> 'initng' and executed by %post

+1. We need such a script anyway. comment 52 looks good, except it should use
the default runlevel instead of looking into rc5.d. It's getting complex, better
to put it in a separate file. And maybe push it upstream, I'm pretty sure they
would be interested.

we need a this as a seperate script too.(not only a %post script)
what if somebody chnaged the strating services? they should be able to start a
update-initng-runlevel script that apply this changes to initng too.

(In reply to comment #53)
> > >   | *** buffer overflow detected ***: ngc terminated
> > ...
> > Que? This is really strange! Is it reproducable?
> It is caused by an strcat() at ngc2.c:553 and/or 556:

Ok, I feel that this is outside my knowledge. Can you please post a bug in 
initng bugzilla?

(In reply to comment #59)
> > I would move its functionality into a separate script which gets shipped 
with 
> > 'initng' and executed by %post
> +1. We need such a script anyway. comment 52 looks good, except it should use
> the default runlevel instead of looking into rc5.d. It's getting complex, 
better
> to put it in a separate file. And maybe push it upstream, I'm pretty sure they
> would be interested.

In my opinion this functionality should be built into the gen_system_runlevel 
script that is run install-time by initng installation. I've posted an upstream 
bug about this. In the meantime it sounds good having it as a separate script. 
Stupid question from rpm newbie: Where do i put the script and how do I call it 
from spec file?

(In reply to comment #61)
> (In reply to comment #53)
> > > >   | *** buffer overflow detected ***: ngc terminated
> > > ...
> > > Que? This is really strange! Is it reproducable?
> > It is caused by an strcat() at ngc2.c:553 and/or 556:
> Ok, I feel that this is outside my knowledge. Can you please post a bug in 
> initng bugzilla?

Ok. Please ignore this comment. I've now fixed this in upstreams bugzilla. I've 
also fixed the system/issue issue.

(In reply to comment #62)
> Stupid question from rpm newbie: Where do i put the script and how do I call it 
> from spec file?
 
- Write the script as a separate file, called update-initng-runlevel.sh for example,
- Put this file in your SOURCES dir,
- Add a "Source1: update-initng-runlevel.sh" line in the spec file,
- In the %install section, add a line like:
install -p -m 755 %{SOURCE1} %{buildroot}/sbin/update-initng-runlevel
And add it in you files list (which, by the way, could use "/sbin/*", but
listing files individually has advantages: it lets you know when something
didn't build)
- In the %postun section, call :
/sbin/update-initng-runlevel >/dev/null 2>&1 || :
to make sure there's no output, and that it exits 0.
- That's it.

Created attachment 121537 [details]
initng 0.4.4-7 srpm

New spec. I've uploaded entire srpm this time to get scripts and paths too.
Changes:

* Mon Nov 28 2005 Daniel Malmgren <daner964.se> 0.4.4-7
- Split out the default services script from spec file
- Remove glibc and bash dependencies
- Remove mkinitrd dependencies, check if grubby exists in %post instead

I hope I've covered what's mentioned above now (except for the things that I've
fixed in initng svn). It would be nice if Bugzilla could show some kind of
treeview, it's really hard to handle all the messages in a plain view.

Well. Anyway. On the TODO right now:

* Fix the update-initng-runlevel script. It's a start, but it's not good.
* Fix a README.Fedora file, explaining the script and the grubby stuff
* Wait for 0.4.5 which will hopefully fix loads of stuff

Did I forget anything big here?

Gauret: Should I apply for sponsorship for cvsextras?

Created attachment 121544 [details]
new version of script

Fixed the update-initng-runlevel script up so that it doesn't just look in
rc5.d, but first checks in inittab which runlevel is default.

I'd also like to notice that rpmlint errors are now close to zero (and I guess
the one's that's left is nothing to care about):

[~]$ rpmlint rpmbuild/RPMS/i386/initng-0.4.4-7.i386.rpm
W: initng devel-file-in-non-devel-package /lib/libinitng.so
W: initng dangerous-command-in-%post cp

Created attachment 121548 [details]
Modified version of initng's gen_system_runlevel

I noticed that we're doing double work, since there's a script in initng for
generating runlevels. I modified the script a bit to fit our needs, so we won't
have to ship our own script anymore. We'll just have to remove the
system.runlevel and default.runlevel from the package and execute
gen_system_runlevel in %post and everything will be very nice. It will even
obsolete the patch we're shipping now. What do you think?

> Gauret: Should I apply for sponsorship for cvsextras?

Yes, go ahead, I'll sponsor you.

> I'd also like to notice that rpmlint errors are now close to zero (and I guess
> the one's that's left is nothing to care about):

Yes, you can ignore those.

> I noticed that we're doing double work, since there's a script in initng for
> generating runlevels. [...] What do you think?

The closer we are to upstream, the better. If we can improve upstream's script
instead of creating our own, that's definately the way to go.

sorry for this (maybe stupid) question but what about gdm/kdm shutdown/reboot? 
they do call reboot/poweroff or shutdown but not ngc ? or does initng ships whit
a wrapper that solves this issue? If not we need some kind of wrapper ...

wanted to try it using:
http://gauret.free.fr/fichiers/rpms/fedora/initng-0.4.4-5.src.rpm
but it failed even to boot:
ining will continue when fork() exits (executing /sbin/sulogin)
and then it asks for a root password or controll-d to continue...
controll-d lets it asks for a password again and the password only brings me to
a shell root@none

Thanks for all of the great work on this package guys!

Out of curiosity, has anyone ported our current init scripts to .i format yet ?

I figure, if initng is going to get pushed for Core, then we are going to need
our exact init script functionality in order to do a real comparison against
SysVinit.

at comment #71

it would be possible to do this porting but you will loss lot of performance.
E.g. in initng you can write

| daemon = /usr/sbin/ntpd
| daemon_args = -i /var/lib/ntp/chroot -u ntp:ntp -n

or

| daemon {
|   ... parsing /etc/sysconfig/ntpd ...
|   exec /usr/sbin/ntpd $parsed_params
| }


First variant would be the fast initng way while the second one is the bloaty
SysVinit/initscript way spawning a separate bash for each daemon.

initng supports 'env_file' which could be used to pass parameters but afais, it
can NOT be used like

| env_file = /etc/sysconfig/ntpd
| daemon_args = -n $OPTIONS


To get real comparison, the first way should be used but not the second one.

(In reply to comment #69)
> sorry for this (maybe stupid) question but what about gdm/kdm shutdown/reboot? 
> they do call reboot/poweroff or shutdown but not ngc ? or does initng ships whit
> a wrapper that solves this issue? If not we need some kind of wrapper ...

Initng ships with /dev/initctl emulation, so all applications trying to
halt/reboot the SysVinit way will work just fine. Apparently this even works
better than the initng way (ngc -j reboot) right now...

(In reply to comment #68)
> > Gauret: Should I apply for sponsorship for cvsextras?
> 
> Yes, go ahead, I'll sponsor you.

Done.

> > I noticed that we're doing double work, since there's a script in initng for
> > generating runlevels. [...] What do you think?
> 
> The closer we are to upstream, the better. If we can improve upstream's script
> instead of creating our own, that's definately the way to go.

Yep. Absolutely. My new gen_system_runlevel and all Gaurets new scripts is in
initng 0.4.6, so as soon as I'm finished remaking spec file we'll have all our
changes in upstreams!

Created attachment 121573 [details]
initng 0.4.6-1 spec file

Ok. Here's the first try of a spec file for initng 0.4.6. Hopefully this will
solve most of our problems. I've scrapped both the patch and the script, all
that functionality is now upstreams in gen_system_runlevel.

Created attachment 121574 [details]
initng 0.4.6-2 spec file

Some really tiny changes that makes this spec file look better.

I just thought of another thing: With these last changes (the runlevel files
being generated on the machine where the rpm is being installed) we don't own
the runlevel files anymore, so they're not removed when removing the rpm. Is
this a problem? Also it struck me that we never roll back the changes we do to
grub.conf. Should we do that? Seems somewhat dangerous to me...

Gauret: Is there any good reason why mDNSResponder needs nifd? Nifd doesn't seem
to be installed by default, so on my testing machine mDNSResponder refused to
start. Could I change the "need" to an "use"?

(In reply to comment #77)
> Gauret: Is there any good reason why mDNSResponder needs nifd? Nifd doesn't seem
> to be installed by default, so on my testing machine mDNSResponder refused to
> start. Could I change the "need" to an "use"?

Hmmm... It seems the machine didn't have neither nifd nor mDNSResponder
installed. I guess they should be, it might be a bug in FC5t1? Whatever...

Also, since I forgot to put Gauret's new shiny scripts in the makefile, they are
included in the tarball but never built. Please forgive me. It's fixed in cvs
now :-/

(In reply to comment #78)
> Also, since I forgot to put Gauret's new shiny scripts in the makefile, they are
> included in the tarball but never built. Please forgive me. It's fixed in cvs
> now :-/

...which only seems to have effected the audit service, since someone else
remade the Makefile in the daemons directory just before release. I hope you all
can live without audit for the time being. Or should I make a little patch?

If daemon/acpid is added to the default runlevel it doesn't create its socket
(/var/run/acpid.socket) during boot time for some reason.

If ran after boot time, the socket is properly created

(In reply to comment #80)
> If daemon/acpid is added to the default runlevel it doesn't create its socket
> (/var/run/acpid.socket) during boot time for some reason.
> 
> If ran after boot time, the socket is properly created

Ok, I guess this means it depends on some other service that should be added to
the "need=" section. Someone has any good guess what that might be?

When booting with initng-0.4.6 the boot process freezes when it tries to bring
up daemon/xfs. Even Ctrl+C won't work. I can log in on the second virtual
terminal though so it's really just the initng process that gets "stuck".

Created attachment 121678 [details]
initng 0.4.7-1 spec file

New upstream version.

It seems plague doesn't like the firewall at my work, so initng isn't gonna hit
Fedora extras until this weekend when I'll hopefully get some time with my
computer at home. JFYK...

I think I'm going nuts here. I've been tampering around with system/initial 
service half the day without solving the strange font issues. Someone that has 
any good knowledge of console fonts that can help me?

In /etc/rc.d/rc.sysinit all that happens related to fonts is 
that /sbin/setsysfont is run and then the banner is printed out in nice colors 
without problems.

When running /sbin/setsysfont in system/initial it just seems to screw things 
up. That things that were on the screen before the setsysfont call is garbage 
is one thing. We can solve that by not printing out the banner until after the 
call. But it still can't seem to get my nice swedish å, ä änd ö's right until 
after someone logs onto the computer and /etc/profile.d/lang.sh (with a call to 
unicode_start in it) is run. Anyone knows what I'm doing wrong?

cant get it to work on x86_64 rawhide. halts when initng should be executed.
rebuild on x86_64 with latest spec.

I have the same problem as I wrote in comment #60 but forgot to mention that I
am using x86_64

x86_64 problems are probably caused by

| open("/lib/initng", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOENT (No such file or directory)

(see comment #50)

ok did ln -s /lib64/initng /lib/initng and got it to boot.
it bootet very fast(!!).
but its still buggy...
first: after booting usb wasn't working had to do
modprobe usb-controller1
and
modprobe usb-controller to get it working
and shutdown seems to be broken....
it segfaulted  (had to press reset)

it segfaulted for me on x86_64 rawhide at startup already. but symlinking made
it start up at all.

to summarize up the x86_64 problems/warnings while building: Those warnings
could  be a cause for the segfaults.

	

+ /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
*******************************************************************************
*
* WARNING: 'check-rpaths' detected a broken RPATH and will cause 'rpmbuild'
*          to fail. To ignore these errors, you can set the '$QA_RPATHS'
*          environment variable which is a bitmask allowing the values
*          below. The current value of QA_RPATHS is 0x0000.
*
*    0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor
*               issue but are introducing redundant searchpaths without
*               providing a benefit. They can also cause errors in multilib
*               environments.
*    0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute
*               nor relative filenames and can therefore be a SECURITY risk
*    0x0004 ... insecure RPATHs; these are relative RPATHs which are a
*               SECURITY risk
*    0x0008 ... the special '$ORIGIN' RPATHs are appearing after other
*               RPATHs; this is just a minor issue but usually unwanted
*    0x0010 ... the RPATH is empty; there is no reason for such RPATHs
*               and they cause unneeded work while loading libraries
*    0x0020 ... an RPATH references '..' of an absolute path; this will break
*               the functionality when the path before '..' is a symlink
*
*
* Examples:
* - to ignore standard and empty RPATHs, execute 'rpmbuild' like
*   $ QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild my-package.src.rpm
* - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like
*   $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths
*
* 'check-rpaths' is part of 'fedora-rpmdevtools'.
*
*******************************************************************************
ERROR   0001: file '/sbin/initng' contains a standard rpath '/lib64' in
[/lib64]ERROR   0001: file '/lib64/initng/libngc2.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libnetprobe.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libchdir.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libsimplelauncher.so' contains a standard
rpath '/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libfind.so' contains a standard rpath '/lib64'
in [/lib64]
ERROR   0001: file '/lib64/initng/librenice.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libcron.so' contains a standard rpath '/lib64'
in [/lib64]
ERROR   0001: file '/lib64/initng/libidleprobe.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libchroot.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libcritical.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libsyslog.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libstcmd.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libsyncron.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libpause.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libcpout.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libhistory.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libpidfile.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libiparser.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libstdout.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libdepend.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libsuid.so' contains a standard rpath '/lib64'
in [/lib64]
ERROR   0001: file '/lib64/initng/libunneeded.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libinitctl.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libreload.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libfstat.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/liblast.so' contains a standard rpath '/lib64'
in [/lib64]
ERROR   0001: file '/lib64/initng/libbashlaunch.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/librlparser.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/liblimit.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libenvparser.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/librespawn.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libdparser.so' contains a standard rpath
'/lib64' in [/lib64]
ERROR   0001: file '/lib64/initng/libalso.so' contains a standard rpath '/lib64'
in [/lib64]
ERROR   0001: file '/lib64/initng/libinteractive.so' contains a standard rpath
'/lib64' in [/lib64]
 
gcc -DHAVE_CONFIG_H -I. -I. -I../..     -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4
-m64 -mtune=nocona -c ngc2.c
ngc2.c: In function 'send_command':
ngc2.c:191: warning: ignoring return value of 'read', declared with attribute
warn_unused_result
ngc2.c: In function 'ngc_start_result':
ngc2.c:287: warning: ignoring return value of 'read', declared with attribute
warn_unused_result
ngc2.c: In function 'ngc_stop_result':
ngc2.c:341: warning: ignoring return value of 'read', declared with attribute
warn_unused_result
ngc2.c:370: warning: ignoring return value of 'read', declared with attribute
warn_unused_result
 
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=nocona
-Wp,-MD,.deps/initng_ngc2.pp -c initng_ngc2.c  -fPIC -DPIC -o .libs/initng_ngc2.o
initng_ngc2.c: In function 'doread':
initng_ngc2.c:182: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:201: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:214: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:225: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:246: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:264: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:285: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:299: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:311: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:321: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c: In function 'cmd_help':
initng_ngc2.c:629: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c: In function 'cmd_start':
initng_ngc2.c:645: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:656: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:674: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c: In function 'cmd_stop':
initng_ngc2.c:689: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:700: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:720: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c: In function 'cmd_options':
initng_ngc2.c:751: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:774: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c: In function 'cmd_services':
initng_ngc2.c:811: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
initng_ngc2.c:831: warning: ignoring return value of 'fwrite', declared with
attribute warn_unused_result
 
gcc -DHAVE_CONFIG_H -I. -I. -I..     -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=nocona -c
install_service.c install_service.c: In function 'load_overlay_file':
install_service.c:124: warning: ignoring return value of 'fgets', declared with
attribute warn_unused_result install_service.c: In function 'do_exec':
install_service.c:609: warning: ignoring return value of 'pipe', declared with
attribute warn_unused_result install_service.c:610: warning: ignoring return
value of 'pipe', declared with attribute warn_unused_result
install_service.c:643: warning: ignoring return value of 'write', declared with
attribute warn_unused_result install_service.c:644: warning: ignoring return
value of 'write', declared with attribute warn_unused_result

I submitted some patches upstream

http://bugzilla.initng.thinktux.net/show_bug.cgi?id=310
http://bugzilla.initng.thinktux.net/show_bug.cgi?id=311
http://bugzilla.initng.thinktux.net/show_bug.cgi?id=312
http://bugzilla.initng.thinktux.net/show_bug.cgi?id=313


which might fix some segfaults.

Created attachment 121812 [details]
initng-x86_64-buildlog 0.4.7 with the 4 patches

still segfaults btw.

was trying to fix the usb problem but don't now where it come form:
did:
 for i in `cat /etc/sysconfig/hwconf |grep "driver: .*-hcd"|cut -d" " -f2`;do
        echo $i;
  done
and it prints:
ohci-hcd
ohci-hcd
ehci-hcd
this is what is done inside usb.ii (modprobe instead of echo) and then it mounts
the usbfs and call udevstart... 
so it should work. the only thing that I can think of is that the script does
not start at all...
but how do Im check which scripts have been executed? is there any log for that
or do I have to hack the scripts to get such a log?

Created attachment 121814 [details]
fix case where the default kernel is not a linux kernel

When the default kernel in grub is not a linux kernel (ex: windows) it fails in
%post with: grubby kernel not found.
Here is a patch that fixes this by using the current running kernel if there is
no one found by grubby --default-kernel

Now all the latest patches (from comments #91 and #95) are in. Thanks a lot for
your help! I tried making a hard Fedora extras build (using 0.4.7), but Plague
just tells me that "Job failed on arch x86_64". Since I don't have access to any
x86_64 machine I have no way of doing any testing on this. The build process
apparently chokes up on:

Error: Missing Dependency: libdevmapper.so.1.01()(64bit) is needed by package
device-mapper
Error: Missing Dependency: libdevmapper.so.1.01(Base)(64bit) is needed by
package device-mapper

...which doesn't make any sense to me whatsoever. Can someone please explain to
me what's going wrong?

Oh. There is now also an initng component in Fedora bugzilla. Maybe some of the
type of stuff that has been mentioned above could be filed as bugs there instead
from now on?

And of course, the types of bugs that has nothing with the rpm but with
upstreams code to do would be even nicer to have in upstreams bugzilla...

(In reply to comment #94)
> but how do Im check which scripts have been executed? is there any log for that
> or do I have to hack the scripts to get such a log?

Take a look at ngc.

"ngc -h" will give you a nice list of commands, "ngc -s" gives an even nicer
list of which daemons/services has been started and "ngc -L" gives a huge log
with loads of crap that I don't understand anything of ;-)

(In reply to comment #96)
> Error: Missing Dependency: libdevmapper.so.1.01()(64bit) is needed by package
> device-mapper
> Error: Missing Dependency: libdevmapper.so.1.01(Base)(64bit) is needed by
> package device-mapper

It seems this wasn't my fault after all
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174946). I guess I'll have
to try again when I get the time.

Daniel, I see you have imported this package into CVS despite the facts this
package has NOT yet been APPROVED nor is it being reviewed.

I don't know how FESCO wants to proceed with this, but IMO, you have violated
the rules.

(In reply to comment #100)
> Daniel, I see you have imported this package into CVS despite the facts this
> package has NOT yet been APPROVED nor is it being reviewed.
> I don't know how FESCO wants to proceed with this, but IMO, you have violated
> the rules.

Doh! I thought that Gauret approving me for cvsextras meant that the package 
was approved. How do I know when it is approved?

Since I don't know anything about these things I'm just following the 
directives at http://fedoraproject.org/wiki/Extras/Contributors and step 7 
says that "When the package is approved by the reviewer, that person will then 
sponsor you". If I'm doing anything wrong here, can someone please fix the 
text in the wiki?

Yes, it looks like it's partly my mistake here, I sponsored you before the
package was actually approved (I think I've seen it done before, but anyway).
I've checked that the tarball is identical to upstream's, so no security risk
involved. Just don't request build before this package is actually approved
(which means I explicitely say I approve the package, see bug 172400 for example)

actually from tracking upstream cvs it seems that alot things are beeing fixed 
in the next release. some of the x86_64 warnings have been tackled already. i 
hope it will cure the x86_64 segfault probs.

(In reply to comment #102)
> Yes, it looks like it's partly my mistake here, I sponsored you before the
> package was actually approved (I think I've seen it done before, but anyway).
> I've checked that the tarball is identical to upstream's, so no security risk
> involved. Just don't request build before this package is actually approved

I already tried building yesterday. The build failed though (see comment #96 
above), so there is no initng out in the open.

> (which means I explicitely say I approve the package, see bug 172400 for 
example)

Ok. Thanks for the explanation ;-)

(In reply to comment #103)
> actually from tracking upstream cvs it seems that alot things are beeing 
fixed 
> in the next release. some of the x86_64 warnings have been tackled already. i 
> hope it will cure the x86_64 segfault probs.

Yes, Enrico has done a really great work trying to solve x86_64 stuff. Thanks a 
lot Enrico!

Pushing package back to FE-NEW, because it isn't assigned to formal reviewer.

(In reply to comment #105)
> (In reply to comment #103)
> > actually from tracking upstream cvs it seems that alot things are beeing 
> fixed 
> > in the next release. some of the x86_64 warnings have been tackled already. 
i 
> > hope it will cure the x86_64 segfault probs.
> Yes, Enrico has done a really great work trying to solve x86_64 stuff. Thanks 
a 
> lot Enrico!

i am curious if the latest state will start up just fine but i cant try again 
before weekend cause i am not at home at my x86_64 box. ;( I hope people keep 
an eye on it before releasing the package to the wild ;)

can somebody point me to the most recent srpm or spec file (+tarball) so that I
can test it again (on x86_64)

ok I found it... 
I tryed with the lastest svn build an got this problems:
* it adds deamon/sshd to my default.runlevel file (sshd is disabled)
* it comlains about deamon/httpd does not exists this is likly because httpd.i
looks like that:
-----
daemon daemon/apache {
	need = system/initial system/mountfs net/lo;
	use = daemon/sshd daemon/mysql daemon/postgres system/netmount;
	require_network;
	script daemon = { 
	    /usr/sbin/httpd;
	    /bin/sleep 1
	}
	pid_file = /var/run/httpd.pid;
}
--
but it should be
--
daemon daemon/httpd {
	need = system/initial system/mountfs net/lo;
	use = daemon/sshd daemon/mysql daemon/postgres system/netmount;
	require_network;
	script daemon = { 
	    /usr/sbin/httpd;
	    /bin/sleep 1
	}
	pid_file = /var/run/httpd.pid;
}
---
* it hangs after mounting sys (don't now if its related to this warings or not)
I will try again with the corrected file (httpd.i) and see if it boots if yes I
will submit a patch upstream if not I will fil a bug.
what should I do about the sshd thing?
If I decide not to start a service why does gen_system_runlevel pics it up?

the cause for the usb problem I mentioned in comment #94 was that system/usb was
not in system.runlevel
after adding it in system.runlevel usb worked fine (with the 0.4.7 build)
will now try svn again.

ok the change I made fixed the apache problem ....
but it still hangs on or after mounting sysfs
mounting sysfs as /sys (and nothing happens)
no disk ativity but numlock still works

(In reply to comment #109)
> what should I do about the sshd thing?
> If I decide not to start a service why does gen_system_runlevel pics it up?

Mainly because gen_system_runlevel is a bug cludge. I've now fixed this
particular bug in svn.

(In reply to comment #110)
> the cause for the usb problem I mentioned in comment #94 was that system/usb
> was not in system.runlevel

This is also fixed in svn, gen_system_runlevel now puts system/usb in
system.runlevel per default.

What's the status for building on x86_64 right now? Is there any more patches
that needs to go into upstreams svn to get it work? It would be nice if next
upstreams release really would work on 64 bits machines...

Another question from an Extras newbie: When does the review start? Since I
thought what we were doing right here was the review I'm a bit confused right
now. Do we wait for next upstreams release before reviewing?

(In reply to comment #111)
> ok the change I made fixed the apache problem ....
> but it still hangs on or after mounting sysfs
> mounting sysfs as /sys (and nothing happens)
> no disk ativity but numlock still works

It's hard to tell what might be the error here. Could you insert some echo's
into strategic places in /etc/initng/system/initial.i to see exactly where the
boot stops?

What is the status of 

http://bugzilla.initng.thinktux.net/show_bug.cgi?id=313

? There is an 'In SVN.' message but it does not seem to be applied. (I can
commit it also but not before this afternoon (CET))

(In reply to comment #114)
> (In reply to comment #111)
> > ok the change I made fixed the apache problem ....
> > but it still hangs on or after mounting sysfs
> > mounting sysfs as /sys (and nothing happens)
> > no disk ativity but numlock still works
> 
> It's hard to tell what might be the error here. Could you insert some echo's
> into strategic places in /etc/initng/system/initial.i to see exactly where the
> boot stops?

ok I updated the snapshot to 2357 and now it hangs after /dev nor after /sys
changed initial.i to look like this:
-----------
# Ok, go create /dev
echo "Mounting ramfs at /dev ..."
/bin/mkdir -p /dev && mount -n -o size=10M,mode=0755 -t tmpfs tmpfs /dev
echo "/dev mounted"
/bin/mknod /dev/null c 1 3 -m 666
echo "/dev/null created"

# Launch udevd daemon
/sbin/udevd --daemon
echo "started udevd"
----------
the messages "started udevd" never gets printed...
so it seems to hang on /sbin/udevd --daemon
(but I don't know why)

(In reply to comment #116)
> the messages "started udevd" never gets printed...
> so it seems to hang on /sbin/udevd --daemon
> (but I don't know why)

Since I've got no idea what happens here I've posted an upstreams bug.

http://bugzilla.initng.thinktux.net/show_bug.cgi?id=326

svn of today still segfaulting for me on x86_64 rawhide. if someone has the 
hardware and enough time it would be sweet to build up a custom kernel and 
attach gdb to initng. maybe i can find the time next week to provide the proper 
upstream debug info.

does it segfault on boot or shutdown?

Created attachment 122264 [details]
initng 0.4.8-1 spec

Ok, now 0.4.8 is out. All bugs that I experienced in 0.4.7 seems to be fixed
(except for the console font strangeness). I guess the big problems will still
be x86_64...

Created attachment 122265 [details]
initng 0.4.8-2 spec

Oops, almost forgot.

Pass '--localstatedir=/var' to configure according to directions in initng
bugzilla #319

The 

| ERROR   0001: file '/sbin/initng' contains a standard rpath '/lib64' in [/lib64]

errors on x86_64 are caused by an old autoconf version (it seems, an ancient 1.4
was used).

Regenerating buildscripts with 'autoreconf -i -f' removes the rpath errors. But
it should be fixed upstream, not in the package.

(In reply to comment #122)
> errors on x86_64 are caused by an old autoconf version (it seems, an ancient 1.4
> was used).

Are you really sure about this? Autoconf 1.4 has gotta be more than five years
old. Or do you mean automake? (I'll notice this bug to the team, just gotta have
the details clear first)

So, is there any other news on this review? Is anything going to happen this
year? What do we wait for? Gauret?

aclocal.m4 (which brings in the rpath bits) starts with

| dnl aclocal.m4 generated automatically by aclocal 1.4-p6

(In reply to comment #124)
> aclocal.m4 (which brings in the rpath bits) starts with
> | dnl aclocal.m4 generated automatically by aclocal 1.4-p6

So we're talking automake. I've filed a initng bug, 
http://bugzilla.initng.thinktux.net/show_bug.cgi?id=360 about it.

oops, you are right

Another issue which makes current package nearly unusable on Fedora:

you should call '/sbin/udevstart' but not '/sbin/start_udev' in system/initial.i.

Latter program will kill the previously started 'udevd' which stops most
services to work.

And yet another issue:

initng segfaults on x86_64 when a service fails to start. Unfortunately, I do
not have arbitrary access to the x86_64 box and can not track it down (nor can I
provide further details).

(In reply to comment #126)
> oops, you are right

I know ;-)

> Another issue which makes current package nearly unusable on Fedora:
> you should call '/sbin/udevstart' but not '/sbin/start_udev' in 
system/initial.i.
> Latter program will kill the previously started 'udevd' which stops most
> services to work.

Oh, you're right! I haven't noticed this since apparently udev can't be stopped 
while filldev is running, so initng simply ignores udevd dying. I guess this 
means that all the stuff start_udev does is now built into initng's own 
scripts? If I understand things correctly start_udev is Fedora specific, so I 
guess I can simply remove it from initial.ii and this problem will be solved...

>initng segfaults on x86_64 when a service fails to start.

I wish I would have a 64 bit machine to try this out. I hope anybody can trace 
it...

i can help with x86_64... i am running x96_64 rawhide.

according to upstream the x86_64 segfaults are fixed in svn. not in 0.4.8 yet.

I can test it again (on x86_64)...
should I use svn or 0.4.8 ?

ok tested it (svn)
boots fine (still not correct services are added but did this manually ex: samba)
sometimes hald does not run or gets stopped
9:45:53   system/firestarter : STARTING
 19:45:53         daemon/named : STARTING
 19:45:53         daemon/named : RUNNING
 19:45:53         daemon/mysql : STARTING
 19:45:53         daemon/mysql : RUNNING
 19:45:53    daemon/samba/smbd : STARTING
 19:45:53    daemon/samba/smbd : RUNNING
 19:45:53    daemon/samba/nmbd : STARTING
 19:45:53    daemon/samba/nmbd : RUNNING
 19:45:53         daemon/httpd : STARTING
 19:45:53         daemon/samba : DONE
 19:45:55         daemon/mysql : *OUTPUT*
Starting mysqld daemon with databases from /var/lib/mysql
 19:45:58          daemon/hald : STOPPED
 19:45:59   system/firestarter : *OUTPUT*
without any reason (I tryed to add daemon/hald to gdm but it did'nt help)
this causes that mountpoints are displayed on the desktop instead of in computer://
shutdown:
still broken it freezes at %5 (hald) or %11 (modules) seems to be a random
freeze at the end.
currently I don't now what exactly happens (no segfault or similar error message
just freeze)

I found an other bug:
when I boot with initng and after reboot boot with sysvinit (normal boot)
I get a message that It could not open /etc/fstab permission denied (relabel was
needed) 
seems that initng changes some file labes during boot (or shutdown).

here is the avc error:
audit(1135277882.299:2): avc:  denied  { read } for  pid=1610 comm="fsck"
name="fstab" dev=sda5 ino=1705884 scontext=system_u:system_r:fsadm_t
tcontext=system_u:object_r:unlabeled_t tclass=file

0.5.0 released ;)

0.5.0 works on x86 64 for me without segfaulting. yay.

0.5.0 with nvidia binary drivers 8178 (tested on x86_64 rawhide) workaround:

add the following to /etc/udev/links.conf:

M nvidia0 c 195 0
M nvidia1 c 195 1
M nvidiactl c 195 255

instead of the net script it would maybe make sense to startup
/etc/init.d/network somehow. any better idea for approaching that? (per default
the gen runlevel script didnt pick up my pppoe device in the auto start list).

remaining issues:

 08:16:28 system/swap                            : FAIL_STARTING              1101s.
i guess i have to provide more input there.

08:17:28 system/firestarter                     : FAIL_STARTING              1365s.
service firestarter restart works fine ;)

08:17:30 daemon/postfix                         : WAIT_FOR_PID_FILE          1687s.
still waiting for pid. whereas:
service postfix status tells me:
master (PID 4531) wird ausgeführt... (service is running)

 08:16:27 daemon/nvidia-glx                      : FAIL_STARTING              1750s.
this one fails either but then again... it didnt work for me at all. i used
themethod from comment #136

reduced the problems to:

08:17:30 daemon/postfix                         : WAIT_FOR_PID_FILE          1687s.
still waiting for pid. whereas:
service postfix status tells me:
master (PID 4531) wird ausgeführt... (service is running)

 08:16:27 daemon/nvidia-glx                      : FAIL_STARTING              1750s.
this one fails either but then again... it didnt work for me at all. i used
themethod from comment #136

what about the selinux issue?
0.4.8-svn does not seem to initalize it at all (all files become unlabled)

fwiw, two patches to make 'atd' and 'smartd' work better with initng:

* bug #176530 (smartmontools) and bug #176486 (at)

When applied, the pidfile hack can be removed. Chances are bad (nearly zero for
at) that upstream applies them but they are perhaps for interest for other
initng distributions.

Created attachment 122592 [details]
initng 0.5.0 spec

there is a typ in this file:
Source0: http://initng.thinktux.net/download/v0.4/initng-%{version}.tar.gz
should be:
Source0: http://initng.thinktux.net/download/v0.5/initng-%{version}.tar.gz

(In reply to comment #140)
> what about the selinux issue?
> 0.4.8-svn does not seem to initalize it at all (all files become unlabled)

the selinux problem is beeing worked on upstream see:
http://bugzilla.initng.thinktux.net/show_bug.cgi?id=365
if anyone want to help then fell free to do it...

Created attachment 122594 [details]
initng 0.5.0-2 spec

(In reply to comment #143)
> there is a typ in this file:

Just checking if you're awake now that christmas weekend is over ;-)

(In reply to comment #137)
> instead of the net script it would maybe make sense to startup
> /etc/init.d/network somehow. any better idea for approaching that? (per default
> the gen runlevel script didnt pick up my pppoe device in the auto start list).

I've added some code to gen_system_runlevel (in svn) that checks in
/etc/sysconfig/network-scripts which interfaces that ought to be in default
runlevel. Hopefully this will pick up your pppoe. Please check it out!

Created attachment 122745 [details]
BootChart

System Specas 
1.5 Ghzz pentuim M 
768 MB ram 
30 GB 5400 rpm drive 
NetworkManager manages my Intel ipw2200 wireless device 
This chart is after initng and turning off some processes

Created attachment 122746 [details]
Botchart after a fresh install

initng 0.5 doesn't output anything at all but seems to boot but at the end of
the booting process it just gets stuck. Switching to the second virtual console
allows me to log in and most of the daemons are running but shutting down the
machine again provides no output at all and then gets stuck too requiring to
push the power button to restart the machine.

Ok. Now it's been a month since the incident where I thought the package was
reviewed but it wasn't. It seems that Aurelien left the ship and I get no
answers about what happens to the review.

Should I assume that Fedora has dropped this project completely? And if not,
what more needs to be done? If the problem is that I did wrong, should someone
else take over this rpm instead?

there are still bugs remaining that break existing setups [1] ...
we need to get them fixed first
1: like the selinux one
x86_64 shutdown? (for me it hangs) see comment #131

Ps its worth mentioning that even for a small and not so exciting package the
first package review takes some time.. There is a limited list of people who can
do the initial sponsorship, and its unfortunatly 'normal' that this takes quite
a bit of time.

With more complex packages like this one, the process can go even slower. Its
not only a simple package review but also involves judgement of when its ready
for 'prime time' in fedora extra's, Which is a decission which can be sped up by
making sure the issues reported here are looked at and preferably solved to
ensure when its in extra's it will work correctly, and to be responsive in this
bug report (which by all apearances you are!)

I'm afraid i'm not on the list of initial sponsors so i can only make some
general comments, but i'll happily will test and try the initng package again to
atleast leave some feedback on its functioning!

Don't get discouraged, a new boot manager is a big deal and will take some time
but i'm sure its definatly not ignored!

(In reply to comment #151)
> there are still bugs remaining that break existing setups [1] ...
> we need to get them fixed first
> 1: like the selinux one

Darn. I thought we fixed that one with the work in initng bz 365. What is it
that doesn't work now?

> x86_64 shutdown? (for me it hangs) see comment #131

Hmmmm... I guess we need more information on this one as well. It seems to me
hald is the problem. Does starting/stopping hald manually (using ngc) work?

(In reply to comment #152)
> ...not so exciting package...

But it is!

> Don't get discouraged, a new boot manager is a big deal and will take some time
> but i'm sure its definatly not ignored!

Thanks. I guess it's just me being impatient. I've been working on this package
for about half a year now, and I still haven't got a clear picture of what needs
to be done before it's really good...

(In reply to comment #154)
> > ...not so exciting package...
> But it is!

I meant to say that even for a non-exciting package it takes a lot of time, so
for an exciting package like this one its normal it takes even a little more
time before someone will stamp it 'Ok ready for prime time now!'; I didn't mean
to insinuate it was not exciting at all :-)

(In reply to comment #153)
> (In reply to comment #151)
> > there are still bugs remaining that break existing setups [1] ...
> > we need to get them fixed first
> > 1: like the selinux one
> 
> Darn. I thought we fixed that one with the work in initng bz 365. What is it
> that doesn't work now?
> 
> > x86_64 shutdown? (for me it hangs) see comment #131
> 
> Hmmmm... I guess we need more information on this one as well. It seems to me
> hald is the problem. Does starting/stopping hald manually (using ngc) work?

we need a patch that loads the policy ...
or is it already included?

Don't be hasty, master Daniel.
I did not leave the ship, I just had other things to do first. You're already
sponsored, so we now "just" have to make sure initng can be a full init
replacement for Fedora. That takes time, SELinux and x86_64 must work before
this package is approved.
This bug is not even 2 months old, it's pretty young for such a package. A
"heads up" post can be useful sometimes, but don't think everybody lost interest
in initng because they were busy playing with their new Christmas toys :)

comment #146:

yes the pppoe detection works properly now on x86_64 rawhide (and i guess
anywhere else)

since 0.5.1 is coming pretty soon and somehow svn doesent work cause i cant
mount rootfs (guess another lvm issue)

other than that i think aswell there is good progress beeing made.

I just tried to boot with a current svn checkout but the system still doesn't
output anything after "Switching to new root and running init" and a few line of
"unmounting old XYZ".

I'm always doing a complete reinstall ("rpm -e" followed by "rm -rf /etc/initng"
and removal of the initng lines in grub.conf) but while I was able to boot the
system with older versions of initng (plus some tweaks) things have gotten worse
for me with every release.

Created attachment 122905 [details]
initial selinux policy patch

This patch loads the selinux policy inside initng.
We still need to make this a configure option.
Note: It has to be compiled with -lsepol -lselinux (chnages for that are not
included in this patch).
(patch also posted upstream).
http://bugzilla.initng.thinktux.net/show_bug.cgi?id=365

Created attachment 122906 [details]
patch for selinux support 

This patch tryes to reuse the init policy for initng.
it labes /sbin/initng as init_exec_t and everything in /etc/initng as
initrc_exec_t.
I did chcon in %post to do this.. but I don't know if this is the correct way
to label files inside a spec file.

Created attachment 122918 [details]
new (working) version of the selinux patch

this is a new version of my patch (the old one was broken).
I tested it and it builds (with some hacks to configure.in that needs to be
done better) and it also seems to work (booted with it and successfully loaded
the policy)

I tryed 0.5.1 on my x86_64 box. (with the selinux patch)
It loaded the policy successfully but it hangs after readahead (does not know if
this is related to selinux) or if it is a bug in 0.5.1.
Can somebody try 0.5.1 (with the patch) and see if it works for him?
Note: you will need libsepol-devel and libselinux-devel

(In reply to comment #163)
> I tryed 0.5.1 on my x86_64 box. (with the selinux patch)
me too without the selinux patch

> It loaded the policy successfully but it hangs after readahead (does not know if
> this is related to selinux) or if it is a bug in 0.5.1.
did you try 0.5.1 without the patch? do you use lvm? did it work?

> Can somebody try 0.5.1 (with the patch) and see if it works for him?
> Note: you will need libsepol-devel and libselinux-devel
well if the system would boot for me with x86_64 rawhide id try the patch right
now ;)

(In reply to comment #164)
> (In reply to comment #163)
> > I tryed 0.5.1 on my x86_64 box. (with the selinux patch)
> me too without the selinux patch
> 
> > It loaded the policy successfully but it hangs after readahead (does not know if
> > this is related to selinux) or if it is a bug in 0.5.1.
> did you try 0.5.1 without the patch? do you use lvm? did it work?
> 
not yet but will do it (no lvm here) does your system boot without the patch?
> > Can somebody try 0.5.1 (with the patch) and see if it works for him?
> > Note: you will need libsepol-devel and libselinux-devel
> well if the system would boot for me with x86_64 rawhide id try the patch right
> now ;)
> 
I am building the rpm on my rawhide (i386) box now.
will see if it is a x86_64 issues or not.

tryed i386 rawhide no.
It failed to boot because it was unable to read /proc booted with enforcing=0
and it booted. only this avc message has to be fixed to get selinux working:
audit(1136711719.772:2): avc:  denied  { read } for  pid=1 comm="initng"
name="stat" dev=proc ino=17367054 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:system_r:udev_t:s0-s0:c0.c255 tclass=file

it hangs on shutdown on my i386 box too,
same issue as comment #131

after commenting out the fsck part of mountroot.i i was able to boot on x86_64
rawhide (lvm). fsck there doesent even start... maybe devices missing too?

activating swap fails (/dev/VolGroup00/LogVol01 doesent get created)

udevd event complains for failed to execute: /lib/udev/floppysomething.sh when
initng is not started in --verbose mode (reproduced that various times).

shutdown also not complete on x86_64 rawhide.

(In reply to comment #157)
> but don't think everybody lost interest
> in initng because they were busy playing with their new Christmas toys :)

Oh. That's just plain unfair. I didn't get any fun new toys this christmas!

Hmmmm... Right now I feel that I agree with those that doesn't think it's stable
enough yet. Took me over two hours of hard work before my home computer booted
using 0.5.1 (upgrading it from 0.4.8). Guess I'll have to fill in quite a heap
of bug reports.

One thing maybe someone here can answer: system/usb chokes on the line " for i
in `/bin/grep "driver: .*-hcd"|cut -d" " -f2 /etc/sysconfig/hwconf`". Tried
executing the grep in a terminal manually, which gave me loads of non relevant
stuff and then just stopped. I'm no bash expert so I don't know what happens,
anyone else?

Created attachment 122926 [details]
0.5.1-1 spec

- New upstream version
- Include dragoran's selinux patch

(In reply to comment #167)
> it hangs on shutdown on my i386 box too,
> same issue as comment #131

I've noticed that if there are services/daemons doesn't start up correctly (i e
they're in the state FAILED_STARTING) shutting down doesn't work properly. Can
you try zapping (ngc -z) all services that doesn't start properly and then
reboot? It might at least work rebooting, and if it does we've got enough on our
feet to start grumping about it ;-)

(In reply to comment #169)

> One thing maybe someone here can answer: system/usb chokes on the line " for i
> in `/bin/grep "driver: .*-hcd"|cut -d" " -f2 /etc/sysconfig/hwconf`". Tried
> executing the grep in a terminal manually, which gave me loads of non relevant
> stuff and then just stopped. I'm no bash expert so I don't know what happens,
> anyone else?

Good catch, this may be the reason initng doesn't boot my system at all at the
moment. This got broken by the changes made in revision 2508 of initng. The line
has to look like this:

for i in `/bin/grep "driver: .*-hcd" /etc/sysconfig/hwconf|cut -d" " -f2`

(In reply to comment #172)
> The line has to look like this:
> 
> for i in `/bin/grep "driver: .*-hcd" /etc/sysconfig/hwconf|cut -d" " -f2`

Ok, this is now fixed in svn (commit 2764)

Can someone here take a look at
http://bugzilla.initng.thinktux.net/show_bug.cgi?id=393 and tell me if you
experience the same? This is a huge problem on one of the computers that I'm
testing initng on.

Created attachment 123192 [details]
initng 0.5.2-1 spec

Spec for new upstream version. First version for quite a while that worked for
me straight out of the box! There was some strangeness while building though,
seems like the "make" command ran configure again even though it already was
done. And apparently Jimmy (who rolls the tarballs) forgot to not use automake
1.4, so we're back to that. A real fix for that is on the way.

I've heard rumours about initng not working with lvm lately. Anyone using lvm
that can comment that?

Created attachment 123288 [details]
initng 0.5.2-2 spec

Run gen_system_runlevel even if the runlevels exist. The script is smart enough
to handle this itself. (see
http://bugzilla.initng.thinktux.net/show_bug.cgi?id=413 for details)

Created attachment 123573 [details]
initng 0.5.3-1 spec

0.5.3. Not much difference from what I can see. Seems we're at least back to
automake 1.9 again.

I tried initng 0.5.2 on FC4. On the whole it was a *very* positive experience.
Adding it to the Extras would be nice.

Minor issues I noticed. 

- english mistakes in messages;
- lack of documentation (I had too google to find the --interactive argument
to initng);
- some debatable coding (all state information is in a global called 'g'
(ungreppable));
- some bugs (e.g. sometimes stopping a daemon does not seem to work if it
dependent on a service in the same file); 
- booting hung while starting the daemon udev/udevd hung because udevd does not
recognize the --daemon argument (easily fixable);
- sometimes sound devices are not created, this is clearly a udevd issue;
- often console switches to cyrillic for a while (ugly);
- console flashes (ugly);
- kernel messages on consose (ugly but easily fixed by adding -c 1 to klogd);
- no integration yet with rhgb (easily fixable I presume).

In my opinion the following bugs aren't "minor" and should be fixed before this
can land in extras:

- some bugs (e.g. sometimes stopping a daemon does not seem to work if it
dependent on a service in the same file); 
- booting hung while starting the daemon udev/udevd hung because udevd does not
recognize the --daemon argument (easily fixable);
- sometimes sound devices are not created, this is clearly a udevd issue;
- often console switches to cyrillic for a while (ugly);

(In reply to comment #177)
> - english mistakes in messages;

Hmmm... Jimmy (the guy who makes most of the code) is heck of a programmer, but
I've seldom seen anyone that's worse in english ;-) Patches are welcome though.

> - lack of documentation (I had too google to find the --interactive argument
> to initng);

Yep. I don't think the project has anyone who's really responsible for
documentation, so it's kinda lagging...

> - some debatable coding (all state information is in a global called 'g'
> (ungreppable));

Hmmm... Might be worth filing a bug about...

> - some bugs (e.g. sometimes stopping a daemon does not seem to work if it
> dependent on a service in the same file);

Could you post a bug about this (with all relevant information) in initng bz? It
doesn't sound like a hard fix to me...

> - booting hung while starting the daemon udev/udevd hung because udevd does not
> recognize the --daemon argument (easily fixable);

Are you sure about this? According to udevd manpage udevd _has_ a daemon argument.

> - sometimes sound devices are not created, this is clearly a udevd issue;

Udev scripts are being heavily worked on. Let's hope this gets fixed. Filing a
bug might help too.

> - often console switches to cyrillic for a while (ugly);

I've been trying to fix this, but it didn't get any better. Check comment #84
above. If anyone can help me out here I would be very glad...

> - console flashes (ugly);

Flashes? Could you elaborate?

> - kernel messages on consose (ugly but easily fixed by adding -c 1 to klogd);

Ok, fixed in svn.

> - no integration yet with rhgb (easily fixable I presume).

Blah. Do we really need rhgb when running initng?

> - no integration yet with rhgb (easily fixable I presume).

Blah. Do we really need rhgb when running initng?

The question here in my eyes is... do we want to completly integrate initng 
into fedora or not. rhgb is enabled by default on a core install so it should 
also work with initng in my eyes. just my opinion. end users want eye candy.

I repeat that I like initng. By trying it I have now a much clearer view on
the boot process of Fedora.

>> - some bugs (e.g. sometimes stopping a daemon does not seem to work if it
>> dependent on a service in the same file);
>
>Could you post a bug about this (with all relevant information) in initng bz? It
>doesn't sound like a hard fix to me...


I will try but first I need to install 0.5.3. Or would svn be better?


>> - sometimes sound devices are not created, this is clearly a udevd issue;

>Udev scripts are being heavily worked on. Let's hope this gets fixed. Filing a
>bug might help too.

The problem that it only happens occasionally so it seems like a timing issue.
Calling udevstart at the end of system/alsasound/loadmodules forces the devices
to be created but adds 2 seconds to the boottime (as it also checks all other
devices). Again I will need to install 0.5.3 before filing a proper bug report.


>> - booting hung while starting the daemon udev/udevd hung because udevd does not
>> recognize the --daemon argument (easily fixable);
>
>Are you sure about this? According to udevd manpage udevd _has_ a daemon >argument.

Not on my system! Perhaps you are running rawhide? I am running FC4 with the
latest updates but little else.

>> - often console switches to cyrillic for a while (ugly);
>
>I've been trying to fix this, but it didn't get any better. Check comment #84
>above. If anyone can help me out here I would be very glad...

I also have no idea what could possibly cause this. Disabling gdm, consolefont,
and keymaps did not fix it....

>> - console flashes (ugly);
>
>Flashes? Could you elaborate?

The console turns black and then it comes back up.

>> - no integration yet with rhgb (easily fixable I presume).
>
>Blah. Do we really need rhgb when running initng?

I think we do (but it is of course not a show stopper). Many people do like the
cleanliness of a WinXP or Mac/OSX boot.  On a desktop system users should not
see *any* bootmessages (even rhgb is too noisy for my taste). 

(In reply to comment #181)
> >> - some bugs (e.g. sometimes stopping a daemon does not seem to work if it
> >> dependent on a service in the same file);
> >
> >Could you post a bug about this (with all relevant information) in initng bz? It
> >doesn't sound like a hard fix to me...
> 
> I will try but first I need to install 0.5.3. Or would svn be better?

I think 0.5.3 is good. I haven't seen any big changes in that area since 0.5.3...
 
> >> - sometimes sound devices are not created, this is clearly a udevd issue;
> 
> >Udev scripts are being heavily worked on. Let's hope this gets fixed. Filing a
> >bug might help too.
> 
> The problem that it only happens occasionally so it seems like a timing issue.
> Calling udevstart at the end of system/alsasound/loadmodules forces the devices
> to be created but adds 2 seconds to the boottime (as it also checks all other
> devices). Again I will need to install 0.5.3 before filing a proper bug report.

I've also experienced strange timing problems involving udev. Someone promised
me they were gone, but obviously not. Does it make any difference simply
inserting a "sleep 10" at the beginning of system/alsasound/loadmodules?

> >> - booting hung while starting the daemon udev/udevd hung because udevd does not
> >> recognize the --daemon argument (easily fixable);
> >
> >Are you sure about this? According to udevd manpage udevd _has_ a daemon
>argument.
> 
> Not on my system! Perhaps you are running rawhide? I am running FC4 with the
> latest updates but little else.

Hmmm... After a closer look that particular argument doesn't exist anymore in
0.5.3. Just upgrade and be happy...

> >> - console flashes (ugly);
> >
> >Flashes? Could you elaborate?
> 
> The console turns black and then it comes back up.

Strangeness. Haven't ever seen this one. Sounds like it tried to switch to
another tty or something?

> >> - no integration yet with rhgb (easily fixable I presume).
> >
> >Blah. Do we really need rhgb when running initng?
> 
> I think we do (but it is of course not a show stopper). Many people do like the
> cleanliness of a WinXP or Mac/OSX boot.  On a desktop system users should not
> see *any* bootmessages (even rhgb is too noisy for my taste). 

Ok. I guess the best way to do this would be a plugin. All output on the screen
comes from a plugin named cpout (colorprintout). I don't think it would be a
really big deal (for someone custom with rhgb) to make a rhgb output plugin
which instead sends information to rhgb. I guess big question is what would be
showed. Since multiple services/daemons are starting at the same time I guess
rhgb would have to be extended?

I had a look at the initng.spec file in cvs but it is not up to date. The Source0
refers to v0.4. Which spec file should I use?

Created attachment 123789 [details]
new version of selinux patch

the attached patch should fix the selinux issues.
please test and write feedback.
I have some alsasound issue that lets initng hang at boot (0.5.3) will try to
resolve them and test the patch.

ok the problem was theat alsasound has a need = system/boodmisc but it should be
system/bootmisc
after solving that I tryed booting and it hangs after system is starting up
(selinux policy was loaded)
seems like that the rexec code is broken.
can somebody review it? 

(In reply to comment #183)
> I had a look at the initng.spec file in cvs but it is not up to date. The Source0
> refers to v0.4. Which spec file should I use?

The spec file in svn was removed ages ago since it wasn't updated anyway. The
spec attached to this bug is always the latest.

Buglet:

Spec file refers to initng_selinux.patch

Patch is named selinux_2.patch

Buglet (when using selinux patch):

Missing build requires: automake, libtool.

More seriously: is it a good idea for patches to modify configure.in?

there are easy to fix.

does the patch works for you?
I tryed the same code on a test app and it does not hang (the re-exec part seems
ok).
I have no idea why it hangs after "system is starting up"

(In reply to comment #189)
> Buglet (when using selinux patch):
> 
> Missing build requires: automake, libtool.
> 
> More seriously: is it a good idea for patches to modify configure.in?

what else should be done to add extra cflags? 
just edit CFLAGS ?

I edited CFLAGS in configure I think.

does your system boots with selinux enabled and this patch?

(In reply to comment #192)
> I edited CFLAGS in configure I think.

Well, that's no good. First the patch is applied and then the autoconf stuff is
run, so there will be no configure file when the patch is applied, it is
generated later. So dragoran is completely right patching configure.in.

I think autoconf is only run *if* you modify configure.in (since that
makes configure.in newer than configure). At least this is what happens on
my system.

>does your system boots with selinux enabled and this patch?

No unfortunately not. And selinux is disabled on my system. My system hangs
after initializing the kernel. No messages from initng. 

Solutions?

on my rawhide sys it hangs with the message:
mount: sys already mounted or busy
I realy don't know whats gonig on here...
does this patch works for you:
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=122918
(re-exec stuff is not included)

Just to confirm: I compiled initng without the selinux patch and now
my system booted (2.6.14-1.1656_FC4, selinux disabled).

No obvious issues at first sight.

>does this patch works for you:
>https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=122918
>(re-exec stuff is not included)

Yes. Now my computer boots.

But remember that on my system selinux is disabled.

Created attachment 123833 [details]
Patch to disable counter

The counter is not suitable for an automatic build.

Created attachment 123834 [details]
Patch that fixes typo in system/alsasound 

Patch that fixes typo in system/alsasound  (bootmisc ipv boodmisc)

(In reply to comment #199)
> >does this patch works for you:
> >https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=122918
> >(re-exec stuff is not included)
> 
> Yes. Now my computer boots.
> 
> But remember that on my system selinux is disabled.

can you do this:
enable selinux
do touch /.autorelabel as root
reboot and boot using sysvinit (will take some time to relabel)
boot initng with the selinux patch (old one without re-exec) and add enforcing=0
to the kernel cmd line.
post all avc messages you get after booting.

Created attachment 123838 [details]
new selinux patch

Created attachment 123839 [details]
new selinux patch

Created attachment 123847 [details]
Port of alsa part of  /etc/rc.sysinit.

I have been experimenting with the way the official Fedora /etc/rc.sysinit
initializes alsa. The main difference is that Fedora *only* loads the module
for the sound card. All other modules are loaded automagically (does anybody
know why?).

The attached alsasound.i is a port of /etc/rc.sysinit. For me it seems
to solve the problem of sound devices not being created. 

Remark: the "alsactl restore" part does not work as it is called too quickly
after loading the alsa modules. The official Fedora scripts never seem to call
alsactl restore.

The Fedorized alsasound.i I submitted unfortunately does not solve the problem
of the sound devices occasionally not being created. I was too hasty. I really
don't understand what is going on.

Turning on logging in udev did not reveal anything. udevd simply does not seem
to receive the required events.

I will stop looking at initng for a while.

(In reply to comment #206)
> The Fedorized alsasound.i I submitted unfortunately does not solve the problem
> of the sound devices occasionally not being created. I was too hasty. I really
> don't understand what is going on.
> 
> Turning on logging in udev did not reveal anything. udevd simply does not seem
> to receive the required events.
> 
> I will stop looking at initng for a while.
> 
> 
this can happen if udev needs to much time to start and alsasound get started
before udev finished...
does alsasound depend on udev? if not I think it should.

(In reply to comment #207)
> this can happen if udev needs to much time to start and alsasound get started
> before udev finished...
> does alsasound depend on udev? if not I think it should.

There is also a problem in 0.5.3 which makes system/udev/filldev sometimes 
finish without really being finished. I've done a little loop in svn that kicks 
in right after udevstart and that doesn't let filldev finish 
until /dev/.udev/queue is empty. This fixed things for me, lets hope it fixes 
other small bugs like this as well...

the selinux patch is now in svn ..
but some changes to the policy are needed.
I filled a bug here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179761

Created attachment 125311 [details]
initng 0.5.4-2 spec file

* Mon Jan 27 2006 Daniel Malmgren <daner964.ser> 0.5.4-2
- Added --disable-count-me configure argument

* Mon Jan 27 2006 Daniel Malmgren <daner964.ser> 0.5.4-1
- New upstream version
- Remove selinux patch since it's now in upstreams. Don't enable selinux though

  since it stops initng from compiling cleanly.
- Add whole bunch of new stuff to /sbin

Short question: Is there any nice way of disabling Werror from rpm spec or do I
need a patch for that?

0.5.4-2 not building on devel x86_64:
ngc2.c:27:18: error: term.h: No such file or directory

Sometimes specifying --disable-werror to configure works, but not this case,
because -Werror is unconditionally listed in ALL_CFLAGS in configure.in. If you
patch it you may want to do so to the autoconf, to enable easy future enabling
and disabling.

(In reply to comment #211)
> 0.5.4-2 not building on devel x86_64:
> ngc2.c:27:18: error: term.h: No such file or directory

Hmmm... Have you got ncurses-devel installed? If not, try that. If it works,
maybe it should be included in the buildrequires?

> Sometimes specifying --disable-werror to configure works, but not this case,
> because -Werror is unconditionally listed in ALL_CFLAGS in configure.in. If you
> patch it you may want to do so to the autoconf, to enable easy future enabling
> and disabling.

Ok. I've fixed the warnings upstreams, so I'll simply wait for next release ;-)

Created attachment 125860 [details]
initng 0.5.5-1 spec file

New upstreams version. It's getting more and more stable now, this one is
really good.

Now selinux compiles. My computer doesn't start with selinux enabled though,
but at least it compiles ;-)

I once again get the feeling that nothing really happens here. Wouldn't it be
nice to have initng in Extras now that FC5 is being released?

(In reply to comment #213)
> Created an attachment (id=125860) [edit]
> initng 0.5.5-1 spec file
> 
> New upstreams version. It's getting more and more stable now, this one is
> really good.
> 
> Now selinux compiles. My computer doesn't start with selinux enabled though,
> but at least it compiles ;-)
> 
> I once again get the feeling that nothing really happens here. Wouldn't it be
> nice to have initng in Extras now that FC5 is being released?

well if youd do a full install turn everything on and then do a gap analysis
what isnt supported / doesent work youd see that its not completly done yet.

i will be reporting upstream cause reporting here doesent really make sense.
while i also think 0.5.5 is better i think a few more iterstations cant hurt.
didnt yet have time to try on my x86_64 box either only tested with i386 for 0.5.5.

It would be nice when the programs and the initscripts would be shipped
in different packages:

* the initscripts are evolving more and more from simple 'exec start'
  commands to complex and slow 'script start' sequences. Most of the
  code executed there can be done shorter and faster when omitting
  generality

* the initscripts are sometimes very Gentoo specific; e.g. they enforce
  a special syntax to declare bind-mounts

* when initng comes into Core, I am prognosing that we will see all
  the Requires: which are in the 'initscripts' package already but
  which are needed under certain circumstances only

So, I would like when the packaged initscripts would be optional so
that a user could write optimized scripts for his system and/or package
alternative initscripts with minimal dependencies.


I suggest to use a virtual provides so you could write something like

 ,--- 
| ... main-package ...
| Requires: initscripts(initng)
|
| %package initscripts
| Provides: initscripts(initng)
| Requires(post): initng = %version-%release
| ...
| %post initscripts
| /sbin/gen_system_runlevel
| ...
| %files initscripts
| %defattr(-,root,root)
| %config(noreplace) %{_sysconfdir}/initng/*

(In reply to comment #215)
> It would be nice when the programs and the initscripts would be shipped
> in different packages:

I completely agree and from what I understand this is going to happen upstreams
quite soon. The svn structure has just been completely redone and core and
scripts now has separate branches. Sounds like we'll have different tarballs for
next release. I don't really know what that would mean to us. Multiple srpms?

Initng 0.6.0RC1 has just been released. The big difference from earlier versions
is that the scripts are released in a separate tarball. Question is what we want
to do about this. It seems quite clear to me that it would be nice with separate
rpm's, but does that mean having separate spec and srpm files as well or do we
just add a Source1 and another %package section to the existing spec file?

Created attachment 126611 [details]
initng 0.6.0RC1 spec file

Ok, tried splitting up the spec file in two. Seemed like the best solution.

Created attachment 126612 [details]
initng-ifiles 0.0.1 spec file

...and here comes the scripts spec.

Hmmm... Just noticed that rpmlint says that 0.6.0RC1 is an invalid version. What
should I call it instead? 0.5.91?

Move "RC1" to the release tag. 
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-e104844825856d7c45f2f0241586985c0495966b

Created attachment 126805 [details]
0.6.0RC2 spec file

Hope I got the tagging stuff right this time. Those that tried installing
0.6.0RC1 will have to use --oldpackage for this one :-/

Created attachment 126806 [details]
initng-ifiles 0.0.2.1 spec file

Created attachment 126894 [details]
initng 0.6.0 spec file

Created attachment 126895 [details]
initng-ifiles 0.0.2.2 spec file

Created attachment 127695 [details]
initng-ifiles 0.0.3 spec file

- New upstream version
- Added build requirement cmake
- Adopt spec to cmake building
- Removed ifplugd package. Those files doesn't seem to exist anymore (?)
- Updated URLs. Initng homepage is now www.initng.org

I would use virtual packages to express the initng -> ifiles dependency;
e.g.

 ,-- initng.spec:
| Requires:   initng(ifiles)


 ,-- initng-ifiles:
| Provides:   initng(ifiles)

(the parenthesis are just syntactic sugar; don't use it when you dislike it)


Currently, you require the specific 'initng-ifiles' package which
bring in my concerns from comment #215.



Else:
* I would not use versioned BuildRequires; you want a certain upstream
  version (API) of the selinux libraries but support for expression
  such a wish was removed some time ago from 'rpm'. Currently you can
  express a wish for a certain package version only; every supported
  Fedora Core version has these package versions so it is superflously.

  Since Fedora Extras tends to minimize the explicitly stated
  BuildRequires:, the version should be removed.

  Ditto for 'filesystem >= 2.2.4-1'; Fedora Core >= 4 has this package.


* initng-devel should require full-versioned main-package (inclusive
  %release)

* Missing SMP flags. If it doesn't build with it, please add a comment
  (wiki: PackagingGuidelines#parallelmake) (cited from comment #9)

* the first part of %post should be moved into a

  | %triggerin -- mkinitrd

  section. You should add

  | Requires(triggerin): grep coreutils

  too.

  The 'grep ... >/dev/null' can be expressed as

  | grep -q ...


* are the '*.la' files really needed?

* the

  | %install
  | ...
  | mv %{buildroot}%{_datadir}/doc/%{name}/* %{buildroot}/%{_docdir}/%{name}-%{version}/
  | cp -a COPYING AUTHORS ... %{buildroot}/%{_docdir}/%{name}-%{version}/
  | ...
  | %files
  | %doc %{_docdir}/%{name}-%{version}

  can be written as

  | %install
  | ...
  | mkdir _doc
  | mv %{buildroot}%{_datadir}/doc/%{name}/* _doc/
  | 
  | %files
  | %doc COPYING AUTHORS ...
  | %doc _doc/*

* the URL must be updated

* the provided .bz2 should be used instead of the .gz

* the '/%{_includedir}' in

  | %files devel
  | /%{_includedir}/initng

  can be written without leading '/' as

  | %{_includedir}/initng

Created attachment 127742 [details]
new spec file

I updated the spec file and added some changes to %post (selinux support)
A new selinux patch is already in svn.

For next release the spec file needs to be fixed to use cmake instead of
autotools. I'll fix that up as soon as we have a release.

One question: To get selinux working we need to do something like this:

----------pseucocode snip----------------
[if Fedora version >= 5]
cmake . -DSELINUX:BOOL=ON
[else]
cmake . -DOLDSELINUX:BOOL=ON
-----------------------------------------

...instead of the current ./configure line (like I already did in the ifiles
spec, except that we just have a "cmake ." there). What's the best way to
achieve this?

(Oh, and I got a son yesterday. This probably means I won't have much time for
anything the coming week(s).)

(In reply to comment #229)
> For next release the spec file needs to be fixed to use cmake instead of
> autotools. I'll fix that up as soon as we have a release.
Given that upstream seems to be wanting fall into the cmake trap, and given the
fact this PR has seen 229 comments, I am inclined to think this package is not
ready for inclusion into FE.

I am hereby proposing to close this Request as FAILED until this package has
matured.

(In reply to comment #229)

> ...instead of the current ./configure line (like I already did in the ifiles
> spec, except that we just have a "cmake ." there). What's the best way to
> achieve this?

You could have a look at
http://fedoraproject.org/wiki/DistTag
To test (for example to have %dist set to el3)
rpmbuild -ba --define "dist el3" initng.spec
Or use mock. In that case you may have to set in mock cfg file
config_opts['buildgroup'] = 'build build-base build-minimal'

(In reply to comment #230)

> fact this PR has seen 229 comments, I am inclined to think this package is not
> ready for inclusion into FE.
> 
> I am hereby proposing to close this Request as FAILED until this package has
> matured.

I disagree, not on the fact that this package isn't ready for inclusion
into FE. But that closing the request as FAILED is a good thing. Indeed
I think that the review process done here helps the upstream to ameliorate
the package, an maybe more importantly to structurate it such that it is 
easier to package, and this is easier if the review is kept alive.

Given how long the current review is, it may be right to close it and 
reopen another review, such that unneeded history is forgotten, but I 
believe that a review for inclusion in extras should be continued.
It would make sense to reopen reviews now that the sources are splitted,
but that's only my opinion.

Please do not close initng. Even though perhaps not ready for extras, it is very
usable.

(In reply to comment #233)
> Even though perhaps not ready for extras, it is very usable.
This is an FE review request. The purpose of such requests is review packages
for integration into FE.

As it seems to me, you guys are abusing FE-devel as your testbed and are mixing
up bugzilla with a developers mailing list.

(In reply to comment #230)
> Given that upstream seems to be wanting fall into the cmake trap,

What trap is that? I thought that cmake being in FE meant that other packages in
FE could use it?

> and given the fact this PR has seen 229 comments, I am inclined to think this
> package is not ready for inclusion into FE.

(almost) all those comments are constructive and helpful, they're here because
people want this package in extras and are willing to help. I'm guilty of having
written almost 100 of them. Blame me.

> I am hereby proposing to close this Request as FAILED until this package has
> matured.

It is maturing all the time. Have you really looked at the difference between
when I opened this bug and where we stand now?

> What trap is that?
I already answered that yesterday on fedora-extras@

> It is maturing all the time. Have you really looked at the difference between
> when I opened this bug and where we stand now?
Yes, initially you stood in the middle of nowhere, now you are still standing
midst of active development and way off from being ready for a release.

This is my last comment on this RR, I'll leave the final decision to this RR to
others.

Created attachment 128141 [details]
initng 0.6.1-1 spec file

Until told otherwise I'll just keep on working. Now initng has completely moved
over to using cmake, which means it builds a lot faster.

I think everything Enrico pointed out in #227 is fixed now.

I decided that for the selinux stuff it would be better to look at libselinux
version than FC version, right? I'm no expert at awk, anyone else might want to
check if the awk statement (in %build) can be done better.

Created attachment 128142 [details]
initng-ifiles 0.0.3.1-1 spec file

...and the corresponding ifiles.

* I think, the old vs. recent SELinux API check should be implemented
  in the upstream package (I do not know, whether cmake is powerful
  enough for that). Else, I would not use 'rpm -q ...' but check the
  required feature. E.g. with

  | grep -q only-in-old-api /usr/include/selinux/selinux.h && API=OLD || API=
  | cmake . -D${API}SELINUX:BOOL=ON ...

  But I really do not know for what the OLDSELINUX/SELINUX flag is
  used and can not tell the exact string for 'only-in-old-api'.

* there should be appended a '|| :' to the

  | /usr/sbin/semanage ...
  | /sbin/restorecon ...

  calls in %post and %postun, and perhaps '2>/dev/null' too. 'semanage'
  is not available for FC4.

* %postun is buggy; '/sbin/ldconfig' must be moved into the body:

  | %postun -p /sbin/ldconfig
  | /usr/sbin/semanage ...


* just a minor tweak: use

  | %install
  | rm -rf %{buildroot} _doc
                        ~~~~

* the

  | %post
  | ...
  | exit 0

  is useless; either %post reached the 'exit 0'; then the last command
  succeeded with exit code '0' and the complete script will exit with
  0. Or, a command failed; then the complete script will abort
  immediately without seeing the 'exit 0'.

* not really wrong, but the '-r' flag can/should be omitted:

  | %install
  | ...
  | rm -rf %{buildroot}/sbin/killall5



Else:

* when you want a full review, then provide a complete .src.rpm.

* how mature is the i-files syntax? When scripts will have to be
  rewritten for e.g. 0.70, this will stop me from approving it...

  Resp.: when published now, can you guarantee, that
  a) package follows upstream releases, and
  b) a nightly 'smart update' to a new version will not bring the
     system into an unusable state?

* when attaching spec files to the ticket, a 'text/plain' type shall 
  be assigned instead of 'application/octet-stream'

(In reply to comment #239)
> * I think, the old vs. recent SELinux API check should be implemented
>   in the upstream package (I do not know, whether cmake is powerful
>   enough for that). Else, I would not use 'rpm -q ...' but check the
>   required feature. E.g. with
> 
>   | grep -q only-in-old-api /usr/include/selinux/selinux.h && API=OLD || API=
>   | cmake . -D${API}SELINUX:BOOL=ON ...
> 
>   But I really do not know for what the OLDSELINUX/SELINUX flag is
>   used and can not tell the exact string for 'only-in-old-api'.

Done in upstream svn, -DSELINUX should now work on FC4 and FC5

Created attachment 128240 [details]
initng 0.6.2-1 spec file

(In reply to comment #239)
> * I think, the old vs. recent SELinux API check should be implemented
>   in the upstream package

Since Dragoran's fix (thanks a lot for that one!) didn't make it into 0.6.2
I'll fix this in the spec for 0.6.3 when released.

> * there should be appended a '|| :' to the
> 
>   | /usr/sbin/semanage ...
>   | /sbin/restorecon ...
> 
>   calls in %post and %postun, and perhaps '2>/dev/null' too. 'semanage'
>   is not available for FC4.

Fixed.

> * %postun is buggy; '/sbin/ldconfig' must be moved into the body:

Did I get it right this time? (What was that "-p"?)

>   | rm -rf %{buildroot} _doc
>			  ~~~~

Fixed.

> * the
> 
>   | %post
>   | ...
>   | exit 0
> 
>   is useless;

No idea where that came from. Removed.

> * not really wrong, but the '-r' flag can/should be omitted:

Well, we might save one cpu cycle or two by removing it ;-)

> * when you want a full review, then provide a complete .src.rpm.

I'll do that as soon as someone tells me there will be any point with a full
review. Judging by Ralf's comment about the package being "way off from being
ready for a release", I guess there's no point really yet?

> * how mature is the i-files syntax? When scripts will have to be
>   rewritten for e.g. 0.70, this will stop me from approving it...

I'll pass this question on to upstreams ml. The syntax has changed a lot in the
past, but it seems to have stabilized lately.

>   Resp.: when published now, can you guarantee, that
>   a) package follows upstream releases, and
>   b) a nightly 'smart update' to a new version will not bring the
>      system into an unusable state?

A is no problem, I'll continue to release as I'm doing now (Only problem might
be that I can't reach neither Fedoras build system nor cvs from work because of
a corporate firewall, I'll have to do this from home instead).

About B, I guess this means that I'll have to solve incompabilities that may
arise using scriptlets in the spec file, right?

> * when attaching spec files to the ticket, a 'text/plain' type shall 
>   be assigned instead of 'application/octet-stream'

Oh. I've always used the "auto-detect", I thought it was smart enough...

Created attachment 128245 [details]
initng 0.6.3-1 spec file

From the changelog:
- New upstream version
- Removed selinux version check from spec, this is now upstreams
- Hot reload initng in %post

just as an addition. someone posted a nice bsah-completion file on the initng
mailinglist. works nicely for me and i guess some of you been waiting for beeing
able to properly autocomplete ngc etc.

you forgot to specify cmake as buildrequries in the latest 0.6.3 spec

RPATH Problem when building with cmake in a userbuild env:

ERROR   0002: file '/lib/initng/libhistory.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libnetprobe.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/liblockfile.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libfstat.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libcritical.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libsimplelauncher.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libreload.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libchroot.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libenvparser.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libpause.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libsyslog.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libstcmd.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libinitctl.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libfind.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]ERROR   0002: file
'/lib/initng/liblast.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]ERROR   0002: file
'/lib/initng/librlparser.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libdebug_commands.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/librunlevel.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libbashlaunch.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libunneeded.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libnge.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libinteractive.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libsyncron.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libalso.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]ERROR   0002: file
'/lib/initng/libidleprobe.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/liblogfile.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libstdout.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libcpout.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libctrlaltdel.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libservice.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libconflict.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libsuid.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]ERROR   0002: file
'/lib/initng/libdaemon.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libiparser.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/liblimit.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/libchdir.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/lib/initng/librenice.so' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]
ERROR   0002: file '/sbin/nge' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/plugins/nge' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/plugins/nge]
ERROR   0002: file '/sbin/nge_raw' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/plugins/nge' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/plugins/nge]
ERROR   0002: file '/sbin/ngc' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/plugins/ngc4' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/plugins/ngc4:/home/rkl/rpmbuild/BUILD/initng-0.6.3/plugins/nge]
ERROR   0002: file '/sbin/ngc' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/plugins/nge' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/plugins/ngc4:/home/rkl/rpmbuild/BUILD/initng-0.6.3/plugins/nge]
ERROR   0002: file '/sbin/initng' contains an invalid rpath
'/home/rkl/rpmbuild/BUILD/initng-0.6.3/src' in
[/home/rkl/rpmbuild/BUILD/initng-0.6.3/src]

initng-ifiles 0.0.3.1 needs initng-devel as buildrequires. if you do test builds
with mock you wont miss such buildrequires problems in the future.

sorry for the amount of posts... but since i tested cvs shortly before release i
didnt expect that many problems to pop up... i still used autotools for building
though back then.

damn... another one...

initng-0.6.3 %post scriptlet always fails if initng isnt installed. the
scriptlet should only be executed at update not at install time.

Created attachment 128252 [details]
initng 0.6.3-2 spec file

- Only hot reload initng if there is a initng process
- Add cmake back to buildrequires

And yes, those rpath errors are back. Anyone knows what to do this time?

Created attachment 128253 [details]
initng-ifiles 0.0.3.1-2 spec file

Added initng-devel to buildrequires

thanks for your quick fixes. i have another 3 things that need fixing though:

1. initng-ifiles %post doesent generate the required files... 
the generate script actually only does something if the -all switch is used.

2. system/auditd doesent start because /etc/init.d/auditd doesent exist

3. and initng %post requires grubby to be installed. (post requires)

#250: 2. audit wasnt installed on my fc5 test system (fresh install with 
updates) i have to look into that. not an initng problem really unless maybe of 
the runlevel gen... why did it add it when its not present.

with all the stuff fixed above everything is running quite fine. 

one of the things i dont like though is the current iptables script in 
initng... maybe it would make sense to patch it to use the existing init 
scripts of the sysvinit for start and stop. would be better and easy to 
maintain.

just a suggestion that has to be discussed.

at some point of booting up initng output becomes russian for me. someone has 
to figure out what script triggers that. (probably wrong encoding?) it switches 
back at the end of the booting process. 

Nobody seems to know what causes this. I did some testing a while ago 
and it didn't seem to be used by any script. Perhaps the handling 
of terminal output by initng itself?

I meant "...caused by any script..."

#253: i will carry it upstream in a few hours. there must be a trivial cause of 
this. i am 80% sure its triggered by an ifiles script. going to try to figure 
out by which one because it always happens at the same point of booting (with 
my setup). one way to figure it out is to generate a bootchart. then i can see 
what switches there and what switches actually back. 

i can also share a trivial patch to the iptables script to use the sysvinit 
script as "backend". 

the next question is... shouldnt NetworkManager provide network so the 
bootprocess completes if its enabled? What do you think?

x86_64 build issue:
+ rm -f /home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/sbin/killall5
+ mkdir _doc
+ mv
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/usr/share/doc/initng/gentoo-chart.png
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/usr/share/doc/initng/initng-chart.png
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/usr/share/doc/initng/initng.txt
_doc/
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-python-bytecompile
Processing files: initng-0.6.3-2
error: File not found by glob:
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/lib64/libinitng.*
error: File not found by glob:
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/lib64/libngeclient.*
error: File not found by glob:
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/lib64/libngcclient.*
error: File not found:
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/lib64/initng
Executing(%doc): /bin/sh -e /home/dragoran/rpm/tmp/rpm-tmp.32939
+ umask 022
+ cd /home/dragoran/rpm/BUILD
+ cd initng-0.6.3
+
DOCDIR=/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/usr/share/doc/initng-0.6.3
+ export DOCDIR
+ rm -rf
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/usr/share/doc/initng-0.6.3
+ /bin/mkdir -p
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/usr/share/doc/initng-0.6.3
+ cp -pr COPYING AUTHORS CODING_STANDARDS FAQ NEWS README TODO
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/usr/share/doc/initng-0.6.3
+ cp -pr _doc/gentoo-chart.png _doc/initng-chart.png _doc/initng.txt
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/usr/share/doc/initng-0.6.3
+ exit 0
Processing files: initng-devel-0.6.3-2
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: initng = 0.6.3-2


RPM build errors:
    File not found by glob:
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/lib64/libinitng.*
    File not found by glob:
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/lib64/libngeclient.*
    File not found by glob:
/home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/lib64/libngcclient.*
    File not found: /home/dragoran/rpm/tmp/initng-0.6.3-2-root-dragoran/lib64/initng

hardcoding 
/lib/libinitng.*
/lib/libngeclient.*
/lib/libngcclient.*
/lib/initng
fixes it.. 
whats the clean why to do so?

/lib is hardcoded in the CMakeList.txt files...

Created attachment 128268 [details]
new spec file

This spec file fixes the x86_64 build issues and the rpath issues.
The only porblem that I have is that gen_system_runlevel does not seem to
generate a runlevel.

gen_system_runlevel -all does generate files but many services are missing and
it fails to boot after udev because its trys to start udev a second time.

Created attachment 128285 [details]
initng-ifiles 0.0.3.1-3 spec file

(In reply to comment #250)
> 1. initng-ifiles %post doesent generate the required files... 
> the generate script actually only does something if the -all switch is used.

I really wonder why that was changed. Well, I'll add -all to it then...

> 3. and initng %post requires grubby to be installed. (post requires)

Check again. Grubby is run from %triggerin -- mkinitrd now.


(In reply to comment #251)
> #250: 2. audit wasnt installed on my fc5 test system (fresh install with 
> updates) i have to look into that. not an initng problem really unless maybe
of 
> the runlevel gen... why did it add it when its not present.

Hmmm... I thought audit was one of those fundamental things that was installed
on all recent fedora systems?


(In reply to comment #252)
> at some point of booting up initng output becomes russian for me. someone has

> to figure out what script triggers that. (probably wrong encoding?) it
switches 
> back at the end of the booting process. 

This one is really a pain in the ass. I tried hard to fix it a while back
(check #84 above) without any success. You could try running with "interactive"
on the grub prompt, I guess it would make it easier to determine where the
problem is.


(In reply to comment #259)
> This spec file fixes the x86_64 build issues and the rpath issues.

Is this really a good idea? Hardcoding stuff in our spec file because they're
hardcoded upstreams?

(In reply to comment #261)
> Created an attachment (id=128285) [edit]
> initng-ifiles 0.0.3.1-3 spec file
> 
> (In reply to comment #250)
> > 1. initng-ifiles %post doesent generate the required files... 
> > the generate script actually only does something if the -all switch is used.
> 
> I really wonder why that was changed. Well, I'll add -all to it then...
> 
for me -all creates some files but it does not even add gdm and some services
that are started in sysvinit
> > 3. and initng %post requires grubby to be installed. (post requires)
> 
> Check again. Grubby is run from %triggerin -- mkinitrd now.
> 
> 
> (In reply to comment #251)
> > #250: 2. audit wasnt installed on my fc5 test system (fresh install with 
> > updates) i have to look into that. not an initng problem really unless maybe
> of 
> > the runlevel gen... why did it add it when its not present.
> 
> Hmmm... I thought audit was one of those fundamental things that was installed
> on all recent fedora systems?
> 
no audit is only for debugging.
> 
> (In reply to comment #252)
> > at some point of booting up initng output becomes russian for me. someone has
> 
> > to figure out what script triggers that. (probably wrong encoding?) it
> switches 
> > back at the end of the booting process. 
> 
> This one is really a pain in the ass. I tried hard to fix it a while back
> (check #84 above) without any success. You could try running with "interactive"
> on the grub prompt, I guess it would make it easier to determine where the
> problem is.
> 
> 
> (In reply to comment #259)
> > This spec file fixes the x86_64 build issues and the rpath issues.
> 
> Is this really a good idea? Hardcoding stuff in our spec file because they're
> hardcoded upstreams?

ok fixed it upstream (commit 3961) add -DLIB_INSTALL_DIR:STRING=/%{_lib} to the
cmake line in the spec file.
other issue:
the deps have a chicken egg problem :
initng-ifiles requires initng-devel to build; initng-devel depends on initng;
initng depends on initng-ifiles 
so I am forced to use --nodeps onm initng-devel
does it really require initng?

x86_64 bug is fixed for upstream initng-ifiles too.

Created attachment 128739 [details]
initng 0.6.4-1 spec file

- New upstream version
- Added lib config flag to cmake
- Removed CODING_STANDARDS and FAQ that doesn't exist anymore

Anyone got any solution to the chicken-egg problem? Does initng-devel really
need initng?

Created attachment 128740 [details]
initng-ifiles 0.0.3.2-1 spec file

(In reply to comment #264)
> Created an attachment (id=128739) [edit]
> initng 0.6.4-1 spec file
> 
> - New upstream version
> - Added lib config flag to cmake
> - Removed CODING_STANDARDS and FAQ that doesn't exist anymore
> 
> Anyone got any solution to the chicken-egg problem? Does initng-devel really
> need initng?

you have to remove /lib (hardcoded) again now /%{_lib} can be used again.

Created attachment 128844 [details]
initng 0.6.5-1 spec file

- New upstream version
- Removed the hardcoded /lib path

New in this release is that the selinux stuff moved to a plugin, which will
hopefully be an enhancement.

(In reply to comment #267)
> New in this release is that the selinux stuff moved to a plugin, which will
> hopefully be an enhancement.

Yeah, right! Discovered that I hadn't even enabled selinux (since the way to
enable it changed when it became a plugin). Enabling it (by enabling
BUILD_SELINUX instead of SELINUX) broke entire build process. It's noted in
upstreams bz.

Created attachment 128936 [details]
initng 0.6.6-1 spec file

- New upstream version
- Once again commented out the selinux stuff since I can't get it to work.

Created attachment 128966 [details]
64bit libprovide libdir patch against inting-0.6.6 to be applied with -p0

(In reply to comment #270)
> Created an attachment (id=128966) [edit]
> 64bit libprovide libdir patch against inting-0.6.6 to be applied with -p0
> 

I fixed this upstream

#272 wierd... yesterdays when i sent it here upstream told me that its fixed in
head already. still 0.6.6 needed the patch to package up cleanly so i thought
cant hurt to submit to here :)

Created attachment 129307 [details]
initng-ifiles 0.0.4-1 spec file

New upstreams ifiles. Nothing new in the spec. Biggest change upstreams seem to
be that require_network now is gone in favour of a better solution.

with 0.0.4 ifiles and cleanly regenned runlevels the agettys dont spawn for me.
just investigating the problem. can anyone confirm?

#274 tested head and its already fixed there

Created attachment 129586 [details]
initng 0.6.7-1 spec file

Biggest change is that selinux now compiles and actually seems to work!

A minor drawback in this release is that it seems to require c++ devel files to
build (because of a glitch in the makesystem that's already fixed in svn).
Should I add a temporary build requirement in the spec file for this?

Is there any opinions about how stable initng is now? Any major stuff that
needs fixing? Are we getting ready for a full review?

Something I find really ugly is that initng switches to cyrillic for a while
during boot. It would be nice if this were fixed!

#276

1. speedstep script causes an oops on shutdown
2. iptables script is suboptimal
3. iptables seems not to be started with default generated runlevels
4. #277 yeah i reported that already. its a fact that fedora seems to need a
special presetup for the gettys according ot the infos i collected from the
initng mailinglist.
5. chicken egg dep problem will be problematic for doing clean mock builds of
both  packages (main/ifiles)

for future relaeses i will help testing initng before baselines/releasetags are
made. yet we all seem to have been running after it... we gotta run ahead :o)

personally i think with the above issues fixed its ready for release

(In reply to comment #278)
> #276
> 1. speedstep script causes an oops on shutdown

Anyone got any ideas?

> 2. iptables script is suboptimal

Hmmm... I can see what you mean. Anyone here that has the knowledge and time to 
look at it?

> 3. iptables seems not to be started with default generated runlevels

Oops. A quick look at gen_system_runlevel showed that it was a complete mess, I 
guess it hasn't worked for a while. Fixed it up in svn. Gen_system_runlevel 
mainly is a big cludge that everyone has agreed should be replaced. Question is 
with what...

> 4. #277 yeah i reported that already. its a fact that fedora seems to need a
> special presetup for the gettys according ot the infos i collected from the
> initng mailinglist.

So what _is_ the problem with Fedora? What's the difference from everybody else?

> 5. chicken egg dep problem will be problematic for doing clean mock builds of
> both  packages (main/ifiles)

Anyone got any ideas on this? I'm quite sure initng can't be completely alone 
about this kind of problem, how do other packages solve it?

#279

1. i am going to fix that (compare sysvinit script) unless someone else is faster

2. i am going to fix that (compare sysvinit script) unless someone else is faster
3. great
4. the full explanation is somewhere on the initng mailinglist. somewhere in the
2005 archives if i am not too wrong.
5. thats something that just shouldnt happen. other packages afaik dont have
that problem after beeing properly fixed. not splitting it would prevent it from
throwing up.

another issue:

suspend / resume doesent work in fc5 with initng
should be looked into

with all the issues mentioned today fixed i see it ready to go into extras (my
personal view)

as for the chicken egg problem... not having initng depend on the ifiles would
make it build in mock.

hah... just figured out that swap is noted used ...

swapon isnt really executed and/or working at boottime. has to be investigated.

(In reply to comment #280)
> 4. the full explanation is somewhere on the initng mailinglist. somewhere in
> the 2005 archives if i am not too wrong.

After a whole lot of searching in the archive I give up. The only mails I find 
regarding the issue are the ones where I try to solve it :-/ Back in november I 
was trying to make a plugin for it. What I still can't figure out is why Fedora 
is having these troubles when other distro's just work right out of the box. 
Something with utf stuff set up in the kernel?

(In reply to comment #281)
> suspend / resume doesent work in fc5 with initng
> should be looked into

Do you file it upstreams? I have no idea if this work with other distros...

> as for the chicken egg problem... not having initng depend on the ifiles would
> make it build in mock.

Yep. And it would also mean that a whole lot of people would just do a "yum 
install initng", reboot and then blame us when it doesn't work. Initng needs 
the ifiles to do any good. But do initng-devel really need initng? Or is it 
just common practice that foo-devel depends on foo?

I noticed btw that initscripts depends on SysVinit but not the other way 
around. Seems strange to me...

(In reply to comment #282)
> hah... just figured out that swap is noted used ...
> swapon isnt really executed and/or working at boottime. has to be 
investigated.

Looked into it, turned out system/swap wasn't added to default runlevel. Fixed 
in svn.

#283

well thats what i meant i think... if the comments from around nov 2005 are from
you then sorry for misreferencing you.

for suspend resume i am going to file it upstream once i figure out more why it
barfs... anyone is invited to help me though.
swsusp2 works if i swapon manually. maybe the whole not swap mounting issue hsa
to do with the facts that i use LABEL for the swap partition.
to be investigated.

i will also discuss the issue with upstream... i am quite often on freenode
#initng with nick "che"

inconvenience vs not beeing able to build it for extras at all. you pick ;)

i agree that it would be nicer if ifiles would be installed automatically if
initng is pulled but currently that just cant happen.

just found more out regarding the "cyrillic letters" issue...

actually it doesent happen for me if i use vgs kernel boot param

e.g. vga=792 for 1024x768 (on my thinkpad i use 834 for 1400x1050)

maybe that is yet undiscovered useful input to go for that problem

Very nice work around indeed. Maybe other distros include a vga= parameter by
default?

(In reply to comment #285)
> #283
> 
> well thats what i meant i think... if the comments from around nov 2005 are from
> you then sorry for misreferencing you.
> 
> for suspend resume i am going to file it upstream once i figure out more why it
> barfs... anyone is invited to help me though.
> swsusp2 works if i swapon manually. maybe the whole not swap mounting issue hsa
> to do with the facts that i use LABEL for the swap partition.
> to be investigated.
> 
> i will also discuss the issue with upstream... i am quite often on freenode
> #initng with nick "che"
> 
> inconvenience vs not beeing able to build it for extras at all. you pick ;)
> 
> i agree that it would be nicer if ifiles would be installed automatically if
> initng is pulled but currently that just cant happen.

it would be easier to drop the initng -> initng-devel dep

spec file issue:

add the default opt flags to the cmake line... like:

cmake . -DBUILD_SELINUX:BOOL=ON -DCOUNT_ME:BOOL=OFF -DCMAKE_SKIP_RPATH:BOOL=ON
-DLIB_INSTALL_DIR:STRING=/%{_lib} -DCMAKE_CXX_FLAGS:STRING='%{optflags}'

Blockers:

1. core package contains development files (*.so); write

   | %files
   | ...
   | /%{_lib}/lib*.so.*

   | %files devel
   | ...
   |  /%{_lib}/lib*.so

2. the

   | if [ -n "`ps -e|grep initng`" ]; then
   | 	/sbin/ngc --quiet -c >/dev/null 2>&1
   | fi

   in %post is

   a) ugly
   b) has missing Requires(post): grep procps
   c) contains one of the worst constructs in %scriptlets:

      | cmd 2>/dev/null

      which makes scriptlets fail silently without giving user a hint
      about the reason
   d) wrong because it will take non-init initngs into account

   The construct above should be replaced by

   | Requires(post): procps
   | ...
   | init=$(ps --no-headers -o '%%c' 1)
   | test x"$init" != xinitng || /sbin/ngc --quiet -c || :



Comments:

1. For bootstrapping in Extras, you can omit the

   | Requires: %{name} = %{version}-%{release}

   in -devel. Alternatively (I would prefer that), you should create a
   '-lib' subpackage with only the libraries and require this subpackage
   by -devel.

2. the

   | if [ -x /usr/sbin/semanage ]; then
   |      /usr/sbin/semanage fcontext -a -t init_exec_t /sbin/initng 2>/dev/null || :
   | fi

   can be expressed shorter as

   | /usr/sbin/semanage fcontext -a -t init_exec_t /sbin/initng 2>/dev/null || :

Forgot:

when following the -lib suggestion you should prevent version mix either by:

| Requires: %name-lib = %version-%release

in main; or by

| Conflicts: %name < %version-%release
| Conflicts: %name > %version-%release

in -lib.

Created attachment 129723 [details]
initng 0.6.7-2 spec file

(In reply to comment #290)
> 1. core package contains development files (*.so); write

Did I get you right now?

>    | Requires(post): procps
>    | ...
>    | init=$(ps --no-headers -o '%%c' 1)
>    | test x"$init" != xinitng || /sbin/ngc --quiet -c || :

Thanks! That's a lot nicer!

>    in -devel. Alternatively (I would prefer that), you should create a
>    '-lib' subpackage with only the libraries and require this subpackage
>    by -devel.

Something like this?

> 2. the
> 
>    | if [ -x /usr/sbin/semanage ]; then
>    |	    /usr/sbin/semanage fcontext -a -t init_exec_t /sbin/initng
2>/dev/null || :
>    | fi
> 
>    can be expressed shorter as
> 
>    | /usr/sbin/semanage fcontext -a -t init_exec_t /sbin/initng 2>/dev/null
|| :

Ok. The check was introduced since you pointed out that semanage doesn't exist
in FC4...

#289

i have to correct myself. id suggets building it with:

cmake . -DBUILD_SELINUX:BOOL=ON -DCOUNT_ME:BOOL=OFF -DCMAKE_SKIP_RPATH:BOOL=ON
-DLIB_INSTALL_DIR:STRING=/%{_lib} -DCMAKE_C_FLAGS:STRING='%{optflags}'
make %{?_smp_mflags} VERBOSE=1

without the explcit setting its getting built 32 bit on x86_64 and the default
optflags should be used anyways to build it.

VERBOSE=1 with the make line will print the real output of the build. its
contraproductive to hide that because you cant see if its building right.

a hardcoded path makes a plugin yet segfault on x86_64 will be fixed in svn soon.

> > 1. core package contains development files (*.so); write

> Did I get you right now?


sorry, not completely ;)

* you should add 
  | %post   lib -p /sbin/ldconfig
  | %postun lib -p /sbin/ldconfig

  and remove the /sbin/ldconfig from main's %scriptlets

* I am not sure about the plugins (/%{_lib}/initng); I would see them
  as part of the main-package and would not ship them in -lib.

  Beside the devel-ifiles chicken-egg problem, the purpose of -lib is
  to avoid heavy dependencies e.g. for GUIs which are using the initng
  ifiles-parser.


> >    | if [ -x /usr/sbin/semanage ]; then
> >    |	    /usr/sbin/semanage fcontext -a -t init_exec_t /sbin/initng 2>/dev/null || :
> >    | fi
> > 
> >    can be expressed shorter as
> > 
> >    | /usr/sbin/semanage fcontext -a -t init_exec_t /sbin/initng 2>/dev/null || :
> 
> Ok. The check was introduced since you pointed out that semanage doesn't exist
> in FC4...

My comment #239 was about a

| /usr/sbin/semanage fcontext -a -t init_exec_t /sbin/initng

statement *without* the trailing '|| :'

Current spec is ok regarding this issue.

Created attachment 129763 [details]
fixes hardcoded path for 64 bit builds so plugins can work at all.

fixes hardcoded path for 64 bit builds so plugins can work at all.

(its already in the upstream queue to be commitedm just for those that need it
working meanwhile :) )

Comment on attachment 128966 [details]
64bit libprovide libdir patch against inting-0.6.6 to be applied with -p0

fixed upstream already and is in 0.6.7

0.0.5 ifiles have been release since a while now...

http://download.initng.org/initng-ifiles/v0.0/

Created attachment 129900 [details]
initng-ifiles 0.0.5-1 spec file

(In reply to comment #297)
> 0.0.5 ifiles have been release since a while now...
> 
> http://download.initng.org/initng-ifiles/v0.0/

I know that. I should've uploaded it directly if just bugzilla had been
working. Here goes. Nothing changed but the version number...

Created attachment 129901 [details]
initng 0.6.7-3 spec file

Fixing what was pointed out in #294

-DCMAKE_CXX_FLAGS:STRING='%{optflags}'
is stupid becuase initng is written in C you should use (or at least add)
-DCMAKE_C_FLAGS:STRING='%{optflags}' here.

Created attachment 129911 [details]
initng 0.6.7-4 spec file

(In reply to comment #300)
> -DCMAKE_CXX_FLAGS:STRING='%{optflags}'
> is stupid becuase initng is written in C you should use (or at least add)
> -DCMAKE_C_FLAGS:STRING='%{optflags}' here.

You're quite right. Noticed that I'd missed Rudolfs #293, now fixed.

#300
was more or less a copy and paste typo i missed in my first comment like #301
says i corrected myself already in #293

atleast with that added at all 64 bit builds are actually real 64 bit builds :)

initng 0.6.7 with 0.0.5 ifiles work quite fine here. can you confirm on 32bit
that the loop module never gets probed? i have to look up where in the sysvinit
stuff that is done. cant atm though... sorry.

Just like to note that with -DCMAKE_C_FLAGS:STRING='%{optflags}' 0.6.7 doesn't
build at all for me, I get the following:

cc1: warnings being treated as errors
/home/danielm/rpmbuild/BUILD/initng-0.6.7/src/initng_main.c: In function
'initng_main_segfault':
/home/danielm/rpmbuild/BUILD/initng-0.6.7/src/initng_main.c:547: warning:
ignoring return value of 'write', declared with attribute warn_unused_result
/home/danielm/rpmbuild/BUILD/initng-0.6.7/src/initng_main.c:559: warning:
ignoring return value of 'write', declared with attribute warn_unused_result

...whereas I don't get any warnings at all without the extra flags. I fixed the
warnings in svn by just checking the return value of write() and then doing
nothing with it, which might not be the prettiest - but working - solution.

for me svn does not build:
Linking C shared library libinitng.so
/usr/bin/cmake -E remove -f libinitng.a libinitng.so.0.0.0 libinitng.so.0
libinitng.so
cd /home/dragoran/rpm/BUILD/initng-0.6.7/src && gcc -fPIC  -shared
-Wl,-soname,libinitng.so.0 -o libinitng.so.0.0.0
"CMakeFiles/initng.dir/initng_active_db.o"
"CMakeFiles/initng.dir/initng_active_state.o"
"CMakeFiles/initng.dir/initng_common.o"
"CMakeFiles/initng.dir/initng_control_command.o"
"CMakeFiles/initng.dir/initng_depend.o" "CMakeFiles/initng.dir/initng_error.o"
"CMakeFiles/initng.dir/initng_execute.o"
"CMakeFiles/initng.dir/initng_env_variable.o"
"CMakeFiles/initng.dir/initng_fd.o" "CMakeFiles/initng.dir/initng_fork.o"
"CMakeFiles/initng.dir/initng_handler.o"
"CMakeFiles/initng.dir/initng_interrupt.o"
"CMakeFiles/initng.dir/initng_kill_handler.o"
"CMakeFiles/initng.dir/initng_load_module.o"
"CMakeFiles/initng.dir/initng_main.o"
"CMakeFiles/initng.dir/initng_open_read_close.o"
"CMakeFiles/initng.dir/initng_plugin_callers.o"
"CMakeFiles/initng.dir/initng_plugin_hook.o"
"CMakeFiles/initng.dir/initng_process_db.o"
"CMakeFiles/initng.dir/initng_service_cache.o"
"CMakeFiles/initng.dir/initng_service_data_types.o"
"CMakeFiles/initng.dir/initng_service_types.o"
"CMakeFiles/initng.dir/initng_signal.o"
"CMakeFiles/initng.dir/initng_static_data_id.o"
"CMakeFiles/initng.dir/initng_static_states.o"
"CMakeFiles/initng.dir/initng_static_service_types.o"
"CMakeFiles/initng.dir/initng_string_tools.o"
"CMakeFiles/initng.dir/initng_struct_data.o"
"CMakeFiles/initng.dir/initng_toolbox.o"  -ldl -lselinux
cd /home/dragoran/rpm/BUILD/initng-0.6.7/src && /usr/bin/cmake -E
cmake_symlink_library libinitng.so.0.0.0 libinitng.so.0 libinitng.so
make[2]: Leaving directory `/home/dragoran/rpm/BUILD/initng-0.6.7'
make[1]: Leaving directory `/home/dragoran/rpm/BUILD/initng-0.6.7'
make: *** [all] Error 2
error: Bad exit status from /home/dragoran/rpm/tmp/rpm-tmp.80463 (%build)


RPM build errors:
    Bad exit status from /home/dragoran/rpm/tmp/rpm-tmp.80463 (%build)
no errormessage at all..
whats going on?
the only thing that I changed is the selinux file (src/plugins/initng_selinux.c)
will attach it after posting this (not tested at all so not in svn)

Created attachment 129936 [details]
 plugins/selinux/initng_selinux.c

here is the new initng_selinux file please test and report if it builds at all
and if yes if it works better (less avcs)

Created attachment 129937 [details]
sorry wrong file attached again

found the error:
cc1: warnings being treated as errors
/home/dragoran/rpm/BUILD/initng-0.6.7/plugins/bash_parser/initng_bash_parser.c:
In function 'bp_handle_client':
/home/dragoran/rpm/BUILD/initng-0.6.7/plugins/bash_parser/initng_bash_parser.c:108:
warning: value computed is not used
/home/dragoran/rpm/BUILD/initng-0.6.7/plugins/bash_parser/initng_bash_parser.c:118:
warning: value computed is not used
/home/dragoran/rpm/BUILD/initng-0.6.7/plugins/bash_parser/initng_bash_parser.c:149:
warning: value computed is not used
make[2]: ***
[plugins/bash_parser/CMakeFiles/bash_parser.dir/initng_bash_parser.o] Error 1
make[1]: *** [plugins/bash_parser/CMakeFiles/bash_parser.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
for some reason it does not like SEND()
#define SEND() (send(fd, &rep, sizeof(bp_rep), 0) == (signed) sizeof(bp_rep))
whitout a if this does not make any sense...

what do you think about building initng-usplash in the extras folder and
splitting off the main package? usplash is a pure userspace bootsplash using the
framebuffer device.

(In reply to comment #307)
> #define SEND() (send(fd, &rep, sizeof(bp_rep), 0) == (signed) sizeof(bp_rep))
> whitout a if this does not make any sense...

Fixed in upstreams svn now.

(In reply to comment #309)
> (In reply to comment #307)
> > #define SEND() (send(fd, &rep, sizeof(bp_rep), 0) == (signed) sizeof(bp_rep))
> > whitout a if this does not make any sense...
> 
> Fixed in upstreams svn now.

still broken:
cc1: warnings being treated as errors
/home/dragoran/rpm/BUILD/initng-0.6.7/plugins/bash_parser/runiscript.c: In
function 'main':
/home/dragoran/rpm/BUILD/initng-0.6.7/plugins/bash_parser/runiscript.c:50:
warning: ignoring return value of 'getcwd', declared with attribute
warn_unused_result

(In reply to comment #310)
> still broken:
> cc1: warnings being treated as errors
> /home/dragoran/rpm/BUILD/initng-0.6.7/plugins/bash_parser/runiscript.c: In
> function 'main':
> /home/dragoran/rpm/BUILD/initng-0.6.7/plugins/bash_parser/runiscript.c:50:
> warning: ignoring return value of 'getcwd', declared with attribute
> warn_unused_result

Sorry. Fixed this one too in svn and this time I checked so that I don't get any
more warnings ;-)

going to do another 64 bit test build with svn then.

actually since theres a release scheduled on monday i did some tests with
yesterdays svn of inting and ifiles.

initng svn:
builds without warnings on x86_64 but has rpath problems:
http://rafb.net/paste/results/MdPv0942.html

initng-files:
doesent boot with freshly generated runlevel configs fails to mount virtual
filesystem for me.

additionally in case selinux is turned off it still tries to switch selinux contexts

new release just happened 30 seconds ago:

http://download.initng.org/initng/v0.6/initng-0.6.8.tar.bz2 
http://download.initng.org/initng-ifiles/v0.0/initng-ifiles-0.0.6.tar.bz2

testing has been done... its working fine for me so far.

known problems: squid doesent terminate properly

The last comment from the submitter has been made 4 months back. I guess we will
give it a week and close this review request. 

Folks might want to look at upstart as an alternative to initng.

http://www.netsplit.com/blog/work/canonical/upstart.html
Supposedly it is fully compatible with existing service scripts while working
very well... at least according to Ubuntu.

#317 been there tried that :)

lets talk again once someone invested the time to create a proper jobs package
and when it has selinux support. i got basic upstart spec files around if there
are any takers.

initng actually just wfm.

(In reply to comment #316)
> The last comment from the submitter has been made 4 months back. I guess we will
> give it a week and close this review request. 

I'm very much alive. The reason I haven't committed anything is there has been
nothing to commit. I was starting to think this project was quite dead. So it's
a big surprise with a new release!

Anyway, I'll look into fixing the spec file up for the new release later today.

Another addition to the happy news is that I've got a brand new 64 bit machine
(with a C2D processor!), which means I'll be able to try the rpm's out in that
environment as well.

Created attachment 136626 [details]
initng 0.6.8 spec file

...and here's the spec file for 0.6.8. Works as a charm for me, both on i386
and x86_64.

Created attachment 136627 [details]
initng-ifiles 0.0.6 spec file

...and the accompanying ifiles...

summary of problems left i found:

1. suspend doesent work yet (no clue why)
2. squid daemon doesent shutdown properly (needs to be zapped)
3. if vga= kernel boot param is not set tty1 shows cyrillic letters at some 
point of bootup (no exact clue why)
4. selinux support works but in past versions i tried there was a problem with 
booting up if selinux is detected to be installed but disabled.

besides those small problems id really say its very useable at this point.

is there a chance to get it approved now?

it doesent break sysvinit and it can peacefully coexist.

(In reply to comment #322)
> summary of problems left i found:
> 
> 3. if vga= kernel boot param is not set tty1 shows cyrillic letters at some 
> point of bootup (no exact clue why)

This one is really a pain in my *ss. No idea whatsoever what's wrong with it.
Note that it only seems to affect stuff that's not printed out in white, ie it
could have something with the ansi colour stuff to do?

> 4. selinux support works but in past versions i tried there was a problem with 
> booting up if selinux is detected to be installed but disabled.

This seems familiar. I'm quite sure though that this was fixed months ago.
Right, Dragoran?

I'm not sure though what happened to the policy stuff (#179761)?

> besides those small problems id really say its very useable at this point.
> 
> is there a chance to get it approved now?
> 
> it doesent break sysvinit and it can peacefully coexist.

Well, you all know my opinion on this one...

Something bad happened to the blockers on this bug.  I think it's supposed to
block 176581 (the fnord review) but now it's blocking both FE-NEW and FE-REVIEW,
which is obviously bogus.  It's not assigned to anyone, so I don't think
FE-REVIEW is accurate.

I've set things the way I'm guessing they're supposed to be; if that's not
correct then please set it properly.

My bad, no cookies for me. Thanks for fixing. Considering this review has near
350 (!) comments, it should probably be assigned to someone (with sponsor
privileges).

I would prefer when the 

| Requires: policycoreutils

would be in an own subpackage. 'policycoreutils' is badly packed (brings in
'initscripts', 'python' and 'pyxf86config' dependencies) and would bloat up
'initng'.

Having the SElinux %script in an own subpackage with

| %package selinux
| Requires(pre): initng = %name-%version

would allow people without SELinux to keep a small system.

Alternatively, core stuff (content of the current main package) could be moved
into a '-core' subpackage which is an 'Requires(pre):' of the main-page. The
main-page would require and execute the heavy-weighted SELinux stuff only. This
alternative has the advantage that 'yum install initng' would do the thing which
is correct for 90% of users while special environments (e.g. chroots) can
install the -core package with reduced dependencies.

'policycoreutils' are not required by much packages and it would be not good
when 'initng' would bring it in.

while I think about it... SELinux scripts and requirements should be removed
completely. FC5 policy contains already

| /sbin/init(ng)?         --      system_u:object_r:init_exec_t:s0

so that initng will be labeled correctly by 'rpm' itself. 

Created attachment 136952 [details]
initng 0.6.8-2 spec file

(In reply to comment #327)
> while I think about it... SELinux scripts and requirements should be removed
> completely. FC5 policy contains already
> 
> | /sbin/init(ng)?	    --	    system_u:object_r:init_exec_t:s0
> 
> so that initng will be labeled correctly by 'rpm' itself.

Something like this?

initng + initng-ifiles
----------------------

GOOD:

* package follows naming guidelines
* spec-file name is ok
* I do not see a violation of packaging guidelines; it builds in mock
  and BuildRequires: are satisfying
* license is ok and consistent
* COPYING is shipped in package
* I do not see a violation of Americon English (does not mean very
  much...;) )
* spec-file is ok
* builds on i386
* package does not have locales which must be handled
* scripts of -lib are calling 'ldconfig'
* package owns all used directories resp. they are shipped by a
  dependency (except of the man-dir but this is accepted)
* %clean section is ok
* paths are macro'ized as far as possible; special paths like /boot or
  /sbin must be written literarily
* content is ok
* documentation is ok
* headers/.so are in -lib
* no pkgconfig issues
* inter-(sub)package dependencies are ok
* there are no .la archives
* no desktop files needed and shipped


initng
------

BLOCKER:

* permissions of plugins are bad; rpmlint complains with

  | W: initng unstripped-binary-or-object /lib/initng/libunneeded.so
  | W: initng unstripped-binary-or-object /lib/initng/libsysreq.so

  like messages. You should add 'chmod +x /%_lib/initng/*.so'



initng-ifiles
-------------

BLOCKER:

* fail to build:
  | [  0%] Building C object tools/CMakeFiles/install_service.dir/install_service.o
  | distcc[3688] ERROR: compile (null) on localhost failed
  | /var/tmp/sessiondir-ensc.1158090336.eM4348/redhat/BUILD/initng-ifiles-0.0.6/tools/install_service.c:34:26: error: initng-paths.h: No such file or directory
  | /var/tmp/sessiondir-ensc.1158090336.eM4348/redhat/BUILD/initng-ifiles-0.0.6/tools/install_service.c:73: error: 'INITNG_PLUGIN_DIR' undeclared here (not in a function)
  | distcc[3687] ERROR: compile /var/tmp/sessiondir-ensc.1158090336.eM4348/redhat/BUILD/initng-ifiles-0.0.6/tools/install_service.c on localhost failed

  Probably an issue in 'initng' (unverified).

initng
------

MINOR (non-blocker):

* the -DCMAKE_SKIP_RPATH:BOOL=ON is not needed anymore with cmake 2.4; see
  'NOTE' section at http://fedoraproject.org/wiki/PackagingDrafts/cmake.

  I will accept it as-is, but it should be evaluated whether it works
  without this option too.


BLOCKERS:

* the permissions-problem affects -lib subpackage too.

forget the initng-ifiles issues; they were caused by me by building against an
old initng-devel package. Hence, 'initng-ifiles' are APPROVED and can be
committed when 'initng' is ready.

another issue: initng does not work when SELinux is disabled. Workaround is, to
remove the libselinux.so plugin. Solution would be, to place some
is_selinux_enabled(3) calls into the module but due to the broken SELinux kernel
API, I am not sure how to do it correctly.

#332 known problem. have reported it various times in this thread.

Created attachment 137000 [details]
check whether selinux is available before trying to use it

Should fix the issues on systems not having SELinux.

Please try it on SELinux enabled systems.

Created attachment 137015 [details]
initng 0.6.8-3 spec file

- Fix up permissions of .so files
- Remove the rpath stuff that works out-of-the-box with recent cmake
- Include Enrico's patch to check if there is any selinux (Thanks a lot for
that one Enrico!)

ok, both initng and initng-ifiles are ACCEPTed

- remaining rpmlint warnings can be ignored
- basic checks on my system show that 'initng' works

So this means I'm free to commit initng against FE svn and request a build?
That's good news indeed!

Another completely different questions to the folks here: I just noticed that I
had a process nash-hotplug running 100% all the time. Is this something init(ng)
is supposed to kill? I find some rows in rc.sysinit which seems to do this...

Also, I noticed that I'm suddenly not member of cvsextras anymore (which I was
when I looked a few hours ago). I don't really know what went wrong this time,
but I guess I need someone to sponsor me again...

(In reply to comment #338)
> Also, I noticed that I'm suddenly not member of cvsextras anymore (which I was
> when I looked a few hours ago). I don't really know what went wrong this time,
> but I guess I need someone to sponsor me again...

Some accounts were removed from cvsextras recently, as described here:
http://fedoraproject.org/wiki/Extras/RemovedFromCvsextras

Ask on fedora-extras-list about getting cvsextras membership back.

(In reply to comment #339)
> Ask on fedora-extras-list about getting cvsextras membership back.

*sigh* It's a wonder any packages at all make it into FE.

On fedora-extras-list I got the suggestion that whoever sponsored me the last
time could do it again. Gauret, you around?

Yes, I'm around. But since Enrico reviewed your package, it would be best for
him to sponsor you.

Thanks Enrico. I'll commit to cvs and request a build as soon as I can (which I
need to do from home because of corporate firewall).

Also I'll include Enrico's selinux patch to upstreams.

Ok. initng and initng-ifiles are now built against FE devel. I also requested a
FC-5 branch for initng-ifiles.

My problem now is that initng allready has a FC-5 branch since I erroneously
imported initng 0.4.7 into cvs december last year. What do I do about this?
Simply replace the files in the FC-5 directory with proper ones? Or request a
new FC-5 branch?

I'd say simply replace the old files with the new ones.

(In reply to comment #344)
> I'd say simply replace the old files with the new ones.

Ok. I'll do that. Well, since initng and initng-ifiles now has been successfully
built in FE-devel, I guess it's time to close this ticket. A big thanks to
everyone that has been involved.

This is comment #345. This bug was open for 10 months and 12 days. Over and out.