Re: Switching /bin/sh to dash without dash essential

[Goswin von Brederlow]

Frans Pop  writes:

> Manoj Srivastava wrote:
>> I think we can engineer a system where Debian suggests various
>> shells as the default shell, and the user selects one. And only the
>> selected default shell is one that can't be removed from the system.
>
> Debian Installer could in theory support this by having a default shell 
> (varying per-architecture even). It could also prompt the user for which 
> shell to use in expert mode.

Default to dash (as that seems to be prefered, or why do we have that
conversation at all?). In expert mode create a list of anything
providing posix-sh and let the user pick one.

> The main challenge for installations would be that the default shell is 
> installed by debootstrap, so that would need to be extended with a 
> parameter to select a shell.

Actualy the installation would be automatic through an essential
"the-shell" package that (pre-)depends on default-posix-sh |
posix-sh. Essential so it can not be removed so that its dependency
keeps at least one /bin/sh installed.

The only really new and tricky thing would be that (c)debootstrap
would need to create the /bin/sh link after unpacking. Packages can
not contain that link and maintainer scripts aren't run in debootstrap
at first. Or it needs to run the maintainer scripts of at least one
posix-sh first and that script must not use /bin/sh (but can use
/bin/itself).

> Problem is package priorities: can you have (pseudo) package that is 
> priority required which is provided by packages that are all priority 
> optional (which the shells would have to be to avoid them being installed 
> automatically by debootstrap or the standard task)?

Isn't that exactly the mawk/gawk situation?
Essential/Required/Standard packages need awk but there is still a
choice which of the two to use. Only now we have exactly one package
(the-shell) that depends on posix-sh.

> And that would also mean that no packages of prio standard or higher can 
> be allowed to depend on a specific shell (as policy would make that shell 
> package get the same priority).

I think that is too strong. bash should still be standard I think. The
goal was to make it not essential so it can be removed on embedded
systems, right? On such systems you would have to have anything
(installed) depend on bash but that is their problem. It would be nice
to have nothing standard or higher depend on a specific shell but I
would not start with making that a MUST.

> In addition all shells supported as defaults would need to be included on 
> CD images. And the selected shell would of course have to be set as the 
> default for new users.
> Debootstrap would still need a sane default in case no shell is set 
> through a parameter or if the selected shell is not available for some 
> reason.

Only one posix-sh MUST be included. Just like kernels. Everything else
will be solved by dependencies. If a shell is selected then the
the-shell package willhave its depends fullfilled already, otherwise
one will be picked to fullfill it.

I don't think including every shell on the install medium is such high
priority. After all the design here is so that one can later change
the shell too. The shells should probably be on dvd1 but having only
the major candidates on the netinst image is perfectly fine.

> For switching the default shell on an installed system, something (a prerm 
> script shared between shell packages?) would need to check for the shell 
> being removed whether there are users who have it as their default shell 
> and what the default shell for new users is, and fail if the shell is 
> still in use. I also feel that this is a case where showing a debconf 
> dialog warning about possible consequences is appropriate.

That is somewhat unrelated to the issue. You can already install any
!bash shell, make it the default for some user and then purge
it. Nothing to do with the shell being /bin/sh.

> Plenty of challenges...
>
> Cheers,
> FJP

MfG
Goswin


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

Bug#538214: ITP: libio-compress-perl -- IO::Compress modules

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: libio-compress-perl
  Version : 2.020
  Upstream Author : Paul Marquess 
* URL : http://search.cpan.org/dist/IO-Compress/
* License : "Same terms as Perl"
  Programming Lang: Perl
  Description : IO::Compress modules

This module contains all IO::Compress and IO::Uncompress modules:
..
  - Compress-Zlib
  - IO-Compress-Zlib
  - IO-Compress-Bzip2
  - IO-Compress-Base
..
Compress::Zlib is a Perl external module which provides an interface to
the info-zip zlib compression library. zlib is a general purpose
compression library.
..
Some of the features provided by Compress::Zlib include:
..
   * in-memory compression and decompression
   * read and write gzip (.gz) files directly.
..
IO::Compress::Bunzip2 and IO::Uncompress::Bunzip2 provide a Perl interface
that allows transparent reading and writing bzip2 compressed data files or
buffers.
..
IO::Compress::Bases is the base class for all IO::Compress and IO::Uncompress
modules. It is not intended for direct use in application code. Its sole
purpose is to be sub-classed by IO::Compress modules.

Note: This is due to an upstream merge of libio-compress-bzip2-perl,
libcompress-zlib-perl, libio-compress-zlib-perl, and
libio-compress-base-perl.  I am coordinating this upload with the
maintainers of these packages.  The resulting package will probably be
mainained in pkg-perl.

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 
'jaunty-backports'), (500, 'jaunty')
Architecture: i386 (i686)



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

Re: RFC round 4: DEP-3: Patch Tagging Guidelines

[Manoj Srivastava]

On Thu, Jul 23 2009, Charles Plessy wrote:

> Le Fri, Jul 24, 2009 at 01:14:16AM +0200, Raphael Hertzog a écrit :
>> 
>> * Charles Plessy wanted to specify more precisely the format instead
>> of saying "RFC-2822 compliant fields". The discussion went nowhere
>> and nobody else expressed support for such a change.
>
> Hi Raphaël,
>
> my main concern is the discrepancy betwen the fact that the format does not
> comply with RFC-2822, and the following sentence: “The meta-information would
> be stored in a set of RFC-2822 compliant fields”.
>
> It is you decision if the DEP needs to contain or not a precise description of
> the format, but I would really recommend to soften the above sentence to make
> it match the facts. How about:
>
>   The meta-information would be stored in a set of fields similar to the ones
>   used in RFC-2822.

Why is this an improvement? Wouldn't this add to the complexity
 of the parser (having to cater to implementing "similar") without
 adding a whole lot to the humans?

> I think that it is important for the newcommers that our documentation
> is accurate and does not rely on obviousness that only comes with
> experience.

I do not see an increase of accuracy in going from:
   a set of RFC-2822 compliant fields
 to
   a set of fields similar to the ones  used in RFC-2822.

Apart from compliant --> similar, which changes the format, I
 don't see a difference in accuracy. It is a different proposal, though.

manoj
-- 
Life is the childhood of our immortality. Goethe
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Bug#538211: ITP: texworks -- An environment for authoring TeX (LaTeX, ConTeXt, etc) documents

[Atsuhito KOHDA]

Package: wnpp
Severity: wishlist
Owner: Atsuhito KOHDA 


* Package name: texworks
  Version : N/A (svn rev.333)
  Upstream Author : Jonathan Kew
* URL : http://www.tug.org/texworks/
* License : GPL ver.2.0
  Description : An environment for authoring TeX (LaTeX, ConTeXt, etc) 
documents

 An environment for authoring TeX (LaTeX, ConTeXt, etc) documents, with
 a Unicode-based, TeX-aware editor, integrated PDF viewer, and a clean,
 simple interface accessible to casual and non-technical users.
 .
 TeXworks is inspired by Dick Koch's award-winning TeXShop program for
 Mac OS X, which has made quality typesetting through TeX accessible to
 a wider community of users, without a technical or intimidating face.
 The goal of TeXworks is to deliver a similarly integrated, easy-to-use
 environment for users on other platforms, especially GNU/Linux and Windows.


Jonathan Kew is very famous for his XeTeX and texworks is
also his work.  Although I have not used TeXShop but heard 
that it is an excellent tool.  We will enjoy a similar excellent
texworks.  As far as I tested my private package, it could
display multi-byte characters like CJK in its pdf-viewer and
its most notable feature is synctex support IMHO.

Regards,Fri Jul 24 2009



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

Re: Bug#538202: ITP: virt-what -- detect if we are running in a virtual machine

[Aaron M. Ucko]

Laurent Léonard  writes:

> Description: detect if we are running in a virtual machine

What does it offer over the existing imvirt package?

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu


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

Re: Switching /bin/sh to dash without dash essential

[Manoj Srivastava]

On Thu, Jul 23 2009, Frans Pop wrote:

> Manoj Srivastava wrote:
>> I think we can engineer a system where Debian suggests various
>> shells as the default shell, and the user selects one. And only the
>> selected default shell is one that can't be removed from the system.
>
> Debian Installer could in theory support this by having a default shell 
> (varying per-architecture even). It could also prompt the user for which 
> shell to use in expert mode.
>
> The main challenge for installations would be that the default shell is 
> installed by debootstrap, so that would need to be extended with a 
> parameter to select a shell.

I can see a parameter for debootstrap; with  perhaps the same
 builtin default that d-i uses for the arch. The other way is to  let
 package priorities resolve this, more on this below.

> Problem is package priorities: can you have (pseudo) package that is
> priority required which is provided by packages that are all priority
> optional (which the shells would have to be to avoid them being
> installed automatically by debootstrap or the standard task)?  And
> that would also mean that no packages of prio standard or higher can
> be allowed to depend on a specific shell (as policy would make that
> shell package get the same priority).

Perhaps a high priority, or even an currently essential package
 depends on the (pseudo) package which is provided by packages with
 POSIX shells that meet policy requirements for /bin/sh.

This way, in order to fulfill the requirements of the essential
 package, we shall need at least one shell; which one it is will flow
 out of libapt. If the user selects a shell, or d-i does, the
 requirement is met.

This will allow people to install more than one candidate, but
 prevent them from removing the last candidate.

The tricky part, though, is managing the symlink.

> In addition all shells supported as defaults would need to be included
> on CD images. And the selected shell would of course have to be set as

Well, the set of packages included can serve as the initial
 selection offered to the user, though it does not need to be the
 complete set of policy compliant POSIX shells, I would think that the
 release and D-I teams will make the decision as to what does or does
 make the cut.

> the default for new users.  Debootstrap would still need a sane
> default in case no shell is set through a parameter or if the selected
> shell is not available for some reason.

Well, if the psuedo package posix-shell is a requirement of an
 essential package, do you still need such hard coded fall backs?


> For switching the default shell on an installed system, something (a
> prerm script shared between shell packages?) would need to check for
> the shell being removed whether there are users who have it as their
> default shell and what the default shell for new users is, and fail if
> the shell is still in use. I also feel that this is a case where
> showing a debconf dialog warning about possible consequences is
> appropriate.

Well, it is very tricky, espescially on multi-user systems --
 since you never know what might fail if /bin/sh changes under local
 scripts. But I guess the sysadmin can just say no to changes, in that
 case. But most certainly there should be no action taken unless the
 user has given the go-ahead.

manoj
signing with his new openpgp card
-- 
Bell Labs Unix -- Reach out and grep someone.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


pgpWy04K5aKYp.pgp
Description: PGP signature

Re: Switching /bin/sh to dash without dash essential

[Philipp Kern]

On 2009-07-23, Frans Pop  wrote:
> In addition all shells supported as defaults would need to be included on 
> CD images. And the selected shell would of course have to be set as the 
> default for new users.

Strike the "of course".  If I want my users to have zsh as a default that's
different from the question where I want to point my /bin/sh to.

Kind regards,
Philipp Kern


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

Re: Switching /bin/sh to dash (part two)

[Manoj Srivastava]

On Thu, Jul 23 2009, Raphael Geissert wrote:

> Manoj Srivastava wrote:
>
>> On Tue, Jul 21 2009, Raphael Geissert wrote:
>>>
>>> The goal of dropping bash from essential is not to remove bash from the
>>> systems (or from Debian), it is about making packages really using it
>>> depend on it.
>> 
>> Can you explain why this added dependency is a good thing, apart
>>  from creating more work for people?
>
> I'd prefer if this is discussed when the proposal is actually made

And I prefer to cut off silly proposals in the bud, if at all
 possible, before significant  effort is spent on it. The question is, is
 this proposal silly? In order to evaluate that, we have to find out
 _why_. The Embedded folk have made a reasonable argument for not
 wanting the weight of bash or zsh. Understandable, though it represents
 a smallish, competent section of the user base.

> (not to mention that I'm not really the person who plans to carry
> it).

If you are really not the competent person to defend the idea,
 perhaps you should not be so free to assert it as a truism.

> But well, one of the ideas is to avoid having such extra stuff deeply
> tied to the core system, i.e. essential.

That's it? The time to try to reduce the set of Essential
 packages is to deny entry to new  items (like dash),  since once the
 package is essential, people (and not just package maintainers) come to
 rely on it. Our user base, in particular, has had 15+ years to rely on
 bash -- and there are loads of user scripts, support systems, cron
 jobs, third part packages -- that need bash.

Once something is marked essential, it takes a lot of pain to
 remove it, and transition the user base off the package. Oh, gee, I
 think it is a good idea to not have bash essential perhaps does not
 meet the cut when trying to determine if the pain that one must go
 through is worth the return.

manoj
 leaning towards silly
-- 
I couldn't possibly fail to disagree with you less.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Switching /bin/sh to dash without dash essential

[Philipp Kern]

On 2009-07-23, Manoj Srivastava  wrote:
>> As long as /bin/sh refuses extensions to posix I agree with you, but
>> bashism has been a cuss word for years before 2004.
> Source? Policy does not even ban bashims for maintainer scripts.

Surely not, it just tells you to use bash in the shebang.

"""
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.
"""

Kind regards,
Philipp Kern



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

Re: RFC round 4: DEP-3: Patch Tagging Guidelines

[Charles Plessy]

Le Fri, Jul 24, 2009 at 01:14:16AM +0200, Raphael Hertzog a écrit :
> 
> * Charles Plessy wanted to specify more precisely the format instead
> of saying "RFC-2822 compliant fields". The discussion went nowhere
> and nobody else expressed support for such a change.

Hi Raphaël,

my main concern is the discrepancy betwen the fact that the format does not
comply with RFC-2822, and the following sentence: “The meta-information would
be stored in a set of RFC-2822 compliant fields”.

It is you decision if the DEP needs to contain or not a precise description of
the format, but I would really recommend to soften the above sentence to make
it match the facts. How about:

  The meta-information would be stored in a set of fields similar to the ones
  used in RFC-2822.

I think that it is important for the newcommers that our documentation is
accurate and does not rely on obviousness that only comes with experience. 

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Switching /bin/sh to dash (part two)

[Raphael Geissert]

Manoj Srivastava wrote:

> On Tue, Jul 21 2009, Raphael Geissert wrote:
>>
>> The goal of dropping bash from essential is not to remove bash from the
>> systems (or from Debian), it is about making packages really using it
>> depend on it.
> 
> Can you explain why this added dependency is a good thing, apart
>  from creating more work for people?

I'd prefer if this is discussed when the proposal is actually made (not to
mention that I'm not really the person who plans to carry it). But well,
one of the ideas is to avoid having such extra stuff deeply tied to the
core system, i.e. essential.

Cheers,
Raphael Geissert



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

Work-needing packages report for Jul 24, 2009

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 386 (new: 2)
Total number of packages offered up for adoption: 132 (new: 1)
Total number of packages requested help for: 55 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   kallery (#537669), orphaned 3 days ago
 Description: image gallery creator for kde
 Reverse Depends: kallery kallery-data
 Installations reported by Popcon: 232

   sysvconfig (#537966), orphaned yesterday
 Description: A text menu based utility for configuring init script
   links
 Installations reported by Popcon: 1042

384 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   trac-mercurial (#538076), offered yesterday
 Description: Mercurial version control backend for Trac
 Installations reported by Popcon: 81

131 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] mdadm (#537993), requested yesterday
 Description: tool to administer Linux MD arrays (software RAID)
 Reverse Depends: mdcfg-utils partman-md rescue-mode
 Installations reported by Popcon: 11185

   apache2 (#470795), requested 497 days ago
 Description: Co-maintainer wanted
 Reverse Depends: ampache apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (163 more
   omitted)
 Installations reported by Popcon: 44670

   ara (#450876), requested 620 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 111

   asymptote (#517342), requested 146 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 592

   athcool (#278442), requested 1731 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 179

   boinc (#511243), requested 196 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1614

   cvs (#354176), requested 1246 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsreport (11
   more omitted)
 Installations reported by Popcon: 20699

   dctrl-tools (#448284), requested 635 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies dlocate haskell-devscripts
   hg-buildpackage ia32-archive ia32-libs-tools libsbuild-perl mlmmj
   simple-cdd
 Installations reported by Popcon: 12216

   dpkg (#282283), requested 1705 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   asymptote asymptote-doc avrdude-doc backuppc biblatex (247 more
   omitted)
 Installations reported by Popcon: 84226

   elvis (#432298), requested 745 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 356

   fglrx-driver (#454993), requested 593 days ago (non-free)
 Description: non-free AMD/ATI r5xx, r6xx display driver
 Reverse Depends: fglrx-amdcccle fglrx-atieventsd fglrx-control
   fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-kernel-src
 Installations reported by Popcon: 1855

   flightgear (#487388), requested 397 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 656

   gentoo (#422498), requested 809 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 246

   gnat-4.3 (#475374), requested 469 days ago
 Description: help needed to execute test cases
 Reverse Depends: adabrowse adacontrol asis-programs ghdl gnade-bin
   gnat gnat-4.3 gnat-gps libadasockets-dev libahven16 (49 more
   omitted)
 Installations reported by Popcon: 942

   gnat-gps (#496905), requested 329 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 129

   graphviz (#536245), requested 

Re: Switching /bin/sh to dash (part two)

[Raphael Geissert]

Manoj Srivastava wrote:

> 
> I would be happier of we worked out a a way for the sysadmin to
>  be able to specify the default shell for the machine, rather than have
>  Debian decide it for them.

There's already a way to do it: dpkg-reconfigure dash

Cheers,
Raphael Geissert



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

Re: RFC round 4: DEP-3: Patch Tagging Guidelines

[Lucas Nussbaum]

On 24/07/09 at 01:14 +0200, Raphael Hertzog wrote:
> * I wonder if I shall add some samples to the document to make it clearer
> in everybody's mind. What do you think? If you think it's a good idea,
> feel free to provide some interesting (real-life) sample.

Examples would be nice, yes. Choose them wisely, as many people will
probably just copy/paste from them. :-)
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: RFC round 3: DEP-3: Patch Tagging Guidelines

[Azazel]

Raphael Hertzog wrote:
> On Tue, 30 Jun 2009, Andrei Popescu wrote:
> > On Mon,29.Jun.09, 22:53:53, Raphael Hertzog wrote:
> > > @@ -63,6 +63,10 @@ The set of fields ends on the first empty line.
> > > Free-form comments follow and be used for any other information
> >   ^^

No "can" here.

> > I'm not a native speaker, but this doesn't sound very well.
>
> There's an implicit "can".
>
> “Free-form comments can follow and [can] be used for”

One "can" here.

Az.
-- 
+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+
  www: http://www.azazel.net/
  pgp: http://www.azazel.net/~azazel/az_key.asc
+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+


signature.asc
Description: Digital signature

Re: RFC round 3: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Thu, 23 Jul 2009, brian m. carlson wrote:
> If you had said "Free-form comments can follow", then that would be
> correct.

Actually, that's what's in the document...

> As a native speaker of en_US, I would say that "Free-form
> comments follow and may be used..." sounds best.  "May" is better than
> "can" here because there is no doubt about your ability: you *can* write
> anything you want, but whether it is permitted or not is another matter.

So "Free-form comments may follow and be used..." ?

Cheers,
-- 
Raphaël Hertzog


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

RFC round 4: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

Hello,

one more turn for this DEP, after all. Recent changes are not numerous
but there are some.

Current version: http://dep.debian.net/deps/dep3/

=== Changes since last round ===

- Clarified that vendor names are case-insensitive

- Made the categorization in Origin optional. Made the field optional if Author
  field is present. he whole paragraph has been rewritten due to this:

+  * `Origin` (required except if `Author` is present)
+
+This field should document the origin of the patch. In most cases, it
+should be a simple URL. For patches backported/taken from upstream, it
+should point into the upstream VCS web interface when possible,
+otherwise it can simply list the relevant commit identifier (it should
+be prefixed with "commit:" in that case). For other cases, one should
+simply indicate the URL where the patch was taken from (mailing list
+archives, distribution bugtrackers, etc.) when possible.
+
+The field can be optionaly prefixed with a single keyword followed by
+a comma and a space to categorize the origin. The allowed keywords are
+"upstream" (in the case of a patch cherry-picked from the upstream
+VCS), "backport" (in the case of an upstream patch that had to be
+modified to apply on the current version), "vendor" for a patch
+created by Debian or another distribution vendor, or "other" for all
+other kind of patches.
+
+In general, a user-created patch grabbed in a BTS should be
+categorized as "other". When copying a patch from another vendor, the
 meta-information (and hence this field) should be kept if present, or
 created if necessary with a "vendor" origin.
 
+If the `Author` field is present, the `Origin` field can be omitted
+and it's assumed that the patch comes from its author.
+

- Recommend to keep description lines shorter than 80 chars

- Allow multiple Author fields.

- Added the rationale for encoding vendor name in Bug-

--- a/web/deps/dep3.mdwn
+++ b/web/deps/dep3.mdwn
@@ -115,6 +115,12 @@ of any other distribution that tracks the same 
problem/patch.
 bug tracker. Those fields can be used multiple times if several
 bugs are concerned.
 
+The vendor name is explicitely encoded in the field name so that
+vendors can share patches among them without having to update the
+meta-information in most cases. The upstream bug URL is special
+cased because it's the central point of cooperation and it must
+be easily distinguishable among all the bug URLs.
+
   * `Forwarded` (optional)


=== Remaining concerns/ideas ===

* Charles Plessy wanted to specify more precisely the format instead
of saying "RFC-2822 compliant fields". The discussion went nowhere
and nobody else expressed support for such a change.

* I wonder if I shall add some samples to the document to make it clearer
in everybody's mind. What do you think? If you think it's a good idea,
feel free to provide some interesting (real-life) sample.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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


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

Re: RFC round 3: DEP-3: Patch Tagging Guidelines

[brian m. carlson]

On Fri, Jul 24, 2009 at 12:58:20AM +0200, Raphael Hertzog wrote:
> On Tue, 30 Jun 2009, Andrei Popescu wrote:
> > On Mon,29.Jun.09, 22:53:53, Raphael Hertzog wrote:
> > > @@ -63,6 +63,10 @@ The set of fields ends on the first empty line. 
> > > Free-form comments follow and be used for any other information that 
> >   ^^
> > I'm not a native speaker, but this doesn't sound very well.
> 
> There's an implicit "can".
> 
> “Free-form comments can follow and [can] be used for”

If you had said "Free-form comments can follow", then that would be
correct.  As a native speaker of en_US, I would say that "Free-form
comments follow and may be used..." sounds best.  "May" is better than
"can" here because there is no doubt about your ability: you *can* write
anything you want, but whether it is permitted or not is another matter.

The implicit direct object of "follow" is "this line".

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: RFC round 3: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Tue, 30 Jun 2009, Andrei Popescu wrote:
> On Mon,29.Jun.09, 22:53:53, Raphael Hertzog wrote:
> > @@ -63,6 +63,10 @@ The set of fields ends on the first empty line. 
> > Free-form comments follow and be used for any other information that 
> ^^
> I'm not a native speaker, but this doesn't sound very well.

There's an implicit "can".

“Free-form comments can follow and [can] be used for”

I don't know if it's correct english but it sounds fine to me.

Cheers,
-- 
Raphaël Hertzog


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

Bug#538202: ITP: virt-what -- detect if we are running in a virtual machine

[Laurent Léonard]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: virt-what
Version: 1.1
Upstream Author: Richard Jones 
URL: http://et.redhat.com/~rjones/virt-what
License: GPL2
Description: detect if we are running in a virtual machine

-- 
Laurent Léonard



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

Bug#538203: ITP: fence-agents -- fende agents for cluster suite

[Guido Günther]

Package: wnpp
Severity: wishlist
Owner: "Guido Günther" 

* Package name: fence-agents
  Version : 3.0.0
* URL : https://fedorahosted.org/releases/c/l/cluster/
* License : GPL
  Programming Lang: C, Perl, Python
  Description : fende agents for cluster suite

Cheers,
-- Guido



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

Re: Switching /bin/sh to dash without dash essential

[Frans Pop]

Manoj Srivastava wrote:
> I think we can engineer a system where Debian suggests various
> shells as the default shell, and the user selects one. And only the
> selected default shell is one that can't be removed from the system.

Debian Installer could in theory support this by having a default shell 
(varying per-architecture even). It could also prompt the user for which 
shell to use in expert mode.

The main challenge for installations would be that the default shell is 
installed by debootstrap, so that would need to be extended with a 
parameter to select a shell.

Problem is package priorities: can you have (pseudo) package that is 
priority required which is provided by packages that are all priority 
optional (which the shells would have to be to avoid them being installed 
automatically by debootstrap or the standard task)?
And that would also mean that no packages of prio standard or higher can 
be allowed to depend on a specific shell (as policy would make that shell 
package get the same priority).

In addition all shells supported as defaults would need to be included on 
CD images. And the selected shell would of course have to be set as the 
default for new users.
Debootstrap would still need a sane default in case no shell is set 
through a parameter or if the selected shell is not available for some 
reason.

For switching the default shell on an installed system, something (a prerm 
script shared between shell packages?) would need to check for the shell 
being removed whether there are users who have it as their default shell 
and what the default shell for new users is, and fail if the shell is 
still in use. I also feel that this is a case where showing a debconf 
dialog warning about possible consequences is appropriate.

Plenty of challenges...

Cheers,
FJP


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

Re: Switching /bin/sh to dash without dash essential

[Manoj Srivastava]

On Thu, Jul 23 2009, Luk Claes wrote:

> Sam Hartman wrote:
>>
>> Folks, there was a longish discussion on IRC starting about an hour
>> ago about dash and bash.
>>
>> I agree we want to move the default /bin/sh to /bin/dash.
>> However I'm failing to understand why  we want dash to be essential.
>> If I'm not using dash as my /bin/sh why do I need it?
>>
>> If the answer is that we really do want it everywhere independent of
>> what /bin/sh is, that's fine.  However, that's not obvious to me.
>
> We want everyone to use dash by default.

Who is we? Why is the sysadmin not the one making the decision?
 Why is the Vendor making this decision for the user?

> If someone does not want to use the default, they are free to do so,
> but the default system shell is supposed to always be on the system.

Why? Is there a technical reason, or because you say so?

Frankly, if a user is happy with bash, they need bash anyway
 cause they have users that use it as an interactive shell, adding dash
 is pure bloat. They might not care for the 4 seconds it saves them on
 boot, since they rarely boot.

I think we can engineer a system where Debian suggests various
 shells as the default shell, and the user selects one. And only the
 selected default shell is one that can't be removed from the system.

I kinda like the mawk/gawk solution, which has
 worked. Admittedly, /bin/sh is rather more critical to get right, but I
 think we have the ability to craft a solution to do so.

manoj
-- 
filibuster, n.: Throwing your wait around.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Switching /bin/sh to dash without dash essential

[Sam Hartman]

> "Siggy" == Siggy Brentrup  writes:
8
>> I agree we want to move the default /bin/sh to /bin/dash.
>> However I'm failing to understand why we want dash to be
>> essential.  If I'm not using dash as my /bin/sh why do I need
>> it?

Siggy> So you are complaining about a small package (installed
Siggy> size 224) becoming essential while forcing the embedded ppl
Siggy> to work around a monster (installed size 1236); numbers
Siggy> taken from my Ubuntu laptop where both are essential, I
Siggy> hope only for a limited period of time.  
Hmm.
I don't get any complaint about /bin/dash being the default system shell from 
my mail.
Nor do you see me complaining about having /bin/sh scripts be posixly correct.

>> If the answer is that we really do want it everywhere
>> independent of what /bin/sh is, that's fine.  However, that's
>> not obvious to me.

Siggy> As long as /bin/sh refuses extensions to posix I agree with
Siggy> you, but bashism has been a cuss word for years before
Siggy> 2004.

I don't understand how this has anything to do with anything I said.

Siggy> Maybe "posixly-correct-shell" would be a better name.

Siggy> Summing up you suggest making a virtual package - 

No.  I suggest a package with no files but with pre-depends and the
essential flag.  I don't think a virtual package would work correctly
at a technical level, although I'd be happy to be shown to be wrong.

Siggy> however
Siggy> it's called - essential.  While I think I grok your
Siggy> intentions, I doubt dpkg will follow, please read
Siggy> carefully:

Siggy>   http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8

Read that long ago and read that word for word just now.
Can you help me understand what I'm missing?
I don't see how what I'm proposing would violate that.


>> I really don't mind if we go forward with the current proposal.
>> However, I think I and a lot of other people would appreciate
>> clarity, so far not expressed, about why dash needs to be
>> essential.

Siggy> See debian-policy cited above.

Again, please help me understand how what I propose would violate policy.


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

Re: Switching /bin/sh to dash without dash essential

[Manoj Srivastava]

On Thu, Jul 23 2009, Siggy Brentrup wrote:

> On Thu, Jul 23, 2009 at 11:19 -0400, Sam Hartman wrote:
>
>> Folks, there was a longish discussion on IRC starting about an hour
>> ago about dash and bash.
>
> These discussions are extremely long standing :)  The move away from
> bash has been aimed at long before I vanished from the project in 2004.
> I'm really upset that 5 years are not enough to accomplish the move.

I think because few proponents actually think through the impact
 on end user machines. There are more constituencies to Debian than just
 embedded users, and people write  shell scritps on their own, and use
 it as cron jobs, helper functions (I use a couple to handle mailto:
 URI's in mozilla to fire up gnus). The impact on these systems bigger,
 since there are more of them, and embedded systems end users, who can
 definitely switch the link themselves.

>> I agree we want to move the default /bin/sh to /bin/dash.
>> However I'm failing to understand why  we want dash to be essential.
>> If I'm not using dash as my /bin/sh why do I need it?
>
> So you are complaining about a small package (installed size 224)
> becoming essential while forcing the embedded ppl to work around a
> monster (installed size 1236); numbers taken from my Ubuntu laptop
> where both are essential, I hope only for a limited period of time.
> Although preferring CLI over GUI I don't use both of them, I prefer
> zsh for my daily work but my #!/bin/sh scripts are always posixly
> correct.

There is a traedeoff between an embedded system, and  machines
 where user tools and cron jobs may break  which 
>
>> If the answer is that we really do want it everywhere independent of
>> what /bin/sh is, that's fine.  However, that's not obvious to me.
>
> As long as /bin/sh refuses extensions to posix I agree with you, but
> bashism has been a cuss word for years before 2004.

Source? Policy does not even ban bashims for maintainer scripts.

manoj
-- 
How can you be in two places at once when you're not anywhere at all?
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Switching /bin/sh to dash (part two)

[Manoj Srivastava]

On Tue, Jul 21 2009, Henrique de Moraes Holschuh wrote:

> On Tue, 21 Jul 2009, Russ Allbery wrote:
>> "Giacomo A. Catenazzi"  writes:
>> > But probably for the shell cases it is easier to remove 'essential'
>> > flag (especially for a minimal nearly POSIX-like shell like dash),
>> > because the interface of #!/bin/sh is defined in policy (10.3).
>> 
>> Except that every package in Debian that explicitly uses bash has no
>> declared dependency on bash because it's essential.  I think attempting to
>> go through and add all those dependencies and test would be a huge waste
>> of time and resources.
>
> We can certainly retain bash as essential but still make dash essential and
> switch to dash.

Can we refrain from this  serial essentialness of the
 default-shell-du-jour, and arrange for some essential package to pull
 in the default shell for the day?

I would be happier of we worked out a a way for the sysadmin to
 be able to specify the default shell for the machine, rather than have
 Debian decide it for them.

This way, I can have a consistent /bin/sh across my machines,
 with different (supported) versions of Debian on them, even if Debian
 decides to change it's mind midway about what shell is king of the
 hill.

Users may have tonnes of shell scripts (cron jobs, helper
 scripts, local commands) that use #!/bin/sh but have come to rely on
 the fact that for the last 16 years or so, /bin/sh reliably pointed to
 /bin/bash.

The tradeoff of increased boot speed might not matter for users
 (certainly does not for me -- I only reboot to switch kernels), and
 adding dash or whatever incereases the disk usage for them (they need
 bash anywa, and so far have not needed dash -- so adding dash _adds_ to
 the bloat).

manoj
-- 
I'm going to give my psychoanalyst one more year, then I'm going to
Lourdes. Woody Allen
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Switching /bin/sh to dash (part two)

[Manoj Srivastava]

On Tue, Jul 21 2009, Raphael Geissert wrote:

> Henrique de Moraes Holschuh wrote:
>> 
>> It is not like you will be able to remove bash from the vast majority of
>> the Debian systems out there anyway, so it doesn't matter if it remains
>> "essential" for a while.
>
> The goal of dropping bash from essential is not to remove bash from the
> systems (or from Debian), it is about making packages really using it
> depend on it.

Can you explain why this added dependency is a good thing, apart
 from creating more work for people?

manoj
-- 
"We demand rigidly defined areas of doubt and uncertainty!" Vroomfondel
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Switching /bin/sh to dash (part two)

[Manoj Srivastava]

On Tue, Jul 21 2009, Giacomo A. Catenazzi wrote:


> but policy recommend not to use bash features on scripts (10.3),

That happens to be not what policy actually says.

> and the availability of a POSIX-shell (with few extension) is
> already provided by policy (still 10.3), thus no need to add
> package dependencies.

Unless you happen to use features of a package that been
 essential forever (in Debian years). And all policy says is that you
 have the magic #!/bin/bash at top.

manoj

-- 
Absence is to love what wind is to fire.  It extinguishes the small, it
enkindles the great.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Switching /bin/sh to dash (part two)

[Manoj Srivastava]

On Wed, Jul 22 2009, Giacomo A. Catenazzi wrote:


> If we remove the essential flag, we have a nice feature:
> the packages who needs bash need to be documented (via Depends).

Can you tell me how long did it take to move from /usr/doc to
 /usr/share/doc? 

manoj
-- 
Beware the one behind you.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Switching /bin/sh to dash without dash essential

[Sam Hartman]

> "Luk" == Luk Claes  writes:
Luk> We want everyone to use dash by default. If someone does not
Luk> want to use the default, they are free to do so, but the
Luk> default system shell is supposed to always be on the system.
Why?
I agree something should always provide /bin/sh.
I do not understand why the default system shell should be on the system always.

The only argument you've given that I understand is that no one wants
to do the work necessary to guarantee that /bin/sh is always present
and that the default system shell is not essential.
If that's the answer, that's a perfectly fine answer, but *say that*, don't 
just make assertions.


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

Re: Switching /bin/sh to dash without dash essential

[Goswin von Brederlow]

Siggy Brentrup  writes:

> On Thu, Jul 23, 2009 at 11:19 -0400, Sam Hartman wrote:
>
>
>> Folks, there was a longish discussion on IRC starting about an hour
>> ago about dash and bash.
>
> These discussions are extremely long standing :)  The move away from
> bash has been aimed at long before I vanished from the project in 2004.
> I'm really upset that 5 years are not enough to accomplish the move.
>
>> I agree we want to move the default /bin/sh to /bin/dash.
>> However I'm failing to understand why  we want dash to be essential.
>> If I'm not using dash as my /bin/sh why do I need it?
>
> So you are complaining about a small package (installed size 224)
> becoming essential while forcing the embedded ppl to work around a
> monster (installed size 1236); numbers taken from my Ubuntu laptop
> where both are essential, I hope only for a limited period of time.
> Although preferring CLI over GUI I don't use both of them, I prefer
> zsh for my daily work but my #!/bin/sh scripts are always posixly
> correct.

No, complaining about replacing shackles with handcuffs.

>> If the answer is that we really do want it everywhere independent of
>> what /bin/sh is, that's fine.  However, that's not obvious to me.
>
> As long as /bin/sh refuses extensions to posix I agree with you, but
> bashism has been a cuss word for years before 2004.
>
>> So, a proposal for doing a switch with dash not essential.
>
>> 1) all /bin/sh shells know about each other.

1b) All /bin/sh shells must behave as if they where essential. They
must work while being unconfigured and so on.

>> 2) The prerm script for a /bin/sh shell finds another /bin/sh shell
>>and updates the symlink if the current /bin/sh link is the one being
>>removed.
>
>> 3) The postinst for a /bin/sh shell can update the link if it
>>decides that the installed shell would make a better /bin/sh
>
>> 4) There is a package `the-shell ' that is essential and pre-depends
>>on one of the /bin/sh shells.
>
> Maybe "posixly-correct-shell" would be a better name.
>
> Summing up you suggest making a virtual package - however it's called
> - essential.  While I think I grok your intentions, I doubt dpkg
> will follow, please read carefully:
>
>   http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8

And what exactly do you mean? Nothing in there about virtual packages.

>> Variations:
>
>> 1) You could have a registration mechanism.  My assumption is the
>>set is small enough static is good
>
>> 2) I assume that package operations cannot take place between
>>calling the prerm script and actually removing the package.  If that
>>is false, you could make sure that you are changing the link to a
>>configured shell

It is false afaik. You can deconfigure any number of packages before
starting to remove any of them.

>> I really don't mind if we go forward with the current proposal.
>> However, I think I and a lot of other people would appreciate clarity,
>> so far not expressed, about why dash needs to be essential.
>
> See debian-policy cited above.
>
> looking-forward-for-posixly-correct-/bin/sh-ly yours
>   Siggy

Say you have only shell-1 installed to provide /bin/sh. The big
question is if apt/aptitude/synaptic/.../dpkg will ever deconfigure or
even uninstall shell-1 before it unpacks shell-2.

Can the following sequence happens?

deconfigure the-shell
deconfigure shell-1
remove shell-1
unpack shell-2
configure shell-2
configure the-shell

If this sequence ever happens then the system is without /bin/sh for a
time. Not a good idea.

I think the above is unlikely but can possibly happen and nothing in
Depends or Pre-Depends can prevent it. But the prerm script could
(should) fail if it can not find another /bin/sh provider to at least
don't make the system unusable.

MfG
Goswin


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

Bug#538171: ITP: makefs -- create a file system image from a directory tree

[Thorsten Glaser]

Package: wnpp
Severity: wishlist
Owner: Thorsten Glaser 

* Package name: makefs
  Version : 20090724
  Upstream Author : The MirOS Project 
* URL : http://www.mirbsd.org/cvs.cgi/src/usr.sbin/makefs/
* License : 4-clause BSD
  Programming Lang: C
  Description : create a file system image from a directory tree


NetBSD® makefs(8) creates a file system image from a directory tree
without the need for superuser privileges. The MirBSD version fixes
ECMA 119, SUSP and RRIP (Rock Ridge) compliance.

Supported target filesystem types are:
   cd9660   ISO 9660 (ECMA 119) compatible filesystem images, with
Rock Ridge, El Torito, and other features
   ffs  4.2FFS, the BSD Fast Filesystem, also known as UFS1;
support for UFS2 is currently untested

The images created can be of a fixed (predefined) size, given on the
command line, or sized automatically. Permission bits are taken from
the source directory tree but may be overridden using an mtree file.


This package is created to aid Luca Favatella in porting d-i to
Debian GNU/kFreeBSD. It also serves purpose as a genisoimage re-
placement, if people should then so wish. (Which is why the MirBSD
version was ported, as it conforms to ECMA 119, RRIP, SUSP and the
El Torito standard, which the NetBSD® version doesn’t.)

I fully intend to maintain this package in MirBSD (“upstream”) as
well as Debian (in my capacity as DM); I also try to coordinate
pushing all patches to the “up-upstream” (NetBSD®).



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

Re: [config-model-users] Please test krb5-config in experimental

[Dominique Dumont]

> The model was pretty much 100% complete and had been well tested on my
> box. However, I ran out of free time to work on this, so I never got
> around to implementing the suggestions that you made back in September
> 2008.

Peter, do you have any hope to resume working on it ?

Or should I look for a volunteer to take it over ?

All the best


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

Re: Switching /bin/sh to dash without dash essential

[Luk Claes]

Sam Hartman wrote:


Folks, there was a longish discussion on IRC starting about an hour
ago about dash and bash.

I agree we want to move the default /bin/sh to /bin/dash.
However I'm failing to understand why  we want dash to be essential.
If I'm not using dash as my /bin/sh why do I need it?

>

If the answer is that we really do want it everywhere independent of
what /bin/sh is, that's fine.  However, that's not obvious to me.


We want everyone to use dash by default. If someone does not want to use 
the default, they are free to do so, but the default system shell is 
supposed to always be on the system.



So, a proposal for doing a switch with dash not essential.

1) all /bin/sh shells know about each other.


Not going to happen AFAICS. bash does not know about any for instance.


2) The prerm script  for a /bin/sh shell finds another /bin/sh shell and 
updates the symlink if the current /bin/sh link is the one being removed.


Might be possible, but currently needs a lot of work and I don't see 
anyone interested to do that.



3) The postinst for a /bin/sh shell can update the link if it decides that the 
installed shell would make a better /bin/sh


'it' decides :-)


4) There is a package `the-shell ' that is essential and pre-depends on one of 
the  /bin/sh shells.


This seems ugly, I would rather go for a virtual package in that case 
similar to awk.



I really don't mind if we go forward with the current proposal.
However, I think I and a lot of other people would appreciate clarity,
so far not expressed, about why dash needs to be essential.


You do not want to give the possibility to remove /bin/sh from the 
system. Currently this is done by making the default system shell essential.


Cheers

Luk


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

Re: Switching /bin/sh to dash without dash essential

[Siggy Brentrup]

On Thu, Jul 23, 2009 at 11:19 -0400, Sam Hartman wrote:


> Folks, there was a longish discussion on IRC starting about an hour
> ago about dash and bash.

These discussions are extremely long standing :)  The move away from
bash has been aimed at long before I vanished from the project in 2004.
I'm really upset that 5 years are not enough to accomplish the move.

> I agree we want to move the default /bin/sh to /bin/dash.
> However I'm failing to understand why  we want dash to be essential.
> If I'm not using dash as my /bin/sh why do I need it?

So you are complaining about a small package (installed size 224)
becoming essential while forcing the embedded ppl to work around a
monster (installed size 1236); numbers taken from my Ubuntu laptop
where both are essential, I hope only for a limited period of time.
Although preferring CLI over GUI I don't use both of them, I prefer
zsh for my daily work but my #!/bin/sh scripts are always posixly
correct.

> If the answer is that we really do want it everywhere independent of
> what /bin/sh is, that's fine.  However, that's not obvious to me.

As long as /bin/sh refuses extensions to posix I agree with you, but
bashism has been a cuss word for years before 2004.

> So, a proposal for doing a switch with dash not essential.

> 1) all /bin/sh shells know about each other.

> 2) The prerm script for a /bin/sh shell finds another /bin/sh shell
>and updates the symlink if the current /bin/sh link is the one being
>removed.

> 3) The postinst for a /bin/sh shell can update the link if it
>decides that the installed shell would make a better /bin/sh

> 4) There is a package `the-shell ' that is essential and pre-depends
>on one of the /bin/sh shells.

Maybe "posixly-correct-shell" would be a better name.

Summing up you suggest making a virtual package - however it's called
- essential.  While I think I grok your intentions, I doubt dpkg
will follow, please read carefully:

  http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8

> Variations:

> 1) You could have a registration mechanism.  My assumption is the
>set is small enough static is good

> 2) I assume that package operations cannot take place between
>calling the prerm script and actually removing the package.  If that
>is false, you could make sure that you are changing the link to a
>configured shell

> I really don't mind if we go forward with the current proposal.
> However, I think I and a lot of other people would appreciate clarity,
> so far not expressed, about why dash needs to be essential.

See debian-policy cited above.

looking-forward-for-posixly-correct-/bin/sh-ly yours
  Siggy

-- 
Please don't Cc: me when replying, I might not see either copy.
   bsb-at-psycho-dot-informationsanarchistik-dot-de
   or:bsb-at-psycho-dot-i21k-dot-de
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


signature.asc
Description: Digital signature

Re: The wider implications of stuffing the NEW queue with issues it was not designed for.

[Philipp Kern]

On 2009-07-23, Steve Langasek  wrote:
> On Sun, Jul 19, 2009 at 07:12:57AM +, Philipp Kern wrote:
>> On 2009-07-19, Charles Plessy  wrote:
>> > Do we have evidence that maintainers have damaged the project in the past 
>> > by
>> > willingfully upload packages with overriden lintian errors?
>> Damaged the project... no.  Caused a RC bug to be overlooked... yes.
>> I recently encountered a package where the library's binary package
>> was not named after the SONAME.  This caused a lintian error which was...
>> overridden.  And it broke horribly when the SONAME change went unnoticed
>> because... well... the binary was never named after the SONAME and thus
>> the check wasn't active anymore.
> Lintian's error on soname mismatches references both the binary package
> name, and what lintian thinks the package name should be based on the actual
> soname.  AFAIK you can only override lintian errors by spelling them out
> fully, so surely the lintian error should have reappeared in this case as
> soon as the soname changed?

That would have prevented this indeed.  But it looks that it did not work
that way because the only override present was this one:

libbotan1.8: package-name-doesnt-match-sonames

This obviously didn't need changing.  According to [0] there was also no
other Lintian warning.

Kind regards,
Philipp Kern

[0] http://lintian.debian.org/maintainer/dan...@debian.org.html#botan-devel


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

Switching /bin/sh to dash without dash essential

[Sam Hartman]

Folks, there was a longish discussion on IRC starting about an hour
ago about dash and bash.

I agree we want to move the default /bin/sh to /bin/dash.
However I'm failing to understand why  we want dash to be essential.
If I'm not using dash as my /bin/sh why do I need it?

If the answer is that we really do want it everywhere independent of
what /bin/sh is, that's fine.  However, that's not obvious to me.

So, a proposal for doing a switch with dash not essential.

1) all /bin/sh shells know about each other.
2) The prerm script  for a /bin/sh shell finds another /bin/sh shell and 
updates the symlink if the current /bin/sh link is the one being removed.
3) The postinst for a /bin/sh shell can update the link if it decides that the 
installed shell would make a better /bin/sh
4) There is a package `the-shell ' that is essential and pre-depends on one of 
the  /bin/sh shells.


Variations:

1) You could have a registration mechanism.  My assumption is the set is small 
enough static is good

2) I assume that package operations cannot take place between calling the prerm 
script and actually removing the package.  If that is false, you could make 
sure that you are changing the link to a configured shell

I really don't mind if we go forward with the current proposal.
However, I think I and a lot of other people would appreciate clarity,
so far not expressed, about why dash needs to be essential.


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

Re: Switching /bin/sh to dash (part two)

[Luk Claes]

Steve Langasek wrote:

On Sun, Jul 19, 2009 at 06:04:13PM +0200, Raphael Geissert wrote:


This is a follow up to my previous thread, with a slightly different
proposal.



What actually needs to be done is:
* Make dash essential, make it divert the current /bin/sh symlink by default, 
make another essential package depend on dash. Prompt the user before 
diverting on interactive upgrades.


Is this latter part actually needed, or do we just need some package in the
required set to depend on it?  Note that, when essential functionality is
being split between packages, the authoritative way to handle upgrades is to
have an existing Essential: yes package *Pre-*Depend on the new package; but
we're not actually splitting any essential functionality in this case, since
bash is still Essential and will still provide all the same functionality.


No, the latter part is not necessary, though the consensus seemed to be 
that people did not want the change to happen without them having the 
chance to easily prevent it on upgrades.



If we're to have an Essential package depend on dash for upgrades, I suppose
base-files is the obvious choice.


Well, bash is already doing it now and we did not want to bother people 
during d-i or debootstrap and having bash depend on dash made that easier.


Cheers

Luk


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

Re: Switching /bin/sh to dash (part two)

[Steve Langasek]

On Sun, Jul 19, 2009 at 06:04:13PM +0200, Raphael Geissert wrote:

> This is a follow up to my previous thread, with a slightly different
> proposal.

> What actually needs to be done is:
> * Make dash essential, make it divert the current /bin/sh symlink by default, 
> make another essential package depend on dash. Prompt the user before 
> diverting on interactive upgrades.

Is this latter part actually needed, or do we just need some package in the
required set to depend on it?  Note that, when essential functionality is
being split between packages, the authoritative way to handle upgrades is to
have an existing Essential: yes package *Pre-*Depend on the new package; but
we're not actually splitting any essential functionality in this case, since
bash is still Essential and will still provide all the same functionality.

If we're to have an Essential package depend on dash for upgrades, I suppose
base-files is the obvious choice.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: The wider implications of stuffing the NEW queue with issues it was not designed for.

[Steve Langasek]

On Sun, Jul 19, 2009 at 07:12:57AM +, Philipp Kern wrote:
> On 2009-07-19, Charles Plessy  wrote:
> > Do we have evidence that maintainers have damaged the project in the past by
> > willingfully upload packages with overriden lintian errors?

> Damaged the project... no.  Caused a RC bug to be overlooked... yes.
> I recently encountered a package where the library's binary package
> was not named after the SONAME.  This caused a lintian error which was...
> overridden.  And it broke horribly when the SONAME change went unnoticed
> because... well... the binary was never named after the SONAME and thus
> the check wasn't active anymore.

Lintian's error on soname mismatches references both the binary package
name, and what lintian thinks the package name should be based on the actual
soname.  AFAIK you can only override lintian errors by spelling them out
fully, so surely the lintian error should have reappeared in this case as
soon as the soname changed?

Or did the maintainer willfully update the override *as well* when the
soname changed?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: Intend to create an -fPIC library package...

[Raphael Hertzog]

On Wed, 22 Jul 2009, Cyril Brulebois wrote:
> Raphael Hertzog  (22/07/2009):
> > Yes. Check "man dpkg-gensymbols" and see how some nice tools
> > […propaganda…]
> 
> FSVO “nice”. #536034.

Mistakes happen, that doesn't change anything concerning the usefulness of
the tool.

> In case a maintainer of a shared lib never did this, I strongly advise
> playing around with a simple combo of diff, find, and nm, in order to
> have a look at what symbols are becoming between two releases.

Why is that better than comparing both symbols files and having the build
actually fail if a symbol is removed?

Using nm/find/diff is more complicated and I don't see a clear advantage
to it.

Cheers,
-- 
Raphaël Hertzog


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

Re: The wider implications of debhelper/dbus breakage

[Raphael Hertzog]

On Wed, 22 Jul 2009, Cyril Brulebois wrote:
> Raphael Hertzog  (17/07/2009):
> > At least dpkg-dev has one and it's run at build-time.
> 
> I thought the goal of dpkg-dev was to actually build other packages. I
> don't know how dpkg-dev developers see this, but maybe having a few
> packages rebuilt using the new dpkg-dev package would help spotting
> breakages?

Well, I always run the git version on my machine. But maintaining dpkg-dev
is enough of a job that I don't maintain many other packages... so I
don't build many other packages except for QA work or similar (like
investigation build failures with the new source format).

> I dunno, but especially eglibc and other important packages
> would be quite good candidates.

Well, multiple hours compilation don't buy us much testing of dpkg-dev.
That said the bigger packages are also those that make usage of the
advanced features...

> I guess that a loop for getting the
> source packages, pushing them through sbuild once with the old dpkg-dev
> package and once with the new dpkg-dev packages, then debdiffing (and
> whatever interesting diff tests might come to mind) would help and
> wouldn't be very hard to implement.

Are you interested in writing it? :-) I don't see anything that needs to
be specific for each tool. Starting with a new sbuild option to
auto-install a new .deb in the chroot (and restore the official one
provided by apt) would be half the job.

Deciding what difference is tolerated is the second (more annoying) half
of the job.

Cheers,
-- 
Raphaël Hertzog


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

Bug#538130: ITP: prosody -- jabber server

[Enrico Tassi]

Package: wnpp
Severity: wishlist
Owner: Enrico Tassi 


* Package name: prosody
  Version : 0.5.0
  Upstream Author : Matthew Wild , Waqas Hussain 
, Tobias Markmann 
* URL : http://prosody.im
* License : MIT/X
  Programming Lang: Lua, C
  Description : jabber server

Prosody is a flexible communications server for Jabber/XMPP written in
Lua. It aims to be easy to use, and light on resources. For developers
it aims to be easy to extend and give a flexible system on which to
rapidly develop added functionality, or prototype new protocols.



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

Bug#538117: ITP: plasma-widget-dvb-info -- A KDE plasma applet for Dresden's public transport arrival/departure times

[Gregor Jasny]

Package: wnpp
Severity: wishlist
Owner: Gregor Jasny 

* Package name: plasma-widget-dvb-info
  Version : 0.1
  Upstream Author : Tobias Koenig 
* URL : http://wiki.github.com/tokoe/DVB-Plasma-Applet
* License : GPL2 / GPL2+
  Programming Lang: C++
  Description : A KDE plasma applet for Dresden's public transport 
arrival/departure times

This KDE plasma applet provides arrival and departure times for any stop
of Dresden's public transportiation system.



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