Re: RFA: dbi,rmysql,qtl -- GNU R package providing a generic database interface

[Steffen Moeller]

Dear Dirk,

one should indeed discuss if the packages should remain in the distribution, 
but please not because I am a bit behind in maintenance. I promise updates 
for this weekend.

The packages built for CRAN and BioConductor derived automagically via the 
script you wrote (http://alioth.debian.org/projects/pkg-bioc/) are usable. 
The packages update very quickly as you know and hence I'd indeed prefer to 
establish a single site with all the CRAN and BioC packages over the partial 
distribution of such within Debian. Though you might have additional thoughts 
about this.

Many greetings

Steffen

Am Donnerstag 01 Dezember 2005 04:45 schrieb Dirk Eddelbuettel:
> Steffen Moeller is the maintainer of dbi, a database interface for R.  I
> have sponsored a few uploads. The package could use a refreshment. A new
> version is out. The debian/ directory can probably do with an update.  I
> can help and advise, but cannot take on more packages.
>
> I will retitle/refile this as an Orphan bug in a few weeks if nothing
> changes, after which the package should probably be removed from Debian.


pgph4NNwLFfVY.pgp
Description: PGP signature

Re: ITP: ladder.app -- GNU Go frontend for GNUstep

[Joey Hess]

Anthony DeRobertis wrote:
> "The description should also give information about the significant
> dependencies and conflicts between this package and others, so that the
> user knows why these dependencies and conflicts have been declared."
> ---Debian Policy, Section 3.4

So, I see two options... either slavishly document your package's
dependency on libc6 too, or look through
grep-aptavail -s Description -F Description depends
and see how this line of policy is actually used and perhaps get some
indication of the reasoning beind it. 

Some very good example of packages that mention their dependencies in
their descriptions include: build-essential, amarok-engines,
grandfatherclock, and ruby.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: texlive-basic_2005-1_i386.changes REJECTED

[Peter Samuelson]

[Frank Küster]
> > Why do we need two packages containing the "latex" command, for example?
> 
> Why do we need N packages that provide MTA functionality?

That's not equivalent.  An equivalent question would be more like "why
do we need N packages all containing the source code for exim and
building a binary called /usr/sbin/exim?"  What I mean is, AFAICT, if
you get past the packaging, tetex and texlive are the *same* source
code and the *same* data - not just two different implementations of a
similar interface.

So I would dearly hope that eventually tetex would evolve into little
more than a set of metapackages that suck in stuff from texlive.  Or do
the existing tetex packages actually provide anything that could not be
provided that way?  (Yes, I realise 'tetex' would be a misnomer at that
point.)

I'm in favor of texlive being included in debian unstable (assuming
license issues can be worked out), but I am not particularly in favor
of having texlive and tetex coexist indefinitely.  tetex is heavy
enough that it should have to justify its continued existence (I mean
as more than just a way to "get all useful bits of TeX by listing just
one package dependency") if texlive provides the same thing.


signature.asc
Description: Digital signature

Re: How to automatically update files on alioth from svn

[Anthony DeRobertis]

Frank Küster wrote:

> What do you mean
> with https?  I don't want to only check out individual files from a
> websvn site, but complete directories, including new files.

http://svnbook.red-bean.com/en/1.1/ch06s04.html


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

Re: ITP: ladder.app -- GNU Go frontend for GNUstep

[Anthony DeRobertis]

Roberto C. Sanchez wrote:
> On Wed, Nov 30, 2005 at 12:59:07PM +0100, Gürkan Sengün wrote:
> 
>>It uses gnugo as its
>>engine and you must have a recent version of gnugo installed in order to run 
>>it.
> 
> This statement is unnecessary.  You use dependencies to specify that.

"The description should also give information about the significant
dependencies and conflicts between this package and others, so that the
user knows why these dependencies and conflicts have been declared."
---Debian Policy, Section 3.4


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

RFA: dbi -- GNU R package providing a generic database interface

[Dirk Eddelbuettel]

Package: wnpp
Severity: normal

Steffen Moeller is the maintainer of dbi, a database interface for R.  I have
sponsored a few uploads. The package could use a refreshment. A new version
is out. The debian/ directory can probably do with an update.  I can help and
advise, but cannot take on more packages.

I will retitle/refile this as an Orphan bug in a few weeks if nothing
changes, after which the package should probably be removed from Debian.

Regards, Dirk

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


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

RFA: rmysql -- GNU R package providing a DBI-compliant interface to MySQL

[Dirk Eddelbuettel]

Package: wnpp
Severity: normal

Steffen Moeller is the maintainer of rmysql, a MySQL database package for R.  I
have sponsored a few uploads.  The package could use a refreshment. Three new
minor versions are out, and there is a bug report. The debian/ directory can
probably do with an update.  I can help and advise, but cannot take on more
packages.

I will retitle/refile this as an Orphan bug in a few weeks if nothing
changes, after which the package should probably be removed from Debian.

Regards, Dirk


-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


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

RFA: qtl -- GNU R package for genetic marker linkage analysis

[Dirk Eddelbuettel]

Package: wnpp
Severity: normal

Steffen Moeller is the maintainer of qtl, a bio/genetics analysis package for
R.  I have sponsored a few uploads. The package could use a refreshment. A
new minor version is out. The debian/ directory can probably do with an
update.  I can help and advise, but cannot take on more packages.

I will retitle/refile this as an Orphan bug in a few weeks if nothing
changes, after which the package should probably be removed from Debian.

Regards, Dirk

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


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

Re: dpkg-sig support wanted?

[Anthony Towns]

On Tue, Nov 29, 2005 at 02:20:55PM +0100, Florian Weimer wrote:
> > not even be out of the question to find someone who'll sponsor an upload
> > without rebuilding the .deb. I think it's safe to imagine that there are
> > developers right now who've done some shady things in the past; is it
> > that far fetched to imagine it's worth protecting against developers
> > who try to abuse their priveleges?
> No, but they can directly upload a bad package.  No need to create an
> MD5 collision and sneak the "evil twin" package into some mirror
> archive.

Sure; someday, maybe some of the test suite stuff will allow us to avoid
that, but at the moment we can't. What we can do now is limit the chances
that people will get away with that.

> Have we already done that?  Have we expelled people becaue they put
> vulnerable code into Debian?

We've expelled people for violating the DMUP in other ways; and we've
stopped distributing micq because it included upstream code that could
reasonably be called an exploit.

> You can embed code that checks for characteristics of the victim
> system and activate the attack only if there's a match.

Sure, these things aren't perfect; but they're a help.

Anyway, I'm not going to waste my time further arguing why we shouldn't
continue using a hash that's had a practical exploit published on
slashdot.

Cheers,
aj



signature.asc
Description: Digital signature

Re: package name changes in atlas-cpp (was Re: library renaming due to changed libstdc++ configuration)

[Steve Langasek]

On Wed, Nov 30, 2005 at 10:21:34PM +0100, Michael Koch wrote:
> On Wed, Nov 30, 2005 at 09:10:58PM +0100, Stephan Hermann wrote:

> > Don't worry :) If new 0.6.0 upstream source will change the soname and the 
> > package is named to libatlas-cpp-0.7 then you can just conflicts/replaces 
> > to 
> > libatlas-cpp-0.6, libatlas-cpp-0.6c2, libatlas-cpp-0.6c2a, so ubuntu can 
> > sync 
> > it directly without any problems. we are then in sync again and avoid any 
> > serious troubles during updates.

> It will be named libatlas-cpp-0.6-1. Just its interface version is
> changed.

> > Actually what you can also do is to follow Matthias Kloses post from 
> > 2005-11-14 about the libstdc++ new allocator transition. You actually need 
> > to 
> > rename libatlas-cpp-0.6c2 to c2a so we are in sync as well..
> > If you want I can send you an accurate debdiff.

> > Any objections?

> I dont mind what the solution of this problem is finally choosen. My
> Problem is that I made the same fault with wfmath and cal3d.

> I would like a vote from a RM about this. Steve ?

Well, if the soname will be changing again soon anyway then there's no
reason to reupload just to add the "a" to the package name.  If the lib
soname is going to be around for a while, though, for my part I think it's
worthwhile to get the package name consistent across distros where possible;
and in that case, the "c2a" name should be preferred since that's the name
specified in the published transition plan.

Cheers,
-- 
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: Bug#341465: ITP: libfile-copy-recursive-perl -- Perl extension for recursively copying files and directories

[Florian Ragwitz]

On Wed, Nov 30, 2005 at 08:05:02PM +0100, Krzysztof Krzyzaniak (eloy) wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>
> 
> * Package name: libfile-copy-recursive-perl
>   Version : 0.16
>   Upstream Author : Daniel Muey <[EMAIL PROTECTED]>
> * URL : http://search.cpan.org/~dmuey/File-Copy-Recursive-0.16/
> * License : (GPL, LGPL, BSD, MIT/X, etc.)
>   Description : Perl extension for recursively copying files and 
> directories

I already packaged this module. I think you'll maintain it with
pkg-catalyst anyway, so I think I should check in and upload my version.


signature.asc
Description: Digital signature

Re: BTS down?

[Don Armstrong]

On Wed, 30 Nov 2005, Gregor Jasny wrote:
> Don Armstrong schrieb:
> > On Mon, 21 Nov 2005, Gregor Jasny wrote:
> > 
> >>Bastian Venthur schrieb:
> >>
> >>>Can somebody confirm that there is a problem with the BTS?
> >>
> >>I've got the same setup and the same problem. Still no confirmation
> >>from bugs.debian.org.
> > 
> > The BTS is currently receiving mail properly and acting on it
> > properly, as near as I can tell.
> > 
> > Just use reportbug; if necessary, point it directly at
> > bugs.debian.org.
> > 
> > If you give me the precise message ID and the time of your message, I
> > may be able to track it down if it ever actually reached spohr.
> 
> It happened again. This time I have a tcpflow log of the communication
> with spohr. The Massage-Id is: 1EhVNQ-tO-LD, the message was sent at
> 17:04 UTC. I have attached the tcpflow dump.

Right, this message was sent without a message id, and was tagged as a
duplicate spam because of it.

[15] B.11333702574909 scanning ...
  From: Gregor Jasny <[EMAIL PROTECTED]>
  Subject: fbdesk must depend on libxft
  Date: Wed, 30 Nov 2005 19:05:15 +0100
  Message-Id: 
  spam 14.0/4.0 1 duplicate

This is bug #341325 in reportbug, and has been fixed in reportbug
3.18.

I'll see about reinserting this message into the queue for processing.


Don Armstrong

-- 
I'd never hurt another living thing.
But if I did...
It would be you.
 -- Chris Bishop  http://www.chrisbishop.com/her/archives/her69.html

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


signature.asc
Description: Digital signature

Bug#341487: ITP: gchempaint -- Chemical structure editor

[Michael Banck]

Package: wnpp
Severity: wishlist
Owner: Michael Banck <[EMAIL PROTECTED]>


* Package name: gchempaint
  Version : 0.6.2
  Upstream Author : Jean Brefort <[EMAIL PROTECTED]>
* URL : http://www.nongnu.org/gchempaint/
* License : GPL
  Description : Chemical structure editor
   gchempaint is a 2D chemical strucutre editor for the GNOME desktop.


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

Bug#341486: ITP: gnome-chemistry-utils -- GNOME chemistry utility library

[Michael Banck]

Package: wnpp
Severity: wishlist
Owner: Michael Banck <[EMAIL PROTECTED]>


* Package name: gnome-chemistry-utils
  Version : 0.4.7
  Upstream Author : Jean Brefort <[EMAIL PROTECTED]>
* URL : http://www.nongnu.org/gchemutils/
* License : GPL
  Description : GNOME chemistry utility library
   The Gnome Chemistry Utils provide C++ classes and Gtk+-2 widgets
   related to chemistry.
   .
   Existing widgets are:
- a periodic table of the elements (GtkPeriodic)
- a crystal structure viewer
- a molecular structure viewer



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

Re: Stephen Frost MIA?

[Thijs Kinkhorst]

On Wed, November 30, 2005 18:34, Nico Golde wrote:
> [...]
> Please consider reading this:
> http://www.us.debian.org/doc/developers-reference/ch-beyond-pkging.en.html
> #s-mia-qa

You mean where it says "It is also allowed to post a query to
debian-devel@lists.debian.org, asking if anyone is aware of the
whereabouts of the missing maintainer."?  ;-)


Thijs


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

Re: package name changes in atlas-cpp (was Re: library renaming due to changed libstdc++ configuration)

[Michael Koch]

On Wed, Nov 30, 2005 at 09:10:58PM +0100, Stephan Hermann wrote:
> Hi Michael,
> 
> On Wednesday 30 November 2005 22:00, Michael Koch wrote:
> > On Wed, Nov 30, 2005 at 08:08:15PM +0100, Stephan Hermann wrote:
> > > Well, I will try to revert the change, no problem. But even for
> > > libatlas-cpp-0.6 there was a soname change (if you see this bugreport
> > > about the rename of libatlas-cpp-0.5) and there was no need to rename
> > > libatlas-cpp-0.6 because the soname change was introduced by a new
> > > upstream source.
> > >
> > > When I got the merge report into my hands for libatlas-cpp-0.6, there was
> > > no renaming in rev 1, so I had to add c2a as soname change. I just saw
> > > too late, that there was a rev 2 of this package, and in this rev a
> > > renaming was made.
> > >
> > > At the time of the merge, I was right. There is now a difference between
> > > ubuntu and debian. I'm sorry for that, but I don't change it right now.
> > > If there is a new upstream of atlas-cpp, we can try to bring the two
> > > packages again in sync.
> >
> > Sorry for the trouble I made. My fault to not correctly reread the
> > transition mail again before doing the actual transition of atlas-cpp.
> > It's clearly my bug. What shall I do now? Rename the binary packages
> > again? Wait for a new upstream version (0.6.0) which changes the SONAME
> > again? 0.6.0rc2 is already out.
> 
> Don't worry :) If new 0.6.0 upstream source will change the soname and the 
> package is named to libatlas-cpp-0.7 then you can just conflicts/replaces to 
> libatlas-cpp-0.6, libatlas-cpp-0.6c2, libatlas-cpp-0.6c2a, so ubuntu can sync 
> it directly without any problems. we are then in sync again and avoid any 
> serious troubles during updates.

It will be named libatlas-cpp-0.6-1. Just its interface version is
changed.

> Actually what you can also do is to follow Matthias Kloses post from 
> 2005-11-14 about the libstdc++ new allocator transition. You actually need to 
> rename libatlas-cpp-0.6c2 to c2a so we are in sync as well..
> If you want I can send you an accurate debdiff.
> 
> Any objections?

I dont mind what the solution of this problem is finally choosen. My
Problem is that I made the same fault with wfmath and cal3d.

I would like a vote from a RM about this. Steve ?


Cheers,
Michael
-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/


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

Re: package name changes in atlas-cpp (was Re: library renaming due to changed libstdc++ configuration)

[Stephan Hermann]

Hi Michael,

On Wednesday 30 November 2005 22:00, Michael Koch wrote:
> On Wed, Nov 30, 2005 at 08:08:15PM +0100, Stephan Hermann wrote:
> > Well, I will try to revert the change, no problem. But even for
> > libatlas-cpp-0.6 there was a soname change (if you see this bugreport
> > about the rename of libatlas-cpp-0.5) and there was no need to rename
> > libatlas-cpp-0.6 because the soname change was introduced by a new
> > upstream source.
> >
> > When I got the merge report into my hands for libatlas-cpp-0.6, there was
> > no renaming in rev 1, so I had to add c2a as soname change. I just saw
> > too late, that there was a rev 2 of this package, and in this rev a
> > renaming was made.
> >
> > At the time of the merge, I was right. There is now a difference between
> > ubuntu and debian. I'm sorry for that, but I don't change it right now.
> > If there is a new upstream of atlas-cpp, we can try to bring the two
> > packages again in sync.
>
> Sorry for the trouble I made. My fault to not correctly reread the
> transition mail again before doing the actual transition of atlas-cpp.
> It's clearly my bug. What shall I do now? Rename the binary packages
> again? Wait for a new upstream version (0.6.0) which changes the SONAME
> again? 0.6.0rc2 is already out.

Don't worry :) If new 0.6.0 upstream source will change the soname and the 
package is named to libatlas-cpp-0.7 then you can just conflicts/replaces to 
libatlas-cpp-0.6, libatlas-cpp-0.6c2, libatlas-cpp-0.6c2a, so ubuntu can sync 
it directly without any problems. we are then in sync again and avoid any 
serious troubles during updates.

Actually what you can also do is to follow Matthias Kloses post from 
2005-11-14 about the libstdc++ new allocator transition. You actually need to 
rename libatlas-cpp-0.6c2 to c2a so we are in sync as well..
If you want I can send you an accurate debdiff.

Any objections?

Regards,

\sh


pgp0jUWpkT5nw.pgp
Description: PGP signature

Re: package name changes in atlas-cpp (was Re: library renaming due to changed libstdc++ configuration)

[Michael Koch]

On Wed, Nov 30, 2005 at 08:08:15PM +0100, Stephan Hermann wrote:
> Well, I will try to revert the change, no problem. But even for 
> libatlas-cpp-0.6 there was a soname change (if you see this bugreport about 
> the rename of libatlas-cpp-0.5) and there was no need to rename 
> libatlas-cpp-0.6 because the soname change was introduced by a new upstream 
> source. 
> 
> When I got the merge report into my hands for libatlas-cpp-0.6, there was no 
> renaming in rev 1, so I had to add c2a as soname change. I just saw too late, 
> that there was a rev 2 of this package, and in this rev a renaming was made.
> 
> At the time of the merge, I was right. There is now a difference between 
> ubuntu and debian. I'm sorry for that, but I don't change it right now. If 
> there is a new upstream of atlas-cpp, we can try to bring the two packages 
> again in sync.

Sorry for the trouble I made. My fault to not correctly reread the
transition mail again before doing the actual transition of atlas-cpp.
It's clearly my bug. What shall I do now? Rename the binary packages
again? Wait for a new upstream version (0.6.0) which changes the SONAME
again? 0.6.0rc2 is already out.


Cheers,
Michael
-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/


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

Bug#341465: ITP: libfile-copy-recursive-perl -- Perl extension for recursively copying files and directories

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name: libfile-copy-recursive-perl
  Version : 0.16
  Upstream Author : Daniel Muey <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~dmuey/File-Copy-Recursive-0.16/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Description : Perl extension for recursively copying files and directories

 This module copies and moves directories recursively (or single files, 
 well... singley) to an optional depth and attempts to preserve each file or 
 directory's mode.
 
NOTE:

This module used widely in test suites included in perl modules.
Is also required to build new upstream version of libcatalyst-perl

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-686
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]

XyMTeX licensing

[Karl Berry]

Dear Dr. Shinsaku,

I'm one of the people developing the TeX Live software distribution for
the TeX user groups.  The Debian project recently asked me about XyMTeX,
which we do currently include in TeX Live, based on your license
statement being analogous to that of Knuth's for TeX itself.

But now it seems that back in April, Debian contacted you about this,
and you replied that only personal + CTAN redistribution was allowed.

If that is truly what you intend, then we will regretfully have to
remove XyMTeX from TeX Live (and other free software distribution).  Of
course we'd much prefer to keep distributing it.

So, may I ask you to clarify/confirm, please?

If you do intend the user groups and distributions to be able to include
it, then I'd like to further suggest that the LPPL
(http://www.latex-project.org/lppl/) is perhaps the simplest widespread
choice that seems to come closest to your wishes.

Thanks for all your work, and best regards,
Karl


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

Re: XyMTeX in TeX live

[Karl Berry]

Hi Norbert,

I hope life after release of TL2005 has settled down a bit 

Well, just redirected into other areas :(.

Interstingly, the files state something a bit different:

A "license" statement clearly taken from tex.web, so I'm glad it is not
considered nonfree :).

we (actually Frank KŽüster suggested this) would
like you to ask him again about the license condition, 

Ok, I will ask him.

Cheers,
karl


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

Re: package name changes in atlas-cpp (was Re: library renaming due to changed libstdc++ configuration)

[Stephan Hermann]

Hi Steve,

On Tuesday 29 November 2005 12:15, Steve Langasek wrote:
> On Tue, Nov 29, 2005 at 11:38:32AM +0100, Stephan Hermann wrote:

> > > I don't see any reason to rename the -dbg packages, generally.
> >
> > For the first cxx transition during Breezy development, I renamed
> > libatlas-cpp-0.5 to libatlas-cpp-0.5c2 because this was our plan. Every
> > package without c102 (from old ABI changes) will get c2 and the other
> > library packages with a c102 suffix, the c102 will be removed.
> >
> > For Debian there was another decision, and it's in the responsibilty of
> > the Debian package maintainer, if he wants to rename or not. (If I recall
> > the mail correctly).
>
> Absolutely not.  Renaming of library packages on ABI change is mandatory in
> Debian, just as it was for Ubuntu.

Well, yes. But not in the same way as we did in Ubuntu.
Please recall:

[1] http://lists.debian.org/debian-devel/2005/06/msg00315.html

This was the first plan of Matthias, in this post he wrote at least exactly 
this, what we did in Ubuntu.
c102 suffixes will be dropped during rename, and c2 will be added to lib 
packages where no c102 was added during the first transition.

After a while Matthias posted this:

[2] http://lists.debian.org/debian-devel/2005/07/msg00064.html

I'm refering to this paragraph:


There has been a concern about re-renaming library packages
libfoo1c102 back to libfoo1, because this might break third party
packages on systems, that are directly upgraded from potato to etch.
I don't know any of these, but if a package maintainer thinks it's
worth supporting these packages and upgrades, please rename the
package to libfoo1c2. In this case you have to keep the libfooc1
conflict/replace and add the libfoo1c102 conflict/replace.


So actually there was a change in the plan, and during the Dapper Merge Run we 
have right now, we found some packages which are renamed differently from the 
plans discussed in [1].

> Anyway, the fact that there was never a c102 version of libatlas-cpp-0.6 in
> Debian or Ubuntu certainly cuts down on the chances of there being an
> incompatible libatlas-cpp-0.6-0c2 package in the wild.  So it's not
> *crucial* that this package be named -0.6-0c2a, but it would be nice to not
> have gratuitous inter-distro incompatibilities when they can be avoided.

Well, I will try to revert the change, no problem. But even for 
libatlas-cpp-0.6 there was a soname change (if you see this bugreport about 
the rename of libatlas-cpp-0.5) and there was no need to rename 
libatlas-cpp-0.6 because the soname change was introduced by a new upstream 
source. 

When I got the merge report into my hands for libatlas-cpp-0.6, there was no 
renaming in rev 1, so I had to add c2a as soname change. I just saw too late, 
that there was a rev 2 of this package, and in this rev a renaming was made.

At the time of the merge, I was right. There is now a difference between 
ubuntu and debian. I'm sorry for that, but I don't change it right now. If 
there is a new upstream of atlas-cpp, we can try to bring the two packages 
again in sync.

Regards,
\sh


pgpsY1K7ZdLts.pgp
Description: PGP signature

Re: Stephen Frost MIA?

[Stephen Frost]

* Jos? Luis Tall?n ([EMAIL PROTECTED]) wrote:
> Having sent you e-mails with my last answers to the Tasks&Skills
> stage of the NM process on 2005/10/05, and having received receipt
> confirmation from you on 2005/10/18, i still have no answer from you.
> Moreover, i have ping'd you on 2005/10/07, 10/12, 10/15 and 21/11;
> No answer so far either.

Err, I replied to one of your pings on 10/17.  I don't think I really
need to reply to each and every one individually.  Did you not get the
reply I sent?

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: Stephen Frost MIA?

[Andrew Suffield]

On Wed, Nov 30, 2005 at 09:25:31AM -0600, Graham Wilson wrote:
> On Wed, Nov 30, 2005 at 08:48:44AM +0100, Martin Zobel-Helas wrote:
> > how about sending this to Frontdesk <[EMAIL PROTECTED]> or MIA,
> > <[EMAIL PROTECTED]> instead of spamming debian-devel with that?
> 
> Since when is a message that is on topic (or at least relevant) to
> Debian development spam?

Everything on -devel is spam these days, didn't you get the memo?

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: BTS down?

[Gregor Jasny]

Hi,

Don Armstrong schrieb:
> On Mon, 21 Nov 2005, Gregor Jasny wrote:
> 
>>Bastian Venthur schrieb:
>>
>>>Can somebody confirm that there is a problem with the BTS?
>>
>>I've got the same setup and the same problem. Still no confirmation
>>from bugs.debian.org.
> 
> The BTS is currently receiving mail properly and acting on it
> properly, as near as I can tell.
> 
> Just use reportbug; if necessary, point it directly at
> bugs.debian.org.
> 
> If you give me the precise message ID and the time of your message, I
> may be able to track it down if it ever actually reached spohr.

It happened again. This time I have a tcpflow log of the communication
with spohr. The Massage-Id is: 1EhVNQ-tO-LD, the message was sent at
17:04 UTC. I have attached the tcpflow dump.

I hope you can track down the error.

Thanks,
Gregor
ehlo [127.0.0.1]
mail FROM:<[EMAIL PROTECTED]> size=1321
rcpt TO:<[EMAIL PROTECTED]>
data
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Gregor Jasny <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: fbdesk must depend on libxft
X-Mailer: reportbug 3.17
Date: Wed, 30 Nov 2005 19:05:15 +0100
X-Debbugs-Cc: [EMAIL PROTECTED]

Package: fbdesk
Version: 1.1.5-1
Severity: grave
Justification: renders package unusable

Hi,

fbdesk is linked against the shared library libXft.so.1. But it does not
depend on the libxft1 package. Beside that, it seems that libxft1 is not
available in Sid anymore.

Thanks,
Gregor

-- 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.14.2
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages fbdesk depends on:
ii  libc62.3.5-8 GNU C Library: Shared libraries an
ii  libgcc1  1:4.0.2-4   GCC support library
ii  libpng12-0   1.2.8rel-5  PNG library - runtime
ii  libstdc++5   1:3.3.6-10  The GNU Standard C++ Library v3
ii  xlibs6.8.2.dfsg.1-10 X Window System client libraries m

fbdesk recommends no packages.

-- no debconf information
.
quit
220 spohr.debian.org ESMTP Exim 4.50 Wed, 30 Nov 2005 09:04:15 -0800
250-spohr.debian.org Hello p54b3a652.dip0.t-ipconnect.de [84.179.166.82]
250-SIZE 62914560
250-PIPELINING
250 HELP
250 OK
250 Accepted
354 Enter message, ending with "." on a line by itself
250 OK id=1EhVNQ-tO-LD
221 spohr.debian.org closing connection

Re: Best tool for patch update use case?

[Florian Weimer]

> I was really asking for a GUI tool that allows me to update the current
> patches, one by one, to the current upstream sources, going through
> each patch chunk and letting me update the chunk if it doesn't apply
> correctly. 

Ah, something like an interactive three-way merge?  ediff, kdiff3 and
meld, and probably others can do this.  They don't work directly on
patch files, though, so you'd have to write a short script to create
the proper input files and diff the result.


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

Re: Stephen Frost MIA?

[Nico Golde]

Hi,
* José Luis Tallón <[EMAIL PROTECTED]> [2005-11-30 18:23]:
> Having sent you e-mails with my last answers to the Tasks&Skills
> stage of the NM process on 2005/10/05, and having received receipt
> confirmation from you on 2005/10/18, i still have no answer from you.
> Moreover, i have ping'd you on 2005/10/07, 10/12, 10/15 and 21/11;
> No answer so far either.

[...] 
Please consider reading this:
http://www.us.debian.org/doc/developers-reference/ch-beyond-pkging.en.html#s-mia-qa
Kind regards
Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org
Forget about that mouse with 3/4/5 buttons -
gimme a keyboard with 103/104/105 keys!


pgpsN47VcDNGs.pgp
Description: PGP signature

Re: dpkg-sig support wanted?

[Colin Watson]

On Tue, Nov 29, 2005 at 02:20:55PM +0100, Florian Weimer wrote:
> * Anthony Towns:
> > On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
> >> In terms of security, there are some better hash functions.  
> >
> > My understanding was that there aren't other hash functions that've had
> > remotely similar levels of cryptographic analysis to md5 and sha.
> 
> Neither MD5 nor SHA1 have received much public scrutiny.  Dobertin's
> work on MD5 has never been fully published.  I've already joked that
> the difference between Wang et al. and European or U.S. cryptographers
> is that the Chinese government doesn't tell their researchers not to
> publish their results. 8-P
> 
> > IIRC, the elliptic curve cryptography stuff was supposed to be
> > similarly neat, until people started analysing it seriously, at
> > which point it broke.
> 
> The NSA has recently licensed ECC patents from Certicom.
> 
> There are weak elliptic curves as far as cryptography is concerned,
> but there are also others: inefficient ones and those which have been
> patented by Certicom.

A cryptographer friend of mine recently attended the NIST Hallowe'en
Hash Bash (http://www.csrc.nist.gov/pki/HashWorkshop/index.html), and
made a few notes in his blog:

  http://www.livejournal.com/users/sevenstring/7326.html

His suggestion there was "stick to SHA2 (or maybe Whirlpool) for now".
Did anyone else here attend this workshop?

That said, I suspect that any "my favourite algorithm" argument is going
to get horribly bogged down in bikeshedding. As long as we don't fall
into the multicollisions trap of spending more and more CPU time
generating and checking more and more iterative hash functions that
don't actually add significant collision-resistance when you check them
all together, a generalised checksumming tool as proposed seems an
obviously sensible and desirable thing to have.

-- 
Colin Watson   [EMAIL PROTECTED]


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

OTOMATIK KAPI VE KEPENK

[GÖKERMAKİNA]

SAYIN YETKİLİ
 
ALÜMİNYUM VE GALVENİZ PROFİLDEN HER NEVİ KEPENK 
YAPIMI İLE GARAJ KAPILARI OTOMASYONU,BARİYER,MANTAR BARİYER VE FOTOSELLİ KAPILAR 
KONUSUNDA HİZMET VERMEKTEYİZ.
AYRINTILI BİLGİ İÇİN www.gokermakina.com ADLI WEB SAYFAMIZDAN 
YADA 0216 472 97 29 - 30 NOLU TELEFONLARIMIZDAN BİLGİ 
ALABİLİRSİNİZ.
 
SAYGILARIMIZLA / GÖKER 
MAKİNA

Re: dpkg-sig support wanted?

[Colin Watson]

On Mon, Nov 28, 2005 at 07:07:22PM +1000, Anthony Towns wrote:
> (Note that "dsum" would probably need to become Priority:required,
> and possibly Essential:yes, with the complications that entails)

Stick it in dpkg.deb. There's plenty of precedent for that (some
not-so-good, but I think mostly good).

-- 
Colin Watson   [EMAIL PROTECTED]


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

XyMTeX in TeX live

[Norbert Preining]

Hi Karl!

I hope life after release of TL2005 has settled down a bit and the
discussions about Lucida fonts are going well!?

ATM I have a different question: In the course of trying to get TeX live
into Debian, a discussion about the licensing of XyMTeX occurred. Short
background:

Kevin McCarty wanted to package XyMTeX for Debian, and found several
interesting license conditions in the files contained in the
distribution of XyMTeX. Afte consulting the debian-legal mailing list he
wrote an email to the author of XyMTeX to clear up the license
statements and got back, in essence (see full email below):
I regret to say that only personal redistribution (except CTAN)
is permissible.
Interstingly, the files state something a bit different:

% Copying of this file is authorized only if either
%
% (1) you make absolutely no changes to your copy, including name and
% directory name
% (2) if you do make changes,
% (a) you name it something other than the names included in the
% ``xymtex'' directory and
% (b) you acknowledge the original name.
% This restriction ensures that all standard styles are identical.

which seems to be ok in the sense that it is LPPL (more or less).

But as the explicite statement of the author does not permit
redistribution (and thus not even in TeX live), it would be nice if we
could ask him again if this is his intention, or if it wouldn't be
better to license the files as LPPL, allowing redistribution as
specified there.

If you agree with this interpretation, that the files would have to be
taken out of TeX live, we (actually Frank Küster suggested this) would
like you to ask him again about the license condition, as you are
responsible for TeX live (and more famous ;-).

If you think this is not your job and/or you don't want/have time to do
this, I will ask him myself, but better you than me!

Thanks a lot and all the best

Norbert


Here is the answer ofMcCarty and Shinsakus reply:

> From: Fujita Shinsaku <[EMAIL PROTECTED]>
> Subject: Re: Licensing questions about XyMTeX
> To: "Kevin B. McCarty" <[EMAIL PROTECTED]>
> Date: Mon, 25 Apr 2005 09:53:16 +0900
> 
> Dear Dr. McCarty
> 
> I regret to say that only personal redistribution (except CTAN) is 
> permissible. 
> Thank your for your kind attention to XyMTeX. 
> 
> Sincerely Yours
> 
> Shinsaku Fujita
> 
> ===
> 
> "Kevin B. McCarty" <[EMAIL PROTECTED]> wrote:
> 
> > Hello,
> > 
> > I hope my previous email didn't come at a bad time for you - I realize
> > it was probably unexpected.  When you have a chance, I would be very
> > grateful if you could look over my questions about XyMTeX licensing
> > (attached again below for your convenience) and respond.  I've found
> > XyMTeX a very useful tool, and I would love to see the Debian Project
> > distribute it, so that it might reach a larger audience.
> > 
> > best regards,
> > 
> > Kevin McCarty
> > 
> > On 04/14/2005 06:10 PM, Kevin B. McCarty wrote:
> > > Dear sir:
> > > 
> > > I just discovered XyMTeX today and I want to thank you for making such a
> > > useful LaTeX package available!  I am using it for my doctoral thesis.
> > > To make it easier for others to install, I would like to package XyMTeX
> > > for the Debian GNU/Linux operating system (please check
> > > http://www.debian.org/ if you are not familiar with it).  In order to do
> > > this I need to better understand some things about the license under
> > > which it is available.
> > > 
> > > 1) In some of the files compressed in the xymtx402.lzh file, you have
> > > the following statement:
> > > 
> > > % Copying of this file is authorized only if either
> > > %
> > > % (1) you make absolutely no changes to your copy, including name and
> > > % directory name
> > > % (2) if you do make changes,
> > > % (a) you name it something other than the names included in the
> > > % ``xymtex'' directory and
> > > % (b) you acknowledge the original name.
> > > % This restriction ensures that all standard styles are identical.
> > > 
> > > Is it permitted for people to distribute modified versions of XyMTeX as
> > > well as copying it, as long as they follow conditions 2a and 2b?  (In
> > > other words, do you intend "copying" to include "redistribution"?)
> > > 
> > > 2) Some of the files (the PDFs, for instance) do not include a licensing
> > > statement, and there is no license that specifically encompasses every
> > > file.  Under what license do you intend to distribute those files?
> > > 
> > > 3) Some files, for instance doc402/jobdoc402/xymps402.tex, contain a
> > > statement "This file is not permitted to be translated into Japanese and
> > > any other languages."  May I ask the reasoning behind this?  This
> > > restriction would not make it possible to distribute XyMTeX in the
> > > "main" section of software distributed by Debian; it would have to go
> > > into the so-called "non-free" section which is

Re: dpkg-sig support wanted?

[Florian Weimer]

* Henning Makholm:

> Scripsit Florian Weimer <[EMAIL PROTECTED]>
>> * Jochen Voss:
>
>>> I found the example at http://www.cits.rub.de/MD5Collisions/ quite
>>> impressive.  They have two different valid PostScript files with
>>> identical MD5 sums.  I don't know how much computing time they used,
>>> though.
>
> They claim a few hours:
>
> | Based on [WY05] and the analysis described in [Da], we implemented
> | an attack to find random collisions for the MD5 compression
> | function. It took just a few hours on a customary PC.

I can no longer recall if this paragraph was present in the original
version of the page; I didn't notice it when I read it for the first
time.

>> None, many of these examples were created before the collision
>> generation tools were generally available.
>
> They did create or use a collision, as anyone can verify simply by
> downloading the files.

One collision was published by Wang et al. as a zero-knowledge proof
of their discovery.  I thought they had reused this one, like many
others did.

>> The "exploit" uses some properties of Postscript files which make
>> them not very desirable for storing electronic documents which
>> cannot be altered.
>
> There is absolutely no reason to put the word exploit in scare quotes
> here.

Strictly speaking, you cannot exploit MD5 itself, you can only exploit
security systems that rely on some property of the MD5 function.

Let's look what happens in the attack published by the RUB
researchers:

  1. The attacker creates two Postscript files with the same MD5 hash.
  2. The attacker submits one of the file to the victim.
  3. The victim views the file in his Postscript viewer, doesn't notice
 anything strange, and signs it.
  4. The attacker obtains the signature, and uses it together with the
 second file he has created.

A successful attack is possible if the following conditions are met:
(a) the attacker can create a suitable collision, (b) the victim uses
the document supplied by the attacker, (c) the victim only checks one
presentation form of the document, and (d) the document is used in a
way which does not lead to the victim disputing the signature, and
into investigation (which would immediately reveal the attack).

It turns out that we can actually do without (a).  Have a look at the
attached Postscript with your favorite Postscript viewer, and sign it
if you agree with its message. 8-)

In my opinion, this modified attack strongly suggest that the process
described above is already substantially broken.  MD5 is just a weak
part among others.  As a result, the attack doesn't show what people
claim.

Just be clear: I don't claim everything is alright with MD5.  For most
applications, you should definitely migrate to something else (what is
a different question).  But most organization's resources are limited,
you can't afford to migrate too often, and you deal with many issues
at once.  Correctly analyzing the relevance of security issues is very
important.  Misleading claims about the impact of new attacks are not
helpful, may lead to wrong allocation of resources, and prevent more
important vulnerabilities from being addressed.

> You might want to notice that the "properties" you apparently think
> invalidate the example are also shared by many common formats for
> software. An ELF binary can easily be crafted to contain a blob of
> initialized data whose contents are only used for checking whether to
> enable some malicious machine code that is always present - and this
> would not be easily detectable at all.

In general, any form of malicious code is not easy to detect.  But the
malicious code must be present in the first place.  You can use a MD5
collision to make it dormant, but it has to be there.

This means that it's dangerous to commit yourself to the contents of a
document, using a digital signature, unless you fully understand the
meaning of each byte in the document.

>> (Note the "rub.de" part of the URL.  A clear warning sign.)
>
> The nice thing about ad hominem arguments is that you can make them
> without ever having to argue the merits of your case.

*shrug* The computer security folks at that university started
spreading FUD about various security systems, mainly rehashing the
work of others.  They seem to be in it mostly for the publicity.



psTcrNiJNRKU.ps
Description: PostScript document

Re: Stephen Frost MIA?

[Graham Wilson]

On Wed, Nov 30, 2005 at 08:48:44AM +0100, Martin Zobel-Helas wrote:
> how about sending this to Frontdesk <[EMAIL PROTECTED]> or MIA,
> <[EMAIL PROTECTED]> instead of spamming debian-devel with that?

Since when is a message that is on topic (or at least relevant) to
Debian development spam?

-- 
gram


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

Re: ITP: ladder.app -- GNU Go frontend for GNUstep

[Jochen Voss]

On Wed, Nov 30, 2005 at 08:55:40AM -0500, James Vega wrote:
> Indicating that gnugo is the engine is relevant, but specifying that a
> recent version of gnugo need be installed is not.  In fact, that part of
> the description could become invalid depending on the development of
> both gnugo and ladder.app.
I agree.

All the best,
Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Re: How to automatically update files on alioth from svn

[Marc Haber]

On Wed, 30 Nov 2005 15:31:34 +0100, Frank Küster <[EMAIL PROTECTED]>
wrote:
>Yann Dirson <[EMAIL PROTECTED]> wrote:
>> Frank wrote:
>>> - how to authenticate the transfer, since the svn repository and the
>>>   webspace is on different machines.
>>
>> https or svn+ssh to access the repo should provide the level of
>> authentication you need, or do I miss something ?
>
>With svn+ssh, I'd need a key without a password that allows logging into
>the SVN server machine;  I'd prefer not to have that.

You could restrict that key to be valid only from the IP address
belonging to the client box, and it should be possible to restrict the
key only to invoke a read-only svn server. I didn't try that with svn,
though.

For example,
|from="127.0.0.1",command="svnserve -t" ssh-rsa 
B3NzaC1yc2EBIwAAAQEAu0DKRi2tHpQcpFLuBqLvS/LbOnBTMlkprHuJSQeglX/LW1
in an authorized_keys file allows the key to only be used if the
connection comes from localhost, and it _always_ invokes svnserve -t
instead of whatever command was requested on the command line. This
gives, however, read/write access to the repository.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: texlive-basic_2005-1_i386.changes REJECTED

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le mardi 29 novembre 2005 à 22:48 +0100, Norbert Preining a écrit :
>> There is a lot of duplication in Debian, and up to now nobody has
>> complaint. We are working on taking out and packagin *big* stuff (like
>> font packages: lmodern, cm-super) so that they can be used with both
>> teTeX and TeX live. The work on TeX live for Debian has actually led to
>> this and an improved TeX Policy.
>
> Why do we need two packages containing the "latex" command, for example?

Why do we need N packages that provide MTA functionality?

> When there is duplication, there is generally a reason behind it. We
> have several "ping" packages, but they all have different advantages and
> drawbacks. What does texlive's "latex" command bring that tetex'
> doesn't? And if it brings something, is there any point in using tetex?

Have you actually read the discussion following the ITP that you were
pointed to?  I don't like to repeat all that...

- Both packages have different release cycles; teTeX has been released
  at about the same frequency as Debian, causing it to be outdated by
  one major version in woody and sarge, I don't remember potato.
  TeXLive has a planned release cycle of "once per year", implying that
  chances are much bigger chance to get a recent pdfTeX (the executable
  behind the "latex" command) and LaTeX (the format behind it), along
  with more recent CTAN packages, into a Debian release.

- teTeX, being smaller and less modular, will continue to be the system
  of choice for Build-Depends and for packages that depend on a TeX
  system because they use it for some internal purpose (e.g. creating
  PDF files from database content, from docbook sources,...).  It is
  also better for people who simply want to use LaTeX (or TeX, or
  ConTeXt), but not bother about the newest, coolest CTAN packages.
  TeXLive, on the other hand, would be the system of choice for people
  that want to create (La,Con)TeX documents according to current
  state-of-the-art, and want to communicate and get or give support in
  TeX-related newsgroups and mailinglists (where "do you have the latest
  version installed" is usually one of the first questions).

You can read more arguments in the ITP, see the link given earlier.

>> > How can users know which package to install to get a working TeX system?
>> 
>> Yes, a TeX system is *not* for the faint of heart! It is more complex
>> and definitely bigger than anything in Debian. You cannot expect that a
>> complete novice becomes a TeXnician by using the Debian packages. We
>> take from the users the burden to care for formats, font maps and
>> various other things. But flexibility has to be paid by complexity.
>> That's live.
>
> Bullshit. TeX is not that complicated, and it is used by
> non-specialists. It is much simpler than a C++ development system, for
> example. But when someone installs g++, he gets a working C++ compiler.

So install teTeX.  That's the collection of packages for the people who
want to use TeX as non-specialists, like you do.  TeXLive is for the
others.

This is not just a pet project of Norbert.  For a long time, it has been
a wish of the Debian users among the TeXlive developers and users to be
able to install "their" TeXlive on their Debian system, without keeping
teTeX or fiddle with equivs just to satisfy dependencies.  

I think that it would be to the benefit of our users (one group of them,
actually) to have TeXLive in Debian.  It's for the benefit of an other
group to keep teTeX, and to keep it less modular (but with a better
splitting between -base and -extra, as we currently discuss on
debian-tetex-maint). 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Bug#341425: ITP: libmail-date-perl -- RFC2822 compliant date-time conversion

[Stephen Quinney]

Package: wnpp
Severity: wishlist
Owner: Stephen Quinney <[EMAIL PROTECTED]>

* Package name: libmail-date-perl
  Version : 0.09
  Upstream Author : Masanori HATA <[EMAIL PROTECTED]> (Saitama, JAPAN)
* URL : http://www.cpan.org/authors/id/H/HA/HATA/
* License : GPL (>= 1) or Perl Artistic
  Description : RFC2822 compliant date-time conversion

 The well-known RFC822 has been obsoleted by RFC2822 since April 2001
 and the standard format of expression for date-time was updated in
 the RFC2822. This lightweight module provides a method for converting
 the time in seconds since the epoch along with the local timezone
 into the correctly formatted RFC2822 representation.


-- 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.14-2-k7
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


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

Re: Non-DFSG TeXLive stuff

[Frank Küster]

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

> Norbert Preining wrote:
>
>> To my reading that thread didn't end in a conclusion that it is not 
>> acceptable.
>> 
>> Furthermore, IMHO, if it would be *not* acceptable, then we would
>> have to remove all, I repeat  *ALL* LPPL licensed packages.
>> 
>> I guess this is something we don't want to have in Debian.
>
> Yes, I figured that the LPPL could probably squeak by debian-legal
> (otherwise I wouldn't have ITP'ed XyMTeX), but I was more concerned
> about the somewhat contradictory-seeming reply from upstream.  Possibly
> he has misinterpreted the meaning of the LPPL?  But when there is a
> conflict between the written license in the package and the author's
> expressly stated wishes, it seems safest to assume that the latter are
> valid.

I'm not sure, but it seems to me as if the lppl allows derived works to
be licensed more restrictively, even with proprietary, no-sell, or
similar licenses.  Therefore, it might be that it is not a
misinterpretation of the LPPL by XymTeX's author, but instead a
deliberate decision.

>> This [upstream's reply] seems strange, I guess there was a
>> misunderstanding, because the right to distribute the file unchanged
>> is given in the file itself. Hard to say since we don't see the mail
>> exchange with Shinsaku Fujita.
>
> I attach our entire email exchange (with some extraneous headers
> removed).  I emailed once, to which he didn't reply; sent a follow-up
> email about a week later; and he finally gave the brief reply I quoted
> earlier.  Apologies for the top-quoting in this exchange.
>
> I wasn't quite sure what to make of his reply so I didn't follow up
> further.  Probably TeX Live or someone else distributing XyMTeX should
> do so, though.

Indeed; perhaps telling him that the Software will be taken off TeXLive
and moved to the new nonfree branch on CTAN will make him rethink his
decision. 

Norbert, Karl for sure has more of a name than you and I - do you think
he has time to contact him?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: How to automatically update files on alioth from svn

[Frank Küster]

Yann Dirson <[EMAIL PROTECTED]> wrote:

> Frank wrote:
>
>> - how to authenticate the transfer, since the svn repository and the
>>   webspace is on different machines.
>
> https or svn+ssh to access the repo should provide the level of
> authentication you need, or do I miss something ?

With svn+ssh, I'd need a key without a password that allows logging into
the SVN server machine;  I'd prefer not to have that.  What do you mean
with https?  I don't want to only check out individual files from a
websvn site, but complete directories, including new files.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: sparc64 system?

[Frans Pop]

On Wednesday 30 November 2005 14:49, Bernd Eckenfels wrote:
> I need a sparc64 test system to debug a bus  error (#340384).
> Cananybody tell me where I get an account, or do the debug symbols
> compile and backtrace for me? And also update the availability
> information of vore in the db.

I can give you an account on my Ultra10.
Contact me on IRC (nick fjp, both networks) or by mail for details if 
you're interested.

Cheers,
FJP


pgpcAgqOxEQIU.pgp
Description: PGP signature

Re: texlive-basic_2005-1_i386.changes REJECTED

[Frank Küster]

Joerg Jaspert <[EMAIL PROTECTED]> wrote:

> On 10488 March 1977, Frank Küster wrote:
>
>allrunes   dfsg
>Please: Tell me its not true that the DFSG is used as a license there.
 As stated in the License file, this list was generated from the TeX
 Catalogue, which *can be wrong*! If you check the actual allrunes files,
 you see that it is LPPL.
>>> I really hope you've done this --- for all files --- before uploading.
>>> Also, there are several versions of the LPPL, at least one of which
>>> might have DFSG issues.
>> Note that teTeX is worse in this respect (#218105), and that having two
>> (groups of) maintainers work on this will speed up resolving that bug,
>> while rejecting texlive because it's copyright file is still not ideal
>> will not.
>
> Just because something else is worse than this isnt a reason to allow
> another bad thing. That argumentation doesnt work.

So far for the first part of my sentence.  The second part means:  With
texlive in Debian, the chances to resolve #218105 for etch get
realistic. 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Best tool for patch update use case?

[[EMAIL PROTECTED]]

Florian Weimer wrote:
> > What tool do you think is the easiest to perform this task?
> In the Debian context, most developers who maintain individual patches
> use dpatch.  quilt is a similar tool.  There's also Chris Mason's mq
> extension for Mercurial, and Stacked GIT, but these haven't been
> packaged for Debian yet.

I was really asking for a GUI tool that allows me to update the current
patches, one by one, to the current upstream sources, going through
each patch chunk and letting me update the chunk if it doesn't apply
correctly. 



Prueba el Nuevo Correo Terra; Seguro, Rápido, Fiable.

sparc64 system?

[Bernd Eckenfels]

Hallo,

according to db.debian.org we have two sparc machines (aric and vore) for
Developers. However vore seems to be unable, and on auric I can't log in.
(it wont ask me for the pubkey i have in the databse and it wont accept the
password)

I need a sparc64 test system to debug a bus  error (#340384). Cananybody
tell me where I get an account, or do the debug symbols compile and
backtrace for me? And also update the availability information of vore in
the db.

Gruss
Bernd
-- 
  (OO) -- [EMAIL PROTECTED] --
 ( .. )[EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o   1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+49721151516129
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!


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

Re: ITP: ladder.app -- GNU Go frontend for GNUstep

[James Vega]

On Wed, Nov 30, 2005 at 01:28:30PM +, Jochen Voss wrote:
> On Wed, Nov 30, 2005 at 07:31:21AM -0500, Roberto C. Sanchez wrote:
> > On Wed, Nov 30, 2005 at 12:59:07PM +0100, Gürkan Sengün wrote:
> > > It uses gnugo as its
> > > engine and you must have a recent version of gnugo installed in order to 
> > > run 
> > > it.
> > This statement is unnecessary.  You use dependencies to specify that.
> 
> I think that the use of gnugo is a significant piece of information
> about the package.  When selecting a program to play Go against you
> would want to know what opponent (playing strength/style/...) you
> will be facing.  It would be awkward to find this from the dependency
> list and thus should be in the package description.

Indicating that gnugo is the engine is relevant, but specifying that a
recent version of gnugo need be installed is not.  In fact, that part of
the description could become invalid depending on the development of
both gnugo and ladder.app.

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


pgpOCDBYDPUI7.pgp
Description: PGP signature

Re: ITP: ladder.app -- GNU Go frontend for GNUstep

[Jochen Voss]

Hello Robert,

On Wed, Nov 30, 2005 at 07:31:21AM -0500, Roberto C. Sanchez wrote:
> On Wed, Nov 30, 2005 at 12:59:07PM +0100, Gürkan Sengün wrote:
> > It uses gnugo as its
> > engine and you must have a recent version of gnugo installed in order to 
> > run 
> > it.
> This statement is unnecessary.  You use dependencies to specify that.

I think that the use of gnugo is a significant piece of information
about the package.  When selecting a program to play Go against you
would want to know what opponent (playing strength/style/...) you
will be facing.  It would be awkward to find this from the dependency
list and thus should be in the package description.

All the best,
Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Re: Best tool for patch update use case?

[Florian Weimer]

> What tool do you think is the easiest to perform this task?

In the Debian context, most developers who maintain individual patches
use dpatch.  quilt is a similar tool.  There's also Chris Mason's mq
extension for Mercurial, and Stacked GIT, but these haven't been
packaged for Debian yet.


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

Re: ITP: ladder.app -- GNU Go frontend for GNUstep

[Roberto C. Sanchez]

On Wed, Nov 30, 2005 at 12:59:07PM +0100, Gürkan Sengün wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: ladder.app
>  Version : 1.0
>  Upstream Author : Banlu Kemiyatorn <[EMAIL PROTECTED]>
> * URL : http://www.nongnu.org/gap/ladder/index.html
> * License : GNU GPL
>  Description : GNU Go frontend for GNUstep
>  This is a graphically pleasing implementation of Go.

> It uses gnugo as its
> engine and you must have a recent version of gnugo installed in order to run 
> it.
This statement is unnecessary.  You use dependencies to specify that.
Unless for some reason you don't depend on it (e.g., the user may
actually want to install the front end without the engine) you needn't
mention it in the description.

-Roberto

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


pgpYmRoqdEMt7.pgp
Description: PGP signature

Best tool for patch update use case?

[[EMAIL PROTECTED]]

I have this use case:
I have a bunch of patches in a folder and I'd like to update them to the
latest version of the upstream software as easily as possible.

It's the use case that a typical Debian maintainer faces when he has to
upgrade the upstream sources and there's patches added there and patches
that don't apply correctly anymore.

What tool do you think is the easiest to perform this task?



Prueba el Nuevo Correo Terra; Seguro, Rápido, Fiable.

Bug#341388: ITP: libvmime -- a C++ mail library

[Mattias Nordstrom]

Package: wnpp
Severity: wishlist
Owner: Mattias Nordstrom <[EMAIL PROTECTED]>


* Package name: libvmime
  Version : 0.8.0
  Upstream Author : Vincent Richard <[EMAIL PROTECTED]>
* URL : http://www.vmime.org/
* License : GPL
  Description : a C++ mail library

 VMime is a powerful C++ class library for parsing, generating, or editing
 Internet RFC-[2]822 and MIME messages. VMime is designed to provide a fast
 and an easy way to manipulate Internet mail messages.
 .
 The recent releases of VMime also include support for using messaging
 protocols (POP3, IMAP, SMTP and maildir) with a lot of features supported:
 listing folders, downloading and adding messages to folders, extracting parts
 from message, getting and setting message flags, and a lot more.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

ITP: ladder.app -- GNU Go frontend for GNUstep

[Gürkan Sengün]

Package: wnpp
Severity: wishlist

* Package name: ladder.app
 Version : 1.0
 Upstream Author : Banlu Kemiyatorn <[EMAIL PROTECTED]>
* URL : http://www.nongnu.org/gap/ladder/index.html
* License : GNU GPL
 Description : GNU Go frontend for GNUstep
 This is a graphically pleasing implementation of Go. It uses gnugo as its
engine and you must have a recent version of gnugo installed in order to 
run it.

.

Homepage: http://www.nongnu.org/gap/ladder/index.html


-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc
Locale: LANG=POSIX, LC_CTYPE=POSIX


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

Re: too long to build 2.6.14.2 kernel

[Luca Capello]

Hello!

On Tue, 22 Nov 2005 23:49:34 +0100, Andreas Orfanos wrote:
> I try to produce some statistical data with different kernels. The
> latest 2.4.32 takes an average 6 minutes to build (~500
> objects). But 2.6.0 takes more than half an hour for (~3000objects
> and more). The latest 2.6.14.2one hour and more,
> and again we are talking for thousands of object files. I was using
> a 2GHz Pentium for the builds.

FYI, with the linux-source-2.6.14 and the linux-image-2.6.14-2-686
.config (so, all drivers as module) I got:
=
[EMAIL PROTECTED]:~/src/linux-2.6.15-rc3$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
 --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
 --enable-shared --with-system-zlib --libexecdir=/usr/lib
 --without-included-gettext --enable-threads=posix --enable-nls
 --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
 --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
 --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
 --enable-mpfr --disable-werror --enable-checking=release
i486-linux-gnu
Thread model: posix
gcc version 4.0.3 2005 (prerelease) (Debian 4.0.2-4)

[EMAIL PROTECTED]:~/src/linux-source-2.6.14$ time fakeroot make-kpkg
real34m9.394s
user30m30.182s
sys 2m19.645s

[EMAIL PROTECTED]:~/src/linux-source-2.6.14$ fakeroot make-kpkg clean

[EMAIL PROTECTED]:~/src/linux-source-2.6.14$ time fakeroot make-kpkg \
 kernel_image
real35m34.851s
user31m26.494s
sys 2m25.501s

[EMAIL PROTECTED]:~/src/linux-source-2.6.14$
=

This is on a IBM ThinkPad T42p: Pentium-M 745 (1.80GHz) and 512MB RAM.

Thx, bye,
Gismo / Luca


pgpb9uNq1nDSQ.pgp
Description: PGP signature

Re: Stephen Frost MIA?

[José Luis Tallón]

Martin Zobel-Helas wrote:

>Hi José,
>
>how about sending this to Frontdesk <[EMAIL PROTECTED]> or MIA,
><[EMAIL PROTECTED]> instead of spamming debian-devel with that?
>  
>
Thank you for the suggestion. Will do that in the future.

J.L.


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Josselin Mouette]

Le mardi 29 novembre 2005 à 22:48 +0100, Norbert Preining a écrit :
> > When did I ask you to make one single binary package?
> 
> Even if I take five packages each of it will be bigger than anything
> else in Debian and completely unable to be handled.

TeX is big, I'd expect packages to be big. How is it an issue?

> > And there's a duplication of most TeX components. I hope there is some
> > plan to merge those packages some day in the future.
> 
> There is a lot of duplication in Debian, and up to now nobody has
> complaint. We are working on taking out and packagin *big* stuff (like
> font packages: lmodern, cm-super) so that they can be used with both
> teTeX and TeX live. The work on TeX live for Debian has actually led to
> this and an improved TeX Policy.

Why do we need two packages containing the "latex" command, for example?
When there is duplication, there is generally a reason behind it. We
have several "ping" packages, but they all have different advantages and
drawbacks. What does texlive's "latex" command bring that tetex'
doesn't? And if it brings something, is there any point in using tetex?

> > How can users know which package to install to get a working TeX system?
> 
> Yes, a TeX system is *not* for the faint of heart! It is more complex
> and definitely bigger than anything in Debian. You cannot expect that a
> complete novice becomes a TeXnician by using the Debian packages. We
> take from the users the burden to care for formats, font maps and
> various other things. But flexibility has to be paid by complexity.
> That's live.

Bullshit. TeX is not that complicated, and it is used by
non-specialists. It is much simpler than a C++ development system, for
example. But when someone installs g++, he gets a working C++ compiler.

> > texlive-latex-base or texlive-foobar-stuff ? Worse, how can he know what
> > Debian package to install when a .sty is missing? Will it be in
> 
> This has been the same since many many years: How does one know that if
> you want to install pshan.sty you have to install the cjk package in
> Debian? And this does not happen only with TeX files, I often enough
> have to search packages.debian.org for a specific file.

And we should try to avoid the need to rely on such tools instead of
increasing it. Most issues of regular Debian users can be solved by
installing the right package. But the problem is how they can know which
package to install.

Regards,
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom