Bug#352353: ITP: wmfrog -- A dockapp for showing weather in graphical way

[Jari Aalto]

Package: wnpp
Severity: wishlist
Owner: Jari Aalto <[EMAIL PROTECTED]>

* Package name: wmfrog
  Version : 0.1.6
  Upstream Author : <[EMAIL PROTECTED]>
* URL : http://www.colar.net/wmapps/
* License : GPL
  Description : A dockapp for showing weather in graphical way

A dockapp for wheather reports. Includes clouds (clear, few,
scattered, broken, overcast ...); Precipitations (drizzle, rain,
snow, ice christals: light/moderate or heavy); Special weather
(Blowing wind / Freezing / Thunderstorm, funnel cloud...); Humidity
perentage; Wind speed (average & gust); Wind Direction; Temperature
(Celcius or Fareinheit); Station name can be configured and weather
report time is displayed.

See also
  http://dockapps.org/file.php/id/92

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.14-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US)


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

Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)

[Jari Aalto]

Package: wnpp
Severity: wishlist
Owner: Jari Aalto <[EMAIL PROTECTED]>

* Package name: gitmail
  Version : 0.4
  Upstream Author : <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/gitmail
* License : GPL
  Description : Very simple graphical mail user agent for sending mail (GTK)

Ghost In The Mail (gitmail) is an anonymous mail client for Linux
written in C/GTK. It supports attached files. The user can specify the
SMTP server, the sender's e-mail, and the name.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.14-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US)


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

Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)

[Jari Aalto]

| * Adeodato Simó [Mon, 13 Feb 2006 22:58:24 +0100]:
| 
| >   And it may fall under the "too buggy that we refuse to support it"
| 
|   Ah, forgot to say that the code is, at least, full of malloc(FIXED_NUM), 
|   that afterwards get used without any check for errors.

I've renamed the package to "ghostmail". It's now listed and *.deb packages
available at

http://sponsors.debian.net/viewpkg.php?id=219

The HELO argument may be funny, but the package seems to work okay.
This list weight GUI version of sending mail (in contrast to console
based ones; mutt etc.), is very small application that is suitable for
low end machines (166Mhz).

As for the anonymous mail, Debian includes privacy tools and there is
nothing in the mail itself that would not be possible straight from
Perl or Python script.

Any Mail agent almost let's you define who you are.

Can you all provide more information on

"too buggy that we refuse to support it"
 full of malloc(FIXED_NUM)
 
So that I can take this to upstream. Is there improvements
that you would like to propose?

Jari


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

Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)

[Jari Aalto]

Henning Makholm <[EMAIL PROTECTED]> writes:

> Scripsit Ron Johnson <[EMAIL PROTECTED]>
>
>>>From http://gitmail.sourceforge.net/ :
>> This piece of software allows to send e-mails to any person 
>> over the net with a fake email address, and also a fake name.
>
> Is this a feature, even? I should think all regular MUAs in Debian
> happily allow the user to put anything he wants in the From line --
> they had better, as a MUA running on a NATted box with no global FQDN
> of its own has no way of knowing _any_ guaranteed-to-work sender
> address.
>
> There does not appear to be anything one can do with this software
> that is not straightforwardly possible with an off-the-shelf MUA
> that can be configured to send to a smarthost rather than to a local
> MTA.

The text is diretly form the developer's page. I'll improve the
description, since there is nothing special on it.

The speciality is the small size + GUI to send mail. Useful for
low end harware (166Mhz / 64 M mem).

Jari




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

Re: Bug#352353: ITP: wmfrog -- A dockapp for showing weather in graphical way

[Jari Aalto]

Nico Golde <[EMAIL PROTECTED]> writes:

> Hi,
> * Jari Aalto <[EMAIL PROTECTED]> [2006-02-11 15:08]:
>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Jari Aalto <[EMAIL PROTECTED]>
>> 
>> * Package name: wmfrog
>>   Version : 0.1.6
>>   Upstream Author : <[EMAIL PROTECTED]>
>> * URL : http://www.colar.net/wmapps/
>> * License : GPL
>>   Description : A dockapp for showing weather in graphical way
>
> [...]
> What about wmweather?

the "frog" is nicer and gives inforamtion visually, not in numeric
forms. See picture in above URL.

Jari


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

Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)

[Jari Aalto]

Ron Johnson <[EMAIL PROTECTED]> writes:

> On Tue, 2006-02-14 at 01:16 +0200, Jari Aalto wrote:
>> 
>> The speciality is the small size + GUI to send mail. Useful for
>> low end harware (166Mhz / 64 M mem).
>
> But that's just it.  It's for *sending* mail only.  What is the
> purpose of a GUI for sending mail?

The small memory footprint. In minimalistic Window manager +
minimalistic program to send mail. 

Jari



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

Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)

[Jari Aalto]

Adeodato Simó <[EMAIL PROTECTED]> writes:
>> Can you all provide more information on
>
>> "too buggy that we refuse to support it"
>>  full of malloc(FIXED_NUM)
>
>> So that I can take this to upstream. Is there improvements
>> that you would like to propose?

I noticed that later. I've forwarded the discussion to upstreams and
he acknowledges the problems. There is a promise to get them fixed,
because this project is hosted at sourceforge.

Thank you for participants to point how to improve this package,

Jari



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

Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)

[Jari Aalto]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> On Tue, 14 Feb 2006, Ron Johnson wrote:
>
>> On Tue, 2006-02-14 at 03:35 -0500, Glenn Maynard wrote:
>> > On Tue, Feb 14, 2006 at 10:07:45AM +0200, Jari Aalto wrote:
>> > > Ron Johnson <[EMAIL PROTECTED]> writes:
>> > > 
>> > > > On Tue, 2006-02-14 at 01:16 +0200, Jari Aalto wrote:
>> > > >> 
>> > > >> The speciality is the small size + GUI to send mail. Useful for
>> > > >> low end harware (166Mhz / 64 M mem).
>> > > >
>> > > > But that's just it.  It's for *sending* mail only.  What is the
>> > > > purpose of a GUI for sending mail?
>> > > 
>> > > The small memory footprint. In minimalistic Window manager +
>> > > minimalistic program to send mail. 
>> > 
>> > Err, who uses GTK when "small memory footprint" or "minimalistic"
>> > are objectives?
>> 
>> XFce is lighter than GNOME.
>> 
>> And writing in GTK is (supposed to be) easier that writing Xlib.
>
> Which's the reason you use xaw.  But in this case, it is a simple X-based
> form plugged to broken crap that needs to be replaced, and which could well
> be replaced by a call to sendmail.  Thus, you don't even need C code, just a
> tcl/tk script.

Not so fast. If the light weight system is to be kept as small as
possible, the additional tcl/Tk libraries would not be welcomed.

GTK at least is common to most of the C programs that do not bring
along other libraries.

The programs talks directly to SMTP, so there is no need to require
a MTA in the system.

Upstream is interested in getting the program in better shape based on
the malloc-discussion here.

Jari



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

Re: Size matters. 7zip. Again.

[Jari Aalto]

Eduard Bloch <[EMAIL PROTECTED]> writes:

> #include 
> * Lars Wirzenius [Wed, Feb 15 2006, 10:42:02AM]:
>
>> (Once we use .tar.bz2, the sizes will be even smaller.)
>
> I cannot remember a clear consens from the "Size matters" thread, and
> IMO we should go for 7zip at least for source packages.

There are more alternatives:  http://rzip.samba.org/

...In the following I show the compression ratios of the
large-corpus for rzip 2.0, gzip 1.3.5 and bzip2 1.0.2 on my Debian
Linux laptop. In all cases the programs were run with their
maximum compresion options.

File Name rzip  gzipbzip2   
large-corpus/archive  6.03  3.644.97
large-corpus/emacs5.08  3.664.62
large-corpus/linux5.54  4.245.23
large-corpus/samba9.55  3.504.78
large-corpus/spamfile 29.95 8.4314.23

Does anyone know how 7zip would compare to this?

Jari


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

Re: when and why did python(-minimal) become essential?

[Jari Aalto]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Le samedi 28 janvier 2006 à 21:19 -0600, Manoj Srivastava a écrit :
>
>> And if we followed the the line of argument you are pressing
>>  uncritically, we'd bloat essential/base with gazillions of
>>  interpreters from people too lazy or incompetent to learn the
>>  interpreters already in base.
>
> I prefer to be labeled as incompetent by people like you than to write
> scripts that no one will be able to understand later. Every time I face
> a write-once, never change perl script, the only thing to do is to
> rewrite it. And this isn't a Debian-specific issue.

Don't blame the language[1], but the people. You can as well code unbearable
code in C/C++/Mono/C# (whatever) that no-one can understand. The Perl
syntax is elegant, efficient and Python's regexp handling is nowhere
as intuitive as needed for day-to-day tasks where the poer is needed.

This is not to day that Python is bad - It has better OO, which Perl
unfortunately negletted fromt he very starts. Now, talk about Perl OO 
and that's hairy!.

Jari

[1] Example of Perl coding (do not blame the language):

# 
#
#   DESCRIPTION
#
#   Convert tokens 7m, 2h, 3d into minutes. Die if value is not numeric.
#
#   INPUT PARAMETERS
#
#   none
#
#   RETURN VALUES
#
#   none
#
# 

sub TimeValue ($)
{
my $id = "$LIB.TimeValue";

local ($ARG) = (@ARG);

if ( /^(\d+)([mhd]?)$/ )
{
$ARG = $1;
my $spec = $2  if defined $2;

$debug  and  print "$id: val [$ARG] spec [$spec]\n";

my $factor = 1;
$factor = 60if $spec =~ /h/i;
$factor = 60 *24if $spec =~ /d/i;

$ARG *= $factor;

$debug  and  print "$id: val [$ARG] factor [$factor]\n";
}
else
{
die "$id: Not a recognized time value [$ARG]. Try 2m, 2d, 2h";
}

$ARG;
}


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

Bug#353365: ITP: gt5 -- Terminal program for visual disk usage with navigation

[Jari Aalto]

Package: wnpp
Severity: wishlist
Owner: Jari Aalto <[EMAIL PROTECTED]>

* Package name: gt5
  Version : 1.3
  Upstream Author : Thomas Sattler <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/gt5
* License : GPL
  Description : Terminal program for visual disk usage with navigation

Years have passed and disks have become larger and larger, but even on
this incredibly huge harddisk era, the space seems to disappear over
time. This small and effective programs provides more convenient
listing than the default du(1). It displays what has happened since
last ran and displays dir size and the total percentage. It is
possible to navigate and ascend to directories by using cursor-keys.

Languages:

  shell
  awk

Screenshot:

  http://gt5.sf.net/

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.14-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US)


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

PROPOSAL: debian/control file to include new License: field

[Jari Aalto]

To my understanding the only way to obtain the license information
for a package is to actually download it (or install it) and the
study the content of

/usr/share/doc//copyright

It would be better if user could use the packaging search commands,
like

grep-dctrl -F License ... --and -F package ...

PROPOSAL:

Add new field to the debian/control (which would be generated by dh-make):

License:

It would contain a canonicalized word to describe the license in 
questions, like:

GPL, GPL2, GPL3, LGPL, BSD, Perl Artistic, MIT/X . Custom

The number of generic license name can be debated and instead of
the last resort "Custom" there could be word like:

DFSG-approved, OSI-approved, FSF-approved etc.

DH_MAKE TEMPLATE

If given the option --copyright, then the field is initialised with
that value, otherwise add

Licence: http://wiki.debian.org/DFSGLicenses>

Jari

[PS]
Should this be disccussed in, (crossposted to) debian-legal as well? 


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

Bug#354976: ITP: bbweather -- Dockapp to show the current weather conditions.

[Jari Aalto]

Package: wnpp
Severity: wishlist
Owner: Jari Aalto <[EMAIL PROTECTED]>

* Package name: bbweather
  Version : 0.6.2
  Upstream Author : Jan Schaumann <[EMAIL PROTECTED]>
* URL : http://www.netmeister.org/apps/bbweather/index.html
* License : GPL
  Description : dockapp to show the current weather conditions

 Bbweather is a tool which displays the current weather conditions in
 an decorated window, simulating the look of the Blackbox toolbar.
 This tool is heavily based on "bbdate" by John Kennis. Furthermore,
 bbweather was inspired by wmWeather by Michael G. Henderson, from
 where a perl-script that fetches the weather-conditions
 from local station was borrowed.

See also 

  <http://bbtools.sourceforge.net/download.php?file=11>

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.15-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US)


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

Bug#355030: ITP: ultimate-othello -- classic othello game with nice graphics

[Jari Aalto]

Package: wnpp
Severity: wishlist
Owner: Jari Aalto <[EMAIL PROTECTED]>

* Package name: ultimate-othello
  Version : 1789.12
  Upstream Author : Jean-Christophe Hoelt <[EMAIL PROTECTED]>
* URL : http://www.ios-software.com/?page=projet&quoi=2&lg=AN
* License : GPL
  Description : classic othello game with nice graphics

The ultimate othello game with aqua-friendly graphics, full 
cocoa interface and animations.

Picture available at homepage.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.15-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US)


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

Re: Bug#355030: ITP: ultimate-othello -- classic othello game with nice graphics

[Jari Aalto]

| On 02-Mar-06, 15:01 (CST), Jari Aalto <[EMAIL PROTECTED]> wrote: 
| > The ultimate othello game with aqua-friendly graphics, full 
| > cocoa interface and animations.
| 
| And how is that relevant to a Debian GNU/Linux user?

Here is better description:

 graphical client-server 8x8 grid Othello game with chat

 An Othello game with friendly graphics and movement animations.
 This is game includes server to which clients can connect. A chat
 session between players is supported.

 Homepage: <http://www.ios-software.com/?page=projet&quoi=2&lg=AN>

Jari


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

Re: Desktop task(sel) in Etch? (Bug #389092)

[Jari Aalto]

Joey Hess <[EMAIL PROTECTED]> writes:

> Jon Dowland wrote:
> > Hm. If you installed the gnome metapackage with aptitude,
> > then the dependencies would be marked 'auto' and removed
> > once you'd removed the manual package at the top of the
> > tree.
> 
> Or you can just tasksel remove gnome-desktop; tasksel install kde-desktop

If possible, document these commands in the help screen of the Debian
installed. Many don't know this.

Jari


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

Re: Proposed new POSIX sh policy

[Jari Aalto]

Manoj Srivastava <[EMAIL PROTECTED]> writes:
>  policy, really -- policy could just take the approach /bin/sh ==
>  bash [...]
> 
>  Why don't we do that? Because people wanted to have a
>  different shell that can serve as /bin/sh.  What purpose does it
>  serve to allow that? We can't, in all honesty, say that any disk
>  space is conserved, since bash is essential, it is too deeply rooted
>  in all places in our system to be casually ripped out.
> 
>  So why not just specify all maintainer scripts just use
>   /bin/bash? [...]
>
>  One thing I see happening is that replacing bash as /bin/sh
>  might make script startup ties a bit faster, at the expense of  soe
>  of the built in facilities and extensions present in bash.

FREEDOM TO CHOOSE

First, people should have freedom to choose and writing a requirement
to use a specific tool for the job is not in the spirit of Debian.

The standard shell is not the problem, the problem is the developers
that are not aware of the standard shell constructs. They may have
programmed C, zsh, csh previously and just "went on sh", because the
policy required the standard scrupts to be written 

   a) sh-compliant shell
   b) or Perl

Since Perl is not really needed for simple tasks, they choose shell
scripts.

IMPROVE QA - THE LINTIAN PROGRAM

All discussion about "policy has problems" is really due to lack of
quality assurance work that prevents non-sh-compliant scripts to enter
into the packaging in the first place. If people are sloppy or don't
know how to comply with standard sh scripts, this is great oppurtunity
to make lintian to warn them. Simple typical constructs would not be
hard to add - substle differences are another matter.

WHY ALLOW OTHER SHELLS

Old PCs. Really, the reality is not that everybody owns 3Ghz P4
or MAD FX2 with 4G memory. There are lot of countries that
stil use 14k modem lines and old PCs. The education sector
has to live with PCs that may be very old, like 64M memory
and 166 - 800Mhz processor speed.

It's not about disk space, it's execution speed.

- every bash call takes 3 times the memory compared to mksh
- 80% of the bash features are taken cared of dash, posh, mksh
  or other shells

IF all scripts just were written better, they would be
automatically ocmpatible with any standard sh-alike shell that 
is included in Debian. 

Policy really should stay sh-agnistic and netral; and not mandate 
what shell is required. People have reasons to use other tools.
And that choice is not difficult to serve.

Jari







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

Re: Proposed new POSIX sh policy

[Jari Aalto]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Jari Aalto <[EMAIL PROTECTED]> writes:
> 
> > IMPROVE QA - THE LINTIAN PROGRAM
> 
> > know how to comply with standard sh scripts, this is great oppurtunity
> > to make lintian to warn them. Simple typical constructs would not be
> > hard to add - substle differences are another matter.
> 
> [lintian] ...cases that have slipped through the cracks, but as
> Marco says I know that a fair number of people are using dash as
> their /bin/sh already without encountering many problems.

I can confirm that. I also use /bin/dash without problems (due to
performance reasons / old hardware) and I have reported every bashism
that have come accross.

> The core of Debian is already in fairly good
> shape for supporting changing /bin/sh to other shells and I expect new
> lintian checks will mostly pick up little-used scripts or
> infrequently-used packages.

Excellent news, that is very welcomed. The lintian is one of the best
inventions next to sliced bread.

Jari



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

Re: Proposed new POSIX sh policy

[Jari Aalto]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Manoj Srivastava ([EMAIL PROTECTED]) [061116 05:57]:
> > ,
> > |  "Shell scripts specifying /bin/sh as interpreter must only use POSIX
> > |  features, additionally, they may assume that echo -n  . Also,
> > |  they may use test -a/o and the local directive in shell functions,
> > |  as long as   If a shell script uses features beyond this set
> > |  listed, then the appropriate shell must be specified in the first
> > |  line of the script (e.g., #!/bin/bash) and the package must depend on
> > |  the package providing the shell (unless the shell package is marked
> > |  "Essential", as in the case of bash). "
> > `
> > 
> > This does specify what the scripts may expect, but drops all
> >  wording from this section regarding what the policy expectation of
> >  /bin/sh is.
> 
> Sounds good to me. Though (as a non-native speaker) I would rather
> reformat it to:
> | ... must only use POSIX features, and can:
> | - assume that echo -n ...
> | - use test -a/o and the local directive

I concur. Please use definition list (bulletin or some suct), to list the
items. It's more clear that way.

Jari


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

Re: Proposed new POSIX sh policy

[Jari Aalto]

Bill Allombert <[EMAIL PROTECTED]> writes:

> I am of two mind with that. On the positive side it removes the promise
> to the users that the system works with _any_ POSIX-compliant /bin/sh, which
> is something we never actively tested.
> 
> On the other hand, it more or less mandates that /bin/sh is /bin/bash
> (because /bin/sh is not a config file, and baring policy authorization,
> users are not supposed to change symlinks in /bin). This looks like a 
> regression a regression in user choice: I expect there are sufficiently
> many Debian installation where /bin/sh is /bin/dash for us to claim 
> that /bin/sh pointing to /bin/dash is a supported and tested configuration.

The /bin/sh should really point to a reference shell that is accepted
for the release builds (like /bin/dash). It's is unfortunate that in
the distant past someone made a decision to simply soft link it to
bash.

I suppose it is impossible to make an etch+1 change to remove the
/bin/sh => /bin/bash coupling.

Jari




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

Re: Proposed new POSIX sh policy

[Jari Aalto]

Bruce Sass <[EMAIL PROTECTED]> writes:

> Scripts specifying /bin/sh as their command interpreter (shell) must 
> only use SUSv3[1] features or the following exceptions:
> 
> - echo -n[2]
> - [ x -a y ] [3]
> - ...[4]
> 
> Thus, the only shells allowed to be /bin/sh are those which are SUSv3 
> compliant and implement the allowed exceptions to SUSv3. If a script 
> requires non-SUSv3 features not explicitly excepted, the appropriate 
> shell must be specified in the first line of the script (e.g., 
> #!/bin/bash) and the package must depend on the package providing the 
> shell (unless the shell package is marked "Essential", as in the case 
> of bash).
> 
> [1] http://www.opengroup.org/onlinepubs/009695399/ POSIX, XSI, whatever
> [2] whatever its problem is
> [3] why -a is allowed

Make it a recommendation to use:

  [ x ] && [ y ]

as alternative to "-a". The "-a" may cause problems because it does
not short circuilt, like the && would. Lintian could give a warning
and suggest maintainers to consider the "&&" choice.

Too bad lintian doesnät have "--pedantic" equivalent of gcc.

Jari


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

Re: Proposed new POSIX sh policy

[Jari Aalto]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> On Wed, 2006-11-15 at 16:28 -0700, Bruce Sass wrote:
> At that point, I suggested and still suggest that we change Policy to
> restrict /bin/sh to a specific set of shells, rather than just any
> "Posix-compatible shell".  

I think this could be solved with wording like:

   ...must work with any POSIX compliant shell. The reference shell in
   Debian is /bin/dash, which can be used to test the maintainer
   scripts. It is however recommended that the maintainer scripts are
   made as general as possible and not restricted to any particular
   sh-implementation, not even /bin/dash.

I'm sure someone can rephrase the above better, my idea being:

- /bin/dash is the measure (the minimum)

- It is encouraged that maintainers accept patches and seek ways to
  generalize scripts (= pay attention to lintian warnings) 
  even further so that they are not restricted to even
  /bin/dash alone. It is preferred that scrpts could also work with
  /bin/posh /bin/pdksh /bin/mksh etc. as well, if this does not require
  overly complex constructs in the programs.

Jari


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

Re: Proposed new POSIX sh policy

[Jari Aalto]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Jari Aalto ([EMAIL PROTECTED]) [061117 17:40]:
> > I'm sure someone can rephrase the above better, my idea being:
> > 
> > - /bin/dash is the measure (the minimum)
> 
> I disagree to that.

Care to share your thoughs a little in depth? Any specific oobjections with
/bin/dash being the default reference sh-implementation in Debian?

Jari


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

Re: Question about "Depends: bash"

[Jari Aalto]

Ben Armstrong <[EMAIL PROTECTED]> writes:

> On Mon, 20 Nov 2006 17:58:58 +0100
> Michelle Konzack <[EMAIL PROTECTED]> wrote:
>
> But if they are concerned about the memory footprint of the shell
> used by default as /bin/sh, that is another matter. They can always
> install dash and symlink /bin/sh to it. This will not break scripts
> that use bash (unless they call bash as #!/bin/sh, but if they do,
> that's a bug in the script).

I believe he meant that. 

The memory footprint[1] of bash is bothering in old PC's, so there are
real benefits trying to make without it; even on command line sessions
where alternative shell, like /bin/mksh, whose capabilities will 
surpise even the bash enthusiasts.

Jari

[1] Stem desktop project for Debian
See near the end, under heading "4.3 Can I save even more memory - how?"
and Picture 17 titled "Memory consumption of various shells."
http://debian.cante.net/stem/faq/index.html


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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Okay, here's try number two.  I tried to incorporate the feedback from
> various people.  Please critique.
> 
> --- debian-policy-3.7.2.2/policy.sgml 2006-10-02 15:36:50.0 -0700
> +++ /home/eagle/dvl/policy/policy.sgml2006-11-20 22:35:59.0 
> -0800
> @@ -5662,7 +5670,7 @@
>   /etc/default, which typically will have the same
>   base name as the init.d script.  This extra file
>   should be sourced by the script when the script runs.  It
> - must contain only variable settings and comments in POSIX
> + must contain only variable settings and comments in SUSv3
>   sh format.  It may either be a
>   conffile or a configuration file maintained by
>   the package maintainer scripts.  See 
> @@ -6723,34 +6731,54 @@
>   
>  
>   
> -   The standard shell interpreter /bin/sh can be a
> -   symbolic link to any POSIX compatible shell, if echo
> -   -n does not generate a newline.
> -   Debian policy specifies POSIX behavior for
> -   /bin/sh, but echo -n has widespread
> -   use in the Linux community (in particular including this
> -   policy, the Linux kernel source, many Debian scripts,
> -   etc.).  This echo -n mechanism is valid but not
> -   required under POSIX, hence this explicit addition.
> -   Also, rumour has it that this shall be mandated under
> -   the LSB anyway.
> +   Scripts may assume that /bin/sh implements the
> +   SUSv3 Shell Command Language
> + Single UNIX Specification, version 3, which is also IEEE
> + 1003.1-2004 (POSIX), and is available on the World Wide Web
> + from http://www.unix.org/version3/online.html";
> +   name="The Open Group"> after free
> + registration.
> +   plus the following additional features not mandated by
> +   SUSv3:
> + These features are in widespread use in the Linux community
> + and are implemented in all of bash, dash, and ksh, the most
> + common shells users may wish to use as /bin/sh.
> 
> -   Thus, shell scripts specifying /bin/sh as
> -   interpreter must only use POSIX features. If a script
> -   requires non-POSIX features from the shell interpreter, the
> -   appropriate shell must be specified in the first line of the
> -   script (e.g., #!/bin/bash) and the package must
> -   depend on the package providing the shell (unless the shell
> -   package is marked "Essential", as in the case of
> -   bash).
> +   
> + echo -n, if implemented as a shell built-in,
> +   must not generate a newline.
> + test, if implemented as a shell built-in, must
> +   support -a and -o as binary logical
> +   operators.
> + local to create a scoped variable must be
> +   supported; however, local may or may not preserve
> +   the variable value from an outer scope and may or may not
> +   support arguments more complex than simple variable.  Only
> +  uses such as:
> +
> +fname () {
> +local a
> +a=''
> +# ... use a ...
> +}
> +
> +  must be supported.
> +
> +   
> +   If a shell script requires non-SUSv3 features from the shell
> +   interpreter other than those listed above, the appropriate shell
> +   must be specified in the first line of the script (e.g.,
> +   #!/bin/bash) and the package must depend on the package
> +   providing the shell (unless the shell package is marked
> +   "Essential", as in the case of bash).
>   

I would drop that "special" case and always require explicit
requirement for the shell. It's more clear to see which packages
"need" bash to make them work. someone may then provide a patch to
"make bash go away". I suggest removing the last 2 lines:

  If a shell script requires non-SUSv3 features from the shell
  interpreter other than those listed above, the appropriate shell
  must be specified in the first line of the script (e.g.,
  #!/bin/bash) and the package must depend on the package
  providing the shell.

  
>   
> -   You may wish to restrict your script to POSIX features when
> -   possible so that it may use /bin/sh as its
> -   interpreter. If your script works with dash
> -   (originally called ash), it's probably POSIX
> -   compliant, but if you are in doubt, use
> +   You may wish to restrict your script to SUSv3 features plus the
> +   above set when possible so that it may use /bin/sh
> +   as its interpreter. If your script works with dash
> +   (originally called ash), it probably complies with
> +   the above requirements, but if you are in doubt, use
> /bin/bash.
>   
>  
> -- 
> Russ Allbery ([EMAIL PROTECTED]) 

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> On Thu, 2006-11-23 at 01:15 +0200, Jari Aalto wrote:
> > 
> > I would drop that "special" case and always require explicit
> > requirement for the shell. It's more clear to see which packages
> > "need" bash to make them work. someone may then provide a patch to
> > "make bash go away". I suggest removing the 
> 
> Russ has already explained why this would violate other parts of policy.
> 
> I'm interested in why we should care at all.  Perl is a far bigger space
> hog than bash.
> 
> Someone somewhere told a Big Lie: "bash isn't essential to Debian".
> Lots of people perhaps believe this lie, and have a Grand Quest to "make
> bash go away".  What is the reason?  Why is it worth energy on the part
> of *everyone else*?

Bash is not essential for running Debian. It is possible to run old
PCs and old laptops completely free of bash. The point here is not the
disk consumption, but the reduced memory constrainsts. When scripts
are written with only "sh" in mind, they become portable to even
embedded systems (think busybox). Every bash-dependent scipt that runs
on the system, takes memory out from other processes.

Explicitly listing bash in "Depends:" may be redundant but it makes
things transparent and not "hidden". It announces what is the required
"feature" that the package cannot be run without.

It is possible to remove bash after install and use alternative
shells, as has been demonstrated. And if Package is patched so that
no more bash constructs are needed, it becomes generic.

Education sector and 3rd world still have PCs that are *years* and
*tears* old. Everybody do not live in countries where computers or
hardware are cheap.


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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Jari Aalto <[EMAIL PROTECTED]> writes:
> 
> > I would drop that "special" case and always require explicit requirement
> > for the shell. It's more clear to see which packages "need" bash to make
> > them work. someone may then provide a patch to "make bash go away".
> 
> This would conflict with Policy 3.5, which says that packages should not
> depend on any essential package unless they need a specific version.
> Policy shouldn't contradict itself, so I think this would require further
> discussion and justification for making an exception for bash.
> 
> In practice, I don't think it would ever be possible to remove any feature
> from the set of essential packages in Debian.

I'm not suggesting to remove features from essential, but I think the
policy should take the shells as special case, because the
sh-compliances (SusV/POSIX) itself is a matter of its own. There are
no viable alternative implementation of Perl which is in essential, likewise
for the rest.

But for the shells there are. I think the Policy should exempt shells
and require that if package is not POSIX/Susv -compiant, it needs to
announce dependance on a particular shell -- where it bash, tcsh,
pdksh ..., if it uses those shells special features.

Jari





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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Marvin Renich <[EMAIL PROTECTED]> writes:

> * Jari Aalto <[EMAIL PROTECTED]> [061123 06:56]:
> > 
> > But for the shells there are. I think the Policy should exempt shells
> > and require that if package is not POSIX/Susv -compiant, it needs to
> > announce dependance on a particular shell -- where it bash, tcsh,
> > pdksh ..., if it uses those shells special features.
> > 
> > Jari
> > 
> 
> Making an exception like this is not a good idea, and is not necessary.
> If it is decided that allowing bash to be replaced by one of a short
> list of other shells is a good idea, then make each shell in the list
> Provide: almost-posix-shell (or something) and make almost-posix-shell
> essential (can a virtual package be essential?).  Or make a real package
> almost-posix-shell that depends on bash | dash | 

Russ, I'm CC'ing - please tell if you'd rather read the list.

I agree. Your suggestion solves this for all parties. The policy stays
intact, but the underlying dependencies need an improvement. The
problem I see in current situation is that

  Packages' dependencies tend to be implicit. Sometimes it would
  be more better to be explicit and not optimize dependencies away
  with the assumption that a feature is provided by "essential".

  In a way, Policy encourages view that listing explicit
  dependencies is considered bad and wrong. On the contrary The
  policy could encourage to make things transparent; this is good
  testing and QA methodology. Policy should not care whether
  package announces all dependencies or that some package
  announces only those not covered in "essential".

The lack of explicit 'Depends:' is now shadowed byt the Policy which
does not require bash to be listed ... because it's in essential.

Your suggestion, that there should be something like:

Provides: standard-compliant-shell

in every shell packages that provide the standard (were it POSIX or
SusV) features expected in Debian. Even better, there should be a
test suite:

Package: standard-compliant-shell-test-suite

which could be used as measure to see which shells qualify the
"compliance"; whatever that would be.

A more simpler approach would be making /bin/dash the "test suite" and
suggesting developer's to test scripts under it. The dash could be
fixed to correct any non-standard features it might contain.

I'm not sure what's the deal with /bin/posh vs /bin/dash; but from
testing and QA perspective the more the marrier; if script passes
both, then it must be in good shape.

Jari


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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> On Thu, 2006-11-23 at 13:43 +0200, Jari Aalto wrote:
> > 
> > Bash is not essential for running Debian. It is possible to run old
> > PCs and old laptops completely free of bash. The point here is not the
> > disk consumption, but the reduced memory constrainsts. When scripts
> > are written with only "sh" in mind, they become portable to even
> > embedded systems (think busybox). Every bash-dependent scipt that runs
> > on the system, takes memory out from other processes.
> 
> What about "perl".  Is that essential?  Why are you not going for big
> targets?

I don't see perl used that much for maintainer scripts, or daemon
scripts. As I explained in previous mails that there is no viable
alternative versions of Perl, like there are alternative versions of
shells.

Perl isn't likely to be included in embedded systems either.

> > Education sector and 3rd world still have PCs that are *years* and
> > *tears* old. Everybody do not live in countries where computers or
> > hardware are cheap.
> 
> Guess what?  I used bash on that old hardware when it was shiny and new
> also.  Didn't seem to have any problems.

The issue is not having or experiencing problems or not. The issue is
portability and making things work in wider spectrum than bash. People
have personal preferences and it is possible to accomodate those.

Some prefer bash and see no problems. Others consider bash's memory
consumption a problem when compared to other alternatives.

Jari



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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:

> On 23 Nov 2006 13:43:52 +0200, Jari Aalto <[EMAIL PROTECTED]> wrote:
> 
> There's a difference between requiring maintainer scripts to say
> /bin/bash if they need bash constructs and rewriting existing scripts
> to work with some generic shell. The former is going to be *much*
> easier. Isn't that enough?

My point. If there is explicit "Depends: bash", then someone can post
a patch to provide alternative solution to a person who may not know
alternative constructs (having learned only bashism).

Note, that I did not suggest rewriting any existing scripts, but I was
looking forward to making the need of bash more transparent that what
it is now in packages.

Jari



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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> On Thu, 2006-11-23 at 20:07 +0100, David Weinehall wrote:
> > On Thu, Nov 23, 2006 at 07:49:10PM +0100, Martijn van Oosterhout wrote:
> > [snip]
> > > 
> > > There's a difference between requiring maintainer scripts to say
> > > /bin/bash if they need bash constructs and rewriting existing scripts
> > > to work with some generic shell. The former is going to be *much*
> > > easier. Isn't that enough?
> > 
> > If you just want to avoid things breaking, it's enough.  If you want to
> > be able to use the scripts on an embedded platform, or to take advantage
> > of the performance boost of using dash instead of bash, it isn't.
> 
> Debian does not support every need.

I think the spirit of Debian is to be versatile and going towards it
or improving it is the spirit of itself.

Jari


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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> On Thu, 2006-11-23 at 20:46 +0100, David Weinehall wrote:
> > Well, let's hope people don't use any of the non-SuSv3 features of cat
> > in their shell scripts... 
> 
> Why?  Who cares? 
> 
> This is some huge amount of work for some very little benefit.

Some of us do. If we're interested in putting manpower and effort on
it, it soudnät bother anyone who does not care.

Jari


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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

David Weinehall <[EMAIL PROTECTED]> writes:

> On Thu, Nov 23, 2006 at 07:09:49PM +0100, Steinar H. Gunderson wrote:
> 
> Now the choice of 464kB or 4528kB on a desktop where you're actually
> using the shell for interactive things is probably not a big deal,
> personally I'd never use dash, posh, or busybox (except for rescue
> purposes)  on a desktop (or server, for that matter) other than for
> scripts.

Actually it is. In desktop (low memory PC; 64M or less), you open
several terminals to work efficiently. It's quite natural to have
10-20 open.

Count 20 x bash against some other alternative shell and the
consumed memory becomes apparent.

Jari



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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> On Thu, 2006-11-23 at 19:33 +0200, Jari Aalto wrote:
> > I don't see perl used that much for maintainer scripts, or daemon
> > scripts.
> 
> Exactly the *point*.  So why isn't this your target?
> 
> > Some prefer bash and see no problems. Others consider bash's memory
> > consumption a problem when compared to other alternatives.
> 
> The only alternative in Debian is dash, which explicitly says it's not a 
> replacement:
> 
>  "bash" is a better shell for most users, since it has some nice
>  features absent from "dash", and is a required part of the system.

This refers to inteactive use. dash suits well for scripts.

Jari


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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

David Weinehall <[EMAIL PROTECTED]> writes:

> On Thu, Nov 23, 2006 at 11:20:03AM -0800, Thomas Bushnell BSG wrote:
> > On Thu, 2006-11-23 at 19:33 +0200, Jari Aalto wrote:
> > > I don't see perl used that much for maintainer scripts, or daemon
> > > scripts.
> > 
> > Exactly the *point*.  So why isn't this your target?
> > 
> > > Some prefer bash and see no problems. Others consider bash's memory
> > > consumption a problem when compared to other alternatives.
> > 
> > The only alternative in Debian is dash, which explicitly says it's not a 
> > replacement:
> > 
> >  "bash" is a better shell for most users, since it has some nice
> >  features absent from "dash", and is a required part of the system.
> 
> dash is better for scripts (smaller memory footprint, faster), bash is
> better for interactive use.  Most users need a good interactive shell,
> hence it's better for most users.  That doesn't mean we should limit
> ourselves to using bash for non-interactive use though.

Right. Here is data for "alternative" interactive shells. Also 
available in graphical format.

E.g. *ksh shells like mksh are real replacements for bash in
interactive use in low memory systems.

Jari

Picture 17. Memory consumption of various shells. 
http://debian.cante.net/stem/faq/#can_i_save_even_more

PROGRAMS: shells

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
30933 foo   16   0  1664  464  396 S  0.0  0.1   0:00.00 dash

[1.x - 1.14.6]
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
10011 foo   17   0  3348 1988 1132 S  0.0  0.6   0:00.14 bash1

[3.x - 3.1.14]
  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
10229 foo   15   0  4692 1568 1260 S  0.0  0.5   0:00.33 bash   


  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
30781 foo   17   0  2372  996  744 S  0.0  0.3   0:00.01 esh

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 1579 foo   16   0  3032 1112  900 S  0.0  0.3   0:00.01 ksh 

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
32107 foo   16   0  1784  588  484 S  0.0  0.2   0:00.00 mksh

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 1602 foo   17   0  1764  536  440 S  0.0  0.2   0:00.00 pdksh

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
30899 foo   16   0  1676  544  448 S  0.0  0.2   0:00.00 posh

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
31445 jaalto17   0  6992 4928 2132 S  0.0  1.5   0:00.36 psh

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
31002 foo   15   0   808  204  164 S  0.0  0.1   0:00.00 sash

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
27122 foo   16   0  3800 2236 1596 S  0.0  0.7   0:00.14 zsh



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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Jari Aalto <[EMAIL PROTECTED]> writes:
> 
> To be frank, I don't think you're going to have a lot of luck.  Basically,
> you're trying to move bash into the same category as awk, where it's not
> explicitly essential and can be handled by something akin to alternatives,
> but given that this will require modifying all packages that use bash
> explicitly and there's little incentive for maintainers to do this unless
> it's made RC (and I have a hard time imagining that would happen), I don't
> think the transition is likely to happen.  It's a lot of work, and the
> amount of gain doesn't seem to warrant it.

I must have explained poorly then. 

- There is no need to make *any* changes to packages
- But it would be helpful if patches to make things transparent
  were made acceptable.

The problem is that policy gives a leverage to the maintainers to
shrug their shoulders to anything that touches something belonging
Essential: "It's there so I don't care". And when the Policy text
alleviates that "packages provided by Essestial need not be
mentioned", that the final straw.

Now, I'm asking for thinking it another way around:

- It's all good to announce only dpendencies that are not in Essential
- BUT, it should be encouraged to list all dependencies even if
  in essential.

This would change the whole mindset and expose package to full set of
dependencies if someone wants to do that. It sould also make it
possible to provide patches to the "Depends:". 

... and if someone cares anough, he could even start converting some
bashism to sh-only and send a patch. Encourageable practise again, 
if policy were with it.

Jari




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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Jari Aalto <[EMAIL PROTECTED]> writes:
> > Russ Allbery <[EMAIL PROTECTED]> writes:
> 
> >> To be frank, I don't think you're going to have a lot of luck.
> >> Basically, you're trying to move bash into the same category as awk,
> >> where it's not explicitly essential and can be handled by something
> >> akin to alternatives, but given that this will require modifying all
> >> packages that use bash explicitly and there's little incentive for
> >> maintainers to do this unless it's made RC (and I have a hard time
> >> imagining that would happen), I don't think the transition is likely to
> >> happen.  It's a lot of work, and the amount of gain doesn't seem to
> >> warrant it.
> 
> > I must have explained poorly then. 
> 
> > - There is no need to make *any* changes to packages
> 
> You proposed a wording change to Policy making adding a dependency to bash
> mandatory for packages that use bash.  That requires making changes to
> *lots* of packages.
> 
> Maybe you meant to propose a change that just made it *optional* to add a
> dependency on bash?

Correct. 
 
> > The problem is that policy gives a leverage to the maintainers to shrug
> > their shoulders to anything that touches something belonging Essential:
> > "It's there so I don't care". And when the Policy text alleviates that
> > "packages provided by Essestial need not be mentioned", that the final
> > straw.
> 
> Right, that's much of the point of Essential.  You've seen the Policy
> footnote, I presume?
> 
> Essential is defined as the minimal set of functionality that must be
> available and usable on the system even when packages are in an
> unconfigured (but unpacked) state. 

And making bash essential on the gounds that "must be available" is
not a good idea. I guess this is a chicken and egg situation

I'd rather make it read:

> Essential represents the minimal set of functionality that are 
> available on a system even when packages are in an
> unconfigured (but unpacked) state. 


> This is needed to avoid
> unresolvable dependency loops on upgrade. If packages add unnecessary
> dependencies on packages in this set, the chances that there will be
> an unresolvable dependency loop caused by forcing these Essential
> packages to be configured first before they need to be is greatly
> increased. It also increases the chances that frontends will be unable
> to calculate an upgrade path, even if one exists.
> 
> Also, it's pretty unlikely that functionality from Essential shall
> ever be removed (which is one reason why care must be taken before
> adding to the Essential packages set), but packages have been removed
> from the Essential set when the functionality moved to a different
> package. So depending on these packages just in case they stop being
> essential does way more harm than good.
> 
> That's a pretty strong argument against doing what you're proposing in
> general.  I think a lot of justification is required to change this.
> 
> > Now, I'm asking for thinking it another way around:
> 
> > - It's all good to announce only dpendencies that are not in Essential
> > - BUT, it should be encouraged to list all dependencies even if
> >   in essential.
> 
> I'm opposed to doing this for the reasons spelled out in Policy.  I think
> it adds a bunch of additional work and causes problems for dependency
> resolution with no significant benefit.


I think the policy should be implementation agnostic. What is referred
here is tying it to the dependency resolution algorithm that is true at a
particular time. I'm quite sure that the install case can be
made to skip any package that is mentioned in the "Depends: " that is
in the the list of Essential. Like:

Depends: bash, .

=> Algorithm:

Hm, bash is in the list of essential-packages.lst, drop it and
resolve only other packages mentioned in Depends:

Listing the packages in the Depends should not necessarily cause any
more work to the tools. I'm sure patches can me made to correct the
tools.

Jari


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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> On Fri, 2006-11-24 at 21:08 +0100, David Weinehall wrote:
> > You can use whatever bashisms you like when you're working
> > interactively, that won't hinder dash from executing shells on boot and
> > elsewhere.  Using bashisms in scripts does however cause a problem.
> 
> I think it's time to realize that "bash" specifies a programming
> language, and so does "dash".
> 
> Instead of focusing and hammering again and again on /bin/sh, why not
> instead ask maintainers to do #!/bin/dash?

Because the correct is #!/bin/sh and not to be tied on particular shell.

> > Oh, and there *are* other suitable interactive shells than bash.  tcsh,
> > ksh, zsh, rc...  Whether any of these actually consume less memory than
> > bash, I cannot say, since I'm a bash user myself on the desktop.  Yet
> > all the scripts I write run perfectly well (and faster) in dash.
> 
> I said that dash was not a substitute for bash, by its own claim.  This
> is like a game of whackamole.  If the claim is made that dash involves
> less disk space or memory use, it's nearly irrelevant, because bash will
> be there anyway.

Bash is not there "nayway". It is posisble to substitute it for the
reasons explained (memory consumption), without any significant loss of
interactive functionality.
 
> There may well be advantages to dash for this or that application.  So
> then, maintainers should be encouraged to use it.  The best way, of
> course, is #!/bin/dash.

The point was making script sh-agnostic. dash is just an
implementation of sh. Someone may very well use busybox or /bin/posh.

Jari


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

Re: Question about "Depends: bash"

[Jari Aalto]

Michelle Konzack <[EMAIL PROTECTED]> writes:

> Am 2006-11-22 01:15:59, schrieb Jari Aalto:
> 
> > The memory footprint[1] of bash is bothering in old PC's, so there are
> 
> But what do you mean with an OLD PC?
> 
> A 486?  Such computers should run busybox anyway.

PII with 62-128M, fairly common.
 
> For example my IBM TP570 (PII/366MHz/192MB)
> is happy with /bin/bash and fast enough.

"fast enought" is in the eye of a beholder. Try with PII/64M with
X deskop with 20 sessions of bash open. And opening firefox and xchat.
 
> > real benefits trying to make without it; even on command line sessions
> > where alternative shell, like /bin/mksh, whose capabilities will 
> > surpise even the bash enthusiasts.
> 
> I have tried a bunch of them and some have realy nice extension.  :-)

Anyway. What works for some is no indication of that it works for all.
I'm not sure why people are so enthustiastic with bash. It's just a
shell and there are alternatives to it - which are quite nice.

Jari


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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> On Thu, 2006-11-23 at 22:54 +0200, Jari Aalto wrote:
> > David Weinehall <[EMAIL PROTECTED]> writes:
> > 
> > > On Thu, Nov 23, 2006 at 07:09:49PM +0100, Steinar H. Gunderson wrote:
> > > 
> > > Now the choice of 464kB or 4528kB on a desktop where you're actually
> > > using the shell for interactive things is probably not a big deal,
> > > personally I'd never use dash, posh, or busybox (except for rescue
> > > purposes)  on a desktop (or server, for that matter) other than for
> > > scripts.
> > 
> > Actually it is. In desktop (low memory PC; 64M or less), you open
> > several terminals to work efficiently. It's quite natural to have
> > 10-20 open.
> > 
> > Count 20 x bash against some other alternative shell and the
> > consumed memory becomes apparent.
> 
> Somebody needs to explain to Jari the concept of a shared text segment.

And why do you think that? please take a look at the RES values.

Jari


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

Re: Question about "Depends: bash"

[Jari Aalto]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> On Sat, 2006-11-25 at 00:02 +0200, Jari Aalto wrote:
> > "fast enought" is in the eye of a beholder. Try with PII/64M with
> > X deskop with 20 sessions of bash open. And opening firefox and xchat.
> 
> What on earth is this nonsense about multiple invocations?  Do you not
> understand what shared text is?  
> >  
> > Anyway. What works for some is no indication of that it works for all.
> > I'm not sure why people are so enthustiastic with bash. It's just a
> > shell and there are alternatives to it - which are quite nice.
> 
> I never understood what was so wonderful about perl.  Yet, Debian
> decided to make perl Essential, so there it is.  Such decisions have to
> be made.
> 
> Nobody is telling you not to use the alternatives.  Go ahead! Use them!
> Encourage other people to!
> 
> But don't tell me that I *must* use the alternative.

I'm not sure I follow. I' puzzled why you do not seem benefit in:

- Making scripts sh-agnostict. That is making them portable
- Supporting low end systems with minimal of effort
- Improving the overall awaress of shells

What I gather so far, you have suggested that it is better to 
put the shell name /bin/bash in scripts that /bin/sh. I'm not sure why
should people need to install dash if equivalent sh-implementation
woudl do the same?

Could you elaborate.

Jari


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

Re: Question about "Depends: bash"

[Jari Aalto]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> > I'm not sure I follow. I' puzzled why you do not seem benefit in:
> > 
> > - Making scripts sh-agnostict. That is making them portable
> > - Supporting low end systems with minimal of effort
> > - Improving the overall awaress of shells
> 
> I don't care about the "awareness" of shells, no.
> 
> If we can support low end systems with *minimal* effort, fine, but you
> are asking lots of *extra* effort.

To my knowledge, I haven't or then there is a mixup somewhere.

> I don't care about making anything sh-agnostic.  bash is just a
> language; dash is just a language.  We don't insist that our C programs
> be C-compiler-agnostic; we don't insist that lisp or scheme programs be
> dialect-agnostic; why should we insist this for shell programs?

I'm not the right person to explain this. I would rather compare this
to the C compiler warnings:

- I don't care. The code compiles. Right?

Or saomeone who takes another approach:

- Oh, I dind't know that there were warnings having never used -Wall
  --pedantic. Give me a week and I'll fix those.
 
> If a maintainer wants to make a script that works with dash and posh and
> busybox, they can do that too.  
>
> They can even have a debconf option that
> asks the user which #! line to use.

The point is to make things generic. Like C which can be made to
compile in multiple platforms.

> None of this requires this obsessive nattering about /bin/sh.

Obsessive? The problem is not big. I haven't encountered any breakege
by using /bin/dash instead of /bin/bash in a year. It proves that the
maintainer scripts are already in a good shape. There is no big
"converting work" needed anywhere.

What would be good is that The Policy should encourage this practise
(like many maintainers do see value in this as demonstrated in their
scripts) instead of the current wording which discourages it.

Of of the problmes in this path is the status of bash in Essential,
which implies all the rest. Fortunately many maintainers are
professionals and see things from wider sh-perspective.

Jari



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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> On Fri, 2006-11-24 at 16:28 -0700, Bruce Sass wrote:
> > > > but it is Debian's job to be responsive to its users needs and
> > > > Debian has made a choice to strive for susv3 compatibility
> > >
> > > I don't think you understand what "compatibility" means in this
> > > context. It does not mean that you can substitute any component of
> > > the system with a different standards-compliant version and
> > > everything must continue to work.
> > 
> > So, what does "compatibility" mean in this context?
> 
> Debian has *achieved* susv3 compatibility.  There is nothing more to be
> done.
> 
> A compatible implementation is allowed to have special options "behind
> the scenes" which it uses to implement things.  Compatibility (actually,
> I believe the term is compliance) refers to the entire system, not its
> individual components.
> > 
> > > Our users needs do not, by and large, include embedded systems.
> > 
> > I am glad that "by and large" is not the standard, for that would make 
> > Debian somewhat less universal than it is.
> 
> *Yawn*. 
> 
> I don't care about making a distribution suitable for every possible
> purpose.  I see no shame in saying that we are suitable for some
> purposes and not others.

You don't have to care. There are people who do. Let them do the work.
That's how the Debian can come where it is now. It compiles in systems 
where none other distro does because people have cared to make porting
work.

Porting from bash to dash to towards generic sh-SusV compliance is
similar work. We could even talk about "standards-compliant" init
scripts

I'm sure you're not against work towards overall generalism. You
should not care if someone puts effort on it. Any work of this kind
should be highly encouraged and not discouraged.

Jari



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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> On Fri, 2006-11-24 at 23:55 +0200, Jari Aalto wrote:
> > > Instead of focusing and hammering again and again on /bin/sh, why not
> > > instead ask maintainers to do #!/bin/dash?
> > 
> > Because the correct is #!/bin/sh and not to be tied on particular shell.
> 
> I can't tell what you mean.  There is nothing wrong with using
> #!/bin/dash if that's what the maintainer wants to specify.

And if the system does not have dash installed? And if the scrpts work
fine with the /bin/sh of his choice?

Hard coding is always been bad. 
 
> > Bash is not there "nayway". It is posisble to substitute it for the
> > reasons explained (memory consumption), without any significant loss of
> > interactive functionality.
> 
> And around and around we go.  Dash itself say it is not suitable for
> interactive use, and, bash is an Essential part of Debian.
> >  
> > The point was making script sh-agnostic. dash is just an
> > implementation of sh. Someone may very well use busybox or /bin/posh.
> 
> Sure, if the maintainer thinks one of those is best, they could be used
> too.

And this is only possible if scripts use

/bin/sh

The  /bin/sh could be any valid shell that provided the standard set
of features. 

The installation system ("Essential") which sets /bin/sh to point to
/bin/bash in this respect has been a bad choice because people are not
aware of the bashinm they might be using as a result of it.

Jari


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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Hubert Chan <[EMAIL PROTECTED]> writes:

> On 23 Nov 2006 22:40:01 +0200, Jari Aalto <[EMAIL PROTECTED]> said:
> 
> > My point. If there is explicit "Depends: bash", then someone can post
> > a patch to provide alternative solution to a person who may not know
> > alternative constructs (having learned only bashism).
> 
> Sorry, but I don't understand what you're trying to do here.  Can you
> please explain what dependencies have to do with wishlist bugreports?

"Depends:" make dependency visible, whereas filing a wishlist is
usually result of someone by accident finding the script to include
bashism. He may offer a patch to convert those constructs to standard
sh-way-of-doing-things.

It's easier to eyeball packages that explicitly announce "bash".
Those could be  put to a stress test through:

/bin/dash
/bin/posh
...

If someone feels up to.

Jari


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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Mike Hommey <[EMAIL PROTECTED]> writes:

> On Sat, Nov 25, 2006 at 09:51:37AM +0200, Jari Aalto <[EMAIL PROTECTED]> 
> wrote:
> > And this is only possible if scripts use
> > 
> > /bin/sh
> > 
> > The  /bin/sh could be any valid shell that provided the standard set
> > of features. 
> > 
> > The installation system ("Essential") which sets /bin/sh to point to
> > /bin/bash in this respect has been a bad choice because people are not
> > aware of the bashinm they might be using as a result of it.
> 
> Maybe bash should restrict its features when called sh... like gzip
> changes its features when called gunzip, etc.

I think this would complicate the bash's C-code base unnecessarily.
The problem is not in the bash, but in the symlink. The proper way
would be to ship in etch+1

/bin/sh -> /bin/dash

And leave bash as it is now (in essential and for interactive use; as
a default shell). Breaking the symlink to bash of course would need
decision from the board that is resposible for such a change.

In practise the change will not be that big at all, because as
demonstrated, the Debian works fine and with no breakage if the
symlink points to dash[1]. It's good to know that developers pay
attention to lintian bashism warnings and the maintainer scripts are
in fact mostly "bash free".


Jari

[1] I can of course speak from perspective other than "testing" brach
where I have been running such systems for 1-2 years. The selected
packages however do not represent the whole set of packages, so there
is no doubt still bashim somewhere. But on the whole, all seem to work
nicely and I wouldn't expecte the transition to move to dash have big
impact.



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

Re: Proposed new POSIX sh policy, version two

[Jari Aalto]

Stephen Gran <[EMAIL PROTECTED]> writes:

> This one time, at band camp, Jari Aalto said:
> > "Depends:" make dependency visible, whereas filing a wishlist is
> > usually result of someone by accident finding the script to include
> > bashism. He may offer a patch to convert those constructs to standard
> > sh-way-of-doing-things.
> > 
> > It's easier to eyeball packages that explicitly announce "bash".
> > Those could be  put to a stress test through:
> 
> It's also relatively trivial to just run through the archive, looking
> for shell scripts and at least sh -n them from various shells of your
> choice.

Sure, but it's more time consuming that using the 'Depends: '

Jari


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

Re: Question about "Depends: bash"

[Jari Aalto]

Michelle Konzack <[EMAIL PROTECTED]> writes:

> Am 2006-11-25 00:02:34, schrieb Jari Aalto:
> > PII with 62-128M, fairly common.
> 
> ACK
> 
> > > For example my IBM TP570 (PII/366MHz/192MB)
> > > is happy with /bin/bash and fast enough.
> > 
> > "fast enought" is in the eye of a beholder. Try with PII/64M with
> > X deskop with 20 sessions of bash open. And opening firefox and xchat.
> 
> I do not know a singel person which open 20 xterms with bash at the
> same time.  On my IBM i have normaly 4-6 XTerms open, mozilla and gaim.

Try developing 10 software packages simultaneously (you leave the
session open and come back next day) possibly in different sites
(compiling ,aking manual, html pages, writng docs). Include piece of
version control tools and editors and you find you need *lots* of
rooms to play in.

And that is only a start.

Jari


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

Re: Do not use [EMAIL PROTECTED] for bug ping-pong

[Jari Aalto]

Don Armstrong <[EMAIL PROTECTED]> writes:

> On Fri, 15 Dec 2006, Marc Haber wrote:
>> But I feel that it is _wrong_ to close wishlist bugs like that. It
>> is ok to tag them wontfix or help, or even usertag them send-patch,
>> but closing them immediately doesn't help anybody but statistics.
>
> I personally don't close bugs capriciously either,[1] but it is the
> maintainer's right to do so. [I don't think there's much that can be
> done if a maintainer wants to be an ass short of hijacking their
> packages... thankfully, that's a course of action which I don't have
> to contemplate.]

Just theoretically, if such "an ass" maintainer exists or the behavior
can be demonstrated, wouldn't it be much better if some other
maintainer took over his work (hijacking the packages).

Isn't the goal to help Debian project much more important that
individual goals; that someone may misuse their position.

IS there a comiittee that can intervene or mediate in this matter if a
hijack seems justified?

Jari


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

BTS package to report bugs in "Debian New Maintainers' Guide"

[Jari Aalto]

[Please keep CC]

Where should the bugs found in "Debian New Maintainers' Guide" be
reported? BTS package name?

Jari



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

Old packages: when removed, what happens to them, where are they?

[Jari Aalto]

I've recently have an interest in using older Debian packages that
were once included in the distribution but then removed. The Debian
FAQ did not talk about this issue and tha packages.debian.org search
page did not offer option to look for old and removed packages.

What happens to them? Where can I browse and download the dusted
packages that were put away? [1]

Jari

[1] 

I'd need the xaw95 package, once uploaded to Debian xaw95
1.1-4.6potato1 (or newer) to build the small xrun program for use with
small window managers.



Maintainer: Joey Hess <[EMAIL PROTECTED]>
Description: 
 xaw95g - Windows 95-like look for X apps using the Athena widgets
Changes: 
 xaw95 (1.1-4.6potato1) stable; urgency=HIGH
 .
   * NMU. Fixed temp file security holes in AsciiSrc and MultiSrc
 widgets. Fix taken from X, which had the same problem.
   * Removed the libc5 stuff from the package, since it is no longer
 possible to build it on unstable, which lacks a libc5 xpm library.
   * Conflicts with old insecure libc5 package to ensure no users are
 left with it installed.
Files: 
 e1e851e56e8bd55e7aa7ad75d53e1795 579 x11 extra xaw95_1.1-4.6potato1.dsc
 8e2814e26829f8618407bddc2a8139a0 97389 x11 extra xaw95_1.1-4.6potato1.diff.gz
 ad465ec7dd6b7cdf155da49ed40fd0f1 1154248 x11 extra 
xaw95g_1.1-4.6potato1_i386.deb



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

Re: Bug#364319: base-files: PS1 setting for *ksh (PROPOSAL: /etc/profile.d/)

[Jari Aalto]

| On Sun, 23 Apr 2006, Jari Aalto wrote:
| 
| > | Please note that policy says:
| > |
| > |A program must not depend on environment variables to get reasonable
| > |defaults.
| > |
| > | The way I read this, whatever "good" defaults you think should be in
| > | /etc/profile, should be instead coded in the shells themselves
| > | as a default when no PS1 is set at all.
| >
| > The quote has no relevance in this point, because program's behavior
| > is not dependent on it.
| 
| Yes, it is relevant. We are using the PS1 environment variable to get
| a reasonable default for the prompt. If we followed policy, we should
| not be setting the environment variable PS1 so that bash gets a good
| default for the prompt. Same for any other shell.
| 
| So, instead of breaking policy even more (by adding more defaults to
| override the shell's internal "bad" defaults), we should be thinking
| about following policy closer, which means removing PS1 settings
| completely from /etc/profile in the long run.
| 

I feel that the current /etc/profile or the future (if that plan is
commenced) /etc/profile does not do any service whatsoever since it
does not improve the situation.

The policy's purpose should not to hinder development but guide it to
sensible direction that serves the Debian community, the end users.

What we need and what should have been done a long time ago, is to
modularize profile to /etc/profile.d/ where each program is resposible
for shipping reasonable defaults. Redhad has done this long time and
Cygwin does that too and it works very well.

This way all the other issues concerning configuration would be nicely
modularized. There would certainly be several packages that would
benefit from /etc/profile.d/ 

Jari


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

Re: System users and valid shells...

[Jari Aalto]

Richard A Nelson <[EMAIL PROTECTED]> writes:

> On Wed, 3 May 2006, Colin Watson wrote:
>
>
> The rest of the system accounts are happily running with /bin/false
>

There is now /bin/nologin which is more secure

Jari


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

Re: System users and valid shells...

[Jari Aalto]

Uwe Hermann <[EMAIL PROTECTED]> writes:
> On Fri, May 05, 2006 at 11:12:35AM +0300, Jari Aalto wrote:
>> > The rest of the system accounts are happily running with /bin/false
>> 
>> There is now /bin/nologin which is more secure
>
> I think you mean /usr/sbin/nologin, right? Please define "more secure"
> in this context.

The /bin/nologin records the user who tried to log in. This helps
auditing the system and provides more secure approach to system
monitoring.

/bin/nologin is straight replacement of /bin/false. It originates
from BSD systems.

Jari



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

Re: Intent to hijack Bacula

[Jari Aalto]

José Luis Tallón <[EMAIL PROTECTED]> writes:
>
> Hijacking a package without contacting the maintainer first is against
> the Developers' Reference and can only be considered a personal attack.
>
>
> I still don't know what is John Goerzen trying to achieve with this.
> More on this later.

This thread is refreshening in couple of points, because it opened
up discussion that may have become (or already is) a problem:

   1. somebody starts nurturing a package
   2. He's eager at start, but the steam doesn't last long
   ..
   3. package slowly drops under lower and lower of pile of works
  * taking care of things is starting to take too much time
  * lacked experience in the first place?

   4. The package starts being "unmaintained"[1]. Bug reports gow and
  grow and nothing happens in year.

Just look at some packages, where bug reports have last been addressed
several years ago. Not good at all.

Then, a miracle happens

   Person with competence comes, pulls up his sleeves and 
   puts the package in shape.

   Voila, the package is maintained again.

Now, the orignal packager is not pleased at all. because

   IT'S MY PACKAGE. IT BELONGS TO ME. 
   -- Lord of the rigs echoing...

ALTERNATIVE STRATEGY - BEING DYNAMIC

The developer manual could say something about non-active packages and
suggest clear procedures. Or the quality team should seek more closely
for MIA maintainers, who have bugs hanging in their packages that date
years back.

Unmaintained packages are not a healthy situation. The maintenance
process should encourage:

 hijacking[2]

The current process unfortunately encourages keeping the status quo,
to not do "hijacks". The problem is that status quo doesn't promote
change; it discourages being dynamic, being active, taking active
role.

In contract being active and taking maintainership:

Get work done! Good!

=> Will serve the end users of package

=> Will satisfy all the 3rd party people that *care* to submit
   bug reports in the hope that things will evolve

=> Will possibly activate the orig. maintainer of package from sleep

A sleeping maintainer is a bad thing. It woudl be good if the the
process alleviated that packages are not "personal artefacts", but
shared properties. 

The end result is the only important one. To my understanding, the
goal is "to provide common good" -- that is: to provide service to end
users.

Jari

[1] Seasoned maintainers know the right thing: Orphan. Some
unfortunately cling on victory marks, and don't want to let go. 

[2] Hijacking is not the same as lasking manner. There could be
clearly laid out rules for grace periods and time limits for original
maintainer to show the will to become active again. Otherwise the
package would be "up for grabs" with no further discussion needed.

In some way the "hijacking" is already encourages in small scale by
the NMU process. But in those cases the person fixing things usually
does not want to become new maintaineg; he only wanted to get fixes
in.


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

Re: stumpwm: Clarify README.Debian - can't understand a thing how to start this wm

[Jari Aalto]

| 
| tags 356948 + help
| retitle 356948 stumpwm: clarify how to start this WM in the README.Debian
| thanks
| 
| Hello!
| 
| For d-d: I'd like a more general advice about the user request, which
| I'm quite reluctant to accomplish.
| 
| For all: please honor the R-T and M-F-T headers (no need to cc: me).
| 
| On Fri, 02 Jun 2006 19:05:01 +0200, Jari Aalto wrote:
| > The debian/control::Description reads:
| [...]
| > From "StumpWM is a window manager written entirely in Common Lisp"
| > it suggests, that is is just another window manager only that the
| > host language is common lisp.
| 
| Well, as I already explained in my previous reply [1], you need a
| specific background in Common Lisp to use this WM.  Moreover, the
| package section is specifically set to "devel" and not "x11" as most
| of the other WMs.

This is all good, but I don't think visible enough to an end user.
If first line in debian/Control::Description would make the intention
clear clear, it would solve the bug as far as I'm concerned.

   BEFORE

Description: a Common Lisp window manager
 StumpWM is a window manager written entirely in Common Lisp. It
 ...

   AFTER

Description: a Common Lisp window manager
 Note: this is not and end user program; i.e. a regular window manager.
 .
 StumpWM is a window manager written entirely in Common Lisp. It
 ...

That leaves open how to generally resolve similar cases in other
packages.

Jari


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

Bug#363486: dpkg: [update-alternatives] New categories for: WORD, EXCEL, MEDIA-PLAYER etc.

[Jari Aalto]

| Guillem Jover <[EMAIL PROTECTED]>:
| reassign 363486 debian-policy
| 
| each package should agree on which interface is needed to be able to
| provide a specific alternative. And if they should provide a virtual
| package for it.
| 
| On Wed, 2006-04-19 at 14:44:08 +0300, Jari Aalto wrote:
| > Package: dpkg
| > Version: 1.13.18
| > Severity: wishlist
| > 
| > There are many programs that act on a file that contains certain extension
| > or if they support MIME types, they look up the program associated with it.
| > 
| > The problem is that there are many programs to do the same thing. For 
example
| > Person trying to open "File Manager" must remmeber that the
| > esoteric names are
| > 
| > xfe
| > mfm
| > emelfm
| > worker
| > krusader
| > endeavour2
| > rox-filer
| > thunar 
| > ...
| > 
| > The same problem is with Office programs:
| > 
| > lyx
| > abiword
| > oowriter
| > ...
| > 
| > The /etc/alternatives contains a good framework to canonicalize actions to
| > common names available in system and to control the preferred program.
| > 
| > SUGGESTION
| > 
| > Create new alternatives with names something like:
| > 
| > x-office-word
| > x-office-excel  
| > x-file-manager
| > x-archiver  
| > x-media-player  or "video-player"
| > x-music-player  For music
| > 
| > This way numerous programs could refer to common program "music-player",
| > which the arternatives frame work would provide. The generic names would
| > also add simplicity to overall handling of the various binaries that
| > would hook themselves to the alternatives base.
| > 
| > Small window managers (Other than the KDE, Gnome, Xfce) would also
| > benefit from this, because they could use generic menu items and call
| > the "alternatives" name without the need to refer to certain binary,
| > which may not be installed.

To Debian Policy ML:

Is there any coordinated effort to standardize the name of the provided
programs in /etc/alternatives? 

I revised the above proposal by adding prefix:

  x-*

for programs requiring an X environment.

Jari


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

Re: [cl-debian] Bug#356948: stumpwm: Clarify README.Debian - can't understand a thing how to start this wm

[Jari Aalto]

| On 12/06/06, Jari Aalto <[EMAIL PROTECTED]> wrote:
| > |
| > | tags 356948 + help
| > | retitle 356948 stumpwm: clarify how to start this WM in the README.Debi=
| an
| >AFTER
| >
| > Description: a Common Lisp window manager
| >  Note: this is not and end user program; i.e. a regular window manage=
| r.
| 
| Why not just use cl-launch to make it an end user program too???

Sure, whatever is appropriate. Please add the needed support,
instructions or documentation in that case.

Jari



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

Bug#363486: dpkg: [update-alternatives] New categories for: WORD, EXCEL, MEDIA-PLAYER etc.

[Jari Aalto]

| an off-topic question:
| 
| why x-office-word, x-office-excel, etc?
| are these trying to express "the replacement for microsoft windows
| word, excel" ?
| or is this what text documents or spreadsheet documents being called?

It's almost industry standard to refer to "Word" as the word processor
program, similarly "Excel", but as suggested below

  x-word-processor
  x-office-spreadsheet

will do nicely too. I'll recap this issue in Debian devel.

Jari

| On 6/12/06, Margarita Manterola <[EMAIL PROTECTED]> wrote:
| > On 6/12/06, Jari Aalto <[EMAIL PROTECTED]> wrote:
| > > Is there any coordinated effort to standardize the name of the provided
| > > programs in /etc/alternatives?
| >
| > I don't think this concerns debian-policy at all.  The use of
| > alternatives is something that needs to be coordinated amont the
| > maintainers of packages.  It's not a question of policy or of dpkg.
| >
| > So, in order to have an alternative link for x-word-processor or
| > x-spreadsheet, you need to file wishlist bugs against the packages
| > that would be involved, and then have the maintainers  agree with each
| > other what to do.
| >
| > But, before doing so, it would be a good idea to discuss about this on
| > debian-devel.  I suggest you post the original proposal to
| > debian-devel, explaining the full rationale on why you want this, what
| > would need to be changed, what would be the benefits for the users and
| > what would be the maintainers' resposibilities.
| >
| > --
| > Besos,
| > Marga


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

Re: wnpp situation

[Jari Aalto]

Bas Zoetekouw <[EMAIL PROTECTED]> writes:

> Hi David!
>
> About ITP's, they should be retitled to RFPs, rather than closed.  That
> way, other people can have a go at packaging the software.
>

I concur. If someone did not produce a packge withing NN days (say 3
months) after ITP, the system should automtically send the ITP
sumitter mail, that his packaging effort has been returned to stae RFP
and he is no longer the "owner" of that ITP.

Jari


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

Re: better init.d/* : who carres ?

[Jari Aalto]

Alfie Costa <[EMAIL PROTECTED]> writes:

| Wed, 21 Sep 2005 09:32:41 +, Gerrit Pape wrote:
| 
| ...but try come up with a rule of thumb for '%%' (big suffix), '#' 
| (small prefix), etc.?  Maybe the 'p' in percent is for Prefix -- but no, 
| the Prefix is the hash symbol; two signs are bigger than one, like Roman 
| numerals... it's a puzzle.

It's in fact easier; the keys can be visualized easily. On keyboard:

# %

is on the leftis on the right

So, "Delete left" or "Delete right". And the more character, there
more deletion (That's %% and ##).

Jari


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

Re: Bug#545782: imagemagick-dbg: missing README.Debian to explain how programs are used

[Jari Aalto]

"Nelson A. de Oliveira"  writes:
>> README.Debian to explain how programs are used". Please provide
>
> The problem here is that we have a lot of -dbg packages on Debian
> Do we need the same README file on all of them?
>
> ...the package maintainer is responsible in helping the user to get a
> backtrace ... Or at least an explanation in the gdb package only.

Neil Williams  writes:

> Once the -dbg packages are installed:
> $ gdb /usr/bin/convert
>
> The rest is down to the gdb manpage, no?
>
> gdb does all the work of locating /usr/lib/debug/usr/bin/convert, hence
> all such files are mode 0644.
>
> That is down to the gdb manpage, not every single -dbg package in the
> entire archive IMHO. There are other sources of info too, like the Wiki.
>
> http://wiki.debian.org/HowToGetABacktrace

In latest lintian, a message was added that warned about missing

debian/REAADME.source

in order to document the used patch system (dpatch, quilt etc.). It
could have been be argued that this information were already available
in the manual pages.

I think the the added check in lintian was a good thing and that it had
an impact in making used patching system more explicit.

It would be good if something similar were adopted to *-dbg packages as
well. The best would be to simply point to a location where this
information would be available, like the Wiki you mentioned:

http://wiki.debian.org/HowToGetABacktrace

If this is not mentioned in the package itself, this information is not
readily available.

Jari


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Jari Aalto]

FOREWORD

I have seen following construct to be used in shell-context
(makefiles, sh-scripts, Perl):

  `cmd` [1]

However, the POSIX standard and SUSv[23] declares alternative way of
accomplishing the same with in *sh context:

  $(cmd) [2]

I would see following problems quality wise with [1]:

- The backtick version is not easily readable in high resolution screens
  or in terminals with small fonts 

- There may be problems in distinguishing character ' from ` with sme
  particularly selected font.

- The missing backtick is hard to find in highly quoted context, where
  single, double quotes and backticks play the code tune.

- The backtick is awkwardly located in some keyboards. (possible
  orphan/adopt/NMU maintenance problem)

- Lastly, isually impaired people have problems with non-easily
  dintinguishable content. ' and ` fall into this category.

All Debian *sh compatible shells support $() and are thus POSIX/SUS
compliant in this respect. 

BUG REPORTS -- AND REPONSES

I have reported bugs against backtick and suggested to change to use
the more readable alternative. The result was surprising. To quote
one message (bug closed reasoning):

 "If your development environment cannot display ` differently than ' ,
 you need to get a new one."

I'm askinf if it is ok to to reopen such bugs based of better QA
aspects. Possibly by providing patches if the maintainer is busy
elsewhere to handle such a "minor issue" from his perspective.

Jari

REFERENCES

The Single UNIX Specification, Version 2 (SUSv2):
"Shell Command Language"


...The input characters within the quoted string that are
also enclosed between "$(" and the matching ")" will not
be affected by the double-quotes, but rather define that
command whose output replaces the $(...)


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

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Jari Aalto]

John Goerzen <[EMAIL PROTECTED]> writes:

> On Fri, Feb 09, 2007 at 07:26:21PM +0100, Marco d'Itri wrote:
>> > I'm askinf if it is ok to to reopen such bugs based of better QA
>> > aspects. Possibly by providing patches if the maintainer is busy
>> > elsewhere to handle such a "minor issue" from his perspective.
>> No, it's not. Even if a patch is provided, handling a bug is a time
>> consuming activity (*horribly* time consuming if the patch is for
>> upstream code).
>> If you really think this crusade is worth being pursued then I suggest
>> you just mail patches to Debian maintainers for original scripts and to
>> the upstream maintainers for the rest.
>
> I agree.  And I would add that this is not a bug (not a defect, etc) at
> all.  It is perfectly valid syntax.  

The issue was not whether the syntax is valid or not. Given that there
are alternatives, there might be reasons what would be in favor of one
of the two.

Le't call this "wishlist" if we need to be pedantic. I would still
call this a bug from a QA perspective. Quality is more than "valid
syntax".

> If you're going to open up bugs on this, then you might as well file
> a bug against the kernel for not indenting like GNU does, against
> libc for not indenting like Linus does, and against gnome for not
> indenting like either of them do.

I don't see choice in the indentation character "{", so it's not
comparable. Besides Kernel has a written Coding Style that they
follow, so the "quality aspects" haave been recorded, so this is not
comparable either.

Jari



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

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Jari Aalto]

"Wesley J. Landaker" <[EMAIL PROTECTED]> writes:

> On Friday 09 February 2007 11:11, Jari Aalto wrote:
>> I have reported bugs against backtick and suggested to change to use
>> the more readable alternative. The result was surprising. To quote
>> one message (bug closed reasoning):
>>
>>  "If your development environment cannot display ` differently than '
>> , you need to get a new one."
>>
>> I'm askinf if it is ok to to reopen such bugs based of better QA
>> aspects. Possibly by providing patches if the maintainer is busy
>> elsewhere to handle such a "minor issue" from his perspective.
>
> IMHO:
>
> I would be happy to see bugs against my own packages that *clearly* 
> increased usability and readability of code, as long as they included 
> tested, working, patches.

I think this requirement is too high. A simple message sent to me
suggesting alternatives has always go my mind processes going. No need
to require full test suite and all that, because the developer knows
how to fill in the gaps.

> But a bug that asks to change coding style just for the sake of style or 
> preference of someone who isn't even working on the software at all 
> wouldn't be as welcome.

Style changes over the time. New ideas always open up mind to see
things from other perspective, so it's not that "status quo" is the
preferred solution in software methodology (Think Extreme
Programming/Agile where refactoring is the motivation factor of
keeping code always up to date to current standards)

Jari


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

Re: Too much disruptive NMUs

[Jari Aalto]

Ana Guerrero  writes:
>
> It is good to care for packages from people who are currently too busy and
> making NMUs to fix critical/very important bugs. However, lately I have been
> seeing a lot of NMUs that are being very disruptive

Hi Ana,

The packages I took under close look have been carefully selected and
any possible "active" were either contacted or notified about the
upcoming NMU. I also participated #debian-qa to ask for MIA of certain
people when in doubt.

Via email, those that I contacted, were happy to responded "OK" with the
changes.

We've coordinated the uploads with Tony during period of 3 months, for
the upcoming release. The uploads were always put to DELAYED/NN, and
extra time (14 days) were given for some packaged for developers to
react.

The debian/changes lists may look "verbose", but the actual chages are
really minor. I prefer explicit changelogs so that peer-review is
possible.

In addition to fixing the RC bugs, minor updates were usually done at
the same time. This was done for the reasons that in case the packages
were later orphaned or the maintainer were MIA, it would be more
desireable to have a well shaped package in archive. The minor changes
include:

- update to latest debhelper (In many times no debian/rules changes;
  possibly update deprecated dh_clean to dh_prep")
- use packaging format 3.0 (delete quilt if it was used)
- update compat to 7

The DEP1 does't specifially encourage fixing anything else than the BUG
at hand, and that's a very good rule for actively maintained packages.

However these uploads you were seeing were for packages that:

- had very old bugs
- or were not actively maintained (developer not seen in years).

So I felt a "shaping up" would be in the spirit of good maintenance.

Jari

[1] http://dep.debian.net/deps/dep1.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hblyg3dx@jondo.cante.net

Re: Too much disruptive NMUs

[Jari Aalto]

Alexander Wirt  writes:
>> Jari Aalto schrieb am Sunday, den 23. May 2010:
>>
>> [When package was not maintained]
>>
>> In addition to fixing the RC bugs, minor updates were usually done at
>> the same time. This was done for the reasons that in case the packages
>> were later orphaned or the maintainer were MIA, it would be more
>> desireable to have a well shaped package in archive. The minor changes
>> include:
>> 
>> - update to latest debhelper (In many times no debian/rules changes;
>>   possibly update deprecated dh_clean to dh_prep")
>> - use packaging format 3.0 (delete quilt if it was used)
>> - update compat to 7
>
> I don't find anything of them acceptable for an nmu.
>
>> The DEP1 does't specifially encourage fixing anything else than the BUG
>> at hand, and that's a very good rule for actively maintained packages.
>
> That dep thingys are no policy. imho these uploads violate the nmu policy.

It was later turned into policy.

So there is not room for discreet judgement for cases like:

- active maintainer

- non-active maintainer and for case like: years old package, 6+
  months old FTBFS, or ancient 3.[56].x policy in debian/control?

That'd be a loss, quality wise.

Jari


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739xid80z@jondo.cante.net

Re: Bug#595427: wnpp: ITP: winetricks -- Quick and dirty script to download and install variousredistributable runtime libraries

[Jari Aalto]

Date: Tue, 15 Mar 2011 20:52:05 +0200
Message-ID: <87k4g0fc8a@picasso.cante.net>
MIME-Version: 1.0
Content-Type: text/plain
--text follows this line--
> Andreas Barth 
> 
> 
> I agree that starting with the current scripts is for starters. But we
> should do it in a way that is prepared for doing it right, and then
> starting with the easier parts of replacing the scripts with the right
> libraries.
> 
> Obviously there are some very low hanging fruits within the
> winetricks-scripts (basically everything that is downloaded from an
> open source site).

What is the status of this ITP opened 2010-10-03, 6 months ago? To my
understanding winetricks:

- is DFSG compliant. The current license is GPL.

- does not depend on external programs outside of Debian.

- is a single utility that helps quite a bit to install WINE related
  software much easier.

- has nothing to do with WINE package itself, so bundling it would
  not be good. Winetricks update schedule is different from WINE.

- There is no sense of making integration "packages for WINE" like
  those of Perl and Python, because WinE/Windows is too unstable
  platform to target at.

Could we just package it as is for the benefit of the users?

Jari


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipvkfc86@picasso.cante.net

Re: Bug#595427: wnpp: ITP: winetricks -- Quick and dirty script to download and install variousredistributable runtime libraries

[Jari Aalto]

2011-03-15 21:24 Austin English :
> On Tue, Mar 15, 2011 at 13:52, Jari Aalto  wrote:
>>    - does not depend on external programs outside of Debian.
>
> ...vast majority of its uses requires downloading things from outside of
> Debian, typically with a potentially non-DFSG license (Microsoft
> redistributable dlls being one of the most common).

But that does not conern Debian. The winetricks itsef is LGPL and DSFG
compliant.

>
>>    - has nothing to do with WINE package itself, so bundling it would
>>      not be good. Winetricks update schedule is different from WINE.
>
> Actually, we're looking at making the release schedule match Wine's
> (every other Friday), to make it easier to package. That said, it's
> not a huge deal at the moment, since Debian hasn't updated Wine in
> ages (still waiting on mingw64 to build wine-gecko, last I checked,
> but I'm not intimately familiar with the situation).

If I understand correct, there are no obstacles left with proceeding with
the packaging of winetricks?

Jari


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3licmna@picasso.cante.net

DEP5: minor suggestions - FSF address etc.

[Jari Aalto]

I'd like to propose updates to:

http://dep.debian.net/deps/dep5/

(1) Use URL instead of real FSF address everywhere

-You should have received a copy of the GNU General Public
-License along with this package; if not, write to the Free
-Software Foundation, Inc., 51 Franklin St, Fifth Floor,
-Boston, MA  02110-1301 USA
+You should have received a copy of the GNU General Public License
+along with this program; if not, see .

Rationale: FSF recommendation
:

...
You should have received a copy of the GNU General Public License
along with this program. If not, see .

(2) No ending commas in years

Example 1. tri-licensed files
Example 2. recurrent license

Files: src/js/editline/*
-Copyright: 1993, John Doe
-   1993, Joe Average
+Copyright: 1993 John Doe
+   1993 Joe Average

Rationale: Commas are used between years ,,YYY and not at the
end. Compare to section "Copyright" where there are no ending commas.
See also FSF recommentation
:

Copyright (C) year1, year2, year3 copyright-holder

(3) Uniform Layout

E.g.

-Copyright: 1993 John Doe
-  1993 Joe Average
+Copyright:
+ 1993 John Doe
+ 1993 Joe Average

Rationale: The whole document uses one-space indent for consequtive
lines.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d39ly8hb@cante.cante.net

Re: DEP5: minor suggestions - FSF address etc.

[Jari Aalto]

2012-02-11 20:44 Charles Plessy :
| Le Sat, Feb 11, 2012 at 12:23:12PM +0200, Jari Aalto a écrit :
| http://dep.debian.net/deps/dep5/
|
| > (1) Use URL instead of real FSF address everywhere
|
| The examples contain license notices for the GNU GPL version 2, and in
| these there is no URL but the postal address. The current practice in
| Debian is to update if needed the postal address in the GPL notices
| version 1 and 2 (lintian tag old-fsf-address-in-copyright-file), but not
| to replace them by the URL of the latest GPL. I would prefer that the
| examples do make implicit suggestions to do so.

In my opinion, we should follow strictly how FSF recommends the GPL to be
presented. The use of postal addresses is no longer the FSF's current
postion.

.. and what a headache it all was when they moved their office. All License
texts had to be revised. That's a reason enough to stick to the FSF
recommended format that uses URL.

Jari


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ty2sjtqa@test20.cante.net

Re: DEP5: minor suggestions - FSF address etc.

[Jari Aalto]

2012-02-11 20:44 Charles Plessy :
| Le Sat, Feb 11, 2012 at 12:23:12PM +0200, Jari Aalto a écrit :
|> (2) No ending commas in years
|
| I would apply this change if it were supported by more people, but given
| that the object of DEP 5 is to record upstream license and copyright
| statements, and given that Upstreams write such statements using many
| different styles, I would prefer to not normalise the examples and give
| the impression that the copyright statements need to be normalised to be
| compliant with the machine-readable format.

I though that DEP5 was intended to use for Debian and not to record how
upstram chose to write their copyright statements.

I feel that Debian should focus on standards and therefore also present
those standards in DEP documents to the readers that follow the DEPs.

In this case, the FSF lawyers probably know how to write proper Copyright
statements, as they have instructed:

<http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html>

A copyright notice looks like this:
Copyright (C) year1, year2, year3 copyright-holder

The word ‘Copyright’ must always be in English, by international
convention.

...

You can use a range (‘2008-2010’) instead of listing individual years
(‘2008, 2009, 2010’) if and only if: 1) every year in the range,
inclusive, really is a “copyrightable” year that would be listed
individually; and 2) you make an explicit statement in a ‘README’ file
about this usage.

In addition, typographically, it's illogical to have ending-commas in
written text like that.

Jari



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqdgjtdf@test20.cante.net

[PATCH] dep5.mdwn: Fine tune Copyright header description and examples

[Jari Aalto]

** CC: DEP5 drivers
** Here is a small patch to update the DEP5's Copyright examples
** See also FSF copyright year use recommendations at
   http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html

In "Files paragraph (Repeatable)"

- Drop duplicate word "Copyright"; already included in header "Copyright:"
- Use - range.
- Enclose examples in markdows backticks i.e. .
- Clean up extra whitespaces from empty lines.

In "Standalone License Paragraph (Optional, Repeatable)"
- Canonicalize "Copyright:" header to use 1 space indentation
  as used in other headers.
- Drop duplicate word "Copyright"; already included in header "Copyright:"
- Clean up extra whitespaces from empty lines.
- Add email addresses to names of copyright holders.

In "Complex"
- Canonicalize "Copyright:" header to use 1 space indentation
  as used in other headers.
- Drop unused comma after year element in copyright holder lines.
  Comma would be used with multiple discrete years like in
  , +3, +5; see FSF recommendation.

Signed-off-by: Jari Aalto 
---
 deps/dep5.mdwn |   63 +--
 1 files changed, 33 insertions(+), 30 deletions(-)

diff --git a/deps/dep5.mdwn b/deps/dep5.mdwn
index 4bb4ef6..ae711c3 100644
--- a/deps/dep5.mdwn
+++ b/deps/dep5.mdwn
@@ -234,19 +234,19 @@ ## Files paragraph (Repeatable)
  individual file, and years of publication for one copyright holder may
  be gathered together.  For example, if file A has:
 
- Copyright 2008 John Smith
- Copyright 2009 Angela Watts
+ `Copyright (C) 2008 John Smith`
+ `Copyright (C) 2009 Angela Watts`
 
  and file B has:
 
- Copyright 2010 Angela Watts
+ `Copyright (C) 2010 Angela Watts`
 
- the Copyright field for a stanza covering both file A and file B need
+ the "Copyright:" field for a stanza covering both file A and file B need
  contain only:
 
- Copyright 2008 John Smith
- Copyright 2009, 2010 Angela Watts
- 
+ `2009-2010 Angela Watts`
+ `2008 John Smith`
+
 The Copyright field may contain the original copyright statement
 copied exactly (including the word "Copyright"), or it can
 shorten the text, as long as it does not sacrifice information.
@@ -308,15 +308,15 @@ ## Files paragraph (Repeatable)
 Files: *
 Copyright: 1975-2010 Ulla Upstream
 License: GPL-2+
-
+
 Files: debian/*
 Copyright: 2010 Daniela Debianizer
 License: GPL-2+
-
+
 Files: debian/patches/fancy-feature
 Copyright: 2010 Daniela Debianizer
 License: GPL-3+
-
+
 Files: */*.1
 Copyright: 2010 Manuela Manpager
 License: GPL-2+
@@ -337,16 +337,17 @@ ## Standalone License Paragraph (Optional, Repeatable)
 Example 1 (tri-licensed files).
 
 Files: src/js/editline/*
-Copyright: 1993, John Doe
-   1993, Joe Average
+Copyright:
+ 1993 John Doe ,
+ 1993 Joe Average 
 License: MPL-1.1 or GPL-2 or LGPL-2.1
-
+
 License: MPL-1.1
  [LICENSE TEXT]
-
+
 License: GPL-2
  [LICENSE TEXT]
-
+
 License: LGPL-2.1
  [LICENSE TEXT]
 
@@ -354,12 +355,13 @@ ## Standalone License Paragraph (Optional, Repeatable)
 Example 2 (recurrent license).
 
 Files: src/js/editline/*
-Copyright: 1993, John Doe
-   1993, Joe Average
+Copyright:
+ 1993 John Doe 
+ 1993 Joe Average 
 License: MPL-1.1
 
 Files: src/js/fdlibm/*
-Copyright: 1993, J-Random Corporation
+Copyright: 1993 J-Random Corporation 
 License: MPL-1.1
 
 License: MPL-1.1
@@ -599,7 +601,7 @@ ## Simple
 Source: ftp://ftp.example.com/pub/games
 
 Files: *
-Copyright: Copyright 1998 John Doe 
+Copyright: 1998 John Doe 
 License: GPL-2+
  This program is free software; you can redistribute it
  and/or modify it under the terms of the GNU General Public
@@ -623,7 +625,7 @@ ## Simple
  `/usr/share/common-licenses/GPL-2'.
 
 Files: debian/*
-Copyright: Copyright 1998 Jane Smith 
+Copyright: 1998 Jane Smith 
 License:
  [LICENSE TEXT]
 
@@ -638,15 +640,16 @@ ## Complex
 Source: http://www.example.com/code/venus
 
 Files: *
-Copyright: 2008, John Doe 
-   2007, Jane Smith 
-   2007, Joe Average 
-   2007, J. Random User 
+Copyright:
+ 2008 John Doe 
+ 2007 Jane Smith 
+ 2007 Joe Average 
+ 2007 J. Random User 
 License: PSF-2
  [LICENSE TEXT]
 
 Files: debian/*
-Copyright: 2008, Dan Developer 
+Copyright: 2008 Dan Developer 
 License:
  Copying and distribution of this package, with or without
  modification, are permitted in any medium without royalty
@@ -654,27 +657,27 @@ ## Complex
  preserved.
 
 Files: debian/patches/theme-d

Re: severities of blocking bugs

[Jari Aalto+usenet]

* Fri 2006-06-09 Ian Jackson 
> If some program lacks a feature or bugfix you want for your package,
> then _implement it_ instead of whining !
>
> Most maintainers are much more cooperative when you tag the bug as
> +patch and say something like:

Nope. If you happend to send a patch to fix the problem, there are as
many responses as there are developers. I've got messages saying
"I/We're not interested".

> As opposed to writing to demand that the maintainer spend their free
> time to help you fix your problem !

Wrong. The person responsibnle for the package is responsible for
the bugs and features (coordinating them to upstream); overall things
for the whole package.

This responsibility cannot be put on the shoulders of others.
Everybody is on their free time, the bug submitter included. The
packager has *taken* the burden, so he should also carry it. Or
otherwise he is not the right person for the maintenance - it's not a
parking garage.

> Remember also that the purpose of bug reports is to help us improve
> the package.  The purpose of bug reports in Free software is _not_ to
> solve the submitter's problem !  (Although that's sometimes a helpful
> side-effect.)

Features and improvements raise on the field. Anything that can be
improved and make quality better can be considered bug (severity may
differ).

Jari



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

Re: Debian Light Desktop - meta package

[Jari Aalto+mail.linux]

* Wed 2006-06-07 Axel Beckert 
* Message-Id: 20060607001535.GT3066 AT fsinfo.cs.uni-sb.de
> Hi!
>
>> I'm creating a meta package for install a lite desktop for old
>> machines with poor hardware.
>
> Hey, that's a really cool idea! Debian is one of the last modern (and
> not specialised) Linux distribution feasible for old and slow
> hardware, especially old PCs. But Sarge already made a big step away
> from old PCs (e.g. by dropping XFree86 3.3 and requiring 32 Megs of
> RAM for installation -- Woody needed only 12 Megs) so I'm really happy
> to see that others try to take the cudgels for Debian on old hardware
> too.

FYI,

I've already have a running a project to provide a very light, very
low profile Desktop for Debian. The project is ready to install[*] and it
has been tested for old harware running 64M/166 (even lower) needs.

The project page is at:

  http://debian.cante.net/stem

The extra packages currently used are optional and some that are
missing are being ported to Debian.

At the end of opening page you will find listing of programs
used for the desktop. 

http://debian.cante.net/stem/package.lst

The WM choices currently are:

- Jwm window manager (very light)
- Fvwm95 (the "standard look"), moderate memory consumption.

You will also find study on programs that were evaluated to build up
the desktop from pictures of memory consumption graphs.

   http://debian.cante.net/stem/manual
   http://debian.cante.net/stem/faq

Suggestions how to eventually be included it in Debian, please comment
how this could be done. I'm not a DD yet.

Jari

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

[*] The bugs are being ironed out, but in general it's
ready for the prime time.

Repository

deb http://debian.cante.net/debian unstable main
deb-src http://debian.cante.net/debian unstable main

There is automatic install script (asks few questions)
  
wget -qN http://debian.cante.net/stem/netinstall.sh
sh netinstall.sh [--help]

or install can be done manually (for expert only)

apt-cache search ^stem-
apt-cache show 


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

Re: Bug#363486: dpkg: [update-alternatives] New categories for: WORD, EXCEL, MEDIA-PLAYER etc.

[Jari Aalto+mail.linux]

* Tue 2006-06-13 Josselin Mouette 
* Message-Id: 1150231486.17236.21.camel AT utena.localnet
> Le lundi 12 juin 2006 à 20:44 +0200, Kurt Roeckx a écrit :
>
>> I think you're not very clear in what you're asking, so I'm going
>> to try and explain what I think you said.
>> 
>> If you open a file in a file browser, or you open it thru a web
>> browser or something, it might have a mime type assosiated with
>> it.  So what I think you suggest is that based on the mime-type
>> we start an application that should be able to handle that
>> mime-type.
>
> This is what the Freedesktop.org MIME database achieves. No need to
> reinvent what is already a widespread standard.

The proposal here talks about differnt thing, but indirectly concerns
the mime types, which are used to associate actions to certain file
extensions.

Command line usage (or from Window manager menu):

call: x-spreadsheet

instead of

call: name-of-the-program-that-user-may-not-have

The mime types benefits from the alternatives framework too, whcih
currently use hard coded names (programs that user may not have
installed:

application/msexcel; oocalc '%s ...

Whereas the entried would better read:

application/msexcel; x-spreadsheet '%s ...

And the user selected program were configured with (and programs available
would register themselves into):

update-alternatived --config x-spreadsheet

Jari






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

Re: Bug#363486: dpkg: [update-alternatives] New categories for: WORD, EXCEL, MEDIA-PLAYER etc.

[Jari Aalto+mail.linux]

* Wed 2006-06-14 Hendrik Sattler 
>>
>> The proposal here talks about differnt thing, but indirectly concerns
>> the mime types, which are used to associate actions to certain file
>> extensions.
>
> Why not have something that starts the proper program according to the given 
> mimetype? E.g.:
> x-mime-handler application/whatever
>
> This program can make use of the .desktop files. If the .desktop files cannot 
> do this, yet, the standard for them should be extended to make it possible 
> instead of inventing yet another.

Hm. How does that work from command line? Or from X programs that have
fields like:

 Run program: _

As I understand, these require the name of executable and the
alternatives system does that. Like providing

sensible-editor

I'm not familiar with the .desktop files but I assume they belong only
to environments like Gnome and KDE. How would they be used with small
window managers, that simply contain "plug menu item name here, call
program" approach?

> Note that the alternative-System has one major drawback: it reflects the 
> choice of the administrator only, not the one of the user. And those two 
> _often_ do not match.

90% of the Linux installations or more are personal PCs. For corporate
wide installations, the choice of fixed programs is preferred.

I don't see real obstacle here. Granted that the alternatives system
should be extended to look for

$HOME/debian/alternatives

Before checking

/etc/laternatives

Perhaps I should file a wishlist for it.

> Another problem is the missing option compatibility between all of those 
> programs and thus only offers very limited usage of the used programs. And it 
> hides the problem that you have to get used to a program to efficiently use 
> it, e.g. KWord has many differences when compared to OpenOffice Writer.

I believe the need to pass options to programs is beyond the scope of
this.

> And the last point: you have icons on a desktop (or in a menu or whatever) 
> and 
> don't have to remember strange names, anyway. Users that start everything 
> from a shell usually do not use such (mainly mouse-operated) programs.

There are 20+ window managers out there that do not have icons. Not
everybody is capable of running KDE/Gnome that drain all memory from
average systems ( 400Mhz .. 1500Mhz).

We can forget KDE an Gnome (and XFCE?) altogether from this picture,
because they are completely self contained and any invention in there
cannot be used outside of them.

The proposal talks about providing framework for Window managers that
do not have sophisticated program control mechanism. This also means
that it is impossible to ship reasonable default menus, when there is
no infrastructure in place to use.

Jari


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

Re: Bug#363486: dpkg: [update-alternatives] New categories for: WORD, EXCEL, MEDIA-PLAYER etc.

[Jari Aalto+usenet]

* Wed 2006-06-14 Thibaut Paumard 
* Message-Id: 1150288566.1225.141.camel AT pc-paumard.mpe-garching.mpg.de
> Le mercredi 14 juin 2006 à 01:33 +0200, Hendrik Sattler a écrit :
>
>> Why not have something that starts the proper program according to the given 
>> mimetype? E.g.:
>> x-mime-handler application/whatever
>
> That would be run-mailcap, perhaps enhanced to not require a file name. 
>
> An x-spreadsheet could indeed be a wrapper around run-mailcap, so that
> the actual program to use could be overridden in ~/.mailcap.

This would be good. Where should this feature request be filed?

One thing, when etc/mailcap entry reads:

   application/msexcel; oocalc '%s'; edit=oocalc '%s

What happens then 'oocalc' is not available? How is
the error handling done, so that e.g. 'xmessage' is
displayed under Window mamager to notify the user?

Jari


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

SUMMARY -- Generic handling of WORD, EXCEL, FILE MANGER ...

[Jari Aalto+usenet]

-- This is summary of thread:
-- Subject: Bug#363486: dpkg: [update-alternatives] New categories for: WORD, 
EXCEL ...

Please comment. --Jari

THE INTENTION

There are many programs that can act on a file if it contains
certain extension. The use of program names like 'konqueror', 'xfe'
is not optimal. It would be better if common actions could be
expressed through terms of "File Manager", "Spreadsheet" etc.

This would help e.g. to provide better defaults for graphical
programs that include features like: "Options => Preferences =>
Programs" having line:

Edit __ (fill program name)

Filling in 'xedit' is not good default, when user must change this
same "setting" is other installed GUI programs as well.

PROPOSED SOLUTIONS

(1) It was discussed if /etc/alternatives could be used by providing
configuration possiblitity through

update-alternatives --config 

Where items proposed for graphical programs could include:

x-word-processor
x-spreadsheet
x-file-manager
x-archiver
x-media-player  or "x-video-player"
x-media-editor  or "x-media-mastering"
x-music-player
x-music-editor  think "audacity" etc.

This list is not comprehensive, only a start.

(2) Another proposed solution was to use existing MIME types
framework in /etc/mime.types, /etc/mailcap.order and /etc/mailcap.
It tackles the proposal like this:

application/msword; oowriter '%s'; edit=oowriter '%s'; ...
application/msexcel; oocalc '%s'; edit=oocalc '%s';...

CONCLUSIONS

Method (1) has drawbacks. Only adminstrator can update the
alternatives links, so individual users would not have control
over selected programs.

Method (2) supports user configurations through personal
mime type files in $HOME/.mailcap and thus better suitable.

REQUIRED WORK

(1) In order to carry on this proposal, there is need to write
a wrapper program that would use `run-mailcap'. The program
would use syntax:

x-mime-handler --mime TYPE [--action ACTION]

Where ACTION could be those defined in /etc/mime.types
[FIXME: If I understood correctly]

run (implicit if not given), edit, compose, print

An example call

x-mime-handler --mime application/msword --action run

Error handling would be based on return status

(2) There would also be need for standard features to call common
"actions". There is no need for end user to know the names of mime
types.

x-mime-handler --run FEATURE [ARGS]

The features would be those proposed at the beginning. Examples:

x-mime-handler --run x-file-manager /home/foo
x-mime-handler --run x-spreadsheet this.xls

BENEFITS

There are many graphical programs that contain setting that are
shipped with packages.

- These would all now have sensible defaults. E.g to run "editor".

There are many non-desktop window managers (not KDE, Gnome, XFCE),
that have simple menu structures. The menus call simple "programs".

- All those window managers could now have menu entries like
  "File manager" and use the program `x-mime-handler'.

PROBLEMS

The mime types are based on WWW protocol, which does not
necessarily map to local actions. Editing videos or mastering DVDs
are not expressed through MIME types (FIXE: If I undertand
right).

However, the possibility to use

x-mime-handler --run FEATURE

poses no such resstrictions and can run any defined FEATURES that
cannot be expressed through mime types. QUESTION: What about
user preferences in these cases when MIME types are not used?

QUESTION: this might be possible through MIME types by defining
custom actions.



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

Re: SUMMARY -- Generic handling of WORD, EXCEL, FILE MANGER ...

[Jari Aalto+mail.linux]

* Thu 2006-06-15 Bernhard Link 
* Message-Id: 20060615123501.GA11774 AT login.informatik.uni-freiburg.de
> * Jari Aalto+usenet  [060615 12:32]:
>> The features would be those proposed at the beginning. Examples:
>> 
>> x-mime-handler --run x-file-manager /home/foo
>> x-mime-handler --run x-spreadsheet this.xls
>
> What is wrong with:
>
> run-mailcap  --action=view application/vnd.ms-excel:this.xls
>
> or shorter:
>
> see application/vnd.ms-excel:this.xls
>
> or even shorten (if its type can be detected automatically correctly and
> one has no other information:)
>
> see this.xls

Good. I just wasn't familiar with run-mailcap's capabilities. I'll
update the proposal after comments.

Jari


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