Re: Bug#531450: ITP: gmameui -- front-end for the arcade games emulator MAME

[Loïc Martin]

Paul Wise wrote:

I note the GPLv2+ is probably not compatible with the MAME non-free
license. How does gmameui interact with MAME? Is the way it does that
likely to form a derivative work? If so we cannot distribute gmameui.


Yes, the MAME license restricts commercial use, and is thus non 
gpl-compatible.


As we've just talked on IRC, gmameui runs mame in a separate process.
Thanks for your help!



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

Renaming of new package that has an ITP bugreport (ITP: task - Bug#531587)

[Federico Hernandez]

As I forgot to CC the ITP bug to the list I want to do this now afterwards
and include a question:

The bugreport is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531587

After an initial view on the package Charles Plessy suggested to rename the
package to avoid confusion with the existing package "tasks". I have done
this now after getting in touch with the upstream project (actually I
contributed to project). The upstream maintainers are planning to rename the
project in the future to "taskwarrior" and it is OK to use this name already
for the debian package.

So the renamed package is now called taskwarrior and has been uploaded to
mentors.debian.org (together with a RFS to the debain.-mentors
mailiniglist).

To superseed the old upload I increased the version number of the package to
1.7.0-2 while renaming it. I still refer to the original ITP bugreport in
the changelog file and explain why the package was renamed.

Would that be sufficient?

Or should I file a new ITP with the correct packagename or change the
subject of the current ITP bugreport by maling cont...@bugs.ddebian.org with
the retitle command.

Greetings,
Federico "Fredde" Hernandez



The original bugreport:

Subject: ITP: task - An open source, command-line, TODO list manager
Package: wnpp
Severity: wishlist
Package name : task
Version : 1.7.0
Upstream Author : Paul Beckingham 
URL : http://www.beckingham.net/task.html
License : GPLv2+
Description :
Task is an open source, command-line, TODO list manager. It is
scope-limited to GTD functionality and features: tags, colorful
tabular output, reports and graphs, lots of commands, low-level
API, abbreviations for all commands and options, multiuser file
locking, recurring tasks. Task is based on ideas presented in
the todo.sh script found on: http://todotxt.org 

Re: no deprecation of /usr as a standalone filesystem

[Carsten Hey]

On Mon, Jun 01, 2009 at 03:50:50PM +0200, Josselin Mouette wrote:
> Nowadays, you cannot use your system if you don’t use udev, so this is
> irrelevant.

I'm writing this mail from a system without udev:

  $ cat /proc/version
  Linux version 2.6.26-1-vserver-686 (Debian 2.6.26-12) (wa...@debian.org) (gcc 
version 4.1.3 20080704 (prerelease) (Debian 4.1.2-24)) #1 SMP Mon Dec 15 
21:11:05 UTC 2008
  $ dpkg -s udev | grep Status
  Status: unknown ok not-installed
  $ dpkg -s yaird | grep Status
  Status: install ok installed

(Yes, I need to reboot ...)


Regards
Carsten


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

Bug#531673: ITP: oasis3 -- Coupler for exchanging fields between components of Earth system models

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: oasis3
  Version : 3.3
  Upstream Author : Sophie Valcke  
* URL : 
http://www.prism.enes.org/PAEs/coupling_IO/software_OASIS3.php
* License : GPL-2
  Programming Lang: Fortran
  Description : Coupler for exchanging fields between components of Earth 
system models

OASIS3 is the direct evolution of the OASIS coupler developed since more than 
10 years at CERFACS (Toulouse, France). Portability and flexibility are 
OASIS3 key design concepts. At run-time, OASIS3 acts as a separate mono process 
executable, which main function is to interpolate the coupling fields 
exchanged between the component models, and as a library linked to the 
component models, the OASIS3 PRISM Model Interface Library (OASIS3 PSMILe).

OASIS3 supports 2D coupling fields only. To communicate with OASIS3, directly 
with another model, or to perform I/O actions, a component model needs to 
include few specific PSMILe calls. OASIS3 PSMILe supports in particular 
parallel communication between a parallel component model and OASIS3 main 
process based on Message Passing Interface (MPI) and file I/O using the GFDL 
mpp_io library. 

OASIS3 has been extensively used in the PRISM demonstration runs and is 
currently used by approximately 15 climate modelling groups in Europe, USA, 
Canada, Australia, India and Brazil.

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)



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

Re: Renaming of new package that has an ITP bugreport (ITP: task - Bug#531587)

[Jonathan Wiltshire]

On Wed, Jun 03, 2009 at 10:58:31AM +0200, Federico Hernandez wrote:
> So the renamed package is now called taskwarrior and has been uploaded to
> mentors.debian.org (together with a RFS to the debain.-mentors
> mailiniglist).
> 
> To superseed the old upload I increased the version number of the package to
> 1.7.0-2 while renaming it. I still refer to the original ITP bugreport in
> the changelog file and explain why the package was renamed.

mentors.d.n will accept the same version of a package and overwrite it,
even though the main archive will not. It will warn you when this
happens.

> Or should I file a new ITP with the correct packagename or change the
> subject of the current ITP bugreport by maling cont...@bugs.ddebian.org with
> the retitle command.

You can retitle the bug if you want, but I don't see any real need to do so
or remark on it in the changelog. 


-- 
Jonathan Wiltshire

PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3  A903 CA6B EA3E DB80 0B52


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

Bug#531699: ITP: apt-offline -- Offline APT Package Manager

[Ritesh Raj Sarraf]

Package: wnpp
Severity: wishlist
Owner: Ritesh Raj Sarraf 

* Package name: apt-offline
  Version : 0.8.0
  Upstream Author : Ritesh Raj Sarraf 
* URL : http://pypt-offline.sf.net
* License : GPL
  Programming Lang: Python
  Description : Offline APT Package Manager

apt-offline is a utility for people using Debian (and distros
based on Debian) on a machine with no network connectivity.
It helps in downloading the required Package Management data
from another networked Windows/Linux/Mac box.

Some of the features of apt-offline are:
 - Fetch the list of package updates
 - Generate the list of packages to be upgraded
 - Offline Bug Reports (Currently only Debian BTS)
 - Multiple download threads
 - apt cache check
 - Multiple Platform Support

Dear DDs,
The original name referred in the upstream link is pypt-offline.
Since Debian currently doesn't have a package named apt-offline, I'd
like to take over this name for the utility I've developed, if there is
no objection.



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

Bug#531700: ITP: python-django-site-assets -- Concatenate, minify and compress CSS and JS assets, for Django

[Janos Guljas]

Package: wnpp
Severity: wishlist
Owner: Janos Guljas 

* Package name: python-django-site-assets
  Version : 0.1
  Upstream Author : Branko Vukelic 
* URL : http://github.com/foxbunny/django-site-assets
* License : BSD
  Programming Lang: Python
  Description : Concatenate, minify and compress CSS and JS assets, for 
Django

 Django SiteAssets is a set of template tags and scripts that help concatenate,
 minify, compress, and generate HTML elements for, JavaScript and CSS assets.
 The application is coded so that the defauts work in 99% of cases, but also
 super-customizable to cover the remaining 1%.



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

Bug#531712: ITP: audex -- Audio grabber tool for KDE

[Romain Beauxis]

Package: wnpp
Severity: wishlist
Owner: Romain Beauxis 


* Package name: audex
  Version : 0.71b2
  Upstream Author : Marco Nelles 
* URL : http://opensource.maniatek.de/cgi-bin/audex/audex/index.html
* License : GPL2
  Programming Lang: C++
  Description : Audio grabber tool for KDE

 Audex is a new audio grabber tool for CD-ROM drives for the KDE desktop.
 .
 The assistant is able to create profiles for LAME, OGG Vorbis (oggenc),
 FLAC, FAAC (AAC/MP4) and RIFF WAVE. Please install your favorite encoder.
 Of course for WAVE no external encoder is needed!
 Beyond the assistant you can define your own profile, which means, that
 audex works together with commmand line encoders in general.
 .
 Some features are:
  * Extracting with CDDA Paranoia. So you have quite perfect audio quality.
  * Extracting and encoding run parallel.
  * Filename editing with local and remote CDDB/FreeDB database.
  * Submit new entries to CDDB/FreeDB database.
  * Metadata correction tools like capitalize etc.
  * Multi-profile extraction (with one commandline-encoder per profile).
  * Fetch covers from the internet and store them in the database.
  * Create playlists, cover and template-based-info files in target directory.
  * Creates extraction and encoding protocols.
  * Transfer files to a FTP-server.


This package is imported from ubuntu and will be co-maintained by me and 
its original ubuntu maintainer.

Audex is a very good replacement for kaudiocreator that didn't survive the 
KDE4 transition..


Romain



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

Re: no deprecation of /usr as a standalone filesystem

[Marco d'Itri]

On Jun 03, Carsten Hey  wrote:

> I'm writing this mail from a system without udev:
Yes, and nobody cares much. Many functions of modern systems require
udev and more and more will with time.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: no deprecation of /usr as a standalone filesystem

[Carsten Hey]

On Wed, Jun 03, 2009 at 02:59:52PM +0200, Marco d'Itri wrote:
> > On Jun 03, Carsten Hey  wrote:
> > > On Mon, Jun 01, 2009 at 03:50:50PM +0200, Josselin Mouette wrote:
> > Nowadays, you cannot use your system if you don’t use udev, so this
> > is irrelevant.
> >
> > I'm writing this mail from a system without udev:
>
> Yes, and nobody cares much.

Correct, it just shows that "your argument is irrelevant because you
can't use a system without udev" is wrong, at least for lenny.

Someone wrote a while ago:
> Debian ... will be easy to keep up-to-date with a 'upgrading' script
> in the base system which will allow complete integration of upgrade
> packages.

How do you plan to ensure that upgrading from one stable release to the
next is possible after deprecating /usr as a separate partition?  Or do
you plan to force all the systems using a separate /usr to be
reinstalled whilst being upgraded to squeeze+n?


Regards
Carsten


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

Bug#531743: ITP: python-fixture -- Python module for loading and referencing test data

[Julián Hernández Gómez]

Package: wnpp
Severity: wishlist
Owner: "Julián Hernández Gómez" 

* Package name: python-fixture
  Version : 1.1.2
  Upstream Author : Kumar McMillan 
* URL : http://farmdev.com/projects/fixture/
* License : LGPL-2.1+
  Programming Lang: Python
  Description : Python module for loading and referencing test data

 It provides several utilities for achieving a fixed state when
 testing Python programs. Specifically, these utilities setup /
 teardown databases and work with temporary file systems. This is
 useful for testing and came about to fulfill stories like these:
 .
 * I want to load data into a test database and easily reference that
   data when making assertions.
 * I want data linked by foreign key to load automatically and delete
   without integrity error.
 * I want to reference linked rows by meaningful names, not hard-coded
   ID numbers.
 * I don’t want to worry about auto-incrementing sequences.
 * I want to recreate an environment (say, for a bug) by querying a
   database for real data.
 * I want to test with files in a temporary, transparent file system.



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

Re: Bug#531581: Critical problems on hppa and ia64 buildds

[Frank Küster]

[a failed build was wrongly assigned as a RC bug of texlive-base, and
since the reason was a problem on the buildd, I assigned it to
buildd.debian.org] 

Luk Claes  wrote:

> buildd.d.o is not the place to reassign bugs for particular buildds to.
> If it's just for particular buildds, you'd better contact the buildd
> admin like you did.

And what should one do with a bug like this?  At the moment it's quite
irrelevant whether one of our packages has a bogus RC bug.  But what if
that happens when I'm hoping for a transition to testing?

What do people generally do in such a case?  What should we do?

Regards, Frank
-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


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

Bug#531761: ITP: liblatex-encode-perl -- Perl module to encode characters for LaTeX formatting

[Salvatore Bonaccorso]

Package: wnpp
Severity: wishlist
Owner: Salvatore Bonaccorso 

* Package name: liblatex-encode-perl
  Version : 0.03
  Upstream Author : Andrew Ford 
* URL : http://search.cpan.org/dist/LaTeX-Encode/
* License : Perl
  Programming Lang: Perl
  Description : Perl module to encode characters for LaTeX formatting

 LaTeX::Encode provides a function to encode text that is to be formatted with
 LaTeX. It encodes characters that are special to LaTeX or that are
 represented in LaTeX by LaTeX commands.
 .
 The special characters are: \ (command character), { (open group), } (end
 group), & (table column separator), # (parameter specifier), % (comment
 character), _ (subscript), ^ (superscript), ~ (non-breakable space), $
 (mathematics mode).
 .
 Note that some of the LaTeX commands for characters are defined in the LaTeX
 textcomp package. If your text includes such characters, you will need to
 include the following lines in the preamble to your LaTeX document.
 .
  \usepackage[T1]{fontenc}
  \usepackage{textcomp}

This Perl module is needed to fullfill the csv2pdf requirements in
liblatex-table-perl.



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

Bug#531763: ITP: liblatex-driver-perl -- driver module that encapsulates the details of formatting a LaTeX document

[Salvatore Bonaccorso]

Package: wnpp
Severity: wishlist
Owner: Salvatore Bonaccorso 

* Package name: liblatex-driver-perl
  Version : 0.08
  Upstream Author : Andrew Ford 
* URL : http://search.cpan.org/dist/LaTeX-Driver-0.08/
* License : Perl
  Programming Lang: Perl
  Description : driver module that encapsulates the details of formatting a 
LaTeX document

 The LaTeX::Driver module encapsulates the details of invoking the Latex
 programs to format a LaTeX document. Formatting with LaTeX is complicated;
 there are potentially many programs to run and the output of those programs
 must be monitored to determine whether further processing is required.
 .
 LaTeX::Driver runs the required commands in the directory specified, either
 explicitly with the dirname option or implicitly by the directory part of
 basename, or in the current directory. As a result of the processing up to a
 dozen or more intermediate files are created. These can be removed with the
 cleanup method.
 .
 The LaTeX::Driver module takes care of running and re-running latex on
 a LaTeX document so that forward references, tables of contents, and
 lists of figures and tables are resolved.  It will also run bibtex and
 makeindex if it detects that a bibliography or in index have been
 specified, and will re-run latex again one or more times until the
 formatting of the document has stabilized.



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

Re: Bug#531581: Critical problems on hppa and ia64 buildds

[Luk Claes]

Frank Küster wrote:
> [a failed build was wrongly assigned as a RC bug of texlive-base, and
> since the reason was a problem on the buildd, I assigned it to
> buildd.debian.org] 
> 
> Luk Claes  wrote:
> 
>> buildd.d.o is not the place to reassign bugs for particular buildds to.
>> If it's just for particular buildds, you'd better contact the buildd
>> admin like you did.
> 
> And what should one do with a bug like this?  At the moment it's quite
> irrelevant whether one of our packages has a bogus RC bug.  But what if
> that happens when I'm hoping for a transition to testing?

Are you now talking about the failure on hppa or the one on ia64 (in
both cases the bugs were filed by the buildd admin)?

The one on hppa is as far as I can see nothing you can do about and
should probably be mentioned to the porters.

The one on ia64 breaks the buildd's chroot and looks to be easily solved
by making sure that the maintainer scripts don't fail when the missing
command is not available. You can indeed argue that it should not
happen, though I don't see what that brings you apart from a lot of
heated discussion and trouble?

Cheers

Luk


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

Bug#531762: ITP: libtomcrypt -- public domain open source cryptographic toolkit

[Michael Stapelberg]

Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg 

* Package name: libtomcrypt
  Version : 1.17
  Upstream Author : Tom St Denis 
* URL : http://www.libtomcrypt.com/
* License : Public Domain
  Programming Lang: C
  Description : public domain open source cryptographic toolkit

LibTomCrypt is a well documented, public domain open source crypthographic
toolkit written in C. It supports lots of block ciphers (Blowfish, Twofish,
AES, XTEA, ...), chaining modes (ECB, CBC, OFB, CFB, CTR, ...), hash functions
(MD5, SHA-1, SHA-256, RIPE-MD, ...), HMAC mechanisms, pseudo-random number
generators and public key algorithms. It has several optimizations for the
i386, x86_64 and ppc32 architecture.



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

Re: Bug#531581: Critical problems on hppa and ia64 buildds

[Frank Küster]

Luk Claes  wrote:

>> And what should one do with a bug like this?  At the moment it's quite
>> irrelevant whether one of our packages has a bogus RC bug.  But what if
>> that happens when I'm hoping for a transition to testing?
>
> Are you now talking about the failure on hppa or the one on ia64 (in
> both cases the bugs were filed by the buildd admin)?

I'm talking about any bug that was filed against package $foo because
package $bar FTBFS on $buildd_a, when it later turns out that the reason
for the breakage is "something" on $buildd_a.

> The one on hppa is as far as I can see nothing you can do about and
> should probably be mentioned to the porters.

That doesn't solve my problem: Should I 

- keep the bug open against my package? Doesn't make sense, since I have
  no bug

- make sure that the porters, buildd admins etc. are aware of the
  problem and simply close the bug?

- reassign to buildd.debian.org: That you just said I shouldn't do

- reassign to $computer_name.buildd.debian.org: That would make most
  sense, but it isn't possible.

> The one on ia64 breaks the buildd's chroot and looks to be easily solved
> by making sure that the maintainer scripts don't fail when the missing
> command is not available. 

? 

It could be easily solved by making sure that nothing on the buildd
installs packages without installing their dependencies.

Regards, Frank
-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


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

Re: Bug#531581: Critical problems on hppa and ia64 buildds

[Luk Claes]

Frank Küster wrote:
> Luk Claes  wrote:
> 
>>> And what should one do with a bug like this?  At the moment it's quite
>>> irrelevant whether one of our packages has a bogus RC bug.  But what if
>>> that happens when I'm hoping for a transition to testing?
>> Are you now talking about the failure on hppa or the one on ia64 (in
>> both cases the bugs were filed by the buildd admin)?
> 
> I'm talking about any bug that was filed against package $foo because
> package $bar FTBFS on $buildd_a, when it later turns out that the reason
> for the breakage is "something" on $buildd_a.
> 
>> The one on hppa is as far as I can see nothing you can do about and
>> should probably be mentioned to the porters.
> 
> That doesn't solve my problem: Should I 

> - make sure that the porters, buildd admins etc. are aware of the
>   problem and simply close the bug?

You might want to downgrade the bug and only close it when it is realy
solved?

>> The one on ia64 breaks the buildd's chroot and looks to be easily solved
>> by making sure that the maintainer scripts don't fail when the missing
>> command is not available. 
> 
> ? 
> 
> It could be easily solved by making sure that nothing on the buildd
> installs packages without installing their dependencies.

A patch is appreciated, thanks for your cooperation.

Cheers

Luk


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

Re: no deprecation of /usr as a standalone filesystem

[Ken Bloom]

Josselin Mouette  wrote:
> Le lundi 01 juin 2009 à 16:26 +0200, Goswin von Brederlow a écrit :
> > > What has the initramfs got to do with this?
> > 
> > For / to be on LVM you need an initramfs. / on raid (with custom
> > kernel) or plain partition works without one.
> 
> I already know that, thanks, but it still doesn’t make your point. Just
> because you have some religious taboo against initramfs doesn’t make it
> an invalid solution.

Go back and look at what Goswin wrote in the first place:

> As long as debian does not provide support for kernel independent non
> breaking initramfs support (i.e. not regenerated on every whim and
> break) having / outside lvm and no initramfs is a real plus.

It sounds like he feels that having an initramfs is very fragile the way
Debian handles it now. If / is outside of lvm, then when the initramfs
breaks, he can boot up without it and get to a place where he can
regenerate an initramfs. That's not "a religious taboo against
initramfs." That's sensible troubleshooting behavior.

--Ken


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

Re: Bug#531581: Critical problems on hppa and ia64 buildds

[Manoj Srivastava]

On Wed, Jun 03 2009, Luk Claes wrote:

> Frank Küster wrote:
>> Luk Claes  wrote:
>> 
 And what should one do with a bug like this?  At the moment it's quite
 irrelevant whether one of our packages has a bogus RC bug.  But what if
 that happens when I'm hoping for a transition to testing?
>>> Are you now talking about the failure on hppa or the one on ia64 (in
>>> both cases the bugs were filed by the buildd admin)?
>> 
>> I'm talking about any bug that was filed against package $foo because
>> package $bar FTBFS on $buildd_a, when it later turns out that the reason
>> for the breakage is "something" on $buildd_a.
>> 
>>> The one on hppa is as far as I can see nothing you can do about and
>>> should probably be mentioned to the porters.
>> 
>> That doesn't solve my problem: Should I 
>
>> - make sure that the porters, buildd admins etc. are aware of the
>>   problem and simply close the bug?
>
> You might want to downgrade the bug and only close it when it is realy
> solved?

If it is not a bug in the package (in other words, no change
 made in the package would fix the issue), I see no point in keeping it
 open. It would be nice, however, is a psuedo-package were created for
 the buildds (or one per buildd, though that seems excessive) so such
 issues can be tracked in a central location, rather than scattered
 across the 9000 or so source packages. 

manoj
-- 
"If that makes any sense to you, you have a big problem." Durance,
Computer Science 234
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: no deprecation of /usr as a standalone filesystem

[Giacomo Catenazzi]

Marco d'Itri wrote:
> On Jun 02, "Giacomo A. Catenazzi"  wrote:
> 
>> - there is still a close windows in initram, and possibility
>>   at early rc scripts.
> No.
> 
>> - /var is still not mounted, so programs could not write they status, nor
>>   log failures
> So programs which have such requirements need to take care of waiting
> long enough. e.g. the ifupdown wrapper script waits for /dev/log to
> appear.
> 
>> - care about security implication: user that triggers events before system
>>   is fully up (e.g. busy resources)
> I see no security implications.

Wrong udev script could make busy resources, mounting point, ...
which cause an unexpected execution path  (when there are bugs on
udev scripts).

We cannot log problems, and we cannot reproduce errors, because
it is difficult to plug again devices at the exact same time
of previous run.

Some newbies (and others) will have wrong permissions in udev configuration
(google for udev rules, and you will see ugly and unsecure udev rules).
Such rules are not done by you or Debian, but we cannot ignore that people
do thing wrongly and publish it.

So the security rule I recently see in a RFC (which disabled some
cryptography algorithms): "seldom run paths should be considered
insecure"

> 
>> - and I think other usual system assumption are not fulfilled, so
>>   maintainers should be trained on what they could assume on udev sequence.
> Maintainers who have doubts can ask for help here or by private mail.
> 
>> For these reasons, I think only few events (explicitly ack by maintainers)
>> should be handled by early boot, and the rest run later (udev events are
>> already asynchronous by definition).
> There is no need for this.

More I think about the specific issue, the more I think we should not
accept hotplug before very late boot process: kernel and boot people
hate asynchronous boot process, because it boot process has
bugs, but it is very difficult to track such bugs.
With udev we have the same cases: how many of us test every device with
early plug?

Do we really need to handle such hotplugs? We could require that
all boot hardwares must be available short after boot loader. The
later plugged hardware will be shown only later, when the system
in up.  I see no disadvantage, and make thing easier, more
testable (and I think also more secure).


But nobody commented with the orthogonal question:
could we handle /usr specially and mount at the beginning?
We eventually lose networked /usr, but we can still use
plain non-crypted read-only /usr as an other partition.


ciao
cate


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