Bug#848343: ITP: nrpe-ng -- The next generation Nagios Remote Plugin Executor
Package: wnpp Severity: wishlist Owner: Chris Boot * Package name: nrpe-ng Version : 0.1.2 Upstream Author : Chris Boot * URL : https://github.com/bootc/nrpe-ng * License : GPL Programming Lang: Python Description : The next generation Nagios Remote Plugin Executor This is a rewrite from the ground up of NRPE. This set of programs allows you to run Nagios check scripts on a remote host. Its main selling points are: - nearly drop-in NRPE replacement - real, proper TLS/SSL with keys/certificates - safer command-line argument passing - support for named command-line arguments I plain to maintain both the Debian package and continue upstream development with a colleague for my employer, Tiger Computing, on company time.
Re: Downscaling responsibilities
On 30/01/16 13:22, Enrico Zini wrote:
> Hello,
>
> it has been clear to me for a while that I am unable to stay on top of
> my Debian responsibilities.
Hi Enrico,
First of all, I'm sure I won't be the only person to want to thank you
for all that you have done for Debian (and beyond) so far. It's people
like you who have inspired me to join this community. I totally
understand that you want to scale back on how much you're responsible for.
> I have now decided to hit the reset button and end this situation. I'm
> going to orphan most of my packages, and radically scale down the
> complexity of the web services I'm stuck maintaining.
>
> I'm writing this mail so that you'll know what is happening when you see
> my name disappearing from packages like debtags, apt-xapian-index,
> polygen and so on, and when you see features disappearing from
> debtags.debian.net, nm.debian.org, contributors.debian.org and
> sso.debian.org.
I guess the bit I don't follow is removing features from various
services, but carrying on maintaining them.
I realise that with packages one can RFA or totally Orphan them and make
it obvious to other parties that a new maintainer is required. It feels
like perhaps that's lacking for some of the Debian infrastructure services.
While I don't feel I can realistically volunteer to maintain any of the
things you are trying to orphan, I also had no real idea that this was
on the cards. I'm sure I'm not the only one.
Do we need a WNP{Services} to improve the visibility of this kind of thing?
Cheers,
Chris
--
Chris Boot
bo...@debian.org
GPG: 8467 53CB 1921 3142 C56D C918 F5C8 3C05 D9CE
signature.asc
Description: OpenPGP digital signature
Re: ppp plugins and dependencies
On 07/06/15 11:26, Chris Boot wrote:
[...]
> One of the first tasks on my list is to resolve the issue with
> dependencies and ABI compatibility surrounding the building of ppp
> plugins.
[...]
Hi folks,
During this week's Mini-debconf in Cambridge I have worked a lot on ppp
and I believe that I have found a solution to the problem of managing
ppp's ABI compatibility, including detecting and triggering rebuilds of
packages that build plugins for pppd.
In short, my solution involves manipulating the debian revision of the
package version to include an ABI version field. A new dh_ppp helper
script can inject appropriate Depends or Breaks dependencies into
packages that use it.
I have just uploaded the new version to experimental for further testing
and feedback.
For some packages that provide plugins, the required change boils down
to just adding "--with ppp" to the existing "dh $@" invocation. For
packages like network-manager that would like to use Breaks rather than
Depends, you also need to override_dh_ppp and run "dh_ppp --breaks",
then ensure that "Breaks: ${misc:Breaks}" appears in the control file.
More information about my scheme and the helper tools is available from:
README.source for ppp:
http://anonscm.debian.org/cgit/collab-maint/pkg-ppp.git/tree/debian/README.source?h=develop&id=dfac4f63a7cab9472da3cc5f17ed3c500a83712a
README.Debian for ppp-dev:
http://anonscm.debian.org/cgit/collab-maint/pkg-ppp.git/tree/debian/ppp-dev.README.Debian?h=develop&id=dfac4f63a7cab9472da3cc5f17ed3c500a83712a
The commit that introduces this is:
http://anonscm.debian.org/cgit/collab-maint/pkg-ppp.git/commit/?h=develop&id=dfac4f63a7cab9472da3cc5f17ed3c500a83712a
I will shortly start preparing patches for the packages listed below
that build ppp plugins and submit them to the BTS.
I would very much appreciate any feedback or questions about the scheme.
> Affected maintainers and source packages:
>
> Christoph Biedl
>pptpd
>
> Debian FreeSmartphone.Org Team
>fso-gsmd
>
> Jan-Michael Brummer
>isdnutils (U)
>
> Michael Biebl
>network-manager (U)
>network-manager-pptp (U)
>
> Rico Rommel
>fso-gsmd (U)
>
> Rolf Leggewie
>isdnutils
>
> Sebastian Reichel
>fso-gsmd (U)
>
> Simon Busch
>fso-gsmd (U)
>
> Sjoerd Simons
>network-manager (U)
>
> Utopia Maintenance Team
>network-manager
>network-manager-pptp
>
--
Chris Boot
deb...@bootc.net
GPG: 8467 53CB 1921 3142 C56D C918 F5C8 3C05 D9CE
signature.asc
Description: OpenPGP digital signature
Re: ppp plugins and dependencies
Hi all,
I'm emailing again because I realise I got the per-package QA email
addresses all wrong, but also because I don't think we came to any real
resolution on this.
My original message:
On 07/06/15 11:26, Chris Boot wrote:
> Hi all,
>
> Apologies for the long email, but there's a lot to discuss on the topic.
>
> Marco d'Itri and I recently agreed that I would take over maintenance of
> ppp. Thanks for all your hard work over the years keeping this package
> going, Marco.
>
> One of the first tasks on my list is to resolve the issue with
> dependencies and ABI compatibility surrounding the building of ppp
> plugins. Several packages in the archive use the ppp-dev package to help
> them build ppp plugins that are loaded into pppd at run-time using
> dlopen(). The plugins are generally installed into a particular
> versioned directory on the filesystem (currently
> /usr/lib/pppd/${abi_version}/) where pppd looks for them by default.
>
> There is currently no mechanism for binary packages to depend on a
> particular ppp plugin ABI version being available, other than manually
> creating (and maintaining) dependencies such as:
>
> Depends: [...] ppp (>= 2.4.6~), ppp (<< 2.4.7~) [...]
>
> This is easy to get wrong (in fact, only network-manager-pptp appears to
> get it even nearly right), is a pain to maintain by hand, and is
> impossible for the release team to track sensibly with the transition
> tracker.
>
> I want to fix this. I'd like to upload the new upstream release 2.4.7
> soon, but when I do this all the packages that build plugins will
> silently break. Last time we went through this pain I had to work with
> the maintainers to get fixed versions uploaded; I know I can't get away
> with it this time either, but perhaps we can make it better for next
> time especially now that ppp has gained momentum upstream again.
>
> The main problem that I see is that there isn't a built-in mechanism for
> tracking such a situation, as far as I can tell. There aren't any shared
> libraries involved, so I don't have the benefit of sonames, symbols
> files or symbol versioning.
>
> It seems I the way to resolve this might well be by using a
> "pppapi-${upstream_version}" virtual package (or perhaps a newfangled
> versioned Provides / virtual package). This appears to work for Apache,
> Perl and PHP among others. The disadvantage of this is that currently
> pppd is not a Depends for all the packages that build ppp plugins,
> unlike Apache/Perl/PHP are for their plugins.
>
> network-manager only has pppd as a Recommends despite shipping a pppd
> plugin. fso-gsmd ships ppp2fsogsmd.so and yet has no dependency on pppd
> whatsoever. Clearly, either those packages need to change or I cannot
> rely on a Depends relationship on pppapi-$foo.
>
> A ppp plugin is no use on its own, but could easily be installed and
> simply go unused without pppd installed. What definitely doesn't work is
> a ppp plugin built for a different version of pppd - the result will
> either fail to load (due to pppd's built-in version check or being in
> the wrong directory) or crash/misbehave due to an ABI incompatibility.
>
> What's the best way to handle this?
>
> I was also considering writing a debhelper plugin and/or dh_ppp_plugin
> script to help with calculating the correct dependencies at build time,
> so that packages can simply invoke the script at build-time and Do The
> Right Thing. It could also be used to obtain the correct plugin
> directory to install plugins into, which seems like it would be useful
> for network-manager-pptp among others. Does this sound like a useful
> addition?
>
> Lastly, pppd has a built-in mechanism for checking that loaded plugins
> are built for the correct version of pppd. It does this by looking up a
> pppd_version symbol and comparing it against its own version. Currently
> this check is optional, and is used by all the listed packages (below)
> except fso-gsmd. If it's not used, pppd prints a warning and carries on
> regardless. I wonder about making this version check a requirement to
> avoid silent ABI breakage in future. Thoughts?
>
> I very much look forward to everyone's input on these issues.
>
> If you'd like to see what's cooking so far for the next upload of ppp,
> please feel free to have a poke around the 'develop' branch in
> collab-maint/pkg-ppp.git [1]. All comments gratefully received.
>
> 1:
> http://anonscm.debian.org/cgit/collab-maint/pkg-ppp.git/log/?h=develop
>
> Thanks,
> Chris
>
> Affected maintainers and source packages:
>
> Christoph Biedl
>pptpd
>
> Debian FreeSma
Re: ppp plugins and dependencies
On 07/06/15 11:49, Michael Biebl wrote: > Am 07.06.2015 um 12:26 schrieb Chris Boot: >> network-manager only has pppd as a Recommends despite shipping a pppd >> plugin. > > Small correction: network-manager has a versioned Recommends and a > versioned Breaks against ppp. > This is deliberate, since network-manager does not strictly need ppp. > The versioned Breaks is there to ensure that breakage due to a new ppp > upstream version with changed plugin path does not go unnoticed. > Unfortunately it seems ppp changes its plugin dir with every new > upstream release. Upstream ppp not only changes the plugin directory name but also the value of the VERSION #define, which goes into pppd_version that pppd looks at. I agree that network-manager doesn't strictly need pppd to operate, and a versioned Breaks is sufficient for this particular situation. This is why I wanted to strike up discussion about this - we need a way of dealing with these dependencies in such a way that works for everyone while causing the least disruption. [ from your follow-up ] > Sorry, the versioned Breaks: ppp (<< 2.4.6) obviously only helps too > ensure that a recent enough version of ppp is installed. It doesn't > guard against breakage due to new ppp upstream releases. > I guess I would have to add a Breaks: ppp (>= 2.4.7) for that > > Thinking about this, something like this could be useful for such > situations: > Breaks: != ppp-abi-version-2.4.6 > as counterpart to > Depends: = ppp-abi-version-2.4.6 We can't do that quite, but this could perhaps be achieved with a versioned virtual package such as (for ppp-2.4.7): Breaks: ppp-plugin-abi (<< 2.4.7), ppp-plugin-abi (>> 2.4.7) I don't see a != declared in the Debian Policy Manual section 7.1 either, which might have helped to condense this a bit. Nobody wants to manage these types of dependencies by hand though, do they? >> I was also considering writing a debhelper plugin and/or dh_ppp_plugin >> script to help with calculating the correct dependencies at build time, >> so that packages can simply invoke the script at build-time and Do The >> Right Thing. It could also be used to obtain the correct plugin >> directory to install plugins into, which seems like it would be useful >> for network-manager-pptp among others. Does this sound like a useful >> addition? > > Shipping a .pc file upstream to get the correct plugin directory (and > build flags) sounds like a useful addition. Upstream's build system is... archaic. It doesn't autotools and its configure script is hand-built and does its own templating. I don't think there's much scope for adding pkg-config upstream, sadly. > The question I would ask myself, is if ppp has to break the ABI for its > plugins with each new upstream release? Is there actually an ABI break > in 2.4.7? There probably doesn't need to be an ABI break for every version, but there is with 2.4.6 => 2.4.7 due to the addition of some variables. If this was a shared library it wouldn't necessitate a soname bump as it's essentially just a new symbol, but a plugin that happens to use this new symbol would break badly on an older pppd. Cheers, Chris -- Chris Boot bo...@bootc.net signature.asc Description: OpenPGP digital signature
ppp plugins and dependencies
Hi all,
Apologies for the long email, but there's a lot to discuss on the topic.
Marco d'Itri and I recently agreed that I would take over maintenance of
ppp. Thanks for all your hard work over the years keeping this package
going, Marco.
One of the first tasks on my list is to resolve the issue with
dependencies and ABI compatibility surrounding the building of ppp
plugins. Several packages in the archive use the ppp-dev package to help
them build ppp plugins that are loaded into pppd at run-time using
dlopen(). The plugins are generally installed into a particular
versioned directory on the filesystem (currently
/usr/lib/pppd/${abi_version}/) where pppd looks for them by default.
There is currently no mechanism for binary packages to depend on a
particular ppp plugin ABI version being available, other than manually
creating (and maintaining) dependencies such as:
Depends: [...] ppp (>= 2.4.6~), ppp (<< 2.4.7~) [...]
This is easy to get wrong (in fact, only network-manager-pptp appears to
get it even nearly right), is a pain to maintain by hand, and is
impossible for the release team to track sensibly with the transition
tracker.
I want to fix this. I'd like to upload the new upstream release 2.4.7
soon, but when I do this all the packages that build plugins will
silently break. Last time we went through this pain I had to work with
the maintainers to get fixed versions uploaded; I know I can't get away
with it this time either, but perhaps we can make it better for next
time especially now that ppp has gained momentum upstream again.
The main problem that I see is that there isn't a built-in mechanism for
tracking such a situation, as far as I can tell. There aren't any shared
libraries involved, so I don't have the benefit of sonames, symbols
files or symbol versioning.
It seems I the way to resolve this might well be by using a
"pppapi-${upstream_version}" virtual package (or perhaps a newfangled
versioned Provides / virtual package). This appears to work for Apache,
Perl and PHP among others. The disadvantage of this is that currently
pppd is not a Depends for all the packages that build ppp plugins,
unlike Apache/Perl/PHP are for their plugins.
network-manager only has pppd as a Recommends despite shipping a pppd
plugin. fso-gsmd ships ppp2fsogsmd.so and yet has no dependency on pppd
whatsoever. Clearly, either those packages need to change or I cannot
rely on a Depends relationship on pppapi-$foo.
A ppp plugin is no use on its own, but could easily be installed and
simply go unused without pppd installed. What definitely doesn't work is
a ppp plugin built for a different version of pppd - the result will
either fail to load (due to pppd's built-in version check or being in
the wrong directory) or crash/misbehave due to an ABI incompatibility.
What's the best way to handle this?
I was also considering writing a debhelper plugin and/or dh_ppp_plugin
script to help with calculating the correct dependencies at build time,
so that packages can simply invoke the script at build-time and Do The
Right Thing. It could also be used to obtain the correct plugin
directory to install plugins into, which seems like it would be useful
for network-manager-pptp among others. Does this sound like a useful
addition?
Lastly, pppd has a built-in mechanism for checking that loaded plugins
are built for the correct version of pppd. It does this by looking up a
pppd_version symbol and comparing it against its own version. Currently
this check is optional, and is used by all the listed packages (below)
except fso-gsmd. If it's not used, pppd prints a warning and carries on
regardless. I wonder about making this version check a requirement to
avoid silent ABI breakage in future. Thoughts?
I very much look forward to everyone's input on these issues.
If you'd like to see what's cooking so far for the next upload of ppp,
please feel free to have a poke around the 'develop' branch in
collab-maint/pkg-ppp.git [1]. All comments gratefully received.
1:
http://anonscm.debian.org/cgit/collab-maint/pkg-ppp.git/log/?h=develop
Thanks,
Chris
Affected maintainers and source packages:
Christoph Biedl
pptpd
Debian FreeSmartphone.Org Team
fso-gsmd
Jan-Michael Brummer
isdnutils (U)
Michael Biebl
network-manager (U)
network-manager-pptp (U)
Rico Rommel
fso-gsmd (U)
Rolf Leggewie
isdnutils
Sebastian Reichel
fso-gsmd (U)
Simon Busch
fso-gsmd (U)
Sjoerd Simons
network-manager (U)
Utopia Maintenance Team
network-manager
network-manager-pptp
--
Chris Boot
deb...@bootc.net
GPG: 8467 53CB 1921 3142 C56D C918 F5C8 3C05 D9CE
signature.asc
Description: OpenPGP digital signature
Re: logcheck rules for systemd
On 28/08/14 12:37, Ondřej Surý wrote: > Hey all, > > I have started to collect logcheck/ignore.d.server/systemd rules for > systemd: > > https://wiki.debian.org/systemd/logcheck > > I think it might be a good idea to fine tune the rules before submitting > them > for inclusion into logcheck default ruleset... Hi Ondřej, You may find it easier to bundle the logcheck rules with systemd itself rather than as part of logcheck-database. Debhelper has a dh_installlogcheck tool that you may find useful. In my opinion, packaging the logcheck rules with the program that generates the log messages makes more sense, as the rules can be more easily kept up to date with the generating program. HTH, Chris -- Chris Boot deb...@bootc.net GPG: 8467 53CB 1921 3142 C56D C918 F5C8 3C05 D9CE -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ff17f5.8010...@bootc.net
Bug#729885: ITP: squeezelite -- Lightweight headless Squeezebox emulator
Package: wnpp Severity: wishlist Owner: Chris Boot * Package name: squeezelite Version : 1.3 Upstream Author : Adrian Smith * URL : https://code.google.com/p/squeezelite/ * License : GPLv3 Programming Lang: C Description : Lightweight headless Squeezebox emulator Squeezelite is a small headless Squeezebox emulator. It is aimed at supporting high quality audio including USB DAC based output at multiple sample rates. It supports decoding PCM (WAV/AIFF), FLAC, MP3, Ogg, AAC, WMA and ALAC audio formats. It can also resample audio, which allows squeezelite to upsample the output to the highest sample rate supported by the output device. -- Chris Boot deb...@bootc.net GPG: 1DE8 6AB0 1897 A330 D973 D77C 50DD 5A29 FB09 signature.asc Description: OpenPGP digital signature
Re: Debian Mini-distro: how to recompile base-system and remove Java?
On 30 May 2006, at 09:12, Alexander Shishkin wrote: On 5/30/06, Chris Boot <[EMAIL PROTECTED]> wrote: Just make a list of everything you have installed and rebuild each package one-by-one until you've covered everything. I can't see where the problem is. In the real world (tm) building things by hand is not acceptable because of a) complicated build dependencies which you do not want to think about each time you rebuild world b) the amount of work, considering at least 6 architectures (in current slind) multiplied by the number of target packages (42 in current slind, and increasing). I mean, you typically want to build things according to their build- deps. Of course, but I'm just talking about getting a basic environment set up from scratch. I realise slind removes the need for that now, but... Chris -- Chris Boot [EMAIL PROTECTED] http://www.bootc.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Mini-distro: how to recompile base-system and remove Java?
On 30 May 2006, at 08:53, Alexander Shishkin wrote: On 5/30/06, Chris Boot <[EMAIL PROTECTED]> wrote: On 29 May 2006, at 23:53, Daniel Ruoso wrote: Yes, I can see that could be handy. I'm guessing SLIND is based on woody? No, it is based on testing/unstable. Host part is mostly sarge (it was in the 0.1 prerelease, now most of it is sid). Well ideally I'd like to have a complete system with the bare minimum number of patches required to make packages build & work on uclibc. Removing Java was an idea for a short-cut to get to that stage. What does Java have to do with compiling packages? gcc-3.3 depends on gettext which depends on fastjar which is built by gcc-3.4 If one cuts out Java, gettext is that much smaller and easier to build, and so is gcc. Simple really. Once again this is just a shortcut to get build-dependencies out of the way first. Once most of the packages are present this would be rebuilt to be the full package. Once you want the build-dependencies back, I tell you, it will be a pain you-know-where to put them in correct shape. And this is going to happen once you get to the point of compinig X11 stuff and glib/gtk. Just make a list of everything you have installed and rebuild each package one-by-one until you've covered everything. I can't see where the problem is. Regards, -- I am free of all prejudices. I hate every one equally. -- Chris Boot [EMAIL PROTECTED] http://www.bootc.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Mini-distro: how to recompile base-system and remove Java?
On 29 May 2006, at 23:53, Daniel Ruoso wrote: Em Seg, 2006-05-29 às 22:08 +0100, Chris Boot escreveu: SLIND sounds interesting indeed, I've been using a buildroot-built system for mine so it was difficult getting dpkg built in the first place, but I've got it mostly all going. All the arch-independent packages help a lot too. In fact, I want it to work as a native debian system. This way, buildroot causes a lot of problems (I think that's the motivation behind SLIND). And they already have a binary base system which is a hell lot of work already done... Mixing this with dpkg-cross, well... it's perfect :) So do I! I'm just using buildroot as a short-cut towards getting a basic debian base going. I know it's probably the wrong thing to do but it seemed a good idea at the time. The challange is to compile the other packages that compose the build-essential package list. With that, in theory, you can setup a buildd. That's what I'm aiming for as well, but unfortunately there's a hell of a lot of dependencies in all that lot! That's where SLIND helps more... the base system is already built. Yes, I can see that could be handy. I'm guessing SLIND is based on woody? There seem to be ways to build a minimal gcc built into the build scripts, but I can't seem to be able to trigger these to successfully build a compiler. It keeps dying with: I think it's possible to just use dpkg-buildpackage -auclibc-i386 and get a functional package (after some changes, probably)... I'm trying to stay as close as I can from the stock debian packages. Well ideally I'd like to have a complete system with the bare minimum number of patches required to make packages build & work on uclibc. Removing Java was an idea for a short-cut to get to that stage. * libgdbm3 * libdb4.2 (I'm very near on finishing this one) * perl (which depends on the two libs above) I've built perl without having either of the two prerequisites installed, works for most things and satisfies lots of dependencies! :-) As I said, I aim to have a standard debian machine, so I do want to deal with the dependencies correctly to have a real package. Once again this is just a shortcut to get build-dependencies out of the way first. Once most of the packages are present this would be rebuilt to be the full package. Maybe we could join forces to speed things along? Sure... Actually, I think we should both join forces to emdebian, which is doing a great job... I've joined #emdebian on IRC but there's not a lot of activity. Sounds like a good idea though, and sounds like they could do with a hand. What I do think it would be really nice is to have a "contrib-builds" SLIND repository (like backports do). This would make things easier for sharing this effort. Many thanks, Chris -- Chris Boot [EMAIL PROTECTED] http://www.bootc.net/
Re: Debian Mini-distro: how to recompile base-system and remove Java?
On 29 May 2006, at 18:32, Daniel Ruoso wrote: Em Seg, 2006-05-29 às 13:49 +0100, Chris Boot escreveu: I'm starting work again on a thinned-down version of Debian I call PicoDebian. The idea of this new version is to replace glibc with uClibc, and generally slim down various packages to fit nicely in confined environments. This need is starting to become more and more evident... I'm working on this also, using SLIND as toolchain and initial bootstrap (which, actually, is saving the day). It's good to find someone in the same boat! SLIND sounds interesting indeed, I've been using a buildroot-built system for mine so it was difficult getting dpkg built in the first place, but I've got it mostly all going. All the arch-independent packages help a lot too. Can anybody give me a helping hand in building a basic base-system that I can use to recompile other packages? How about removing all the Java dependencies from gcc-3.3, gettext, et al? The challange is to compile the other packages that compose the build-essential package list. With that, in theory, you can setup a buildd. That's what I'm aiming for as well, but unfortunately there's a hell of a lot of dependencies in all that lot! I'm working locally on this (my bandwidth is poor, so it's hard to me to upload partial progress). The uclibc-i386 packages missing to me are: * gcc There seem to be ways to build a minimal gcc built into the build scripts, but I can't seem to be able to trigger these to successfully build a compiler. It keeps dying with: stage1/xgcc -Bstage1/ -B/usr/i486-linux/bin/ -g -O2 -DIN_GCC -W - Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes - Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H - DGENERATOR_FILE -o gengenrtl \ gengenrtl.o ../libiberty/libiberty.a ./gengenrtl -h > tmp-genrtl.h /bin/sh: line 1: ./gengenrtl: No such file or directory * libgdbm3 * libdb4.2 (I'm very near on finishing this one) * perl (which depends on the two libs above) I've built perl without having either of the two prerequisites installed, works for most things and satisfies lots of dependencies! :-) I'm working with sarge, as it's easier to deal with a frozen target, but after that 4 packages, we have the way to setup a buildd and start natively building packages. Yup, same here, Sarge base with a few patched packages. Maybe we could join forces to speed things along? Many thanks, Chris -- Chris Boot [EMAIL PROTECTED] http://www.bootc.net/
Debian Mini-distro: how to recompile base-system and remove Java?
Hi all, I'm starting work again on a thinned-down version of Debian I call PicoDebian. The idea of this new version is to replace glibc with uClibc, and generally slim down various packages to fit nicely in confined environments. I've managed to build several of the base-system packages already, mostly forcing dependencies to be ignored as a start, but there are some that I'm not entirely sure how to get around. For example, a huge number of packages depend on gettext. While I've installed a local version from vanilla upstream source, this isn't good enough! The gettext source package itself would be better, but requires Java related tools to build. I'd rather keep Java and other such less-used stuff out of my distro, which also means thinning down GCC so it no longer requires quite so much to build, and no longer building Java. Can anybody give me a helping hand in building a basic base-system that I can use to recompile other packages? How about removing all the Java dependencies from gcc-3.3, gettext, et al? Many thanks, Chris -- Chris Boot [EMAIL PROTECTED] http://www.bootc.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
