Sourcing init-functions
Hello, several init scripts use such a fragment for sourcing init-functions: if ! [ -x "/lib/lsb/init-functions" ]; then . /lib/lsb/init-functions else echo "E: /lib/lsb/init-functions not found, lsb-base (>= 3.0-6) needed" exit 1 fi What is the reason to bail out if the execute bit is set? Or should I bug report these packages? Regards hmw -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sourcing init-functions
Hi Michael, On Sat, Jan 16, 2010 at 10:57:48AM +0100, Michael Welle wrote: > several init scripts use such a fragment for sourcing init-functions: > if ! [ -x "/lib/lsb/init-functions" ]; then > . /lib/lsb/init-functions > else > echo "E: /lib/lsb/init-functions not found, lsb-base (>= 3.0-6) needed" > exit 1 > fi What do you mean, "several"? What init scripts use this fragment? No init scripts on any of my systems do this. > What is the reason to bail out if the execute bit is set? Or should I > bug report these packages? Looks like nonsense to me. I think you should file a bug. For one thing, any init script that needs lsb-base (>= 3.0-6) *should depend on lsb-base (>= 3.0-6)*, not throw an error if it's not installed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Sourcing init-functions
On Sat, Jan 16, 2010 at 10:57:48AM +0100, Michael Welle wrote: > Hello, > > several init scripts use such a fragment for sourcing init-functions: > > if ! [ -x "/lib/lsb/init-functions" ]; then > . /lib/lsb/init-functions > else > echo "E: /lib/lsb/init-functions not found, lsb-base (>= 3.0-6) needed" > exit 1 > fi > > What is the reason to bail out if the execute bit is set? Or should I > bug report these packages? Looks like a bug. -x checks for existence _and_ the exec bit set, so if the file does not exist the next line will try to source it. The error message suggests that the author wanted a completely different behaviour... -- Stanislav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sourcing init-functions
Hi Steve, Steve Langasek writes: > Hi Michael, > > On Sat, Jan 16, 2010 at 10:57:48AM +0100, Michael Welle wrote: >> several init scripts use such a fragment for sourcing init-functions: > >> if ! [ -x "/lib/lsb/init-functions" ]; then >> . /lib/lsb/init-functions >> else >> echo "E: /lib/lsb/init-functions not found, lsb-base (>= 3.0-6) needed" >> exit 1 >> fi > > What do you mean, "several"? What init scripts use this fragment? No init > scripts on any of my systems do this. several means that on the subset of all possible init scripts, that is installed on my machines, an astonishing quantity use this construct ;): r...@stella:/etc/init.d# grep '\-x.*init-functions' * ippl:if ! [ -x "/lib/lsb/init-functions" ]; then nagios3:if ! [ -x "/lib/lsb/init-functions" ]; then ser2net:if ! [ -x "/lib/lsb/init-functions" ]; then I guess there is a single source of this construct and then it is copied and copied again. >> What is the reason to bail out if the execute bit is set? Or should I >> bug report these packages? > > Looks like nonsense to me. I think you should file a bug. For one thing, > any init script that needs lsb-base (>= 3.0-6) *should depend on lsb-base > (>= 3.0-6)*, not throw an error if it's not installed. That is my feeling, too. I had discovered this annoyance while re-using Debian init scripts on a Xen Server. While Debian init scripts are supposed to work on the Debian distribution (which they do at the moment) it is IMHO a good thing to make them as universal as possible and I can't see what we gain with this restriction. In this sense init scripts can have some logic built in to bail out if their runtime environment doesn't fit. There are Unix system that do not use such a sophisticated packaging system as Debian do and this way the scripts can easiely be re-used. Regards Gyro -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Invitation to the BSP in Tokyo/Japan,23 January 2010
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, all.
Debian Developer in Japan and Debian JP Project convenes BSP on January 23.
Location, Date :
* Hosted The University of Tokyo, Komaba 2 campus[0].
* 9:00-21:00 January 23rd, 2010
* Main organizer: Yasuhiro Araki (ar) and me.
Targets for the BSP:
* RC-Bugsquashing[1].
* Take care of bugs found by piuparts[2] and ipv6[3].
* Fix l10n issues in Japanese envrionment bugs.
* Translate po and document to Japanese.
Please contact us if you are interested.
Hope to see you here.
Best regards,
Nobuhiro
[0]: http://www.u-tokyo.ac.jp/campusmap/map02_02_e.html
[1]: http://people.debian.org/~vorlon/rc-bugsquashing.html
[2]:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=piuparts;users=debian...@lists.debian.org&archive=both
[3]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;tag=ipv6
- --
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 3170EBE9 / 40AD1FA6
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAktRuA8ACgkQQSHHQzFw6+l+pgCdEOf4FRToB7K0gCjfKSpJLTh+
l08Ani2kRZdisRK4CJj8dmHSt1f0dv9Y
=i+0P
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ITP: otf-ipaexfont -- Japanese OpenType font, IPAexFont (IPAex Gothic/Mincho)
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, pkg-fonts-de...@lists.alioth.debian.org Package name: otf-ipaexfont Version: 00101 Upstream Author: Information-technology Promotion Agency, Japan. URL: http://ossipedia.ipa.go.jp/ipafont/ License: IPA Font License (OSI approval) http://www.opensource.org/licenses/ipafont.html Description: Japanese OpenType font, IPAexFont (IPAexGothic/Mincho) IPAex Fonts are JIS X 0213:2004 compliant OpenType fonts based on TrueType outlines. . IPAexFont pursues the optimized quality for document readability. Western characters are proportional style and Japanese Kana, Kanji characters and symbols are full width fixed width style. . It consists of * IPAexGothic * IPAexMincho -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane pgpjt80Oxp03Y.pgp Description: PGP signature
Bug#565515: ITP: sudosh3 -- Complete logging for sudo
Package: wnpp Severity: wishlist Owner: Sylvestre Ledru * Package name: sudosh3 Version : 3.2.0 Upstream Author : Giulio Capitanio * URL : http://sourceforge.net/projects/sudosh3/ * License : Open Software License version 2.0 (non free) Programming Lang: C Description : Complete logging for sudo sudosh allows complete session logging of shells run under sudo. Individual sudo commands are still logged as normal but running a shell under sudosh records the entire session as well as session timings for complete playback later. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Invitation to the BSP in Tokyo/Japan,23 January 2010
Hi, On Sat, Jan 16, 2010 at 09:58:55PM +0900, Nobuhiro Iwamatsu wrote: > * 9:00-21:00 January 23rd, 2010 > [...] > * RC-Bugsquashing[1]. > * Take care of bugs found by piuparts[2] and ipv6[3]. Without coordination with the BSP in Moenchengladbach[1] at the same time, targeting the same groups of bugs is a bad idea. [1] http://wiki.debian.org/BSP2010/Moenchengladbach We definitely need some common place to coordinate who fixes which bug during that time. If we would have only one BSP at that date, local coordination would be possible, but two geographically separated BSPs need online coordination. Only with proper coordination we can avoid to unnecessarily duplicate a lot of important work and cause quite some developer's frustration and wasting developers' time. I think using a single page in the Debian wiki for both BSPs is the best place to document the state of every bug being worked on during the two BSPs since it provides better overview than an IRC channel. But of course, #debian-bugs will be one of the main real-time communcation channels for both BSPs. Therefore I created http://wiki.debian.org/BSP2010/CoordinationTokyoMoenchengladbach and linked to it from both BSP pages. > * Fix l10n issues in Japanese envrionment bugs. > * Translate po and document to Japanese. These issues surely don't interfere with the Moenchengladbach BSP's focussed subjects, but of course can and should be documented on the same wiki page. :-) Regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News| a...@deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | a...@noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Invitation to the BSP in Tokyo/Japan,23 January 2010
On Sat, Jan 16, 2010 at 04:34:26PM +0100, Axel Beckert wrote:
> Without coordination with the BSP in Moenchengladbach[1] at the same
> time, targeting the same groups of bugs is a bad idea.
IMHO, you're overestimating the _additional_ risks of having 2 BSPs at
the same time instead of one (which already has the risks you mention
per se).
First of all, it has been observed already, that a group of more than 2
DDs hacking in a single room will end up communicating on IRC :-) While
jokish, I think this defeats your argument about "local coordination" in
a single BSP. This is not meant to be polemic at all, it is just my
personal experience.
To that end, BSPs already have tools to avoid conflicts *even among the
local participant*, which are: the #debian-bugs channel you've already
mentioned and the "claim" and "comment" features in Debbugs and
bts.turmzimmer.net.
Thanks nevertheless for the coordination page!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Invitation to the BSP in Tokyo/Japan,23 January 2010
Hi Zack, On Sat, Jan 16, 2010 at 04:54:48PM +0100, Stefano Zacchiroli wrote: > On Sat, Jan 16, 2010 at 04:34:26PM +0100, Axel Beckert wrote: > > Without coordination with the BSP in Moenchengladbach[1] at the same > > time, targeting the same groups of bugs is a bad idea. > > IMHO, you're overestimating the _additional_ risks of having 2 BSPs at > the same time instead of one (which already has the risks you mention > per se). Hehe. Well, there was a slight panic on #debian.de because of the announcement of the second BSP on that weekend. I was just the one who formed a mail out of that panic and tried to not letting it escalate. :-) > First of all, it has been observed already, that a group of more than 2 > DDs hacking in a single room will end up communicating on IRC :-) Hehe. > While jokish, I think this defeats your argument about "local > coordination" in a single BSP. This is not meant to be polemic at > all, it is just my personal experience. Yeah, I would have expected a wiki page for coordination anyway, even for a single BSP. IIRC all BSPs I've attended so far had a wiki page for coordinating and collecting the BSP's result. My hope was that by acting quickly we don't end up having two such pages. > To that end, BSPs already have tools to avoid conflicts *even among > the local participant*, which are: the #debian-bugs channel you've > already mentioned and the "claim" and "comment" features in Debbugs > and bts.turmzimmer.net. Ah, right, I knew I had forgotten something. Thanks for that hint! Regards, Axel -- Axel Beckert - a...@deuxchevaux.org, a...@noone.org - http://noone.org/abe/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
schroot version 1.4.0 released
Dear all, I have released schroot stable version 1.4.0. After testing of the 1.3.x development releases in experimental, this is the first 1.4.x stable release. This release has been uploaded to unstable, and is also available from our public git repository at git://git.debian.org/buildd-tools/schroot (tag release/schroot-1.4.0, branch schroot-1.4 http://git.debian.org/?p=buildd-tools/schroot.git;a=tag;h=refs/tags/release/schroot-1.4.0 http://git.debian.org/?p=buildd-tools/schroot.git;a=shortlog;h=refs/heads/schroot-1.4 The major changes from the previous 1.2.x stable releases are detailed below. Some configuration options have been deprecated and others obsoleted. These are documented in schroot.conf(5), and the user will be warned at runtime when deprecated or obsolete options are used. The most important user-visible change is the new support for union filesystems to create "scratch" writable snapshot sessions of chroots, for which many thanks are due to Jan-Marek Glogowski for his hard work on this feature. This is useful for situations where the LVM snapshot chroot type was previously the only choice, such as temporary clean build environments for sbuild/buildd chroots. A bash completion has also been added, for which Tim Abbott must be thanked. I'd also like to thank everyone else who contributed to this release; the full list is at the end of this mail. Major changes in 1.4.0: 1) Exec scripts have been removed. Unlike setup scripts, these scripts were never used, and there are no known uses for them. Removing them will improve the performance of schroot. The run-exec-scripts configuration option is no longer used, but is still permitted to be used until it is obsoleted in a future release. 2) Setup scripts are now always run for all chroot types except "plain". In practice, scripts were required for all types except "plain" in order to function correctly. The ability to configure this is not useful and so setting run-setup-scripts is now deprecated in schroot.conf. It may still be set for backward compatibility, but it has no effect and will be removed in the future. 3) Chroot configuration files in /etc/schroot/chroot.d are not loaded if they are backup files or dpkg conffile backups. 4) Support for GCC versions prior to 3.4 has been removed. 5) System databases are copied into the chroot using the getent program to use the appropriate name service switch (NSS) modules to get the data, rather than just copying the files. This means all NSS database sources are supported, including NIS and LDAP. 6) Setup script output is logged to stderr which prevents schroot outputting to stdout when run with verbose logging enabled. 7) Most schroot features are compiled conditionally, which should ease porting to non-Linux platforms. 8) Support for union filesystems has been added (aufs and unionfs). This permits the use of read-only block-device, directory and loopback chroots with a temporary writable overlay. For "scratch" temporary chroots, this method is recommended over the existing LVM snapshot support. It is considered to be faster, more robust, and uses less disc space. 9) The "command-prefix" option no longer requires an absolute path to the command. It will use the normal search path inside the chroot to locate the command. 10) When creating a session, the users in "users", "root-users", and groups in "groups" and "root-groups" are no longer preserved. The user requesting access will be the sole user listed in "users" for the session; however, if the user was in "root-users" or "root-groups", they will be added to "root-users" instead. This ensures that only the user creating the session will have access, so that other users having access to the chroot will not also automatically gain access to other users sessions. 11) Kernel personality support should now work on non-Linux architectures such as kfreebsd. If you have any feedback or problems with the new release, please let the developers know at buildd-tools-de...@lists.alioth.debian.org or file bugs in the BTS. You can also find us on #debian-buildd on OFTC. Regards, Roger Leigh Contributors and patches: Clytie Siddall (1): [po] Update vi translation Geoffrey Thomas (4): build: Only use silent-rules if it's available scripts/git-version: Ask git for date differently build: Auto-detect whether -mt is needed for Boost libs etc/setup.d/00check: Permit union chroots on the root directory Helge Kreutzmann (1): po: Update de translation Holger Wansing (1): po: Update de translation Jan-Marek Glogowski (43): [build] Just link schroot-mount to boost filesystem lib [.gitignore] debian: Simplify ignore rules [debian] schroot-dbg: Add debug symbols package [debian] libsbui
Bug#565544: ITP: duply -- easy to use frontend to duplicity
Package: wnpp Severity: wishlist Owner: Joachim Wiedorn * Package name: duply Version : 1.5.1.4 Upstream Author : Edgar Soldin * URL : http://sourceforge.net/projects/ftplicity/ * License : GPL-2 Programming Lang: Bash Description : easy to use frontend to duplicity Duply is a shell front end to duplicity that simplifies the usage by managing settings for each backup job in profiles. It supports executing multiple commands in a batch mode to enable single line cron entries and allows the user to use pre/post backup scripts. All duplicity backends are supported. The previous name fo duply was ftplicity. Fondest regards, Joachim Wiedorn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#565544: ITP: duply -- easy to use frontend to duplicity
I found it is a nice package for better using of duplicity. It have the stability for getting a Debian package. I have tested the package and already created a new Debian package of duply. If nobody have the same intention I would upload the package onto mentors.debian.net. Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Bug#565554: ITP: capstats -- print statistics about the current load on a network interface
Package: wnpp Severity: wishlist Owner: Justin Azoff * Package name: capstats Version : 0.11 Upstream Author : Robin Sommer * URL : http://www.icir.org/robin/capstats/ * License : GPL Programming Lang: C Description : print statistics about the current load on a network interface capstats reports statistics per time interval and/or for the tool's total run-time. For each interval it outputs: * the number of packets seen * the number of packets per second * the total number of kilobytes seen * the rate in megabits per second * the number of tcp,udp,icmp, and non-ip packets -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Invitation to the BSP in Tokyo/Japan,23 January 2010
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
2010/1/17 Axel Beckert :
> Hi,
>
> On Sat, Jan 16, 2010 at 09:58:55PM +0900, Nobuhiro Iwamatsu wrote:
>> * 9:00-21:00 January 23rd, 2010
>> [...]
>> * RC-Bugsquashing[1].
>> * Take care of bugs found by piuparts[2] and ipv6[3].
>
> Without coordination with the BSP in Moenchengladbach[1] at the same
> time, targeting the same groups of bugs is a bad idea.
>
> [1] http://wiki.debian.org/BSP2010/Moenchengladbach
>
> We definitely need some common place to coordinate who fixes which bug
> during that time. If we would have only one BSP at that date, local
> coordination would be possible, but two geographically separated BSPs
> need online coordination.
>
> Only with proper coordination we can avoid to unnecessarily duplicate
> a lot of important work and cause quite some developer's frustration
> and wasting developers' time.
Yes, I think too.
We knew that Moenchengladbach BSP was held on the same day.
And we are going to adjust it in IRC(#debian-bug) and bts.turmzimmer.net each
other.
It is my clumsiness that did not write these.
>
> I think using a single page in the Debian wiki for both BSPs is the
> best place to document the state of every bug being worked on during
> the two BSPs since it provides better overview than an IRC channel.
> But of course, #debian-bugs will be one of the main real-time
> communcation channels for both BSPs.
>
> Therefore I created
> http://wiki.debian.org/BSP2010/CoordinationTokyoMoenchengladbach and
> linked to it from both BSP pages.
>
>> * Fix l10n issues in Japanese envrionment bugs.
>> * Translate po and document to Japanese.
>
> These issues surely don't interfere with the Moenchengladbach BSP's
> focussed subjects, but of course can and should be documented on the
> same wiki page. :-)
Thank you for create the coordination page.
Best regards,
Nobuhiro
- --
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAktSUV8ACgkQQSHHQzFw6+lFhACgr/B0+XFWeuvnBrXYqSJXUBNX
Of4AmwVQJZPzcoWx8j0tb29FWca7UaI6
=vhhm
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#565515: ITP: sudosh3 -- Complete logging for sudo
On Sat, Jan 16, 2010 at 04:00:56PM +0100, Sylvestre Ledru wrote:
> * Package name: sudosh3
> Version : 3.2.0
> Upstream Author : Giulio Capitanio
> * URL : http://sourceforge.net/projects/sudosh3/
> Description : Complete logging for sudo
> sudosh allows complete session logging of shells run under sudo.
> Individual sudo commands are still logged as normal but running a shell
> under sudosh records the entire session as well as session timings for
> complete playback later.
Uhm, it appears to be an one-trick pony which tries to replicate what ttyrec
does, except that it's usage is sharply limited, it spits out several files
instead of one, and the code quality is terrible. Just one example:
In replay.c, it does sscanf("... %i ...", &b) to an int, makes a sanity
check, rejecting values of b more than 8MB -- comparing it as a _signed_
value. Then, it does read(fd, buffer, (size_t)b). (size_t is unsigned).
But after a second reading of the code, you don't need to go that far. The
check against overflow was for 8MB, and size of the static buffer is 8192
bytes...
Also,
> * License : Open Software License version 2.0 (non free)
Is there any need for non-free tools where better free equivalents already
exist? Try ttyrec, my termrec, script -t (not as well suited for this
task), RealLog, nh_recorder or one of many others...
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
