Re: On init in Debian

2012-03-18 Thread Josselin Mouette 
Le dimanche 18 mars 2012 à 00:35 +0800, Thomas Goirand a écrit : 
> I just had a look, and no, that's not what metainit does.
> What it does is *generating* an init.d script, using the
> metainit syntax as input. IMO, just a normal shell script
> tiny library to simplify our init.d scripts would be enough.

Sorry, this is not enough to switch to a decent init system.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Re: debian-multimedia.org considered harmful

2012-03-18 Thread Eric Valette 

On 18/03/2012 02:24, Christoph Anton Mitterer wrote:


Which distro provides Blu-Ray playback?



Even though there is libaacs and friends now... the MKBs are only
publicly known till version ... what? ... 10?



As long as it remains free of charge and available, you can package 
makemkv in non-free.


--eric


--
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/4f659bdc.8000...@free.fr

Re: debian-multimedia.org considered harmful

2012-03-18 Thread Reinhard Tartler 
On Sun, Mar 18, 2012 at 6:35 AM, Russ Allbery  wrote:
> Chris Knadle  writes:
>> On Saturday, March 17, 2012 21:53:18, Russ Allbery wrote:
>
>>> Hence the Debian patent policy.
>
>>> We can't just ignore things like this, nor is it responsible use of
>>> project resources to openly flaunt disobedience to laws, however
>>> ill-conceived.  But neither is it Debian policy to seek out trouble
>>> when that trouble isn't forthcoming.
>
>>> If you do want to be part of an organization that openly disobeys
>>> stupid laws and makes a point of civil disobedience, more power to you.
>>> I personally will be cheering you on.  But the Debian Project is not
>>> that organization, nor is it structured to be that organization (and
>>> carefully structuring such an organization is important).  The Debian
>>> Project has other goals, which mostly require that it work within the
>>> legal framework that it has available while making public statements
>>> when that legal framework interferes with project goals.
>
>> The above explains the whole reason d-m.o exists.
>
>> However perhaps it also might explain the tenuous relationship d.o has
>> with d-m.o because d.o may need to distance itself from the work d-m.o
>> does.
>
> Yup.  Exactly.  Christian is taking on himself the legal risk of providing
> those packages, which the project as a whole can't really do.  Discussion
> about the confusion that can be caused by some of the other packages he
> carries aside (and I do think that issue is real), I for one thank him for
> his work.

It would be great if dmo would restrict itself to this, or at least
separate these "add-on" packages from packages that are problematic.

Unfortunately, dmo does not categorize his archive in a way that would
allow recommending at least parts. Therefore, adding this archive to
the package sources of a system remains harmful.

-- 
regards,
    Reinhard


--
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/CAJ0cceZiCwgdkQtW5LDrTFWwVDEUgcZvySjPZR5VoSd4mp=8...@mail.gmail.com

Re: On init in Debian

2012-03-18 Thread Tollef Fog Heen 
]] Thomas Goirand 

> I'd like people to think twice before opt-in for systemd. I just
> taked with a friend working for redhat, and he told me how much
> he hates it. He told me that if *anything* goes wrong in the boot
> process, then basically, you're stuck, because the next thing will
> be waiting forever. That's basically truth with any event based
> init, and maybe we're just fine with just dependency booting.

Then just have something starting a getty on ttyN very early in the boot
process or even from the initramfs?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/877gyitf9y@qurzaw.varnish-software.com

Re: debian-multimedia.org considered harmful

2012-03-18 Thread Thomas Goirand 
On 03/18/2012 08:53 AM, Romain Beauxis wrote:
> It's a cliche comparison but still, CSS decryption is the knife and
> DMCA is the murder; the fact that murder is illegal does not imply
> that knives are.
>   
Well, the whole concept of DMCA is to make knives illegal!
Please read a bit more about it before making such wrong statement here.

Thomas


-- 
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/4f65bdae.7030...@debian.org

Re: debian-multimedia.org considered harmful

2012-03-18 Thread Chris Knadle 
On Sunday, March 18, 2012 04:51:10, Reinhard Tartler wrote:
> On Sun, Mar 18, 2012 at 6:35 AM, Russ Allbery  wrote:
> > Chris Knadle  writes:
> >> On Saturday, March 17, 2012 21:53:18, Russ Allbery wrote:
> >>> Hence the Debian patent policy.
> >>> 
> >>> We can't just ignore things like this, nor is it responsible use of
> >>> project resources to openly flaunt disobedience to laws, however
> >>> ill-conceived.  But neither is it Debian policy to seek out trouble
> >>> when that trouble isn't forthcoming.
> >>> 
> >>> If you do want to be part of an organization that openly disobeys
> >>> stupid laws and makes a point of civil disobedience, more power to you.
> >>> I personally will be cheering you on.  But the Debian Project is not
> >>> that organization, nor is it structured to be that organization (and
> >>> carefully structuring such an organization is important).  The Debian
> >>> Project has other goals, which mostly require that it work within the
> >>> legal framework that it has available while making public statements
> >>> when that legal framework interferes with project goals.
> >> 
> >> The above explains the whole reason d-m.o exists.
> >> 
> >> However perhaps it also might explain the tenuous relationship d.o has
> >> with d-m.o because d.o may need to distance itself from the work d-m.o
> >> does.
> > 
> > Yup.  Exactly.  Christian is taking on himself the legal risk of
> > providing those packages, which the project as a whole can't really do.
> >  Discussion about the confusion that can be caused by some of the other
> > packages he carries aside (and I do think that issue is real), I for one
> > thank him for his work.
> 
> It would be great if dmo would restrict itself to this, or at least
> separate these "add-on" packages from packages that are problematic.

Some public discussion with the repository maintainer about this might be 
warranted.  Such would be worhwhile even if the outcome is not what is 
desired, because at least then there will be a public record of where d-m.o 
and d.o stand.

> Unfortunately, dmo does not categorize his archive in a way that would
> allow recommending at least parts. Therefore, adding this archive to
> the package sources of a system remains harmful.

If d-m.o doesn't have a BTS, requesting that one be created I think is 
reasonable.  Filing bugs on the packages in d-m.o (by whatever means is 
common) is reasonable.  IMHO putting priority on the packages within d.o over 
those in d-m.o for those that understand what that choice means is reasonable.

But what I don't think is realistic is requesting everyone not to use the 
archive at d-m.o.  And I also don't think that the answer of "any packages 
within d-m.o aren't worth debugging at all" sounds really lame; I certainly 
wouldn't want that to be the norm for Debian as a whole.  At minimum, users 
can and do use the d-m.o mailing list to file bugs, and they get handled, so 
I'd much rather that be the answer than for the bugs to simply be dropped and 
to point to the repo as a whole as the problem.

Now that said, I also don't think it's fair that the Debian BTS has to handle 
the bugs introduced from an external repository.  It would be nice if there 
was a way of clearly knowing that a package is external and telling the 
reporter of the bug where the bug needs to be filed instead.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
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/201203180950.39565.chris.kna...@coredump.us

adding information to wnpp

2012-03-18 Thread Henri Le Foll 

Hello

I don't know a to maintain a package, and I would be interested to 
maintain a package I use every day.


First I need to learn how to maintain an easy package. But I don't know 
how to find one.


Question
***
Is it possible to sort (and find) packages by the difficulty of its 
maintainance ?



proposition
**

If every package could contain information about the difficulty of its 
maintainance,


   - Every week on debian-devel the mail about Work-Needing and 
Prospective Packages could show this information.

   - The PTS could display this information in its general section
   - UDD could order and find packages by difficulty.

Here are the informations I think could be usefull in the wnpp mail (and 
in the PTS when it is not already there)



1. The name of the team the package belongs to.
==
   - I hope every package will one day belong to a team.
   - I think that each package in wnpp or rfa or rfh should belong to a 
team (other than QA).


2. the langages you need to know to maintain the package
=

3. an  automatically generated information about the difficulty to 
maintain the package

==
Three or more characters which could easily show the difficulty to 
maintain the package.

AA0 for simple ones.

This information should be generated automatically.

3.1 about the source package

A : a source package generates one binary package
B : a source package generates multiple binary package
C : a source package contains multiple upstream source.
D : used for D-I (udeb)
E : a library
F : a daemon
G : part of the kernel

3.2 about the conffiles and the maintainer script
---
A : no modification from d-h
B : only one file like copyright or control need attention

E : non trivial maintainer script
F : very difficult maintainer script.

3.3 if the package need to follow some sub-policy
-
O : none
A : java
B : perl
C : python


--
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/4f65f777.4070...@lefoll.eu

Re: Important information regarding upcoming dpkg 1.16.2 upload

2012-03-18 Thread Guillem Jover 
Hi,

On Sat, 2012-03-10 at 09:35:39 +0100, Guillem Jover wrote:
> I'll be uploading dpkg 1.16.2 targeting unstable, by the end of
> this weekend or beginning of next week the latest (after some final
> polishing).

Unfortunately I found some issues with the selection handling and with
dselect and this didn't happen. I'm doing final testing and polishing
now and should be uploading later today, if nothing else comes up...


With multiarch, non-installed selections w/o an architecture, do not
make sense, in addition there's no guarantee they match any entry
from the available file and the db could end up with a selection that
could not be addressed from the command line when other more specific
selections were present. As such the new dpkg will silently drop any
such selections, which look like (with possible Section and Priority
fields):

  Package: foo
  Status: install ok not-installed

Because those should have been already installed if they were
available, I don't think this should cause any issues, but if you
want to preserve them you'll need to save them before upgrading:

  dpkg --get-selection '*' > selections

In addition selections for packages unknown to dpkg will not be
accepted anymore.

> On-disk db damage
> -

> [...], upgrading from those versions to the new dpkg 1.16.2 might
> cause the status db to get messsed up in some conditions. Before
> upgrading, you should either downgrade to a non-multiarch enabled dpkg, or
> make sure there's no package present (i.e. with status >= config-files)
> with a mix of M-A:same and non-M-A:same instances. If there's such package
> with two instances, the new dpkg will consider that a “cross-grade” and
> as such replace one of them with the other, depending on the order they
> are parsed, but leaving any control files untouched; if there's more than
> two instances the new dpkg will outright refuse to parse such bogus and
> inconsistent status db.

I reworked the code to make it more resilient against manual edits of
the status file, which while not a recommended action it might happen
from time to time. As a side effect, this should turn the above issue
into a parsing error, instead of silent lose of information when
upgrading from those dpkg versions.

regards,
guillem


-- 
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/20120318140726.ga18...@gaara.hadrons.org

Bug#664019: marked as done (ITP: lintian4python -- Debian package checker (for Python packages))

2012-03-18 Thread Debian Bug Tracking System 
Your message dated Sun, 18 Mar 2012 00:17:09 +
with message-id 
and subject line Accepted lintian4python 0+20120317 (source all)
has caused the Debian Bug report #664019,
regarding ITP: lintian4python -- Debian package checker (for Python packages)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
664019: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664019
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: wnpp
Severity: wishlist
Owner: Jakub Wilk 

* Package name: lintian4python
  Upstream Author : Jakub Wilk 
* URL : https://bitbucket.org/jwilk/lintian4python/
* License : GPL-2+
  Programming Lang: Perl
  Description : Debian package checker (for Python packages)

Lintian dissects Debian packages and reports bugs and policy violations. 
It contains automated checks for many aspects of Debian policy as well 
as some checks for common errors.


This package provides an experimental flavor of lintian designed to 
check packages implemented in Python.


--
Jakub Wilk


--- End Message ---
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 17 Mar 2012 22:41:38 +0100
Source: lintian4python
Binary: lintian4python
Architecture: source all
Version: 0+20120317
Distribution: experimental
Urgency: low
Maintainer: Jakub Wilk 
Changed-By: Jakub Wilk 
Description: 
 lintian4python - Debian package checker (for Python packages)
Changes: 
 lintian4python (0+20120317) experimental; urgency=low
 .
   * Initial release.
   * Summary of tag changes:
 + Added:
   - SOURCES.txt-in-binary-package
   - cannot-parse-python-central-metadata
   - egg-info-version-mismatch
   - extension-uses-old-pyrex-import-type
   - incorrect-team-name
   - incorrect-vcs-field
   - missing-dependency-for-import
   - missing-requires.txt-dependency
   - missing-requires.txt-optional-dependency
   - missing-vcs-field
   - pth-file-modifies-sys.path
   - pyflakes-duplicate-argument
   - pyflakes-import-shadowed-by-loop-var
   - pyflakes-import-star-used
   - pyflakes-late-future-import
   - pyflakes-redefined-function
   - pyflakes-redefined-while-unused
   - pyflakes-undefined-export
   - pyflakes-undefined-local
   - pyflakes-undefined-name
   - pyflakes-unused-import
   - pyflakes-unused-variable
   - python-central-metadata-for-missing-files
   - python-depends-but-no-python-helper
   - python-module-but-no-python-depends
   - syntax-error
   - unknown-optional-project-in-requires.txt
   - unknown-project-in-requires.txt
Checksums-Sha1: 
 31e9d97e3e257603a4b1758aead457bab5ddd6e5 1440 lintian4python_0+20120317.dsc
 4232bab6ca4b3ed618f6d0790441e73910cfffbe 23280 lintian4python_0+20120317.tar.gz
 1cee66fffa80fbbf2bc3a5b3c192ea63d00b8f2d 22570 
lintian4python_0+20120317_all.deb
Checksums-Sha256: 
 c3647784c80a139d42d0b563ed295d067dcd1000e60a4174f1b18ea8f26f3f66 1440 
lintian4python_0+20120317.dsc
 d9034a9f744b9277834c341ede52e7673ae525a8638ad150822c9c9ef5ac1b27 23280 
lintian4python_0+20120317.tar.gz
 65fae622990e488a2fa1ced30dd9ae42be660a392dc1f5fd5aa46c5b17cf47dc 22570 
lintian4python_0+20120317_all.deb
Files: 
 d62a0faccf9ec72250ce68a5bb34e11c 1440 devel extra lintian4python_0+20120317.dsc
 86cfe37d176a8675e3d448e2e06dadd9 23280 devel extra 
lintian4python_0+20120317.tar.gz
 254e0afc737d2cdd70e03077b573e841 22570 devel extra 
lintian4python_0+20120317_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJPZRocAAoJEC1Os6YBVHX15S4P/RxcvN5LTpo0g7H2da153JR0
fuXuRaTHxpmSl7ZQJzRhCmzZij0xhJNA8EtV8VpIb2e4TJUIbx+XsylZcPWpJS+W
Cs7PVDgJgT+SHZC+1AQ4evJeAX7NKKOqeb5JIlBpsaCUSAD2wDFpk/RiHNeXDlM0
pNLHxJ+587BXdd2dbqgQaItMGBIA+2BR/bf5KsZW8wArCuvjKZJdrEGtDiVzahyC
2eut6XCur1PD01zJaO+2wQ9V2s2d4Fm6XLeESWwltwqQbOzbN8OqpZ+LUq4zcBZ0
7k7Wn/2JB6JN6NvZr0OpQUzpBqMzfJrw9Adth0F1mqZuyTCt3XWgzmf0LIVBTjgj
aYY5gRlPQeRkKgXpZaMh1jRpUvu0x9faB6IapzGmUxlNZyVtUApGY9SGWMtLnLzt
zSnWW/6fm05gU6PQP2H0xtRHze8Ki9RSW/l2oSCLwt8o+qG7YbMwCwmj/5ujbeex
e68LkiipfAcq7gF18mx76aU7bwLea2Y31YthelapbgM0dO+P7rYclnOvSOsQMfHD
mV6vByUUK9CNKk3Wbr6lDLsr27V4FHg0S8QdEdFmEOCbwj++jAjBqRIwXN0QWKdZ
rh+L/LctwmMvDYNr6dj274bMY/KqId17+dIH2NP8eA8pJv7TBhl6nq8/raQHUhIL
e3z48r+v1h6wEn+xDu8t
=lV8h
-END PGP SIGNATURE-


Accepted:
lintian4python_0+20120317.dsc
  to main/l/lintian4python/lintian4python_0+20120317.dsc
lintian4python_0+20120317.tar.gz
  to main/l/lintian4python/lintian4python_0+20120317.tar.gz
lintian4python_0+20120317_all.deb
  to main/l/lintian4python/l

Re: Important information regarding upcoming dpkg 1.16.2 upload

2012-03-18 Thread John D. Hendrickson and Sara Darnell 

Hi,  I like dselect, dpkg, and aptitude.  I have a request.  aptitude should 
import and export

/var/lib/dpkg/status

At least when asked.  Right now aptitude takes awkwardly and but doesn't give 
back.

It's not just private selections.  Private methods and worse pivate status make other programs 
impossible.


"aptitude : attempts to detect status of  dpkg or dselect"  That's is far short of par - noting how 
sipmle the task of using human readable status as save format is.


/var/lib/aptitude/pkgstatus

(also it uses pieced avail lists/ instead of unified avail in dpkg/ )

pkgstatus contains incorrect information!  and it codes states "1 3 3 4" while using wide text for 
everything but that.


My main concern is the these "states" for aptitude are private data - excluding other software - and 
covering up why things are wrong.  (takeover issues)


Lastly, an end user (me) can make install errors by using aptitude, dpkg, apt-get, dselect not 
realizing that aptitude uses privatized unshared current system disk status that isn't what dpkg 
uses (and how would you know if it's not in a status file to see?)


There's a way to get aptitude states maybe by relying on dump software.  Though relying on anyone 
keeping dumpers efficient and up to date simply isn't a great idea.


a more efficient status file (table) is maybe a good idea but using object dumps for system status - 
not wise.


Thanks much i enjoy aptitude and dselect both :)

John

http://sourceforge.net/projects/dep-trace

see examples

new ver not yet uploaded show specific depends order of all in status
 which it can't do without status [and dpkg --compare-versions]

anohter script has demonstrated it then can use dpkg to , optionally ,
use current status dependancy order as an order to install new packages


On Sat, 2012-03-10 at 09:35:39 +0100, Guillem Jover wrote:

I'll be uploading dpkg 1.16.2 targeting unstable, by the end of


from the available file and the db could end up with a selection that
could not be addressed from the command line when other more specific
selections were present.

  Package: foo
  Status: install ok not-installed


--
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/4f65fc36.4040...@cox.net

dpkg, aptitude and use of state files (was: Re: Important information regarding upcoming dpkg 1.16.2 upload)

2012-03-18 Thread Daniel Hartwig 
TL;DR: aptitude does keep dpkg/status and apt/extended_states
up-to-date with the *current* state of a package, just like other
software.  Please do not grok pkgstates to determine if something is
installed, etc.

On 18 March 2012 23:16, John D. Hendrickson and Sara Darnell
 wrote:
> Hi,  I like dselect, dpkg, and aptitude.  I have a request.  aptitude should
> import and export
>
>/var/lib/dpkg/status
>
> At least when asked.  Right now aptitude takes awkwardly and but doesn't
> give back.
>
> It's not just private selections.  Private methods and worse pivate status
> make other programs impossible.
>
> "aptitude : attempts to detect status of  dpkg or dselect"  That's is far
> short of par - noting how sipmle the task of using human readable status as
> save format is.
>
>/var/lib/aptitude/pkgstatus
>
>(also it uses pieced avail lists/ instead of unified avail in dpkg/ )
>
> pkgstatus contains incorrect information!  and it codes states "1 3 3 4"
> while using wide text for everything but that.
>

The developer explains (vaguely) why there is not a one-to-one
corelation between dpkg status, aptitude pkgstates, and apt
extended_states:[1]

>> Currently, aptitude stores the held status of packages in some
>> internal database. I am guessing this may be
>> /var/lib/aptitude/pkgstates. Would it not be best if it behaved like
>> apt-get, ie. reading information from /var/lib/dpkg/status?
>
>   No, it wouldn't.  dselect's states are not in general equivalent to
> aptitude's, although they're similar.

Not sure what that means?  Me either, initially.

Aptitude allows the user to mark package changes but leave them for
another session.  So, interactively you can mark several installs,
removals, etc. and then quit, when you start again those changes will
still be remembered and ready to perform.

This is what it tries to store in pkgstates, the user's "intended"
state for the package, not it's actual state.

Except for "hold" (which is a whole bag of fish), the actual, current
state of packages is kept in dpkg and apt files, just like other
programs use.


> My main concern is the these "states" for aptitude are private data -
> excluding other software - and covering up why things are wrong.  (takeover
> issues)
>
> Lastly, an end user (me) can make install errors by using aptitude, dpkg,
> apt-get, dselect not realizing that aptitude uses privatized unshared
> current system disk status that isn't what dpkg uses (and how would you know
> if it's not in a status file to see?)
>

As above, most of pkgstates is actually private to aptitude.  Some of
it is duplicated for convenience, however, aptitude does take measures
to keep in sync. with dpkg/apt when it is started.  Admitedly, this
process fails quite often.

For example, removing a package with apt-get can lead to aptitude
trying to reinstall that package.  Note that aptitude is aware that
the package has been removed, it just mistakenly believes the user has
requested it be installed again.


> There's a way to get aptitude states maybe by relying on dump software.
>  Though relying on anyone keeping dumpers efficient and up to date simply
> isn't a great idea.
>

I don't think it would be useful for an other program to grok
pkgstates to determine if something is installed, etc.  Please use the
normal dpkg and apt means for that.

In theory, the only unique information in pkgstates is whether the
user has pending actions marked in aptitude.


Any problem in this situation is due entirely to aptitude's unique
requirements.  IMO the current dpkg and apt status files are quite
adequate for those systems.

Please be aware that it is my next priority to resolve the issues in this area.


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=137771#23


Regards


-- 
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/CAN3veReMaYNHWsBfuLO9brNuQ56xoR1uTPkddg=y5lzvzev...@mail.gmail.com

Re: debian-multimedia.org considered harmful

2012-03-18 Thread Thomas Goirand 
On 03/18/2012 09:50 PM, Chris Knadle wrote:
> Some public discussion with the repository maintainer about this might be 
> warranted.  Such would be worhwhile even if the outcome is not what is 
> desired, because at least then there will be a public record of where d-m.o 
> and d.o stand.
>   
debian-devel@lists.debian.org is a public mailing list. He's free to
join the list and contribute to this thread!

Thomas


-- 
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/4f661a01.90...@debian.org

Re: Important information regarding upcoming dpkg 1.16.2 upload

2012-03-18 Thread Jonathan Wiltshire 
On Sun, Mar 18, 2012 at 10:16:06AM -0500, John D. Hendrickson and Sara Darnell 
wrote:
> Hi,  I like dselect, dpkg, and aptitude.  I have a request.  aptitude should 
> import and export
> 
>   /var/lib/dpkg/status
> 
> At least when asked.  Right now aptitude takes awkwardly and but doesn't give 
> back.

I don't see the relevance of your message to this thread. You should file a
wishlist bug for this kind of request, or start a new thread on -dpkg only.
Either way please avoid cross-posting to -devel for no reason.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits


-- 
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/20120318183138.gb16...@lupin.home.powdarrmonkey.net

Re: debian-multimedia.org considered harmful

2012-03-18 Thread Chris Knadle 
On Sunday, March 18, 2012 13:23:13, Thomas Goirand wrote:
> On 03/18/2012 09:50 PM, Chris Knadle wrote:
> > Some public discussion with the repository maintainer about this might be
> > warranted.  Such would be worhwhile even if the outcome is not what is
> > desired, because at least then there will be a public record of where
> > d-m.o and d.o stand.
> 
> debian-devel@lists.debian.org is a public mailing list. He's free to
> join the list and contribute to this thread!

Rediculous.

d-m.o has a public mailing list to discuss issues concerning the repo.

What you're suggesting is that someone should to go tell Christian that 
there's this two-week old thread on debian-devel called "d-m.o considered 
harmful" and he's supposed to jump into that, where he can expect to enter a 
hostile enviornment*.  I really doubt that's going to occur.

* [I'm not saying [debian-devel] is hostile, just that it should be expected 
that it would be in this speicific instance given the subject of the thread.]

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
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/201203181648.24558.chris.kna...@coredump.us

Re: debian-multimedia.org considered harmful

2012-03-18 Thread Jonas Smedegaard 
On 12-03-18 at 04:48pm, Chris Knadle wrote:
> On Sunday, March 18, 2012 13:23:13, Thomas Goirand wrote:
> > On 03/18/2012 09:50 PM, Chris Knadle wrote:
> > > Some public discussion with the repository maintainer about this 
> > > might be warranted.  Such would be worhwhile even if the outcome 
> > > is not what is desired, because at least then there will be a 
> > > public record of where d-m.o and d.o stand.
> > 
> > debian-devel@lists.debian.org is a public mailing list. He's free to 
> > join the list and contribute to this thread!
> 
> Rediculous.
> 
> d-m.o has a public mailing list to discuss issues concerning the repo.

Feel free to discuss your issues with that non-Debian repository at 
their own mailinglist.  No need to inform us that you intend to do so.

Have a nice day.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: debian-multimedia.org considered harmful

2012-03-18 Thread Chris Knadle 
On Sunday, March 18, 2012 17:13:55, Jonas Smedegaard wrote:
> On 12-03-18 at 04:48pm, Chris Knadle wrote:
> > On Sunday, March 18, 2012 13:23:13, Thomas Goirand wrote:
> > > On 03/18/2012 09:50 PM, Chris Knadle wrote:
> > > > Some public discussion with the repository maintainer about this
> > > > might be warranted.  Such would be worhwhile even if the outcome
> > > > is not what is desired, because at least then there will be a
> > > > public record of where d-m.o and d.o stand.
> > > 
> > > debian-devel@lists.debian.org is a public mailing list. He's free to
> > > join the list and contribute to this thread!
> > 
> > Rediculous.
> > 
> > d-m.o has a public mailing list to discuss issues concerning the repo.
> 
> Feel free to discuss your issues with that non-Debian repository at
> their own mailinglist.  No need to inform us that you intend to do so.
> 
> Have a nice day.
> 
>  - Jonas

Standard geek rudeness: cut someone's email down to where the meaning is 
misconstrued, then reply.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
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/201203181745.54566.chris.kna...@coredump.us

Re: debian-multimedia.org considered harmful

2012-03-18 Thread Andres Mejia 
On Sun, Mar 18, 2012 at 5:45 PM, Chris Knadle  wrote:
> On Sunday, March 18, 2012 17:13:55, Jonas Smedegaard wrote:
>> On 12-03-18 at 04:48pm, Chris Knadle wrote:
>> > On Sunday, March 18, 2012 13:23:13, Thomas Goirand wrote:
>> > > On 03/18/2012 09:50 PM, Chris Knadle wrote:
>> > > > Some public discussion with the repository maintainer about this
>> > > > might be warranted.  Such would be worhwhile even if the outcome
>> > > > is not what is desired, because at least then there will be a
>> > > > public record of where d-m.o and d.o stand.
>> > >
>> > > debian-devel@lists.debian.org is a public mailing list. He's free to
>> > > join the list and contribute to this thread!
>> >
>> > Rediculous.
>> >
>> > d-m.o has a public mailing list to discuss issues concerning the repo.
>>
>> Feel free to discuss your issues with that non-Debian repository at
>> their own mailinglist.  No need to inform us that you intend to do so.
>>
>> Have a nice day.
>>
>>  - Jonas
>
> Standard geek rudeness: cut someone's email down to where the meaning is
> misconstrued, then reply.
>
>  -- Chris
>
> --
> Chris Knadle
> chris.kna...@coredump.us
>
>
> --
> 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/201203181745.54566.chris.kna...@coredump.us
>

Note that Christian Marillat is a Debian Developer. He should be
subscribed to this list.

-- 
~ Andres


--
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/capm41npsuhyb1oj5_2+xfjx8gey+qeetvzptzhymca28kzp...@mail.gmail.com

Re: debian-multimedia.org considered harmful

2012-03-18 Thread Russ Allbery 
Andres Mejia  writes:

> Note that Christian Marillat is a Debian Developer. He should be
> subscribed to this list.

There is no requirement that a Debian Developer be subscribed to
debian-devel, only debian-devel-announce.

If I were Christian and saw a thread in debian-devel, even assuming I was
reading it, with a subject header of "X considered harmful," where X is
something that I put a lot of time and energy into, and I was feeling wise
that day and made the right decision on how to invest my time, I would add
a filter rule sending the whole thread to /dev/null and go on with my
life.  If I were feeling foolish, I'd engage instead, but I'd probably
just waste my time and energy.

If someone wanted to do something productive about this, it would look
more like following up on Zack's summary of what would make a useful
disclaimer for the front of debian-multimedia.org, combined with possibly
making a list of packages in d-m.o that are no longer useful because
they've been superseded by packages in Debian proper and which may be good
removal candidates from that archive.  And then bring that up with
Christian directly, and politely.  Some gratitude for taking a legal risk
for Debian users who want to have packages of multimedia software that
Debian cannot distribute directly would be nice too.

I realize that the folks working on multimedia packages in Debian are
probably fairly frustrated at this point by user confusion and misdirected
bug reports, but Christian isn't doing the work he's doing just to make
you angry or your lives difficult, and that work really does serve a
purpose, even if parts of it may be buggy.  It's possible to disagree
without being disagreeable.

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

thoughts on blocking and downgrade attacks agains secure APT

2012-03-18 Thread Christoph Anton Mitterer 
Hi.

I recently played with Nagios' check_apt script (more on that later) and
this brought my attention to the following issues.


As everyone knows, our packages/archives are in principle fully secured
("secure APT")... via signed Release files and hashsums on the other
files.

I personally have still several open questions, one whether this is
really securely used by all clients, e.g.:
- Is APT (apt-get) using it in all places, i.e. not just apt-get
upgrade/install/update but also source?
- When verification fails for some reason, are the respective files
in /var/log/apt removed and are any previous files removed before an
update?
- Do the clients further down (especially aptitude, but also all the
others) use it in all places? E.g. I though "aptitude download" was an
aptitude specific thing... does it verify the packages downloaded?
- Do the clients further down handle all security related errors by APT
correctly?
- Can I use all these commands (e.g. apt-get update) safely in
scripting, e.g. will $? != 0, if just a single "small" problem arises in
apt-get update (like a completely missing repo).


Well, this may all work and it's just me who is uncertain, ... but it
seems to me the following is really still open:



Generally an attacker could use blocking and downgrade attacks (two
distinct things):


I) Blocking attacks:
He could prevent some files or all files from one or several given
repositories from being downloaded at all (or correctly).

If they're incorrectly downgraded, I hope/assume, that APT already
removes them immediately.
But even then (at least) two attack vector may be left (which is
basically the same as when blocking whole repositories):

1) The may not recognise that updates (i.e. security updates) are
already available.
This is similar to the "downgrade attack vector" I'll discuss below, so
see there for more.

2) Given that Debian has the wonderful and powerful APT preferences
system (with priorities to packages, etc.) it might be possible to trick
a system into choosing the "wrong" packages, as some repos are missing.


Especially attack vector (2) may sound quite obscure, but sometimes the
complex and very unlikely ways are the best (no one expects them).


I'm not sure whether the above attacks are "still" possible... the
question is basically, do all clients (APT, aptitude, etc.) handle
missing repositories as an error?
And I really mean error,... IIRC APT and aptitude both generate warnings
if a repos or some files are missing, but who's reading this (especially
when something is scripted)?
Rather they should stop service and continue only when command line
options are specified or some interactive input has been made, that this
and that specific missing repository should be ignored.



II) Downgrade attacks:
Similar to the attack above (I/1), an attacker might present the client
(APT, aptitude, etc.) old Release/Packages/etc. files.
Of course he cannot forge them (as long as he hasn't the OpenPGP key)
but by presenting an old set, he can already hide the fact that security
updates are available by either users, or some automatic scripting.

Now as far as I can see, the necessary information to avoid this would
be already in the Release files:
Date: Sun, 18 Mar 2012 20:19:08 UTC
Valid-Until: Sun, 25 Mar 2012 20:19:08 UTC
(btw: The range seems quite long to me.)

But it seems to me that this is not yet used by the clients, is it?
Generally I'd say, that (from a security point of view) really ALL
clients (APT and all ifs tools, aptitude, etc.) should stop working if a
single repository is out of date.
There may be little exceptions:
- of course the update command may succeed
- command line options and that like may allow users to ignore outdated
repos.

This sounds of course quite harsh, but IMHO it's required if one want's
to be really secure.
Even for tools that just list some status (e.g. apt-cache) old data may
be a security problem, as we can never know by which way the output is
processed by users.



In principle I'd be willing to open bugs for the above but given that
the impact is quite big and quite a lot is affected and I may not yet
even see the whole picture,... I thought it would be better to first
have a discussion with the experts on d-d.



Thanks for you input,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: thoughts on blocking and downgrade attacks agains secure APT

2012-03-18 Thread Christoph Anton Mitterer 
(sorry for the double posting,.. my MUA crashed in between)


One addition immediately which is however not directly related to the
discussion.

I stumbled across those issues when I spent some thoughts on the
check_apt test from Nagios.

I wanted a fully secure way to be notified when updates are in place
(but not having them automatically installed).


As you can imagine now, the issues described above apply to check_apt,
too, and an attacker could trick me into not recognising available
updates.


I've opened a Nagios bug #300
(http://tracker.nagios.org/view.php?id=300) asking for improvements.
I describe the general issue there, but I have so far no details on how
it should securely "access" APT to gather the necessary information.



Which Debian secure APT experts could I ask for help with this? :)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: debian-multimedia.org considered harmful

2012-03-18 Thread Romain Beauxis 
2012/3/18 Thomas Goirand :
> On 03/18/2012 08:53 AM, Romain Beauxis wrote:
>> It's a cliche comparison but still, CSS decryption is the knife and
>> DMCA is the murder; the fact that murder is illegal does not imply
>> that knives are.
>>
> Well, the whole concept of DMCA is to make knives illegal!
> Please read a bit more about it before making such wrong statement here.

That was a cliche, indeed. The main point remains: does using
libdvdcss, for instance, for watching a DVD using a multimedia player
installed in millions of other computers qualify as an "circumvention
of technological barriers for using a digital good in certain ways
which the rightsholders do not wish to allow."? Rightsholders
certainly wish to allow DVDs owners to watch them privately...

As I was reading recently, it's always good to remember that law is a
liberal art degree, not an engineering degree :-)

I think this is probably enough OT from me on this thread, sorry for
the digression..
Romain


-- 
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/CABWZ6OS6Ldyac3BHw1KcW0Q8e26mJrwvNRuv+AHx=64cO=v...@mail.gmail.com