Re: Accepted fam 2.7.0-8 (source i386)

[Chuan-kai Lin]

On Mon, Aug 29, 2005 at 08:09:06AM +0200, Aurelien Jarno wrote:
> Chuan-kai Lin a ?crit :
> >   * Make libfam0 Provides libfam0c102
> I am afraid you can't do that. libfamc2 does NOT provide
> the same interface as libfam, so they are both incompatible.

It turns out that the published public interface of libfam as specified
in fam(3) is purely in C (that is, C++ is used only internally), so
libfam remains binary compatible across the g++ ABI change.  This
observation was pointed out to me only very recently, otherwise maybe we
could have avoided the package name change altogether.

See http://lists.debian.org/debian-release/2005/08/msg00090.html for
discussions related to this change.

-- 
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/


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

Re: a place for a package directory in root

[sean finney]

On Sun, Aug 28, 2005 at 09:26:16PM +0100, Roger Leigh wrote:
> sean finney <[EMAIL PROTECTED]> writes:
> > On Sat, Aug 27, 2005 at 12:53:09PM -0700, Steve Langasek wrote:
> >> /run/bootchart, but there seems to be some resistance to actually trying to
> >> standardize on /run :)
> >
> > what about /dev/shm?
> 
> /dev/shm is an implementation detail of POSIX shared memory support by
> the Linux kernel.  See POSIX 1003.1 (2001)
> http://www.cnop.net/docs/susv3/functions/shm_open.html (or download
> from www.unix.org).

didn't know about that, thanks for the reference.

> Some packages chose to place random junk in there (e.g. resolvconf).
> This is wrong.  This location is for (and *only* for) file-backed
> shared memory storage, otherwise there is potential for namespace
> clashes, and it's totally disgusting.
> 
> The fact that it's useful for other things should be an indication
> that we need another tmpfs mount, mounted elsewhere, rather than
> abusing a location intended for a specific, unrelated, use.

so it's a choice between abusing a pre-existing location but standards
specified for another use, or using a non-existing location with no
standards whatsover.  can't say i really like either option.  more
specifically because both are not addressed in policy/fhs, i'd be worried
about an in-flow of non-standard, first-come-first-serve namespace
usage.


sean


signature.asc
Description: Digital signature

Re: a place for a package directory in root

[Steve Langasek]

On Sat, Aug 27, 2005 at 06:32:26PM -0400, sean finney wrote:
> On Sat, Aug 27, 2005 at 12:53:09PM -0700, Steve Langasek wrote:
> > /run/bootchart, but there seems to be some resistance to actually trying to
> > standardize on /run :)

> what about /dev/shm?

Aside from the other objections voiced that it abuses that namespace, I
also object to it because it inappropriately ties the required feature
(early availability of read-write space for data that doesn't persist
across reboots) to a particular implementation, instead of leaving the
admin free to structure the mounts in a way that's most appropriate for
the system.

-- 
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: Unnecessary "Conflicts" with imap-server packages

[Gerrit Pape]

On Thu, Aug 25, 2005 at 01:04:28PM +1000, Brian May wrote:
> > "Gerrit" == Gerrit Pape <[EMAIL PROTECTED]> writes:
> Gerrit>  Gerrit> bincimap-run package provides the virtual package
> Gerrit> ``imap-server'' and conflicts with other packages
> Gerrit> providing ``imap-server''.  This ensures that bincimap is
> Gerrit> the only service that listens on the address 0.0.0.0:993
> Gerrit> on a system, and also satisfies packages that depend on a
> Gerrit> running imap service.  The bincimap package without the
> Gerrit> bincimap-run package can be installed alongside other
> Gerrit> imap-server packages on a system, e.g. to provide
> Gerrit> different imap or imaps services on different addresses
> Gerrit> simultaneously.
> 
> So are you suggesting that every imap-server (for example) should be
> split into two packages?
> 
> Taken a step further this would include every server where multiple
> implementations exist.

I suggest to split all packages providing service(s) into one package
containing the programs, documentation, examples, and one package
setting up the default service(s) to be run automatically.  See these
threads

 http://lists.debian.org/debian-devel/2004/04/msg00080.html
 http://lists.debian.org/debian-devel/2004/02/msg01390.html

I'm doing this for nearly all of the packages I maintain since years,
works just fine.

> Is this really a good idea?

Yes, why not?  It solves the OP's problem; it lets you install packages
that provide a service without enabling the service automatically; it
uses the dpkg dependency facility to show or solve conflicts; it adds
flexibility, and avoids unnecessary conflicts.

You might say it blows up the Packages file.  Well, yes, but I don't
think the scalability problem with the number of packages included in
Debian should stop us developing good design choices, or adding new good
quality packages to Debian.  I'm confident the problem will be solved
technically some day.

Regards, Gerrit.
-- 
Open projects at http://smarden.org/pape/.


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

Re: a place for a package directory in root

[Peter Samuelson]

[Steve Langasek]
> [use of /dev/shm] inappropriately ties the required feature (early
> availability of read-write space for data that doesn't persist across
> reboots) to a particular implementation, instead of leaving the admin
> free to structure the mounts in a way that's most appropriate for the
> system.

Well, this *is* early boot he's talking about.  mountvirtfs.sh has not
been run yet, /etc/fstab lies disregarded.  The admin only has so much
control over where /run is mounted from at this stage of the game.

I still support a tmpfs /run, but not because it gives the admin any
particular control.


signature.asc
Description: Digital signature

Re: incoming

[Adeodato Simó]

* martin f krafft [Mon, 29 Aug 2005 02:37:18 +0200]:

> also sprach Roger Leigh <[EMAIL PROTECTED]> [2005.08.29.0219 +0200]:
> > > is there a reponsible person for cleaning up the cadavers in
> > > incoming? If yes, could you you please do so? Don't found a severity
> > > for that in the BTS.

> > > The oldest entry is from
> > > oops_1.5.19.cvs.20010818-0.1woody1_ia64.changes 20-May-2005 04:32

> > You could upload a .commands file.  See the README in incoming.

> Correct me if I am wrong, but .commands files are for the upload
> queue, not for incoming. I don't think this will work.

  I confirm this is correct.

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol


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

Re: Unnecessary "Conflicts" with imap-server packages

[Hamish Moffatt]

On Mon, Aug 29, 2005 at 07:55:31AM +, Gerrit Pape wrote:
> On Thu, Aug 25, 2005 at 01:04:28PM +1000, Brian May wrote:
> > So are you suggesting that every imap-server (for example) should be
> > split into two packages?
> > 
> > Taken a step further this would include every server where multiple
> > implementations exist.
> 
> I suggest to split all packages providing service(s) into one package
> containing the programs, documentation, examples, and one package
> setting up the default service(s) to be run automatically.  See these
> threads
> 
>  http://lists.debian.org/debian-devel/2004/04/msg00080.html
>  http://lists.debian.org/debian-devel/2004/02/msg01390.html
> 
> I'm doing this for nearly all of the packages I maintain since years,
> works just fine.

You can José Fonseca (esmtp) seem to be the only ones.

> > Is this really a good idea?
> 
> Yes, why not?  It solves the OP's problem; it lets you install packages
> that provide a service without enabling the service automatically; it
> uses the dpkg dependency facility to show or solve conflicts; it adds
> flexibility, and avoids unnecessary conflicts.
> 
> You might say it blows up the Packages file.  Well, yes, but I don't
> think the scalability problem with the number of packages included in
> Debian should stop us developing good design choices, or adding new good
> quality packages to Debian.  I'm confident the problem will be solved
> technically some day.

It's solved now - edit configuration files! It's not essential that
everything can be configured by adding/removing packages.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Accepted fam 2.7.0-8 (source i386)

[Adeodato Simó]

* Aurelien Jarno [Mon, 29 Aug 2005 08:09:06 +0200]:

> >Changes: 
> > fam (2.7.0-8) unstable; urgency=low
> > .
> >   * Acknowledge NMU (closes: #317700, #317839)
> >   * Make libfam0 Provides libfam0c102

> I am afraid you can't do that. libfamc2 does NOT provide
> the same interface as libfam, so they are both incompatible.

Small story:

  I'm sitting next to Isaac Clerencia, and he just said to me re this
  thread: "if it had been you who made the upload, Aurelien wouldn't
  have asked this question". And I went like, "Huh, why?", and he
  answered, "Because you're oh-so-verbose in changelogs".

  And well, he has a point. Putting in the changelog, when appropriate,
  the _reasoning_ behind a change is as useful as the change itself. So
  I'd like to encourage maintainers to think, when describing an
  important change, "is there something else I could/should mention
  here?"

  Changelog entries that make other developers go like, "huh, wtf?", and
  force them to investigate a bit are, IMHO, a bad thing.

  Cheers,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Algebraic symbols are used when you do not know what you are talking about.
-- Philippe Schnoebelen


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

Bug#325539: ITP: polyglot -- is a chess engine protocol adaptor. It connects a UCI protocol engine to xboard frontend.

[Oliver Korff]

Package: wnpp
Severity: wishlist
Owner: Oliver Korff <[EMAIL PROTECTED]>


* Package name: polyglot
  Version : 1.3
  Upstream Author : Fabien Letouzey, <[EMAIL PROTECTED]>
* URL : http://wbec-ridderkerk.nl/
* License : (GPL)
  Description : is a chess engine protocol adaptor. It connects a UCI 
protocol engine to xboard frontend.

 is a chess engine protocol adaptor. It connects a UCI protocol engine to 
xboard frontend.
 Common chess frontends have a winboard/xboard input interface, modern
 chess engines speak the UCI "universal chess interface" protocol. This
 protocol adaptor makes it possilble to use standard chess frontends,
 like xboard or scid with UCI speaking engines and play chess against
 them.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.9-1-686-smp
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: Unnecessary "Conflicts" with imap-server packages

[Olaf van der Spek]

On 8/29/05, Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 29, 2005 at 07:55:31AM +, Gerrit Pape wrote:
> > On Thu, Aug 25, 2005 at 01:04:28PM +1000, Brian May wrote:
> > > So are you suggesting that every imap-server (for example) should be
> > > split into two packages?
> > >
> > > Taken a step further this would include every server where multiple
> > > implementations exist.
> >
> > I suggest to split all packages providing service(s) into one package
> > containing the programs, documentation, examples, and one package
> > setting up the default service(s) to be run automatically.  See these
> > threads
> >
> >  http://lists.debian.org/debian-devel/2004/04/msg00080.html
> >  http://lists.debian.org/debian-devel/2004/02/msg01390.html
> >
> > I'm doing this for nearly all of the packages I maintain since years,
> > works just fine.
> 
> You can José Fonseca (esmtp) seem to be the only ones.
> 
> > > Is this really a good idea?
> >
> > Yes, why not?  It solves the OP's problem; it lets you install packages
> > that provide a service without enabling the service automatically; it
> > uses the dpkg dependency facility to show or solve conflicts; it adds
> > flexibility, and avoids unnecessary conflicts.
> >
> > You might say it blows up the Packages file.  Well, yes, but I don't
> > think the scalability problem with the number of packages included in
> > Debian should stop us developing good design choices, or adding new good
> > quality packages to Debian.  I'm confident the problem will be solved
> > technically some day.
> 
> It's solved now - edit configuration files! It's not essential that
> everything can be configured by adding/removing packages.

It's not solved.
There are still daemons that conflict with eachother 'just' because
they wish to listen on the same port or use the same directories (by
default).

Re: Unnecessary "Conflicts" with imap-server packages

[Gerrit Pape]

On Mon, Aug 29, 2005 at 07:06:34PM +1000, Hamish Moffatt wrote:
> On Mon, Aug 29, 2005 at 07:55:31AM +, Gerrit Pape wrote:
> > > Is this really a good idea?
> > 
> > Yes, why not?  It solves the OP's problem; it lets you install packages
> > that provide a service without enabling the service automatically; it
> > uses the dpkg dependency facility to show or solve conflicts; it adds
> > flexibility, and avoids unnecessary conflicts.
> > 
> > You might say it blows up the Packages file.  Well, yes, but I don't
> > think the scalability problem with the number of packages included in
> > Debian should stop us developing good design choices, or adding new good
> > quality packages to Debian.  I'm confident the problem will be solved
> > technically some day.
> 
> It's solved now - edit configuration files! It's not essential that
> everything can be configured by adding/removing packages.

It's not essential to have everything configured through configuration
files.  I haven't heard any reason yet why splitting the packages would
be a bad thing.

And there's more advantages: it eases usage of different service
managers than sysvinit and init scripts, support of a different init
scheme can be done through an alternative package which 'provides' the
default *-run package; same for services running under a superserver,
and corresponding alternatives; it plays well with fully automated
installs; it separates services from programs.

Regards, Gerrit.
-- 
Open projects at http://smarden.org/pape/.


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

Re: Unnecessary "Conflicts" with imap-server packages

[Fabio Tranchitella]

Il giorno lun, 29/08/2005 alle 12.16 +0200, Olaf van der Spek ha
scritto:
> It's not solved.
> There are still daemons that conflict with eachother 'just' because
> they wish to listen on the same port or use the same directories (by
> default).

Which makes no sense, and I think this is an abuse of Conflicts field.
Having a package installed doesn't mean the corresponding service is
started.

Cheers,

-- 
Fabio Tranchitella <[EMAIL PROTECTED]>.''`.
Proud Debian GNU/Linux developer, admin and user.: :'  :
 `. `'`
   http://people.debian.org/~kobold/   `-
_
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564


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

Re: incoming

[Noèl Köthe]

Am Montag, den 29.08.2005, 00:51 +0200 schrieb Nico Golde:

> > is there a reponsible person for cleaning up the cadavers in
> > incoming? If yes, could you you please do so? Don't found a severity
> > for that in the BTS.

> Mail to the ftpmasters team.

Already done but as usual without any respond.:(
http://lists.debian.org/debian-devel/2005/08/msg00500.html


-- 
Noèl Köthe 
Debian GNU/Linux, www.debian.org


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

Re: a place for a package directory in root

[Joerg Sommer]

Hello Goswin,

Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Joerg Sommer <[EMAIL PROTECTED]> writes:
>> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>>> Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
>>>
>> What about /run/? Can a new package simply use/create /run? I would add
>> /run to the directories of the package and mount a tmpfs there at
>> startup. Is this alright?
>
> Do it and get enough things to use it. Then there is no stopping you.

Well, I add /run/ to the directories of my package and mount a tmpfs
there on startup. But I leave it mounted after exit, because I don't know
if someone else use it.

Any objections?

Have a nice day, Jörg.

PS: Don't Cc me. I read the list.
-- 
Gienger's Law (http://www.bruhaha.de/laws.html):
Die Wichtigkeit eines Newspostings im Usenet ist reziprok zur Anzahl der
enthaltenenen, kumulierten Ausrufungszeichen.


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

Re: Unnecessary "Conflicts" with imap-server packages

[Hamish Moffatt]

On Mon, Aug 29, 2005 at 10:29:20AM +, Gerrit Pape wrote:
> On Mon, Aug 29, 2005 at 07:06:34PM +1000, Hamish Moffatt wrote:
> > On Mon, Aug 29, 2005 at 07:55:31AM +, Gerrit Pape wrote:
> > > quality packages to Debian.  I'm confident the problem will be solved
> > > technically some day.
> > 
> > It's solved now - edit configuration files! It's not essential that
> > everything can be configured by adding/removing packages.
> 
> It's not essential to have everything configured through configuration
> files.  

Perhaps not, but it is the traditional approach on UNIX.

> files.  I haven't heard any reason yet why splitting the packages would
> be a bad thing.
> 
> And there's more advantages: it eases usage of different service
> managers than sysvinit and init scripts, support of a different init
> scheme can be done through an alternative package which 'provides' the
> default *-run package; same for services running under a superserver,
> and corresponding alternatives; it plays well with fully automated
> installs; it separates services from programs.

These problems should be solved by discussion and generation of a
policy. IMHO it would be better to have a consistent approach that
didn't solve every problem (or had some other flaw) than to have
each individual developer generate their own scheme.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

Hi.  I'd like to get in contact with someone who would be interested
in creating and supporting Debian packages for my Kerberos 5
implementation, and its related GSS-API library.  Web pages are
available at:

http://www.gnu.org/software/shishi/
http://www.gnu.org/software/gss/

Shishi and GSS can be used by GNU SASL, GNU Mailutils, Fetchmail, Curl
and maybe other projects.

It would be good if you are familiar with MIT Kerberos or Heimdal in
general, and their Debian packages in particular.

One advantage with my Kerberos 5 implementation compared to
MIT/Heimdal is that it support Kerberos 5 over TLS, which means that
you can use X.509 or (work in progress) OpenPGP keys, rather than
passwords to get a Kerberos ticket.

Thanks,
Simon


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Steinar H. Gunderson]

On Mon, Aug 29, 2005 at 03:43:43PM +0200, Simon Josefsson wrote:
> One advantage with my Kerberos 5 implementation compared to
> MIT/Heimdal is that it support Kerberos 5 over TLS, which means that
> you can use X.509 or (work in progress) OpenPGP keys, rather than
> passwords to get a Kerberos ticket.

Oooh, that's neat. Will this work with, say, an OpenPGP smart card as
well?

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: RFS: libssh - SSH and SCP library

[Jean-Philippe Garcia Ballester]

Hi,

> > > You will probably want to look at the following code:
> > > 
> > > gnutls:libextra/gnutls_openssl.c
> > >   This code is incomplete, but does most of the things
> > 
> > The part that misses is the part I need :( (ie PEM_read_DSAPrivateKey
> > and PEM_read_RSAPrivateKey)
> 
> Considering they should be really necessary for decent crypto; 
> I would dig up code from the existing ssh implementations.

By using libcrypto code and websites, I managed to rewrite the code that
was missing. Hope I didn't do this to ugly.
I updated my packages (deb http://dgnr.free.fr/ repository/)
So I ask for RFS again, if nobody complains about it.
Regards,

-- 
Jean-Philippe Garcia Ballester


signature.asc
Description: Digital signature

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:

> On Mon, Aug 29, 2005 at 03:43:43PM +0200, Simon Josefsson wrote:
>> One advantage with my Kerberos 5 implementation compared to
>> MIT/Heimdal is that it support Kerberos 5 over TLS, which means that
>> you can use X.509 or (work in progress) OpenPGP keys, rather than
>> passwords to get a Kerberos ticket.
>
> Oooh, that's neat. Will this work with, say, an OpenPGP smart card as
> well?

Yes, that is the intention, and I'm currently working on that.  Werner
Koch jas sent me a few smart cards and a reader, so I'm playing with
this setup.

Regards,
Simon


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

Re: Unnecessary "Conflicts" with imap-server packages

[Bob Proulx]

Fabio Tranchitella wrote:
> Having a package installed doesn't mean the corresponding service is
> started.

If I install something then I want it installed, configured and
running.

I think you are asking for another type of action for APT.  Currently
APT has two types of remove.  You can remove leaving configuration
files or you can purge taking off the configuration files too.  I
think you are asking for a new type of install target where a package
is only partially installed.  I could see the utility of that but
there is no support for it in the code at this moment.

Bob


signature.asc
Description: Digital signature

Stocks discovered for quick profit kegful

[cammie Norfleet]

cackled

Hot Oil Pick Of The Week- ORTE

We have uncovered a diamond here, ORTE is
on the move for strong continued success.
We are recommending it to all of our readers
this week. With experts saying oil can reach
five dollars per gallon by the end of the
year, the oil industry is in strong demand
more than ever before. This is why we are
recommending ORTE now, this one will sky
rocket easily, get it immediately.

*Company: Oretech, Inc.
*Symb0l: ORTE . Pk
*Current-Price: . 53
*52 Wk High:  1. 60
*3 to 4 Day target: 1. 10+
*6 months taeget: 2. 30+

Company Inside News:

Oretech Announces Positive Test Results Extracting
Oil from Tar Sands.

Oretech, Inc. announced today that the company has
recently completed test processing on tar sands from
the Athabasca region of Alberta, Canada. Preliminary
results indicate the extraction of oil is apparently
a higher percentage than that which is extracted by
conventional methods, while remaining extremely
environmentally friendly. The API gravity of the
bitumen (oil) is significantly upgraded during the
extraction process.
 
Alberta's tar sands comprise one of the world's two
largest sources of bitumen; the other is in Venezuela.
These oil reserves are second only to Saudi Arabia,
and are found only in three places in Alberta -- the
Athabasca, Peace River and Cold Lake regions -- covering
a total of nearly 140,800 square kilometers. These tar
sands currently represent 54 per cent of Alberta's total
oil production, and about one-third of all the oil
produced in Canada. Output of marketable tar sands
production increased to 858,000 barrels per day
(bbl/d) in 2003, up from 741,000 bbl/d the year
before. It is anticipated that in 2005, Alberta's
tar sands production may account for one-half of
Canada's total crude output and 10 per cent of
North American production. 

Oretech, Inc. has developed a proof of concept model
that represents a breakthrough in oil extraction from
Tar Sand processing technology. Its business model
is to be a leading edge developer and licensor of
proprietary innovative technology that reduces the
cost of extraction of noble metals (Gold / Silver
/ Platinum / Titanium) and energy resources (Oil
Extraction from Tar Sand and Shale). Focusing on
reducing pollution of the environment, Oretech
is known for its breakthrough materials processing
technology, which extracts specific minerals from
diverse feedstock and raw materials without the
use of harmful chemicals or the emission of
environmentally unsafe gases. frontier

snow imponderable


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

Re: Unnecessary "Conflicts" with imap-server packages

[Fabio Tranchitella]

On lun, 29 ago 2005, Bob Proulx wrote:
> Fabio Tranchitella wrote:
> > Having a package installed doesn't mean the corresponding service is
> > started.
> 
> If I install something then I want it installed, configured and
> running.
> 
> I think you are asking for another type of action for APT.  Currently
> APT has two types of remove.  You can remove leaving configuration
> files or you can purge taking off the configuration files too.  I
> think you are asking for a new type of install target where a package
> is only partially installed.  I could see the utility of that but
> there is no support for it in the code at this moment.

No, I meant that if I have to switch my mail server from $imapserver1 to
$imapserver2, I would prefer to have both imapservers fully installed and 
running, for example on two different ports. There is no need for them to 
conflicts one with each other, this is annoying and I think it is an abuse 
of the Conflicts field, which in my opinion means "you can't install both 
packages because (for example) they installs the same files" and not 
"you can't install both packages because it is not common to have both 
installed, even if it is possible".

-- 
Fabio Tranchitella <[EMAIL PROTECTED]>.''`.
Proud Debian GNU/Linux developer, admin and user.: :'  :
 `. `'`
   http://people.debian.org/~kobold/   `-
_
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564


signature.asc
Description: Digital signature

Re: Unnecessary "Conflicts" with imap-server packages

[sean finney]

On Mon, Aug 29, 2005 at 09:15:36AM -0600, Bob Proulx wrote:
> Fabio Tranchitella wrote:
> > Having a package installed doesn't mean the corresponding service is
> > started.
> 
> If I install something then I want it installed, configured and
> running.

but you are not all users.  

> I think you are asking for another type of action for APT.  Currently
> APT has two types of remove.  You can remove leaving configuration
> files or you can purge taking off the configuration files too.  I
> think you are asking for a new type of install target where a package
> is only partially installed.  I could see the utility of that but
> there is no support for it in the code at this moment.

no, he was simply stating that there are cases where you want to install
a daemon, but not have it startup and run by default (or in other
cases with non-default options).  for example, maybe i want to install
multiple imap daemons because some users require a specific feature
from one and others from another.  as an admin why shouldn't i be able
to have both installed and configured to run on alternate ports?

the idea that one protocol server conflicts with another simply because
it refuses to be on a system where it might not be the one that
gets the default port is... well... dumb.

the appropriate response would be to have the postinst script be
unaffected by whether or not the service fails to start.  if you
want to be extra helpful you could try and detect for a failure and
spit out a warning, or even better provide a clean way to determine the
behaviour of the daemon when the package is installed.


sean


-- 


signature.asc
Description: Digital signature

unsubscribe

[Martin Kelly]

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

Re: Documentation of alioth?

[Branden Robinson / Debian Project Leader]

[Gack, what a nasty CC line.  Is all that really necessary?]

On Fri, Aug 26, 2005 at 12:23:14PM +0200, Raphaël Hertzog wrote:
> Le vendredi 26 août 2005 à 12:04 +0200, Martin Schulze a écrit :
> > Hi Raphaël,
> 
> Hi Joey,
> 
> > I'm sorry, but I have to tell you that you're wrong in your assertion.
> 
> I've been corrected by Wiggy on IRC too. Although what I said before was
> not invented, I've read part of it in #debian-devel in the mouth of
> Overfiend (Branden)...

Eh?  What exactly did I say?

> It looks like the actual problem is more lack of donors and the fact
> that Branden is not willing to spend money on it.

Actually, I was contacted just very recently by a potential hardware donor
that should have some pretty reasonable iron at its disposal.

I don't rule out cash expenditures on hardware in general, but when we're
seeking entire machines, I'd rather exhaust donation opportunties first.
As far as I can tell, they haven't yet been exhausted.  When we just need
parts, the main thing I need is a proposal that enumerates what is to be
purchased and includes a cost breakdown (or at least a bottom-line figure
including taxes and shipping costs).

I don't categorically rule anything out in the case of an emergency.  It's
been my impression that the situation with alioth is uncomfortable as
opposed to emergent.

> Maybe a brief status of the "hardware donations" people would be nice ?

Yes, I'd love to see such a report myself.  :)

> > Also DSA does not have anything to do with ftpmaster work.  The
> > ftpmaster people organise themselves on their own.

Well, in theory, when a task crosses a lane of responsibility from
ftpmaster to DSA and back, these people do actually communicate with each
other.

(I *did* say "in theory"...)

-- 
G. Branden Robinson
Debian Project Leader
[EMAIL PROTECTED]
http://people.debian.org/~branden/


signature.asc
Description: Digital signature

Re: Documentation of alioth?

[Raphaël Hertzog]

Le lundi 29 août 2005 à 11:42 -0500, Branden Robinson / Debian Project
Leader a écrit :
> > I've been corrected by Wiggy on IRC too. Although what I said before was
> > not invented, I've read part of it in #debian-devel in the mouth of
> > Overfiend (Branden)...
> 
> Eh?  What exactly did I say?

 wiggy: if anyone from d-a is responding to any of the offers
they're getting, they're not CCing me.
 And we all know how much good it will do if I cheerfully
accept hardware that d-a refuses to touch.

> > It looks like the actual problem is more lack of donors and the fact
> > that Branden is not willing to spend money on it.
> 
> Actually, I was contacted just very recently by a potential hardware donor
> that should have some pretty reasonable iron at its disposal.
> 
> I don't rule out cash expenditures on hardware in general, but when we're
> seeking entire machines, I'd rather exhaust donation opportunties first.

I have no problem with that but we should also avoid waiting for ever
when the donor doesn't come.

I hope the issue will be solved until the end of the year. :-)

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Any reason why libmotif3 vanished for Sparc

[Andreas Metzler]

Andreas Tille <[EMAIL PROTECTED]> wrote:
> I just noticed that libmotif3 vanished for Sparc architecture from the
> non-free archive.
[...]
> I know that it was there formerly because I once got it without any extra
> lines in my sources.list file.  Now the Sparc port can be found at

>http://ftp.unixdev.net/pub/debian-udev/pool/non-free/o/openmotif/

This is a version with security issues.

> but I wonder what might be the reason to drop this single archive from the
> non-free mirrors?

Hello,
Iirc there's a security-related bug in the version in etch and the
missing binary on sparc blocked migration of the fixed package.

libmotif3 is non-free and not-autobuilt, it requires somebody with
access to a sparc machine to build it manually. Sadly this seems to be
made difficult by a FTBFS on sparc, http://bugs.debian.org/323798
cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


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

Re: Bug#325539: ITP: polyglot -- is a chess engine protocol adaptor. It connects a UCI protocol engine to xboard frontend.

[Neil Schemenauer]

I think this is a little better:

Description: a UCI to xboard chess engine protocol adaptor.

polyglot connects a UCI protocol chess engine to xboard frontend.
Common chess frontends have a winboard/xboard input interface, modern
chess engines speak the UCI "universal chess interface" protocol. This
protocol adaptor makes it possilble to use standard chess frontends,
like xboard or scid with UCI speaking engines and play chess against
them.

Cheers,

  Neil


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

Version tracking in the BTS

[Florian Weimer]

Could someone who is familiar with the new BTS have a look at #324167,
please?

The BTS has corectly record this data:

  Found in version openvpn/2.0-1;
  Fixed in version openvpn/2.0.2-1 

2.0-1 is the sarge version, but the report has been closed
nevertheless.

Is it still necessary to manually reopen all security bugs which have
been fixed in a new upload to unstable, but are also present in the
stable distribution?


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

Re: Version tracking in the BTS

[martin f krafft]

also sprach Florian Weimer <[EMAIL PROTECTED]> [2005.08.29.1957 +0200]:
> 2.0-1 is the sarge version, but the report has been closed
> nevertheless.

That's all good and well. It still shows up as outstanding when you
apply the sarge filter:

  
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=openvpn&archive=no&version=&dist=stable

-- 
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
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"if ever somethin' don't feel right to you, remember what pancho said
 to the cisco kid...  `let's went, before we are dancing at the end of
 a rope, without music.'"
 -- sailor


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

Re: Unnecessary "Conflicts" with imap-server packages

[John Hasler]

Perhaps we need some sort of a "weakly conflicts".  Sort of the inverse of
"recommends".
-- 
John Hasler


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Russ Allbery]

Simon Josefsson <[EMAIL PROTECTED]> writes:

> Hi.  I'd like to get in contact with someone who would be interested in
> creating and supporting Debian packages for my Kerberos 5
> implementation, and its related GSS-API library.  Web pages are
> available at:

> http://www.gnu.org/software/shishi/
> http://www.gnu.org/software/gss/

> Shishi and GSS can be used by GNU SASL, GNU Mailutils, Fetchmail, Curl
> and maybe other projects.

I *might* be interested in this, although I'm fairly busy at the moment.
But I certainly have a strong interest in good Kerberos implementations
and have a lot of experience with the existing packages.

I'd be very interested in making sure that it can co-exist with MIT
Kerberos on the same system, since I can't really switch away from MIT
Kerberos for my own personal use, but I'd want to have it installed to be
able to easily test.

Certainly, if multiple people are interested in working on this, I'd be
glad to be part of a maintainer team.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Version tracking in the BTS

[Florian Weimer]

* martin f. krafft:

> also sprach Florian Weimer <[EMAIL PROTECTED]> [2005.08.29.1957 +0200]:
>> 2.0-1 is the sarge version, but the report has been closed
>> nevertheless.
>
> That's all good and well. It still shows up as outstanding when you
> apply the sarge filter:
>
>   
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=openvpn&archive=no&version=&dist=stable

Would it be possible to include such information in the bug-specific
page as well, or at least a link to obtain it?

The summarized output with the sarge filter is somewhat confusing as
well:

| Outstanding bugs -- Grave; Unclassified (1 bug)
| 
| * #324167: OpenVPN 2.0-1 vulnerabilities
|   Package: openvpn (openvpn 2.0-1; fixed: openvpn 2.0.2-1);
| Severity: grave; Reported by: Daniel Lehmann <[EMAIL PROTECTED]>;
| Tags: fixed-upstream, security
|   Done: Alberto Gonzalez Iniesta <[EMAIL PROTECTED]>;
| Will be archived in 28 days. 

Does this mean that the bug will be archived even though it's not
fixed in sarge?


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

Re: Version tracking in the BTS

[Frans Pop]

On Monday 29 August 2005 20:12, martin f krafft wrote:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=openvpn&archive=no&version=&dist=stable

What is "Unclassified" all about?


pgp7ADUQqwFW9.pgp
Description: PGP signature

Re: Version tracking in the BTS

[Mark Brown]

On Mon, Aug 29, 2005 at 08:22:32PM +0200, Frans Pop wrote:
> On Monday 29 August 2005 20:12, martin f krafft wrote:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=openvpn&archive=no&version=&dist=stable

> What is "Unclassified" all about?

No tags that it chooses to use for classification.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: Version tracking in the BTS

[Florian Weimer]

* Mark Brown:

> On Mon, Aug 29, 2005 at 08:22:32PM +0200, Frans Pop wrote:
>> On Monday 29 August 2005 20:12, martin f krafft wrote:
>> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=openvpn&archive=no&version=&dist=stable
>
>> What is "Unclassified" all about?
>
> No tags that it chooses to use for classification.

Which tags are used for classification? sarge et al.?  Would it make
sense to tag a bug "sarge" if it is reported against the version in
sarge (even though this is technically incorrect)?


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

Re: Version tracking in the BTS

[martin f krafft]

also sprach Frans Pop <[EMAIL PROTECTED]> [2005.08.29.2022 +0200]:
> What is "Unclassified" all about?

These classes reflect the tags on the bugs therein.

  "Patched"
  "More information needed"
  "Will not fix"
  ...

I am not sure what happens when there's a +patch+wontfix.

-- 
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
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
micro$oft windows psychic edition:
we will tell you where you are going tomorrow.


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

Re: Accepted fam 2.7.0-8 (source i386)

[Chuan-kai Lin]

Russ Allbery <[EMAIL PROTECTED]> wrote:
>> For more information see:
>> http://lists.debian.org/debian-devel-announce/2005/07/msg7.html
> This reference doesn't help with the question of libraries that use
> C++ internally but don't expose a C++ interface.

You are absolutely right about that.  However, like vorlon, I had
trouble remembering where the original discussion took place, so I
supplied this link instead.

If you inspect libfam.so.0.0.0 with readelf, you will see that it
technically does export some C++ symbols.  However, since none of those
symbols are documented as part of the fam API, changes in those symbols
should be pretty harmless.

-- 
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/


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

Re: Version tracking in the BTS

[martin f krafft]

also sprach Florian Weimer <[EMAIL PROTECTED]> [2005.08.29.2028 +0200]:
> Which tags are used for classification? sarge et al.?  Would it make
> sense to tag a bug "sarge" if it is reported against the version in
> sarge (even though this is technically incorrect)?

Please read the announcement about the new meaning of these tags:

  http://lists.debian.org/debian-devel-announce/2005/07/msg00010.html

-- 
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
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"i've got a bike,
 you can ride it if you like,
 it's got a basket. a bell that rings, and things to make it look good.
 i'd give it to you if i could,
 but i borrowed it."
  -- syd barrett, 1967


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

Re: Accepted fam 2.7.0-8 (source i386)

[Chuan-kai Lin]

Adeodato Sim? <[EMAIL PROTECTED]> wrote:
>  Changelog entries that make other developers go like, "huh, wtf?",
>  and force them to investigate a bit are, IMHO, a bad thing.

Message received loud and clear.

-- 
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/


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

Re: Version tracking in the BTS

[Florian Weimer]

* martin f. krafft:

> also sprach Florian Weimer <[EMAIL PROTECTED]> [2005.08.29.2028 +0200]:
>> Which tags are used for classification? sarge et al.?  Would it make
>> sense to tag a bug "sarge" if it is reported against the version in
>> sarge (even though this is technically incorrect)?
>
> Please read the announcement about the new meaning of these tags:
>
>   http://lists.debian.org/debian-devel-announce/2005/07/msg00010.html

Oh, this seems to imply that security bugs must be tagged sarge
manually, otherwise the bug will soon disappear from the radar
screen. 8-(

Is it acceptable if this tag is set by non-maintainers?


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

Re: Version tracking in the BTS

[Andreas Barth]

* Florian Weimer ([EMAIL PROTECTED]) [050829 20:39]:
> Oh, this seems to imply that security bugs must be tagged sarge
> manually, otherwise the bug will soon disappear from the radar
> screen. 8-(
> 
> Is it acceptable if this tag is set by non-maintainers?

yes.


Cheers,
Andi


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

Re: Version tracking in the BTS

[Frans Pop]

On Monday 29 August 2005 20:31, martin f krafft wrote:
> also sprach Frans Pop <[EMAIL PROTECTED]> [2005.08.29.2022 +0200]:
> These classes reflect the tags on the bugs therein.
>   "Patched"
>   "More information needed"
>   "Will not fix"
>   ...

Hmm. IMO listing bugs without those tags as "Unclassified" is confusing, 
especially with the emphasis that is now put on it. It implies that 
action is required where I think that is not always the case.

Also I don't think that "Patched" as a description for tag 'patch' is 
correct. The bug has not been patched, there just is a _proposed_ patch 
available. There is no certainty that the patch is either correct or will 
be accepted by the maintainer.
I would sooner accept a description of "Patched" for 'pending'.

What do others think of the new, extended subdivision of bugs?
Personally I don't see enough difference in status between "unclassified" 
and "moreinfo" to warrant separating them.


pgp3ZmAokPhlI.pgp
Description: PGP signature

Re: Version tracking in the BTS

[Florian Weimer]

* Frans Pop:

> Hmm. IMO listing bugs without those tags as "Unclassified" is confusing, 
> especially with the emphasis that is now put on it. It implies that 
> action is required where I think that is not always the case.

A public page listing only "unclassified" bugs also suggests that
there are private, "classified" bugs.  We know that this
interpretation is wrong, but a cursory reader might not.


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

Re: Version tracking in the BTS

[Mark Brown]

On Mon, Aug 29, 2005 at 08:50:24PM +0200, Frans Pop wrote:

> What do others think of the new, extended subdivision of bugs?

In general more control of the sorting would be nicer.  Right now
there's an awful lot of categories which I'm finding makes bug listings
a lot more cluttered without adding sufficiently useful information.  I
think this is just that the classification chosen by the BTS isn't quite
what I'm looking for but what I'm looking for is likely to change based
on what I'm doing.

I'm not sure separating out the confirmed tag is such a useful thing,
especially given that it sorts so far up.  Given the use of tags it'd
also seem logical to sort the upstream tag and the forwarded bugs
together.

A way to for a maintainer separate out bug reports that they've not much
intention of doing anything with in the immediate future would be
something I'd personally like to see.

> Personally I don't see enough difference in status between "unclassified" 
> and "moreinfo" to warrant separating them.

I do find that one makes some sense - it separates out bugs where the
maintainer is less likely to be able to do anything about.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: incoming

[Elimar Riesebieter]

On Mon, 29 Aug 2005 the mental interface of
Nico Golde told:

[...]
> Mail to the ftpmasters team.
Thread start forwarded.
Elimar

-- 
  Never make anything simple and efficient when a way 
  can be found to make it complex and wonderful ;-)


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

les bons achats de forfaits d'info tourisme

[info tourisme]

(Mailing List Information, including unsubscription instructions, 
is located at the end of this message.)
__ 

English below   

Alpine Inn *** 3 etoiles Sainte-Adele
Speciaux de fin de saison pour une periode limitée :

Forfait 1 : Une nuit, deux repas 59,99 p/pers.

Forfait 2 :  Une nuit deux repas un massage 99,99 p/pers.(recu d’assurance 
60.00 par pers)

Forfait 3 : Deux nuits quatres repas 114,99 p/pers. 3ieme nuit au prix coutant !

Forfait 4 : Deux nuits quatres repas un massage 159,99 p/pers.(recu d’assurance 
60.00 par pers) 3ieme nuit au prix coutant !

Leger supplement le Samedi,   
Informez vous au 1-877-257-4630  
www.hotelalpine.com

Hotel Alpine Inn *** 3 stars
End of the season specials for a very limited period only

Package#1  One night two meals 59,99 per pers

Package#2  One night two meals one body massage 99,99 per pers (insurance 
receipt 60.00 p/pers)

Package #3  Two nights 4 meals 114,99 per pers 3rd night at cost price

Package #4  Two nights 4 meals one body massage 159,99 per pers (insurance 
receipt 60.00 p/pers)
 3rd night at cost price

Extra charge for Saturdays
Call us today toll free 1-877-257-4630



-- 
The following information is a reminder of your current mailing
list subscription: 

You are subscribed to the following list: 
info tourisme

Using the following email:
debian-devel@lists.debian.org

You may automatically unsubscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 

[EMAIL PROTECTED]


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

Re: Unnecessary "Conflicts" with imap-server packages

[Roberto C. Sanchez]

On Mon, Aug 29, 2005 at 09:15:36AM -0600, Bob Proulx wrote:
> Fabio Tranchitella wrote:
> > Having a package installed doesn't mean the corresponding service is
> > started.
> 
> If I install something then I want it installed, configured and
> running.
> 

I'm sorry, but I think this is completely wrong.  Take a look at horde3
and its associated packages.  There are far too many options to have it
completely configured and ready to go right after an `apt-get install`.
Believe me, I tried to get Ola to use debconf to ask all the required
questions, but he managed to convince me that it was a bad idea.

I am sure that there are other packages that fall into this category.

-Roberto

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


pgp0uxf08rlzg.pgp
Description: PGP signature

Re: a place for a package directory in root

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

sean finney <[EMAIL PROTECTED]> writes:

> On Sun, Aug 28, 2005 at 09:26:16PM +0100, Roger Leigh wrote:
>> sean finney <[EMAIL PROTECTED]> writes:

>> Some packages chose to place random junk in there (e.g. resolvconf).
>> This is wrong.  This location is for (and *only* for) file-backed
>> shared memory storage, otherwise there is potential for namespace
>> clashes, and it's totally disgusting.
>> 
>> The fact that it's useful for other things should be an indication
>> that we need another tmpfs mount, mounted elsewhere, rather than
>> abusing a location intended for a specific, unrelated, use.
>
> so it's a choice between abusing a pre-existing location but standards
> specified for another use, or using a non-existing location with no
> standards whatsover.  can't say i really like either option.  more
> specifically because both are not addressed in policy/fhs, i'd be worried
> about an in-flow of non-standard, first-come-first-serve namespace
> usage.

In this case, it looks like we should standardise on something like
/run.  Has this been brought up with the FHS/LSB folks?  This sounds
like something other distributions will also need to tackle, so if it
gets standardised, so much the better.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFDE28wVcFcaSW/uEgRAgC5AKCuXQMCDqO+2V/lemhMv4xE+H7r3wCfYEZt
jVnRh6bDSaiZQS41FyySZhE=
=MilK
-END PGP SIGNATURE-


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

Re: incoming

[Elimar Riesebieter]

On Mon, 29 Aug 2005 the mental interface of
Elimar Riesebieter told:

> Hi all,
> 
> is there a reponsible person for cleaning up the cadavers in
> incoming? If yes, could you you please do so? Don't found a severity
> for that in the BTS.
> 
> The oldest entry is from
> oops_1.5.19.cvs.20010818-0.1woody1_ia64.changes 20-May-2005 04:32

$ lynx -dump incoming.debian.org | tail -1
 196. http://incoming.debian.org/zlib_1.2.2-4.sarge.2_s390.changes

Is that the new Debian cemetery ;-)

This is after upload. The youngest entry at the moment is Report.

Elimar


-- 
  Never make anything simple and efficient when a way 
  can be found to make it complex and wonderful ;-)


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

Re: incoming

[Steve Langasek]

On Mon, Aug 29, 2005 at 10:37:19PM +0200, Elimar Riesebieter wrote:
> On Mon, 29 Aug 2005 the mental interface of
> Elimar Riesebieter told:

> > is there a reponsible person for cleaning up the cadavers in
> > incoming? If yes, could you you please do so? Don't found a severity
> > for that in the BTS.

> > The oldest entry is from
> > oops_1.5.19.cvs.20010818-0.1woody1_ia64.changes 20-May-2005 04:32

> $ lynx -dump incoming.debian.org | tail -1
>  196. http://incoming.debian.org/zlib_1.2.2-4.sarge.2_s390.changes

That's a bug in how dak currently attempts to back-propagate packages
from stable-security to testing-proposed-updates and unstable.

Other packages may have gotten stuck for other reasons.

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

info tourisme Mailing List Confirmation

[info tourisme]

This message has been sent to you as the final step to confirm your
email *removal* for the following list: 

info tourisme

To confirm this unsubscription, please follow the below URL:



(Click the URL above or, copy and paste the URL into your browser)

Doing so will *remove* you to this list. 

---

The following is the description given for this list: 

[EMAIL PROTECTED]

---

This double opt-out confirmation email was sent to protect the privacy
of the owner of this email address. 

Furthermore, the following privacy policy is associated with this list: 

[EMAIL PROTECTED]

Please read and understand this privacy policy. 

If you did not asked to be removed from this particular list, please
do not visit the confirmation URL above. The confirmation for 
removal will not go through and no other action on your part 
will be needed.

To contact the owner of this email list, please use the below address: 



The following physical address is associated with this mailing list: 

[EMAIL PROTECTED]


- 


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

info tourisme Mailing List Confirmation

[info tourisme]

This message has been sent to you as the final step to confirm your
email *removal* for the following list: 

info tourisme

To confirm this unsubscription, please follow the below URL:



(Click the URL above or, copy and paste the URL into your browser)

Doing so will *remove* you to this list. 

---

The following is the description given for this list: 

[EMAIL PROTECTED]

---

This double opt-out confirmation email was sent to protect the privacy
of the owner of this email address. 

Furthermore, the following privacy policy is associated with this list: 

[EMAIL PROTECTED]

Please read and understand this privacy policy. 

If you did not asked to be removed from this particular list, please
do not visit the confirmation URL above. The confirmation for 
removal will not go through and no other action on your part 
will be needed.

To contact the owner of this email list, please use the below address: 



The following physical address is associated with this mailing list: 

[EMAIL PROTECTED]


- 


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

Re: a place for a package directory in root

[Jim Crilly]

On 08/29/05 03:32:55AM -0500, Peter Samuelson wrote:
> 
> [Steve Langasek]
> > [use of /dev/shm] inappropriately ties the required feature (early
> > availability of read-write space for data that doesn't persist across
> > reboots) to a particular implementation, instead of leaving the admin
> > free to structure the mounts in a way that's most appropriate for the
> > system.
> 
> Well, this *is* early boot he's talking about.  mountvirtfs.sh has not
> been run yet, /etc/fstab lies disregarded.  The admin only has so much
> control over where /run is mounted from at this stage of the game.

As long as this is mounted and run via an initrd/initramfs image then
control over the script should be fine. The admin should be able to edit
either a config file or script under /etc/mkinitrd and regenerate the
image. If the locations are going to be hard coded into the init
replacement,  then there's really no choice.

> 
> I still support a tmpfs /run, but not because it gives the admin any
> particular control.

Jim.


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

info tourisme Unsubscription

[info tourisme]

The removal of the email address:

debian-devel@lists.debian.org

>From the mailing list: 

info tourisme 

is all set.

Date of this removal: Mon Aug 29 17:32:35 2005

Please save this email message for future reference.

---

You may automatically subscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 

[EMAIL PROTECTED]

- 



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

Re: Version tracking in the BTS

[Hamish Moffatt]

On Mon, Aug 29, 2005 at 08:50:24PM +0200, Frans Pop wrote:
> What do others think of the new, extended subdivision of bugs?
> Personally I don't see enough difference in status between "unclassified" 
> and "moreinfo" to warrant separating them.

Generally I think it's quite useful. However, and slightly off the
topic, how did we end up with "Done bugs"? "Resolved bugs" reads well but
done does not. "Closed" would also work, if you want to use a term that
is an exact BTS command.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Bug#325371: ITP: binfmtc -- a binfmt_misc hook for running C programs as scripts

[Junichi Uekawa]

Hi,

> > Are you sure? http://fabrice.bellard.free.fr/tcc/ claims it produces
> > optimized x86 code, which could be a problem on other archs.
> 
> TCC does some simple local optimizations (AIUI, some peephole
> optimization, and simple intra-statement linear register allocation),
> but calling it an "optimizing" compiler in the GCC sense would be too much.
> 
> The TCC architecture would require significant changes if one wanted to
> make it a true optimizing compiler.
> 
> However, TCC-compiled code is likely much faster than anything that the
> interpreters (Python, Perl) produce from equivalent code.

tcc has a very different scope to binfmtc in that it tries to be 
a compiler.

binfmtc is just an interface, and currently supports 
c, c++, java, assembler, fortran and pascal; and can be 
extended if the language can have a compiled
output in a sane way (I'm currently eyeing bison; flex looks a bit 
difficult).

Considering that there doesn't seem to be a similar project, 
I'm going to upload the package.



regards,
junichi
-- 
Junichi Uekawa, Debian Developer   http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5  CE82 D837 7D4E E81E 55C1 


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

Re: a place for a package directory in root

[Joerg Sommer]

Hi Roger,

Roger Leigh <[EMAIL PROTECTED]> wrote:
>
> In this case, it looks like we should standardise on something like
> /run.  Has this been brought up with the FHS/LSB folks?  This sounds
> like something other distributions will also need to tackle, so if it
> gets standardised, so much the better.

Who is responsible in Debian for such things? Has Debian a FHS group?

Bye, Jörg.
-- 
Es ist außerdem ein weit verbreiteter Irrtum das USENET "helfen" soll.
Tatsächlich wurde USENET nachweislich zur persönlichen Belustigung
seiner Erfinder geschaffen.
Jörg Klemenz <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>


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

Re: Bruce Perens hosts party at OSCON Wednesday night

[Miles Bader]

Russell Coker <[EMAIL PROTECTED]> writes:
>> Non-UBE "commercial" email doesn't seem to be a problem on this list, so
>
> It is a big problem.

No it's not.  Are we reading the same list?

-miles
-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.


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

Re: arch, svn, cvs

[Miles Bader]

martin f krafft <[EMAIL PROTECTED]> writes:
> When we speak about arch these days, we mean baz.

Except of course, when we don't...

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]


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

Re: Version tracking in the BTS

[Anthony Towns]

On Mon, Aug 29, 2005 at 08:50:24PM +0200, Frans Pop wrote:
> Also I don't think that "Patched" as a description for tag 'patch' is 
> correct. The bug has not been patched, there just is a _proposed_ patch 
> available. There is no certainty that the patch is either correct or will 
> be accepted by the maintainer.

If it's known to be incorrect or the maintainer's not going to accept
it, the patch tag isn't appropriate:

A patch or some other easy procedure for fixing the bug is included
in the bug logs. If there's a patch, but it doesn't resolve the bug
adequately or causes some other problems, this tag should not be
used.

> What do others think of the new, extended subdivision of bugs?
> Personally I don't see enough difference in status between "unclassified" 
> and "moreinfo" to warrant separating them.

The idea is that a maintainer can divide bugs by the actions needed:

* patch: apply the patch, build, test, upload
* moreinfo: no action -- waiting for more info
* wontfix: no action -- won't fix anyway
* unclassified: reproduce, analyse, come up with solutions
* confirmed: analyse, come up with solutions

Bugs tagged "help", "unreproducible", and "upstream" aren't separated
out from unclassified at the moment; maybe "confirmed" shouldn't be
split from unclassified.

Thanks for the polite feedback, it's appreciated.

For those who preferred the bugs not broken up, visit

http://bugs.debian.org/cgi-bin/cookies.cgi?oldview=yes

Cheers,
aj



signature.asc
Description: Digital signature

Re: Version tracking in the BTS

[Anthony Towns]

On Mon, Aug 29, 2005 at 08:16:36PM +0200, Florian Weimer wrote:
> Would it be possible to include such information in the bug-specific
> page as well, or at least a link to obtain it?

Well, anything's possible. The versioning checks are somewhat slow and
cumbersome at the moment; so they're only done when /specifically/
requested, which is only possible for pkgreport listings atm. I guess
what you mean is you'd like something like:

* Bug applies to testing only!

somewhere obvious in the bugreport page.

> | Outstanding bugs -- Grave; Unclassified (1 bug)
> | * #324167: OpenVPN 2.0-1 vulnerabilities
> |   Package: openvpn (openvpn 2.0-1; fixed: openvpn 2.0.2-1);
> | Severity: grave; Reported by: Daniel Lehmann <[EMAIL PROTECTED]>;
> | Tags: fixed-upstream, security
> |   Done: Alberto Gonzalez Iniesta <[EMAIL PROTECTED]>;
> | Will be archived in 28 days. 
> Does this mean that the bug will be archived even though it's not
> fixed in sarge?

Hrm. Yes it does, and yes you should manually tag it +sarge if you
don't want that behaviour.

Technically, that can be changed -- expiry isn't actually reimplemented
yet; and I guess it wouldn't be impossible to say "don't expire bugs
that are open in stable and have either  or  tags".

I'd kind-of hope it wouldn't be an issue in practice -- security bugs
that're fixed in unstable ought to have the fix for stable uplaoded
within 28 days anyway, shouldn't they?

Cheers,
aj


signature.asc
Description: Digital signature

Re: Version tracking in the BTS

[Thomas Bushnell BSG]

martin f krafft <[EMAIL PROTECTED]> writes:

> also sprach Florian Weimer <[EMAIL PROTECTED]> [2005.08.29.2028 +0200]:
>> Which tags are used for classification? sarge et al.?  Would it make
>> sense to tag a bug "sarge" if it is reported against the version in
>> sarge (even though this is technically incorrect)?
>
> Please read the announcement about the new meaning of these tags:
>
>   http://lists.debian.org/debian-devel-announce/2005/07/msg00010.html

How about adding documentation to the bugs.debian.org webpage?  I
don't normally read through debian-devel-announce when looking for
documentation. 

Thomas


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

Regalos para este 18 Septiembre

[Bull]

Title: ofertas para este 18 septiembre





SI NO PUEDE VER ESTE CORREO POR FAVOR PRESIONE AQUÍ ( 
DAR TU DIRECCION DE BAJA DE ESTA PROMOCION )Acatando la nueva Ley 
del Consumidor Nº 19.496 y su modificación Nº 19.955 del 2004,en su Artículo 
28b, donde regula el envío de correos electrónicos("Toda comunicación 
promocional o publicitaria enviada por correo electrónico deberá indicar la 
materia o asunto sobre el que versa, la identidad del remitente y contener una 
dirección válida a la que el destinatario solicite la suspensión de los 
envíos")

Re: Version tracking in the BTS

[martin f krafft]

also sprach Thomas Bushnell BSG <[EMAIL PROTECTED]> [2005.08.30.0729 +0200]:
> How about adding documentation to the bugs.debian.org webpage?

How about a patch? Writing the documentation yourself has the added
benefit that you won't need it in the future anymore.

-- 
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
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"of course the music is a great difficulty.
 you see, if one plays good music, people don't listen,
 and if one plays bad music people don't talk."
-- oscar wilde


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

Re: Version tracking in the BTS

[Steve Langasek]

On Tue, Aug 30, 2005 at 05:43:52AM +1000, Anthony Towns wrote:

> I'd kind-of hope it wouldn't be an issue in practice -- security bugs
> that're fixed in unstable ought to have the fix for stable uplaoded
> within 28 days anyway, shouldn't they?

Well, there's the mozilla packages, for one example where this hasn't
been the case in practice.  I would rather not have security bugs in
stable be forgotten about because they passed some threshold where the
BTS auto-vanished them.

I don't know if it's feasible, but my ideal vision for how the new
version tracking would handle bugs in stable would be that if the
version in stable is affected, the bug is left open if it's tagged
sarge or if it's of RC severity; otherwise the bug is archived normally.
I don't even see a reason to special-case "security", most such bugs are
going to be of RC severity and the others can be tagged with the
per-suite tag just as we've been doing.

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