Yo,
After some delay[0] I have uploaded a new version of module-init-tools
to http://www.kerneltools.org/
This release mostly has a bunch of build fixes, some memory leakage
cleanups that will benefit systems that actually run out of memory
(embedded, etc.) and various other things in the changelog.
I plan on a non-pre release soon but need a bit more time to go over the
current code and look at the tests, etc. Patches welcome, as usual.
Jon.
[0] Suspected mononucleosis...oh such a joyful experience :-)
Sergey Vlasov wrote:
> I see that you have merged some patches which change depmod.8.
> However, this file is generated from doc/depmod.sgml, which was not
> changed appropriately.
Ah. A valid point - Luiz, do you want to redo your patch or I can take a
look at the SGML source myself.
Jon.
On Thu, 22 Feb 2007 09:52:20 -0500
Jon Masters <[email protected]> wrote:
| Sergey Vlasov wrote:
|
| > I see that you have merged some patches which change depmod.8.
| > However, this file is generated from doc/depmod.sgml, which was not
| > changed appropriately.
|
| Ah. A valid point - Luiz, do you want to redo your patch or I can take a
| look at the SGML source myself.
Urgh, I didn't know that, sorry.
I can redo my patch, but shouldn't the manpages be removed from the
repository then?
--
Luiz Fernando N. Capitulino
Luiz Fernando N. Capitulino wrote:
> On Thu, 22 Feb 2007 09:52:20 -0500
> Jon Masters <[email protected]> wrote:
>
> | Sergey Vlasov wrote:
> |
> | > I see that you have merged some patches which change depmod.8.
> | > However, this file is generated from doc/depmod.sgml, which was not
> | > changed appropriately.
> |
> | Ah. A valid point - Luiz, do you want to redo your patch or I can take a
> | look at the SGML source myself.
>
> Urgh, I didn't know that, sorry.
>
> I can redo my patch, but shouldn't the manpages be removed from the
> repository then?
I think it's like the configure/Makefile.in situation. These files
should technically not be in the repo either (and you removed them in
your tree) but I re-added them because people have an expectation that:
./configure
make
will do something "out of the box". I just need to re-run
autoconf/automake periodically to keep the files up to date. It's a
pain, but I'll script that in due course alongside rebuilding the man
pages - actually, this is probably just a convenient makefile target.
So if you want to redo the patch against those man pages, I'll
regenerate them prior to pushing the next update. We'll leave it as it
is until then because the update (IIRC) was just to re-order existing
content so it's not like we have to push this with urgency.
Jon.
On Feb 23 2007 10:41, Jon Masters wrote:
>
> I think it's like the configure/Makefile.in situation. These files should
> technically not be in the repo either (and you removed them in your tree) but I
> re-added them because people have an expectation that:
>
> ./configure
> make
>
> will do something "out of the box".
Out of the box perhaps if it is the .tar.bz2 archive, but the same does not
always hold for CVS repos, much less SVNs [random guess on svn]. He who pulls
from a developer tree mostly knows to run 'autogen.sh' or 'autoreconf -fi'
beforehand.
Jan
--
Jan Engelhardt wrote:
> Out of the box perhaps if it is the .tar.bz2 archive, but the same does not
> always hold for CVS repos, much less SVNs [random guess on svn]. He who pulls
> from a developer tree mostly knows to run 'autogen.sh' or 'autoreconf -fi'
> beforehand.
You know what, you're right of course. Ok, I'm taking those back *out*
of the repo in the next update and then will have a script generate
these for the tarball. That does sound like the right thing.
Thanks!
Jon.