Re: Request for virtual package ircd

[Mario Iseli]

On Thu, Oct 12, 2006 at 08:55:57AM +0200, Lucas Nussbaum wrote:
> Those packages should not depend on ircd anyway, because the service and
> the ircd can run on different systems.

Ok, this is a good argument.
I think the oppinion is more or less clear:

Some people think it would be a nice idea, BUT it can be also a problem
because some people want more than one Ircd on a system.

I only wanted to ask you for your oppinion, so thank you all! :-)

-- 
  .''`. Mario Iseli <[EMAIL PROTECTED]>
 : :'  :proud user of Debian unstable
 `. `'`
   `-  Debian - when you have better things to do than fixing a system


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

Re: delay of the full etch freeze

[Hubert Chan]

On Thu, 12 Oct 2006 09:38:21 +0900, [EMAIL PROTECTED] said:

> Le Wed, Oct 11, 2006 at 06:58:55PM +0200, Andreas Barth a écrit :
>> 
>> For these reasons, we are delaying the full archive freeze for a few
>> days.  We haven't chosen a date yet, but you can still expect it to
>> happen in October or early November.

> Dear Andreas,

> May I suggest to delay the freeze as long as it is necessary for the
> packages which were uploaded to NEW before the 8th to enter in Etch if
> they have no bugs?

[...]

It is probably better, in general, to let the RMs decide on a freeze
date, and make special exceptions for packages that are stuck in NEW, if
they choose, rather than to keep pushing back the freeze.

Of course, depending on when the actual freeze occurs, and how quickly
NEW is processed (which seems to be going more quickly now), this point
may be completely moot anyways.

-- 
Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA   (Key available at wwwkeys.pgp.net)
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA

Re: Bug#392122: ITP: php-suhosin -- Suhosin is an advanced protection system for PHP installations.

[Luca Capello]

Hello!

On Tue, 10 Oct 2006 14:57:38 +0200, Jan Wagner wrote:
> * Package name: php-suhosin
>   Version : 0.9.6

There's already ITP #392119 [1] (cc:ing its submitter), I guess the
two should be merged.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392119


pgpmAKlhCXgvG.pgp
Description: PGP signature

Re: Bug#392122: ITP: php-suhosin -- Suhosin is an advanced protection system for PHP installations.

[Jan Wagner]

On Thursday 12 October 2006 14:52, Luca Capello wrote:
> There's already ITP #392119 [1] (cc:ing its submitter), I guess the
> two should be merged.

Since Alexander was quite faster, I'm closing this ITP.

With kind regards, Jan.
-- 
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GIT d-- s+: a- C+++ UL P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE
Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++
--END GEEK CODE BLOCK--


pgpEWGIPS0ULT.pgp
Description: PGP signature

Another option to reconfigure to avoid rejection on Alioth mailing lists.

[Charles Plessy]

Dear all,

In addition to "generic_nonmember_action" and
"require_explicit_destination" (in "Privacy options... / Sender filters"
and "Privacy options... / Recipient filters" respectively), I realised
today that there is another filter wich is on by default and can subject
mails to moderation on the mailing list hosted on Alioth, which are
increasingly being used a "Maintainer:" of packages.

At the bottom of the "General Options", there is "max_message_size",
which defaults to 40 kb. In my case, it sent a bug report with attached
files to the moderation queue, which is not good. Setting the value to
zero disables the filter.

Hope this helps,

-- 
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan


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

Re: Lack of a GR proposal explicitly condemning dunc-tank

[Ian Jackson]

Matthew Wilcox writes ("Re: Lack of a GR proposal explicitly condemning 
dunc-tank"):
> I'm so thoroughly disgusted by you and the actions of people like you
> that I've stopped working on Debian.  nice job, wanker.

That is the sole content of Matthew Wilcox's message to me, apart from
some quoted text from debian-private, which I have removed.

Normally I wouldn't publish private email but I think in this case the
abusive nature warrants it.

Ian.


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

Re: Lack of a GR proposal explicitly condemning dunc-tank

[Frans Pop]

On Thursday 12 October 2006 12:34, Ian Jackson wrote:
> Matthew Wilcox writes ("Re: Lack of a GR proposal explicitly condemning 
dunc-tank"):
> > I'm so thoroughly disgusted by you and the actions of people like you
> > that I've stopped working on Debian.  nice job, wanker.
>
> That is the sole content of Matthew Wilcox's message to me, apart from
> some quoted text from debian-private, which I have removed.
>
> Normally I wouldn't publish private email but I think in this case the
> abusive nature warrants it.

Well, if he really has stopped worked on Debian, he has a point doesn't 
he? Sorry, but I don't see why you felt the need to share this message.


pgpFkfHrzXUKK.pgp
Description: PGP signature

Re: Lack of a GR proposal explicitly condemning dunc-tank

[Russ Allbery]

Ian Jackson <[EMAIL PROTECTED]> writes:
> Matthew Wilcox writes:

>> I'm so thoroughly disgusted by you and the actions of people like you
>> that I've stopped working on Debian.  nice job, wanker.

> That is the sole content of Matthew Wilcox's message to me, apart from
> some quoted text from debian-private, which I have removed.

> Normally I wouldn't publish private email but I think in this case the
> abusive nature warrants it.

Two wrongs didn't really make a right here, IMO, and I'm not talking about
publication of private e-mail.  Losing one's temper and insulting one's
colleagues in e-mail isn't okay, but neither is deciding to escalate an
already angry situation by trying to humiliate someone in public for
losing their temper.  Nothing good is going to come from that.

I daresay nearly everyone here has lost their temper from time to time.
It's a lot easier to calm down and decide that there are more constructive
ways of expressing anger if the target of the anger takes a deep breath,
de-escalates, and provides room in which to make the discussion more
productive (or at least to let people stop talking to those with whom they
have strong clashes).

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Lack of a GR proposal explicitly condemning dunc-tank

[Frans Pop]

On Thursday 12 October 2006 18:50, Russ Allbery wrote:
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > Normally I wouldn't publish private email but I think in this case
> > the abusive nature warrants it.
>
> Two wrongs didn't really make a right here, IMO, and I'm not talking
> about publication of private e-mail.  Losing one's temper and insulting
> one's colleagues in e-mail isn't okay, but neither is deciding to
> escalate an already angry situation by trying to humiliate someone in
> public for losing their temper.  Nothing good is going to come from
> that.

Yes, and quietly ignoring an emotional private mail would help to prevent 
escalating anything; certainly more than posting it on a public mailing 
list does.


pgpOpOcB7x8Hj.pgp
Description: PGP signature

Processed: Re: Bug#392643: 'IFUP cannot open the file /etc/network/interfaces'

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 392643 general
Bug#392643: 'IFUP cannot open the file /etc/network/interfaces'
Warning: Unknown package 'on'
Warning: Unknown package 'startup'
Bug reassigned from package `' to `general'.

> --
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Making SELinux standard for etch

[Ian Jackson]

Mr Yan writes ("Re: Making SELinux standard for etch"):
> Ian Jackson wrote:
> > if (selinux_enabled > 0)
> >   if(setfscreatecon(NULL) < 0)
> > perror("Error restoring default security context:");
> > 
> > Error checking ?  We don't need no steenking error checking, this is
> > SECURITY software !  Quick, dump your brains and deploy it !
> 
> Without checking these functions for what they return its hard to say
> how bad this is, but it does look like its checking the return values
> for an error (albeit not doing anything other than printing a message).
> Without more context its impossible to say whether not resetting the
> default security context is bad or not.

Having the program carry on after it has failed to restore the default
security context is definitely bad.

Manoj Srivastava writes ("Re: Making SELinux standard for etch"):
> Assuming for an instant Ian may know what he is talking about,
>  could an example be given about what the so called missing error
>  checks are, by him or anyone else who knows what he is referring to?
>  How would people code this differently?

 if (selinux_enabled > 0)
   if(setfscreatecon(NULL) < 0)
 ohshite(_("Error restoring default security context"));

(I haven't read the manpage for setfscreatecon to check whether the
 `< 0' is right; I'll charitably assume it.)

But the answer here isn't to go through all of the selinux patches to
all of our programs and try to fix the bugs in them.  If the code is
buggy the concepts are likely to be buggy too.

Indeed, if you're willing to take my word as a computer security
expert[1] for it, I can say with confidence that selinux is not the
right approach to fixing the security problems with our systems.
It probably does more harm than good.

([1] I have a PhD in computer security from Cambridge University,
8 years' practical experience in the computer security industry, and a
similar period of experience as an author of Free security software.)

> So far, I think the criticism reflect more of a lack of
>  understanding of SELinux trhan anything else, but I would be happy if
>  someone could show me the error of my ways.

The selinux patch to dpkg contains several calls to setfscreatecon,
and in each case, if setfscreatecon fails, the code uses perror to
print a message to stderr and then carries on anyway.

> Since the default permissions are to deny all access, all it
>  means is that any special permissions accorded  by policy to the
>  package being installed would not be set by dpkg.  So the package may
>  not work in enforcing mode until the file system is relabelled; but
>  that is failing safe;

Not at all!  The package will be broken and the system unuseable.

Furthermore, the error abort is missing after _both_ the calls to set
file-specific contexts, and the calls to restore the default.  If
these calls fail, files in general might be created by dpkg or even by
its callees (postinst scripts, etc.) with inappropriate security
labels.

> if there are things wrong in the system that
>  dpkg can't set the initial file contexts for the packages being
>  installed, it is reasonable to assume that you might have to relable
>  your file system to recover from the error condition.

No, it is reasonable to assume that dpkg would fail during the
installation/upgrade so that you can correct the problem.

dpkg (unlike rpm!) doesn't carry on blithely when your disk is full or
when your filesystem is readonly; nor should it carry on blithely if
it can't set the security context in the way intended.

Unless, of course, this whose security context palaver isn't really
important.  In which case why are we contorting our code and
introducing dodgy and unstable libraries right at the bottom of our
software stack ?

Ian.


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

Re: Request for virtual package ircd

[John Goerzen]

On Thu, Oct 12, 2006 at 12:10:51AM +0200, Mario Iseli wrote:
> Hello,
> 
> as described in
> http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
> I announce here my idea of the virtual package ircd. When I count
> correctly are at the moment 7 different IRC-daemons in Debian and they
> logically conflict with each other. So I would think an official virtual

I don't think so.  If they all are listening on different parts, what's
the problem?  I'm concerned about going overboard with conflicts.

-- John


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

Orphaning most of my packages

[Steve Greenland]

The time is long since past to admit that I will *never* again have the
time to provide proper maintenance to my packages. Given the brief delay
in the freeze, hopefully someone can pick these up and get new versions
in with proper maintainers. 

I don't have time to provide sponsorship either; I will be around to
answer questions for the new maintainer, but you might wait a day or two
for a response (but usually more quickly than that.) I can provide a CVS
repo of the package history for all of these; send me an email (adopters
only, please).

I have submitted wnpp bugs for these; I've not uploaded versions with
the maintainer set to QA, I'll get around to that later(!) for any that
aren't adopted.

Bug#392665: O: nvi - 4.4BSD re-implementation of vi

Effectivley dead upstream. Needs some love for 8bit and unicode
handling.

Bug#392666: O: dgpsip -  Correct GPS location with DGPS signal from internet

Probably irrelevant now that selective availability is gone, but popcon
shows 32 installs, so maybe someone is actually using this. If noone
adopts, I'll ask for removal rather than re-assign to QA.


Bug#392671: O:  ee -  An "easy editor" for novices and compuphobics

Not dead upstream, but finished, I think.


Bug#392672: O: positron - synchronization manager for the Neuros Audio
Computer Python. Probably dead after v1.1. Pierre Habouzit has NMU'd a
version 1.1 upgrade and support for new python policy, see bug # 380895.


Regards,
Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: Making SELinux standard for etch

[Daniel Jacobowitz]

On Thu, Oct 12, 2006 at 02:12:54PM +0100, Ian Jackson wrote:
> Indeed, if you're willing to take my word as a computer security
> expert[1] for it, I can say with confidence that selinux is not the
> right approach to fixing the security problems with our systems.
> It probably does more harm than good.
> 
> ([1] I have a PhD in computer security from Cambridge University,
> 8 years' practical experience in the computer security industry, and a
> similar period of experience as an author of Free security software.)

Ian, why are you doing this?  You must surely know better by now.
Trying to pull you credentials isn't going to do you any good; SELinux
is developed by plenty of people with solid credentials, as I hope
you realize if you did even a cursory investigation.  All it does is
make you sound presumptuous.

It absolutely blows my mind that you can sit here and calmly assert
that a project as thoroughly designed and audited (and generally
respected) as SELinux is simply "more harm than good", whatever the
quality of the Debian-specific patches, and expect to be taken
seriously.

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: Request for virtual package ircd

[Jeremy Stanley]

On Thu, Oct 12, 2006 at 09:14:19AM +0200, Mario Iseli wrote:
> Ok, this is a good argument.
> I think the oppinion is more or less clear:
> 
> Some people think it would be a nice idea, BUT it can be also a problem
> because some people want more than one Ircd on a system.
> 
> I only wanted to ask you for your oppinion, so thank you all! :-)

Maybe what you're looking for is a "Provides: irc-server" in the
ircd packages and a "Recommends: irc-server" or "Suggests:
irc-server" in the service packages that potentially benefit from
(but do not necessarily require) a locally-installed ircd to which
to connect? That way when someone installs the services via, say,
aptitude or synaptic, an ircd is pulled in automatically (if one is
not already installed) or at least mentioned as being suggested, but
multiple ircd packages providing irc-server could still be installed
on the same system since there is no conflict expressed.
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }


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

Re: Orphaning most of my packages

[Jan C. Nordholz]

Hi,

> Bug#392665: O: nvi - 4.4BSD re-implementation of vi

I'll take nvi if no one objects.


Regards,

Jan


signature.asc
Description: Digital signature

Processed: Re: 'IFUP cannot open the file /etc/network/interfaces'

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 392643 ifupdown
Bug#392643: 'IFUP cannot open the file /etc/network/interfaces'
Bug reassigned from package `general' to `ifupdown'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: delay of the full etch freeze

[Petter Reinholdtsen]

[Charles Plessy]
> The rationale is that the 8th is "old freeze deadline minus 10
> days", so it was not completely unreasonnable to take this day as
> the deadline for having new packages in Etch.

I find this completely unreasonable.  If someone waited that late in
the release process before uploading a package they knew would have to
go through NEW, they can not expect the package to make it into Etch.
New packages should have had at least a few weeks in unstable to allow
problems to be detected before heading for testing.

So I would recommend against moving the freeze deadline to allow
packages in NEW to enter.

Besides, there is like 18000 binary packages in Etch already.  It is
not like we are short on packages in the next release. :)

Friendly,
-- 
Petter Reinholdtsen


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

Help offered

[HXC]

I would like to help with the debian.org website. I have a bachelor 
degree in communication management. Is there help needed and if so where 
do I start / who do I contact?


Grtz.

HXC


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

Re: Help offered 2 - opinion wanted about debian.org

[HXC]

HXC wrote:
I would like to help with the debian.org website. I have a bachelor 
degree in communication management. Is there help needed and if so 
where do I start / who do I contact?


Grtz.

HXC




I also wondered what the community finds about the colours and layout 
used for the website Does it need to be upgraded? Do find a new layout 
or other colours more appealing? If so what do you have in mind? Or do 
you think the current theme is just fine?



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

Re: Help offered

[Daniel Leidert]

HXC wrote:

> I would like to help with the debian.org website. I have a bachelor 
> degree in communication management. Is there help needed and if so where 
> do I start / who do I contact?

A starting point could be to send bug-reports against the www.debian.org 
(or similar: bugs.debian.org, lists.debian.org, ...) pseudo package(s): 
http://bugs.debian.org/www.debian.org

Regards, Daniel
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer


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

Re: Help offered

[Javier Fernández-Sanguino Peña]

On Fri, Oct 13, 2006 at 12:00:00AM +0200, Daniel Leidert wrote:
> HXC wrote:
> 
> > I would like to help with the debian.org website. I have a bachelor 
> > degree in communication management. Is there help needed and if so where 
> > do I start / who do I contact?
> 
> A starting point could be to send bug-reports against the www.debian.org 
> (or similar: bugs.debian.org, lists.debian.org, ...) pseudo package(s): 
> http://bugs.debian.org/www.debian.org

No need to file bugs, you can subscribe to the debian-www mailing list and
start throwing out ideas there and sparking discussion. Getting consensus on
future changes from the people involved in the website development is much
better than opening bugs IMHO.

Regards

Javier


signature.asc
Description: Digital signature

Re: Lack of a GR proposal explicitly condemning dunc-tank

[Ian Jackson]

I wrote:
> Normally I wouldn't publish private email but I think in this case the
> abusive nature warrants it.

It has been suggested that it would be better to include the context,
to avoid any potential or perceived unfairness, given that the context
was a debian-private posting by me.  So here is the whole of Matthew's
message, including the text of my message which he is objecting to:

  On Wed, Oct 11, 2006 at 02:17:50PM +0100, Ian Jackson wrote:
  > So I'd like to encourage dunc-tank opponents to consider whether they
  > ought to have seconded my resolution too.  There's still time to do so
  > I think.

  I'm so thoroughly disgusted by you and the actions of people like you
  that I've stopped working on Debian.  nice job, wanker.

Apparently taking the other side in this controversy is, in Matthew's
view, a justification for vitriol.

Ian.


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

Re: support of aoe devices and aoetools package

[David Martínez Moreno]

El miércoles, 11 de octubre de 2006 17:44, Warren Turkal escribió:
> Debian Developers,
>
> I hope this is the right forum to express this idea.
>
> I have not received any feedback from the maintainer of the aoetools
> package, so I wanted to voice my concerns over that package in front of a
> wider audience as I don't want to see the aoetools ship in the crappy form
> in which they now exist for Etch. I have sent many messages to bugs and
> received little to no correspondence from the maintainer.

Hello, Warren.  I am sorry for having faulty hardware at home and being 
almost unable to access my debian.org mail.  It seems that this situation is 
getting better, but I see that definitely I should have taken you seriously.

> First of all, the implementation aoetools include to enable mounting the
> aoe devices at boot time is severely lacking. This support was implemented
> in response to bug #387552 [1], which is now closed. They depend on a
> filesystem argument in fstab called _netdev, and they do not work with lvm

Argument that I extracted from S35mountall.sh and mount manpage...

I do not really know much about LVM and its shortcomings or requisites, 
and 
how it deals with networked volumes, but I am sure it is not as easy as you 
draw it.

> (or any other dev mapper based system) at all as far as I can tell. I
> contributed a new init script [2] that attempts to address these
> shortcomings while removing the need for the special fstab option. I
> submitted this info to bug #387552, but have received no response yet. I
> was tempted to reopen the bug, but I didn't think that'd be proper. I have
> also CCed the maintainer on all mailings to make sure that he got it.

As I replied in a former mail, your approach is simply broken.  You 
decided  
to unconditionally initialize network before stage 40, in fact, even before 
stage 35 (mountall), and with the first lines of your script being:

modprobe -r aoe
modprobe aoe

mount /usr

sleep 1

You are *not* taking care of _anyone_ having a different setting from 
yours.  
As I told you before, this kind of scripts are nice for your homegrown 
machines, but not for general use.

> I am basically writing here to see what I can do to at least get someone to
> look over the idea presented in the script to see if they think it would be
> a good idea. It is also frustrating to not receive any response when I
> clearly have a personal stake in this matter (that being that I have to
> support aoe based hardware).

I am sorry for not being much more responsive, really.  Apart from 
that, 
given that your first try to compose a working 11-1 aoetools release was not 
very 'careful' (bashisms, missing variables, and so on), and your second try 
to solve another problem on this matter was simply to mess with the init 
stages in runlevel S, you might understand that I did not make a lot of 
effort to reply to you in time.

If you want, we can forward this issue to the Debian Technical Comitee, 
where 
they will study this issue and make an official *technical* (non-emotional) 
report.  If they say so, I will accept to configure network interfaces before 
stage 40, but not before that.

Best regards,


Ender.
-- 
Network engineer
Debian Developer


pgp0LvaH8YS9F.pgp
Description: PGP signature

Setting Laguage

[Rodrigo Tavares]

Hello,

How I can to resolve it ?

debian-sarge:~/# debconf-getlang lang master po
debconf-getlang: This utility is deprecated; you
should switch to using the po-debconf package.
master: file or dictory not gound at
/usr/share/perl5/Debconf/Template.pm line 87.

Best regards,

Faria




___ 
Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. 
Registre seu aparelho agora! 
http://br.mobile.yahoo.com/mailalertas/ 
 


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

Re: delay of the full etch freeze

[Frans Pop]

On Thursday 12 October 2006 22:22, Petter Reinholdtsen wrote:
> So I would recommend against moving the freeze deadline to allow
> packages in NEW to enter.

I would guess for the most part package is  NEW are not totally new 
packages, but rather packages with a new upstream release that causes 
(minor?) ABI changes or e.g. changes in packaging because of licencing 
issues forcing _existing_ packages to go through NEW.
In those cases I can well understand maintainer's frustration if NEW 
processing suddenly takes weeks again after we all just got used to 
having NEW processed within days for a while.

Your point is valid, but I doubt it is valid for most packages currently 
waiting in NEW.

Cheers,
FJP


pgpk5KMLIhsFi.pgp
Description: PGP signature

Bug#392647: ITP: arpalert -- Used for monitoring arp changes in ethernet networks

[Jan Wagner]

Package: wnpp
Severity: wishlist
Owner: Jan Wagner <[EMAIL PROTECTED]>

* Package name: arpalert
  Version : 1.1.1 
  Upstream Author : Thierry Fournier <[EMAIL PROTECTED]>
* URL : http://www.arpalert.org
* License : GPL 2 or later
  Description : Used for monitoring arp changes in ethernet networks

 It listens on a network interface (without using 'promiscuous' mode)
 and catches all conversations of MAC address to IP request.
 It then compares the mac addresses it detected with a pre-configured
 list of authorized MAC addresses. If the MAC is not in list, arpalert
 launches a pre-defined user script with the MAC address and IP address
 as parameters.
 This software can run in daemon mode; it's very fast (low CPU and memory
 consumption).

-- System Information:
Debian Release: 3.1
Architecture: sparc (sparc64)
Kernel: Linux 2.4.27-3-sparc64
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: Request for virtual package ircd

[Joe Smith]

"Jeremy Stanley" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Thu, Oct 12, 2006 at 09:14:19AM +0200, Mario Iseli wrote:

Ok, this is a good argument.
I think the oppinion is more or less clear:

Some people think it would be a nice idea, BUT it can be also a problem
because some people want more than one Ircd on a system.

I only wanted to ask you for your oppinion, so thank you all! :-)


Maybe what you're looking for is a "Provides: irc-server" in the
ircd packages and a "Recommends: irc-server" or "Suggests:
irc-server" in the service packages that potentially benefit from
(but do not necessarily require) a locally-installed ircd to which
to connect? That way when someone installs the services via, say,
aptitude or synaptic, an ircd is pulled in automatically (if one is
not already installed) or at least mentioned as being suggested, but
multiple ircd packages providing irc-server could still be installed
on the same system since there is no conflict expressed.


That seems fine to me. Arguably, as mentioned in a different post the ftp
servers should do the smae thing instead of conflicting with each other.

Mail-tansport-agent should also do the same thing, using the alternatives
system to handle the multiple 'sendmail' binaries.

Conflicts on a virtual package by a package that provides it is generally 
questionable
because often these is no valid technical reason to restrict the user to 
only one of
the providers of that virtual package. 




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

Starting services in runlevels 0 and 6

[Jurij Smakov]

Greetings,

I've accidentally noticed that there are a few services which are 
*started* when entering runlevels 0 and 6 (halt and reboot, 
respectively). For example, on my mostly up-to-date sid system I have:

/etc/rc0.d/S30urandom
/etc/rc0.d/S35networking
/etc/rc0.d/S36ifupdown
/etc/rc0.d/S37sendsigs (start action for this one is a no-op)
/etc/rc0.d/S48cryptdisks 
/etc/rc0.d/S59cryptdisks-early

and similar stuff in /etc/rc6.d. I cannot find a rational explanation 
for starting services right before shutdown. Is it intentional, or are 
those just bugs?

Best regards,
-- 
Jurij Smakov   [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC


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

Re: Help offered 2 - opinion wanted about debian.org

[Luis Hidalgo]

Hi,

I personally dislike the colors of this particular website and I like
cooler colors. The problem is that, I think this way and many may think
alike (or not) but IMHO a color scheme is just too subjective to 
ask a person's opinion.-- Luis"All science is either physics or stamp collecting." - Ernest Rutherford

Bug#392643: 'IFUP cannot open the file /etc/network/interfaces'

[Petter Reinholdtsen]

reassign 392643 ifupdown
thanks

The message indicate that this might be a problem with the ifupdown
package.  Can you provide information about the version of ifupdown
you have installed (dpkg -l ifupdown).

Also, can you provide information about /etc/network?  Please run
these commands and attach the output:

  ls -ld /etc/network
  ls -l /etc/network/interfaces

I have no idea what can be the problem, but having more information
might provide some clue.

Friendly,
-- 
Petter Reinholdtsen


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

Re: Starting services in runlevels 0 and 6

[Jurij Smakov]

On Thu, Oct 12, 2006 at 07:34:19PM -0700, Jurij Smakov wrote:
> Greetings,
> 
> I've accidentally noticed that there are a few services which are 
> *started* when entering runlevels 0 and 6 (halt and reboot, 
> respectively). For example, on my mostly up-to-date sid system I have:
> 
> /etc/rc0.d/S30urandom
> /etc/rc0.d/S35networking
> /etc/rc0.d/S36ifupdown
> /etc/rc0.d/S37sendsigs (start action for this one is a no-op)
> /etc/rc0.d/S48cryptdisks 
> /etc/rc0.d/S59cryptdisks-early
> 
> and similar stuff in /etc/rc6.d. I cannot find a rational explanation 
> for starting services right before shutdown. Is it intentional, or are 
> those just bugs?

It was pointed out to me, that even the scripts starting with S are 
called with argument 'stop' for runlevels 0 and 6 by /etc/init.d/rc. 
However, the reason why it is implemented that way is still not clear.

Best regards,
-- 
Jurij Smakov   [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC


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

Re: Starting services in runlevels 0 and 6

[Henrique de Moraes Holschuh]

On Thu, 12 Oct 2006, Jurij Smakov wrote:
> It was pointed out to me, that even the scripts starting with S are 
> called with argument 'stop' for runlevels 0 and 6 by /etc/init.d/rc. 
> However, the reason why it is implemented that way is still not clear.

Braindamage inherited from SysV.

-- 
  "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: Lack of a GR proposal explicitly condemning dunc-tank

[Matthew Wilcox]

On Thu, Oct 12, 2006 at 05:34:01PM +0100, Ian Jackson wrote:
> I wrote:
> > Normally I wouldn't publish private email but I think in this case the
> > abusive nature warrants it.

It really doesn't.  Wanker.

> It has been suggested that it would be better to include the context,
> to avoid any potential or perceived unfairness, given that the context
> was a debian-private posting by me.  So here is the whole of Matthew's
> message, including the text of my message which he is objecting to:
> 
>   On Wed, Oct 11, 2006 at 02:17:50PM +0100, Ian Jackson wrote:
>   > So I'd like to encourage dunc-tank opponents to consider whether they
>   > ought to have seconded my resolution too.  There's still time to do so
>   > I think.
> 
>   I'm so thoroughly disgusted by you and the actions of people like you
>   that I've stopped working on Debian.  nice job, wanker.
> 
> Apparently taking the other side in this controversy is, in Matthew's
> view, a justification for vitriol.

Hey, Ian, you're trebly a wanker.  Thanks for confirming my decision.
I'm not going to explain my position as you'd only use it as an excuse
to debate me.  I am sick and fucking tired of the wankery coming from
the parts of the debian disorganisation who don't want anything to
change.  It makes me so fucking angry that I've decided to just stop
doing anything Debian related.

I'm tempted to propose expulsion for a whole bunch of people, except
that would involve dealing with Manoj, who I loathe.  So, in summary:

  ___
 / _|_   _  ___| | __  _   _  ___  _   _ 
| |_| | | |/ __| |/ / | | | |/ _ \| | | |
|  _| |_| | (__|   <  | |_| | (_) | |_| |
|_|  \__,_|\___|_|\_\  \__, |\___/ \__,_|
   |___/ 


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

Re: Orphaning most of my packages

[Anthony DeRobertis]

Steve Greenland wrote:
> Bug#392672: O: positron - synchronization manager for the Neuros Audio
> Computer Python. Probably dead after v1.1. Pierre Habouzit has NMU'd a
> version 1.1 upgrade and support for new python policy, see bug # 380895.
I can confirm that Positron is dead. Not only is it dead, it isn't
compatible with newer Neuros firmware. Sorune (Perl) and NDBM (Java) are
the two not-dead replacements.

I suggest removal.


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

Re: delay of the full etch freeze

[Steve Langasek]

On Thu, Oct 12, 2006 at 10:22:43PM +0200, Petter Reinholdtsen wrote:

> [Charles Plessy]
> > The rationale is that the 8th is "old freeze deadline minus 10
> > days", so it was not completely unreasonnable to take this day as
> > the deadline for having new packages in Etch.

> I find this completely unreasonable.  If someone waited that late in
> the release process before uploading a package they knew would have to
> go through NEW, they can not expect the package to make it into Etch.
> New packages should have had at least a few weeks in unstable to allow
> problems to be detected before heading for testing.

> So I would recommend against moving the freeze deadline to allow
> packages in NEW to enter.

Yes, this is my official position on the question (dunno about Andi's, I'm
replying to email off-line at the moment and haven't checked with him, but I
would guess his position is similar).

The only packages in NEW that I'm inclined to worry about are those that fix
release-critical bugs.

Thanks,
-- 
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/


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

Re: Request for virtual package ircd

[Steve Langasek]

On Thu, Oct 12, 2006 at 08:54:15AM +0200, Milan P. Stanic wrote:
> On Wed, Oct 11, 2006 at 06:34:41PM -0500, Ron Johnson wrote:
> > It's also possible to run multiple FTP servers, each listening on a
> > different port, but all the packaged ftp daemons "Conflicts:
> > ftp-server".

> That is bad, IMO. (and chance to raise my opinion about virtual
> packages ;) )

> Conflicts tag is used overmuch. Sometimes I want to have more than one
> ftp-server or mail-transport-agent installed but Conflicts tag does not
> allow that. I know that inexperienced user or admin have benefit from
> Conflicts (and some other tags) and virtual packages but experienced
> ones have problem with them.

m-t-a's must conflict because they are required by policy to provide a
sendmail program at a fixed filesystem location.

While it's possible that port conflicts were part of the original rationale
for m-t-a conflicts, this has definitely not been adhered to consistently in
Debian for other services, and I think there are enough use cases for
installing more than one daemon providing the same service that we /should
not/ attempt to apply such a rule for virtual packages.

-- 
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/


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

Re: delay of the full etch freeze

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Thu, Oct 12, 2006 at 10:22:43PM +0200, Petter Reinholdtsen wrote:
>
>> [Charles Plessy]
>> > The rationale is that the 8th is "old freeze deadline minus 10
>> > days", so it was not completely unreasonnable to take this day as
>> > the deadline for having new packages in Etch.
>
>> I find this completely unreasonable.  If someone waited that late in
>> the release process before uploading a package they knew would have to
>> go through NEW, they can not expect the package to make it into Etch.
>> New packages should have had at least a few weeks in unstable to allow
>> problems to be detected before heading for testing.
>
>> So I would recommend against moving the freeze deadline to allow
>> packages in NEW to enter.
>
> Yes, this is my official position on the question (dunno about Andi's, I'm
> replying to email off-line at the moment and haven't checked with him, but I
> would guess his position is similar).
>
> The only packages in NEW that I'm inclined to worry about are those that fix
> release-critical bugs.

I think this is unrealistic, because we cannot predict NEW's
behavior.  It doesn't follow that somebody "waited that late"; it may
well be instead that they did everything they could, and it was the
processing of NEW that waited a long time.

Sometimes packages require more than one trip through NEW, and the
release process cannot assume that people "waited that late" when it
was not they, but ftpmaster, that was waiting.

Thomas


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

Alas for lilypond in etch

[Thomas Bushnell BSG]

It seems that it is extremely unlikely that lilypond 2.8 will be in
etch.  We are still waiting on guile-1.8; the first upload took about
three weeks to get through the NEW queue and was then bounced by
ftpmaster because it contained a license problem.  It is now back in
the NEW queue, but it is not predictable when it will be in the
archive.

If someone can successfully build lilypond 2.8 with guile 1.6.8, then
I would rush to make things happen, but thus far, nobody has been able
to do so.  Please post an appropriate patch to the BTS.

Failing that, we can either remove lilypond 2.6 from etch, or not.  I
am happy to do what other people judge to be best, since nobody is
generally happy with my own decisions here.

Thomas


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

Re: support of aoe devices and aoetools package

[Warren Turkal]

On Thursday 12 October 2006 17:50, David Martínez Moreno wrote:
> El miércoles, 11 de octubre de 2006 17:44, Warren Turkal escribió:
> > First of all, the implementation aoetools include to enable mounting the
> > aoe devices at boot time is severely lacking. This support was
> > implemented in response to bug #387552 [1], which is now closed. They
> > depend on a filesystem argument in fstab called _netdev, and they do not
> > work with lvm
>
>   Argument that I extracted from S35mountall.sh and mount manpage...
>
>   I do not really know much about LVM and its shortcomings or requisites,
> and how it deals with networked volumes, but I am sure it is not as easy as
> you draw it.

Consider that it is not only a networked volume. It is also a network block 
device. You treat it something like an NFS mount in your implementation, 
which it is not what it is.

BTW, my script is loosely based on an example on the coraid support website 
(the only manufacturers of AOE devices that I am aware of) at [1].

> > (or any other dev mapper based system) at all as far as I can tell. I
> > contributed a new init script [2] that attempts to address these
> > shortcomings while removing the need for the special fstab option. I
> > submitted this info to bug #387552, but have received no response yet. I
> > was tempted to reopen the bug, but I didn't think that'd be proper. I
> > have also CCed the maintainer on all mailings to make sure that he got
> > it.
>
>   As I replied in a former mail, your approach is simply broken.

I didn't have any replies mentioning my implementation from you until a few 
hours ago. How was I supposed to know your reaction to it if you didn't even 
respond until today?

>   You 
> decided to unconditionally initialize network before stage 40, in fact,
> even before stage 35 (mountall), and with the first lines of your script
> being:
>
>   modprobe -r aoe
>   modprobe aoe
>
>   mount /usr
>
>   sleep 1

This script implemented the version for when the aoe tools were located 
in /usr. Also note that this script was a prototype. I was willing to put 
more time once I got some feedback from you. Instead I got a package bomb 
with an underfeatured implementation. If you don't like the unchecked 
interface activation

Also note, enabling the ethernet device doesn't enable the TCP/IP unless you 
assign an address. The reason for enabling the interfaces is to enable the 
aoe as block devices that can be used for lvm physical volumes.

>   You are *not* taking care of _anyone_ having a different setting from
> yours. As I told you before, this kind of scripts are nice for your
> homegrown machines, but not for general use.

Your script is not good for general use. You don't allow any more abstract 
uses of the block devices. You only allow laying a filesystem directly on 
them with no device manager stuff (lvm, evms, etc.) to manage it. My script 
was the beginning of a prototype implementation. If you had replied to it 
before now, maybe I would have known your objections in a reasonable time 
frame instead of being surprised by an implementation that I felt was 
lacking.

> > I am basically writing here to see what I can do to at least get someone
> > to look over the idea presented in the script to see if they think it
> > would be a good idea. It is also frustrating to not receive any response
> > when I clearly have a personal stake in this matter (that being that I
> > have to support aoe based hardware).
>
>   I am sorry for not being much more responsive, really.  Apart from that,
> given that your first try to compose a working 11-1 aoetools release was
> not very 'careful' (bashisms, missing variables, and so on), and your
> second try to solve another problem on this matter was simply to mess with
> the init stages in runlevel S, you might understand that I did not make a
> lot of effort to reply to you in time.

Thanks for finding the bashisms in the aoe-* scripts.

Maybe that lack of transparency led to this misunderstanding?

Your implementation is not any better. Releasing what you did without input of 
actual users who have a stake in its use is somewhat disheartening.

>   If you want, we can forward this issue to the Debian Technical Comitee,
> where they will study this issue and make an official *technical*
> (non-emotional) report.  If they say so, I will accept to configure network
> interfaces before stage 40, but not before that.

I don't think we need to bureaucracy of the tech committee. I would rather 
rationally present my functional requirements and see what kind of solution 
we can come to. However, without any kind of response until today, I didn't 
feel that was happening. Maybe now it can? Truce, please? I want to work with 
Debian and you. I was just very disappointed with the implementation and the 
response that I got when raising concerns about it. I didn't go immediately 
here. I waited 9 days with no response before I 

Re: delay of the full etch freeze

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Thu, Oct 12, 2006 at 10:22:43PM +0200, Petter Reinholdtsen wrote:
>
>> [Charles Plessy]
>> > The rationale is that the 8th is "old freeze deadline minus 10
>> > days", so it was not completely unreasonnable to take this day as
>> > the deadline for having new packages in Etch.
>
>> I find this completely unreasonable.  If someone waited that late in
>> the release process before uploading a package they knew would have to
>> go through NEW, they can not expect the package to make it into Etch.
>> New packages should have had at least a few weeks in unstable to allow
>> problems to be detected before heading for testing.
>
>> So I would recommend against moving the freeze deadline to allow
>> packages in NEW to enter.
>
> Yes, this is my official position on the question (dunno about Andi's, I'm
> replying to email off-line at the moment and haven't checked with him, but I
> would guess his position is similar).
>
> The only packages in NEW that I'm inclined to worry about are those that fix
> release-critical bugs.

Was there a reason this was not said when I asked:

http://lists.debian.org/debian-release/2006/09/msg00315.html

Thomas


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

Re: Making SELinux standard for etch

[Manoj Srivastava]

On Thu, 12 Oct 2006 14:12:54 +0100, Ian Jackson <[EMAIL PROTECTED]> said: 

> Mr Yan writes ("Re: Making SELinux standard for etch"):
>> Ian Jackson wrote:
>> > if (selinux_enabled > 0)
>> >   if(setfscreatecon(NULL) < 0)
>> > perror("Error restoring default security context:");
>> > 
>> > Error checking ?  We don't need no steenking error checking, this
>> > is SECURITY software !  Quick, dump your brains and deploy it !
>> 
>> Without checking these functions for what they return its hard to
>> say how bad this is, but it does look like its checking the return
>> values for an error (albeit not doing anything other than printing
>> a message).  Without more context its impossible to say whether not
>> resetting the default security context is bad or not.

> Having the program carry on after it has failed to restore the
> default security context is definitely bad.

And you base this statement on? Why are you disallowing the
 use cases where policy is allowed to temporarily go to seed and the
 ones where the system is not in enforcing mode? It is not dpkg's job
 to tell me in what mode I must run my machine.

The default policy being deny by default means we allow the
 install to go on, despite  the installed program not working in an
 enforcing context. This allows the software to be installed; and at a
 later stage the security

> Manoj Srivastava writes ("Re: Making SELinux standard for etch"):
>> Assuming for an instant Ian may know what he is talking about,
>> could an example be given about what the so called missing error
>> checks are, by him or anyone else who knows what he is referring
>> to?  How would people code this differently?

>  if (selinux_enabled > 0)
>if(setfscreatecon(NULL) < 0)
>  ohshite(_("Error restoring default security context"));

> (I haven't read the manpage for setfscreatecon to check whether the
>  `< 0' is right; I'll charitably assume it.)

> But the answer here isn't to go through all of the selinux patches
> to all of our programs and try to fix the bugs in them.  If the code
> is buggy the concepts are likely to be buggy too.

Strawman. You haven't yet uncovered a bug; you are going off
 based on self admitted incomplete information of what is going on
 based on faulty assumptions.  

> Indeed, if you're willing to take my word as a computer security
> expert[1] for it, I can say with confidence that selinux is not the
> right approach to fixing the security problems with our systems.  It
> probably does more harm than good.

That, based on me being a security expert and all, as well,
 and being around other security experts and all, sounds more
 like ignorance, really. So, no, I guess I am not going to just take
 your word for it.

> ([1] I have a PhD in computer security from Cambridge University, 8
> years' practical experience in the computer security industry, and a
> similar period of experience as an author of Free security
> software.)

I am sorry to hear that. This means that credentials like you
 are presenting don't mean squat when it comes to asserting knowledge
 about cutting edge security implementations.  This seems mostly hand
 waving and intimidating people by the letters after your name;
 unfortunately, it also shows that you have nothing concrete to back
 up your assertions. Show me a information flow analysis where you can
 demonstrate information leakage or a MLS constraint violation, and
 I'll listen to you. So far, every flow analysis I have run about
 installing some of the packages without the proper  initial file
 That it has failed to show leaks; all  that happens is that the
 program does not run in enforcing mode.

Frankly, if you are coming out saying that mandatory access
 controls, type enforcement, and multi-level security are  useless, I
 have trouble taking you seriously.

>> So far, I think the criticism reflect more of a lack of
>> understanding of SELinux trhan anything else, but I would be happy
>> if someone could show me the error of my ways.

> The selinux patch to dpkg contains several calls to setfscreatecon,
> and in each case, if setfscreatecon fails, the code uses perror to
> print a message to stderr and then carries on anyway.

Right. That is the design. as I have explained.

>> Since the default permissions are to deny all access, all it means
>> is that any special permissions accorded by policy to the package
>> being installed would not be set by dpkg.  So the package may not
>> work in enforcing mode until the file system is relabelled; but
>> that is failing safe;

> Not at all!  The package will be broken and the system unuseable.

In enforcing mode. The situations where setfscreatecon fails
 if that the system is not running in enforcing mode, and/or the file
 system is not relabeled correctly.  It is my opinion that since
 security s not compromised by the install going forward, we go ahead
 (allowing users to ru

Re: Request for virtual package ircd

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:

> m-t-a's must conflict because they are required by policy to provide a
> sendmail program at a fixed filesystem location.

I was about to say the same thing earlier, but then realized that we
*could* deal with that via alternatives.  And there's actually some appeal
to that in some very limited situations.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Work-needing packages report for Oct 13, 2006

[wnpp]

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

Total number of orphaned packages: 327 (new: 18)
Total number of packages offered up for adoption: 104 (new: 3)
Total number of packages requested help for: 34 (new: 1)

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



The following packages have been orphaned:

   bricolage (#392206), orphaned 2 days ago
 Description: full-featured, enterprise-class content management
   system
 Reverse Depends: bricolage bricolage-cms bricolage-queued
 Installations reported by Popcon: 10

   dgpsip (#392666), orphaned today
 Description: Correct GPS location with DGPS signal from internet
 Installations reported by Popcon: 32

   dlume (#391423), orphaned 6 days ago
 Description: handy and easy to use addressbook
 Installations reported by Popcon: 26

   ee (#392671), orphaned today
 Description: An "easy editor" for novices and compuphobics
 Installations reported by Popcon: 114

   fpm (#391419), orphaned 6 days ago
 Description: Secure password manager
 Installations reported by Popcon: 119

   gwget2 (#391407), orphaned 6 days ago
 Description: GNOME front-end for wget
 Reverse Depends: epiphany-extension-gwget
 Installations reported by Popcon: 460

   gxmms (#391415), orphaned 6 days ago
 Description: Simple GNOME applet to control the basic functions of
   XMMS
 Reverse Depends: gxmms-bmp gxmms-common gxmms-xmms
 Installations reported by Popcon: 192

   kipina (#391418), orphaned 6 days ago
 Description: training program to log physical activities of athletes
 Installations reported by Popcon: 27

   libadabindx (#392083), orphaned 2 days ago
 Description: Ada binding to the X Window System and *tif
 Reverse Depends: libadabindx-dev
 Installations reported by Popcon: 4

   libapache2-mod-layout (#392229), orphaned 2 days ago
 Installations reported by Popcon: 66

   libform-validator-ruby (#391416), orphaned 6 days ago
 Description: html form validation library for ruby
 Reverse Depends: libform-validator-ruby
 Installations reported by Popcon: 15

   libgtk-mozembed-ruby (#391399), orphaned 6 days ago
 Description: ruby 1.8 binding of GtkMozEmbed, gecko renderer
 Reverse Depends: geekast-binary ruby-gnome2
 Installations reported by Popcon: 43

   libgtk-trayicon-ruby (#391411), orphaned 6 days ago
 Description: system tray protocol library for Ruby
 Reverse Depends: geekast-binary libgtk-trayicon-ruby
 Installations reported by Popcon: 29

   libtermios-ruby (#391425), orphaned 6 days ago
 Description: termios simple wrapper for ruby
 Reverse Depends: libtermios-ruby
 Installations reported by Popcon: 30

   positron (#392672), orphaned today
 Description: synchronization manager for the Neuros Audio Computer
 Installations reported by Popcon: 23

   revolution (#391403), orphaned 6 days ago
 Description: revolution, ruby binding for the evolution mail client
 Reverse Depends: libevolution-ruby
 Installations reported by Popcon: 16

   sendemail (#391413), orphaned 6 days ago
 Description: email-from-console sending tool
 Installations reported by Popcon: 72

   wallpaper-tray (#391406), orphaned 6 days ago
 Description: wallpaper changing utility for GNOME
 Installations reported by Popcon: 151

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



The following packages have been given up for adoption:

   kdirstat (#392205), offered 2 days ago
 Description: graphical disk usage display with cleanup facilities
 Installations reported by Popcon: 380

   knoda (#392204), offered 2 days ago
 Description: graphical database frontend for KDE
 Reverse Depends: knoda libhk-kdeclasses7-dev
 Installations reported by Popcon: 238

   systemimager (#391473), offered 6 days ago
 Description: Automate GNU/Linux installs and upgrades over a network
 Reverse Depends: systemimager-client systemimager-server
   systemimager-server-flamethrowerd systeminstaller
 Installations reported by Popcon: 87

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



For the following packages help is requested:

[NEW] openscenegraph (#392266), requested 2 days ago
 Description: 3d scenegraph
 Reverse Depends: libopenalpp-cvs-dev libopenalpp-cvs1
   libopenscenegraph-dev libopenscenegraph4 libopenthreads-dev
   libosgal-cvs1 libproducer-dev libproducer4 openscenegraph

Re: Lack of a GR proposal explicitly condemning dunc-tank

[Manoj Srivastava]

On Thu, 12 Oct 2006 09:50:27 -0700, Russ Allbery <[EMAIL PROTECTED]> said: 

> Ian Jackson <[EMAIL PROTECTED]> writes:
>> Matthew Wilcox writes:

>>> I'm so thoroughly disgusted by you and the actions of people like
>>> you that I've stopped working on Debian.  nice job, wanker.

>> That is the sole content of Matthew Wilcox's message to me, apart
>> from some quoted text from debian-private, which I have removed.

>> Normally I wouldn't publish private email but I think in this case
>> the abusive nature warrants it.

> Two wrongs didn't really make a right here, IMO, and I'm not talking
> about publication of private e-mail.  Losing one's temper and
> insulting one's colleagues in e-mail isn't okay, but neither is
> deciding to escalate an already angry situation by trying to
> humiliate someone in public for losing their temper.  Nothing good
> is going to come from that.

In my experience, turning the other cheek ends up in getting
 two smarting cheeks and little else. There has to be _some_
 disincentive for people initiating and perpetuating such overt abuse;
 some negative conditioning so that they don't spew off quite so
 unrestrainedly in the future.

Could you suggest what form this negative conditioning should
 take?

manoj
-- 
Ninety percent of everything is crap. Theodore Sturgeon
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Lack of a GR proposal explicitly condemning dunc-tank

[Manoj Srivastava]

On Thu, 12 Oct 2006 15:25:46 -0600, Matthew Wilcox <[EMAIL PROTECTED]> said: 

> I'm tempted to propose expulsion for a whole bunch of people, except
> that would involve dealing with Manoj, who I loathe.

Wow.

> So, in summary:
>   ___
>  / _|_   _  ___| | __  _   _  ___  _   _ 
> | |_| | | |/ __| |/ / | | | |/ _ \| | | |
> |  _| |_| | (__|   <  | |_| | (_) | |_| |
> |_|  \__,_|\___|_|\_\  \__, |\___/ \__,_|
>|___/ 


Wow.

> It makes me so fucking angry that I've decided to just stop doing
> anything Debian related.

Yay?

manoj
-- 
I saw Lassie.  It took me four shows to figure out why the hairy kid
never spoke. I mean, he could roll over and all that, but did that
deserve a series?
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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