Choose prescripiton medicine

2005-01-16 Thread Joanne Gould
Title: loop

	
	
		 
			afforestation cool demountable cohesion ukrainian hoot burtt  



	Find all your medications in one place!
	We have all pills you may well require!

	You name it! We have them all! 
	








	Stop receiving promotional material now

	guardia severalty louisiana  

			
		
	



Re: Is debhelper build-essential?

2005-01-16 Thread Anthony Towns
Peter Samuelson wrote:
[Ken Bloom]
I'm confused. One making backports from sid to woody should backport
a package in such a way that it is buildable with woody's
build-essential.
AFAICS, that's no more true for build-essential than for anything else. 
That is, you can either backport it so it builds using packages in 
stable, or you can backport the build dependency too. Backporting 
build-essential is pretty easy if everything it depends on is already in 
sarge -- it's a no op. It'd seem strange to do anything else...

Yes.  Same will be true backporting to sarge.  But if sarge
build-essential were to be updated to contain debhelper (>= 4), that
would make less work for backporters than if this same change were made
only post-sarge.
That's crazy talk. If it's true, you're surely doing something wrong.
Cheers,
aj
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


Re: [Pre-RFA] Intending to drop twenty-some packages

2005-01-16 Thread Tollef Fog Heen
* Dirk Eddelbuettel 

|   - time (dead upstream)

[...]

| Please CC me on follow-ups to debian-devel, or email me directly if you have
| any interest. I should follow up with RFA and O bug reports over the next
| few weeks, but doing this informally first may be simpler. Or maybe not. 

I'd like time, please.

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


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



Stephen Frost: MIA ?

2005-01-16 Thread José Luis Tallón
Hi everybody.
   I would like to know if Stephen Frost is alright and if he is still 
active in any way. He is my Application Manager and i have known nothing 
from him since 19th July. He has not even answered my pings on 21st 
October, 8&19th November and 29th December, even though i promptly 
answered him on 20th July.

   I have been in the NM queue since November 2003 and have not yet 
received the questions for the "Task & Skills" part :-S
I understand that Stephen must be very busy, but i'm sure i can be of 
some help if i was a DD myself (as opposed to having to bug some poor 
fellow Developer to sponsor my uploads).

Sorry for the noise, but i need some feedback on my NM process after so 
much time has passed.

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


Re: Bug#290652: ITP: kernel-patch-ibookg4-suspend -- patch to support for hibernation in new G4 ibooks

2005-01-16 Thread Alexander Wirt
Jorge Bernal wrote:
Package: wnpp
Severity: wishlist
* Package name: kernel-patch-ibookg4-suspend
  Version : test6
  Upstream Author : Benjamin Herrenschmidt <[EMAIL PROTECTED]>
* URL : http://gate.crashing.org/
* License : GPL
  Description : patch to support for hibernation in new G4 ibooks
 This patch adds support for hibernation in new G4 ibooks.
 .
 Note that it's an EXPERIMENTAL patch and may not work.
 I have packages available at:
http://www.amedias.org/~koke/debian/unstable/
 There is a test7 version but does not work very well, at
 least with my ibook.
Ehm, the Test7 works fine and nobody yet complaint about it.
If you have problems please report them on debian-powerpc, I haven't
found any mail from you on this list.
Additionally the name is not chosen very good since the patch is for 
powerbooks too.

You should really get more experience with the patch if you want to 
package it. Maybe you want to try my ppc kernel packages at:
http://people.debian.org/~formorer/ppc. The packages have been reported
as working fine for ibooks.

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


Re: [Pre-RFA] Intending to drop twenty-some packages

2005-01-16 Thread Isaac Clerencia
On Saturday, 15 de January de 2005 18:51, Dirk Eddelbuettel wrote:
> * the Octave complex
>   - octave2.0 (to be removed once sarge is release; frozen upstream ages
> ago; one bug that'll never get fixed, we can barely build it as it requires
> g++ pre-3.0)
>   - octave2.1 (two minor bugs against the emacs mode, one other bug)
>   - octave-forge (pretty active and by now pretty large with many
>  build-depends; very well maintained upstream by Paul Kienzle)
>   - semidef-oct (needs rebuilds with every octave2.1 build)
>   - octave-matcompat (predecessor to octave-forge, can be removed soon)
>   - octave-ci (large chunks of it now in octave-forge and octave2.1)
>   - octave-epstk (active upstream)
>   - matwrap (dead upstream)
>   - inline-octave (Perl package, see above)
>
>   I have tried to unload this onto Rafael for a few years now, but he can't
>   take Octave either.  This may be best served by a maintainer group via
>   alioth, and I could be persuaded to help. But I can't set up such a group
>   or lead it, for lack of time.
>
>   Octave has an outstanding author in John Eaton with whom I have worked
>   very well over the years.  The same can be said of Paul Kienzle for
>   octave-forge.

I use Octave and I'm interested on maintaining it, with a team if possible.
Are there anyone else interested on it?

Best regards

-- 
Isaac Clerencia <[EMAIL PROTECTED]>

Warp Networks         http://www.warp.es
María de Luna 11, 50018 Zaragoza, Spain


pgpBTY9zD3dgD.pgp
Description: PGP signature


see with URL support or agnostic konqueror?

2005-01-16 Thread Eric Lavarde
Hello,
I'm maintaining the freemind package and currently 'sensible-browser' is 
used to open links (which are always absolute, either file:/... or http, 
ftp, whatever). It works well for remote links (http etc.) but is not 
the best solution for file: links, if a true browser is behind 
sensible-browser.
'see' would be a better solution because it handles file types properly, 
but it doesn't understand URL notation and doesn't handle remote links.
konqueror would handle everything well but is not so nice for non-KDE users.

My best guess currently would be a small wrapper script that calls 'see' 
for file: links (removing the file: prefix), and 'sensible-browser' for 
all other kind of links. Not very difficult but I have the feeling this 
must have been needed by others as well.

So my questions:
- is there already an "agnostic" utility that does this kind of thing?
- would the 'mime-support' maintainer be interested in adding URL 
handling to the 'see' utility? (would this be at all a good idea?)

Thanks, Eric
--
Gewalt ist die letzte Zuflucht der Inkompetenz.
Violence is the Last Resort of the Incompetent.
Gwalt jest ostatnem schronieniem niekompetencji.
La violence est le dernier refuge de l'incompetence.
~ Isaac Asimov
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


Re: Stephen Frost: MIA ?

2005-01-16 Thread Stephen Frost
* Jos? Luis Tall?n ([EMAIL PROTECTED]) wrote:
>I would like to know if Stephen Frost is alright and if he is still 
> active in any way. He is my Application Manager and i have known nothing 
> from him since 19th July. He has not even answered my pings on 21st 
> October, 8&19th November and 29th December, even though i promptly 
> answered him on 20th July.

"I'm not quite dead yet.  I think I'm feeling better..."

Guess you don't follow debian-newmaint, oh well.  I'm usually better
about answering pings (in fact, I thought I had at least one of those
times...)

>I have been in the NM queue since November 2003 and have not yet 
> received the questions for the "Task & Skills" part :-S
> I understand that Stephen must be very busy, but i'm sure i can be of 
> some help if i was a DD myself (as opposed to having to bug some poor 
> fellow Developer to sponsor my uploads).

As has been mentioned many times before (and I expect you know...),
there's lots you can do w/o being a DD.  Not excusing myself, I've been
very bad about things of late, and I'm sorry. :)  Of course, you should
have contacted the front desk as opposted to debian-devel (which quite a
few developers don't follow these days anyway, you're just lucky I skim
the subjects every once in a while).

> Sorry for the noise, but i need some feedback on my NM process after so 
> much time has passed.

Really, contacting the front desk is the best thing to do if your AM
isn't being responsive.  You can be confident the front desk will bug
the AM about it and the front desk can actually *do* something about it
(ie: reassign you to a different AM).

Stephen


signature.asc
Description: Digital signature


Re: DebConf4 Final Report

2005-01-16 Thread Petter Reinholdtsen
[Pablo Lorenzzoni]
> If you spot any mistake, please, let me know and I'll fix it in the
> next revision.

Thank you for a good report.

I noticed the list of people from Debian Edu was a bit short.

In addition to me, it should list Andreas Schouldei, Joey Hess and
Konstantinos Margaritis, all of which are part of the debian-edu CDD. :)


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



Bug#290753: ITP: dgap -- driver for Digi Acceleport PCI multiport serial cards

2005-01-16 Thread Julien BLACHE
Package: wnpp
Severity: wishlist

* Package name: dgap
  Version : 1.1
  Upstream Author : Digi International
* URL : http://www.digi.com
* License : GPL w/separate non-free firmwares
  Description : driver for Digi Acceleport PCI multiport serial cards

This will go into contrib; the sources up on Digi's support site also contain
the firmwares needed by the cards. I'll split the firmware files from the
source package to put them in non-free, where they belong. I'm currently
verifying that we can redistribute the files, as there's no mention of 
anything concerning the firmware files in the source package.

The dgap driver obsoletes the epca driver which is included in the vanilla
kernel distribution. It supports only the PCI cards, and works on Linux
2.4 and 2.6.

The source package will produce 2 binary packages in contrib:

Package: dgap-tools
Description: support utilities for the Digi Acceleport multiport serial cards
 This package contains support utilities related to the dgap driver for Digi
 Acceleport multiport serial cards:
 .
  o mpi - driver management utility
  o dinc - a cu/tip replacement
  o ditty - an stty replacement
  o dpa - a port monitoring/testing utility

Package: dgap-source
Description: Digi Acceleport multiport serial cards driver
 This package contains the sources of the dgap driver for Digi Acceleport
 multiport serial cards.
 .
 This driver supports only the following PCI Acceleport cards, on both Linux
 v2.4 and Linux v2.6 :
 .
  o Acceleport Xem
  o Acceleport Xr
  o Acceleport Xr 920
  o Acceleport C/X
  o Acceleport EPC/X
  o Acceleport Xr/422
  o Acceleport 2r/920
  o Acceleport 4r/920
  o Acceleport 8r/920
  o IBM 8-Port Asynchronous PCI Adapter
  o IBM 128-Port Asynchronous PCI Adapter


And an additional package in non-free:

Package: dgap-data
Description: firmware files for the Digi Acceleport multiport serial cards
 This package contains the firmware files needed by the dgap driver for
 Digi Acceleport multiport serial cards.


JB.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.9
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


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



[CFH] Please test new dpatch in experimental

2005-01-16 Thread Gergely Nagy
Hi!

I've uploaded a new dpatch into experimental, with two new interesting
features in dpatch-edit-patch (thanks to Marc Haber) that I would like
to subject to extensive testing before I upload the package to unstable.
The package is available from both http://incoming.debian.org/ and
http://dpatch.alioth.debian.org/. It should hit the mirrors with the
next pulse.

As for the new features, the first - and probably less problematic one -
is that dpatch-edit-patch's default behaviour was changed slightly.
Before, it cleaned the source tree before copying it to a temporary
location. Now it does not do that. It copies the tree as-is, and cleans
the copied, temporary tree. This is very handy when one regularily works
on a half- or fully-built tree, and does not want to clean that.
However, the drawback is, that this way far more data gets copied, and
that might be slow. Therefore a --clean option is provided that restores
the old behaviour.

The other new feature, which in my optionion would need more testing (I
tested the other one as much as I could, but this other I can't. At
least, not easily). So, the second new feature is the --debianonly
option. This is for trees that consist only of a debian/ directory. The
original tarball will be searched for in the parent directory, and if
not found, dpatch-edit-patch tries to download it from the network
(using debian/watch and curl, or apt-get source). This is interesting
for those who only store the debian/ part of their packages under
revision control.

So, that's it! I believe these two are important usability features, so
I'd like to ask all you dpatch-edit-patch users to test this carefully,
so when it gets uploaded into unstable in a few weeks, all remaining
bugs (if any) will be ironed out already.

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



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



Re: Legal budget and Director-and-officer insurance related to packages with "adult" themes

2005-01-16 Thread Lionel Elie Mamane
On Sun, Dec 05, 2004 at 02:59:53AM +, Andrew Suffield wrote:
> On Sat, Dec 04, 2004 at 02:33:44PM -0800, Bruce Perens wrote:

>> There are a few people who are most likely to be prosecuted over
>> legal issues in Debian packages that have "adult" themes.

> Oh come on, they're at far greater risk from our overly-permissive
> approach to copyright and patent issues.

A key difference, IMHO, is that only the ( patent | copyright ) holder
can sue over these; mostly anybody can sue over "inappropriate adult
material": parents, grand-parents, cybercafé operators, morality
leagues, ...

-- 
Lionel


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



Re: [CFH] Please test new dpatch in experimental

2005-01-16 Thread Eduard Bloch
#include 
* Gergely Nagy [Sun, Jan 16 2005, 03:27:16PM]:

> The other new feature, which in my optionion would need more testing (I
> tested the other one as much as I could, but this other I can't. At
> least, not easily). So, the second new feature is the --debianonly
> option. This is for trees that consist only of a debian/ directory. The
> original tarball will be searched for in the parent directory, and if
> not found, dpatch-edit-patch tries to download it from the network
> (using debian/watch and curl, or apt-get source). This is interesting
> for those who only store the debian/ part of their packages under
> revision control.

Please also look in .svn/deb-layout for a line like:

origDir=/home/inet/debian/dev/tarballs

That would be the most probable location for the orig tarball.

Regards,
Eduard.
-- 
Everything is illusion. Constructs of language, light, metaphor; nothing
is real.  -- Babylon 5, Season 4


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



Bug#290763: ITP: libgnujmi-java -- free implementation of the java metadata interface

2005-01-16 Thread Arnaud Vandyck
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: wnpp
Severity: wishlist

* Package name: libgnujmi-java
  Version : 0.0cvs20050116
  Upstream Author : Arnaud Vandyck <[EMAIL PROTECTED]>
* URL or Web page : http://savannah.gnu.org/projects/classpathx
* License : GPL
  Description : free implementation of the java metadata interface

 GNU JMI is a free implementation of the JSR-40 The JavaTM Metadata
 Interface (JMI).
 .
 It consist of an API to solve the problem of incompatible metadata.
 . 
 This is the classpathx free implementation of the library
 . 
 Homepage: http://savannah.gnu.org/projects/classpathx

- -- 
Arnaud Vandyck
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFB6n7U4vzFZu62tMIRAjNSAKCNqKJ3iVDcEkS0sI2Wih6CMofHiwCgg6Rf
haPTOhmsECxTpdTtwRDiKsA=
=6hkR
-END PGP SIGNATURE-



Re: [CFH] Please test new dpatch in experimental

2005-01-16 Thread Gergely Nagy
> > The other new feature, which in my optionion would need more testing (I
> > tested the other one as much as I could, but this other I can't. At
> > least, not easily). So, the second new feature is the --debianonly
> > option. This is for trees that consist only of a debian/ directory. The
> > original tarball will be searched for in the parent directory, and if
> > not found, dpatch-edit-patch tries to download it from the network
> > (using debian/watch and curl, or apt-get source). This is interesting
> > for those who only store the debian/ part of their packages under
> > revision control.
> 
> Please also look in .svn/deb-layout for a line like:
> 
> origDir=/home/inet/debian/dev/tarballs
> 
> That would be the most probable location for the orig tarball.

Done in the arch repo, thanks!

For interested parties, the patch is attached.

-- 
Gergely Nagy
--- orig/dpep/dpatch-edit-patch.functions
+++ mod/dpep/dpatch-edit-patch.functions
@@ -233,6 +233,9 @@
   DPEP_ORIGTARGZ="$(readlink -f "../$ORIGTARGZ")"
 elif [ -n "${DPEP_ORIGTARDIR}" ] && [ -f "${DPEP_ORIGTARDIR}/${ORIGTAGZ}" ]; then
   DPEP_ORIGTARGZ="$(readlink -f "${DPEP_ORIGTARDIR}/${ORIGTAGZ}")"
+elif [ -f ".svn/deb-layout" ]; then
+  DPEP_ORIGTARGZ="$(readlink -f "$(cat .svn/deb-layout | sed -e "s,^origDir=,,")/${ORIGTARGZ}")"
+  return 0
 elif [ -f "debian/watch" -a -x $(which curl) ]; then
   if curl "$(< debian/watch sed -n "/^\\(http\\|ftp\\)/{s/^\\([^(]\\+\\)([^)]*)\\([^ ]*\\).*/\\1${UPSTREAMVERSION}\\2/;s///g;p;q;}")" > ../$ORIGTARGZ; then
 DPEP_ORIGTARGZ="$(readlink -f "../$ORIGTARGZ")"




Re: [Pre-RFA] Intending to drop twenty-some packages

2005-01-16 Thread David Weinehall
On Sun, Jan 16, 2005 at 10:05:46AM +0100, Tollef Fog Heen wrote:
> * Dirk Eddelbuettel 
> 
> |   - time (dead upstream)
> 
> [...]
> 
> | Please CC me on follow-ups to debian-devel, or email me directly if you have
> | any interest. I should follow up with RFA and O bug reports over the next
> | few weeks, but doing this informally first may be simpler. Or maybe not. 
> 
> I'd like time, please.

Wouldn't we all? =P


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/


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



Bug#60810: contents.gz package

2005-01-16 Thread Filippo Giunchedi
On Sat, Jan 15, 2005 at 10:09:07AM -0500, Justin Pryzby wrote:
[snip]
> > I think the only sensible and simple thing to do is to provide a zsync
> > file for the Contents files (zsync can 'look into' gz to rsync just
> > the changes). Then every user can use a cron job to zsync the file to
> > his system on a daily, weekly, monthly, whatever basis. zsync uses the
> > http protocol so any http mirror carrying the Contents files will do
> > as source.
> So maybe an debian-contents-updater package.  It contains some cronjob
> entry, maybe a debconf question, or it uses /etc/defaults/.  Yes, that
> would work nicely, I think.

what about including this (zsync'ed Contents plus cronjob) in apt-file (which
needs Contents anyway) or including a symlink for apt-file so it uses it
instead of downloading a new one on apt-file update

filippo
--
Filippo Giunchedi 
GNU/PG key: 6B79D401
Random signature follows:

Date: Tuesday, 2002/10/22 - 08:09
dselect proves the existence of Satan. It's the worst part of Debian.




h00k-up-in-here

2005-01-16 Thread dalyMead
Meeet a skirt 2nite


http://exradiusaffiancevapor-clouded.com/sse/














stp theze : exradiusaffiancevapor-clouded.com/xxt/


The sandhill leech diet gill .
She eugenia detroit hulk moiseyev constitute .
mckay prentice diatom month .
central dolce thorough roberta .
The enter sediment convalesce ppm caddy .
She fogging monic venturesome nucleolus mescaline . And
karma fleabane hungary despot cordage .
She problematic matrimony opprobrium rototill ceremonious bosom .and
anglicanism yore virgule coercive dioxide .
The cannibal impolitic intemperance .
tam citrate connecticut hunk cia sole .and
isabella arbitrage cameroun chairman .
natural plaid concubine appointee postpone contingent .
The midget foursome shamrock elena benjamin grady .
She viewpoint decommission salmonella sevenfold by .
The calliope delinquent pirogue bring niggle .
t sleep hop onlook soap foss .

debian-devel@lists.debian.org


Re: [Pre-RFA] Intending to drop twenty-some packages

2005-01-16 Thread Dirk Eddelbuettel
On Sat, Jan 15, 2005 at 10:14:41PM +0100, Bas Zoetekouw wrote:
> Hi Dirk!
> 
> You wrote:
> 
> > * the gsl set:
> >   - gsl 
> >   - gsl-ref-html
> >   - gsl-ref-psdoc
> >   
> >   The two doc packages are currently a week behind packaging the new 
> > upstream
> >   gsl. Well maintained upstream, maybe two releases a year.  This should
> >   probably go to another egghead ph.d. type, preferably in sciences. Hi 
> > Chris.
> >   This is all very well maintained upstream. Two nuisance bug reports on the
> >   doc package, one ftbfs that is in explicable to me.
> 
> I'd be happy to help out/co-maintain/etc gsl, too.

That's a pretty good idea.  

How about if I make you an uploader now in the debian/control file of the
three packages, that would become effective on the next upload.  If I a bug
fix is needed and you don't hear from, please feel free to add yourself.

Does that sound allright to you?

Best, Dirk

> 
> -- 
> Kind regards,
> ++
> | Bas Zoetekouw  | GPG key: 0644fab7 |
> || Fingerprint: c1f5 f24c d514 3fec 8bf6 |
> | [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 
> fab7 |
> ++ 

-- 
Better to have an approximate answer to the right question than a precise 
answer to the wrong question.  --  John Tukey as quoted by John Chambers


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



Re: [Pre-RFA] Intending to drop twenty-some packages

2005-01-16 Thread Dirk Eddelbuettel
On Sat, Jan 15, 2005 at 10:21:37PM +0100, Erik Schanze wrote:
> Dirk Eddelbuettel <[EMAIL PROTECTED]>:
> > * Miscellaneous
> >   - afio  (2 open bugs, active upstream, pretty straightforward)
> I like afio for my compressed backups and use it very often.
> I'd like to take over maintainership for it, if no otherone has already asked 
> for.

Sounds good -- consider it yours!

Thanks, Dirk

> 
> 
> Kindly regards,
> Erik
> 
> 
> -- 
>  www.ErikSchanze.de *
>  Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB *
>   * Linux-Info-Tag in Dresden, am 29. Oktober 2005  *
>  Info: http://www.linux-info-tag.de *

-- 
Better to have an approximate answer to the right question than a precise 
answer to the wrong question.  --  John Tukey as quoted by John Chambers


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



Re: [Pre-RFA] Intending to drop twenty-some packages

2005-01-16 Thread Dirk Eddelbuettel
On Sun, Jan 16, 2005 at 10:05:46AM +0100, Tollef Fog Heen wrote:
> * Dirk Eddelbuettel 
> 
> |   - time (dead upstream)
> 
> [...]
> 
> | Please CC me on follow-ups to debian-devel, or email me directly if you have
> | any interest. I should follow up with RFA and O bug reports over the next
> | few weeks, but doing this informally first may be simpler. Or maybe not. 
> 
> I'd like time, please.

All yours. Enjoy the regular bug reports from people who confuse it with the
bash builtin :)

Best, Dirk

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

-- 
Better to have an approximate answer to the right question than a precise 
answer to the wrong question.  --  John Tukey as quoted by John Chambers


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



ITP: scheme.app -- Scheme interpreter for GNUstep

2005-01-16 Thread Gürkan Sengün
Package: wnpp
Severity: wishlist

* Package name: scheme.app
  Version : 0.5
  Upstream Author : Marko Riedel <[EMAIL PROTECTED]>
* URL : http://www.gnustep.it/marko/GScheme/
* License : GNU GPL
  Description : Scheme interpreter for GNUstep
 This is a GNUstep aware scheme interpreter. Includes many examples,
 e.g. the sieve of Erathostenes to compute primes, a Koch curve plotter,
 mandelbrot set, graphs of various functions etc. Scheme is fully tail
 recursive. The garbage collector bypasses GNUstep's retain/release
 mechanism in order to deal with circular data structures.


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





pgpnP6BD1isBm.pgp
Description: PGP signature


ITP: fortunate.app -- Display a quotation (fortune) in a window for GNUstep

2005-01-16 Thread Gürkan Sengün
Package: wnpp
Severity: wishlist

* Package name: fortunate.app
  Version : 3.1
  Upstream Author : Stefan Kleine Stegemann <[EMAIL PROTECTED]> (GNUstep port),
Chris Saldanha <[EMAIL PROTECTED]>
* URL : http://www.orange-carb.org/~csaldanh/software.html 
(Original page)
http://www.linuks.mine.nu/fortunate/
* License : GNU GPL
  Description : Display a quotation (fortune) in a window for GNUstep
 Fortunate displays a quotation in a window. Fortunate is a Cocoa/Objective-C
 graphical front-end to the command-line BSD fortune which, since the dawn of
 time, has been providing countless seconds of fun each time a user logs in.


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






pgp9ma9M40fpY.pgp
Description: PGP signature


ITP: backgrounds-debian-shell -- Photography of shells aligned to form the Debian logo

2005-01-16 Thread Gürkan Sengün
Package: wnpp
Severity: wishlist

* Package name: backgrounds-debian-shell
  Version : 1.0
  Upstream Author : Jakub Budziszewski <[EMAIL PROTECTED]>
* URL : http://linuks.mine.nu/jakub/
* License : Artistic License
  Description : Photography of shells aligned to form the Debian logo
 A photography that consists of shells aligned to form the
 Debian logo.


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






pgpjQGo6QbanY.pgp
Description: PGP signature


intent to rename vips7.10 -> vips

2005-01-16 Thread Jay Berkenbilt

Executive summary: I'm planning on renaming the vips7.10 packages to
get the "7.10" out of the package name unless someone tells me that I
shouldn't.  I've discussed this on debian-mentors already.  Read on
for the copious details.

-

The recent threads on sonames and package names convinced me beyond a
doubt that I made a mistake in the names of the vips packages.  I had
reasons at the time, but in retrospect, they were wrong.  I now intend
to rename the packages.  I discussed it on debian-mentors and have
prepared everything for upload and have tested it thoroughly, but I
wanted to run it past debian-devel before doing the actual upgrade.

Right now, vips7.10 has only been in the archive for a short time.
There is only one dependent package in the archive which I also
maintain.  In other words, this is the right time to correct the
mistake.  Right now, the vips7.10 source package creates four binary
packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and
libvips7.10-doc.  My intention is to do the following:

Create new source package "vips" which will create four binary
packages: libvips10, libvips-dev, libvips-tools, libvips-doc.  (10 is
the current soname.)  Each package Conflicts with the package it
replaces with a version << the future dummy transition version of the
existing packages and Replaces the old package as well.  For example:

  Package: libvips10
  Conflicts: libvips7.10 (<< 7.10.dummy)
  Replaces: libvips7.10

Upload this package and wait for it to clear NEW.

Upload new version of vips7.10 (currently 7.10.8-1) called
7.10.dummy-1 that creates four dummy packages in section "oldlibs"
each of which installs no files (except the mandatory ones in
/usr/share/doc) and depends upon its replacement package.  The
Description of the package includes the word "dummy", and is akin to
this, as adjusted appropriately for each package:

  Package: libvips7.10
  Description: transitional dummy package replaced by libvips10
   This is the old name for libvips10.  It can be safely removed.

Upload new version of the package that depends upon libvips7.10 (nip2)
replacing its dependencies and build dependencies as needed.
(Dependencies will be automatic with the new shlibs file.)

By doing this, anyone who has the current packages installed and does
apt-get dist-upgrade will automatically get the new packages with the
new names.  They will also (unfortunately) have the dummy transition
packages, but I see no way around that.  Someone who explicitly
apt-get installs the new packages prior to upgrading the old packages
would have the old packages removed.  For all the gory details, see
this thread:

http://lists.debian.org/debian-mentors/2005/01/msg00240.html

and particularly

http://lists.debian.org/debian-mentors/2005/01/msg00253.html

I'm going to ask my usual sponsor to upload these in the next few days
unless someone gives me a compelling reason not to. :-)

In the interest of full disclosure, in the original ITP, David Moreno
Garza <[EMAIL PROTECTED]> asked why I was including the version number
in the package name and I gave a reason.  In retrospect, the reason
wasn't really valid.

Thanks!

-- 
Jay Berkenbilt <[EMAIL PROTECTED]>
http://www.ql.org/q/


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



Bug#290799: ITP: libspandsp -- Library which provides DSP functions for VoIP.

2005-01-16 Thread Kilian Krause
Package: wnpp
Severity: wishlist

* Package name: libspandsp
  Version : 0.0.2pre9
  Upstream Author : Steve Underwood <[EMAIL PROTECTED]>
* URL : ftp://ftp.opencall.org/pub/spandsp/
* License : GPL
  Description : Library which provides DSP functions for VoIP.

spandsp is a library which provides many of the DSP functions needed for
telephony. It is designed to be independent of the telephony platform
itself.

It's used by YATE and Asterisk do to Fax for example.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.6
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


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



changing architecture from any to all

2005-01-16 Thread Jay Berkenbilt

If one changes the architecture of a package from "any" to "all" but
makes no change to the package name, does this require any special
manual intervention, or would an upload that makes such a change go
through as quickly as a normal upload would go through?  Hypothetical
situation: a compiled executable gets replaced with a shell script.
Real situation: an architecture-dependent library packages gets
replaced by an architecture-independent dummy transitional package.

As far as I can tell from my own experiments, the override file does
not know anything about this, and apt-get upgrade/dist-upgrade are
happy to upgrade a package whose architecture status has changed.  I
just want to double check to avoid an unnecessary delay in planning a
package transition.  Thanks!

-- 
Jay Berkenbilt <[EMAIL PROTECTED]>
http://www.ql.org/q/


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



gnome-pilot: is it a way to make this work?

2005-01-16 Thread Roberto Lumbreras
Hi...

I've discovered that gnome-pilot doesn't work at all with my palm (zire
31, but I guess that it doesn't matter). It works ok with pilot-xfer and
jpilot, but gnome-pilot just timeouts forever.

I was going to fill a bug report, but there are lots of (important) them!!

I've straced (with -f) gpilotd-control-applet and there are __NOT__ any
open() of the pilot device, just an access() that success. I've tried to
dig a bit in the sources, but gnome is too complex for me :(

Is this program working at all for somebody? If not, it shouldn't go to
sarge.

Can we make this working in some way?

Regards,
-- 
Roberto Lumbreras   .''`.

Debian Developer   `. `' 
 `-  


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



Re: hwcap supporting architectures?

2005-01-16 Thread Falk Hueffner
Marcelo E. Magallon writes:

> On Sat, Jan 15, 2005 at 10:14:15PM +0900, GOTO Masanori wrote:
> 
> > > occurs when you have for example an ev56 library in lib/ev56, and a
> > > ev67 CPU. Then the loader looks in lib/ev67 and then falls back to
> > > lib. Since glibc is very carefully undocumented in this area [1], I
> > > didn't want to try to change this, but rather assumed one could add
> > > a symlink.
> > 
> > Yes, and if ev67 is instruction upper compatible with ev56 (I guess
> > so), I think it's acceptable to add a symlink "ln -sf
> > lib/ev67/libfoo.so lib/ev56/libfoo.so".
> 
> Ugh... that pushes the burden of maitaining support for new
> architectures to the package.  Please bear with me, but I'm trying
> to understand the issue: is the cost of calling access(2) or stat(2)
> really so high?

I'd consider it quite acceptable in this case. However, as I tried to
express, it's not possible with glibc's current "design", and I didn't
feel like changing that.

> I see for example that on start up the file /etc/ld.so.nohwcap is
> accessed multiple times (and it's not present, isn't that a race?
> what happens if the file suddenly appears in the middle of program
> start up? what's that file anyway, I can't find it mentioned in the
> documentation).

It's supposed to disable the use of hwcaps. Stating it multiple times
seems like a bug.

-- 
Falk


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



Re: changing architecture from any to all

2005-01-16 Thread Artur R. Czechowski
On Sun, Jan 16, 2005 at 02:58:24PM -0500, Jay Berkenbilt wrote:
> Hypothetical situation: a compiled executable gets replaced with a shell
> script.
> Real situation: an architecture-dependent library packages gets
> replaced by an architecture-independent dummy transitional package.
Real situation: by mistake package was uploaded with Architecture: any, when
should be Architecture: all. Solution: upload package with correct
Architecture field. No other actions was required.

> As far as I can tell from my own experiments, the override file does
> not know anything about this, and apt-get upgrade/dist-upgrade are
> happy to upgrade a package whose architecture status has changed.
Indeed.

> I just want to double check to avoid an unnecessary delay in planning a
> package transition.
You can always use the experimental distribution.
First, you can test if package required additional action from archive
maintainers.
Second, experimental and unstable share override file. You can upload
package to experimental, wait for approve - if needed, then upload it
to unstable with instant result.

Cheers
Artur
-- 
windows jest jak Odie - głupi jak but, cały czas się uśmiecha, a linux jak
Garfield - może i by coś zrobił, ale trzeba go najpierw do tego zmusić.
/yacoob/


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



Re: changing architecture from any to all

2005-01-16 Thread Santiago Vila
On Sun, 16 Jan 2005, Jay Berkenbilt wrote:

> If one changes the architecture of a package from "any" to "all" but
> makes no change to the package name, does this require any special
> manual intervention, or would an upload that makes such a change go
> through as quickly as a normal upload would go through?

It would go as quickly as a normal upload. (Or maybe even quicker, as
it is built for 11 architectures "instantly" :-)

The things that need changes in the override file are changes in the
source package name, changes in any of the binary package names, or
addition of new binary packages.

If you want to see a recent experiment, I changed a package to be
"Architecture: all" very recently and nothing special happened. See:

http://ftp.debian.org/debian/pool/main/c/cd-circleprint

for example.


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



Re: ITP: backgrounds-debian-shell -- Photography of shells aligned to form the Debian logo

2005-01-16 Thread Joe Wreschnig
On Sun, 2005-01-16 at 19:31 +0100, GÃrkan SengÃn wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: backgrounds-debian-shell
>   Version : 1.0
>   Upstream Author : Jakub Budziszewski <[EMAIL PROTECTED]>
> * URL : http://linuks.mine.nu/jakub/
> * License : Artistic License
>   Description : Photography of shells aligned to form the Debian logo
>  A photography that consists of shells aligned to form the
>  Debian logo.

A package for a single background is a remarkably stupid idea. This
should go in desktop-base.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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


xfce-goodies - help needed; Rudy Godoy MIA?

2005-01-16 Thread Simon Huggins
On Sun, Jan 16, 2005 at 02:57:57PM -0800, Steve Langasek wrote:
> On Sun, Jan 16, 2005 at 05:26:35PM +, Simon Huggins wrote:
> > Package: wnpp
> > Severity: wishlist
> There are currently 11 orphaned xfce4-* packages in unstable, including
> three that have just been removed from testing due to RC bugs that went
> virtually unnoticed since the last upload in May.

I know the -goodies packages are in bad shape.

> Please take some time to help figure out what should be done with
> these packages -- cleaned up/adopted, or removed from the archive --
> before ITPing more packages in the xfce4 namespace.

Sure.  I think for sarge they can be cleaned up/updated.  I've just
finished a stretch getting the 22 packages for the main body of xfce4
for 4.2.0 for experimental sorted this weekend so I'm a bit knackered
currently.

To be honest I'd been expecting others to sort out the -plugins for
sarge given people had said they would.

Rudy Godoy seemed interested at one point but now his mail is bouncing
though I'm ccing him again in case it got fixed.

Likewise Emanuele Rocca seemed interested.

There were some packages that made it to mentors.debian.net - and there
is still some work up there.
http://mentors.debian.net/debian/pool/main/x/

I'll try and pull something together for unstable against the 4.0.x libs
I guess at some point but if others have more time and inclination then
I'd be much obliged of the help.


-- 
--( "That's why we like you, Mulder; your ideas are  )--
Simon (   weirder than ours." - Byers) Nomis
 Htag.pl 0.0.22


pgpRY8uGMG0Cq.pgp
Description: PGP signature


Bug#290829: ITP: libupnp -- Intel Universal Plug And Play SDK for Linux

2005-01-16 Thread Steve McIntyre
Package: wnpp
Severity: wishlist

* Package name: libupnp
  Version : 1.2.1
  Upstream Author : Intel Corporation
* URL : http://upnp.sourceforge.net/
* License : BSD
  Description : Intel Universal Plug And Play SDK for Linux

 The Linux SDK for UPnP Devices (libupnp) provides developers with an
 API and open source code for building control points, devices, and
 bridges that are compliant with Version 1.0 of the Universal Plug and
 Play Device Architecture Specification - see http://www.upnp.org/ for
 specifications.
 .
 The libupnp package contains the runtime libraries; see libupnp-dev
 for the headers needed for developing programs using libupnp.

libupnp is required for another package I'm ITPing - wmaloader.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...


signature.asc
Description: Digital signature


Bug#290832: ITP: wmaloader -- firmware downloader for Linksys WMA11B media adapter

2005-01-16 Thread Steve McIntyre
Package: wnpp
Severity: wishlist

* Package name: wmaloader
  Version : 0.1a
  Upstream Author : Andrew Wild <[EMAIL PROTECTED]>
* URL : 
http://www-jcsu.jesus.cam.ac.uk/~acw43/projects/wma11b/wmaloader.html
* License : GPL
  Description : Firmware downloader for Linksys WMA11B media adapter

  wmaloader is a simple program that can download filesystem images to
  the Linksys WMA11b. It performs the same function as the Windows
  XP/2000 Digital Media Adapter Application Loader (supplied with the
  original software) but can run on other operating systems.

wmaloader is a simple program that allows the Linksys Wireless Media
adapter to be booted from a linux system. It does *not* supply media
files to the device (yet!) but even so it might prove useful to those
who wish to experiment hacking the device.

With wmaloader, daapd and wmamp (all Free Software), it's possible to
run a WMA11B media adapter to play audio from your network without
needing any proprietary software installed.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"It's actually quite entertaining to watch ag129 prop his foot up on
 the desk so he can get a better aim."  [ seen in ucam.chat ]


signature.asc
Description: Digital signature


Re: xfce-goodies - help needed; Rudy Godoy MIA?

2005-01-16 Thread Rudy Godoy
Citando Simon Huggins <[EMAIL PROTECTED]>:

>
> I know the -goodies packages are in bad shape.
>
> > Please take some time to help figure out what should be done with
> > these packages -- cleaned up/adopted, or removed from the archive --
> > before ITPing more packages in the xfce4 namespace.
>
> Sure.  I think for sarge they can be cleaned up/updated.  I've just
> finished a stretch getting the 22 packages for the main body of xfce4
> for 4.2.0 for experimental sorted this weekend so I'm a bit knackered
> currently.
>
> To be honest I'd been expecting others to sort out the -plugins for
> sarge given people had said they would.
>

Hi,

> Rudy Godoy seemed interested at one point but now his mail is bouncing
> though I'm ccing him again in case it got fixed.
>

I've already had the new revisions waiting for a while at mentors.debian.net
I've asked a couple (or more) of times for sponsoring at -mentors and
to the xfce team withouth luck. Didn't "pushed" that much anyway, I
mean talk to my actual sponsors, I was going to do ask for it in these
days.

Well, despite all that, I'm able to provide the updates for such
packages and a couple of new plugins like wireless monitor.
I'll upload all them this week to my website, so any prospective sponsor
can grab and hopefully push them into the archives.

regards,
-Rudy


This message was sent using IMP, the Internet Messaging Program.


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



should changelogs be in chronological order

2005-01-16 Thread Travis Crump
Should changelogs be in chronological order or should they be in version 
number order?  Specifically I just noticed that libtiff4's changelog is 
out of chronological order[attached for reference].  It seems that the 
maintainer was maintaining two branches: an experimental 
branch[3.6.1-3->3.7.0-1->3.7.0-2], and an unstable/testing 
branch[3.6.1-3->3.6.1-4->3.6.1-5].  3.7.1-1 would then be potentially 
descended from either branch.  If it is from the experimental branch, 
then the ->3.6.1-4->3.6.1-5 entries aren't applicable and vice versa. 
Then again 'removing' them[the changelog entries] opens up a whole other 
can of worms[hence the post to devel].  More importantly, I don't think 
it is explicitly clear in the changelog whether or not CAN-2004-1183 and 
CAN-2004-1308 are fixed in 3.7.1-1[though implicitly I assume they are, 
but stranger things have happened].

Travis
tiff (3.7.1-1) unstable; urgency=low

  * New upstream release
  * Correct error in doc-base file (Closes: #285652)

 -- Jay Berkenbilt <[EMAIL PROTECTED]>  Wed,  5 Jan 2005 16:54:12 -0500

tiff (3.7.0-2) experimental; urgency=low

  * Replace hard-coded libc6-dev dependency with something friendlier to
porters (libc6-dev | libc-dev).  (Closes: #179727)
  * Fixed upstream: proper netbsdelf*-gnu support in configure.  Actually
fixed in 3.7.0-1 but left out of changelog.  (Closes: #179728)
  * Include opengl support; adds new libtiff-opengl package. (Closes: #219456)
  * Fixed upstream: fax2ps now allows access to first page. (Closes: #244251)

 -- Jay Berkenbilt <[EMAIL PROTECTED]>  Sat, 11 Dec 2004 09:51:52 -0500

tiff (3.7.0-1) experimental; urgency=low

  * New upstream release (Closes: #276996)
  * New maintainer (Thanks Joy!)
  * Repackage using cdbs and simple-patchsys to fix some errors and
simplify patch management
  * Fixed upstream: tiff2pdf ignores -z and -j (Closes: #280682)
  * Fixed upstream: Memory leak in TIFFClientOpen (Closes: #256657)

 -- Jay Berkenbilt <[EMAIL PROTECTED]>  Fri, 26 Nov 2004 13:50:13 -0500

tiff (3.6.1-5) unstable; urgency=high

  * New maintainer (thanks Joy!)
  * Applied patch by Dmitry V. Levin to fix a segmentation fault
[tools/tiffdump.c, CAN-2004-1183]
Thanks to Martin Schulze for forwarding the patch.
  * Fixed section of -dev package (devel -> libdevel)

 -- Jay Berkenbilt <[EMAIL PROTECTED]>  Wed,  5 Jan 2005 16:27:26 -0500

tiff (3.6.1-4) unstable; urgency=high

  * Fix heap overflow security bug [CAN-2004-1308].  (Closes: #286815)

 -- Jay Berkenbilt <[EMAIL PROTECTED]>  Wed, 22 Dec 2004 10:20:52 -0500

tiff (3.6.1-3) unstable; urgency=medium

  * Patches from upstream to fix zero-size tile and integer overflow
problems created by previous security patches, closes: #276783.
  * Added Jay Berkenbilt as co-maintainer. Jay thanks Joy for letting him
help and eventually take over maintenance of these packages!

 -- Josip Rodin <[EMAIL PROTECTED]>  Mon, 01 Nov 2004 12:28:27 +0100

tiff (3.6.1-2) unstable; urgency=low

  * Included security fixes for:
+ CAN-2004-0803
  - libtiff/tif_luv.c
  - libtiff/tif_next.c
  - libtiff/tif_thunder.c
+ CAN-2004-0804 (but this one is already applied upstream, it seems)
  - libtiff/tif_dirread.c
+ CAN-2004-0886
  - libtiff/tif_aux.c
  - libtiff/tif_compress.c
  - libtiff/tif_dir.c
  - libtiff/tif_dirinfo.c
  - libtiff/tif_dirread.c
  - libtiff/tif_dirwrite.c
  - libtiff/tif_extension.c
  - libtiff/tif_fax3.c
  - libtiff/tiffiop.h
  - libtiff/tif_getimage.c
  - libtiff/tif_luv.c
  - libtiff/tif_pixarlog.c
  - libtiff/tif_strip.c
  - libtiff/tif_tile.c
  - libtiff/tif_write.c
Thanks to Martin Schulze for forwarding the patches.

 -- Josip Rodin <[EMAIL PROTECTED]>  Thu, 14 Oct 2004 16:13:11 +0200

tiff (3.6.1-1.1) unstable; urgency=medium

  * Non-maintainer upload; thanks to Jay Berkenbilt <[EMAIL PROTECTED]> for
preparing the patches
  * Rename shared library and development packages to resolve accidental
upstream ABI change.  Closes: #236247
  * Include patch from upstream to fix multistrip g3 fax bug.
Closes: #243405
  * Include LZW support.  Closes: #260242, #248490
  * Fix URL in copyright file.  Closes: #261357
  * Install missing documentation files.  Closes: #261356

 -- Steve Langasek <[EMAIL PROTECTED]>  Sun, 25 Jul 2004 10:28:06 -0400

tiff (3.6.1-1) unstable; urgency=low

  * New upstream version, closes: #231977.
  * Slightly fixed up the static lib build rules so that the build process
does the normal stuff for the dynamic lib and then does the static with
the same tiffvers.h.

 -- Josip Rodin <[EMAIL PROTECTED]>  Mon, 23 Feb 2004 18:23:34 +0100

tiff (3.5.7-2) unstable; urgency=high

  * Added back the patch that used -src static/libtiff.a in the install
rule. Wonder how that disappeared... closes: #170914.
  * Fake it's a GNU system in order for the configure script to use our
toolchain stuff on the Ne

Re: intent to rename vips7.10 -> vips

2005-01-16 Thread Anthony Towns
Jay Berkenbilt wrote:
The recent threads on sonames and package names convinced me beyond a
doubt that I made a mistake in the names of the vips packages.
Oh dear...
[...] Right now, the vips7.10 source package creates four binary
packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and
libvips7.10-doc.  My intention is to do the following:

Create new source package "vips" which will create four binary
packages: libvips10, libvips-dev, libvips-tools, libvips-doc.  (10 is
the current soname.)
There's no real reason to change "libvips7.10" to "libvips10" -- the 
package name doesn't have to match the soname, it just has to change 
whenever the soname does. So if you've matched "libfoo" to a soname of 
4, you don't have to do anything beyond renaming the package when 
version 5 comes out -- and that's the point you should say "ah, I can 
call it libfoo5 now".

Changing the -dev package name isn't a huge win -- having it 
Provides:/Conflicts: with "libvips-dev", encouraging your users to 
build-depend on the unversioned -dev, then just changing the package 
name when your soname next gets bumped is just as effective.

OTOH, when the soname gets bumped you generally don't want to change the 
source package name so you get to avoid waiting for bugs like #283145 to 
be dealt with, and source package names basically don't affect users at all.

libvips-tools and libvips-doc likewise can probably lose their version 
happily, presuming people who Depend: on libvips-dev today, and end up 
getting the tools from soname 11 aren't going to be unhappy. But for 
both of those you should be able to just have "libvips-* 
Conflicts:/Provides:/Replaces: libvips7.10-*" to satisfy dependencies.

Each package Conflicts with the package it
replaces with a version << the future dummy transition version of the
existing packages and Replaces the old package as well.  For example:
I'm fairly sure the above should ensure you don't need any dummy 
packages, and gain all the benefits you were aiming for. Dummy packages 
are almost always evil.

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


Re: xfce-goodies - help needed; Rudy Godoy MIA?

2005-01-16 Thread Steve Langasek
On Sun, Jan 16, 2005 at 10:20:49PM -0500, Rudy Godoy wrote:
> Citando Simon Huggins <[EMAIL PROTECTED]>:

> > I know the -goodies packages are in bad shape.

> > > Please take some time to help figure out what should be done with
> > > these packages -- cleaned up/adopted, or removed from the archive --
> > > before ITPing more packages in the xfce4 namespace.

> > Sure.  I think for sarge they can be cleaned up/updated.  I've just
> > finished a stretch getting the 22 packages for the main body of xfce4
> > for 4.2.0 for experimental sorted this weekend so I'm a bit knackered
> > currently.

> > To be honest I'd been expecting others to sort out the -plugins for
> > sarge given people had said they would.

> Hi,

> > Rudy Godoy seemed interested at one point but now his mail is bouncing
> > though I'm ccing him again in case it got fixed.

> I've already had the new revisions waiting for a while at mentors.debian.net
> I've asked a couple (or more) of times for sponsoring at -mentors and
> to the xfce team withouth luck. Didn't "pushed" that much anyway, I
> mean talk to my actual sponsors, I was going to do ask for it in these
> days.

If you have fixes for the release-critical bugs on xfce4-diskperf-plugin and
xfce4-showdesktop plugin, and are planning to adopt these packages, I would
be willing to sponsor these uploads if you can point me to the source
packages.  In general, if you're looking to adopt a package with RC bugs and
you have packages that need sponsoring, I would recommend posting your
packages' URL to the BTS; the choice between sponsoring a maintainer upload,
and removing the package from testing, is usually an easy one.

Thanks,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature


Re: should changelogs be in chronological order

2005-01-16 Thread Anthony Towns
Travis Crump wrote:
Should changelogs be in chronological order or should they be in version 
number order? 
The changelog should be in the order changes were made.
Specifically I just noticed that libtiff4's changelog is 
out of chronological order[attached for reference].  It seems that the 
maintainer was maintaining two branches: an experimental 
branch[3.6.1-3->3.7.0-1->3.7.0-2], and an unstable/testing 
branch[3.6.1-3->3.6.1-4->3.6.1-5].  3.7.1-1 would then be potentially 
descended from either branch.
If the changelog includes entries from 3.7.0-2 and 2.6.1-5, then 3.7.1-1 
should be descended from _both_ branches -- ie, it should include all 
the changes from both, merging any conflicts.

Then again 'removing' them[the changelog entries] opens up a whole other 
can of worms[hence the post to devel].  More importantly, I don't think 
it is explicitly clear in the changelog whether or not CAN-2004-1183 and 
CAN-2004-1308 are fixed in 3.7.1-1[though implicitly I assume they are, 
but stranger things have happened].
The whole point of the changelog is to make it explicitly clear which 
changes have been made. If something's listed in the changelog, it's 
been applied. If not, that's a mistake.

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