Adding init.d dependencies mostly done, next step is testing (Was: Dependency based boot sequencing reaches 2/3 threshold)

[Petter Reinholdtsen]

I am happy to report that another mile stone for the release goal of
making it possible to enable dependency based boot sequencing is
reached.

98% of all packages with init.d scripts now have dependency
information in Sid.  Most of the remaining 17 packages are being
removed from the archive, and will probably be fixed that way.  All
base and desktop packages and include the dependency information.  The
updated packages are propagating slowly into Lenny, allowing more
users to test dependency based boot sequencing.

Now the dependency information in the scripts need to be tested and
used to detect errors in them.  Also, the Debian policy should be
updated to document that such headers should be included, and a text
proposal need to be written for this.  Also, it would be nice to
adjust insserv to work with file-rc as well as the current
implementation handling sysv-rc.  It would be useful to check
automatically all init.d scripts in the archive for dependency loops,
perhaps regularly.

I've used dependency based init.d sequencing in my sid chroot for
about a year now, and it has worked just fine.  To test it yourself,
see the talk I gave at at Debconf, linked in from the status wiki
page, http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot>.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Adding init.d dependencies mostly done, next step is testing (Was: Dependency based boot sequencing reaches 2/3 threshold)

[Lucas Nussbaum]

On 09/04/08 at 11:26 +0200, Petter Reinholdtsen wrote:
> Now the dependency information in the scripts need to be tested and
> used to detect errors in them.  Also, the Debian policy should be
> updated to document that such headers should be included, and a text
^^ must?
> It would be useful to check
> automatically all init.d scripts in the archive for dependency loops,
> perhaps regularly.

How do you do that currently? Couldn't you use the lintian lab in
gluck:/org/lintian.debian.org/laboratory/ for that?
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

[Mike Hommey]

On Wed, Apr 09, 2008 at 03:34:18AM -0700, Josh Triplett wrote:
(...)
> Thus, I wrote Dolt, a drop-in replacement for libtool's compilation
> mode.  Dolt runs any necessary system-specific or
> configuration-specific logic as part of configure, writes out a simple
> shell script "doltcompile"[1], and substitutes it for libtool in the
> automake variables LTCOMPILE and LTCXXCOMPILE.  If you use automake,
> autoconf, and libtool, then using Dolt just requires two steps:
(...)

Does it inherit that bad habit libtool has with reordering flags,
such as -Wl,--as-needed ?

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Adding init.d dependencies mostly done, next step is testing

[Petter Reinholdtsen]

[Lucas Nussbaum]
>> updated to document that such headers should be included, and a text
> ^^ must?
I am all for requiring it, yes. :)

>> It would be useful to check
>> automatically all init.d scripts in the archive for dependency loops,
>> perhaps regularly.
>
> How do you do that currently? Couldn't you use the lintian lab in
> gluck:/org/lintian.debian.org/laboratory/ for that?

So far, I have discovered loop using testing or reports from others
doing testing, and then figured out how to resolve them by looking at
the dependency graph generated by
/usr/share/insserv/check-initd-order.  I have nod been able to look at
automatic checking so far.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Announcing Dolt, a drop-in Libtool replacement which cutsbuild times in half

[Josh Triplett]

> On Wed, Apr 09, 2008 at 03:34:18AM -0700, Josh Triplett wrote:
> (...)
>> Thus, I wrote Dolt, a drop-in replacement for libtool's compilation
>> mode.  Dolt runs any necessary system-specific or
>> configuration-specific logic as part of configure, writes out a simple
>> shell script "doltcompile"[1], and substitutes it for libtool in the
>> automake variables LTCOMPILE and LTCXXCOMPILE.  If you use automake,
>> autoconf, and libtool, then using Dolt just requires two steps:
> (...)
> 
> Does it inherit that bad habit libtool has with reordering flags,
> such as -Wl,--as-needed ?

doltcompile does not reorder any flags passed to it; it merely
replaces the .lo filename with the appropriate object filename and
adds any necessary additional compiler flags (such as -fPIC -DPIC) to
the end of the command line.

dolt doesn't currently cover linking; libtool still does that.  Since
-Wl,--as-needed appears at link time, libtool may still mess with it.
If and when I create a doltlink, it will not reorder flags either.

- Josh Triplett



signature.asc
Description: OpenPGP digital signature

Re: help required regarding bug - #436681

[Bernd Zeimetz]

hi,

>  
>"Debian Bug report logs - 
> #436681
> backuppc: Web interface password 
> publicly visible "
>link 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=436681

If you give the page a close look you can see, that the bug was closed
last year, so you should probably choose another bug to fix.

To fix a current bug, you should install Debian testing (called Lenny,
as it is the upcoming Dbeian release) instead of the stable version
(Etch). Then the best (for Debian) would be if you have a look at the
release critical bugs, and bugs which are marked as a release goal, as
they're most important to be fixed.

So have a look at
http://bts.turmzimmer.net/details.php?bydist=any&sortby=packages&ignhinted=on&ignclaimed=on&ignpending=on&ignpatch=on&ignmerged=on&igncontrib=on&ignnonfree=on&ignbritney=on&ignotherfixed=on&ipv6=on&new=7&refresh=1800
which should give you a nice list of bugs to work on.

Interesting to read for you is probably
http://www.debian.org/doc/maint-guide/ which gives a nice overview about
the packaging and files in the debian directory. Chances are good that
you'll have to work on them.

If you've prepared a patch/fix for a bug, just let me know and I'll
review and upload it.


Best regards,

Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

[Josh Triplett]

Many packages use GNU autotools (automake and autoconf) to build, to
the point that "./configure && make" represents one of the most common
build procedures for Free Software packages.  Libraries using
autotools typically use GNU Libtool, partly because it works on almost
any system and partly because autotools makes it difficult to do
otherwise.  Packages which use these libraries sometimes use libtool
as well.

Yet for many of these libraries and other packages, more than half of
the build time goes into running the libtool shell script.

Libtool knows how to handle libraries for umpteen different systems,
including many ancient systems that have terrible shared library
support.  It has some extensive shell script logic to figure out how
to build libraries for your system, and how to compile objects that go
in those libraries.  This logic does an amazingly impressive job of
coping with adverse conditions.  However, this logic all lives in an
~8500 line, ~250kB shell script, which runs *every single time you
compile a source file*.

This does not do wonders for performance.

Meanwhile, modern systems such as GNU/Linux have reasonable library
mechanisms, and need relatively little of the machinery in libtool.
On these common systems, it would significantly improve build times to
avoid running that libtool machinery for every compilation.

Thus, I wrote Dolt, a drop-in replacement for libtool's compilation
mode.  Dolt runs any necessary system-specific or
configuration-specific logic as part of configure, writes out a simple
shell script "doltcompile"[1], and substitutes it for libtool in the
automake variables LTCOMPILE and LTCXXCOMPILE.  If you use automake,
autoconf, and libtool, then using Dolt just requires two steps:

1) add "DOLT" after the call to LT_INIT, AC_PATH_LIBTOOL, or
   AM_PATH_LIBTOOL in your configure.ac or configure.in script, and
2) append dolt.m4 to your project's acinclude.m4.

For any system Dolt does not support, it will transparently fall back
to libtool.

dolt.m4 takes up less than 4kB; it writes out a minimal doltcompile
script which never forks except to run the compiler or to mkdir the
.libs directory if it doesn't already exist.  I have tested it with
various projects, and benchmarked[2] its performance against the same
projects using only libtool.  Results:

kdelibs without dolt: 8m6.115s
kdelibs with dolt:3m50.065s

gtk+-2.0 without dolt: 2m31.825s
gtk+-2.0 with dolt:1m33.858s

libx11 without dolt: 1m50.163s
libx11 with dolt:0m53.417s

libxml2 without dolt: 0m25.722s
libxml2 with dolt:0m19.576s

dbus without dolt: 0m20.062s
dbus with dolt:0m8.940s

I have attached a snapshot of dolt.m4 for convenience.  You can also
obtain the current version of Dolt from Git with:

git clone git://svcs.cs.pdx.edu/git/dolt

or download a snapshot tarball from
.

Please try Dolt with your project, and see if you get comparable
performance improvements.  If you want to make Dolt replace libtool on
your system, feel free to send me a patch to dolt.m4; just remember
the basic tenet that any logic must run at configure time, not build
time.  You can figure out what compiler flags libtool uses by running
"touch dummy.c && libtool --mode=compile gcc -c dummy.c -o dummy.lo";
that will print two compiler command lines, one for the shared object
and one for the static object.

Future directions:
* Support GNU/Linux on architectures other than x86 and x86-64.  I
  think most will work with exactly the same compiler flags, but I
  didn't want to add any architecture I couldn't test.
* Support other systems.
* Possibly try to run libtool on a dummy source file at configure time
  to figure out the necessary flags to use when building library
  objects, but that seems error-prone.
* Replace libtool --mode=link.
* Replace libtool --mode=install.
* Optionally stop installing .la files.
* Make dolt.m4's output of doltcompile cleaner.

- Josh Triplett

[1] "doltcompile" stands for "do ltcompile"; the alternate reading
"dolt compile" led to the name "dolt".

[2] General testing methodology:
* Run ./configure && make && make clean, to make sure it builds and to get
  everything cached.
* Get the "before" time: time make >/dev/null 2>&1
* Remove and re-extract the source.
* Add dolt.m4 to acinclude.m4 and add DOLT to configure.in or configure.ac.
* autoreconf -v -f -i && ./configure && make && make clean, to
  make sure it still builds and to get everything cached again.
* Get the "after" time: time make >/dev/null 2>&1
dnl dolt, a replacement for libtool
dnl Copyright © 2007-2008 Josh Triplett <[EMAIL PROTECTED]>
dnl Copying and distribution of this file, with or without modification,
dnl are permitted in any medium without royalty provided the copyright
dnl notice and this notice are preserved.
dnl
dnl To use dolt, invoke the DOLT macro immediately after the libtool macros.
dnl Optionally, copy this file into acinclud

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

[Ralf Wildenhues]

Hello Josh,

can we limit followups to a subset of this impressive array of mailing
lists?  Say, to <[EMAIL PROTECTED]>?  That would be readable at
.
Thanks.

* Josh Triplett wrote on Wed, Apr 09, 2008 at 12:34:18PM CEST:
> Libtool knows how to handle libraries for umpteen different systems,
> including many ancient systems that have terrible shared library
> support.  It has some extensive shell script logic to figure out how
> to build libraries for your system, and how to compile objects that go
> in those libraries.  This logic does an amazingly impressive job of
> coping with adverse conditions.  However, this logic all lives in an
> ~8500 line, ~250kB shell script, which runs *every single time you
> compile a source file*.
> 
> This does not do wonders for performance.

Curious: can you please state which Libtool version you timed against,
and if not 2.2.x, redo timing against 2.2.2?  Not that I expect wonders,
but I expect something better than what you measured.

Thanks,
Ralf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#475151: ITP: libapache2-reload-perl -- reload changed modules in a mod_perl2 environment

[Niko Tyni]

Package: wnpp
Severity: wishlist
Owner: Niko Tyni <[EMAIL PROTECTED]>

* Package name: libapache2-reload-perl
  Version : 0.10
  Upstream Author : Matt Sergeant <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Apache-Reload/
* License : The Apache Software License, Version 2.0
  Programming Lang: Perl
  Description : reload changed modules in a mod_perl2 environment

"Apache2::Reload" reloads modules that change on the disk.

When Perl pulls a file via "require", it stores the filename in the
global hash %INC. The next time Perl tries to "require" the same file,
it sees the file in %INC and does not reload from disk. This module's
handler can be configured to iterate over the modules in %INC and reload
those that have changed on disk or only specific modules that have
registered themselves with "Apache2::Reload". It can also do the check
for modified modules, when a special touch-file has been modified.

This package is needed for the recent upstream release candidate of
libapache2-mod-perl2 (2.0.4 rc1, "Works with Perl 5.10").

The source package will probably be called libapache-reload-perl, as
it's distributed on CPAN as Apache-Reload and contains modules for both
Apache 1 and 2.

There's a libapache-reload-perl package in Etch, but it has since been
removed because it only contained the Apache 1 module at that time.

This will be packaged under the umbrella of the Debian Perl Group
(unless the previous libapache-reload-perl maintainer, Don Armstrong,
particularly wants it for himself.)

Cheers,
-- 
Niko Tyni   [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#475190: ITP: shotdetect -- shots and scenes detection software

[Johan MATHE]

Package: wnpp
Severity: wishlist
Owner: Johan MATHE <[EMAIL PROTECTED]>


* Package name: shotdetect
  Version : 1.0.85
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://shotdetect.nonutc.fr/
* License : LGPL
  Programming Lang: (C++)
  Description : shots and scenes detection software

 Shotdetect is able to detect shots and scenes boundaries in a movie. It 
generates thumbs and an XML output file. It's based on the ffmpeg libraries, so 
able to read a lot of different formats.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24.2--std-ipv4-32
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Configuration Packaging System

[Erik Rose]

Anders Kaseorg and I created a system of CDBS modules (which we've  
tentatively packaged as the config-package-dev package) for creating  
Debian configuration packages.


I'm designing a hosting service at Penn State which involves  
configuring a big pile of Debian machines (https://weblion.psu.edu/trac/weblion/wiki/WebLionHosting 
). I was midway through inventing/accumulating something very similar  
when I discovered your framework, and I now plan to use it for almost  
all our config packages. Bravo!


Please count my vote toward polishing dpkg's divert behavior, adding  
config hooks, or whatever the best solution turns out to be for  
officially supporting config packages. This is too useful a feature to  
leave teetering on the edge of acceptance!


Erik Rose
Core Developer and General Incorrigible
The WebLion Group
Pennsylvania State University


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RFS: link-grammar 4.3.2

[Ken Bloom]

Could someone sponsor the latest version of link-grammar, version
4.3.2, for which I have uploaded at
http://lingcog.iit.edu/~bloom/link-grammar/

Thanks in advance.

--Ken

-- 
Ken (Chanoch) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/


signature.asc
Description: Digital signature

Bug#475335: ITP: libbio-mage-perl -- Container module for classes in the MAGE package: MAGE

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy <[EMAIL PROTECTED]>

  Package name: libbio-mage-perl
  Version : 20030502.3
  Upstream Author : © 2001-2006 The MicroArray Gene Expression Database Society 
(MGED)
  URL : http://mged.sourceforge.net/
  License : MIT/X11
  Programming Lang: Perl
  Description : Container module for classes in the MAGE package: MAGE

 MAGE-TAB (MicroArray Gene Expression Tabular) format is a standard from the
 Microarray Gene Expression Data Society (MGED). This package contains Perl
 modules in the Bio::MAGE hierarchy to manipulate MIAME-compliant (Minimum
 Information About a Microarray Experiment) records of microarray ("DNA chips")
 experiments.
 .
  The Bio::MAGE module contains the following Bio::MAGE classes:
* NameValueType
* Extendable
* Identifiable
* Describable

Although I have Debian tasks of higher priority, I made this package at work 
because
I need it for work.

I sent a copy of this email to the Debian Perl team: this package is perl-only 
and
and available from SourceForge and CRAN. If you are interested by maintaining 
it in
your repository, just hijack it :) I have upladed it to Mentors:

http://mentors.debian.net/debian/pool/main/l/libbio-mage-perl/

Have a nice day,

-- 
Charles Plessy
Debian-Med packaging team.
Wako, Saitama, Japan



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Release: InetBoot(GRUB+BuildRoot)

[Kuniyasu Suzaki]

Dear,

InetBoot(GRUB+BuildRoot) "netfs" version is released.
  HP:http://openlab.jp/oscircular/inetboot/
  Guide-PDF: 
http://openlab.ring.gr.jp/oscircular/inetboot/InetBoot-netfs080409-E.pdf

InetBoot(GRUB+BuildRoot) loads a kernel from a ISO(KNOPPIX/Xenoppix) file on 
HTTP 
server and boots the OS(KNOPPIX/Xenoppix).
You can designate the URL of KNOPPIX5.3.1. Have fun!


InetBoot is a bootloader which gets kernel and disk image via Internet
and boots form it. "netfs" version boots from a ISO file of KNOPPIX/VMKnoppix 
which is uploaded on a HTTP server. The sample bootable CD (5MB) can 
boot 3 types of KNOPPIX and 5 types of VMKnoppix.
  * 3 types of KNOPPIX(511,501, 402) and 
  * 5 types of VMKnoppix (Xen: 3.2.0, 3.1.1, 3.1.0, 3.0.4.1, 3.0.4)
InetBoot will boot an ISO file which is based on KNOPPIX 4.0.2 or
later. (CAUTION: It doesn't not support special customization. Refer
known problems.)

### Special Feature ###
InetBoot loads a kernel form a HTTP server. Since it doesn't use
BOOTP and TFTP which are used for normal network boot (PXE), InetBoot
is not limited on LAN environment. It also doesn't use a satefull NFS
server for a root file system. InetBoot uses stateless HTTP for a root
file system and enables the dynamic load lancing.

All you have to designate the URL of KNOPPIX at the boot menu and you
can boot the KNOPPIX from Internet. It means you don't need to burn a
CD/DVD for new KNOPPIX.

InetBoot is consisted of GRUB and BuildRoot (BusyBox). It is not
simple boot loader. It boots a mini Linux, sets up the network,
obtains a new kernel form a HTTP server, re-masters the miniroot,
reboots with "kexec". The new OS boots with loopback-mounting the
ISO file at HTTP server with httpfs.

### Usage ###
Download "linux" and "minirt.gz" of BuildRoot and set up GRUB.
Only you have to designate the URL of ISO file of KNOPPIX at GRUB menu.

Ex: Normal KNOPPIX
  kernel /boot/grub/linux netdir=http://***/knoppix.iso ramdisk_size=10 
lang=ja vga=normal
  initrd /boot/grub/minirt.gz

Ex: VMKnoppix. Add "bootxen=1" option.
  kernel /boot/grub/linux netdir=http://***/Xenoppix.iso bootxen=1 
ramdisk_size=10 lang=ja vga=normal
  initrd /boot/grub/minirt.gz

The sample bootable-CD includes some URLs of ISO file. They are load
balanced by SLB(Global Server Load Balance) and InetBoot finds a
suitable site automatically form 3 sites in US, 3 sites in EU, and 7
sites in Japan.
* knoppix511 (linux 2.6.19)
* knoppix501 (linux 2.6.17)
* knoppix402 (linux 2.6.12)
* VMKnoppix (Xen3.2.0+Linux 2.6.18)
* VMKnoppix (Xen3.1.1+Linux 2.6.18)
* VMKnoppix (Xen3.1.0+Linux 2.6.18)
* VMKnoppix (Xen3.0.4.1+Linux 2.6.18) Oprofile
* VMKnoppix (Xen3.0.4) +Linux 2.6.18

### Detail of Implementation ###
The designated URL at GRUB Menu is passed to BuildRoot as a kernel option.
On the BuildRoot (BusyBox) do the following steps.
   1) Set up the network by "udhcp" 
   2) Mount the ISO file by "httpfs"
   3) Extract the kernel
   4) Re-master the miniroot. (The new kernel will mount ISO file with 
"httpfs".)
   5) Reboot by "kexec" (Warm Boot)
The download kernel boots with the re-mastered miniroot.
   1)  Mount the ISO file at /cdrom with "httpfs"
   2)  Pass the control to "init" and boots as the normal KNOPPIX
After that it works as the normal KNOPPIX.

### Known Problems ###
* Depend on Network Interface.
InetBoot sets up Network Interface TWICE (in BuildRoot and
downladed new kernel). Both of them have to set up a suitable
driver.
* Depend on the situation of server and network.
  + It is sensitive of network latency and load of the server because
the root file system is mounted by "httpfs".
  + The situation may change by rebooting because the load balancer
(GSLB) may select another site.
* InetBoot can not applied a deeply re-mastered KNOPPIX.
  + InetBoot has to know the boot procedure to re-master miniroot.
* Some HTTP servers have 2GB limitation. 
  + "httpfs" can not mount DVD ISO file from the servers.

### Related URL ###
[1] BuildRoot: http://buildroot.uclibc.org/
[2] httpfs: http://httpfs.sourceforge.net/
[3] kboot: http://kboot.sourceforge.net/
[4] Linux Symposium 08 BOF: OS Circular,
 http://www.linuxsymposium.org/2008/view_abstract.php?content_key=231

### Download ###
Sample Bootable CD (ISO file) 
  The included UPLs are temporal service. Please designate your favorite URL.
  
http://www.ring.gr.jp/archives/linux/oscircular/iso/inetboot-netfs-20080409-us.iso
  MD5: 1c32b27fbe93903ee2decaec220cfbc6
kernel and miniroot of BuildRoot
  
http://www.ring.gr.jp/archives/linux/oscircular/iso/inetboot-netfs-20080409/linux
  
http://www.ring.gr.jp/archives/linux/oscircular/iso/inetboot-netfs-20080409/minirt.gz

### Acknowledgement ###