Bug 173459
|
Description
Daniel Malmgren
2005-11-17 07:16:35 UTC
*** 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. |