Re: debian and UDEV

[Matt Zimmerman]

On Wed, May 17, 2006 at 12:19:35AM +0200, Goswin von Brederlow wrote:
> Matt Zimmerman <[EMAIL PROTECTED]> writes:
> 
> > You don't need to wait for a particular event to be finished processing;
> > instead you should wait for the resource you actually need to become
> > available, e.g. a device node.
> 
> And how do you detect the resource not becoming available?

With a timeout.

> Say I add a fsck script that runs before the final device node is
> created for any disk that gets added. That could take way longer than
> even the 3 minute timeout of the udevsettle.

Why (and, for that matter, how) would you want to try to operate on the
device before the device node is created?  This seems rather contrived.

> > It would be useful to add a simple utility for this to debianutils or
> > similar so that it doesn't need to be reimplemented in so many places.
> 
> I don't see any way to make this utility without having a race
> condition as it is. udev has no concept of "this rule is finished"
> afaik.

It may be possible to check that all pending udev events have completed.

-- 
 - mdz


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

Re: Creation of custom "configured" packages?

[Marc Haber]

On Tue, 16 May 2006 15:09:37 +0200, "cobaco (aka Bart Cornelis)"
<[EMAIL PROTECTED]> wrote:
>How so? As an admin you can always comment out any conf.d file completely
>if you don't want what is in there. After which dpkg will come with the 
>usual prompt at package upgrade about the conf-file being changed allowing 
>you to keep it that way without any effort. 

Aren't we talking about delivering local configuration to a system
with an independent package? That package cannot comment out a conf.d
file that comes with the original package.

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

Re: I want to modify the gnome panel deb package

[Roberto C. Sanchez]

Indraveni wrote:
> Hi,
> 
>  we are working for a  distro which is using debian pacakges. By default
> the gnome panel is having no colour. I want to change the look and feel
> of the panel, Applications menu backgroud color, Window title background
> color..,etc. Just to make it look diferent with diffrent colors. I dont
> want to go with a new theme.
> 
> can any one please tell me where this panel background colors I can
> change... I searched the gnome-panel pacakge, where there are some files
> called panel-applet-enums.c etc, where the PANEL-BACKGROUND id defined
> as NO BACKGROUND color. Is i the place where I need to modify??? If so
> how can I do it { I mean syntax of it }
> 
> HELP PLEASE.
> 

I notice that you have asked lots of questions on the debian-user and
debian-devel lists.  Not that there is anything wrong with that, but you
may wany to consider hiring a Debian consultant [0] to help the process
go smoother.

-Roberto

[0] http://www.debian.org/consultants/

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


signature.asc
Description: OpenPGP digital signature

Re: Mass bug filing: failure to use invoke-rc.d when required

[Lionel Elie Mamane]

On Wed, May 17, 2006 at 12:53:39AM +0300, Lars Wirzenius wrote:
> ti, 2006-05-16 kello 09:53 +0200, Bas Zoetekouw kirjoitti:
>> Lars wrote:

 The usage is mendantory (aka a must clause) but the bugs are not
 RC?  This does not fit.

>>> It violates policy, but not in a way enumerated on
>>> http://release.debian.org/etch_rc_policy.txt, which means that it isn't
>>> release critical, unless I've misunderstood something.

>> AFAIK, vilolating policy always waarent a serious bug:

>> | serious
>> |is a severe violation of Debian policy (roughly, it violates a
>> |"must" or "required" directive), or, in the package maintainer's
>> |opinion, makes the package unsuitable for release.

>> [http://www.debian.org/Bugs/Developer#severities]

> This is not what Steve Langasek tells me (or else I'm seriously
> misunderstanding). The etch_rc_policy.txt document is what documents
> what is release critical.

Doesn't that mean the bug is severity serious, but should be tagged
"etch-ignore"? That's what we did with sarge, if I remember well?

-- 
Lionel


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

Re: gnome 2 gnucash into unstable

[Henning Glawe]

On Tue, May 16, 2006 at 12:12:30PM -0700, Thomas Bushnell BSG wrote:
> Frank Küster <[EMAIL PROTECTED]> writes:
> 
> > /usr/sbin/pbuilder update --override-config --configfile /etc/pbuilderrc.sid
> 
> Ok, this gets me a good sid chroot.  But I can't build with it.  When
> I try to build, using, say, pbuilder build gnucash_1.9.6-3.dsc, I get
> seemingly normal pbuilder output, lots of Considering; Trying
> messages, then the apt run to install them, which reports:
> 
> WARNING: The following packages cannot be authenticated!
> 
> and then apt doesn't run, and instead prints:
> 
> E: There are problems and -y was used without --force-yes
> 
> Then I gut "Trying to fix apt error" and the same thing happens,
> ending with:
> 
> E: There are problems and -y was used without --force-yes
> E: Unrecoverable error installing build-dependencies.
> E: pbuilder-satisfydepends failed.
> 
> Presumably the problem is that the packages cannot be authenticated.
> Presumably that's because the key inside the chroot is the old 2005
> one?  How do I fix that?

login into the pbuilder chroot using:
pbuilder login --save-after-login

ensure that gpg is installed in the chroot (it may be missing when upgrading
from sarge to sid...):
apt-get install --allow-unauthenticated gnupg

and add the key manually to apt:
gpg --keyserver pgpkeys.mit.edu --recv-key 2D230C5F
gpg -a --export 2D230C5F | apt-key add -


-- 
c u
henning


signature.asc
Description: Digital signature

Re: debian and UDEV

[Marco d'Itri]

On May 17, Matt Zimmerman <[EMAIL PROTECTED]> wrote:

> It may be possible to check that all pending udev events have completed.
It is possible to check the status of individual events by looking at the
queue, but it's not obvious why people would want to do this instead of
using RUN rules.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

The EDOS project: request for comments on a Debian Query Language

[Berke Durak]

Dear Debian users and workers,

The EDOS project (http://www.edos-project.org/) is a research project funded by
the European Union and focusing on fundamental aspects of free software
processes such as distribution, quality assurance and dependency management.

As the WP2 (Dependencies Management) team, we have developed a set of tools for
organizing, displaying, measuring and checking metadata information.

We need your feedback and ideas for defining a query language that would be
useful to maintainers, power-users and FOSS researchers alike.  Two of our
tools, "ara" and "history", have query languages that can be used as starting
points.

I would also like to point out that the EDOS team is organizing two tracks at
the RMLL 2006 Conference, Nancy, France:
  - EDOS track on Large Software Systems Management, July 6 2006:
http://www.rmll.info/conf_124
  - First EDOS workshop, July 7 2006:
http://www.rmll.info/theme_60

I will now give some background information on what we have done and what we
want to do.

We have a complete, correct and efficient tool that takes a "Packages" metadata
file and finds packages that are not installable by solving the associated
satisfiability problem.  This checker is available as a command-line tool
temporarily named "debcheck", which can be checked out from the EDOS SVN
server.  (There is also a RPM version.)  This tool doesn't simply check
first-order dependencies or conflicts, but encodes the total installability
constraints as a boolean formula which is then solved very quickly (one minute
to check the whole unstable).  It is in the process of being packaged, see

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365087

Tools for handling the Debian metadata with its evolution in time are now being
developed.  More precisely, we are downloading every day files such as
Packages.{gz,bz2} for all distributions and components and filling a database
with these data.  We also find, for every day and every distribution (testing,
unstable, stable) uninstallable packages using the algorithms of debcheck.  

This database :
  - Can be browsed on-line using a web interface, "anla".
See http://brion.inria.fr/anla/ but please note that the database is not very
up-to-date.  (Due to performance issues which will be addressed by the
upcoming rewrite.)
  - Can be queried using the "history" tool in a particular query language. 
For a brief description of that language (dubbed DQL), please see

  http://gallium.inria.fr/~durak/dql.html

These are from pages 104 to 109 of the EDOS deliverable 2.2 available at

  
http://www.edos-project.org/xwiki/bin/download/Main/Deliverables/edos-wp2d2.pdf

We want to write clean, re-engineered and integrated versions of these tools,
using a query language tailored to fit the needs of package maintainers, but
also researchers.  As researchers, we may want to do interesting things like
displaying the evolution of the number of non-installable packages, or finding
packages that some criteria, such as packages tagged as libraries that have no
packages that depend on them except packages from the same source.  We think
this would also be very useful to developers and power users.  For instance, we
would like to be able to type something like

  bash$ dql 'packages(stable) \ (depends(libc6) | tagged("lib"))'

to get a list of packages in the current stable archive that do not depend
directly or indirectly on libc6 and that are tagged "lib".  (This is just an
example to give a taste of things we want to do.)

Please reply to this thread using your ideas, comments and suggestions.
Ideally, we would have a command-line version that would respond instantly.
Here are a few ideas to start with.

Language and environment

1) Date manipulation functions.
2) Ability to load multiple historical data sources.
3) Multiple views and environments.

Data I/O

4) Ability to load and save environments.
5) Ability to load installation status.
6) Ability to load non-historical, unparsed data sources.
7) Ability to load installation status data

Statistics
--
9) Ability to easily do statistical measurements:
 a) Count number of things.
 b) Plot the evolution of some quantity with respect to time.
 c) Plot a graph of the number of packages added per day.
 d) Compute the average number of versions per package.
 e) Display the 10 units with most versions.
10) Find packages most depended upon

Complex searches

11) Ability to do complex searches:
 a) Search packages by description, regular expressions
 b) Search packages by tags
 c) Search packages by dependency
12) Search packages by contained files

Installability
--
13) Ability to "simulate" installations and upgrades
14) Find non-conflicting packages that have a common file :
   - with the same MD5
   - with different MD5s
15) Find uninstallable packages
16) Find uninstallable packages that fail

Re: Mass bug filing: failure to use invoke-rc.d when required

[Adam D. Barratt]

On Wednesday, May 17, 2006 7:59 AM, Lionel Elie Mamane <[EMAIL PROTECTED]>
wrote:
> On Wed, May 17, 2006 at 12:53:39AM +0300, Lars Wirzenius wrote:
>> ti, 2006-05-16 kello 09:53 +0200, Bas Zoetekouw kirjoitti:
[...]
>>> AFAIK, vilolating policy always waarent a serious bug:
[...]
>> This is not what Steve Langasek tells me (or else I'm seriously
>> misunderstanding). The etch_rc_policy.txt document is what documents
>> what is release critical.
>
> Doesn't that mean the bug is severity serious, but should be tagged
> "etch-ignore"? That's what we did with sarge, if I remember well?

No. The "foo-ignore" tags mean "this issue /is/ RC, but we're ignoring it
for the release of foo". Any bug tagged "etch-ignore" is by definition RC
the moment etch is released.

The exact definition of what qualifies for a severity of serious or above
(i.e. RC) are the purview of the Release team, as noted at
http://www.debian.org/Bugs/Developer#severities. A "severe violation of
Debian policy" is one which violates the current release policy, as laid out
by the Release team.

Cheers,

Adam


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

Re: multiarch status update

[Goswin von Brederlow]

Ron Johnson <[EMAIL PROTECTED]> writes:

> On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote:
>> "Olaf van der Spek" <[EMAIL PROTECTED]> writes:
>> 
>> > On 5/15/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> >> Bill Allombert <[EMAIL PROTECTED]> writes:
>> >>
>> >> > On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote:
>> >> >> I so far haven't seen any compelling arguments for multiarchifying the
>> >> >> whole archive including all of */bin.
>> >> >
>> >> > Personnally I would favor a new files hierachy that allow every
>> >> > arch-dependend files to be co-installable. Even if we are not able to
>> >> > take full advantage of it at once, it seems saner and more 
>> >> > forward-looking
>> >> > than only allowing libraries to be co-installable. This might also make
>> >> > easier to have this new scheme adopted by other OS.
>> >> >
>> >> > Cheers,
>> >>
>> >> But would make it totaly incompatible with existing systems.
>> >
>> > Why do you think there's no compatible solution?
>> 
>> Because basicaly all sources assume binaries go to /bin. You
>> want to break that. Also a lot of scripts expect binaries to be where
>> they are and anything setting PATH too.
>> 
>> We have thought hard about this over the last 2 years and nobody has
>> come up with a non disruptive way
>
> Is "non-disruptive" that vital?  What about "minimally disruptive",
> or "a little disruptive"?
>
> As a user, I'd put up with some one-time disruption if that means
> that I could have 64-bit coolness (after all, I'm a home user) while
> keeping 32-bit goodness like OOo2 & w32codecs. 

But why would you want to put up with it at all? Do you realy need
both a 32bit OOo and a 64bit OOo? Or both 64bit and 32bit video
players? Isn't one of the two enough?

By only alowing one arch per binary we have a totaly non disruptive
way of implementing multiarch that is fully upwards and downwards
compatible with etch (and only needs a ld.so.conf entry in
sarge). Allowing multiple archs for one binary just solves a problem
that we don't have and adds a ton of complexity not to mention changes
to packages. We are talking 100 vs. 16000.

MfG
Goswin


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

Re: multiarch status update

[Wouter Verhelst]

On Wed, May 17, 2006 at 12:01:08AM +0200, Goswin von Brederlow wrote:
> "Olaf van der Spek" <[EMAIL PROTECTED]> writes:
> > Why do you think there's no compatible solution?
> 
> Because basicaly all sources assume binaries go to /bin. You
> want to break that. Also a lot of scripts expect binaries to be where
> they are and anything setting PATH too.

Have you considered employing the alternatives system (or something
similar)? What I'm suggesting is that you'd basically get a /bin64 and a
/bin32, where binaries install themselves in /bin by default but divert
to the /binXX when both versions are installed, and use symlinks in an
update-alternatives way to select the default.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: reportbug defaults

[Florian Weimer]

* Marco d'Itri:

> On May 16, "Roberto C. Sanchez" <[EMAIL PROTECTED]> wrote:
>
>> Except that many ISPs now block outbound port 25 (at least on
>> consumer-level service), except for what is relayed through their mail
>> servers.

> Agreed. It's not reasonable to expect that port 25 connections from
> large consumer ISPs will work.  reportbug should use port 587
> instead (see RFC2476 for details).

It would be a gross violation of the letter (okay, just a SHOULD) or
the spirit of RFC 2476 (or its successor, whose number I forgot).

In order to make it really work. you'd have to submit it over 80/TCP
anyway. 8->


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

Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]

[Goswin von Brederlow]

Ron Johnson <[EMAIL PROTECTED]> writes:

> On Wed, 2006-05-17 at 00:24 +0200, Goswin von Brederlow wrote:
>> Ron Johnson <[EMAIL PROTECTED]> writes:
>> 
>> > On Tue, 2006-05-16 at 08:44 -0700, Don Armstrong wrote:
>> >> On Tue, 16 May 2006, Ron Johnson wrote:
>> >> > On the "home desktop" reportbug uses Python's smtp library to send
>> >> > email directly to the ISP's smtp server. And that's a good thing,
>> >> > because, for a long time, reportbug did not have that feature, and
>> >> > people who don't know how to configure MTAs were not able to send
>> >> > bug reports.
>> >> 
>> >> reportbug sends mail to wherever it is configured; the default setup
>> >> should be to send mail to bugs.debian.org, not the ISP's smtp server,
>> >> since that can't be known in advance. [I don't know if this is the
>> >> default now, but it should be the default.]
>> >
>> > bugs.d.o is the *destination*, not the journey.
>> 
>> Isn't the default that reprotbug asks on the first run whether to use
>> the local fetchmail / ISPs smpt or send to bugs.d.o now?
>
> OK, I'm confused.
>
> Isn't the question "How does the report gets from "the computer"
> to bugs.d.o?"?
>
> sendmail or smtp library, right?

If you run "reportbug" without arguments it asks you questions on the
first run:

| Do you have a "mail transport agent" (MTA) like Exim, Postfix or SSMTP
| configured on this computer? [Y|n|q|?]? n
| Please enter the name of your SMTP host. Usually it's called something like
| "mail.example.org" or "smtp.example.org". Just press ENTER if you don't have
| one or don't know.
| > 

which results in "smtphost bugs.debian.org" in the conffile. Maybe the
default to the MTA question could be "N" instead.

> When I first installed rb, it failed to work, because it wanted
> to use sendmail, and the only way my PC sent mail to the outside
> world was using my MUA pointing to smtp..net (because exim
> was set up for local delivery only).
>
> Later on, I tried again, and found that they had added (or made
> it more clear in "reportbug --configure") the ability to use the
> user's ISP to transport the email.

Yes, that is a new feature.

MfG
Goswin


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

Re: debian and UDEV

[Goswin von Brederlow]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> On Wed, May 17, 2006 at 12:19:35AM +0200, Goswin von Brederlow wrote:
>> Matt Zimmerman <[EMAIL PROTECTED]> writes:
>> 
>> > You don't need to wait for a particular event to be finished processing;
>> > instead you should wait for the resource you actually need to become
>> > available, e.g. a device node.
>> 
>> And how do you detect the resource not becoming available?
>
> With a timeout.

== race condition.

>> Say I add a fsck script that runs before the final device node is
>> created for any disk that gets added. That could take way longer than
>> even the 3 minute timeout of the udevsettle.
>
> Why (and, for that matter, how) would you want to try to operate on the
> device before the device node is created?  This seems rather contrived.

You create a temporary one in a private dir or one with private
permissions.

The later would probably screw your detection software totaly as the
device appears but remains inaccessible till fsck is done.

>> > It would be useful to add a simple utility for this to debianutils or
>> > similar so that it doesn't need to be reimplemented in so many places.
>> 
>> I don't see any way to make this utility without having a race
>> condition as it is. udev has no concept of "this rule is finished"
>> afaik.
>
> It may be possible to check that all pending udev events have completed.

Which is still stupid not to have in the kernel API as feedback from
the event manager and have insmod optionaly block.

MfG
Goswin


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

Re: Creation of custom "configured" packages?

[Goswin von Brederlow]

Marc Haber <[EMAIL PROTECTED]> writes:

> On Tue, 16 May 2006 15:09:37 +0200, "cobaco (aka Bart Cornelis)"
> <[EMAIL PROTECTED]> wrote:
>>How so? As an admin you can always comment out any conf.d file completely
>>if you don't want what is in there. After which dpkg will come with the 
>>usual prompt at package upgrade about the conf-file being changed allowing 
>>you to keep it that way without any effort. 
>
> Aren't we talking about delivering local configuration to a system
> with an independent package? That package cannot comment out a conf.d
> file that comes with the original package.
>
> Greetings
> Marc

Is it allowed to divert conffiles?

MfG
Goswin


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

Re: I want to modify the gnome panel deb package

[Arjan Oosting]

Op wo, 17-05-2006 te 06:31 +0100, schreef Indraveni:
> Hi,
> 
>  we are working for a  distro which is using debian pacakges. By
> default the gnome panel is having no colour. I want to change the look
> and feel of the panel, Applications menu backgroud color, Window title
> background color..,etc. Just to make it look diferent with diffrent
> colors. I dont want to go with a new theme. 
> 
> can any one please tell me where this panel background colors I can
> change... I searched the gnome-panel pacakge, where there are some
> files called panel-applet-enums.c etc, where the PANEL-BACKGROUND id
> defined as NO BACKGROUND color. Is i the place where I need to
> modify??? If so how can I do it { I mean syntax of it } 
Take a look at gnome-theme-manager.

Greetings Arjan


signature.asc
Description: Dit berichtdeel is digitaal ondertekend

Re: Sun Java available from non-free

[Michael Meskes]

On Wed, May 17, 2006 at 08:20:14AM +0200, Jeroen van Wolffelaar wrote:
> Official packages of Sun Java are now available from the non-free
> section of Debian unstable, thanks to Sun releasing[11 Java under a new
> license: the Operating System Distributor License for Java (DLJ)[2][3].
> This license, while still non-free, allows the Sun Java Runtime
> Environment (JRE) or Java Development Kit (JDK) to be distributed by
> Debian, with our own packaging.

Could someone please explain to me why paragraph 2(f) does not pose a
problem? I couldn't find ANY discussion about the license on Debian legal
which surprises me a little bit, but then maybe I just missed the
relevant parts of the license. Anyway, as a non-lawyer I'm surprised
that we seem to accept that we have to "defend and indemnify Sun".

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: Moving GFDL documentation to non-free

[Wouter Verhelst]

On Wed, May 17, 2006 at 10:20:17AM +0800, Dan Jacobson wrote:
> Hi. I'm just a lowly user with a bandwidth problem.
> Certainly was a shock to get back from town to find the documentation
> gone from the debs I brought back.
> However, I am to make one last trip to town so it's my one shot chance
> to download the new additional debs where that documentation now lies.
> I need to know the names of those additional packages though, so I can
> tell dpkg --set-selections.

The usual package name is -doc. Just to be sure,
you may want to check the changelogs of the packages with missing docs,
however.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email

[Adam Borowski]

On Tue, May 16, 2006 at 07:58:52PM -0500, Ron Johnson wrote:
> > > On Tue, 2006-05-16 at 19:21 +0200, Henning Makholm wrote:
> > >> The point is that they could if the wanted to. And if they did, it
> > >> would work for _all_ programs, not just particular perl scripts that
> > >> happen to use some obscure perl module to send mails.
> 
> T-bird, Evo, Outlook, etc don't figure it out either.  They ask 
> the user, "What's the name of your ISP's outgoing mail server?"
> 
> Here's the relevant question from "reportbug --config"
> 
> Do you have a "mail transport agent" (MTA) like Exim, Postfix
> or SSMTP configured on this computer? [y|N|q|?]? 

Except, this is _doubling_ a question that was already asked somewhere else,
ie, a bug.  The UNIX way of configuring the mail is setting up a binary that
knows how to deliver it as "/usr/sbin/sendmail"; it doesn't matter whether
that binary will do the work itself, run ssh -T foo sendmail, or toss the
mail to a smarthost.  The Debian way of configuring stuff is asking the
admin the relevant questions only once, and keeping the config in a shared
place.

Having to configure every single program that happens to send out mail adds
more work to the user.  You also are guaranteed that every such program will
ask the questions in a different way, which adds extra confusion.

Cheers and schtuff,
-- 
1KB // Rule #6: If violence wasn't your last resort,
// you failed to resort to enough of it.
//   - The Seven Habits of Highly Effective Pirates


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

Re: I want to modify the gnome panel deb package

[Brian M. Carlson]

On Wed, 2006-05-17 at 02:44 -0400, Roberto C. Sanchez wrote:
> Indraveni wrote:
[snip]
> I notice that you have asked lots of questions on the debian-user and
> debian-devel lists.  Not that there is anything wrong with that, but you
> may wany to consider hiring a Debian consultant [0] to help the process
> go smoother.

However, it *is* a problem to violate the Code of Conduct[0].  To quote
the page:

  Never send your messages in HTML; use plain text instead.

A bug has already been filed[1]; I will be following up to it
encouraging its adoption.

[0] http://www.debian.org/MailingLists/#codeofconduct
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=353846


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

Bug#367631: ITP: thunar-media-tags-plugin -- Media tags plugin for the Thunar file manager.

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers <[EMAIL PROTECTED]>


* Package name: thunar-media-tags-plugin
  Version : 0.1.0
  Upstream Author : Jannis Pohlmann <[EMAIL PROTECTED]>
* URL : 
http://thunar.xfce.org/pwiki/projects/thunar-media-tags-plugin
* License : GPLv2 or later
  Programming Lang: C
  Description : Media tags plugin for the Thunar file manager.

This plugin allows tags editing and tags-based file renaming from inside the 
Thunar file manager.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-rc2
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Bug#367628: ITP: thunar-archive-plugin -- Archive plugin for the Thunar file manager.

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers <[EMAIL PROTECTED]>


* Package name: thunar-archive-plugin
  Version : 0.1.2
  Upstream Author : Benedikt Meurer <[EMAIL PROTECTED]>
* URL : 
http://foo-projects.org/~benny/projects/thunar-archive-plugin/
* License : GPLv2 or later
  Programming Lang: C
  Description : Archive plugin for the Thunar file manager.

This plugin allows to extract and create archive from inside the Thunar file
manager. At the moment it uses file-roller but will use xarchiver in the
future.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-rc2
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Creation of custom "configured" packages?

[cobaco (aka Bart Cornelis)]

On Wednesday 17 May 2006 08:33, Marc Haber wrote:
> On Tue, 16 May 2006 15:09:37 +0200, "cobaco (aka Bart Cornelis)"
>
> <[EMAIL PROTECTED]> wrote:
> >How so? As an admin you can always comment out any conf.d file
> > completely if you don't want what is in there. After which dpkg will
> > come with the usual prompt at package upgrade about the conf-file being
> > changed allowing you to keep it that way without any effort.
>
> Aren't we talking about delivering local configuration to a system
> with an independent package? That package cannot comment out a conf.d
> file that comes with the original package.

right, got you now:

there's 2 viewpoints:
- that of the local admin (the 'delete configuration' you mentioned made me
  assume you were talking about the local admin viewpoint, my bad)
  -> can always override everything wether it's monolitic or modular
  -> modular is better if the admin just want to set some additional options
 (you don't need to mess with the conffile in the package, so you don't
  get the "conffile has changed" prompt on upgrade because you set a
  couple of extra options)
- that of another package
  -> modular _at_least allows to add bits of configuration which is usefull
 for:
 - plugins offering extra functionality
 - things building on another service (e.g. web-applications)
 - configuration packages of CDD's
   -> _might_ allow overriding of configuration *IF* the config system 
  always uses either the first or last value encountered for a
  particular setting and looks at things in some non-random order.
  Which I'm guessing should moslty be the case, and is at least
  sometimes be the case (e.g. the modularized system-wide on-login
  scripts for those shells that have them)

=> /etc/.d directory might not be perfect, but it's good sight
   better then monolitic configuration files
-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)


pgpOUZPsogPyr.pgp
Description: PGP signature

Re: Sun Java available from non-free

[Florian Weimer]

* Jeroen van Wolffelaar:

> Official packages of Sun Java are now available from the non-free
> section of Debian unstable, thanks to Sun releasing[11 Java under a new
> license: the Operating System Distributor License for Java (DLJ)[2][3].

This license requires that we remove all other Java implementations
from the mirror network:

| (c) you do not combine, configure or distribute the Software to run
| in conjunction with any additional software that implements the same
| or similar functionality or APIs as the Software

Furthermore, the indemnification clause is not restricted to Java, so
now we basically shield Sun for all kinds of claims related to their
use of Debian:

| you agree to defend and indemnify Sun and its licensors from and
| against any damages [...]  that arises or results from [...] the use
| or distribution of your Operating System

Why do you think this is acceptable for non-free?


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

Re: Sun Java available from non-free

[Brian M. Carlson]

[For -legal people, the license is attached.]

On Wed, 2006-05-17 at 11:01 +0200, Michael Meskes wrote:
> On Wed, May 17, 2006 at 08:20:14AM +0200, Jeroen van Wolffelaar wrote:
> > Official packages of Sun Java are now available from the non-free
> > section of Debian unstable, thanks to Sun releasing[11 Java under a new
> > license: the Operating System Distributor License for Java (DLJ)[2][3].
> > This license, while still non-free, allows the Sun Java Runtime
> > Environment (JRE) or Java Development Kit (JDK) to be distributed by
> > Debian, with our own packaging.
> 
> Could someone please explain to me why paragraph 2(f) does not pose a
> problem? I couldn't find ANY discussion about the license on Debian legal
> which surprises me a little bit, but then maybe I just missed the
> relevant parts of the license. Anyway, as a non-lawyer I'm surprised
> that we seem to accept that we have to "defend and indemnify Sun".

Also, section 4 poses a major issue.  If, for any reason, the Linux
kernel doesn't do something that Java requires, then we are obligated to
either fix it or inform everyone who has acquired Java from us.

Section 10 is not possible with our infrastructure.  The ftp-master
scripts merely remove the package from the tag database, not the archive
(at least until there are no dependencies), and not from all of our
mirrors.

Section 2(b) prohibits allowing people to develop software with Java
that is to be run on another system.

Section 2(c) prohibits us from using the software in conjunction with C,
C++, Perl, Python, or *any reasonable Turing-complete programming
language*.

Section 12 requires that this software be in non-US/non-free.  It is
not, which is not only a violation of the license, but a violation of
United States law.

This conflicts with other project policies and exposes Debian/SPI to
major legal liabilities.  I think that this should be removed from the
archive as soon as possible, preferably before the next mirror pulse.
Operating System Distributor License for Java version 1.1

SUN MICROSYSTEMS, INC. ("SUN") IS WILLING TO LICENSE THE JAVA PLATFORM
STANDARD EDITION DEVELOPER KIT ("JDK" - THE "SOFTWARE") TO YOU ONLY
UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS
LICENSE AGREEMENT (THE "AGREEMENT").� PLEASE READ THE AGREEMENT
CAREFULLY.� BY INSTALLING, USING, OR DISTRIBUTING THIS SOFTWARE, YOU
ACCEPT ALL OF THE TERMS OF THE AGREEMENT.

1.  DEFINITIONS. "Software" means the code identified above in binary
form, any other machine readable materials including, but not
limited to, libraries, source files, header files, and data files),
any updates or error corrections provided by Sun, and any user
manuals, programming guides and other documentation provided to you
by Sun under this Agreement, and any subsequent versions that Sun
makes available to you hereunder.  "Operating System" means any
version of the Linux or OpenSolaris operating systems that manages
the hardware resources of a general purpose desktop or server
computer and shares these resources with various software programs
that run on top of it. "Programs" means Java technology applets and
applications intended to run on the Java Platform Standard Edition
(Java SE platform) platform on Java-enabled general purpose desktop
computers and servers.

2.  License Grant. Subject to the terms and conditions of this
Agreement, as well as the restrictions and exceptions set forth in
the Software README file, Sun grants you a non-exclusive,
non-transferable, royalty-free limited license to reproduce and use
the Software internally, complete and unmodified, for the sole
purposes of running Programs and designing, developing and testing
Programs.  Sun also grants you a non-exclusive, non-transferable,
royalty-free limited license to reproduce and distribute the
Software, directly or indirectly through your licensees,
distributors, resellers, or OEMs, electronically or in physical
form or pre-installed with your Operating System on a general
purpose desktop computer or server, provided that: (a) the Software
and any proprietary legends or notices are complete and unmodified;
(b) the Software is distributed with your Operating System, and
such distribution is solely for the purposes of running Programs
under the control of your Operating System and designing,
developing and testing Programs to be run under the control of your
Operating System; (c) you do not combine, configure or distribute
the Software to run in conjunction with any additional software
that implements the same or similar functionality or APIs as the
Software; (d) you do not remove or modify any included license
agreement or impede or prevent it from displaying and requiring
acceptance; (e) you only distribute the Software subject to this
license agreement; and (f) you agree to defend and indemn

Re: Sun Java available from non-free

[Thijs Kinkhorst]

On Wed, 2006-05-17 at 11:01 +0200, Michael Meskes wrote:
> Could someone please explain to me why paragraph 2(f) does not pose a
> problem? I couldn't find ANY discussion about the license on Debian legal
> which surprises me a little bit, but then maybe I just missed the
> relevant parts of the license. Anyway, as a non-lawyer I'm surprised
> that we seem to accept that we have to "defend and indemnify Sun".

Did you read the accompanying FAQ? Question 12 addresses your concern.
http://download.java.net/dlj/DLJ-FAQ-v1.1.txt


Thijs


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

Re: Mass bug filing: failure to use invoke-rc.d when required

[Brian M. Carlson]

On Wed, 2006-05-17 at 09:19 +0100, Adam D. Barratt wrote:
> On Wednesday, May 17, 2006 7:59 AM, Lionel Elie Mamane <[EMAIL PROTECTED]>
> wrote:
> > On Wed, May 17, 2006 at 12:53:39AM +0300, Lars Wirzenius wrote:
> >> ti, 2006-05-16 kello 09:53 +0200, Bas Zoetekouw kirjoitti:
> [...]
> >>> AFAIK, vilolating policy always waarent a serious bug:
> [...]
> >> This is not what Steve Langasek tells me (or else I'm seriously
> >> misunderstanding). The etch_rc_policy.txt document is what documents
> >> what is release critical.
> >
> > Doesn't that mean the bug is severity serious, but should be tagged
> > "etch-ignore"? That's what we did with sarge, if I remember well?
> 
> No. The "foo-ignore" tags mean "this issue /is/ RC, but we're ignoring it
> for the release of foo". Any bug tagged "etch-ignore" is by definition RC
> the moment etch is released.
> 
> The exact definition of what qualifies for a severity of serious or above
> (i.e. RC) are the purview of the Release team, as noted at
> http://www.debian.org/Bugs/Developer#severities. A "severe violation of
> Debian policy" is one which violates the current release policy, as laid out
> by the Release team.

Then when are we removing the debian-policy package from the archive?
But seriously, if violating Debian Policy has no consequences, then it
probably won't be followed.  As it stands now, Policy is useless because
the worst that can happen is an important bug, which can be safely
ignored almost forever.

As far as the etch_rc_policy.txt, there are at least 10 different issues
with that document that may be unintended, one of which is that as it
stands now, all perl-using packages *must* depend on perl-base, and all
python-using packages *must* depend on the package providing the
interpreter (/usr/bin/python is *not* an interpreter, merely a symlink),
such as python2.3, python2.4, or python2.5[0].

At least with debian-policy, any changes must actually be discussed and
viewed by several people, which increases the probability that this type
of error is found and corrected, hopefully before it even becomes
policy.

Finally, I would prefer if some tag existed that would indicate that a
bug is not a concern for the release but is still a major error in terms
of Debian Policy.  I understand that such tags *do* exist, and that they
are called "sid" and "experimental".  I also understand that these are
deprecated with BTS version tracking; however, since these tags have the
desired effect, and there are no other ones with equivalent effect, I
will use them for all of my current and future bugs.

[0] 5g of the the etch RC policy [sic][1]:
Scripts must include the appropriate #! line, and set executable.
The package providing the script must Depend: on the appropriate
package providing the interpreter.
[1] The text in [0] should say "be set executable" or "be executable"
or even "have been set executable", instead of "set executable".



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

Why not making /sbin/sendmail a mantadory component for mail operation?

[Henrique de Moraes Holschuh]

On Wed, 17 May 2006, Goswin von Brederlow wrote:
> which results in "smtphost bugs.debian.org" in the conffile. Maybe the
> default to the MTA question could be "N" instead.

An open outgoing port 25 is commonly blocked by default anywhere you have
non-incompetent network management, unless you are on the business of
selling full internet uplinks for server hosting, or you do business with
spammers.

Sometimes I feel we are abandoning the true spirit of an Unix system.  If
Debian made sure to always have a local MTA that is properly configured to
send email (and it can be a simple SMTP with no queue thing, too.  It can
work just as well and can be as safe as a full-blown MTA, the drawback is
that the user has to wait for the email to be delivered to a queueing MTA
before the sendmail command returns), everything could be made to just work.

What exactly is the problem with making a local MTA absolutely mandatory,
(as in anything that sends email either recommends or depends on
mail-transport-agent)?

Of course, at the same time we would have to make sure stuff like nbsmtp,
nullmailer, esmtp-run or ssmtp is trivially easy to install, and point our
users to those packages so that they know the possiblity exists. IMHO we
really ought to leverage d-i to bluntly ask the user if he wants a
full-blown MTA or just a SMTP relay (obviously by using easier terms, like a
"Advanced outgoing mail service" (i.e. exim) task, which if not selected,
gives you nullmailer or somesuch.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Sun Java available from non-free

[Michael Meskes]

On Wed, May 17, 2006 at 02:13:31PM +0200, Thijs Kinkhorst wrote:
> Did you read the accompanying FAQ? Question 12 addresses your concern.
> http://download.java.net/dlj/DLJ-FAQ-v1.1.txt

I did, but I wasn't sure if that FAQ has any legal meaning. I have
problems seeing that the FAQ answer fits with the license. To me the
license seems to give more options for Sun to make us idemnify them. 

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Re: multiarch status update

[Gabor Gombas]

On Tue, May 16, 2006 at 06:02:58PM +0200, Romain Beauxis wrote:

> Few things that I see:
> -- FUSE goes throught userland <-> kernel <-> Userland so it:
> ** May be an overhead for all /usr/bin calls.

Sure. Every feature has a price. In reality I expect the dentry cache
and the page cache takes care about the heavily used binaries. In any
case it will be still faster than NFS and people do use NFS for mounting
/usr.

> ** May be a potential security leak, like using LD_PRELOAD for a given user 
> and use a custom fuse library for this user, with *any* /usr/bin filesystem 
> you like

Only if you allow normal users over-mounting /usr/bin. I was only
talking about a system-wide mount.

> -- FUSE module is not loaded by default, and some server maintainer would 
> like 
> te reFUSE using it... :-)

mount --bind /usr/lib/$DEFAULT_ARCH/bin /usr/bin and you are done. The
FUSE solution is only needed if you want dynamic per-binary architecture
selection.

> -- Furthermore, what to do during bootstrap of the root file system? Because 
> this should also be needed for /bin, so again overhead, security and loading 
> at en early stage is not a solution for me...

mount --bind /bin-$DEFAULT_ARCH /bin during boot. Or simply state that
/bin and /sbin are not multiarched.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: multiarch status update

[Gabor Gombas]

On Wed, May 17, 2006 at 12:14:24AM +0200, Goswin von Brederlow wrote:

> Wait a second. How do you create the dir when the file already exists?

There was quite some talk on linux-kernel about
'every-file-is-a-directory' approaches when Reiserfs 4 was released.
Some said they'd like to see this feature in other file systems if only
someone got the nerve to design & implement the needed VFS extensions.

> Say I have /usr/bin/firefox/i486 and /usr/bin/firefox/x86_64. Which
> one should be the default? Where/how do I set the default?

This is just theory, but if you implement the
'every-file-is-a-directory' concept with extended attributes then
- /usr/bin/firefox is just a stub file containing a magic cookie
- the per-architecture binaries are stored as EAs
- there can be a 'default' EA pointing to the default architecture, so
  you can set the default separately for every binary
- a binfmt_misc helper should be created that intercepts the magic
  cookie in the stub file and loads the binary from the appropriate EA

This way running /usr/bin/firefox gives you the defalt arch, and
/usr/bin/firefox/$ARCH (or /usr/bin/[EMAIL PROTECTED] or whatever syntax you
define for accessing the EAs) gives you the binary for the specific arch.

> I never use flash so I want the x86_64 default. But userB always uses
> flash and wants i486. How do you set that up per user?

This problem already exists with alternatives regardless of multiarch.
The sysadmin sets up JDK-1.5 as default using the alternatives system
but userB always uses JDK-1.4. How do you set that up per user?

alias firefox=/usr/bin/firefox/i486 works just fine for userB.

> Multiarch (so far) does not allow the same path/file in 2 packages
> (with the exception of /usr/share/doc/ files)

Hmm. How do you want to handle one-arch-only binNMUs? binNMUs change
changelog.Debian.gz, so
- you can't upgrade just the architecture that was binNMUed without
  changelog.Debian.gz becoming invalid for the other arches
- there will be no new version for the other arches so you can't just
  wait till the versions are in sync

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: Sun Java available from non-free

[Kevin B. McCarty]

Hi Jeroen,

Jeroen van Wolffelaar wrote:

> Users requiring the complete functionality of Sun Java will find
> that the Java 5 JRE and JDK can be installed by adding the non-free
> component to their APT configuration. For now, this applies only to
> users of unstable/sid, but will the packages are expected to migrate
> into testing (etch) in the near future. This means that they most likely
> accompany the next release in etch's non-free section.

>From reference [3], question 20, there are circumstances under which Sun
could demand that we make either a non-trivial update to the Java
packages in a stable release, or else remove them within 90 days:

> 20. What if a problem comes up after I distribute the software?
> 
>   If Sun becomes aware of a compatibility problem with the JDK
>   software on your OS distribution and notifies you about it, then you
>   must fix the problem and offer a patch or new version to your
>   downstream users and distributors, or stop distributing the software
>   within 90 days of being notified. If you stop distributing the
>   software, you must also make reasonable attempts to notify your
>   users, and anyone who might have downloaded your OS
>   distribution. Once your downstream users are notified, they must
>   make the same choice (i.e. fix the problem or stop
>   using/distributing the software)

Is this a burden that FTP-masters are willing and able to take on?  Or
is the probability of this happening judged to be low enough that we
aren't worried about it?

> [1] http://www.sun.com/smi/Press/sunflash/2006-05/sunflash.20060516.4.xml
> [2] http://download.java.net/dlj/DLJ-v1.1.txt
> http://download.java.net/dlj/DLJ-v1.1.pdf
> [3] http://download.java.net/dlj/DLJ-FAQ-v1.1.txt
> http://download.java.net/dlj/DLJ-FAQ-v1.1.pdf

best regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544


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

Bug#367654: ITP: gavl -- Gmerlin Audio Video Library

[Free Ekanayaka]

Package: wnpp
Severity: wishlist
Owner: Free Ekanayaka <[EMAIL PROTECTED]>


* Package name: gavl
  Version : 0.2.4
  Upstream Author : Burkhard Plaum
* URL : http://gmerlin.sf.net
* License : GPL
  Description : Gmerlin Audio Video Library

 Gavl is short for Gmerlin Audio Video Library. It is a low level
 library, upon which multimedia APIs can be built. Gavl handles all
 the details of audio and video formats like colorspaces, samplerates,
 multichannel configurations etc. It provides standardized definitions
 for those formats as well as container structures for carrying Audio
 samples or Video frames.
 .
 In addition, it handles the sometimes ugly task to convert between
 all these formats as well as some elemtary operations (scaling, alpha
 blending etc).


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

Re: debian and UDEV

[Matt Zimmerman]

The rest of the Linux distribution world is using udev with the current
semantics and has not crumbled.  If you don't like the current semantics, I
understand, but that shouldn't stand in the way of its adoption.

-- 
 - mdz


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

Re: mdadm 2.4.1-1 ready for tests

[Simon Huggins]

On Wed, May 17, 2006 at 01:11:43AM -0500, martin f krafft wrote:
> Here's the changelog:

>  mdadm (2.4.1-1) experimental; urgency=low

>* The "I'll kill that maintainer... uh, wait, it's me" release. Sorry for
>  the delay, here's the long awaited new upstream release,
>  which closes: Bug#318230, Bug#321751, Bug#337903, Bug#352798, Bug#363592,
>Bug#356153, Bug#271033

I know this isn't the sort of feedback you want but these aren't all
"please ship the new version of mdadm" bugs and whilst they might well
be fixed by this version I thought consensus was to try to describe what
it was about this release that fixes these bugs.

-- 
--( "And what have they ever given us in return?")--
--( "The aqueduct?"  )--
Simon (  ) Nomis
 Htag.pl 0.0.22


signature.asc
Description: Digital signature

Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email

[Ron Johnson]

On Wed, 2006-05-17 at 11:35 +0200, Adam Borowski wrote:
> On Tue, May 16, 2006 at 07:58:52PM -0500, Ron Johnson wrote:
> > > > On Tue, 2006-05-16 at 19:21 +0200, Henning Makholm wrote:
[snip]
> Except, this is _doubling_ a question that was already asked somewhere else,
> ie, a bug.  The UNIX way of configuring the mail is setting up a binary that
> knows how to deliver it as "/usr/sbin/sendmail"; it doesn't matter whether
> that binary will do the work itself, run ssh -T foo sendmail, or toss the
> mail to a smarthost.  The Debian way of configuring stuff is asking the
> admin the relevant questions only once, and keeping the config in a shared
> place.
> 
> Having to configure every single program that happens to send out mail adds
> more work to the user.  You also are guaranteed that every such program will
> ask the questions in a different way, which adds extra confusion.

You're free to file a bug against every "Provides: mail-reader" app.

People (well, end-users), though, ever since Netscape 1.0 Composer
have been trained to enter their ISP's POP and SMTP server addresses,
and I don't think you're going to get the Evo, Sylpheed, T-bird,
etc developers to change their code.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA

"They laughed at Columbus, they laughed at Fulton, they laughed
at the Wright brothers. But they also laughed at Bozo the
Clown."
Carl Sagan


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

Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]

[Ron Johnson]

On Wed, 2006-05-17 at 10:41 +0200, Goswin von Brederlow wrote:
> Ron Johnson <[EMAIL PROTECTED]> writes:
> 
> > On Wed, 2006-05-17 at 00:24 +0200, Goswin von Brederlow wrote:
> >> Ron Johnson <[EMAIL PROTECTED]> writes:
> >> 
> >> > On Tue, 2006-05-16 at 08:44 -0700, Don Armstrong wrote:
> >> >> On Tue, 16 May 2006, Ron Johnson wrote:
> >> >> > On the "home desktop" reportbug uses Python's smtp library to send
> >> >> > email directly to the ISP's smtp server. And that's a good thing,
> >> >> > because, for a long time, reportbug did not have that feature, and
> >> >> > people who don't know how to configure MTAs were not able to send
> >> >> > bug reports.
> >> >> 
> >> >> reportbug sends mail to wherever it is configured; the default setup
> >> >> should be to send mail to bugs.debian.org, not the ISP's smtp server,
> >> >> since that can't be known in advance. [I don't know if this is the
> >> >> default now, but it should be the default.]
> >> >
> >> > bugs.d.o is the *destination*, not the journey.
> >> 
> >> Isn't the default that reprotbug asks on the first run whether to use
> >> the local fetchmail / ISPs smpt or send to bugs.d.o now?
> >
> > OK, I'm confused.
> >
> > Isn't the question "How does the report gets from "the computer"
> > to bugs.d.o?"?
> >
> > sendmail or smtp library, right?
> 
> If you run "reportbug" without arguments it asks you questions on the
> first run:
> 
> | Do you have a "mail transport agent" (MTA) like Exim, Postfix or SSMTP
> | configured on this computer? [Y|n|q|?]? n
> | Please enter the name of your SMTP host. Usually it's called something like
> | "mail.example.org" or "smtp.example.org". Just press ENTER if you don't have
> | one or don't know.
> | > 
> 
> which results in "smtphost bugs.debian.org" in the conffile. Maybe the
> default to the MTA question could be "N" instead.

Interesting.  b.d.o doesn't seem to be answering on port 25 though.

I ran this tiny python script and it just sits there:

>>> import smtplib
>>> server = smtplib.SMTP('bugs.debian.org')
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.3/smtplib.py", line 240, in __init__
(code, msg) = self.connect(host, port)
  File "/usr/lib/python2.3/smtplib.py", line 293, in connect
self.sock.connect(sa)
  File "", line 1, in connect
KeyboardInterrupt

> > When I first installed rb, it failed to work, because it wanted
> > to use sendmail, and the only way my PC sent mail to the outside
> > world was using my MUA pointing to smtp..net (because exim
> > was set up for local delivery only).
> >
> > Later on, I tried again, and found that they had added (or made
> > it more clear in "reportbug --configure") the ability to use the
> > user's ISP to transport the email.
> 
> Yes, that is a new feature.

And a darned useful one at that...

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA

"The mass of ignorant Negroes still breed carelessly and
disastrously, so that the increase among Negroes, even more than
the increase among whites, is from that portion of the population
least intelligent and fit, and least able to rear their children
properly."
W.E.B. DuBois (co-founder of the NAACP), 1932


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

Re: Sun Java available from non-free

[Emmanuel le Chevoir]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Florian Weimer a écrit :
> * Jeroen van Wolffelaar:
> 
>> Official packages of Sun Java are now available from the non-free
>> section of Debian unstable, thanks to Sun releasing[11 Java under a new
>> license: the Operating System Distributor License for Java (DLJ)[2][3].
> 
> This license requires that we remove all other Java implementations
> from the mirror network:

That's not what I read.
Quoting the FAQ[1]:

 #|  8.  Does this license prevent me shipping any alternative
 #|  technologies in my OS distribution?
 #|
 #|  The DLJ does not restrict you from shipping any other
 #|  technologies you choose to include in your distribution.
 #|  However, you can't use pieces of the JDK configured in
 #|  conjunction with any alternative technologies to create
 #|  hybrid implementations, or mingle the code from the JDK
 #|  with non-JDK components of any kind so that they run
 #|  together. It is of course perfectly OK to ship programs
 #|  or libraries that use the JDK. Because this question has
 #|  caused confusion in the past, we want to make this absolutely
 #|  clear: except for these limitations on combining technologies,
 #|  there is nothing in the DLJ intended to prevent you from shipping
 #|  alternative technologies with your OS distribution.

[1] http://download.java.net/dlj/DLJ-FAQ-v1.1.txt


- --
Emmanuel le Chevoir
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEa0wt4i/Wdr6T0t4RAqtaAJ9s8pc2wBqYxC+eAyswrhlWgtt3eQCfSyGs
MXdSRxjl4uEbfHtKhPkCDww=
=1pqS
-END PGP SIGNATURE-


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

Re: gnome 2 gnucash into unstable

[Ondrej Sury]

On Tue, 2006-05-16 at 12:12 -0700, Thomas Bushnell BSG wrote:
> WARNING: The following packages cannot be authenticated!
> 
> and then apt doesn't run, and instead prints:
> 
> E: There are problems and -y was used without --force-yes

pbuilder login --save-after-login
[...]
# apt-get install gnupg

or add:

EXTRAPACKAGES="gnupg"

to your pbuilderrc when creating pbuilder for first time...

O.
-- 
Ondrej Sury <[EMAIL PROTECTED]>


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

Re: multiarch status update

[Ron Johnson]

On Wed, 2006-05-17 at 10:34 +0200, Goswin von Brederlow wrote:
> Ron Johnson <[EMAIL PROTECTED]> writes:
> 
> > On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote:
> >> "Olaf van der Spek" <[EMAIL PROTECTED]> writes:
> >> 
> >> > On 5/15/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> >> >> Bill Allombert <[EMAIL PROTECTED]> writes:
> >> >>
> >> >> > On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote:
[snip]
> >> 
> >> We have thought hard about this over the last 2 years and nobody has
> >> come up with a non disruptive way
> >
> > Is "non-disruptive" that vital?  What about "minimally disruptive",
> > or "a little disruptive"?
> >
> > As a user, I'd put up with some one-time disruption if that means
> > that I could have 64-bit coolness (after all, I'm a home user) while
> > keeping 32-bit goodness like OOo2 & w32codecs. 
> 
> But why would you want to put up with it at all? Do you realy need
> both a 32bit OOo and a 64bit OOo? Or both 64bit and 32bit video
> players? Isn't one of the two enough?

No.

$JOE_USER will, ISTM, only need to (want to)run a few 32-bit apps
on his otherwise 64-bit system.

OOo2 (until it becomes 64-bit clean)
w32codecs (and thus every app that depends on it)
Wine
other OSS apps that aren't 64-bit clean
binary apps:
Adobe Acrobat Reader
Macromedia Flash player
Crossover Office
Sun Java ?

And this implies apps like Firefox, since many of these apps have
plugins for FF & Mozilla, and the libraries they depend on.  (Yes,
closed source is impure, blah, blah, worship RMS, but the sad fact
is that they are *useful*.)

> By only alowing one arch per binary we have a totaly non disruptive
> way of implementing multiarch that is fully upwards and downwards
> compatible with etch (and only needs a ld.so.conf entry in
> sarge). Allowing multiple archs for one binary just solves a problem
> that we don't have and adds a ton of complexity not to mention changes
> to packages. We are talking 100 vs. 16000.

It looks like we agree on this.  The scope should be narrow and
"downhill", i.e., ia32 apps on x86_64, PPC32 apps on PPC64, SPARC32
on SPARC64 systems.  No uphill, and no complications like all the
different MIPS permutations running together.

Am I arguing for bi-arch?  If so, so be it.  KISS.

Still, in a universe as large as Debian, some group of users must
have a reason to need to/want to be able to install side-by-side
architectures of the same packages.

However, there's no need to make this totally transparent.

People who want to run 32-bit apps in a 64-bit world would have
to EXPLICITLY run a script that changes that process' personality
(using linux32) and then runs /usr/bin/${SOMEAPP}_32.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA

The enemy thinks and plans and strategizes, too.


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

Re: Sun Java available from non-free

[Carlos Correia]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Florian Weimer escreveu:
| * Jeroen van Wolffelaar:
|
|
|>Official packages of Sun Java are now available from the non-free
|>section of Debian unstable, thanks to Sun releasing[11 Java under a new
|>license: the Operating System Distributor License for Java (DLJ)[2][3].
|
|
| This license requires that we remove all other Java implementations
| from the mirror network:
|

No, it doesn't!

~From DLJ FAQ (http://download.java.net/dlj/DLJ-FAQ-v1.1.txt):

8.  Does this license prevent me shipping any alternative technologies
~in my OS distribution?

~  The DLJ does not restrict you from shipping any other technologies
~  you choose to include in your distribution. However, you can't use
~  pieces of the JDK configured in conjunction with any alternative
~  technologies to create hybrid implementations, or mingle the code
~  from the JDK with non-JDK components of any kind so that they run
~  together. It is of course perfectly OK to ship programs or libraries
~  that use the JDK. Because this question has caused confusion in the
~  past, we want to make this absolutely clear: except for these
~  limitations on combining technologies, there is nothing in the DLJ
~  intended to prevent you from shipping alternative technologies with
~  your OS distribution.

Regards,

Carlos
- --
MEMÓRIA PERSISTENTE, Lda.
Tel.: 219 291 591 - GSM:  967 511 762
e-mail: [EMAIL PROTECTED] - URL: http://www.m16e.com
Jabber: [EMAIL PROTECTED] - MSN: [EMAIL PROTECTED] - ICQ: 257488263
GnuPG: wwwkeys.eu.pgp.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEa2CS90uzwjA1SJURAlVVAJ0RlX3ujx1SjqhbOFTLfMvNEzMsWACfUEPI
RD+c8PmvPKaI5sAG4ED/10s=
=pRAB
-END PGP SIGNATURE-


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

Re: Why not making /sbin/sendmail a mantadory component for mail operation?

[Lionel Elie Mamane]

On Wed, May 17, 2006 at 09:42:42AM -0300, Henrique de Moraes Holschuh wrote:

> An open outgoing port 25 is commonly blocked by default anywhere you
> have non-incompetent network management, unless you are on the
> business of selling full internet uplinks for server hosting, or you
> do business with spammers.

Or unless you want ... customers.

-- 
Lionel


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

Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]

[Henning Makholm]

Scripsit Don Armstrong <[EMAIL PROTECTED]>

>> What about modifying it to work through something like an http POST?

> I'm personally not too terribly interested in implementing an HTTP
> access method for the BTS, because it makes it more easy for bug
> submissions to be sent from people who can not be accessed via e-mail.

How does sending directly to from reportbug to an ISP's smarthost
validate the user's email address better than sending directly from
reportbug to a HTTP POST somewhere?

It is not necessary that there is anywhere any HTML form that refers
to the posting URL; only reportbug would need to know it.

-- 
Henning Makholm "This imposes the restriction on any
  procedure statement that the kind and type
 of each actual parameter be compatible with the
   kind and type of the corresponding formal parameter."


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

Re: Why not making /sbin/sendmail a mantadory component for mail operation?

[Henrique de Moraes Holschuh]

On Wed, 17 May 2006, Lionel Elie Mamane wrote:
> On Wed, May 17, 2006 at 09:42:42AM -0300, Henrique de Moraes Holschuh wrote:
> 
> > An open outgoing port 25 is commonly blocked by default anywhere you
> > have non-incompetent network management, unless you are on the
> > business of selling full internet uplinks for server hosting, or you
> > do business with spammers.
> 
> Or unless you want ... customers.

, it will be blacklisted in no time due to the virus-ridden,
bot-ridden computers of your "customers".  So, it will remain unreliable.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: multiarch status update

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Wed, May 17, 2006 at 12:01:08AM +0200, Goswin von Brederlow wrote:
>> "Olaf van der Spek" <[EMAIL PROTECTED]> writes:
>> > Why do you think there's no compatible solution?
>> 
>> Because basicaly all sources assume binaries go to /bin. You
>> want to break that. Also a lot of scripts expect binaries to be where
>> they are and anything setting PATH too.
>
> Have you considered employing the alternatives system (or something
> similar)? What I'm suggesting is that you'd basically get a /bin64 and a
> /bin32, where binaries install themselves in /bin by default but divert
> to the /binXX when both versions are installed, and use symlinks in an
> update-alternatives way to select the default.

Each package that deems it neccessary can choose to do so. I imagine
the count to be near 0. Certainly nothing dpkg should handle
automagicaly for all debs.

MfG
Goswin


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

Re: multiarch status update

[Goswin von Brederlow]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> On Wed, May 17, 2006 at 12:14:24AM +0200, Goswin von Brederlow wrote:
>> Multiarch (so far) does not allow the same path/file in 2 packages
>> (with the exception of /usr/share/doc/ files)
>
> Hmm. How do you want to handle one-arch-only binNMUs? binNMUs change
> changelog.Debian.gz, so
> - you can't upgrade just the architecture that was binNMUed without
>   changelog.Debian.gz becoming invalid for the other arches
> - there will be no new version for the other arches so you can't just
>   wait till the versions are in sync
>
> Gabor

Afaik nothing in the package may depend on the existance of
/usr/share/doc so it doesn't realy matter (to the package) what
happens there. Handling the special overlap for changelog and readme
files there can be implemented in several ways:

1) Don't care about it
   Just assume --force-overwrite for anything in /usr/share/doc.
   Whatever gets installed last sticks and removal of packages can
   lead to files getting removed and so on.

   A slightly better thing would be to always keep the highest version
   as that should include prior versions info as well.

2) Automaticaly divert
   This has the small problem of not workign with 3 or more archs
   since dpkg only handles one diversion.

3) Automaticaly append the arch tripplet to the files

4) Don't allow it
   Split those files off into architecture:all packages. For packages
   that have one anyway this is probably the sanest thing. But
   creating a package with just the changelog, copyright and readme is
   kind of insane.

MfG
Goswin


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

Section of -dev packages

[Jörg Sommer]

Hi,

I ever thought development packages classified by $NAME-dev belong to the
Section devel or libdevel, but

% apt-cache search -n .\*-dev\$ | sed 's/ -.*//' | \
xargs apt-cache show | grep \^Section: | sort -u
Section: admin
Section: comm
Section: contrib/libdevel
Section: devel
Section: doc
Section: games
Section: gnome
Section: graphics
Section: interpreters
Section: kde
Section: libdevel
Section: libs
Section: mail
Section: math
Section: misc
Section: net
Section: non-free/devel
Section: non-free/doc
Section: non-free/net
Section: oldlibs
Section: perl
Section: python
Section: science
Section: sound
Section: text
Section: utils
Section: web
Section: x11

I am really suprised. Which packages belong to devel/libdevel?

Bye, Jörg.
-- 
Nutze die Talente, die du hast. Die Wälder wären sehr still,
wenn nur die begabtesten Vögel sängen.(Henry van Dyke)


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

Re: debian and UDEV

[Goswin von Brederlow]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> On Wed, May 17, 2006 at 10:44:21AM +0200, Goswin von Brederlow wrote:
>
>> Which is still stupid not to have in the kernel API as feedback from
>> the event manager and have insmod optionaly block.
>
> For that to work you should make device discovery synchronous everywhere
> in the kernel. That would be a big change, and then people would start
> complaining that the boot process suddenly takes 10-20 minutes instead
> of 10-20 seconds (because the kernel now has to wait for time-out for
> non-existing devices which you never noticed before thanks to the
> asynchronous discovery).

What timeout? With feedback you would know exactly when it is done and
wouldn't have to poll.

If you mean the timeout of the actual device drivers themself then
that is what pre udev kernels have always done and I think kernels
still do anway. If you load a scsi driver module it will block to scan
the scsi bus, generate the hotplug events and only then go
asynchronous.

If you mean running the udev scripts then yes, that would get
linearised instead of running in parallel to other module loads. But
then again mknod should not take that long.

> And what do you want to do for hot-pluggable devices like USB or SATA?
> Should insmod block forever if there is a free SATA port just in case
> the sysadmin wants to plug in a disk later? And if not, why is this case
> different from insmod returning immediately and reporting all plugged-in
> disks later? You _must_ be able to handle the "disk-plugged-in-later"
> case and that should "just work" for the already-plugged-in disks as
> well...

Scan the USB bus, find all devices on it, run all udev scripts for
them, return.

Just like the kernel always did prior to udev.

> I think it is pointless to bitch about udev without a clean proposal how
> should Debian handle hotplug events (including cases like when the
> device containing the root file system is literally plugged in _after_
> the kernel/initrd has been loaded).

That is a different matter. That never ever worked by itself and udev
doesn't change anything there. But for already plugged in devices the
device node was always ready when the insmod was done. Even with
devfs. With udev the device node appears at some random time after
insmod has returned.

For all cases where you load a module to activate a certain device
(disk for initrd, mouse for X, ...) this is a serious step back.

> Gabor

MfG
Goswin


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

Re: multiarch status update

[Darren Salt]

I demand that Gabor Gombas may or may not have written...

[snip]
> How do you want to handle one-arch-only binNMUs? binNMUs change
> changelog.Debian.gz, so
> - you can't upgrade just the architecture that was binNMUed without
>   changelog.Debian.gz becoming invalid for the other arches
[snip]

I think that this'll just have to be accepted - ignore the binNMU versioning
when comparing versions for co-installation, but take the docs from the
highest-numbered binNMU.

I don't know how a binNMU for one architecture followed by a binNMU for
another is handled, but it seems reasonable to me that the newer one will
have to include the changelog from the older one and, therefore, must have a
higher version number. Otherwise, which binNMU changelog entry you get is a
matter of chance, and entries may even be lost in later uploads.

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Output less CO2 => avoid boiling weather. TIME IS RUNNING OUT *FAST*.

When you go out to buy, don't show your silver.


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

Re: Sun Java available from non-free

[Bill Allombert]

On Wed, May 17, 2006 at 08:20:14AM +0200, Jeroen van Wolffelaar wrote:
> Official packages of Sun Java are now available from the non-free
> section of Debian unstable, thanks to Sun releasing[11 Java under a new
> license: the Operating System Distributor License for Java (DLJ)[2][3].
> This license, while still non-free, allows the Sun Java Runtime
> Environment (JRE) or Java Development Kit (JDK) to be distributed by
> Debian, with our own packaging.

I don't think it is appropriate to use debian-devel-announce to
advertise non-free softwares epecially when we are striving to provide 
a free alternative.

> During the past weeks there has been close collaboration between Sun
> engineers and Debian and Ubuntu developers. The quick turnaround for
> creating those packages was made possible by reusing existing packaging
> code from the Blackdown Java Linux project, contributed by Matthias
> Klose and Jürgen Kreileder. Thanks to both of them for this.

Any pointer to that discussion ? I could not find any on debian-legal.
 From reading the license I don't see how we can distribute it without
some binding promise from SUN they will not sue us no matter what.
Does the discussion included that ?

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpFhXKolNpj3.pgp
Description: PGP signature

Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]

[Michal Čihař]

On Wed, 17 May 2006 10:44:19 -0500
Ron Johnson <[EMAIL PROTECTED]> wrote:

> Interesting.  b.d.o doesn't seem to be answering on port 25 though.

Doesn't your provider block port 25?

$ telnet bugs.debian.org 25
Trying 140.211.166.43...
Connected to bugs.debian.org.
Escape character is '^]'.
220 spohr.debian.org ESMTP Exim 4.50 Wed, 17 May 2006 13:45:34 -0700
EHLO me
250-spohr.debian.org Hello nat-10.jups.junix.cz [86.49.49.74]
250-SIZE 62914560
250-PIPELINING
250 HELP
QUIT
221 spohr.debian.org closing connection
Connection closed by foreign host.


-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: Why not making /sbin/sendmail a mantadory component for mail operation?

[Ron Johnson]

On Wed, 2006-05-17 at 09:42 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 17 May 2006, Goswin von Brederlow wrote:
[snip]
> What exactly is the problem with making a local MTA absolutely mandatory,
> (as in anything that sends email either recommends or depends on
> mail-transport-agent)?
> 
> Of course, at the same time we would have to make sure stuff like nbsmtp,
> nullmailer, esmtp-run or ssmtp is trivially easy to install, and point our
> users to those packages so that they know the possiblity exists. IMHO we
> really ought to leverage d-i to bluntly ask the user if he wants a
> full-blown MTA or just a SMTP relay (obviously by using easier terms, like a
> "Advanced outgoing mail service" (i.e. exim) task, which if not selected,
> gives you nullmailer or somesuch.

The d-i people, or the m-t-a people?  That's where you define what
kind of service you want.

You'd not just have to bluntly ask, but firmly recommend that they
install the m-t-a as a relay host.  (Once a desktop user like me
figures out what a relayhost is, and that it won't hose me or make
my system an open spam relay, it's easy to do.  Now all my outgoing
mail is relayed to smtp.myisp.net via postfix, but for 4 years of
using Linux, and 6 years of OS/2 & NT4 before that, it was the
traditional "put smtp.myisp.net in my MUA".)

Ignorance, fear of becoming an open relay and years of learning 
will have to be overcome before Most Users will config Debian to
use a relayhost.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA

"Talk is cheap -- except when Congress does it."
Cullen Hightower


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

Re: Sun Java available from non-free

[Francesco Poli]

On Wed, 17 May 2006 11:01:26 +0200 Michael Meskes wrote:

> On Wed, May 17, 2006 at 08:20:14AM +0200, Jeroen van Wolffelaar wrote:
> > Official packages of Sun Java are now available from the non-free
> > section of Debian unstable, thanks to Sun releasing[11 Java under a
> > new license: the Operating System Distributor License for Java
> > (DLJ)[2][3]. This license, while still non-free, allows the Sun Java
> > Runtime Environment (JRE) or Java Development Kit (JDK) to be
> > distributed by Debian, with our own packaging.
> 
[...]
> I couldn't find ANY discussion about the license on Debian
> legal which surprises me a little bit,
[...]

How could a package under such a license be distributed by the Debian
Project without even a little check with debian-legal?
Does anyone think that this license is (trivially) suitable for
non-free?
I certainly don't.


I'm really disappointed: what's the use of spending time on
debian-legal, when the Project seems to ignore us?


-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpcsKlWN3hSX.pgp
Description: PGP signature

Re: Sun Java available from non-free

[Francesco Poli]

On Wed, 17 May 2006 12:02:34 + Brian M. Carlson wrote:

> [For -legal people, the license is attached.]

Thanks.

[...]
> Also, section 4 poses a major issue.  If, for any reason, the Linux
> kernel doesn't do something that Java requires, then we are obligated
> to either fix it or inform everyone who has acquired Java from us.

Indeed, it seems we are in chains: whenever Sun decides that we should
do it, we are bound to modifying the Debian System to satisfy their
requirements and/or notifying the world about the issue.

> 
> Section 10 is not possible with our infrastructure.  The ftp-master
> scripts merely remove the package from the tag database, not the
> archive (at least until there are no dependencies), and not from all
> of our mirrors.

It seems that you're right.

> 
> Section 2(b) prohibits allowing people to develop software with Java
> that is to be run on another system.

Yes, a fairly strong restriction, but not something that gets violated
by the Debian Project.
Users of non-free are anyway warned and advised to read licenses in
order to evaluate (on a case-by-case basis) whether they can (and want
to) use a package. 

> 
> Section 2(c) prohibits us from using the software in conjunction with
> C, C++, Perl, Python, or *any reasonable Turing-complete programming
> language*.

Worse: it seems that it prohibits combining, configuring and
*distributing* the Software to run in conjunction with any similar
compiler.
Hence it seems that the Debian Project is already violating the license,
by distributing all the other DKs (such as GCC, Python, Perl, ...)!

> 
> Section 12 requires that this software be in non-US/non-free.  It is
> not, which is not only a violation of the license, but a violation of
> United States law.

I'm not sure:

| 12. Export Regulations. All Software and technical data delivered
|under this Agreement are subject to US export control laws and may
|be subject to export or import regulations in other countries.

This seems to be a statement about facts.
It may be that US export control laws don't restrict the export of the
Software: if this is the case, stating that it's subject to export
cotrol laws does not seem to hurt.
Or am I wrong?

|You acknowledge that you have the responsibility to obtain such
|licenses to export, re-export, or import as may be required after
|delivery to you.

Please note the "may be required": if no export license is required,
then I'm fine (even when I acknowledged that I have the responsibility
of obtaining any required export license).
Is that right?

> 
> This conflicts with other project policies and exposes Debian/SPI to
> major legal liabilities.  I think that this should be removed from the
> archive as soon as possible, preferably before the next mirror pulse.

I agree. 


-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpeQWkYlSh4r.pgp
Description: PGP signature

Re: Why not making /sbin/sendmail a mantadory component for mail operation?

[Goswin von Brederlow]

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

> On Wed, 17 May 2006, Goswin von Brederlow wrote:
>> which results in "smtphost bugs.debian.org" in the conffile. Maybe the
>> default to the MTA question could be "N" instead.
>
> An open outgoing port 25 is commonly blocked by default anywhere you have
> non-incompetent network management, unless you are on the business of
> selling full internet uplinks for server hosting, or you do business with
> spammers.

You mean connection from random user ports to destination port 25?

If you are at a place where that is the case then you should have an
IT team or admin that will tell you what smtp host to use or even
install your system.

> Sometimes I feel we are abandoning the true spirit of an Unix system.  If
> Debian made sure to always have a local MTA that is properly configured to
> send email (and it can be a simple SMTP with no queue thing, too.  It can
> work just as well and can be as safe as a full-blown MTA, the drawback is
> that the user has to wait for the email to be delivered to a queueing MTA
> before the sendmail command returns), everything could be made to just work.

And how would that be any simpler than setting an smtp server for
reportbug? Setting up a fully usable MTA is more difficult than having
reportbug connect directly to bugs.d.o.

> What exactly is the problem with making a local MTA absolutely mandatory,
> (as in anything that sends email either recommends or depends on
> mail-transport-agent)?
>
> Of course, at the same time we would have to make sure stuff like nbsmtp,
> nullmailer, esmtp-run or ssmtp is trivially easy to install, and point our
> users to those packages so that they know the possiblity exists. IMHO we
> really ought to leverage d-i to bluntly ask the user if he wants a
> full-blown MTA or just a SMTP relay (obviously by using easier terms, like a
> "Advanced outgoing mail service" (i.e. exim) task, which if not selected,
> gives you nullmailer or somesuch.

That would mean another service on the system that might get
compromised or misused. I'm perfectly fine with having mail only
delivered internaly or not at all for my chroots but I still want to
be able to report bugs with the right dependency informations. If you
force the use of an MTA then I would have to save the bug reports to a
file and mail them manualy from outside the chroot every time I get a
bug. Much less usable.

MfG
Goswin


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

Re: Why not making /sbin/sendmail a mantadory component for mail operation?

[Roberto C. Sanchez]

Lionel Elie Mamane wrote:
> On Wed, May 17, 2006 at 09:42:42AM -0300, Henrique de Moraes Holschuh wrote:
> 
> 
>>An open outgoing port 25 is commonly blocked by default anywhere you
>>have non-incompetent network management, unless you are on the
>>business of selling full internet uplinks for server hosting, or you
>>do business with spammers.
> 
> 
> Or unless you want ... customers.
> 

Except that most customers don't know what a port is, nor much less care
that any are blocked (unless it prevents them from playing everquest or
chatting).  Most people don't run their own mail servers and can easily
be convinced by the ISP to use a mail client like Lookout, which is
pointed at the ISP's outbound mail server.  Personally, I think it is a
responsible thing for mass market ISPs to do.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


signature.asc
Description: OpenPGP digital signature

Re: debian and UDEV

[Gabor Gombas]

On Wed, May 17, 2006 at 10:44:21AM +0200, Goswin von Brederlow wrote:

> Which is still stupid not to have in the kernel API as feedback from
> the event manager and have insmod optionaly block.

For that to work you should make device discovery synchronous everywhere
in the kernel. That would be a big change, and then people would start
complaining that the boot process suddenly takes 10-20 minutes instead
of 10-20 seconds (because the kernel now has to wait for time-out for
non-existing devices which you never noticed before thanks to the
asynchronous discovery).

And what do you want to do for hot-pluggable devices like USB or SATA?
Should insmod block forever if there is a free SATA port just in case
the sysadmin wants to plug in a disk later? And if not, why is this case
different from insmod returning immediately and reporting all plugged-in
disks later? You _must_ be able to handle the "disk-plugged-in-later"
case and that should "just work" for the already-plugged-in disks as
well...

I think it is pointless to bitch about udev without a clean proposal how
should Debian handle hotplug events (including cases like when the
device containing the root file system is literally plugged in _after_
the kernel/initrd has been loaded).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: Creation of custom "configured" packages?

[Marc Haber]

On Wed, 17 May 2006 12:33:21 +0200, "cobaco (aka Bart Cornelis)"
<[EMAIL PROTECTED]> wrote:
>=> /etc/.d directory might not be perfect, but it's good sight
>   better then monolitic configuration files

Agreement on 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

Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email

[Marc Haber]

On Wed, 17 May 2006 11:35:44 +0200, Adam Borowski
<[EMAIL PROTECTED]> wrote:
>Except, this is _doubling_ a question that was already asked somewhere else,
>ie, a bug.  The UNIX way of configuring the mail is setting up a binary that
>knows how to deliver it as "/usr/sbin/sendmail"; it doesn't matter whether
>that binary will do the work itself, run ssh -T foo sendmail, or toss the
>mail to a smarthost.  The Debian way of configuring stuff is asking the
>admin the relevant questions only once, and keeping the config in a shared
>place.

A bug reporting tool, which might be used to report a fatal bug in the
default MTA, is a possible exception.

Why this tool is written in python, an interpreted language with a run
time system the size of Buckingham Palace, The White House and the
Kreml combined, is an entirely different story.

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

Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email

[Tim Cutts]

On 15 May 2006, at 1:13 pm, Henning Makholm wrote:


Scripsit Russ Allbery <[EMAIL PROTECTED]>


More generally, Perl modules to send mail rather than using
/usr/sbin/sendmail are often useful with web applications (or other
applications that need security isolation) that are running in a  
chroot.

To use /usr/sbin/sendmail in the chroot requires setting up a chroot
maildrop, and while there are packages to do this, using some  
module that

can speak SMTP is often the path of least resistance.


Why not just install some software that can speak SMTP as the chroot's
/usr/bin/sendmail? E.g. nullmailer.


I've done that on some systems.  Works quite well.

Tim


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

Re: multiarch status update

[Goswin von Brederlow]

Ron Johnson <[EMAIL PROTECTED]> writes:

> On Wed, 2006-05-17 at 10:34 +0200, Goswin von Brederlow wrote:
>> Ron Johnson <[EMAIL PROTECTED]> writes:
>> 
>> > On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote:
>> >> "Olaf van der Spek" <[EMAIL PROTECTED]> writes:
>> >> 
>> >> > On 5/15/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> >> >> Bill Allombert <[EMAIL PROTECTED]> writes:
>> >> >>
>> >> >> > On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote:
> [snip]
>> >> 
>> >> We have thought hard about this over the last 2 years and nobody has
>> >> come up with a non disruptive way
>> >
>> > Is "non-disruptive" that vital?  What about "minimally disruptive",
>> > or "a little disruptive"?
>> >
>> > As a user, I'd put up with some one-time disruption if that means
>> > that I could have 64-bit coolness (after all, I'm a home user) while
>> > keeping 32-bit goodness like OOo2 & w32codecs. 
>> 
>> But why would you want to put up with it at all? Do you realy need
>> both a 32bit OOo and a 64bit OOo? Or both 64bit and 32bit video
>> players? Isn't one of the two enough?
>
> No.
>
> $JOE_USER will, ISTM, only need to (want to)run a few 32-bit apps
> on his otherwise 64-bit system.
>
> OOo2 (until it becomes 64-bit clean)
> w32codecs (and thus every app that depends on it)
> Wine
> other OSS apps that aren't 64-bit clean
> binary apps:
> Adobe Acrobat Reader
> Macromedia Flash player
> Crossover Office
> Sun Java ?
>
> And this implies apps like Firefox, since many of these apps have
> plugins for FF & Mozilla, and the libraries they depend on.  (Yes,
> closed source is impure, blah, blah, worship RMS, but the sad fact
> is that they are *useful*.)
>
>> By only alowing one arch per binary we have a totaly non disruptive
>> way of implementing multiarch that is fully upwards and downwards
>> compatible with etch (and only needs a ld.so.conf entry in
>> sarge). Allowing multiple archs for one binary just solves a problem
>> that we don't have and adds a ton of complexity not to mention changes
>> to packages. We are talking 100 vs. 16000.
>
> It looks like we agree on this.  The scope should be narrow and
> "downhill", i.e., ia32 apps on x86_64, PPC32 apps on PPC64, SPARC32
> on SPARC64 systems.  No uphill, and no complications like all the
> different MIPS permutations running together.

No. Only on ia64 and amd64 do you want to default to 64bit. Ia64
because 32bit mode is emulated and amd64 because the ton of extra
regioster make it faster in general. All other archs suffer from the
extra memory and bandwith required for the larger pointer and are
considerably slower in 64bit mode.

But it doesn't realy matter what you call up or downhill. One arch
gets set as prefered or each one gets a pin and the best one available
wins unless overrules by the user.

> Am I arguing for bi-arch?  If so, so be it.  KISS.

You are arguing not to have the same binary for multiple architecture
installed but different binaries from different architectures. Bi-arch
or multiarch is just implementation detail for you. It is what most
sane people want.

> Still, in a universe as large as Debian, some group of users must
> have a reason to need to/want to be able to install side-by-side
> architectures of the same packages.
>
> However, there's no need to make this totally transparent.
>
> People who want to run 32-bit apps in a 64-bit world would have
> to EXPLICITLY run a script that changes that process' personality
> (using linux32) and then runs /usr/bin/${SOMEAPP}_32.

Nah, linux32 just changes the output of uname. Nearly everything has
no need to query that information and you just start it. Alternatives
are much simpler and more transparent for the user.

MfG
Goswin


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

Re: Sun Java available from non-free

[Thiemo Seufer]

Carlos Correia wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Florian Weimer escreveu:
> | * Jeroen van Wolffelaar:
> |
> |
> |>Official packages of Sun Java are now available from the non-free
> |>section of Debian unstable, thanks to Sun releasing[11 Java under a new
> |>license: the Operating System Distributor License for Java (DLJ)[2][3].
> |
> |
> | This license requires that we remove all other Java implementations
> | from the mirror network:
> |
> 
> No, it doesn't!
> 
> ~From DLJ FAQ (http://download.java.net/dlj/DLJ-FAQ-v1.1.txt):
> 
> 8.  Does this license prevent me shipping any alternative technologies
> ~in my OS distribution?
> 
> ~  The DLJ does not restrict you from shipping any other technologies
> ~  you choose to include in your distribution. However, you can't use
> ~  pieces of the JDK configured in conjunction with any alternative
> ~  technologies to create hybrid implementations, or mingle the code
> ~  from the JDK with non-JDK components of any kind so that they run
> ~  together. It is of course perfectly OK to ship programs or libraries
> ~  that use the JDK. Because this question has caused confusion in the
> ~  past, we want to make this absolutely clear: except for these
> ~  limitations on combining technologies, there is nothing in the DLJ
> ~  intended to prevent you from shipping alternative technologies with
> ~  your OS distribution.

Why isn't e.g. an alternative pointing from some other Java environment
to the JDK javac a "hybrid implementation"?

It is the point of a distribution like Debian to integrate the various
pieces.


Thiemo


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

Re: Section of -dev packages

[Roberto C. Sanchez]

Jörg Sommer wrote:
> Hi,
> 
> I ever thought development packages classified by $NAME-dev belong to the
> Section devel or libdevel, but



> 
> I am really suprised. Which packages belong to devel/libdevel?
> 

I found this more instructive:

$ apt-cache search -n .\*-dev\$ | sed 's/ -.*//' | xargs apt-cache show
| grep \^Section: | sort | uniq -c
  1 Section: admin
  1 Section: comm
  3 Section: contrib/libdevel
256 Section: devel
  5 Section: doc
  1 Section: electronics
  1 Section: games
  3 Section: gnome
  3 Section: graphics
  6 Section: interpreters
  3 Section: kde
   1379 Section: libdevel
  5 Section: libs
  6 Section: mail
  2 Section: math
  5 Section: misc
  3 Section: net
  6 Section: non-free/devel
  1 Section: non-free/doc
  3 Section: non-free/libdevel
  1 Section: non-free/net
  2 Section: non-free/x11
 25 Section: oldlibs
 17 Section: python
  2 Section: science
  3 Section: sound
  4 Section: text
  4 Section: utils
  3 Section: web
  3 Section: x11

In other words, on a Sarge system (with backports), over 93% of the
packages (the total is 1757) report themselves as being in devel or
libdevel.  On the whole, I would say that is pretty good.

-ROberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto



signature.asc
Description: OpenPGP digital signature

Re: Why not making /sbin/sendmail a mantadory component for mail operation?

[Roberto C. Sanchez]

Ron Johnson wrote:
> 
> The d-i people, or the m-t-a people?  That's where you define what
> kind of service you want.
> 
> You'd not just have to bluntly ask, but firmly recommend that they
> install the m-t-a as a relay host.  (Once a desktop user like me
> figures out what a relayhost is, and that it won't hose me or make
> my system an open spam relay, it's easy to do.  Now all my outgoing
> mail is relayed to smtp.myisp.net via postfix, but for 4 years of
> using Linux, and 6 years of OS/2 & NT4 before that, it was the
> traditional "put smtp.myisp.net in my MUA".)
> 
> Ignorance, fear of becoming an open relay and years of learning 
> will have to be overcome before Most Users will config Debian to
> use a relayhost.
> 

Perhaps this is something that should be noted in the install notes.  I
know that numerous proposals in the past for splitting Debian into
different desktop and server distros have been shotdown.  However, we
could create seperate release notes or installtion manuals for server
and desktop setups.  The desktop-oriented instructions can include
things like "Most users will want to use their ISPs mail servers.  If
you have a mail server available from your ISP, you can configure your
system to use it by default by following these steps."

That would probably help to eliminate much confusion.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


signature.asc
Description: OpenPGP digital signature

Re: Sun Java available from non-free

[Thiemo Seufer]

Francesco Poli wrote:
> On Wed, 17 May 2006 12:02:34 + Brian M. Carlson wrote:
> 
> > [For -legal people, the license is attached.]
> 
> Thanks.
> 
> [...]
> > Also, section 4 poses a major issue.  If, for any reason, the Linux
> > kernel doesn't do something that Java requires, then we are obligated
> > to either fix it or inform everyone who has acquired Java from us.
> 
> Indeed, it seems we are in chains: whenever Sun decides that we should
> do it, we are bound to modifying the Debian System to satisfy their
> requirements and/or notifying the world about the issue.

Or stop distributing, which terminates the license immediately.


Thiemo


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

Re: Why not making /sbin/sendmail a mantadory component for mail operation?

[Roberto C. Sanchez]

Goswin von Brederlow wrote:
> 
> And how would that be any simpler than setting an smtp server for
> reportbug? Setting up a fully usable MTA is more difficult than having
> reportbug connect directly to bugs.d.o.
> 

I'm sorry, but that is just plain wrong.

aptitude install postfix
"What type of system?" answer: satellite
provide hostname of ISP smarthost

I imagine Exim is similarly simple.

The only thing I think is lacking is that if your ISP requires you to
authenticate, the current postfix packages make it non-trivial to set
this up.  I am not certain if Exim is the same.

Also, it has been a while since I setup Postix in this manner, so I
forget whether it asks you on which addresses to listen.  In any case,
if the default were 127.0.0.1 instead of 0.0.0.0, then even users
without a firewall would be in reasonably good shape.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


signature.asc
Description: OpenPGP digital signature

id gives conflicting results

[Juha Jäykkä]

Hi!

I was digging around a problem with a user not being able to access his
cdrom even though the user belongs to group cdrom (as reported by "groups
user") and the cdrom device is mode rw- group cdrom. It was immediately
clear this is a libnss-ldap issue, since the problem disappears if I add
the user to local (i.e. /etc/group) cdrom group and remove ldap from
group-line in /etc/nsswitch.conf.

Now, what I am concerned about is this. I am logged in as user "juhaj" and

~> id
uid=1000(juhaj) gid=1000(juhaj)
groups=33731,37810,4(adm),4(adm),24(cdrom),24(cdrom),29(audio),29(audio),40(src),40(src),44(video),1000(juhaj),33731,37809

~> id juhaj
uid=1000(juhaj) gid=1000(juhaj)
groups=1000(juhaj),4(adm),24(cdrom),29(audio),40(src),44(video)

These are different, why? According to man id "id" and "id
" are the same. The other command sees four
strange groups > 3 - those are related to openafs kernel tokens and
thus are not "real" groups. The first command, however sees some groups
twice and even in a different order. Can the groups seen twice are a
result of juhaj being a member of these groups both in LDAP and
in /etc/group?

The name service is configured as (I know [SUCCESS=return] is the default,
but having been hit by changing defaults more times than I can count, I
always explicitly mention those defaults that I depend on.)

passwd: ldap [SUCCESS=return] compat
group:  ldap [SUCCESS=return] compat

Can this be related to the not-able-to-access-cdrom problem and is this a
bug?

Cheers,
Juha

-- 
 ---
| Juha Jäykkä, [EMAIL PROTECTED]|
| Laboratory of Theoretical Physics |
| Department of Physics, University of Turku|
| home: http://www.utu.fi/~juolja/  |
 ---


signature.asc
Description: PGP signature

Re: Section of -dev packages

[Kevin B. McCarty]

In case anyone is interested in filing mass bug reports (I am not
sufficiently interested, sorry), here are the -dev packages in
unexpected sections, obtained as follows:

grep-aptavail -r -P '.*-dev$' -s Section,Package | paste -sd '  \n' | \
  egrep -v '^Section: (|contrib/|non-free/)(doc|python|(lib|)devel)' | \
  cut -d ' ' -f 4  | sort

I excluded packages in libdevel,devel,python,doc from the list since:

- the packages in doc are all manpage-dev type packages
- the packages in python are mainly things like python-qt-dev

Below that is the same list piped into dd-list (sorry, dd-list
apparently can only output source package names).


aleph-dev
atm-dev
beagle-dev
cernlib-core-dev
cimg-dev
cli-common-dev
courier-authlib-dev
dpkg-dev
gdk-imlib11-dev
glutg3-dev
gmpc-dev
gnome-applets-dev
imlib11-dev
irssi-dev
jsvc-dev
k3d-dev
kaffe-dev
kdeutils-dev
kdevelop3-dev
konwert-dev
libapr1.0-dev
libapreq2-dev
libaprutil1.0-dev
libcapplet1-dev
libcdg123-dev
libdb4.2-java-dev
libdb4.3-java-dev
libdb4.4-java-dev
libdspam7-dev
libfontenc-dev
libgal-dev
libgd-dev
libgd-noxpm-dev
libgd-xpm-dev
libgdchart-gd1-noxpm-dev
libgdchart-gd1-xpm-dev
libgdk-pixbuf-dev
libgdk-pixbuf-gnome-dev
libghc6-plugins-dev
libghc6-pugs-dev
libghttp-dev
libgl1-mesa-directfb-dev
libgle-dev
libglib1.2-dev
libgnokii2-dev
libgnome-media-dev
libgtk1.2-dev
libicee-dev
libkexi-dev
libmodplug-dev
libmodxslt0-dev
libmpd-dev
libnautilus-burn-dev
libnet0-dev
libnmz7-dev
libnws-dev
libqcad0-dev
libqgis0-dev
libqglviewer-dev
libsdl-ttf1.2-dev
libstk0-dev
libttf-dev
libverbiste0-dev
libvncserver-dev
libxfont-dev
libxmpp4r-ruby1.8-dev
ltp-dev
madwifi-dev
med-bio-dev
med-imaging-dev
mnogosearch-dev
mozilla-thunderbird-dev
nut-dev
nvidia-glx-dev
nvidia-glx-legacy-dev
perdition-dev
pike7.6-dev
pinball-dev
planetpenguin-racer-gimp-dev
playground-dev
plplot-tcl-dev
rsbac-dev
supercollider-dev
svgalibg1-dev
swish-e-dev
thunderbird-dev
vdr-dev
x11proto-bigreqs-dev
x11proto-composite-dev
x11proto-core-dev
x11proto-damage-dev
x11proto-dmx-dev
x11proto-evie-dev
x11proto-fixes-dev
x11proto-fontcache-dev
x11proto-fonts-dev
x11proto-gl-dev
x11proto-input-dev
x11proto-kb-dev
x11proto-print-dev
x11proto-randr-dev
x11proto-record-dev
x11proto-render-dev
x11proto-resource-dev
x11proto-scrnsaver-dev
x11proto-trap-dev
x11proto-video-dev
x11proto-xcmisc-dev
x11proto-xext-dev
x11proto-xf86bigfont-dev
x11proto-xf86dga-dev
x11proto-xf86dri-dev
x11proto-xf86misc-dev
x11proto-xf86vidmode-dev
x11proto-xinerama-dev
xorg-dev
xserver-xorg-dev
xtrans-dev
xutils-dev


Guenter Geiger (Debian/GNU) <[EMAIL PROTECTED]>
   stk

Stefan Hornburg (Racke) <[EMAIL PROTECTED]>
   courier-authlib

Peter De Schrijver (p2) <[EMAIL PROTECTED]>
   linux-atm

Domenico Andreoli <[EMAIL PROTECTED]>
   libnet0

Thomas Bushnell, BSG <[EMAIL PROTECTED]>
   gal0.x
   imlib
   libcapplet

Sebastien Bacher <[EMAIL PROTECTED]>
   verbiste

Paul Brossier <[EMAIL PROTECTED]>
   supercollider

Ross Burton <[EMAIL PROTECTED]>
   nautilus-cd-burner

Javier Carranza <[EMAIL PROTECTED]>
   qcad

Debian Apache Maintainers 
   apr-util1.0
   apr1.0

Debian Qt/KDE Maintainers 
   kdeutils

Debian X Strike Force 
   libfontenc
   libxfont
   x11proto-bigreqs
   x11proto-composite
   x11proto-core
   x11proto-damage
   x11proto-dmx
   x11proto-evie
   x11proto-fixes
   x11proto-fontcache
   x11proto-fonts
   x11proto-gl
   x11proto-input
   x11proto-kb
   x11proto-randr
   x11proto-record
   x11proto-render
   x11proto-resource
   x11proto-scrnsaver
   x11proto-trap
   x11proto-video
   x11proto-xcmisc
   x11proto-xext
   x11proto-xf86bigfont
   x11proto-xf86dga
   x11proto-xf86dri
   x11proto-xf86misc
   x11proto-xf86vidmode
   x11proto-xinerama
   xorg
   xorg-server
   xtrans
   xutils-dev

Dpkg Developers <[EMAIL PROTECTED]>
   dpkg

Yann Dirson <[EMAIL PROTECTED]>
   konwert

Randall Donald <[EMAIL PROTECTED]>
   nvidia-graphics-drivers
   nvidia-graphics-drivers-legacy

Ludovic Drolez <[EMAIL PROTECTED]>
   libvncserver
   swish-e

Anthony Fok <[EMAIL PROTECTED]>
   freetype1

Jochen Friedrich <[EMAIL PROTECTED]>
   pinball

David Moreno Garza <[EMAIL PROTECTED]>
   playground

Jan-Marek Glogowski <[EMAIL PROTECTED]>
   libcdg123

Debian Mono Group <[EMAIL PROTECTED]>
   cli-common

Debian QA Group <[EMAIL PROTECTED]>
   kexi
   libghttp

Steinar H. Gunderson <[EMAIL PROTECTED]>
   libapreq2

Marek Habersack <[EMAIL PROTECTED]>
   pike7.6

Steve Halasz <[EMAIL PROTECTED]>
   qgis

Johannes Hirche <[EMAIL PROTECTED]>
   qglviewer

Simon Horman <[EMAIL PROTECTED]>
   perdition

Philipp Hug <[EMAIL PROTECTED]>
   mnogosearch

Norman Jordan <[EMAIL PROTECTED]>
   kdevelop3

Guillem Jover <[EMAIL PROTECTED]>
   svgalib

Rafael Laboissiere <[EMAIL PROTECTED]>
   plplot

Debian Berkeley DB Maintainers <[EMAIL PROTECTED]>
   db4.2
   db4.3
   db4.4

Debian DSPAM Maintainers <[EMAIL PROTECTED]>
   dspam

Debian Java Maintainers 
   commons-daemon
   kaffe

Bradley Marshall <[EMAIL PROTECTED]>
   gnokii

Kevin B. McCarty <[EM

Re: Sun Java available from non-free

[Anthony Towns]

On Wed, May 17, 2006 at 09:50:51AM -0400, Kevin B. McCarty wrote:
> >   If Sun becomes aware of a compatibility problem with the JDK
> >   software on your OS distribution and notifies you about it, then you
> >   must fix the problem and offer a patch or new version to your
> >   downstream users and distributors, or stop distributing the software
> >   within 90 days of being notified. 
> Is this a burden that FTP-masters are willing and able to take on?  Or
> is the probability of this happening judged to be low enough that we
> aren't worried about it?

90 days is three months, which is about the timeline that seems sensible to
maintain for point releases anyway (ie, two to three months), so this seems
pretty achievable, even if it were likely.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Sun Java available from non-free

[Francesco Poli]

On Wed, 17 May 2006 22:56:06 +0100 Thiemo Seufer wrote:

> Francesco Poli wrote:
> > On Wed, 17 May 2006 12:02:34 + Brian M. Carlson wrote:
> > 
> > > [For -legal people, the license is attached.]
> > 
> > Thanks.
> > 
> > [...]
> > > Also, section 4 poses a major issue.  If, for any reason, the
> > > Linux kernel doesn't do something that Java requires, then we are
> > > obligated to either fix it or inform everyone who has acquired
> > > Java from us.
> > 
> > Indeed, it seems we are in chains: whenever Sun decides that we
> > should do it, we are bound to modifying the Debian System to satisfy
> > their requirements and/or notifying the world about the issue.
> 
> Or stop distributing, which terminates the license immediately.

Yes, I should have been clearer...

There are two options, if Sun decides that the Debian System is an
"Incompatible Operating System":
 (a) modify Debian until Sun is satisfied and release an update
 (b) stop distributing Sun Java and notify Licensees

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpOLluZSVfAl.pgp
Description: PGP signature

Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]

[Ron Johnson]

On Wed, 2006-05-17 at 22:47 +0200, Michal Čihař wrote:
> On Wed, 17 May 2006 10:44:19 -0500
> Ron Johnson <[EMAIL PROTECTED]> wrote:
> 
> > Interesting.  b.d.o doesn't seem to be answering on port 25 though.
> 
> Doesn't your provider block port 25?
> 
> $ telnet bugs.debian.org 25
> Trying 140.211.166.43...
> Connected to bugs.debian.org.
> Escape character is '^]'.
> 220 spohr.debian.org ESMTP Exim 4.50 Wed, 17 May 2006 13:45:34 -0700
> EHLO me
> 250-spohr.debian.org Hello nat-10.jups.junix.cz [86.49.49.74]
> 250-SIZE 62914560
> 250-PIPELINING
> 250 HELP
> QUIT
> 221 spohr.debian.org closing connection
> Connection closed by foreign host.

It blocks *incoming* port 25 traffic for well understood reasons.
I never knew, though that it also blocks all *outgoing* smtp
traffic except to it's own servers.  Maybe to Winbots from emailing
files back "home"?



$ telnet bugs.debian.org 25
Trying 140.211.166.43...




$ telnet smtp.east.cox.net 25
Trying 68.1.17.4...
Connected to smtp.east.cox.net.
Escape character is '^]'.
220 eastrmmtao05.cox.net ESMTP server (InterMail vM.6.01.06.01
201-2131-130-101-20060113) ready Wed, 17 May 2006 19:24:46 -0400
EHLO me
250-eastrmmtao05.cox.net
250-HELP
250-XREMOTEQUEUE
250-ETRN
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 10485760
HELP
214-This SMTP server is a part of the InterMail E-mail system.  For 
214- information about InterMail, please see http://www.openwave.com 
214-  
214-   Supported commands: 
214-  
214-EHLO HELO MAIL RCPT DATA 
214-VRFY RSET NOOP QUIT 
214-  
214-   SMTP Extensions supported through EHLO: 
214-  
214-EXPN HELP SIZE 
214-  
214- For more information about a listed topic, use "HELP " 
214  Please report mail-related problems to Postmaster at this site.
QUIT
221 eastrmmtao05.cox.net ESMTP server closing connection
Connection closed by foreign host.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA

"marauders in radiation poluted area are not just a regular
marauders, they don't steal stuff for themselves. There were
cases of radiactive tv sets and other stuff being sold on city
second hand markets and then police shot 7 or 8 of them and it
helped"
http://www.angelfire.com/extreme4/kiddofspeed/page4.html

Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email

[Ron Johnson]

On Wed, 2006-05-17 at 23:28 +0200, Marc Haber wrote:
> On Wed, 17 May 2006 11:35:44 +0200, Adam Borowski
> <[EMAIL PROTECTED]> wrote:
[snip]
> 
> Why this tool is written in python, an interpreted language with a run
> time system the size of Buckingham Palace, The White House and the
> Kreml combined, is an entirely different story.

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND 
11087 me16   0  155m  77m  18m S  0.0  7.6   0:25.85 evolution-2.6  
12651 me15   0  123m  49m  17m S 32.9  4.9   0:12.98 firefox-bin
29560 root  15   0  183m  34m 7748 S  4.7  3.4  51:35.33 Xorg   
 1104 root  16   0 33252  28m 2268 S  0.0  2.8   0:42.62 spamd  
 5821 root  16   0 31056  25m 2204 S  0.0  2.6   0:12.51 spamd  
 2902 root  16   0 26768  21m 2236 S  0.0  2.1   0:07.74 spamd  

[snip]
12551 me16   0  9132 6624 2512 S  0.0  0.6   0:00.90 reportbug

This doesn't look all that huge to me...

Maybe I'm just jaded by pigs like Evo, FF, X & SpamAssassin.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA

Supporting World Peace Through Nuclear Pacification


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

Great find!!!

[H . Grant]

Check this out!
 
I've found this great site! The girls are hot and the pics are even hotter! 
 And man can they talk the talk. Great Buzz!  A definite must see.
 
www.seemetextme.com/girls


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

Great find!!!

[H . Grant]

Check this out!
 
I've found this great site! The girls are hot and the pics are even hotter! 
 And man can they talk the talk. Great Buzz!  A definite must see.
 
www.seemetextme.com/girls


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

Re: Why not making /sbin/sendmail a mantadory component for mail operation?

[Goswin von Brederlow]

"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
>> 
>> And how would that be any simpler than setting an smtp server for
>> reportbug? Setting up a fully usable MTA is more difficult than having
>> reportbug connect directly to bugs.d.o.
>> 
>
> I'm sorry, but that is just plain wrong.
>
> aptitude install postfix
> "What type of system?" answer: satellite
> provide hostname of ISP smarthost
>
> I imagine Exim is similarly simple.

Huh? What is a smarthost? Do I have one? Do I need one? Damn, my ISP
doesn't have a free smarthost, makes me pay extra for it and I don't
want to. (Yes T-online does that).

> The only thing I think is lacking is that if your ISP requires you to
> authenticate, the current postfix packages make it non-trivial to set
> this up.  I am not certain if Exim is the same.
>
> Also, it has been a while since I setup Postix in this manner, so I
> forget whether it asks you on which addresses to listen.  In any case,
> if the default were 127.0.0.1 instead of 0.0.0.0, then even users
> without a firewall would be in reasonably good shape.

More and more stones in the way the unexperienced user can stumble on.



As a comparison look at the popularity-contest package. For a long
time that package did require an MTA and many people have complained
about it and couldn't use it. Now it also talks http.

Having reportbug not require a local MTA is a step in the right
direction. Someone writing a http POST gateway for it to report bugs
would be the next step in making it more universal.

> -Roberto

MfG
Goswin


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

Re: multiarch status update

[Goswin von Brederlow]

Darren Salt <[EMAIL PROTECTED]> writes:

> I demand that Gabor Gombas may or may not have written...
>
> [snip]
>> How do you want to handle one-arch-only binNMUs? binNMUs change
>> changelog.Debian.gz, so
>> - you can't upgrade just the architecture that was binNMUed without
>>   changelog.Debian.gz becoming invalid for the other arches
> [snip]
>
> I think that this'll just have to be accepted - ignore the binNMU versioning
> when comparing versions for co-installation, but take the docs from the
> highest-numbered binNMU.
>
> I don't know how a binNMU for one architecture followed by a binNMU for
> another is handled, but it seems reasonable to me that the newer one will
> have to include the changelog from the older one and, therefore, must have a
> higher version number. Otherwise, which binNMU changelog entry you get is a
> matter of chance, and entries may even be lost in later uploads.

Not to mention that binNMU for only one arch will be fixing a build
screwup like a broken gcc version on that arch causing faulty
binaries. And binNMUs for multiple/all archs will be to help
transitions in their depends along.

In both cases no change has been made to the source and the reason for
the binNMU is quite irelevant to most users.


But there will be times where the actual source version of debs for
each arch differs. Actualy at every upgarde that happens between arch1
getting unpacked and arch2 getting unpacked as well. Dpkg just has to
handle it in some sane way.

MfG
Goswin


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

Re: Section of -dev packages

[Goswin von Brederlow]

"Kevin B. McCarty" <[EMAIL PROTECTED]> writes:

> In case anyone is interested in filing mass bug reports (I am not
> sufficiently interested, sorry), here are the -dev packages in
> unexpected sections, obtained as follows:
>
> grep-aptavail -r -P '.*-dev$' -s Section,Package | paste -sd '  \n' | \
>   egrep -v '^Section: (|contrib/|non-free/)(doc|python|(lib|)devel)' | \
>   cut -d ' ' -f 4  | sort
>
> I excluded packages in libdevel,devel,python,doc from the list since:

Exclude oldlibs too.

MfG
Goswin


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

Re: id gives conflicting results

[Russ Allbery]

Juha Jäykkä <[EMAIL PROTECTED]> writes:

> I was digging around a problem with a user not being able to access his
> cdrom even though the user belongs to group cdrom (as reported by
> "groups user") and the cdrom device is mode rw- group cdrom. It was
> immediately clear this is a libnss-ldap issue, since the problem
> disappears if I add the user to local (i.e. /etc/group) cdrom group and
> remove ldap from group-line in /etc/nsswitch.conf.

> Now, what I am concerned about is this. I am logged in as user "juhaj"
> and

> ~> id
> uid=1000(juhaj) gid=1000(juhaj)
> groups=33731,37810,4(adm),4(adm),24(cdrom),24(cdrom),29(audio),29(audio),40(src),40(src),44(video),1000(juhaj),33731,37809

> ~> id juhaj
> uid=1000(juhaj) gid=1000(juhaj)
> groups=1000(juhaj),4(adm),24(cdrom),29(audio),40(src),44(video)

> These are different, why? According to man id "id" and "id
> " are the same. The other command sees four
> strange groups > 3 - those are related to openafs kernel tokens and
> thus are not "real" groups.

I wonder if the weird AFS PAG hack is corrupting the process group list in
some way.  It would be the first time I'd heard of that problem if so, but
the output does indeed look rather suspicious and AFS fiddles with the
group list (it won't as soon as the integration with the kernel keyring is
finished, since Linux *finally* provides native functionality that can
replace this technique).

Have you already reported this one to the OpenAFS lists with your kernel
version and where you got the kernel packages from?

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: Why not making /sbin/sendmail a mantadory component for mail operation?

[Henrique de Moraes Holschuh]

On Wed, 17 May 2006, Goswin von Brederlow wrote:
> You mean connection from random user ports to destination port 25?

Yes.

> If you are at a place where that is the case then you should have an
> IT team or admin that will tell you what smtp host to use or even
> install your system.

We do.  So does every user in a proper ISP (not all of them block outgoing
port 25, but many do these days. And all of them tell you which smtp server
to use), and corporate network.

It is still not a good default (as in "safe if the user doesn't know it is
there or what it does"), which is the whole point.

> > Sometimes I feel we are abandoning the true spirit of an Unix system.  If
> > Debian made sure to always have a local MTA that is properly configured to
> > send email (and it can be a simple SMTP with no queue thing, too.  It can
> > work just as well and can be as safe as a full-blown MTA, the drawback is
> > that the user has to wait for the email to be delivered to a queueing MTA
> > before the sendmail command returns), everything could be made to just work.
> 
> And how would that be any simpler than setting an smtp server for
> reportbug? Setting up a fully usable MTA is more difficult than having
> reportbug connect directly to bugs.d.o.

You do it only *once* for the entire system.  I am quite amused I even have
to answer such a question.

> > What exactly is the problem with making a local MTA absolutely mandatory,
> > (as in anything that sends email either recommends or depends on
> > mail-transport-agent)?
> >
> > Of course, at the same time we would have to make sure stuff like nbsmtp,
> > nullmailer, esmtp-run or ssmtp is trivially easy to install, and point our
> > users to those packages so that they know the possiblity exists. IMHO we
> > really ought to leverage d-i to bluntly ask the user if he wants a
> > full-blown MTA or just a SMTP relay (obviously by using easier terms, like a
> > "Advanced outgoing mail service" (i.e. exim) task, which if not selected,
> > gives you nullmailer or somesuch.
> 
> That would mean another service on the system that might get
> compromised or misused. I'm perfectly fine with having mail only

Well, a MSA (mail sending agent, a proper name for a queue-less MTA IMHO)
never listens to anything or needs any other priviledge apart from "open a
inet socket to a remote machine": it just connects to somewhere over SMTP
and delivers its standard input to the SMTP server on the other side.  It is
not a daemon, or anything like that.  It is as vulnerable to compromise as
perl's smtp client code is.

As for misused, well, the real question is how easy is to misuse such a
thing by accident.

> delivered internaly or not at all for my chroots but I still want to
> be able to report bugs with the right dependency informations. If you
> force the use of an MTA then I would have to save the bug reports to a
> file and mail them manualy from outside the chroot every time I get a
> bug. Much less usable.

Override the default to use SMTP directly, then.  Are you seriously
advocating your "chroot with a mail-less setup" as a good reason to define
the *default* method of mail delivery for the distro?  That ain't a common
user case, you know.

It is *not* much less usable, at all.  We are talking about the *default*
behaviour.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]

[Henrique de Moraes Holschuh]

On Wed, 17 May 2006, Ron Johnson wrote:
> It blocks *incoming* port 25 traffic for well understood reasons.

Yes, purely commercial reasons.

> I never knew, though that it also blocks all *outgoing* smtp
> traffic except to it's own servers.  Maybe to Winbots from emailing
> files back "home"?

Yes, to avoid spam-bots, spam mailers, and smtp-client-enabled viruses.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: mdadm 2.4.1-1 ready for tests

[martin f krafft]

also sprach Simon Huggins <[EMAIL PROTECTED]> [2006.05.17.1029 -0500]:
> I know this isn't the sort of feedback you want but these aren't
> all "please ship the new version of mdadm" bugs and whilst they
> might well be fixed by this version I thought consensus was to try
> to describe what it was about this release that fixes these bugs.

Mh. I don't want to (re)start a flamewar, but my take is that
changelog.Debian documents changes I've made, and the upstream
changelog documents the changes they've made. I acknowledge these
changes by closing the bugs, and if you care how it got fixed, you
look at the upstream changelog. I just don't think there's a big
point in duplicating information in the Debian changelog.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
officer, arrest that man! he's whistling a copyrighted song.


signature.asc
Description: Digital signature (GPG/PGP)

Re: Why not making /sbin/sendmail a mantadory component for mail operation?

[Jeroen van Wolffelaar]

On Wed, May 17, 2006 at 03:16:35PM -0500, Ron Johnson wrote:
> Ignorance, fear of becoming an open relay and years of learning 
> will have to be overcome before Most Users will config Debian to
> use a relayhost.

It's not very difficult to have exim, the default MTA, simply not launch
an smtp listener. If it's only running queues and providing the
/usr/sbin/sendmail interface, you cannot possibly be a mail relay, since
nothing even listens on port 25. The configuration file to edit for this
is /etc/default/exim4

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

Re: I want to modify the gnome panel deb package

[Josselin Mouette]

Le mercredi 17 mai 2006 à 06:31 +0100, Indraveni a écrit :
> Hi,
> 
>  we are working for a  distro which is using debian pacakges. By
> default the gnome panel is having no colour. I want to change the look
> and feel of the panel, Applications menu backgroud color, Window title
> background color..,etc. Just to make it look diferent with diffrent
> colors. I dont want to go with a new theme. 

Yes, you want to go with a new theme. This is the only sane solution for
what you are trying to do.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Re: screenshot with package description

[Andrew Donnellan]

What I am trying to point out is that the DEBs *would* be a good idea
it would clog up APT and dpkg (emphasis on dpkg) because on my system
I have over 25 files from packages installed and as a result it
takes at *least* 30 seconds to read the database from /var/lib/dpkg.
Adding these pixmaps would make that 45-60 seconds if I installed all
of them, and when I want to do package installation I want to do it
fast!

However, another solution would be just place these JPGs and PNGs flat
on the server and have apt just download them and save them

On 5/16/06, Gonéri Le Bouder <[EMAIL PROTECTED]> wrote:

>I mean, all pics are in the same location, but can easyly installed
>using apt and friends  and noone must download the whole tarballs.

>Even Modem or ISDN-Users would like to see screenshots of some
>packages/programs and huge tarballs are no sulution.

$ apt-cache rdepends libx11-6|wc -l
2237
2237 x 40k = 90MB
Some non X11 based application like mutt could have a screenshot too but we
won't have 15 000 pixmaps.

Tarball is a good solution for people who don't have an Internet connexion but
some space on theirs hard drive. The tarballs will be copied from the
CD/DVDROMs.
If you have a connexion to a pixmap repository you won't have to feed a local
cache. A slow connexion is enouch too retrieve 40kb pictures.

Regards,

Gonéri





--
Andrew Donnellan
http://andrewdonnellan.com
http://ajdlinux.blogspot.com
Jabber - [EMAIL PROTECTED]
---
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net

Re: mdadm 2.4.1-1 ready for tests

[Henrique de Moraes Holschuh]

On Wed, 17 May 2006, martin f krafft wrote:
> Mh. I don't want to (re)start a flamewar, but my take is that
> changelog.Debian documents changes I've made, and the upstream
> changelog documents the changes they've made. I acknowledge these
> changes by closing the bugs, and if you care how it got fixed, you
> look at the upstream changelog. I just don't think there's a big
> point in duplicating information in the Debian changelog.

Please reconsider.

mdadm is a *critical* part of a system that uses linux software raid.
Anything that helps users understand all the important changes an update
will imply is always uselful.  Anything that helps a developer easily track
down what *exacly* caused a bug to be closed can be very useful, too.

The debian changelog is the only source of such information which is well
defined, consistent, and available from tools like aptitude, apt-listchanges
and other Debian infrastructure.  Duplicating the entire upstream
changelog there can be quite silly (if the upstream changelog is very
detailed), but adding the main points there is *very* appreciated by many of
us.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]

[Don Armstrong]

On Wed, 17 May 2006, Henning Makholm wrote:
> Scripsit Don Armstrong <[EMAIL PROTECTED]>
> >> What about modifying it to work through something like an http POST?
> 
> > I'm personally not too terribly interested in implementing an HTTP
> > access method for the BTS, because it makes it more easy for bug
> > submissions to be sent from people who can not be accessed via
> > e-mail.
> 
> How does sending directly to from reportbug to an ISP's smarthost
> validate the user's email address better than sending directly from
> reportbug to a HTTP POST somewhere?

I'm talking about an HTTP access method in general; if it were to be
done, I'd expect that it validate the users email address before
actually forwarding bug reports from the user.

reportbug is somewhat of a special case because it actually provides
useful information along with the bug report; non-reachable submitters
are slightly less anoying than in other cases.

> It is not necessary that there is anywhere any HTML form that refers
> to the posting URL; only reportbug would need to know it.

Except for the fact that anyone can create a page which posts to that
url. In any case, I'm not stoping anyone else from implementing it;
I've just explained why I'm not going to implement it.


Don Armstrong

-- 
Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly).
 -- Matt Welsh

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: mdadm 2.4.1-1 ready for tests

[Stefano Zacchiroli]

On Wed, May 17, 2006 at 09:55:54PM -0500, martin f krafft wrote:
> I just don't think there's a big point in duplicating information in
> the Debian changelog.

I see debian work as tailoring upstream one so that it best fits our
users. Selecting the appropriate information from the upstream changelog
that describe how bugs reported in our BTS got closed is part of such
tailoring.

Beside that and more practical: why documenting "closes:" in
debian/changelog if the users have no way to understand them? If it is
only for automatically closing bugs with the upload there is something
wrong with the usage of the instrument.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: Why not making /sbin/sendmail a mantadory component for mail operation?

[Goswin von Brederlow]

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

> On Wed, 17 May 2006, Goswin von Brederlow wrote:
>> delivered internaly or not at all for my chroots but I still want to
>> be able to report bugs with the right dependency informations. If you
>> force the use of an MTA then I would have to save the bug reports to a
>> file and mail them manualy from outside the chroot every time I get a
>> bug. Much less usable.
>
> Override the default to use SMTP directly, then.  Are you seriously
> advocating your "chroot with a mail-less setup" as a good reason to define
> the *default* method of mail delivery for the distro?  That ain't a common
> user case, you know.
>
> It is *not* much less usable, at all.  We are talking about the *default*
> behaviour.

No, you sounded like you wanted to enforce the installation of an MTA
on every system and only support that (since all systems would have
one why bother with anything else?).

Anyway, the default currently is to use the normal mail system instead
of going direct.

MfG
Goswin


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

Re: Sun Java available from non-free

[Florian Weimer]

* Emmanuel le Chevoir:

> Florian Weimer a écrit :
>> * Jeroen van Wolffelaar:
>> 
>>> Official packages of Sun Java are now available from the non-free
>>> section of Debian unstable, thanks to Sun releasing[11 Java under a new
>>> license: the Operating System Distributor License for Java (DLJ)[2][3].
>> 
>> This license requires that we remove all other Java implementations
>> from the mirror network:
>
> That's not what I read.
> Quoting the FAQ[1]:

The FAQ claims to be irrelevant:

| Note: This FAQ is provided to help explain the Operating System
| Distributor License for Java; nothing in this FAQ is intended to amend
| the license, so please consult the license itself for the precise
| terms and conditions that actually apply.

Under German law, such a disclaimer isn't 100% effective, but I'm
under the impression that U.S. law is different.  And the license
claims to be governed by Californian law.

>  #|  8.  Does this license prevent me shipping any alternative
>  #|  technologies in my OS distribution?
>  #|
>  #|  The DLJ does not restrict you from shipping any other
>  #|  technologies you choose to include in your distribution.
>  #|  However, you can't use pieces of the JDK configured in
>  #|  conjunction with any alternative technologies to create
>  #|  hybrid implementations, or mingle the code from the JDK
>  #|  with non-JDK components of any kind so that they run
>  #|  together. It is of course perfectly OK to ship programs
>  #|  or libraries that use the JDK. Because this question has
>  #|  caused confusion in the past, we want to make this absolutely
>  #|  clear: except for these limitations on combining technologies,
>  #|  there is nothing in the DLJ intended to prevent you from shipping
>  #|  alternative technologies with your OS distribution.

Even if we read it very favorably, the FAQ seems to require that we
ensure, by testing or with technical means, that no package
accidentally or deliberately overrides parts of Sun's implementation.
This risk of conflict does exist because our users actually want to
use free software from "main" together with Sun's implementation, so
that implementation can't really be completely separated from the
rest.

Re: Sun Java available from non-free

[Florian Weimer]

* Bill Allombert:

> I don't think it is appropriate to use debian-devel-announce to
> advertise non-free softwares epecially when we are striving to provide 
> a free alternative.

I tend to agree.

> Any pointer to that discussion ? I could not find any on debian-legal.
>  From reading the license I don't see how we can distribute it without
> some binding promise from SUN they will not sue us no matter what.

And this promise needs to extend to our mirror operators.  Even if we
put a disclaimer on the non-free section, saying that mirrors should
carry it on a package-by-package basis after considering the license,
I think it's hardly fair to push a license such as this onto the
mirror network.


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

Re: Sun Java available from non-free

[Michael Banck]

On Wed, May 17, 2006 at 10:44:54PM +0200, Bill Allombert wrote:
> On Wed, May 17, 2006 at 08:20:14AM +0200, Jeroen van Wolffelaar wrote:
> > During the past weeks there has been close collaboration between Sun
> > engineers and Debian and Ubuntu developers. The quick turnaround for
> > creating those packages was made possible by reusing existing packaging
> > code from the Blackdown Java Linux project, contributed by Matthias
> > Klose and Jürgen Kreileder. Thanks to both of them for this.
> 
> Any pointer to that discussion ? I could not find any on debian-legal.

As I understand it, this paragraph is talking about the actual packaging
work having been done in collaboration, rather than the licesensing
discussion (which probably also was done in collaboration, but maybe not
publically on debian-legal, I don't know).


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Re: Mass bug filing: failure to use invoke-rc.d when required

[Steve Langasek]

On Wed, May 17, 2006 at 12:37:56PM +, Brian M. Carlson wrote:
> Then when are we removing the debian-policy package from the archive?
> But seriously, if violating Debian Policy has no consequences, then it
> probably won't be followed.  As it stands now, Policy is useless because
> the worst that can happen is an important bug, which can be safely
> ignored almost forever.

The release team is not going to enforce all policy violations as RC bugs,
because although all policy violations should be considered bugs, not all of
them should warrant delaying the release or removing the package from the
release.

So whether or not such bugs are labelled "serious" is irrelevant, because
labelling them "serious" would just mean that sev: serious no longer
correctly identifies RC bugs and we would then need some other way to
separate RC from non-RC serious bugs.

> As far as the etch_rc_policy.txt, there are at least 10 different issues
> with that document that may be unintended, one of which is that as it
> stands now, all perl-using packages *must* depend on perl-base,

Perl-base is Essential: yes.  It is not a bug to not depend on an Essential
package, so nor is it an *RC* Bug to not depend on an Essential package.

> and all python-using packages *must* depend on the package providing the
> interpreter (/usr/bin/python is *not* an interpreter, merely a symlink),
> such as python2.3, python2.4, or python2.5[0].

This is a lame argument.  The RC policy says "package providing the
interpreter", not "package containing the binary".  /usr/bin/python is
clearly an interpreter provided by the "python" package.

Patches to improve the wording of the RC bug policy are certainly welcome,
but I'm not going to spend a lot of my own time trying to idiot-proof it;
both of your examples seem terribly contrived to me, and if the etch RC
policy is read with the understanding that it identifies those violations of
*existing* policy that are RC, rather than attempting to declare *new*
policy, I don't see that there's any reason for confusion here.

> Finally, I would prefer if some tag existed that would indicate that a
> bug is not a concern for the release but is still a major error in terms
> of Debian Policy.  I understand that such tags *do* exist, and that they
> are called "sid" and "experimental".  I also understand that these are
> deprecated with BTS version tracking; however, since these tags have the
> desired effect, and there are no other ones with equivalent effect, I
> will use them for all of my current and future bugs.

No, the "sid" tag does not have the desired effect.  It has the effect of
causing britney to regard the version of the package in sid as having an RC
bug, and take it into consideration when evaluating the sid version of the
package for propagation to testing.  Please don't try to use tags this way,
it's inconsistent with how the software works (and is intended to work,
TTBOMK).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Sun Java available from non-free

[Don Armstrong]

Executive Summary: There are serious issues with clause 2a, 2b, 2c,
2f, and 4; and lesser issues with other bits of this license. As much
as some of our users would like to see us distributing this JDK in
non-free, I'm really not sure that it can be distributed while
complying with the license or without incurring unreasonable burdens
upon our mirror operators and Debian. I'd recommend that ftp-masters
consider pulling this package from non-free until these issues are
resolved (or at least understood.)


First off, I'm going to completely ignore the FAQ as the FAQ and the
license both specifies that the FAQ does not have any legal validity.
I'm also going to rip out the bits of the license which I don't feel
are particularly useful; this doesn't mean that they don't have
problems, only that I haven't seen them in a rapid pass through of the
license.[0]

As a final note, did anyone from Debian who usually examines licences
actually examine this one? [At any time if you're unsure of a license,
but don't want to disclose the new terms publicly you should be
contacting someone who routinely does this kind of examination so this
sort of problem doesn't occur. I'm always willing to help clarify the
issues facing Debian in regards to both free and non-free licenses; I
assume other contributors to -legal are willing to as well.]

> 2. License Grant. Subject to the terms and conditions of this
> Agreement, [...] provided that: (a) the Software and any
> proprietary legends or notices are complete and unmodified;

This seems to cause a problem with actually packaging the software
unless the Debian package counts as the Software... this seems to mean
that any time that the package should be changed the maintainers need
Sun to actually distribute the software to them (or otherwise grant
them the ability to modify the software.)

> (b) the Software is distributed with your Operating System, and
> such distribution is solely for the purposes of running Programs
> under the control of your Operating System and designing,
> developing and testing Programs to be run under the control of
> your Operating System;

non-free is not part of Debian so we definetly don't distribute it as
part of the Operating system.

> (c) you do not combine, configure or distribute the Software to
> run in conjunction with any additional software that implements
> the same or similar functionality or APIs as the Software;

This means that we can't distribute eclispse or anything else which
implements part of the Java API (or if you're going to read this
clause as broadly as possible,[1] things like perl which implement
similar functionality in that perl is an implementation of a cross
platform language Perl.)

> (d) you do not remove or modify any included license agreement
> or impede or prevent it from displaying and requiring
> acceptance;

We may need to modify debconf preseeding to make sure that the user
can't prevent the agreement from being shown...

> (f) you agree to defend and indemnify Sun and its licensors from
> and against any damages, costs, liabilities, settlement amounts
> and/or expenses (including attorneys' fees) incurred in
> connection with any claim, lawsuit or action by any third party
> that arises or results from (i) the use or distribution of your
> Operating System, or any part thereof, in any manner, or (ii)
> your use or distribution of the Software in violation of the
> terms of this Agreement or applicable law.

I'm really not entirely sure what this clause is getting at, but it
seems that the intention is that Debian needs to indemnify Sun for any
litigation resulting by users of the package of Sun's JDK which Debian
has distributed, even if Sun is grossly negligent.[2]
 
> 4. COMPATIBILITY. If you exercise the license in Section 2, and Sun
> or a licensee of the Software (under section 4(b)) notifies you
> that there are compatibility issues [...] caused by the
> interaction of the Software with your Operating System, then
> within ninety (90) days you must either: (a) modify the
> Operating System in a way that resolves the compatibility issue
> (as determined by Sun) and make a patch or replacement version
> available [...]

Oh, right... so if the Sun JDK is buggy, we have to modify our
operating system to make it unbuggy in some way that makes Sun happy.
Makes sense to me.

> 14. MISCELLANEOUS. Any action related to this Agreement will be
> governed by California law and controlling U.S. federal law. No
> choice of law rules of any jurisdiction will apply.

A yeah! Now everyone gets to suffer!

> It supersedes all prior or contemporaneous oral or written
> communications, proposals, representations and warranties and
> prevails over any conflicting or additional terms of any quote,
> order, acknowledgment, or other communication between the
> parties relating to its

Re: Sun Java available from non-free

[Brendon Higgins]

Here I was, as a user, happy to read the announcement that the real thing was 
going into non-free. Then this. Brilliant. This is a stuff-up of Kovco[1] 
proportions. How can Sun consider a license with those sort of provisions 
fair? How can the JDK get into the archive before anyone picking up on this?

Eagerly awaiting a complete and free JDK so we won't have to put up with this 
kind of crap,
Brendon

1: http://news.google.com.au/news?q=Kovco&ie=UTF-8&oe=UTF-8


pgptRoi93NPVP.pgp
Description: PGP signature

Re: mdadm 2.4.1-1 ready for tests

[Frank Küster]

martin f krafft <[EMAIL PROTECTED]> wrote:

> also sprach Simon Huggins <[EMAIL PROTECTED]> [2006.05.17.1029 -0500]:
>> I know this isn't the sort of feedback you want but these aren't
>> all "please ship the new version of mdadm" bugs and whilst they
>> might well be fixed by this version I thought consensus was to try
>> to describe what it was about this release that fixes these bugs.
>
> Mh. I don't want to (re)start a flamewar, but my take is that
> changelog.Debian documents changes I've made, and the upstream
> changelog documents the changes they've made.

No need to restart the discussion, because this has already been
discussed ad nauseam.  The conclusion always was that you should give an
explanation to each bug you close.  In doubt, the list archives will help...

Gruß, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: mdadm 2.4.1-1 ready for tests

[martin f krafft]

also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2006.05.17.2210 
-0500]:
> mdadm is a *critical* part of a system that uses linux software
> raid. Anything that helps users understand all the important
> changes an update will imply is always uselful. 

Of course, but if there weren't any important changes, doesn't it
suffice that a bug is just fixed? As in: previously mdadm did that
wrongly, and that's fixed. Why should a user care how it was fixed?

Also, what you are saying leads me to believe that you would want me
to document *all* important changes, whether respective Debian bugs
existed or not. NEWS.Debian is clearly a better method for such
announcements, but you *should* try to keep the stuff there down to
a minimum, IMHO.

In any case, I *will* go through the fixed-upstream bugs again to
make sure that the fixes do not have implications for users who
weren't affected by the bug.

> Anything that helps a developer easily track down what *exacly*
> caused a bug to be closed can be very useful, too.

I would expect a developer to know to turn to the upstream changelog
for such information. Apart, the Debian changelog would be
hopelessly long if I had to specify "what *exactly* caused a bug to
be closed."

> but adding the main points there is *very* appreciated by many of
> us.

This argument stands. I'll consider it.



also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2006.05.17.2217 -0500]:
> I see debian work as tailoring upstream one so that it best fits
> our users. Selecting the appropriate information from the upstream
> changelog that describe how bugs reported in our BTS got closed is
> part of such tailoring.

Yes, but see above. A bug that existed previously which is now fixed
is in and of itself appropriate information: the problem now does
not exist anymore.

> Beside that and more practical: why documenting "closes:" in
> debian/changelog if the users have no way to understand them? If
> it is only for automatically closing bugs with the upload there is
> something wrong with the usage of the instrument.

Is there? I am telling the user that his/her bugs were closed by
upstream, or have been "obsoleted" by the new release.

So as you can see, I disagree. However, I do understand that mdadm
is kind of critical, so I will reconsider and might change the
changelog when I upload to unstable.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
http://kirch.net/unix-nt/


signature.asc
Description: Digital signature (GPG/PGP)