headers
Charles Plessy | 1 Jul 01:56
Favicon

Re: Intend to orphan pscan.

Le Sat, Jun 30, 2007 at 07:25:11PM +0200, Uwe Hermann a écrit :
> 
> Ack. Sorry for not answering earlier, but as the current maintainer of
> pscan I have no intentions to orphan or remove it.

Dear Uwe,

Thanks for the answer to the ping.

What do we do for the binary conflict ?

The reason I ask is that in the past, even before EMBOSS was packaged,
some people accepted to rename their binary so that the one of EMBOSS
was left unchanged (many thanks).

That is why I think I need your opinion before acting. Anyway, the
policy require developpers to agree on something, but with no answer
from one maintainer, it is my understanding that no agreement is
reached.

Have a nice day,

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

--

-- 
To UNSUBSCRIBE, email to debian-med-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
(Continue reading)

Permalink | Reply | 3 comments |
headers
Charles Plessy | 1 Jul 03:23
Favicon

Re: Intend to orphan pscan.

Le Sat, Jun 30, 2007 at 04:15:40PM +0200, Vincent Fourmond a écrit :
> 
>   This is a pretty rude thing to do. It is not because a package does
> have conflicting files with yours that you should remove it. Few ideas:

>   * simply use Conflict: pscan

Hi all,

I am a bit shocked that so many think that my intention was to force Uwe
to modify his package. In the absence of answer for more than three
months, my standpoint is that a package is unmaintained. Not being a DD,
I will not give Debian lessons about how to deal with does packages. But
when somebody does not manifest his interest for his package, I have a
hard time thinking that asking what to do is rude. Now that Uwe answered
I would like to reassure you that no, I do not intend to orphan his
package anymore.

So far for the excuses.

Now for the solution, since emboss and pscan do not provide the same
functionality, using Conflicts: is explicitely forbidden by policy
10.1. Also, the policy says

 "The maintainers should report this to the debian-devel mailing list and
 try to find a consensus about which program will have to be renamed"

So definitely, if asking the question was rude, this is the place to
fix...
(Continue reading)

Permalink | Reply | 0 comments |
headers
e2xbegqsdyt21hfc | 1 Jul 11:21
Picon
Favicon

Suggestion: Set up web pages with as much info about Debian machines as possible

  I believe that the Debian project can further help
its users by setting web pages with as much details on
its servers as possible. 
  In particular, I refer to the contents of the
configuration files of the software used by its
servers, and their version. This can further help
users to have working examples for DNS, MTA, sshd,
syslogd, kernel, hardware specs (perhaps taken from
/proc and/or boot.log files) and so on. Obviously the
network topology can help to clarify the big picture.

       
____________________________________________________________________________________Ready
for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Permalink | Reply | 2 comments |
headers
Vincent Fourmond | 1 Jul 12:50
Picon
Favicon

Source package containing HTML-only form of texinfo doc


  Hello all,

  I am currently reviewing the qtoctave package (#430731) before
sponsoring it. The package is now in a pretty good shape, excepted with
a problem for which I would like to have some advice: the qtoctave
upstream source ships with HTML-only form of the octave's texinfo
documentation, which is licensed under GPL. This documentation is
actually not installed in any binary package (for many reasons).

  My first reaction was that shipping this was violating the GPL and
that the documentation should be removed. However, do you think it is
reasonable to just add a statement to debian/copyright indicating the
authors/copyright of this document and where to find its source code
should be enough ? This way, no repackaging would be needed.

  Thanks,

	Vincent

PS: CCing the packager.
--

-- 
Vincent Fourmond, Debian Developer
http://vincent.fourmond.neuf.fr/
-- pretty boring signature, isn't it ?
Permalink | Reply | 5 comments |
headers
Enrico Zini | 1 Jul 15:16

Re: synchronizing README.Debian with wiki.debian.org

On Sun, Jun 10, 2007 at 08:40:21AM +0900, Junichi Uekawa wrote:

> I don't really know of any, so if anyone is actually doing it already,
> I'd like to know.
> I know of few existing cases that have similar effect:
> [package->web]
> 1. /usr/share/doc/XXX/*.html included in packages end up on web
>    servers (people can google around and arrive at them).
> [web->package]
> 2. upstream FAQ page is updated through 'wget' into the package source
>    from time-to-time.
> My personal impression is that although we have this system of
> maintaining 'README.Debian', it's often outdated on most packages.  It
> might help if users have direct (although maintainers should really
> check the contents) influence on its contents.

I see the thread a bit late, but I have to say that I like the idea.  In
debtags, I have various bits of information that I wish they were
maintained in the Debian wiki, such as the FAQ and other pieces of
documentation.

I think more packages, and the wiki itself, could benefit if this
procedure could become a bit more standardised.

Indeed something like a push/pull from the wiki into the VCS could do
the job; is there really no utility to replay changes from Moin's
history to a VCS, and changes from a VCS history into moin?

Ciao,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nico Golde | 1 Jul 16:51
Picon
Favicon

Re: Suggestion: Set up web pages with as much info about Debian machines as possible

Hi,
* e2xbegqsdyt21hfc <e2xbegqsdyt21hfc <at> yahoo.com> [2007-07-01 16:27]:
> I believe that the Debian project can further help
> its users by setting web pages with as much details on
> its servers as possible. 
> In particular, I refer to the contents of the
> configuration files of the software used by its
> servers, and their version. This can further help
> users to have working examples for DNS, MTA, sshd,
> syslogd, kernel, hardware specs (perhaps taken from
> /proc and/or boot.log files) and so on. Obviously the
> network topology can help to clarify the big picture.

From the security perspective I guess this absolutly not 
possible, for the user perspective there are enough examples
and documentation flying around in the net for various services.
Cheers
Nico
--

-- 
Nico Golde - http://ngolde.de - nion <at> jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
Permalink | Reply | 0 comments |
headers
Bill Allombert | 1 Jul 17:22
Picon
Favicon

Bug#229357: Can we require build-arch/indep targets for lenny?

On Sat, Jun 30, 2007 at 09:40:29AM +0200, Andreas Metzler wrote:
> I think that is just wrong. sbuild should not need to know anything
> about dpkg-buildpackage's internals and there is no need for change
> here. The currently used and proven interface is:
> 
> 1. install Build-Depends for running dpkg-buildpackage -B

The issue we are trying to fix is that the current combination of 
Debian policy and dpkg-buildpackage actually require
Build-Depends-Indep to be installed when running dpkg-buildpackage -B.

Indeed dpkg-buildpackage -B calls 'debian/rules build' which
requires Build-Depends-Indep to be installed. Since buildd actually
implement 1) this cause packages to FTBFS until they are 'fixed' by
having 'build' not depending on 'build-indep' (or equivalently, the
build-indep task being performed directly by binary-indep), which is
against the spirit of policy (because build-indep will then be 
executed under sudo or fakeroot).

So this interface is used and proven to be wrong.

> 2. install Build-Depends *and* Build-Indep-Indep for running
> dpkg-buildpackage differently (e.g without any modifier or with -b)

If you insist to go that road, you need to:

1) Change policy to require build-arch is implemented anytime the field
Build-Depends-Indep is provided.
and
2) Change dpkg-buildpackage -B to call build-arch if the field
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Metzler | 1 Jul 18:51
X-Face

Bug#229357: Can we require build-arch/indep targets for lenny?

Bill Allombert wrote:
> On Sat, Jun 30, 2007 at 09:40:29AM +0200, Andreas Metzler wrote:
>> I think that is just wrong. sbuild should not need to know anything
>> about dpkg-buildpackage's internals and there is no need for change
>> here. The currently used and proven interface is:

>> 1. install Build-Depends for running dpkg-buildpackage -B

> The issue we are trying to fix is that the current combination of 
> Debian policy and dpkg-buildpackage actually require
> Build-Depends-Indep to be installed when running dpkg-buildpackage -B.

Hello,
Policy does not reflect current reality in that respect. The buildds
do run dpkg-buildpackage -B and they do not install
Build-Depends-Indep. Packages requiring Build-Depends-Indep for
dpkg-buildpackage -B will FTBFS. Since that makes the package
unreleasable there are not many packages around that work like that.
(Except for source packages that do not build any arch-any packages
and therefore are not autobuilt.)

[snip]

>> 2. install Build-Depends *and* Build-Indep-Indep for running
>> dpkg-buildpackage differently (e.g without any modifier or with -b)

> If you insist to go that road, you need to:

> 1) Change policy to require build-arch is implemented anytime the field
> Build-Depends-Indep is provided.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oleg Verych | 1 Jul 20:22
Picon
Picon

long arithmetics in dash, dash fix 4`The Shell: arithmetic comparison with void'

* Date: Mon, 11 Jun 2007 14:24:24 +0000 (UTC)

> Yet arithmetic ones are still with them:
>
>|-*-	       
> olecom <at> flower:/tmp$ bash -c "test '' -eq 0 ; echo \$?"
> bash: line 0: test: : integer expression expected
> 2
> olecom <at> flower:/tmp$ dash -c "test '' -eq 0 ; echo \$?"
> 0
> olecom <at> flower:/tmp$ busybox sh -c "test '' -eq 0 ; echo \$?"
> 0
> olecom <at> flower:/tmp$
>|-*-

Proposed fixing in the dash: #431320

Maybe somebody interested in making dash use "long int", thus enabling
wider range on 64bit platforms, while still having same on 32bit ones?

Patch for test built-in is ready, now i'm thinking about arithmetics.
Long int is used internally, but then casted to int, that's why
changes are very small indeed.
____
Permalink | Reply | 1 comment |
headers
Oleg Verych | 1 Jul 20:28
Picon
Picon

long arithmetics in dash, dash fix 4`The Shell: arithmetic comparison with void'

* Date: Mon, 11 Jun 2007 14:24:24 +0000 (UTC)

> Yet arithmetic ones are still with them:
>
>|-*-	       
> olecom <at> flower:/tmp$ bash -c "test '' -eq 0 ; echo \$?"
> bash: line 0: test: : integer expression expected
> 2
> olecom <at> flower:/tmp$ dash -c "test '' -eq 0 ; echo \$?"
> 0
> olecom <at> flower:/tmp$ busybox sh -c "test '' -eq 0 ; echo \$?"
> 0
> olecom <at> flower:/tmp$
>|-*-

Proposed fixing in the dash: #431320

Maybe somebody interested in making dash use "long int", thus enabling
wider range on 64bit platforms, while still having same on 32bit ones?

Patch for test built-in is ready, now i'm thinking about arithmetics.
Long int is used internally, but then casted to int, that's why
changes are very small indeed.
____
Permalink | Reply | 0 comments |

Gmane