Re: Bug#229357: Can we require build-arch/indep targets for lenny?
In article <[EMAIL PROTECTED]> (gmane.linux.debian.devel.general) you wrote: > On Fri, Jun 29, 2007 at 12:41:04AM +0300, Guillem Jover wrote: [...] >> I've been pondering on what's the cleanest way to fix it for some time, >> and I tend to agree with Steve about using the make options to test >> for the existence of the targets. But as others have pointed out it's >> not clear why that change was reverted at the time. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=345;att=0;bug=218893 | -q checks for "up to dateness" ... the next time you ran the test, it | would fail because build-stamp had been touched and dpkg-buildpackage | would incorrectly run build for you instead. > One of the issue is that tools like sbuild and pbuilder which want to > take advantage of the Build-Depends-Indep split needs to know whether > dpkg-buildpackage will call debian/rules build or build-arch. So if you > go that route, the exact criterium used by dpkg-buildpackage need to be > published as an interface. 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 2. install Build-Depends *and* Build-Indep-Indep for running dpkg-buildpackage differently (e.g without any modifier or with -b) cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Could someone clarify this...
> My understanding is that Debian declares a work non-free if a holder > of a software idea patent is *actively enforcing* a patent that covers > the work, such that Debian cannot distrigute the work as free > software. Is there a known case where a holder actively enforces a patent that covers MPEG-4 video encoding? I am asking, because x264 has been removed out of the Debian archive and there are video codecs disabled in Debian's FFMPEG... Cheers, Fabian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intend to orphan pscan.
Dear debian-devel, I am maintaining a package that shares binary names with three others, cons, hsffig and pscan. I contacted their developpers in private, via debian-devel, and then through the BTS. I got an answer from the maintainer of cons, but the maintainers of hsffig and pscan, although active, have opted out answering. In the meantime, hsffig has been orphaned by others, and its removal is currently discussed. I would like to know if it is OK that I orphan pscan and open a discussion about its removal. Have a nice day, -- Charles Plessy Wako, Saitama, Japan Debian-Med packaging team. Le Mon, May 28, 2007 at 11:15:31PM +0900, Charles Plessy a écrit : > Dear Hwei, Uwe and John, > > I did not manage to contact you in private (see below), therefore by > policy 10.1 I have to move the discussion on debian-devel (copy sent to > debian-med). We (the members of the pkg-emboss project on Alioth) have > uploaded a new package in the experimental section of Debian, emboss, > which provides binary program with similar names as your packages. > > I would like to discuss what is the best solution to this problem for > our users. We have already explored a few possible directions on the > debian-med mailing list: > > http://lists.debian.org/debian-med/2007/04/msg00075.html > http://lists.debian.org/debian-med/2007/05/msg0.html > (The thread is split on two months) > > Basically, the plan would be to provide the binaries under their > original names in /usr/lib, and symlinks in /usr/bin. With such a setup, > a user can set his PATH in order to have access to the original names of > the binary programs. > > However, if I do not get answers, I will suppose that nobody cares about > the packages cons, pscan and/or hsffig anymore, and will request their > removal rather than complicating the things for the users of EMBOSS. > > Have a nice day, > > -- Charles Plessy, Wako, Saitama, Japan > > > - Forwarded message from Charles Plessy <[EMAIL PROTECTED]> - > > Date: Sat, 28 Apr 2007 18:53:45 +0900 > From: Charles Plessy <[EMAIL PROTECTED]> > To: Hwei Sheng Teoh <[EMAIL PROTECTED]>, Uwe Hermann <[EMAIL PROTECTED]>, > John Goerzen <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: New pacakge containing binaries with same name as some from the > packages cons, pscan and hsffig. > Reply-To: [EMAIL PROTECTED] > User-Agent: Mutt/1.5.13 (2006-08-11) > > Dear Hwei, Uwe and John, > > We have uploaded a package to experimental, "emboss", and it contains > binaries whose name are already "taken" by your packages: cons, pscan > and splitter. > > http://packages.qa.debian.org/e/emboss.html > > Emboss is a suite of many command line programs, it has web interfaces > and people use the program names in scripts. I am therefore quite > reluctant to rename the Emboss binaries, as I think that people will > just not use the package if I do this. > > I would like to have your opinion on what to do. The most > straightforward would be to swich the priorities of our packages to > extra and conflict on each other, but I do not know how to interpret the > policy... it this solution acceptable ? > > Have a nice day, > > > -- > Charles Plessy > Debian EMBOSS Packaging Team > Wako, Saitama, Japan > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > - End forwarded message - > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intend to orphan pscan.
Charles Plessy wrote: > Dear debian-devel, > > I am maintaining a package that shares binary names with three others, > cons, hsffig and pscan. I contacted their developpers in private, > via debian-devel, and then through the BTS. I got an answer from the > maintainer of cons, but the maintainers of hsffig and pscan, although > active, have opted out answering. You introduce a new package which ships files that conflict with existing packages... I don't see any good reason why you should decide to break the other packages without any good reason in the first place. > In the meantime, hsffig has been orphaned by others, and its removal is > currently discussed. > > I would like to know if it is OK that I orphan pscan and open a > discussion about its removal. I don't see a reason to orphan a package from an active maintainer unless that maintainer agrees. Now to the core: A package cons that ships /usr/bin/cons and a package pscan that ships /usr/bin/pscan makes sense and these binaries and project names exist for a long time. Why do you think a rename of the files /usr/bin/cons and /usr/bin/pscan in emboss is out of the question? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Fri, Jun 29, 2007 at 12:48:53PM -0400, Daniel Schepler wrote: > I guess it does. But I thought reopen was deprecated since the versioning > stuff was added to the BTS. However, the "notfixed" command issued earlier > didn't completely remove the "done" status from the bug... (And I thought > I'd tried notfixed earlier -- how come it worked for Touko Korpela but not > for me when afaict I tried exactly the same command?) > > So my question remains: what's the officially sanctioned, nondeprecated way > to > revert the effects of a versioned message to [EMAIL PROTECTED] reopen (I think that also clears the fixed list, don't tried it though, so you might need notfixed, too) The open/done status is independent of the found/fixed lists (which is probably a bug, but that how it is atm). Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Sat, Jun 30, 2007 at 11:56:56AM +0200, Frank Lichtenheld wrote: >> So my question remains: what's the officially sanctioned, nondeprecated way >> to >> revert the effects of a versioned message to [EMAIL PROTECTED] > reopen (I think that also clears the fixed list, don't tried it though, > so you might need notfixed, too) reopen clears the fixed list, yes. See http://wiki.debian.org/BugsVersionTracking . > The open/done status is independent of the found/fixed lists (which > is probably a bug, but that how it is atm). Note that it is only "independent" in the sense that it is ignored for most purposes if the fixed list is non-empty. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intend to orphan pscan.
Le Sat, Jun 30, 2007 at 12:13:45PM +0200, Luk Claes a écrit : > > Now to the core: > > A package cons that ships /usr/bin/cons and a package pscan that ships > /usr/bin/pscan makes sense and these binaries and project names exist for a > long time. Why do you think a rename of the files /usr/bin/cons and > /usr/bin/pscan in emboss is out of the question? Hi, Nowhere I have written that I will not rename the binaries from EMBOSS. Indeed, I will move them to /usr/lib/emboss and document in the README how to access them. However, in the process of solving that problem, I found two unmaintained pacages. One has already been orphaned by others, and its maintainer seems OK with this since he did not react. I am just asking if it is OK if I orphan pscan for the same reason, expecting that it will remove a burden for its maintainer. Hope that explains, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
upstream switch to GPLv3, packaging issues
Hi all! Ok, GPLv3 is out. Karl Berry the upstream of texinfo switched to GPLv3. No I am planning to upload a new texinfo package but have the following questions: - anything I have to take care for regarding the GPLv3? What was the stance of debian-legal? - GPLv3 is AFAIS not contained in /usr/share/common-licenses. Will it be included there soon, or should I include the full text in debian/copyright? Thanks a lot and all the best Norbert --- Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology Debian Developer <[EMAIL PROTECTED]> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HARBOTTLE (n.) A particular kind of fly which lives inside double glazing. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#431175: ITP: fact++ -- description logic reasoner for the semantic web
Package: wnpp Severity: wishlist Owner: Steffen Moeller <[EMAIL PROTECTED]> * Package name: fact++ Version : 1.1.7 Upstream Author : Dmitry Tsarkov * URL : http://code.google.com/p/factplusplus/ * License : GPL Programming Lang: C, C++, Java Description : description logic reasoner for the semantic web FaCT++ is a DL reasoner. It supports OWL DL as well as the forthcoming standard OWL 1.1. FaCT++ is implemented in C++ and uses optimised tableaux algorithms. The tool is probably best known for its compatibility with the tool Protege that helps to formally represent semantics. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: upstream switch to GPLv3, packaging issues
Norbert Preining <[EMAIL PROTECTED]> writes: > - anything I have to take care for regarding the GPLv3? What was the > stance of debian-legal? It would be nice if we could get an annotated copy of the GPLv3, explaining the legalese. I read through it in detail this morning, but an explanation of the implications of each clause would be quite useful, IMO. > - GPLv3 is AFAIS not contained in /usr/share/common-licenses. Will it > be included there soon, or should I include the full text in > debian/copyright? I just filed #431176 against base-files. I guess inclusion will depend on it being considered free (in -policy?). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpZso8bmRVnc.pgp Description: PGP signature
Re: Bug#431115: ITP: myspell-pt-br -- Brazilian Portuguese dictionary for myspell
On Friday 29 June 2007 22:48, Rafael Laboissiere wrote: > The myspell-pt-br package exists already in Debian but is generated from > the br.ispell pacakge, which is also maintained by me. The dictionary used > in br.ispell is largely outdated as regards the dictionary distributed by > the BrOffice team. Hence this ITP. Isn't the solution then to upgrade the master word list (perhaps from the one found in this myspell package), so the problem gets fixed for ispell, aspell and myspell rather than for myspell alone? Or am I perhaps misunderstanding something here? Thijs pgp5gT9FEQDsi.pgp Description: PGP signature
Re: Intend to orphan pscan.
On Sat Jun 30, 2007 at 18:43:36 +0900, Charles Plessy wrote: > I would like to know if it is OK that I orphan pscan and open a > discussion about its removal. I think it would be grossly rude to attempt to orphan a package which you do not maintain which has no bugs against it. (Except the naming collision that is currently being discussed.) As the "newcomer" I'd suggest that the solution would be for you to rename/move your binaries rather than forcing the previously working packages to change their names/behaviors. (Something I think you've agreed to do. Just sharing opinion.) pscan I previously maintained, use often, and would miss majorly if it were orphaned and removed. Steve -- pgpewpvXbaQ8w.pgp Description: PGP signature
Re: Bug#431115: ITP: myspell-pt-br -- Brazilian Portuguese dictionary for myspell
* Thijs Kinkhorst <[EMAIL PROTECTED]> [2007-06-30 15:36]: > On Friday 29 June 2007 22:48, Rafael Laboissiere wrote: > > The myspell-pt-br package exists already in Debian but is generated from > > the br.ispell pacakge, which is also maintained by me. The dictionary used > > in br.ispell is largely outdated as regards the dictionary distributed by > > the BrOffice team. Hence this ITP. > > Isn't the solution then to upgrade the master word list (perhaps from the one > found in this myspell package), so the problem gets fixed for ispell, aspell > and myspell rather than for myspell alone? Or am I perhaps misunderstanding > something here? In the past, the ispell, aspell, and myspell dictionaries for Brazilian Portuguese were generated from the br.ispell source package. Today, only ispell is generated from it. Unfortunately, development of br.ispell seems to have stopped. I agree with you that it would be better to generate the three dictionaries from a single, up-to-date word list, but I am not willing to commit myself with such development, due to time constraint. On the other hand, I am willing to maintain the separate packages developed by different upstream authors. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#431186: ITP: liblocale-hebrew-perl -- bidirectional (BiDi) Hebrew support for perl
Package: wnpp Severity: wishlist Owner: Lior Kaplan <[EMAIL PROTECTED]> * Package name: liblocale-hebrew-perl Version : 1.04 Upstream Author : Autrijus Tang <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~autrijus/Locale-Hebrew-1.04/ * License : Artistic License Programming Lang: Perl Description : bidirectional (BiDi) Hebrew support for perl A module implementing bidirectional Hebrew support for Perl. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Fri, 29 Jun 2007, Daniel Schepler wrote:
> So my question remains: what's the officially sanctioned,
> nondeprecated way to revert the effects of a versioned message to
> [EMAIL PROTECTED]
There are three reasonable ways, depending on the effect you want to
have:
1) found foobug fooversion; command to the BTS. If this version is
greater or equal to any other fixed version, or causes all fixed
versions to be removed ('cause they're equal to the found version),
the bug is reopened as well.
2) notfixed foobug fooversion; command to the BTS. You do this if you
only want to remove the fixed version from the list, but do not want
to actually reopen the bug.
3) reopen foobug [fooversion]; command to the BTS. This clears the
fixed list and reopens the bug.
Don Armstrong
--
Guns Don't Kill People.
*I* Kill People.
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Could someone clarify this...
On Sat, 30 Jun 2007, Fabian Greffrath wrote: > > My understanding is that Debian declares a work non-free if a holder > > of a software idea patent is *actively enforcing* a patent that covers > > the work, such that Debian cannot distrigute the work as free > > software. > > Is there a known case where a holder actively enforces a patent that > covers MPEG-4 video encoding? I am asking, because x264 has been > removed out of the Debian archive and there are video codecs > disabled in Debian's FFMPEG... Search for "MPEG LA patent litigation", for starters. Don Armstrong -- A Democracy lead by politicians and political parties, fails. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intend to orphan pscan.
Charles Plessy wrote: > I would like to know if it is OK that I orphan pscan and open a > discussion about its removal. 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 * rename your bin/pscan into something else * if the pscan you're packagin provides a similar functionality, why not setup a system of alternatives ? I would go for the first, as, according to popcon stats, this is unlikely to cause any problems to the users of the package you plan to upload. Cheers, Vincent -- Vincent Fourmond, Debian Developer http://vincent.fourmond.neuf.fr/ -- pretty boring signature, isn't it ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intend to orphan pscan.
On Sat, Jun 30, 2007 at 04:15:40PM +0200, Vincent Fourmond wrote: > Charles Plessy wrote: > > I would like to know if it is OK that I orphan pscan and open a > > discussion about its removal. > 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 > * rename your bin/pscan into something else > * if the pscan you're packagin provides a similar functionality, why > not setup a system of alternatives ? > I would go for the first, as, according to popcon stats, this is > unlikely to cause any problems to the users of the package you plan to > upload. If the programs don't do the same thing, option #1 is prohibited by policy. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Sat, Jun 30, 2007 at 07:11:36AM -0700, Don Armstrong wrote:
> 1) found foobug fooversion; command to the BTS. If this version is
> greater or equal to any other fixed version, or causes all fixed
> versions to be removed ('cause they're equal to the found version),
> the bug is reopened as well.
Was there a time where this didn't reopen the bug? Since I'm pretty
sure I tried that in the past and it didn't reopen the bug.
Gruesse,
--
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intend to orphan pscan.
On Sat, Jun 30, 2007 at 02:40:09PM +0100, Steve Kemp wrote: > On Sat Jun 30, 2007 at 18:43:36 +0900, Charles Plessy wrote: > > > I would like to know if it is OK that I orphan pscan and open a > > discussion about its removal. > > I think it would be grossly rude to attempt to orphan a package > which you do not maintain which has no bugs against it. (Except > the naming collision that is currently being discussed.) > > As the "newcomer" I'd suggest that the solution would be for > you to rename/move your binaries rather than forcing the previously > working packages to change their names/behaviors. > (Something I think you've agreed to do. Just sharing opinion.) > > pscan I previously maintained, use often, and would miss majorly > if it were orphaned and removed. Ack. Sorry for not answering earlier, but as the current maintainer of pscan I have no intentions to orphan or remove it. Thanks, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org signature.asc Description: Digital signature
Re: GCC 4.2 transition
On Sat, 30 Jun 2007, Frank Lichtenheld wrote:
> On Sat, Jun 30, 2007 at 07:11:36AM -0700, Don Armstrong wrote:
> > 1) found foobug fooversion; command to the BTS. If this version is
> > greater or equal to any other fixed version, or causes all fixed
> > versions to be removed ('cause they're equal to the found version),
> > the bug is reopened as well.
>
> Was there a time where this didn't reopen the bug? Since I'm pretty
> sure I tried that in the past and it didn't reopen the bug.
It only reopened the bug in the past if it was exactly equal to the
last entered fixed version; this changed recently because the current
logic makes more sense to me.
Don Armstrong
--
UF: What's your favourite coffee blend?
PD: Dark Crude with heavy water. You are understandink? "If geiger
counter does not click, the coffee, she is just not thick."
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.2 transition
On Saturday 30 June 2007 19:06, Frank Lichtenheld wrote:
> On Sat, Jun 30, 2007 at 07:11:36AM -0700, Don Armstrong wrote:
> > 1) found foobug fooversion; command to the BTS. If this version is
> > greater or equal to any other fixed version, or causes all fixed
> > versions to be removed ('cause they're equal to the found version),
> > the bug is reopened as well.
>
> Was there a time where this didn't reopen the bug? Since I'm pretty
> sure I tried that in the past and it didn't reopen the bug.
Yes, this confused me for a long time too.
IIUC from comments during DebConf, there was a bug that the BR was only
reopened if the 'found' version exactly matched the 'done' version. That
bug should now be fixed.
However, I'm not completely sure if that explanation actually matches what
I was seeing in practice and have not tried only using 'found' recently
(I've been using both reopen and found, just to be sure...).
Cheers,
FJP
pgpTgxhGow9aH.pgp
Description: PGP signature
Re: GCC 4.2 transition
On Sat, 30 Jun 2007, Frans Pop wrote: > However, I'm not completely sure if that explanation actually matches what > I was seeing in practice and have not tried only using 'found' recently > (I've been using both reopen and found, just to be sure...). Heh. The explanation is the way it's *supposed* to work; if it doesn't, let me know, and I'll fix it. Don Armstrong -- Your village called. They want their idiot back. -- xkcd http://xkcd.com/c23.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#431233: ITP: python-cvxopt -- CVXOPT -- A Python Package for Convex Optimization
Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg <[EMAIL PROTECTED]> * Package name: python-cvxopt Version : 0.8.2 Upstream Author : Joachim Dahl <[EMAIL PROTECTED]> and Lieven Vandenberghe <[EMAIL PROTECTED]> * URL : http://abel.ee.ucla.edu/cvxopt * License : GPL Programming Lang: C, Python Description : CVXOPT -- A Python Package for Convex Optimization CVXOPT is a Python package for convex optimization. It includes * Python classes for storing and manipulating dense and sparse matrices * an interface to most of the double-precision real and complex BLAS * an interface to the dense linear equation solvers and eigenvalue routines from LAPACK * interfaces to the sparse LU and Cholesky solvers from UMFPACK and CHOLMOD. * routines for solving convex optimization problems, an interface to the linear programming solver in GLPK, and interfaces to the linear and quadratic programming solvers in MOSEK * a modeling tool for specifying convex piecewise-linear optimization problems. -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc6-sonne (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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... The 10.1 first paragraph finishes by : "If a consensus cannot be reached, both programs must be renamed." So what I am doing is, instead of renaming all the conflicting binaries of emboss, to ping maintainers first. I think that the EMBOSS users should not be penalised by the presence of abandonned packages, so unless a DD/DM/NM or the QA team want to take care of the packages, I second their removal. After Uwe's answer, this concerns only hsffig (#423289). Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
