Bug#587214: ITP: libppix-utilities-perl -- Perl module containing extensions to PPI

[Salvatore Bonaccorso]

Package: wnpp
Owner: Salvatore Bonaccorso 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libppix-utilities-perl
  Version : 1.01
  Upstream Author : Elliot Shank 
* URL : http://search.cpan.org/dist/PPIx-Utilities/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module containing extensions to PPI

This is a collection of functions for dealing with PPI objects, many of which
originated in Perl::Critic. They are organized into modules by the kind of
PPI class they relate to, by replacing the "PPI" at the front of the module
name with "PPIx::Utilities", e.g. functionality related to PPI::Nodes is in
PPIx::Utilities::Node.

Note: libppix-utilities-perl will be needed as dependency for updated
  libperl-critic- perl module and thus needs to be packaged.




-- 
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/1277548172.512264.28...@elende

Bug#587218: ITP: apache-upload-progress-module -- upload progress support for the Apache web server

[Jérémy Bobbio]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Bobbio" 

* Package name: apache-upload-progress-module
  Version : 0.1+git20100316-1
  Upstream Author : Piotr Sarnacki 
* URL : http://github.com/drogus/apache-upload-progress-module/
* License : MIT-style
  Programming Lang: C
  Description : upload progress support for the Apache web server

mod_upload_progress allows to monitor status of HTTP file uploads.

Website authors can then query the server using Javascript to provide
better feedback (e.g. progress bar, throughput) while the browser is
uploading.

This module produces output similar to the equivalent modules for Nginx
and lighttpd.

-- 
Jérémy Bobbio.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Re: Essentiality of Bash

[Marc Haber]

On Fri, 25 Jun 2010 14:27:31 -0700, Steve Langasek 
wrote:
>On Fri, Jun 25, 2010 at 10:20:33PM +0200, Marc Haber wrote:
>> On Wed, 23 Jun 2010 16:58:58 +0200, Goswin von Brederlow
>>  wrote:
>> >I think for that goal it would be good for lintian to add an exception
>> >to the (build-)depends-on-essential-package-without-using-version check.
>> >That does not mean that bash should stop being essential in Debian any
>> >time soon.
>
>> I have never understood that rule in the first place. Why am I not
>> allowed to depend on an essential package, it's just clearer
>> documentation, and doesn't hurt.
>
>> What am I missing?
>
>The footnote to Policy 3.5, where this is written out?

Ah, so this is the same as the no-circular-dependency rule, dumping
extra error proneness and extra thoughtweight on all developers to
work around shortcomings in our software?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1osuae-0002xx...@swivel.zugschlus.de

Bug#587223: ITP: libscalc -- simple/symbolic calculation library

[Vincent Fourmond]

Package: wnpp
Severity: wishlist
Owner: Vincent Fourmond 

* Package name: libscalc
  Version : 0.2.2
  Upstream Author : Vincent Fourmond 
* URL : http://rubyforge.org/frs/?group_id=1477
* License : GPL2+
  Programming Lang: C++
  Description : simple/symbolic calculation library

SCalc is a C++ library for manipulation of mathematical
expressions. It is possible to define functions, either using an
expression or a C function. It is able to compute derivatives
analytically, and is therefore suitable for implementing non-linear
curve fitting with user-specified arbitrary functions.

  Cheers,

Vincent




-- 
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/20100626114612.8162.88533.report...@tanyaivinco.homelinux.org

Re: Essentiality of Bash

[Neil Williams]

On Sat, 26 Jun 2010 14:07:40 +0200
Marc Haber  wrote:

> Ah, so this is the same as the no-circular-dependency rule, dumping
> extra error proneness and extra thoughtweight on all developers to
> work around shortcomings in our software?

Patches to dpkg are welcome if you have a better (and
reliable) solution

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpCAVaQk4cK7.pgp
Description: PGP signature

Re: Essentiality of Bash

[Josselin Mouette]

Le samedi 26 juin 2010 à 14:07 +0200, Marc Haber a écrit :
> >The footnote to Policy 3.5, where this is written out?
> 
> Ah, so this is the same as the no-circular-dependency rule, dumping
> extra error proneness and extra thoughtweight on all developers to
> work around shortcomings in our software?

AIUI it is here because the no-circular-dependency rule isn’t enforced
enough.

Furthermore, I’d be interested to know how to fix such a “shortcoming”
in our software. If both A and B depend on each other, A.postinst must
be executed before B.postinst, and vice versa. Please show me an
algorithm to do that that doesn’t rely on a timeshifting device.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


signature.asc
Description: This is a digitally signed message part

Re: Accepted sdm 0.4.1-2 (source all)

[Julien Cristau]

On Sat, Jun 26, 2010 at 12:57:45 +, Vagrant Cascadian wrote:

>  sdm (0.4.1-2) unstable; urgency=low
>  .
[...]
>* No longer include dash as a dependency; it is included in essential.
>* Add lintian overrides for missing-dep-for-interpreter dash, as dash
>  is now essential.

My understanding was that dash was only in the Essential set as the
default provider of /bin/sh, and that /bin/dash was explicitly *not*
guaranteed to stay in Essential, and thus packages using that need to
keep their dependencies.  Did I misunderstand, or is the above change
wrong?

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Accepted sdm 0.4.1-2 (source all)

[Kurt Roeckx]

On Sat, Jun 26, 2010 at 02:40:37PM +0100, Julien Cristau wrote:
> On Sat, Jun 26, 2010 at 12:57:45 +, Vagrant Cascadian wrote:
> 
> >  sdm (0.4.1-2) unstable; urgency=low
> >  .
> [...]
> >* No longer include dash as a dependency; it is included in essential.
> >* Add lintian overrides for missing-dep-for-interpreter dash, as dash
> >  is now essential.
> 
> My understanding was that dash was only in the Essential set as the
> default provider of /bin/sh, and that /bin/dash was explicitly *not*
> guaranteed to stay in Essential, and thus packages using that need to
> keep their dependencies.  Did I misunderstand, or is the above change
> wrong?

And that's why dash should _not_ set "Essential: yes"


Kurt


-- 
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/20100626134902.ga27...@roeckx.be

Re: Essentiality of Bash

[Bernhard R. Link]

* Marc Haber  [100626 14:07]:
> On Fri, 25 Jun 2010 14:27:31 -0700, Steve Langasek 
> >The footnote to Policy 3.5, where this is written out?
>
> Ah, so this is the same as the no-circular-dependency rule, dumping
> extra error proneness and extra thoughtweight on all developers

Please, try to be a bit more fair. Having people not need to specify
dependencies is really not the solution that "dumps extra error
proneness and extra thoughtweight" on the developers. And once those
need not there saying they should not be there is not adding any error
proneness.

I'm personally all in favor for making the "hard to deinstall"
and "not needed in dependencies" different things (and am annoyed
every time my build-chroot has to contain many unnecessary packages
just because Essential forces to install e2fsprogs and mount
and things like that), but have to acknowledge that while the current
situation is the less flexible one, it is also the less error prone one.

> to work around shortcomings in our software?

If you read the second paragraph it also gives a reason that has nothing
at all to do with making it easier for software [1]: If there are no
dependencies, essential stuff can just move between packages or have
packages renamed.

Not requiring dependencies but allowing them only combines the
disadvantages of both worlds. It does not really make sense to have
both except for transition periods.

Bernhard R. Link

[1] and thus more likely for our users to get smoth upgrades. I really
do not see the point why just because some software could be able
to solve something, we should choose the solution most likely to
break.
Especially circular dependencies are a pain whenever you have some
seriously broken system or are otherwise forced by whatever reason
to fall back to manual dpkg invocations


-- 
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/20100626154515.ga13...@pcpool00.mathematik.uni-freiburg.de

Re: Accepted sdm 0.4.1-2 (source all)

[Vagrant Cascadian]

On Sat, Jun 26, 2010 at 02:40:37PM +0100, Julien Cristau wrote:
> On Sat, Jun 26, 2010 at 12:57:45 +, Vagrant Cascadian wrote:
> 
> >  sdm (0.4.1-2) unstable; urgency=low
> >  .
> [...]
> >* No longer include dash as a dependency; it is included in essential.
> >* Add lintian overrides for missing-dep-for-interpreter dash, as dash
> >  is now essential.
> 
> My understanding was that dash was only in the Essential set as the
> default provider of /bin/sh, and that /bin/dash was explicitly *not*
> guaranteed to stay in Essential, and thus packages using that need to
> keep their dependencies.  Did I misunderstand, or is the above change
> wrong?

well, lintian warns either way you do it, hence the override:

  http://bugs.debian.org/587209

some clarity on how to handle that would be nice, yes.  since dash *is* marked
essential, and based on my reading of policy 3.8:

"Maintainers should take great care in adding any programs, interfaces, or
functionality to `essential' packages.  Packages may assume that
functionality provided by `essential' packages is always available without
declaring explicit dependencies, which means that removing functionality
from the Essential set is very difficult and is almost never done.  Any
capability added to an `essential' package therefore creates an obligation
to support that capability as part of the Essential set in perpetuity."

seemed like the override was the appropriate thing to do, but i'm not terribly
attached if it's deemed better to handle it differently.

live well,
  vagrant


-- 
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/20100626175910.gl9...@claws.fglan

Re: Accepted sdm 0.4.1-2 (source all)

[Russ Allbery]

Vagrant Cascadian  writes:
> On Sat, Jun 26, 2010 at 02:40:37PM +0100, Julien Cristau wrote:

>> My understanding was that dash was only in the Essential set as the
>> default provider of /bin/sh, and that /bin/dash was explicitly *not*
>> guaranteed to stay in Essential, and thus packages using that need to
>> keep their dependencies.  Did I misunderstand, or is the above change
>> wrong?

> well, lintian warns either way you do it, hence the override:

>   http://bugs.debian.org/587209

> some clarity on how to handle that would be nice, yes.

Yes, we need to fix that one way or the other.

I think it's moderately unlikely that we're going to manage to keep dash
from being treated as essential even if we say that it's only essential
for the /bin/sh functionality.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/871vbty72o@windlord.stanford.edu

Re: Accepted sdm 0.4.1-2 (source all)

[Julien Cristau]

On Sat, Jun 26, 2010 at 11:36:31 -0700, Russ Allbery wrote:

> I think it's moderately unlikely that we're going to manage to keep dash
> from being treated as essential even if we say that it's only essential
> for the /bin/sh functionality.
> 
I don't think it's that hard (but then I don't know of a reasonable
reason to use #!/bin/dash instead of #!/bin/sh in the first place).  But
if we can't do that, I'd say let's kick dash out of Essential entirely.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#587258: ITP: im-config -- Input method configuration framework

[Osamu Aoki]

Package: wnpp
Severity: wishlist
Owner: Osamu Aoki 


* Package name: im-config
  Version : 0.1
  Upstream Author : Osami Aoki 
* URL : http://git.debian.org/?p=collab-maint/im-config.git
* License : GPL-2+
  Programming Lang: POSIX shell
  Description : Input method configuration framework
 im-config package provides the framework to configure and to switch
 the input method on X Window System. This input method is the essential
 mechanism for Japanese, Chinese and Korean (CJK) languages to enter
 their non-ASCII native characters.
 .
 Many modern input methods such as IBus support not only one of these CJK
 languages but support almost all languages simultaneously by
 dynamically switching keyboard modes with GUI helper program.
 .
 By installing this package, the most desirable input method and its
 backend conversion engine are automatically configured with both the X
 Window System Input Method (XIM), GTK input method module and Qt input
 method module.
 .
 You can further customize your input method with 'im-config' command.

=
This package is intended to replace im-switch which I maintain.  All Chinese,
Japanese , Korean, ... Input Methods tends to rely on im-switch for their easy
configuration. 

im-switch uses update-alternatives in very complicated way which makes quite
difficult to understand.  This package solves it.

(Actually, I added GUI to im-switch, so it became easier ... but this s
maintenance night mare.  This im-config solves it with easy code with GUI.)

Osamu






-- 
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/20100626184108.ga10...@debian.org

Re: Improve support for installing 32-bit libraries on 64-bit systems

[Steve Langasek]

On Fri, Jun 25, 2010 at 01:14:43PM +0200, David Kalnischkies wrote:

> If you look closer, MultiArch was at least for squeeze on the goal list.
> I guess it is pretty unlikely that we will make it, but i think it was more
> on the list to get a bit of noise and some progress -

That's not why it was put on the list, but unfortunately not as much forward
progress was made during the squeeze cycle as intended.

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


signature.asc
Description: Digital signature

Re: Essentiality of Bash

[Marc Haber]

On Sat, 26 Jun 2010 17:45:15 +0200, "Bernhard R. Link"
 wrote:
>* Marc Haber  [100626 14:07]:
>> On Fri, 25 Jun 2010 14:27:31 -0700, Steve Langasek 
>> >The footnote to Policy 3.5, where this is written out?
>>
>> Ah, so this is the same as the no-circular-dependency rule, dumping
>> extra error proneness and extra thoughtweight on all developers
>
>Please, try to be a bit more fair. Having people not need to specify
>dependencies is really not the solution that "dumps extra error
>proneness and extra thoughtweight" on the developers.

Imagine an embedded system that doesn't have bash for some reason and
a local admin wanting to install a package containing /bin/bash
scripts. This can be done given the current situation, but leads to
subsequent failure.

>I'm personally all in favor for making the "hard to deinstall"
>and "not needed in dependencies" different things

Agreed.

>If you read the second paragraph it also gives a reason that has nothing
>at all to do with making it easier for software [1]: If there are no
>dependencies, essential stuff can just move between packages or have
>packages renamed.

How often do we do that?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1osbzh-0002so...@swivel.zugschlus.de

Re: Essentiality of Bash

[Marc Haber]

On Sat, 26 Jun 2010 15:20:46 +0200, Josselin Mouette 
wrote:
>Furthermore, I’d be interested to know how to fix such a “shortcoming”
>in our software. If both A and B depend on each other, A.postinst must
>be executed before B.postinst, and vice versa.

That's only one kind of circular dependency, and the one making the
problems. When you look at the circular dependencies, for example
within the exim4 or the aide packages, you see that the dependencies
defined in there aren't _that_ strict.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1osc0q-0002vd...@swivel.zugschlus.de

Re: Essentiality of Bash

[Russ Allbery]

Marc Haber  writes:
> "Bernhard R. Link"  wrote:

>> Please, try to be a bit more fair. Having people not need to specify
>> dependencies is really not the solution that "dumps extra error
>> proneness and extra thoughtweight" on the developers.

> Imagine an embedded system that doesn't have bash for some reason and
> a local admin wanting to install a package containing /bin/bash
> scripts. This can be done given the current situation, but leads to
> subsequent failure.

The problem that I have with this argument is that it seems to imply the
situation is improved for that embedded system if some random minority of
Debian packagers explicitly declare the dependency on bash, while most
continue not to do so.  I don't see a lot of justification for that
implication.  Unless a reasonable percentage of the archive has the
dependency expressed correctly, the embedded system is going to have to
deal with this in some other way.  A small handful of developers adding
explicit depencencies is not going to be meaningful assistance.

Put another way, supporting removal of bash is something that we'd have to
do as a project.  Right now, we've made a conscious decision to not
support that.  A small handful of developers adding explicitly
dependencies creates some other (mostly minor) issues and seems very
unlikely to substantively change that situation.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87aaqhwmo1@windlord.stanford.edu

Re: Improve support for installing 32-bit libraries on 64-bit systems

[Luca Bruno]

David Kalnischkies scrisse:
 
> The biggest showstoppers are as far as i know that
> a) dpkg doesn't support it
> b) APT doesn't support it
> c) (not many) packages use it (last time i check ~24)
> 
> c) is likely caused by a) and b) which in fact decreases the
> motivation for a) and b) to implement it as nobody use it… ***
> dependency loop detected ***

Goswin recently offered some help to improve the situation regarding a)
and c) points, but I've seen no (public) answer from you:
http://lists.debian.org/debian-devel/2010/04/msg00493.html

Given that you say apt in experimental is semi-working, it would be
interesting to join forces and see if something almost test-able can
be provided.
If so, it would also be useful to advertise it a bit more and hoping to
gain some momentum...

Ciao, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.| lucab (AT) debian.org
`. `'`  | GPG Key ID: 3BFB9FB3
  `- http://www.debian.org  | Debian GNU/Linux Developer


pgp9Dkea2yZCS.pgp
Description: PGP signature

Re: Accepted sdm 0.4.1-2 (source all)

[Bill Allombert]

On Sat, Jun 26, 2010 at 02:40:37PM +0100, Julien Cristau wrote:
> On Sat, Jun 26, 2010 at 12:57:45 +, Vagrant Cascadian wrote:
> 
> >  sdm (0.4.1-2) unstable; urgency=low
> >  .
> [...]
> >* No longer include dash as a dependency; it is included in essential.
> >* Add lintian overrides for missing-dep-for-interpreter dash, as dash
> >  is now essential.
> 
> My understanding was that dash was only in the Essential set as the
> default provider of /bin/sh, and that /bin/dash was explicitly *not*
> guaranteed to stay in Essential, and thus packages using that need to
> keep their dependencies.  Did I misunderstand, or is the above change
> wrong?

One problem is that Debian lacks a mechanism to prevent the removal
of /bin/sh (and also of the root shell) by the packaging system.
For example if you set the root shell to zsh-static, an upgrade can
remove the shell temporarily.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
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/20100626220721.ge23...@yellowpig

Bug#587274: ITP: denoiser -- Rapid denoising of pyrosequencing amplicon data

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: denoiser
  Version : 0.8.5
* URL : http://www.microbio.me/denoiser/
* License : GPL
  Programming Lang: Haskell
  Description : Rapid denoising of pyrosequencing amplicon data

 To denoise pyrosequencing amplicon data, the package exploits the
 rank-abundance distribution.  PyroNoise uses an expectation maximization
 (EM) algorithm to figure out the most likely sequence for every read. We,
 instead, use a greedy scheme that can be seen as an approximation to
 PyroNoise. According to several test data sets, the approximation gives
 very similar results in a fraction of the time.



-- 
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/20100626224823.22100.98926.report...@toshiba.siemens

Bug#587275: ITP: qiime -- Quantitative Insights Into Microbial Ecology

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: qiime
  Version : 1.1.0
* URL : http://qiime.sf.net
* License : GPL
  Description : Quantitative Insights Into Microbial Ecology

 QIIME (canonically pronounced ‘Chime’) is a pipeline for performing
 microbial community analysis that integrates many third party tools which
 have become standard in the field. A standard QIIME analysis begins with
 sequence data from one or more sequencing platforms, including Sanger,
 Roche/454, and Illumina GAIIx. With all the underlying tools installed,
 of which not all are yet available in Debian (or any other Linux
 distribution), QIIME can perform library de-multiplexing and quality
 filtering; denoising with PyroNoise; OTU and representative set picking
 with uclust, cdhit, mothur, BLAST, or other tools; taxonomy assignment
 with BLAST or the RDP classifier; sequence alignment with PyNAST, muscle,
 infernal, or other tools; phylogeny reconstruction with FastTree, raxml,
 clearcut, or other tools; alpha diversity and rarefaction, including
 visualization of results, using over 20 metrics including Phylogenetic
 Diversity, chao1, and observed species; beta diversity and rarefaction,
 including visualization of results, using over 25 metrics including
 weighted and unweighted UniFrac, Euclidean distance, and Bray-Curtis;
 summarization and visualization of taxonomic composition of samples
 using pie charts and histograms; and many other features.
 .
 QIIME includes parallelization capabilities for many of the
 computationally intensive steps. By default, these are configured to
 utilize a mutli-core environment, and are easily configured to run in
 a cluster environment. QIIME is built in Python using the open-source
 PyCogent toolkit. It makes extensive use of unit tests, and is highly
 modular to facilitate custom analyses.



-- 
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/20100626231912.23778.53611.report...@toshiba.siemens

Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues

[Christoph Anton Mitterer]

Hi folks.

IIRC, Jonas already put some of these issues up here some time ago.
I was recently investigating, and thanks to the help of many people
found out how deep the problems actually are.

Following a discussion at lkml
(http://thread.gmane.org/gmane.linux.kernel/1003210), I've decided that
it would be a good idea to try bringing all kernel developer experts and
(regarding Debian) maintainers together. 


It goes about booting/startup/shutdown of filesystems (including the
root-filesystem) when those are on possible multiple block device layers
(e.g. disk-->lvm-->dmcrypt-->filesystem).

I've put up a wiki site
(http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices) 
which tries to describe and discuss the main issues and related issues.


It's on the Debian wiki, but I guess (as most of them are probably
inter-distro-issues ^^) we can happily invite all non-Debian people to
join the discussion :) .

I've also tried to separate the generic discussion from every Debian
related.


In order to draw attention of the Debian maintainers (respectively their
lists) which I guess are at least affected with their packages, I've
CCed them in this mail.
Please remove them if you reply to it, or the might be quite annoyed
(and blame me ;) ).
If I forget any package that is related, please tell them or let me note
them.


Best wishes,
Chris.


-- 
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/1277606894.9943.18.ca...@fermat.scientia.net

Re: Accepted sdm 0.4.1-2 (source all)

[Raphael Geissert]

Russ Allbery wrote:
> I think it's moderately unlikely that we're going to manage to keep dash
> from being treated as essential even if we say that it's only essential
> for the /bin/sh functionality.

Based on [1], [2] and [3], there's no single package that ships a /bin/dash 
script but doesn't depend on dash. If we exclude dash from the *depends-on-
essential-* checks I don't think it will be too difficult to preserve the 
current status.

The next target would be to make packages using /bin/bash to start depending 
on bash, but I can see that taking years (but excluding bash from the same 
checks as dash would give the hint that it is fine to depend on it.)

[1] http://lintian.debian.org/tags/missing-dep-for-interpreter.html
[2] http://lintian.debian.org/tags/build-depends-on-essential-package-
without-using-version.html
[3] http://lintian.debian.org/tags/depends-on-essential-package-without-
using-version.html

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/i06l76$7u...@dough.gmane.org

Re: Accepted sdm 0.4.1-2 (source all)

[Russ Allbery]

Raphael Geissert  writes:
> Russ Allbery wrote:

>> I think it's moderately unlikely that we're going to manage to keep dash
>> from being treated as essential even if we say that it's only essential
>> for the /bin/sh functionality.

> Based on [1], [2] and [3], there's no single package that ships a /bin/dash 
> script but doesn't depend on dash. If we exclude dash from the *depends-on-
> essential-* checks I don't think it will be too difficult to preserve the 
> current status.

Okay, let's just do that, then, and see how it goes.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87lja1cbns@windlord.stanford.edu

Re: Essentiality of Bash

[Marc Haber]

On Sat, 26 Jun 2010 13:42:38 -0700, Russ Allbery 
wrote:
>The problem that I have with this argument is that it seems to imply the
>situation is improved for that embedded system if some random minority of
>Debian packagers explicitly declare the dependency on bash, while most
>continue not to do so.  I don't see a lot of justification for that
>implication.  Unless a reasonable percentage of the archive has the
>dependency expressed correctly, the embedded system is going to have to
>deal with this in some other way.  A small handful of developers adding
>explicit depencencies is not going to be meaningful assistance.

Agreed. The rule needs to be reversed.

>Put another way, supporting removal of bash is something that we'd have to
>do as a project.  Right now, we've made a conscious decision to not
>support that.  A small handful of developers adding explicitly
>dependencies creates some other (mostly minor) issues and seems very
>unlikely to substantively change that situation.

Agreed as well.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1oslqs-0006et...@swivel.zugschlus.de