date:20050623

* Russell Coker ([EMAIL PROTECTED]) [050622 11:22]:
> On Monday 20 June 2005 21:45, "Marco d'Itri" <[EMAIL PROTECTED]> wrote:
> > Anyway, the major problem now are the @packages.debian.org addresses, I
> > have ~20 of them and most days they account for 1/3 to 1/2 of all the
> > spam I receive (and almost all of it could be blocked with the CBL).
 
> Why not just block mail sent to the packages.debian.org addresses?  No-one 
> sends real mail to them anyway so they are just a free pass for spammers.

The packages.d.o-addresses are a really useful tool for contacting
multiple maintainers e.g. for transitions. They were quite helpful
during e.g. the release of sarge.


Cheers,
Andi


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

dummy packages and "Replaces:" field

2005-06-23 Thread Margarita Manterola

Hi!

As you all know, dummy packages are an ugly hack.  They require
maintainers to do an unnecesary upload and mean that we need to keep
an unuseful package in the archive just to be able to replace the old
package.

Even if dummy packages fulfill their mission, I believe better
solutions are in order.

The one I can think of is honouring the "Replaces:" field, meaning
that when a package states that it replaces another one, apt,
aptitude, dselect, and all the others would  install it to replace of
the old one.

This would mean an important change in all these tools, and I guess
that due to the fact that "Replaces:" was not being honoured up to now
some packages might be abusing it, and that would need to be fixed,
too.

Is there a better solution to this? If there isn't, I think that we
should try to fix this for etch. Even if it means a lot or work, it
would be better than stickying to the dummy packages ugly hack.

-- 
Besos,
Marga

Re: dummy packages and "Replaces:" field

2005-06-23 Thread Steve Greenland

On 23-Jun-05, 08:03 (CDT), Margarita Manterola <[EMAIL PROTECTED]> wrote: 
> The one I can think of is honouring the "Replaces:" field, meaning
> that when a package states that it replaces another one, apt,
> aptitude, dselect, and all the others would  install it to replace of
> the old one.

That is not what "Replaces:" means, and changing dpkg to do what you
want would break a lot of existing packages that are NOT mis-using it.
See the dpkg docs for what "Replaces:" actually does.

> Is there a better solution to this?

I think that there have been proposals for a new header that
accomplishes what you want, but it's never gone anywhere. I suspect that
the effort has not been viewed as worthwhile, given that there's no new
functionality. Dummy packages work, and have the advantage that it's
very clear what is going on.

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: Reportbug and RFS

2005-06-23 Thread Nico Golde

Hello Christian,

* Christian Perrier <[EMAIL PROTECTED]> [2005-06-23 15:30]:
> Quoting David Moreno Garza ([EMAIL PROTECTED]):
> 
> > You could write the patch, file a wishlist bug against reportbug and
> > send it to the bug.
> 
> 
> Or, even, if you're not able to write the patch (noone can actually be
> fluent in all the damn programming languages in the world...:-)), just
> send the wishlist bug report.
> 
> Of course, we like patches..:-)...but maintainers also like just good
> ideas coming from users (no judgment here about *this* idea, which
> obviously does not seem so good for everyone...).

Ok, I mailed Neil it seems that he started what I want to do
too...
Regards Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 1024D/73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpBl04jnKbns.pgp
Description: PGP signature

Re: Reportbug and RFS

2005-06-23 Thread Nico Golde

Hey,

* Peter Samuelson <[EMAIL PROTECTED]> [2005-06-23 15:25]:
> [Nico Golde]
> > what about including the possibility of an RFS in reportbug?
> > I think this would be a good idea because I often see RFS
> > requests which are totally stupid.
> 
> Encouraging people so inexperienced as to post stupid RFSes to upload
> *more* things to Debian is not particularly productive.  It's not like
> it's *hard* to immerse oneself in the Debian development community long
> enough to see how it's done.  Do you really wish to encourage the
> belief that even that amount of effort is superfluous?

Mhm, I don't think the people out there who post stupid RFS
will change their posts if they don't have a good example.
Or maybe a help.

> Well, either way, I'd suggest a separate script.  There's no overlap
> between reportbug and a RFS.  Even overloading it to post ITPs is in my
> opinion pretty much of a stretch.

Ok thanks!
Regards Nico

-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 1024D/73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpYjfSmBADJK.pgp
Description: PGP signature

packages.d.o mail (Re: Greylisting for @debian.org email, please)

2005-06-23 Thread Adeodato Simó

* Andreas Barth [Thu, 23 Jun 2005 13:54:29 +0200]:

> The packages.d.o-addresses are a really useful tool for contacting
> multiple maintainers e.g. for transitions. They were quite helpful
> during e.g. the release of sarge.

  There are plans to merge @packages.d.o and @packages.QA.d.o, so that
  both reach the maintainer and the PTS subscribers. The QA address
  requires the presence of an X-PTS-Approved header to let a message
  reach @p.q.d.o, but I never asked Frank what his plans about
  this wrt the merge were.

  If @packages.d.o addresses are really such a big source of spam, we
  could require the header for both domains, which isn't _that_
  disruptive if we assume most users of @p.d.o addresses are developers,
  and not end users.

  Cheers,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
The Wright Brothers weren't the first to fly. They were just the first
not to crash


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

Re: KDE apps up for adoption

2005-06-23 Thread Ben Burton


>   I guess we (qt-kde team) could do it. and anybody interested in doing 
> it too could join us (only having an alioth account is required) and 
> maintain those inside our svn.

Works for me, ta.

b.


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

Re: dummy packages and "Replaces:" field

2005-06-23 Thread John Hasler

Steve Greenland writes:
> Dummy packages work, and have the advantage that it's very clear what is
> going on.

Users often find them very confusing.
-- 
John Hasler


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

Re: dummy packages and "Replaces:" field

2005-06-23 Thread Margarita Manterola

On 6/23/05, Steve Greenland <[EMAIL PROTECTED]> wrote:
> > The one I can think of is honouring the "Replaces:" field, meaning
> > that when a package states that it replaces another one, apt,
> > aptitude, dselect, and all the others would  install it to replace of
> > the old one.
> That is not what "Replaces:" means, and changing dpkg to do what you
> want would break a lot of existing packages that are NOT mis-using it.
> See the dpkg docs for what "Replaces:" actually does.

The documentation for this is in the Debian Policy:
http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.5.2

And basically, what it says is that if a package "Replaces:" and
"Conflicts:" with another package, the new one is completely replacing
the old one.

So, when both "Replaces:" and "Conflicts:" are there, and it is not a
virtual-package, it would trigger apt replacing the package.

> > Is there a better solution to this?
> I think that there have been proposals for a new header that
> accomplishes what you want, 

Well, a new header would be nice, of course.  But it would mean a
change in policy, that's why I was thinking of using the existing
ones.
Having the "Real-Replaces:" or whatever field might be clearer than
having a set of nested ifs.  And would not cause any problems with
packages that are already using the Replaces field for something else.

> but it's never gone anywhere. I suspect that the effort has not been viewed 
> as 
> worthwhile, given that there's no new functionality. Dummy packages work, 
> and have the advantage that it's very clear what is going on.

It's not really _that_ clear to the end user, and dummy packages are
an unnecesary hassle in the archive.  They work, yes, but they're an
ugly hack, and I think we can do better than that.

-- 
Besos,
Marga

Re: Received: lines in email from Debian servers

2005-06-23 Thread Rob Sims

On Thu, Jun 23, 2005 at 12:45:14PM +1000, Russell Coker wrote:
> Below is a sample from the headers of a mail sent to me by gluck.  You will 
> note that my server logs that the envelope recipient was [EMAIL PROTECTED] 
> while gluck puts no such data in the log entry.
> 
> This lack of information does no good (it's not secret) but makes it much 
> more 
> difficult to track down misconfiguration issues and spam.
> 
> Received: from gluck.debian.org (gluck.debian.org [192.25.206.10])
>   by smtp.sws.net.au (Postfix) with ESMTP id DE3F461B02
>   for <[EMAIL PROTECTED]>; Thu, 23 Jun 2005 12:13:56 +1000 (EST)
> Received: from (carmax.com) [220.90.224.49] 
>   by gluck.debian.org with smtp (Exim 3.35 1 (Debian))
>   id 1DlGod-0002gJ-00; Wed, 22 Jun 2005 19:47:40 -0600

Was this message addressed to more than one recpient handled by gluck?
I've noticed that servers that insert the "for" tag will only do so if
there is one envelope recipient.

If this happens with a single gluck recipient, never mind me...
-- 
Rob


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

Re: packages.d.o mail (Re: Greylisting for @debian.org email, please)

* Adeodato Simó ([EMAIL PROTECTED]) [050623 16:50]:
> * Andreas Barth [Thu, 23 Jun 2005 13:54:29 +0200]:
> > The packages.d.o-addresses are a really useful tool for contacting
> > multiple maintainers e.g. for transitions. They were quite helpful
> > during e.g. the release of sarge.
> 
>   There are plans to merge @packages.d.o and @packages.QA.d.o, so that
>   both reach the maintainer and the PTS subscribers. The QA address
>   requires the presence of an X-PTS-Approved header to let a message
>   reach @p.q.d.o, but I never asked Frank what his plans about
>   this wrt the merge were.
> 
>   If @packages.d.o addresses are really such a big source of spam, we
>   could require the header for both domains, which isn't _that_
>   disruptive if we assume most users of @p.d.o addresses are developers,
>   and not end users.

Well, that would work for me, yes.


Cheers,
Andi


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

Re: dummy packages and "Replaces:" field

On Thu, Jun 23, 2005 at 11:45:26AM -0300, Margarita Manterola wrote:
> On 6/23/05, Steve Greenland <[EMAIL PROTECTED]> wrote:
> > > The one I can think of is honouring the "Replaces:" field, meaning
> > > that when a package states that it replaces another one, apt,
> > > aptitude, dselect, and all the others would  install it to replace of
> > > the old one.
> > That is not what "Replaces:" means, and changing dpkg to do what you
> > want would break a lot of existing packages that are NOT mis-using it.
> > See the dpkg docs for what "Replaces:" actually does.
> 
> The documentation for this is in the Debian Policy:
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.5.2
> 
> And basically, what it says is that if a package "Replaces:" and
> "Conflicts:" with another package, the new one is completely replacing
> the old one.
> 
> So, when both "Replaces:" and "Conflicts:" are there, and it is not a
> virtual-package, it would trigger apt replacing the package.
> 

OK.  How would I make use of this.  I was going to adopt iceme and
icepref, but then I saw that they are abandoned upstream.  They have
become modules of IceWMCP.  I am going to package IceWMCP with the
intent that it replace iceme and icepref.

Someone recommended that I use dummy packages of iceme and icepref that
depend on icewmcp.  But, if I also make icewmcp Replace and Conflict
with iceme and icepref, will that not cause problems (since the new
dummy versions of iceme and icepref will depend on icewmpc)?

The thing is, I would like to be able to package icewmcp and request the
removal of iceme and icepref and know that all users with iceme and
icepref currently installed will get notified that icewmcp is the
"upgrade" they need.  Maybe I misunderstand?

-Roberto

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

pgpguzZ1tJqUL.pgp
Description: PGP signature

Re: Greylisting for @debian.org email, please

2005-06-23 Thread Russell Coker

On Thursday 23 June 2005 21:54, Andreas Barth <[EMAIL PROTECTED]> wrote:
> * Russell Coker ([EMAIL PROTECTED]) [050622 11:22]:
> > On Monday 20 June 2005 21:45, "Marco d'Itri" <[EMAIL PROTECTED]> wrote:
> > > Anyway, the major problem now are the @packages.debian.org addresses, I
> > > have ~20 of them and most days they account for 1/3 to 1/2 of all the
> > > spam I receive (and almost all of it could be blocked with the CBL).
> >
> > Why not just block mail sent to the packages.debian.org addresses? 
> > No-one sends real mail to them anyway so they are just a free pass for
> > spammers.
>
> The packages.d.o-addresses are a really useful tool for contacting
> multiple maintainers e.g. for transitions. They were quite helpful
> during e.g. the release of sarge.

They won't be useful for long unless some decent spam controls are 
implemented.  Don't bother using the packages.d.o addresses for any of my 
packages until some spam controls are configured on the Debian servers.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: raidtools2 -> mdadm change: woes and problems

2005-06-23 Thread Agustin Martin

On Wed, Jun 22, 2005 at 07:16:22PM +1000, Brian May wrote:

> On 2 of the systems I have upgraded, I had serious problems with
> mdadm.
> 
> The documentation said that there was no need for a config file, and I
> never used a 2.2 kernel, so the paragraphs starting with "If your RAID
> array was created on a 2.2 Linux kernel patched with RAID" seem
> irrelevant.
> 
> However, after rebooting, the raid devices would renumber themselves
> starting from /dev/md0 and up.
> 
> This meant the entries in /etc/fstab were now wrong.
> 
> I tried starting /dev/md4 manually, but I got /dev/md0 instead.
> 
> Eventually, I got /dev/md4 up and running, manually, and the computer
> resumed booting.  After rebooting the computer, and the same problem
> reoccurred...
> 
> Repeat previous paragraph numerous times with different variations.
> 
> I tried assembling the RAID with the --update=super-minor option (as
> well as all the other options), but it didn't seem to help.
> 
> In the end, I gave up and changed /etc/fstab to the new system.
> 
> I no longer have access this machine, the other machine doesn't seem
> to have the problem anymore.
> 
> How is this meant to work?

I am trying to remember my experience, so this might not be completely
accurate.

In my setup I have lilo booting different root RAID partitions, and the
normal way here is with a home made kernel having RAID support built in
(not as modules).

If RAID support is compiled into the kernel, and you created the RAID to use
the minor numbers, things will work regardless of the root partition you
boot.

However, if is built as modules, as in an initrd, that automatic detection
does not work and you need to either use a config file, or trust what mdrun
builds (I think mdrun is run if no config file is found). In my system
what mdrun builds is different from what I had set, so a config file is
needed in this case.

Managing a single initrd boot from different root RAID partitions needed a
bit more hack. Otherwise will assemble the one it was built from, but that
will not work if you want to use a different one as root.

Cheers,

-- 
Agustin

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

Re: dummy packages and "Replaces:" field

2005-06-23 Thread Margarita Manterola

On 6/23/05, Roberto C. Sanchez <[EMAIL PROTECTED]> wrote:
> OK.  How would I make use of this.  I was going to adopt iceme and
> icepref, but then I saw that they are abandoned upstream.  They have
> become modules of IceWMCP.  I am going to package IceWMCP with the
> intent that it replace iceme and icepref.
> 
> Someone recommended that I use dummy packages of iceme and icepref that
> depend on icewmcp.  But, if I also make icewmcp Replace and Conflict
> with iceme and icepref, will that not cause problems (since the new
> dummy versions of iceme and icepref will depend on icewmpc)?

Well, of course, you cannot adopt both methods.  Either you use the
dummy package method or you use the Replace and Conflict method.

Also, my suggestion is not the answer to a problem, just a starting
point to think about it.  It has been brought to my attention than
"Replaces:" and "Conflicts:" are not enough, "Provides:" is also
needed.  And for that, we would need a Provides that supports
versions, which is not currently the fact. So dpkg would need to be
fixed first.

-- 
Besos,
Marga

Re: Received: lines in email from Debian servers

2005-06-23 Thread Russell Coker

On Friday 24 June 2005 00:29, Rob Sims <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 23, 2005 at 12:45:14PM +1000, Russell Coker wrote:
> > Below is a sample from the headers of a mail sent to me by gluck.  You
> > will note that my server logs that the envelope recipient was
> > [EMAIL PROTECTED] while gluck puts no such data in the log entry.
> >
> > This lack of information does no good (it's not secret) but makes it much
> > more difficult to track down misconfiguration issues and spam.
> >
> > Received: from gluck.debian.org (gluck.debian.org [192.25.206.10])
> > by smtp.sws.net.au (Postfix) with ESMTP id DE3F461B02
> > for <[EMAIL PROTECTED]>; Thu, 23 Jun 2005 12:13:56 +1000 (EST)
> > Received: from (carmax.com) [220.90.224.49]
> > by gluck.debian.org with smtp (Exim 3.35 1 (Debian))
> > id 1DlGod-0002gJ-00; Wed, 22 Jun 2005 19:47:40 -0600
>
> Was this message addressed to more than one recpient handled by gluck?
> I've noticed that servers that insert the "for" tag will only do so if
> there is one envelope recipient.
>
> If this happens with a single gluck recipient, never mind me...

I used the machine smtp.sws.net.au to send an email to my @debian.org address.  
Below is part of the headers.  As you can see master.debian.org doesn't log 
the for section.

Received: from master.debian.org (master.debian.org [146.82.138.7])
by smtp.sws.net.au (Postfix) with ESMTP id 3BCC461B01
for <[EMAIL PROTECTED]>; Fri, 24 Jun 2005 01:35:08 +1000 (EST)
Received: from smtp.sws.net.au [61.95.69.6] 
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DlTjO-0008KQ-00; Thu, 23 Jun 2005 10:35:07 -0500

Postfix won't display the "for" section if there are multiple local 
recipients.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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

Re: dummy packages and "Replaces:" field

2005-06-23 Thread Manoj Srivastava

On Thu, 23 Jun 2005 11:45:26 -0300, Margarita Manterola
<[EMAIL PROTECTED]> said:  

> And basically, what it says is that if a package "Replaces:" and
> "Conflicts:" with another package, the new one is completely
> replacing the old one.

> So, when both "Replaces:" and "Conflicts:" are there, and it is not
> a virtual-package, it would trigger apt replacing the package.

But the semantics also are that the _user_ selects the new
 package, and all the conflict/replace/provide does is that dpkg does
 not complain. I would be very surprised if apt were to change these
 semantics out from under me.

>> > Is there a better solution to this?
>> I think that there have been proposals for a new header that
>> accomplishes what you want,

> Well, a new header would be nice, of course.  But it would mean a
> change in policy, that's why I was thinking of using the existing
> ones.  Having the "Real-Replaces:" or whatever field might be
> clearer than having a set of nested ifs.  And would not cause any
> problems with packages that are already using the Replaces field for
> something else.

Umm , changing the existing semantics is far worse than the
 problem -- if it is a problem -- you are trying to solve. Also,if apt
 immediately tries to replace the old package with the new one (with
 no dummy package to ewase the transition), then in Sid such an
 upgrade would be broken until the last package with a versioned
 depends on the old one  (provides are unversioned).

Dummy packages are small, cost little, and allow for a
 transition period where people can start using the new package, and
 still gives depending packages (even those with versioned depends) a
 window to change their dependencies over to the new package, without
 stalling out the transition.

Until these technical issues are dealt with, I can't see how
 dummy packages can be done away with.

>> but it's never gone anywhere. I suspect that the effort has not
>> been viewed as worthwhile, given that there's no new
>> functionality. Dummy packages work, and have the advantage that
>> it's very clear what is going on.

> It's not really _that_ clear to the end user, and dummy packages are
> an unnecesary hassle in the archive.  They work, yes, but they're an
> ugly hack, and I think we can do better than that.

What, 239 packages out of some 16000 total? What exactly is
 the problem? This is a miniscule number, and the disk requirements
 for a dummy package is negligible. Now, novice users can possibly be
 puzzled, but the description usually says that the packages is
 a dummy used for upgrades, install package foo instead, and you can
 remove this package. Hardly rocket science to understand what this
 means, neh?

manoj

-- 
Which is worse: ignorance or apathy?  Who knows?  Who cares?
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: dummy packages and "Replaces:" field

On Thu, Jun 23, 2005 at 12:38:34PM -0300, Margarita Manterola wrote:
> On 6/23/05, Roberto C. Sanchez <[EMAIL PROTECTED]> wrote:
> > OK.  How would I make use of this.  I was going to adopt iceme and
> > icepref, but then I saw that they are abandoned upstream.  They have
> > become modules of IceWMCP.  I am going to package IceWMCP with the
> > intent that it replace iceme and icepref.
> > 
> > Someone recommended that I use dummy packages of iceme and icepref that
> > depend on icewmcp.  But, if I also make icewmcp Replace and Conflict
> > with iceme and icepref, will that not cause problems (since the new
> > dummy versions of iceme and icepref will depend on icewmpc)?
> 
> Well, of course, you cannot adopt both methods.  Either you use the
> dummy package method or you use the Replace and Conflict method.

Right.  However, what I would like is to be able to do it *without*
using dummy packages.  I think that what I want is not possible without
dummy packages.  That is where I see a problem.  The current
Replaces/Conflicts mechanism doesn't handle it all well.  I agree a
change that makes it work more elegantly would be nice.  It would also
help to eliminate a number of dummy and transitional packages that exist
for no other reason than to be a hacky work around for replacement of
obselete packages.

-Roberto

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

pgpciUQpcigMJ.pgp
Description: PGP signature

Re: dummy packages and "Replaces:" field

2005-06-23 Thread Brian Nelson

On Thu, Jun 23, 2005 at 12:02:44PM -0400, Roberto C. Sanchez wrote:
> On Thu, Jun 23, 2005 at 12:38:34PM -0300, Margarita Manterola wrote:
> > On 6/23/05, Roberto C. Sanchez <[EMAIL PROTECTED]> wrote:
> > > OK.  How would I make use of this.  I was going to adopt iceme and
> > > icepref, but then I saw that they are abandoned upstream.  They have
> > > become modules of IceWMCP.  I am going to package IceWMCP with the
> > > intent that it replace iceme and icepref.
> > > 
> > > Someone recommended that I use dummy packages of iceme and icepref that
> > > depend on icewmcp.  But, if I also make icewmcp Replace and Conflict
> > > with iceme and icepref, will that not cause problems (since the new
> > > dummy versions of iceme and icepref will depend on icewmpc)?
> > 
> > Well, of course, you cannot adopt both methods.  Either you use the
> > dummy package method or you use the Replace and Conflict method.
> 
> Right.  However, what I would like is to be able to do it *without*
> using dummy packages.  I think that what I want is not possible without
> dummy packages.  That is where I see a problem.  The current
> Replaces/Conflicts mechanism doesn't handle it all well.  

It's not designed nor intended to do what dummy packages do.  It's meant
to be used in cases where two packages don't coexist, so installing one
automatically removes the other.

> I agree a change that makes it work more elegantly would be nice.  

Not to the Replaces/Conflicts behavior.  You must introduce a new
field--see #33344 or #77325.

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Re: dummy packages and "Replaces:" field

2005-06-23 Thread Manoj Srivastava

On Thu, 23 Jun 2005 08:32:35 -0500, Steve Greenland
<[EMAIL PROTECTED]> said:  

> I think that there have been proposals for a new header that
> accomplishes what you want, but it's never gone anywhere. I suspect
> that the effort has not been viewed as worthwhile, given that
> there's no new functionality. Dummy packages work, and have the
> advantage that it's very clear what is going on.

OK. Heres trhe thing. Suppose there is a package foo, now not
 being developed. There is a package baz that depends on it. There is
 a new package foo, that in some sense provides a replacement. Let us
 consider a couple of scenarios:

  a) bar is a drop in replacement -- it uses the same config, for
 example, it hs the same functionality, and is better than foo,
 has support, security fixes, what have you -- and in all cases
 should be installed on any machine on which foo was
 installed. This is currently done using "dummy" packages, and it
 allows for depending packages a window of time to upgrade
 dependencies. 

With a dummy package foo; baz can continue to depend on foo
 during the transition, while the user is actually using bar, the
 transition is not stalled. Even if baz has a versioned dependency
 on foo. This window for transition is critical.

  b) bar is _not_ a drop in replacement -- perhaps it has different
 config files, subtly different behaviour, and you do not want the
 system to automatically replace foo without a human decision to
 do so. (say, kinda like the MTA's in debvian, that all conflict,
 replace, and provide the virtual mail-transport-agent package).

In this case, one does _not_ use a dummy package, one uses
 conflict, replace, and provide (and perhaps a NEWS.Debian in a
 new version of foo), and works with dependent packages to depend
 on foo | bar, if at all possible (which it may not be, given bar
 is not a drop in replacement for foo). It would be better if bar
 could have a versioned provides, but hey, one works with what one
 has.

In no way should support for option (b) be dropped, you
 certainly should not change the semantics of option (b) to work the
 same as option (a). And any replacement for option (a) should
 continue to provide the window for the transition (a flag day
 changeover usually does not work).

manoj
-- 
Some rise by sin and some by virtue fall.
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]

Idea for GAIM add-on (maybe a Summer of Code Project)

2005-06-23 Thread james winter

I think one of the biggest hassles with instant messaging is that its tied to the computer. If Im away from the computer, like watching tv, I may miss an important IM. I can leave the speakers on the PC really loud, but then Im always jumping up and running back to the PC to read an incoming IM in case its important. Most of the time its not. I can subscribe to a service with my cell phonebut that costs money. So here is (I think) the perfect solution, and a good GAIM plug-in thats not too much work.I just installed a Pluto Home system (plutohome.com). Its a free, open source smarthome and media server. You put Bluetooth dongles on all the pcs in your house, and then when you enter a room your Symbian Bluetooth phone turns into a remote control for everything in that room. It already tracks your movementif you start listening to music in 1 room, your music will follow you as you move with your phone to another room. And it already sends
messages to the phone based on events. For example, when the song changes, the cover art shown on my phone changes to show me whats playing.So that got me thinking Why not make a GAIM plugin for pluto so that whenever I get an IM, I see it on my Bluetooth phone? That way I can either type a reply on the phone, or go back to the computer if I want to use the keyboard, or ignore it if its not important. And Im not having to run back and forth to the computer to check IM. And its free since it uses Bluetooth! Plus, I think its such a real convenience it would be a great way to get people to switch to GAIM.I talked to the programmers at Pluto and they said it would be really easy since their stuff is already written in small modules and plugins. However, since were all open source, we could also just take whatever pieces were useful and do something completely new using the same concept.Many of the other GAIM projects listed are either specific for only
some users (like Apple iChat), or would only be used by geeks (like the Perl interpreter). But not having to run back and forth to the computer is something everybody wants (imho). I dont see how to recommend a new idea for GAIM, so Ill just try the forums and hope somebody else likes it too.
Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football

Re: dummy packages and "Replaces:" field

On Thu, Jun 23, 2005 at 07:22:28PM +0300, Brian Nelson wrote:
> On Thu, Jun 23, 2005 at 12:02:44PM -0400, Roberto C. Sanchez wrote:
> > 
> > Right.  However, what I would like is to be able to do it *without*
> > using dummy packages.  I think that what I want is not possible without
> > dummy packages.  That is where I see a problem.  The current
> > Replaces/Conflicts mechanism doesn't handle it all well.  
> 
> It's not designed nor intended to do what dummy packages do.  It's meant
> to be used in cases where two packages don't coexist, so installing one
> automatically removes the other.
> 

OK.  That is what I am looking for.  I want to completely replace the
two packages that cannot coexist with the new icewmcp package.
Currently, I must use dummy packages for that, correct?

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


pgpEYGABfAHf5.pgp
Description: PGP signature

Re: TODO for etch ?

2005-06-23 Thread Alban Browaeys

Le dimanche 19 juin 2005 à 23:22 +0200, Florian Weimer a écrit :
> * Marc Haber:
> 
> > On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer
> > <[EMAIL PROTECTED]> wrote:
> >>That could "save" a grand total of about a second.
> >
> > It will save time in case of error when the bootup process stalls for
> > timeouts like DNS and NTP.
> 
> You should set the clock using NTP *before* starting any daemons.
> Most daemons don't use monotonic clocks (I'm not even sure if Linux
> supports them at the required level), and some of them fail in strange
> ways if the system clock warps.

We need an "interface is ready" target in rcS and move ntpdate to
ifconfig if-up ...
This is tricky and i have no idea yet how to do it ... fix hotplug-net
or deisgn something new (as in hardware and internet ready , let s start
daemons ) ? 

Alban

resolution of licensing with httperf

I have been corresponding with the developer and maintainer of httperf
[0], which I intend to adopt.  The issue was that a libssl linking
exception was needed for the package.  They are currently making
inquiries at HP as to how exaclty go about this from their end, but the
deevloper and the maintainer both seem quite helpful and want to work
this out as quickly as possible.  It looks like they will come through
as soon as they get approval.

My question is this:  since the package currently exists in
oldstable/non-US, would it be possible to have the updated package
(including OpenSSL linking exception and a recompile to link against
libssl0.9.7) to make it into the next stable update?

I think that since there is the potential for previous Woody users to
have had the package installed and then still have it present after an
upgrade to Sarge.  In the (unlikely event) that security updates become
necessary to httperf, the Sarge users won't get them.

Does this situation need to be dealt with?  Is this the correct way of
going about it?

-Roberto


[0] http://packages.debian.org/httperf

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


pgpjhtQCGBG71.pgp
Description: PGP signature

Re: packages.d.o mail (Re: Greylisting for @debian.org email, please)

2005-06-23 Thread Marco d'Itri

On Jun 23, Adeodato Simó <[EMAIL PROTECTED]> wrote:

>   There are plans to merge @packages.d.o and @packages.QA.d.o, so that
>   both reach the maintainer and the PTS subscribers. The QA address
>   requires the presence of an X-PTS-Approved header to let a message
>   reach @p.q.d.o, but I never asked Frank what his plans about
>   this wrt the merge were.
This is evil, I just verified that packages.qa.debian.org generates
backscatter.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: unsubscribe

2005-06-23 Thread Alban browaeys

Le lundi 16 mai 2005 à 10:58 +0200, Bezecny Martin a écrit : 
> 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]

lol this was added by the debian-devel list . jack wanted to
unsusbscribe from  debian-changes . Thus

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


thus  send an "unsusbscribe" to  [EMAIL PROTECTED]

Cheers
Alban

Re: Reportbug and RFS

2005-06-23 Thread David Moreno Garza

On Thu, 2005-06-23 at 15:46 +0200, Nico Golde wrote:
> Ok, I mailed Neil it seems that he started what I want to do
> too...

Now spread the word between maintainers of prospective packages to use
the RFS reportbug template once it is ready. :)

--
David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/
 If at first you don't succeed, work for Microsoft. 
 GPG: C671257D - 6EF6 C284 C95D 78F6 0B78 FFD3 981C 5FD7 C671 257D


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

Re: Greylisting for @debian.org email, please

* Russell Coker ([EMAIL PROTECTED]) [050623 18:04]:
> On Thursday 23 June 2005 21:54, Andreas Barth <[EMAIL PROTECTED]> wrote:
> > The packages.d.o-addresses are a really useful tool for contacting
> > multiple maintainers e.g. for transitions. They were quite helpful
> > during e.g. the release of sarge.
 
> They won't be useful for long unless some decent spam controls are 
> implemented.

You don't need to convince me regarding spam controls. :)


Cheers,
Andi


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

Re: packages.d.o mail (Re: Greylisting for @debian.org email, please)

* Marco d'Itri ([EMAIL PROTECTED]) [050623 19:31]:
> On Jun 23, Adeodato Simó <[EMAIL PROTECTED]> wrote:
> >   There are plans to merge @packages.d.o and @packages.QA.d.o, so that
> >   both reach the maintainer and the PTS subscribers. The QA address
> >   requires the presence of an X-PTS-Approved header to let a message
> >   reach @p.q.d.o, but I never asked Frank what his plans about
> >   this wrt the merge were.

> This is evil, I just verified that packages.qa.debian.org generates
> backscatter.

You mean, this mails should rather be checked during SMTP time? Agreed.


Cheers,
Andi


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

Re: Question about replacing obsolete packages.

2005-06-23 Thread Eduard Bloch

#include 
* Brian M. Carlson [Wed, Jun 22 2005, 10:01:49PM]:

> > iceme or icepref installed should see a new version, which brings in
> > icewmcp.  What is the best way in which to accomplish this?
> 
> Make iceme and icepref dummy packages that just depend on icewmcp.

And please make symlinks (or whatever) to the icewmcp executable so the
users still get the program when they run iceme/icepref.

Regards,
Eduard.

-- 
So, your "solution" is to ask "Should I break your system now or after
the next reboot?". Debconf is not an alternative to fixing the
problem. Such questions are still unacceptable bugs.
  -- asuffield in debian-devel about crazy linux-2.4 repackaging


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

Re: Idea for GAIM add-on (maybe a Summer of Code Project)

2005-06-23 Thread Peter Samuelson


[james winter]
> I just installed a Pluto Home system (plutohome.com). Its a free,
> open source smarthome and media server. You put Bluetooth dongles on
> all the pcs in your house, and then when you enter a room your
> Symbian Bluetooth phone turns into a remote control for everything in
> that room. It already tracks your movementif you start listening to
> music in 1 room, your music will follow you as you move with your
> phone to another room. And it already sends messages to the phone
> based on events. For example, when the song changes, the cover art
> shown on my phone changes to show me whats playing.

I notice the Pluto system is not distributed by Debian.  So the two
things you need to do are (a) to write the plugin, and (b) to get
Pluto, and your plugin, into Debian.

For writing the plugin, I don't know what resources to recommend to
you, since I am not immersed in the Gaim or Pluto scenes.  For getting
the system into Debian, you will want to read
http://www.debian.org/doc/maint-guide/ and other docs linked from
http://www.debian.org/devel/ .

At that point, this will be on-topic for this list.


signature.asc
Description: Digital signature

Re: dummy packages and "Replaces:" field

2005-06-23 Thread Javier Fernández-Sanguino Peña

On Thu, Jun 23, 2005 at 10:47:00AM -0500, Manoj Srivastava wrote:
> 
> What, 239 packages out of some 16000 total? What exactly is
>  the problem? This is a miniscule number, and the disk requirements
>  for a dummy package is negligible. Now, novice users can possibly be
(...)

I guess your count is based on 'apt-cache search dummy'. Sorry, 
unfortunately that will not provide you with a full list for several 
reasons:

1.- there are packages that include 'dummy' in their description which are
not provided for transitional reasons (i.e. java-common)

2.- there are packages labeled as dummy that are in fact used to track
versioned packages (i.e. libapache-mod-python). Users should not remove 
these, they are not transitional packages either.

3.- there are dummy packages which do not use 'dummy' in their description 
but use something else instead (look at zope-tinytable or try searching 
for 'transitional').

One of the main problems looking for these packages is that there is no
standard _description_ for them. That makes it difficult for us to find and
clean them between releases [1] and for system administrators to find which
ones are present in their system and remove them after an upgrade.

Regards

Javier

[1] I did a 'dummy' hunt before sarge which resulted in some dummy packages 
being removed from sarge which were created to ease potato->woody upgrades!

signature.asc
Description: Digital signature

Re: Ongoing Firefox (and Thunderbird) Trademark problems

* Eric Dorland 

| * Tollef Fog Heen ([EMAIL PROTECTED]) wrote:
| > * Eric Dorland 
| > 
| > | BTW, any Ubuntu developers care to comment? I'm interested in second
| > | opinions and how you guys are handling this situation? Did you accept
| > | an arrangement with MoFo? 
| > 
| > We've been in touch with them and have currently renamed the
| > mozilla-firefox package to firefox.  The same thing is going to happen
| > to mozilla-thunderbird once I get around to it.  We are unsure about
| > the downstream namechange requirement, but not having firefox in there
| > would be bad.  So, a bit undecided at the moment.
| 
| Thanks for answering. We may end up having to do the mozilla-firefox
| -> firefox rename too if we keep the name too. Is Ubuntu concerned
| about MoFo's trademark policy? Did Ubuntu make a similar arrangement
| with MoFo that we're being offered? 

Sorry for being late answering this.  I've been out travelling and
slightly out of touch with my email.

Yes, we're concerned about how to handle the trademark policy,
especially given our focus on derived distributions.  At the moment, I
don't think anybody has actually sat down and decided anything as we
are interested in what Debian decides to do.  We have a current
understanding with MoFo that we're respecting their trademarks and
transitioning to something which is within the bounds of what they
allow to.

| As an aside (I should probably just look) but are you guys using their
| official logo? 

TTBOMK, no.

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


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

Re: ftp-master, ftp and db .debian.org moving - hosting sought

2005-06-23 Thread Adrian von Bidder

On Wednesday 22 June 2005 20.02, Olaf van der Spek wrote:
[debian infrastructure]
> I've been wondering, would it be an idea (for the long-term) to use
> (more) distributed ... or p2p concepts to reduce the dependency and
> load on central servers?

You said it yourself:  in the long term.

I think that some of the P2P network concepts might be very interesting for 
some things like file hosting etc. - but this won't be feasible within the 
next few weeks or even months.  Additionally, you need to keep in mind that 
- depending on what exactly you'd want to do - current oldstable's tools 
would reasonably have to be supported at least until oldstable becomes 
veryoldstable, so any benefits of such a new system would have a big effect 
only slowly.

So I guess, the standard open-source-project-answer applies:  if you like 
the idea, write the code, propose to implement it - at least as a 
small-scale prototype - and then we'll look at it.

cheers
-- vbi

-- 
Today is Prickle-Prickle, the 28th day of Confusion in the YOLD 3171


pgpeSov2LgFgs.pgp
Description: PGP signature

Re: And now for something completely different... etch!

* Paul TBBle Hampson 

| The charset of your terminal is orthogonal to the charset you're
| talking on the IRC network with to my mind, since even the built-in
| recode support lets you set a default charset for IRC traffic.

No, it's not, since at least one of the most popular IRC clients
(irssi) doesn't have recode support (yet).

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


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

Re: Question regarding "offensive" material

* Andrew Suffield 

| On Wed, Jun 15, 2005 at 02:32:36PM +0300, Lars Wirzenius wrote:
| > I therefore propose
| > that we do the following:
| > 
| > * Don't install any screensaver modules whatsoever, except one that
| > shows a blank screen and turns off the monitor after a while.
| 
| This is called 'power management', and is enabled by default on every
| installation of X, last I looked (configure with 'xset dpms'). A
| 'screensaver' is those things which display silly animations, and has
| to be installed extra.
| 
| So just don't install any screensavers. Why did you?

Because dpms doesn't lock your screen and provide at least _some_
security.

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


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

Bug#315592: RFH aboot (Alpha bootloader): Looking for co-maintainers

2005-06-23 Thread Helge Kreutzmann

Subject: RFH: aboot
Package: wnpp
Severity: normal

I maintain aboot now for about 2 years, but unfortunately my private alpha
run into serious problems late last year, and now I lost access to the
university machines, so I currently cannot work on aboot. 

I am still interested in the alpha-architecture (and aboot), and will 
see if I can get my machine going again, but this will happen later 
this year as I just started a new job. 

I would like someone with an alpha and interest in keeping this
architecture going in Debian to help me. There are not many bugs, and
I tried to collect as much info as possible. I am still the (upstream)
aboot-docu-maintainer, so if someone joins me I can try to coordinate
future development (mainly bug fixing, and releasing version 1.0) with
the upstream developers.

And for someone with interest in file systems, there are wishlist bugs
for more supported file systems to boot from :-))

-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.10-9-amd64-k8
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
-- 
Dr. Helge Kreutzmann, Dipl.-Phys.   [EMAIL PROTECTED]
   gpg signed mail preferred 
64bit GNU powered  http://www.itp.uni-hannover.de/~kreutzm
  Help keep free software "libre": http://www.ffii.de/


pgpC1wp07HkFP.pgp
Description: PGP signature

Re: dummy packages and "Replaces:" field

2005-06-23 Thread Steve Langasek

On Thu, Jun 23, 2005 at 11:45:26AM -0300, Margarita Manterola wrote:
> On 6/23/05, Steve Greenland <[EMAIL PROTECTED]> wrote:
> > > The one I can think of is honouring the "Replaces:" field, meaning
> > > that when a package states that it replaces another one, apt,
> > > aptitude, dselect, and all the others would  install it to replace of
> > > the old one.
> > That is not what "Replaces:" means, and changing dpkg to do what you
> > want would break a lot of existing packages that are NOT mis-using it.
> > See the dpkg docs for what "Replaces:" actually does.

> The documentation for this is in the Debian Policy:
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.5.2

> And basically, what it says is that if a package "Replaces:" and
> "Conflicts:" with another package, the new one is completely replacing
> the old one.

> So, when both "Replaces:" and "Conflicts:" are there, and it is not a
> virtual-package, it would trigger apt replacing the package.

But there is nothing in policy that says you can't have multiple packages
that Conflicts: and Replaces: the same package.  How is apt supposed to know
which of these packages to install as the replacement?

Also, the Conflicts: and Replaces: fields are frequently overused and abused
in packages currently.  Adding an additional meaning will only make the
problem worse.

> > > Is there a better solution to this?
> > I think that there have been proposals for a new header that
> > accomplishes what you want, 

> Well, a new header would be nice, of course.  But it would mean a
> change in policy, that's why I was thinking of using the existing
> ones.

Changing the meaning of existing fields is far worse than changing policy to
accomodate a new field.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: TODO for etch ?

* Rich Walker 

| email (exim) should start before programs that send email (mailman,
| smartmontools)

No?  /usr/sbin/sendmail usually works when the mail system is down
(and mailman sends out mail itself in the default configuration, so
the only reason for it needing an SMTPd on the host is to receive
incoming mail for the lists.)

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


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

Re: Reportbug and RFS

2005-06-23 Thread Philipp Kern

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David Moreno Garza wrote:
> Now spread the word between maintainers of prospective packages to use
> the RFS reportbug template once it is ready. :)

Perhaps it should just be announced to debian-mentors and put into all
those FAQs related to it (apart from the fact that many still do not
read these...).

Kind regards,
Philipp Kern
-BEGIN PGP SIGNATURE-
Comment: Fingerprint: 1710 7DB1 9A28 42FF B699  7654 ED1A 3933 B2CF CDD8
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iEYEARECAAYFAkK7HvwACgkQ7Ro5M7LPzdg8IACg5/0lMyMs93uQW1kqzBMGzC73
25MAnRJb842Wg/8exxQ/vjqr2o3e1uu6
=ok1R
-END PGP SIGNATURE-


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

Re: Testing package installation, upgrading, and removal

2005-06-23 Thread Junichi Uekawa

Hi,

> I've been thinking about that kind of package testing as well, but
> haven't gotten very far with it. See my two web log entries about it:
> 
> http://liw.iki.fi/liw/log/2005-05.html#20050507b
> http://liw.iki.fi/liw/log/2005-05.html#20050509c
> 
> In other words, I don't think it should be tied to piuparts, but if
> suitable debian/rules targets are standardized on, piuparts could
> certainly run such checks.

We used to have debian-test, which is now removed from
Debian archive.


Learning from that experience, there needs to be some kind of 
policy on tests.

Some debian-test scripts had dependency on maintainer machines
(like IP address and directory structures), and 
sometimes it's difficult to make a portable assumption about
these, while it is requisite for a test to run.



regards,
junichi

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


pgpxJKOluGWp3.pgp
Description: PGP signature

Re: dummy packages and "Replaces:" field

2005-06-23 Thread Simon Richter

Hi,

Roberto C. Sanchez schrieb:

> Someone recommended that I use dummy packages of iceme and icepref that
> depend on icewmcp.  But, if I also make icewmcp Replace and Conflict
> with iceme and icepref, will that not cause problems (since the new
> dummy versions of iceme and icepref will depend on icewmpc)?

I might be horribly wrong with this, but I dimly remember that in the
case that the dummy package depends on a package that conflicts and
provides the dummy, apt will not upgrade with "upgrade" and switch over
to the new package on "dist-upgrade".

   Simon


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

Re: Greylisting for @debian.org email, please

* Thomas Bushnell BSG 

| Steve Greenland <[EMAIL PROTECTED]> writes:
| 
| > On 18-Jun-05, 17:24 (CDT), Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: 
| >> 
| >> An email address with such blocking on it is therefore not suitable
| >> for the Maintainer: field of a Debian package.
| >
| > Any spam filtering system is going to have *some* false positives. Are
| > you claiming that if I do *any* spam filtering on the address listed in
| > my packages, it is not suitable?
| 
| I'm saying you must make sure you can get bug reports from users.

So having you maintainer address be a sink to /dev/null would be fine
since you can read bug reports on the web.

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


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

Re: Reduce the amount of spam for @debian.org