date:20030601

reopen 193497
thanks

Hi,

Debian Bug Tracking System wrote:
 Changes: 
  svtools (0.4-1) unstable; urgency=low
  .
* New upstream version (Closes: #193497)

Meep. No.

Write proper changelogs and(or close bugs the right way[tm].
That form is only acceptable for New upstream version, please package
it like bugs.

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73


pgpddlYfd8I6a.pgp
Description: PGP signature

Re: Bug#195426: O: multi-gnome-terminal -- Enhanced the GNOME Terminal

2003-06-01 Thread Baruch Even

* Christian Surchi [EMAIL PROTECTED] [030601 13:59]:
 On Fri, May 30, 2003 at 09:01:37PM +0300, Baruch Even wrote:
  MGT is much more capable than gnome-terminal, I prefer the power of MGT
  over gnome-terminal, and if no-one else will step in, I'd be willing to
  maintain MGT myself.
 
 I think I can't find enough time... and I'd like to see it maintained
 again! ;-)

Francois Marier seems to be faster than me (or more interested to do the
actual maintenance :-)

He is at the final stages of NM queue (pending DAM approval), so
hopefully soon he'll be able to do full work on this package. I'll be
willing to sponsor him if needed.

Baruch

Re: Debian menu system update

2003-06-01 Thread Bernhard R. Link

* Colin Walters [EMAIL PROTECTED] [030530 19:45]:
 What do you mean consistent concept overall?  Using the freedesktop
 standards makes things more consistent, not less.

Then please point to a documentation, how to overwrite the menus
installed with the packages as admin or other things like this.
We will need to add some way to get windowmangers and modules
to existing windowmanagers handled. 

  I think making update-menus able to parse files in dektop menu
  specification will only cause such files beeing included without
  inspection by newbies.
 
 Oh, right.  I think we should make newbies create Debian packages using
 dd.  After all, otherwise we might actually make creating Debian
 packages easier, have less maintenance burden on ourselves!  We can't
 have that.

I cannot parse that.

  There a many things, that make proper packaging of software a
  complex matter. 
 
 Making Debian packages of software should not be complex for the simple
 cases.  There's just no reason for it to be.

The most of the complexity is not what and how to do things, but to see
what needs to be done. A classical menu item is easy to do and well
documented. Checking a .dektop-file, if it is good enough to be included
it not so easy, but easy to miss looking into it at all.

  Writing this single line to get a menu-item
  should really no problem. 
 
 Writing it is just the start; it has to be translated, 

If it is translated upstream and the name is usable, then there is no
problem in taking the translations. If it is not, it has to be done
anyway.

 and it's just
 another thing that has to be maintained by the Debian packager.  

I strongly believe the menu is something to be maintained. Debian is
about quality and Debian is the only one to include almost any piece
of free software. We cannot let slip in whatever any upstream thinks
is the best place for its items.

 And
 moreover, it's not just a maintenance burden on the packager; everyone
 else has to learn a Debian-specific menu system, with all the drawbacks
 I already mentioned earlier.

Let me come back to my directory example. Some time ago people switching
to Debian had to learn headers are in /usr/include and nothing installed
by debian is in /opt. I did not think it was a bad things and others
following have showed it was the right way.

If there is a good way for the hirachy of the menu, there is no reason
not to adopt it.

  using .dektop will in the long run cause masses of people learn a new
  format and in order to get a coherent understandable system need rewrite
  of masses of old
 
 It's the other way around; keeping our proprietary menu system forces
 administrators to learn yet another needlessly Debian-specific thing
 when using Debian.

While the needlessly Debian-specific thing is working, documented and
supportes the things administrators need. (Next step is abolishing
update-alternative, just another things people have to learn...)

  The currest system works and has
  many nice aspects of configurability and administrability, 
 
 The freedesktop standard is extremely configurable, using the .menu
 files.  It was designed to be so.

It was designed to cope the needs of KDE and GNOME. These are well known
to favor single-user systems, pretend nothing outside their own exists and 
in general be a nightmare to administrators.

Hochachtungsvoll,
  Bernhard R. Link

-- 
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.

Bug#195481: fragmented location info: hassle for users especially mobile ones

2003-06-01 Thread Barak Pearlmutter

Well okay, granted ... but the locale would almost always be
explicitly set, and wouldn't change when eg the lat/long are modified.

Re: new bug tags

2003-06-01 Thread James Troup

Wouter Verhelst [EMAIL PROTECTED] writes:

 On Sun, Jun 01, 2003 at 12:52:02AM +0200, Guido Guenther wrote:
 On Sat, May 31, 2003 at 04:23:49PM +0100, Colin Watson wrote:
  The BTS now has lfs (large file support) and ipv6 tags.
  http://bugs.debian.org/tag:lfs and http://bugs.debian.org/tag:ipv6 will
  search for matching bugs.
 Since we're using bug tags for such specific things now wouldn't it make
 sense to add per architecture tags so one can search via
  http://bugs.debian.org/tag:hppa
 for hppa related issues (not that there are any of course!). It would
 help porters to identify arch related issues much more easily.

 I strongly second this.

I don't; it's silly.  At best you'll get an architecture tag for the
arch that the buildd maintainer reported the bug on, but that's it.
An inaccurate architecture tag is worse than useless, it's misleading.
Just parse wanna-build's failed logs; it's trivial.

-- 
James

Re: Debian menu system update

2003-06-01 Thread Bernhard R. Link

* Chris Cheney [EMAIL PROTECTED] [030530 20:50]:
  I think making things consistent needs us to write them on our own,
  taking upstream entries as suggestions. In my eyes it is just the same
  as with the directories software is installed into. There are just too 
  many ways to do it and we do not serve our users well to let them all in.
 
 I'll let you learn all the languages of the world so that we can throw 
 away upstreams fully i18n menu entries...

I'm nor talking about throwing them away in general. I'm talking about a 
consistent menu. If all your menu shall contain are KDE-programs, you
might archieve this by blidly copying upstream items. 

  Of course it would be nice to have things on places, where users know
  them, but without an consistent concept overall, there is no use to it.
  (Last time I looked we did not put KDE in /opt, though that might have
   things much easier and I'm sure many people were expecting it there...)
 
 Its Debian that is being inconsistent...

Debian may be inconsistent with other distributions. But within Debian
it's a dream of consistency. I have users using fvwm, wmaker, qvwm,
icewm and others. And all have exactly the same menu. All can look at
the others screen to show each other where to find the program to use.

The only thing inconsistent in this regard are KDE-packages, which just
have a unbearable menu. But I guess I'm just not in favor of KDEs
philosophie. I never found a way to let KDE users look at .ps files
other than ininstalling kghostview...

  I think making update-menus able to parse files in dektop menu
  specification will only cause such files beeing included without
  inspection by newbies.
 
 I do not understand this statement. Why would newbies inspect desktop
 entries to begin with...

I was talking about DD newbies.

 It is Debian that is broken since it does not follow the desktop menu
 specification. Both GNOME and KDE follow it and will soon have
 integrated menus, only Debian stuff will then be outside of the menu.

I'd really be suprised, if those will become so simmilar. Even the
update-menus rewrite to parse the new format seems not to aim at
having all wms in debian exactly the same menu.

  There a many things, that make proper packaging of software a
  complex matter. Writing this single line to get a menu-item
  should really no problem. And if it was I really doubt the
  person involved was competent enough to look in the .desktop-file
  if it is reasonable...
 
 Now it becomes obvious you did not look at any .desktop files either...
 slashdot is dooming us all. A single Debian Developer _CAN NOT_ write
 decent menu entries _period_. See the attached konqueror desktop file,
 notice it has translations for 57 languages.

If there is a proper wording for a menu-item upstream (Note that the
item and its place in menu are two different things), then there is
no reason not to use it in the debian package. And then there is also
no problem to include all the translations.

 Debian people SHOULD NOT be writing the menu entries. And it is trivial
 to learn if a DD does want to submit a skeleton one to their upstream. As
 I already said above a menu entry written by only one person is of little
 value since it will have no or very little i18n support.

A menu consisting of only original menu items by upstream has no value
either. Having Gnome and KDE chosing a common policy where to place
their core pieces and adopting such a layout might be nice. Placing all 
the other free software on earth where their upstream thinks they suit
best, will just give an entire mess.

 The current system is limping along and needs to be shot. KDE obeys
 menu policy just fine (afaik) 

fine? not having a debian menu at all but placing some wild items in its
own categories shall be fine? It's about as good as not implementing it
at all.


 PS - Next time try to learn about a system before showing you don't
 understand the issues at all.

Was this a memo for yourself or are you just trying to insult?

MfG,
  Bernhard R. Link

-- 
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.

Re: new bug tags

2003-06-01 Thread David B Harris

On Sun, 01 Jun 2003 15:33:29 +0100
James Troup [EMAIL PROTECTED] wrote:
  Since we're using bug tags for such specific things now wouldn't it make
  sense to add per architecture tags so one can search via
   http://bugs.debian.org/tag:hppa
  for hppa related issues (not that there are any of course!). It would
  help porters to identify arch related issues much more easily.
 
  I strongly second this.
 
 I don't; it's silly.  At best you'll get an architecture tag for the
 arch that the buildd maintainer reported the bug on, but that's it.
 An inaccurate architecture tag is worse than useless, it's misleading.
 Just parse wanna-build's failed logs; it's trivial.

I don't think he's specifically referring to buildd things as much as
just general arch issues (ie: one might file a bug with respect to an
endianness issue and tag it hppa).


pgpkvbWqYwIAk.pgp
Description: PGP signature

Re: new bug tags

Hi,

James Troup wrote:
 I don't; it's silly.  At best you'll get an architecture tag for the
 arch that the buildd maintainer reported the bug on, but that's it.
 An inaccurate architecture tag is worse than useless, it's misleading.
 Just parse wanna-build's failed logs; it's trivial.

Sure, but the architecture tags can be used n ot only for buildd
failures? What if an app just fails on one specific archs during
startup or during execution?

In those cases an tag may be useful.

Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73


pgpPosvqoDHu1.pgp
Description: PGP signature

Re: new bug tags

2003-06-01 Thread James Troup

Rene Engelhard [EMAIL PROTECTED] writes:

 Sure, but the architecture tags can be used n ot only for buildd
 failures?

No, that's my point, IMO they shouldn't be used _at all_ for FTBFS
bugs, because they'd be useless and misleading - and if these tags are
available people will try to use them for FTBFS bugs.

 What if an app just fails on one specific archs during startup or
 during execution?

Sure, fine, whatever, but if you compare arch-specific runtime bugs to
FTBFS bugs, you'll find that the vast  overwhelming majority are
FTBFS not runtime.

-- 
James

Re: [ANN] Quantian: A Knoppix remastering for Scientific Computing

2003-06-01 Thread Andreas Tille

On Wed, 28 May 2003, Dirk Eddelbuettel wrote:

 [ If there is sufficient interest, this may morph into a Debian subproject.
   Please contact me if you would want to be part of it.  --edd ]

Announcing the Quantian Scientific Computing Environment
While I like any project which tries to connect Knoppix and Debian
stronger I think the project you mentioned above is doing the second
step.  In several threads in the debian-knoppix mailing list especially
at

   http://mailman.linuxtag.org/pipermail/debian-knoppix/2003-March/thread.html

I tried to explain how this connection between Debian and Knoppix
can be done.  I hope we can discuss this at LinuxTag and Debconf 3 / Oslo.
If we will be able to bootstrap a Knoppix CD from a Debian mirror all
other Knoppix derivaties will be as easily to acheave as any Debian
package can be installed.

Kind regards

 Andreas.

Re: new bug tags

2003-06-01 Thread Mark Brown

On Sun, Jun 01, 2003 at 03:33:29PM +0100, James Troup wrote:

 I don't; it's silly.  At best you'll get an architecture tag for the
 arch that the buildd maintainer reported the bug on, but that's it.
 An inaccurate architecture tag is worse than useless, it's misleading.
 Just parse wanna-build's failed logs; it's trivial.

Something that would be really useful would be to open up the ability to
annotate the buildd logs more widely.  I've often felt that the buildd
logs would be a lot more useful if they linked into the BTS more often.
Other things would be handy but the ability to say Package X on arch Y
is failing due to bug #Z would really help with scanning the logs.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


pgp9041tLiNBq.pgp
Description: PGP signature

texmf.cnf again

2003-06-01 Thread Marcelo E. Magallon

Hi,

 I don't want to submit a bug since the last time this was discussed it
 degenerated into a flamewar and from the text I quote below it seems
 it's an emotionally overloaded issue for you.

 Installing tetex-bin brings up this:

[!] Configuring Tetex-bin

Now we can generate texmf.cnf, the central configuration file for
TeX system, automatically with update-texmf script.  This is
necessary for other TeX related packages to update the contents of
texmf.cnf

But this overwrites the existing texmf.cnf so if you don't want it,
don't accept this.  Then you should modify /etc/texmf/texmf.cnf
manually. But REMARK that you could fail to install some TeX
components afterwards.

For many users, it is recommended to accept this, despite the
default was set contrary, because this is necessary to install many
other TeX related packages and, if you want, you can custmize
texmf.cnf freely only with modifying files in /etc/texmf/texmf.d/
and adding necessary file(s) there.

Use automatic generation of texmf.cnf with update-texmf?

   Yes _No_

 So the gist of that text is: debian packages can manage the
 configuration file by themselves, it's a good idea if they do and
 there's a chance something will break unless you really really know
 what you are doing.  Then why does it default to no?  Along the same
 line: why is this high priority question if, by the look of it, only a
 handful of people would care?  This is release-note worthy or handbook
 worthy, but it's not really the kind of thing Average Joe wants to see
 when installing Debian afresh[0], is it?

 Small request: please run that text thru our English l10n team
 ([EMAIL PROTECTED])

 Marcelo

 [0] Which I did just last week... boy, is it confusing!

Re: new bug tags

2003-06-01 Thread Javier Fernández-Sanguino Peña

On Sun, Jun 01, 2003 at 12:52:02AM +0200, Guido Guenther wrote:
 On Sat, May 31, 2003 at 04:23:49PM +0100, Colin Watson wrote:
  The BTS now has lfs (large file support) and ipv6 tags.
  http://bugs.debian.org/tag:lfs and http://bugs.debian.org/tag:ipv6 will
  search for matching bugs.
 Since we're using bug tags for such specific things now wouldn't it make
 sense to add per architecture tags so one can search via
  http://bugs.debian.org/tag:hppa
 for hppa related issues (not that there are any of course!). It would
 help porters to identify arch related issues much more easily.
 Regards,

I thinks that the long-asked by i18n maintainers 'translation' tag should 
probably be added too. It helps boths translators and maintainers since it 
introduces a way to manage i18n/l10n related bugs (which are forwarded to 
translation teams)

Regards

Javi


pgp62ZvQmtS65.pgp
Description: PGP signature

Re: Asking for maintainer for astronomical packages and some important (and related) issues

2003-06-01 Thread Javier Fernández-Sanguino Peña

Sorry for the late answer.. you will see in a minute why I took some more 
time to answer on this.

  1.- Copyright issues, these impact on quite a number of 
  astronomical-related packages. 
  
  I made the decision of breaking the star catalogs into packages 
  into non-free but others have not (see bug #174456 - which details 
  some of the copyright issues).
 
 Okay, after reading that, I'm not only worried about the data
 files being non-free, but them being completely unredistributable, in
 main or otherwise.

No, they _are_ redistributable, they just can't be modified. I would 
suggest you read the copyright info in the yale/gliese packages as well as 
the copyright info in the data/ dir of the spacechart package (which 
provides the Hipparcos data set)

  This issue should be pursued to:
  
  - determine wether or not the star data can be distributed in
main (I have a number of mails that need pursuing)
  
  - contact maintainers to coordinate the use of a single data
package instead of having the same star catalogs in every
astronomical packages (maybe even ask for a 
'star-catalog' virtual package that all could provide)
  
  This issue needs to be coordinated with other maintainers since other
  packages (like kstars?) might be affected.
 
 Well, other packages might be able to *make use of* a central star
 catalog, but only if it contains all the formats that all the packages
 need.  This is probably best handled by simply making such a package,
 and then asking everyone else what they would need it to provide in
 order to use it.  However, this may well involve fairly invasive code
 changes that might be difficult to keep in sync with upstream changes.

Not really, if you see how the (new) starplot package manages it is quite
easy.  If it finds star data under /usr/share/stardata it converts it to 
its format and places it in /usr/share/starplot. That way you can remove 
dependancies. Also, the gliese/yale packages call the conversion routine (a 
simple program) if they are installed _after_ the starplot package.

The current status (with the new uploads I've made) is that gliese/yale are 
indepent packages that provide the star catalogue in the format provided 
upstream (which is a standard format in which all catalogues are provided 
BTW).  

 Kstars got its information from the ADC, which has since been
 terminated by NASA as as project.  I poked around their FTP site for a
 while, and while the data files are there and I found a request to
 cite use of the data in any paper, I couldn't find any permission to
 redistribute the data as is.  A couple of contact e-mails were
 listed.  I suppose if I take everything I can start writing to
 everyone to ask about the status.  It'd fit in with the writing I have
 to do to Tulip, anyway.

Ok. Great. Please read the (updated) debian/copyright of yale/gliese, there 
are alternatives to ADC which provide the same catalogues.

As a matter of fact I believe all of these star catalogues are in the 
public domain (like the Hipparcos dataset is), but it does not hurt to be 
cautious. It would be a good idea to contact an astronomer which might help 
clarify this.

 
 
  2.- New releases (bug #169603 - startplot new version and
  bug #172203 - spacechart new release mainly) although the data files
  might need to be updated (haven't checked)
 
 Easily fixed.

Well. I already fixed it (for both), and I have sent new upstream.

  3.- The issue on wether to keep or remove openuniverse
  (its no longer maintained upstream, and maintainers have moved to
  improve celestia but it's not a full replacement for it). The 
  relevant thread in debian-devel starts here:
  http://lists.debian.org/debian-devel/2002/debian-devel-200212/msg01597.html
 
 Heck, I'm still maintaining ssystem (the predecessor to
 openuniverse, and I just recently uploaded a package pointing ssystem
 users at openuniverse unless they have ancient hardware), so if
 nothing else, I should probably pick this one up.  It's more a toy
 than a scientific tool, though.

Great.

  4.- Determine if a new section should be created for astronomic-related
  packages. Some are in section 'science' some in section 'math'...
 
 Much of physics works out to be applied mathematics.  I'd move
 anything not directly used for direct computation out of math and into
 science.

Agreed.

  So, after all this rant, any takers? (I hope somebody raises his hand) :-)
 
 I'm a little nervous about picking up a heavy load until I'm
 finished cleaning house on my own packages, but I have sufficient
 interest in keeping astronomy-related software in Debian that if
 nobody takes you up on your offer by June 15, I will take:
 
 openuniverse
 starplot
 spacechart
 gstar
 

Great. I have made new uploads of starplot/spacechart in order to fix many 
of the lintian bugs and provide the latest versions. I've also made uploads 
of gliese/yale further clarifying

Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)

2003-06-01 Thread Marcelo E. Magallon

On Sun, Jun 01, 2003 at 02:59:40PM +0200, Rene Engelhard wrote:

  * New upstream version (Closes: #193497)
  
  Meep. No.
  
  Write proper changelogs and(or close bugs the right way[tm].  That
  form is only acceptable for New upstream version, please package it
  like bugs.

 With all due respect: piss off.

 Is this a new sport in #d-d or something like that?  I read that entry
 as the new upstream version fixes the problem reported in #193497,
 and looking at the BTS that is exactly its meaning.

 I'm sure there's a thousand better things to do with your time (hint:
 fixing bugs) other than nitpicking at changelog entries because they
 don't include the last period and last comma you want them to.

 This changelog-policying camp is becoming very very counter-productive.

 Marcelo

Re: [ANN] Quantian: A Knoppix remastering for Scientific Computing

2003-06-01 Thread Dirk Eddelbuettel

qOn Sun, Jun 01, 2003 at 05:29:05PM +0200, Andreas Tille wrote:
 On Wed, 28 May 2003, Dirk Eddelbuettel wrote:
 
  [ If there is sufficient interest, this may morph into a Debian subproject.
Please contact me if you would want to be part of it.  --edd ]
 
   Announcing the Quantian Scientific Computing Environment
 While I like any project which tries to connect Knoppix and Debian
 stronger I think the project you mentioned above is doing the second
 step.  In several threads in the debian-knoppix mailing list especially

Second step ? I don't get it? What second step?

 at
 
http://mailman.linuxtag.org/pipermail/debian-knoppix/2003-March/thread.html
 
 I tried to explain how this connection between Debian and Knoppix
 can be done.  I hope we can discuss this at LinuxTag and Debconf 3 / Oslo.

Unfortunately, I cannot attend either.

 If we will be able to bootstrap a Knoppix CD from a Debian mirror all
 other Knoppix derivaties will be as easily to acheave as any Debian
 package can be installed.

That is a fine goal for the medium to long term. Quantian is about
addressing a current niche, and demand, right now.  Both goals are
complements and do not stand in each others way.

Cheers, Dirk

-- 
Don't drink and derive. Alcohol and analysis don't mix.

Re: new bug tags

2003-06-01 Thread Andre Luis Lopes

On Sun, Jun 01, 2003 at 12:05:42PM +0200, Javier Fernández-Sanguino Peña wrote:
 
 I thinks that the long-asked by i18n maintainers 'translation' tag should 
 probably be added too. It helps boths translators and maintainers since it 
 introduces a way to manage i18n/l10n related bugs (which are forwarded to 
 translation teams)

I surelly would second this.

-- 
++--++
||  André Luís Lopes [EMAIL PROTECTED]||
||   http://people.debian.org/~andrelop ||
||  Debian-BR Projecthttp://debian-br.cipsga.org.br ||
||  Public GPG KeyID 9D1B82F6   ||


pgp5fff3krlz5.pgp
Description: PGP signature

Re: Changelog issues with (among others) tkdiff 1:3.08-4

2003-06-01 Thread Brian Nelson

Herbert Xu [EMAIL PROTECTED] writes:

 Brian Nelson [EMAIL PROTECTED] wrote:
 
 Issues that lintian reports are, in most cases, bugs.  Bugs that you
 have fixed should be explicitly described in the changelog.  After all,
 lintian reports many different types of bugs; how can we guess which bug
 is the one that applies in this case?

 He could've choosen to not list that in the changelog at all.  Then you
 wouldn't even know about it.

True, and for some of the really minor stuff lintian complains about, it
probably isn't even worth mentioning in the changelog.

 Seriously, please find something more productive to do than making
 these never-ending complaints about changelog entries.  It might've
 been fun for the first few times but it's getting really boring now.

Well, I'm trying not to rehash old complaints (at least when I Cc d-d)
because anyone that's paying attention has already heard them before.  I
thought this was an interesting case though, because at first at seemed
like a valid entry, but when I thought about it for a second, a dim
light flickered and I realized it really could referring to any kind of
bug.

I really enjoy reading a well-written changelog (and I'm subscribed to
d-d-changes so I tend to read them all), so I'm interested in improving
the quality of ones that aren't quite up-to-par.  If there's a consensus
that it's futile or pointless effort, I'll readily stop.

-- 
Poems... always a sign of pretentious inner turmoil.


pgp8fIFfBvwJr.pgp
Description: PGP signature

Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)

2003-06-01 Thread Sam Hocevar

On Sun, Jun 01, 2003, Marcelo E. Magallon wrote:

  Is this a new sport in #d-d or something like that?  I read that entry
  as the new upstream version fixes the problem reported in #193497,
  and looking at the BTS that is exactly its meaning.

   The point being made is that #193497 has been fixed tells you
absolutely nothing. People who know what #194397 is about can only be
droids with too much time in their hands.

   Now maybe public humiliation and eternal ridiculation on debian-devel
is not necessary, anyone reading the list should be aware of the issue
now. But I think it can be still useful to send the authors of such
changelogs a courteous private request to read the Developer's Reference,
section 6.3.3, which will certainly improve the overall quality of Debian,
with the additional benefit of not annoying this mailing-list.

Regards,
-- 
Sam.

Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)

Hi,

Marcelo E. Magallon wrote:
 On Sun, Jun 01, 2003 at 02:59:40PM +0200, Rene Engelhard wrote:
 
   * New upstream version (Closes: #193497)
   
   Meep. No.
   
   Write proper changelogs and(or close bugs the right way[tm].  That
   form is only acceptable for New upstream version, please package it
   like bugs.
 
  With all due respect: piss off.
 
  Is this a new sport in #d-d or something like that?  I read that entry
  as the new upstream version fixes the problem reported in #193497,
  and looking at the BTS that is exactly its meaning.

yes. And what is when someone is offline and wants to see what
that bug was about?

But we discussed that already enough on this list...

  I'm sure there's a thousand better things to do with your time (hint:
  fixing bugs) other than nitpicking at changelog entries because they

Oh, you think I don't do that?
I do that and when I read mails and see such mails I don't know why I
should reply to it...

  don't include the last period and last comma you want them to.

It doesn't need to. It just should say what the bug was about or how
the procedure was to fix it. Nothing more...

  This changelog-policying camp is becoming very very counter-productive.

I don't think so.
Changelogs are important and they should not be written in such way
because that renders them more or less useless...

/me goes adding questions about that to his NM templates...

Regards,

René
--
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73


pgptXuVjsqKrO.pgp
Description: PGP signature

Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)

2003-06-01 Thread Brian Nelson

Marcelo E. Magallon [EMAIL PROTECTED] writes:

 On Sun, Jun 01, 2003 at 02:59:40PM +0200, Rene Engelhard wrote:

   * New upstream version (Closes: #193497)
   
   Meep. No.
   
   Write proper changelogs and(or close bugs the right way[tm].  That
   form is only acceptable for New upstream version, please package it
   like bugs.

  With all due respect: piss off.

FWIW, my policy has become to only politely ask maintainers in private
to use more verbose New upstream version changelog entries in the
future, because it seems to be a religious issue for some.

  Is this a new sport in #d-d or something like that?  I read that
  entry as the new upstream version fixes the problem reported in
  #193497, and looking at the BTS that is exactly its meaning.

But the problem is that you don't describe what was reported in
#193497.  A entry that says:

  * Closes: 

also says this version fixes a problem reported in #, but I think we
can all agree that's not an acceptable entry.

In this case, an entry that simply says:

  * New upstream version, fixes bashism in svsetup (Closes: #193497)

would be much more informative and only take a few additional seconds
of your time to write.  I find it puzzling why you'd so adamantly refuse
to do something so trivial that is yet so useful.

  I'm sure there's a thousand better things to do with your time (hint:
  fixing bugs) other than nitpicking at changelog entries because they
  don't include the last period and last comma you want them to.

Not even closely analogous.

  This changelog-policying camp is becoming very very
  counter-productive.

Only to you because you've chosen to fight it.  However, poor changelog
entries are very very counter-productive to anyone that is checking the
bug history of your package.

-- 
Poems... always a sign of pretentious inner turmoil.


pgpcZsq0e4BkV.pgp
Description: PGP signature

On Sun, 2003-06-01 at 10:10, Bernhard R. Link wrote:
* Colin Walters [EMAIL PROTECTED] [030530 19:45]:
What do you mean consistent concept overall? Using the freedesktop
standards makes things more consistent, not less.

Then please point to a documentation, how to overwrite the menus
installed with the packages as admin or other things like this.

Basically you would edit the system .menu file, say
/etc/menus/applications.menu.

http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html#MENU-FILE-FORMAT

We will need to add some way to get windowmangers and modules
to existing windowmanagers handled.

No window managers should have to change. We will probably have to
update their /etc/menu-methods/foo though.

The most of the complexity is not what and how to do things, but to see
what needs to be done. A classical menu item is easy to do and well
documented. Checking a .dektop-file, if it is good enough to be included
it not so easy

And why is that?

The .desktop format is quite well documented:

http://www.freedesktop.org/standards/desktop-entry-spec/desktop-entry-spec.html#BASIC-FORMAT

, but easy to miss looking into it at all.

The idea is that we switch to .desktop as our native format as a first
step. That way you can't miss looking into it at all.

If it is translated upstream and the name is usable, then there is no
problem in taking the translations. If it is not, it has to be done
anyway.

Yes, but the point is that the former case will be the vast majority.

I strongly believe the menu is something to be maintained.

I strongly believe that too.

Debian is
about quality and Debian is the only one to include almost any piece
of free software. We cannot let slip in whatever any upstream thinks
is the best place for its items.

No kidding. Why do you keep repeating this, when I have answered that
we can easily make whatever edits are required?

Let me come back to my directory example. Some time ago people switching
to Debian had to learn headers are in /usr/include and nothing installed
by debian is in /opt. I did not think it was a bad things and others
following have showed it was the right way.

But your example is a straw man, because all those paths are specified
by another non-Debian-specific standard (the FHS). Just like the FHS,
the Desktop Menu standard will save administrators time.

(Next step is abolishing
update-alternative, just another things people have to learn...)

Sigh.

It was designed to cope the needs of KDE and GNOME. These are well known
to favor single-user systems, pretend nothing outside their own exists and
in general be a nightmare to administrators.

Ah, right. The I can't think of a technical argument, so I'll just add
in some uninformed flames at GNOME and KDE even though this argument
isn't really related to them part.

Re: new bug tags

2003-06-01 Thread Guido Guenther

On Sun, Jun 01, 2003 at 03:33:29PM +0100, James Troup wrote:
  Since we're using bug tags for such specific things now wouldn't it make
  sense to add per architecture tags so one can search via
   http://bugs.debian.org/tag:hppa
  for hppa related issues (not that there are any of course!). It would
  help porters to identify arch related issues much more easily.
 
  I strongly second this.
 
 I don't; it's silly.  At best you'll get an architecture tag for the
 arch that the buildd maintainer reported the bug on, but that's it.
 An inaccurate architecture tag is worse than useless, it's misleading.
 Just parse wanna-build's failed logs; it's trivial.
I'm not talking about FTBFS bugs only.
 -- Guido

ATI Linux Driver Packages

2003-06-01 Thread Marko Jung

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all!
I build two packages converting the RPM provided by ATI for their RADEON
video cards to a binary package with the XFree module, libGL and some
tools and a source package for building a kernel module with make-kpkg.
These packages are very similar to the nvidia-kernel and nvidia-glx by
Randall Donald.
Now i would ask you to test these packages and send me some feedback.
Actually ATI just released some drivers for XFree 4.1 and 4.2. Because
my job has a NDA with ATI. I already have newer versions of this drivers
including XFree 4.3 support. As soon as ATI releases a new driver
version, I will provide new packages for all XFree versions.
If you would like to get the packages you can add
~   deb http://www.mpi-sb.mpg.de/~mjung/debian stable ati
to your sources.list. The sources for the packages are located here:
~   http://www.mpi-sb.mpg.de/~mjung/debian/src/ati/
The documentation and the copright information need some more work, but
I will fix this soon.
Further Information about the drivers can be found at ATI.com:
http://mirror.ati.com/support/drivers/linux/radeon-linux.html?cboOS=LinuxXFree86cboProducts=RADEON+9700+PROeula=choice=agreecmdNext=Next
Yours,
~   Marko
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE+2jafrews0RqVN+cRAij3AJwI1sdZwKKPr0ln8VU+9dbEPsXtYgCfZjv6
Lpu6rvVn2VHfrOZ6K2x62aY=
=G0Ai
-END PGP SIGNATURE-

Re: Second experimental version of APT with DDTP Support

2003-06-01 Thread Otavio Salvador

Fabio Massimo Di Nitto [EMAIL PROTECTED] writes:

 Hi Otavio,

Hello Fabio,

 just for pure curiosity, when do you expect to have the full system
 integrated within Debian?

I think the code need some otimization and one missing feature to
fallback language codes. After this, in IMHO, the system is ready for
merge.

Have you use this version for testing?

[]s

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

Re: Bug#114398: dbtcp RFP-ITP

2003-06-01 Thread Steve Langasek

On Sun, Jun 01, 2003 at 03:29:07PM +1000, Daniel Stone wrote:
 retitle 114398 ITP: dbtcp -- A client for the MS Windows ODBC proxy server
 thanks

 [Please reply to me, Cc'ing the list, as per the M-F-T header].

 Hi all!
 Just a quick note to say that I've packaged up dbtcp, and am thus taking
 over the RFA (#114398). It was pretty fun to package - a PHP4 module
 that ostensibly needs to be built in-tree. However, it took a nice
 hand-hacked Makefile to make it build out-of-tree, and even then it has
 some fun issues.

 PHP4 installs to /usr/lib/php4/date, where date is probably the
 release date (it's 20020429, currently). I can work out the directory to
 install to (php-config --extension-dir), but how should I handle this in
 package relationships? If the date changes, php4-dbtcp suddenly becomes
 useless - PHP's looking in a different directory for its extensions.

The corresponding virtual package is zendapi-20020429.  Unless you want
to borrow from the build rules for the php4 package, munging the output
of 'php-config --extension-dir' is probably the best way to get this
into your dependency list.

-- 
Steve Langasek
postmodern programmer


pgpMf29c6vHfh.pgp
Description: PGP signature

Re: Debian menu system update

2003-06-01 Thread Bernhard R. Link

* Colin Walters [EMAIL PROTECTED] [030601 19:05]:
Then please point to a documentation, how to overwrite the menus
installed with the packages as admin or other things like this.

Basically you would edit the system .menu file, say
/etc/menus/applications.menu.

http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html#MENU-FILE-FORMAT

Does this mean there simply is no such documentation?

We will need to add some way to get windowmangers and modules
to existing windowmanagers handled.

No window managers should have to change. We will probably have to
update their /etc/menu-methods/foo though.

Currently the main database for window managers or fvwm-modules is the
debian menu, as they are often selectable from a menu and there is no
difference in handling them and normal items. Do you suggest tweaking
the .desktop files, to contain them, too?

And why is that?

The .desktop format is quite well documented:

http://www.freedesktop.org/standards/desktop-entry-spec/desktop-entry-spec.html#BASIC-FORMAT

First of all because it is no menu entry, but a desktop item. It
contains all sort of things like Mime-types and the like. And compare
the size of this file with /usr/share/doc/menu/html/ch3.html.

, but easy to miss looking into it at all.

The idea is that we switch to .desktop as our native format as a first
step. That way you can't miss looking into it at all.

I do not understand, what you want to say.

If it is translated upstream and the name is usable, then there is no
problem in taking the translations. If it is not, it has to be done
anyway.

Yes, but the point is that the former case will be the vast majority.

When I currently look in icewm-gnome, what is has in its KDE and Gnome
menus compared to what it has in its debian menu, I really have to doubt
that.

I strongly believe the menu is something to be maintained.

I strongly believe that too.

Debian is
about quality and Debian is the only one to include almost any piece
of free software. We cannot let slip in whatever any upstream thinks
is the best place for its items.

No kidding. Why do you keep repeating this, when I have answered that
we can easily make whatever edits are required?

Because my argumentation is, that because of
a) most menu items will be written by us, as upstream has no
b) many of the rest would need edit anyway
c) any one should really looked into if it has to.
the
1) the old menu system no real overhead in b) and c)
while the using .desktop-files as native format will cause
2) making a) much more complicated.
3) discouraging c).

It was designed to cope the needs of KDE and GNOME. These are well known
to favor single-user systems, pretend nothing outside their own exists and
in general be a nightmare to administrators.

Ah, right. The I can't think of a technical argument, so I'll just add
in some uninformed flames at GNOME and KDE even though this argument
isn't really related to them part.

It is related. Heck, this specification even gives in the example the
Icon as .png-file. While using .xpm-only for menus is really
long-lasting standard, with no reason to stop this...

Hochachtungsvoll,
Bernhard R. Link

--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.

Re: new bug tags

2003-06-01 Thread Wouter Verhelst

On Sun, Jun 01, 2003 at 06:47:29PM +0200, Guido Guenther wrote:
 On Sun, Jun 01, 2003 at 03:33:29PM +0100, James Troup wrote:
   Since we're using bug tags for such specific things now wouldn't it make
   sense to add per architecture tags so one can search via
http://bugs.debian.org/tag:hppa
   for hppa related issues (not that there are any of course!). It would
   help porters to identify arch related issues much more easily.
  
   I strongly second this.
  
  I don't; it's silly.  At best you'll get an architecture tag for the
  arch that the buildd maintainer reported the bug on, but that's it.
  An inaccurate architecture tag is worse than useless, it's misleading.
  Just parse wanna-build's failed logs; it's trivial.
 I'm not talking about FTBFS bugs only.

Well, I am. But it's important to note that not all FTBFS should get an
architecture-specific tag; in fact, most build failures I encounter
are not architecture-specific at all, but the result of wrong
build-depends or something similar.

While James' point that parsing wanna-build output is not hard may be
valid, finding out whether a failure recorded in the wanna-build
database is arch-specific or not seems quite hard to me, since that
information is not in the database in a machine-parsable format.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts. 
  -- National Geographic Channel, in a documentary about large African beasts.


pgpeY1emMNXL4.pgp
Description: PGP signature

Re: Second experimental version of APT with DDTP Support

2003-06-01 Thread Fabio Massimo Di Nitto

On Sun, 1 Jun 2003, Otavio Salvador wrote:

 Fabio Massimo Di Nitto [EMAIL PROTECTED] writes:

  Hi Otavio,

 Hello Fabio,

  just for pure curiosity, when do you expect to have the full system
  integrated within Debian?

 I think the code need some otimization and one missing feature to
 fallback language codes. After this, in IMHO, the system is ready for
 merge.

 Have you use this version for testing?

To be hounest no i didn't test it since i personally don't like to use
other language than english on my computers. I was only curious about the
integration status since i like to see big projects merging happily
together :-)

Fabio

-- 
Our mission: make IPv6 the default IP protocol
We are on a mission from God - Elwood Blues

http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html

Re: Debian menu system update

2003-06-01 Thread Josef Spillner

On Sunday 01 June 2003 20:02, Bernhard R. Link wrote:
 It is related. Heck, this specification even gives in the example the
 Icon as .png-file. While using .xpm-only for menus is really
 long-lasting standard, with no reason to stop this...

One day, SVG icons might be used, so there has to be some kind of flexibility.
It would be nice to work towards collaboration with freedesktop.org, probably 
a fallback mechanism can be implemented.
I personally do not want to restrict myself to 214 ugly colours, and others do 
not want to use scalable icons. With only one of both implementations, it 
will never be possible to make everyone happy.

Josef

-- 
Play for fun, win for freedom.

Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)

2003-06-01 Thread Andreas Barth

* Brian Nelson ([EMAIL PROTECTED]) [030601 19:05]:
 FWIW, my policy has become to only politely ask maintainers in private
 to use more verbose New upstream version changelog entries in the
 future, because it seems to be a religious issue for some.

That's certainly the right policy.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)

2003-06-01 Thread Andreas Barth

* Rene Engelhard ([EMAIL PROTECTED]) [030601 18:50]:
 Marcelo E. Magallon wrote:
  On Sun, Jun 01, 2003 at 02:59:40PM +0200, Rene Engelhard wrote:
  
* New upstream version (Closes: #193497)

Meep. No.

Write proper changelogs and(or close bugs the right way[tm].  That
form is only acceptable for New upstream version, please package it
like bugs.
  
   With all due respect: piss off.
  
   Is this a new sport in #d-d or something like that?  I read that entry
   as the new upstream version fixes the problem reported in #193497,
   and looking at the BTS that is exactly its meaning.
 
 yes. And what is when someone is offline and wants to see what
 that bug was about?
 
 But we discussed that already enough on this list...

You should really accept the decision of a package maintainer.
However, it really might be better to put a longer statement into
changelog. _But_ it's certainly much worse to re-open a really closed
bug than to make a too short changelog entry. (BTW: You should really
make cleaner why changing of the compiler closes the Bug 194555. The
situation there is fare worse than here. You shouldn't flame until
you're perfekt.)


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Debian menu system update

2003-06-01 Thread Bill Allombert

On Sat, May 31, 2003 at 06:54:46PM -0400, Colin Walters wrote:
 On Sat, 2003-05-31 at 17:52, Bill Allombert wrote:
 
   http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg02071.html
  
  Could you be so kind as to summarize thoses concerns ? 
 
 The message above is fairly concise, I think.  But I can basically sum
 it up as:
 
 I don't see the advantages (besides inertia) of continuing to develop a
 Debian-specific menu system, when the rest of the world is moving to the
 freedesktop.org standard.  Implementing the freedesktop.org standard
 gives us a number of things, in particular i18n and significantly less
 maintenance burden on Debian developers.

This is more an opinion than a concern.

I have already answered about i18n. I am not sure about the maintenance
burden on Debian developers.

Is there stand-alone implementation of this standard ?

I have read it, and I have still difficulty to understand its
full implication.

Cheers,
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here.

Re: Debian menu system update

2003-06-01 Thread Colin Walters

On Sun, 2003-06-01 at 14:02, Bernhard R. Link wrote:
* Colin Walters [EMAIL PROTECTED] [030601 19:05]:
Then please point to a documentation, how to overwrite the menus
installed with the packages as admin or other things like this.

Basically you would edit the system .menu file, say
/etc/menus/applications.menu.

http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html#MENU-FILE-FORMAT

Does this mean there simply is no such documentation?

I think it's pretty clear how it should be done. Once we adopt the
system, we can point system administrators to the relevant file in our
documentation, and give pointers to the file format.

Currently the main database for window managers or fvwm-modules is the
debian menu, as they are often selectable from a menu and there is no
difference in handling them and normal items.

Huh? What main database? Are you saying some window managers read
the Debian menu entries directly? From looking at fvwm, this certainly
seems not to be the case.

Do you suggest tweaking
the .desktop files, to contain them, too?

Contain...what?

First of all because it is no menu entry, but a desktop item. It
contains all sort of things like Mime-types and the like. And compare
the size of this file with /usr/share/doc/menu/html/ch3.html.

The file doesn't have to (and most often doesn't) contain many of those
fields.

When I currently look in icewm-gnome, what is has in its KDE and Gnome
menus compared to what it has in its debian menu, I really have to doubt
that.

If your problem is with the default layout, again: it's only a
*default*. We can and probably will change it.

Because my argumentation is, that because of
a) most menu items will be written by us, as upstream has no

Many of my packages come with perfectly good menu entries from upstream.
And besides, as one of the prominent free software projects, Debian
should be leading the charge here.

b) many of the rest would need edit anyway

I completely disagree with many, for reasons stated previously.

c) any one should really looked into if it has to.
the
1) the old menu system no real overhead

Neither menu system takes much processing power, if that's what you're
referring to.

in b) and c)
while the using .desktop-files as native format will cause
2) making a) much more complicated.

No, it will make things simpler, in addition to giving us useful
features like i18n.

It is related.

It is not.

Heck, this specification even gives in the example the
Icon as .png-file. While using .xpm-only for menus is really
long-lasting standard, with no reason to stop this...

And now the Ok, my pointless KDE and GNOME flame was obviously wrong,
so I'll try to troll about image formats instead part.

Bug#195725: RFA: tkisem (graphical SPARC emulator) binutils-sparc

2003-06-01 Thread Barak Pearlmutter

Package: wnpp

Because I no longer use them myself I am looking for someone to take
over the below packages.  (The second, binutils-sparc, exists only to
service the first and is a trivial modification of binutils-avr, so I
list them together.)

I'm not swizzling the Maintainer: field to QA because I'll deal with
any major problems if necessary.  For now.  But if anyone would like
to take them over, please be my guest!



Package: tkisem
Version: 4.5.12-5
Depends: binutils-sparc ..., tk8.3 | wish, ...
Description: Graphical SPARC emulator
 Instructional SPARC Emulator using tk.  This SPARC CPU simulator has
 nice graphics, and is very good for learning assembly language
 programming.  Particularly suited to the textbook Computer Systems:
 Architecture, Organization, and Programming by Arthur Maccabe.

Package: binutils-sparc
Version: 2.11.92.0.12.3-4
Build-Depends: ..., toolchain-source, ...
Depends: libc6 (= 2.2.4-4), binutils (= 2.11.92.0.12.3-4)
Description: Binary utilities that support the SPARC target.
 The programs in this package are used to manipulate binary and object
 files that may have been created for the SPARC architecture.  This package
 is primarily for SPARC developers and cross-compilers and is not needed
 by normal users or developers, except users of the tkisem SPARC emulator.

Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)

2003-06-01 Thread Herbert Xu

Brian Nelson [EMAIL PROTECTED] wrote:
 
 Marcelo E. Magallon [EMAIL PROTECTED] writes:
 
 On Sun, Jun 01, 2003 at 02:59:40PM +0200, Rene Engelhard wrote:

   * New upstream version (Closes: #193497)
 
  Is this a new sport in #d-d or something like that?  I read that
  entry as the new upstream version fixes the problem reported in
  #193497, and looking at the BTS that is exactly its meaning.
 
 But the problem is that you don't describe what was reported in
 #193497.  A entry that says:

So what? The *Debian* changelog is for Debian changes only.  It's not there
for listing upstream changes, copyright information, or who your favourite
TV personality is.

  * Closes: 
 
 also says this version fixes a problem reported in #, but I think we
 can all agree that's not an acceptable entry.

I most strongly disagree.  The practice of closing upstream bugs with
the New upstream version message has always been common practice.

 In this case, an entry that simply says:
 
  * New upstream version, fixes bashism in svsetup (Closes: #193497)
 
 would be much more informative and only take a few additional seconds
 of your time to write.  I find it puzzling why you'd so adamantly refuse
 to do something so trivial that is yet so useful.

Well if the maintainer wishes to include more information, we don't
need to stop them.  But we sure as hell shouldn't be forcing them to
duplicate what is already in the upstream changelog.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)

2003-06-01 Thread Matt Zimmerman

On Mon, Jun 02, 2003 at 07:39:38AM +1000, Herbert Xu wrote:

 Brian Nelson [EMAIL PROTECTED] wrote:
  
  Marcelo E. Magallon [EMAIL PROTECTED] writes:
  
  On Sun, Jun 01, 2003 at 02:59:40PM +0200, Rene Engelhard wrote:
 
* New upstream version (Closes: #193497)
  
   Is this a new sport in #d-d or something like that?  I read that
   entry as the new upstream version fixes the problem reported in
   #193497, and looking at the BTS that is exactly its meaning.
  
  But the problem is that you don't describe what was reported in
  #193497.  A entry that says:
 
 So what? The *Debian* changelog is for Debian changes only.  It's not there
 for listing upstream changes, copyright information, or who your favourite
 TV personality is.

The Debian changelog should document why a Debian bug is being closed.  Good
reasons include being able to tell in what Debian version of a package a bug
was closed, and being able to easily spot when the wrong bug has been
closed.

-- 
 - mdz

Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)

Hi,

 However, it really might be better to put a longer statement into
 changelog. _But_ it's certainly much worse to re-open a really closed
 bug than to make a too short changelog entry. (BTW: You should really

a wrongly closed... (whithout explanation what the fix was; the
new upstream version wasn't , it was a fix included in it;
the bashisms were removed)

 make cleaner why changing of the compiler closes the Bug 194555. The
 situation there is fare worse than here. You shouldn't flame until
 you're perfekt.)

aha. You say me I should respect the decision and you don't.
*sigh*

I worked around it using a working compiler. the previous version
didn't work, I upload it with -O0 and then it failed.

I wanted to get a working version in to testing and then look how
to fix that in a correct way.

I actually am really busy with other Debian and RL things...

I admit that I could have written
* use gcc-3.2 for now to work around pasting preprocessing token
 errors with gcc-3.3

And no, I do _not_ flame, I tell people what not to do. And my
applicants will get questions about that in the future...
(yes, i did that wrong too in that aria upload)

Regards,

René


pgpincmSd7aR5.pgp
Description: PGP signature

Re: Bug#195490: ITP: raptor -- a vertical shoot'em-up similar to Raptor: Call of the Shadows

2003-06-01 Thread Sam Hocevar

On Sat, May 31, 2003, Neil McGovern wrote:
   Raptor is a clone of Raptor: Call of the Shadows, a classic shoot'em-up 
  game.
 
 Calling the package Raptor, for a clone of Raptor: Call of the Shadows
 could get confusing.

   True. I talked to upstream about it and he agreed to change the
name to Rafkill (no hits on Google).

-- 
Sam.

Celebrating Debian's 10th birthday?

2003-06-01 Thread Alexander Neumann

Hi,

While digging around in the calendar-files at infodrom.org I suddenly
realized that Debian will have it's 10th birthday at August, 16th
(according to the calendar.infodrom.debian file at
http://www.infodrom.org/projects/calendar/)

Are there any parties planned already? ;)

- Alexander


pgpvxEv6vqWX1.pgp
Description: PGP signature

Re: Debian menu system update

On Sun, Jun 01, 2003 at 08:59:58PM +0200, Josef Spillner wrote:
 One day, SVG icons might be used, so there has to be some kind of flexibility.
 It would be nice to work towards collaboration with freedesktop.org, probably 
 a fallback mechanism can be implemented.
 I personally do not want to restrict myself to 214 ugly colours, and others do
 not want to use scalable icons. With only one of both implementations, it 
 will never be possible to make everyone happy.

SVG icons are the only decent long term solution once screens go to
200dpi+ those tiny icons will be worthless, of course you can always
double or triple the size of fixed size icons automatically but they
won't look very good. Microsoft is pushing for high resolution screens
to be available in time for its new OS 'Longhorn' release, which is only
around 2 years from now.

Chris

Re: Bug#193497: marked as done (svtools: svsetup uses bashism echo -e)

2003-06-01 Thread Steve Kowalik

At  7:57 am, Monday, June  2 2003, Herbert Xu mumbled:
 So what? The *Debian* changelog is for Debian changes only.  It's not there
 for listing upstream changes, copyright information, or who your favourite
 TV personality is.
 
And if this new upstream release deals with a bug filed in the BTS?

I personally don't see a problem with:

lala (0.0-2) whatever

  * New upstream release.
- Don't segfault on hppa at startup. (Closes: #12345)

-- 
   Steve
* Overfiend is away -- go libfuckwit.a yourself -- messages will be saved.

Re: Celebrating Debian's 10th birthday?

2003-06-01 Thread Kenshi Muto

Hi,

At Mon, 2 Jun 2003 03:24:39 +0200,
Alexander Neumann wrote:
 Are there any parties planned already? ;)

Debian JP Project, consists of Debian developers/users in Japan, are
planning 'Debian 10th anniversary party' at Tokyo on Aug 15 midnight.

We'll send a article about this party to DWN when our Web page and
programs are ready.

Thanks,
-- 
Kenshi Muto
[EMAIL PROTECTED]

Re: Debian menu system update

On Sun, Jun 01, 2003 at 04:34:55PM +0200, Bernhard R. Link wrote:
 * Chris Cheney [EMAIL PROTECTED] [030530 20:50]:
   I think making things consistent needs us to write them on our own,
   taking upstream entries as suggestions. In my eyes it is just the same
   as with the directories software is installed into. There are just too 
   many ways to do it and we do not serve our users well to let them all in.
  
  I'll let you learn all the languages of the world so that we can throw 
  away upstreams fully i18n menu entries...
 
 I'm nor talking about throwing them away in general. I'm talking about a 
 consistent menu. If all your menu shall contain are KDE-programs, you
 might archieve this by blidly copying upstream items. 

Any application that is written for GNOME or KDE (KDE 3.2+) will be in
the same menu. As I undestand it both ROX and XFCE menus work the same
way as well.

   Of course it would be nice to have things on places, where users know
   them, but without an consistent concept overall, there is no use to it.
   (Last time I looked we did not put KDE in /opt, though that might have
things much easier and I'm sure many people were expecting it there...)
  
  Its Debian that is being inconsistent...
 
 Debian may be inconsistent with other distributions. But within Debian
 it's a dream of consistency. I have users using fvwm, wmaker, qvwm,
 icewm and others. And all have exactly the same menu. All can look at
 the others screen to show each other where to find the program to use.
 
 The only thing inconsistent in this regard are KDE-packages, which just
 have a unbearable menu. But I guess I'm just not in favor of KDEs
 philosophie. I never found a way to let KDE users look at .ps files
 other than ininstalling kghostview...

Right clicking on the file in konqueror and telling it to open with some
other app doesn't work? (Works fine for me) I am viewing a pdf file in
xpdf right now. If you want to make it permanent just click on edit file
type instead and change the default. Or run kcontrol - KDE Components
- File Associations to change them. By the way mime types are also
defined using desktop files and there is a specification for how that
should work on freedesktop.org as well. After the Debian menu system has
been ported to using desktop files the mime system will probably be the
next thing on the list.

   I think making update-menus able to parse files in dektop menu
   specification will only cause such files beeing included without
   inspection by newbies.
  
  I do not understand this statement. Why would newbies inspect desktop
  entries to begin with...
 
 I was talking about DD newbies.

From your posts to me and others it seems you are a Linux newbie as
well. Perhaps you need to learn more before posting about topics you
don't fully understand.

  It is Debian that is broken since it does not follow the desktop menu
  specification. Both GNOME and KDE follow it and will soon have
  integrated menus, only Debian stuff will then be outside of the menu.
 
 I'd really be suprised, if those will become so simmilar. Even the
 update-menus rewrite to parse the new format seems not to aim at
 having all wms in debian exactly the same menu.

They aren't going to become so similiar... they already are the same. As
soon as KDE 3.2, which is currently in development, is released they will
be combined in Debian. People running the KDE 3.2 cvs debs already benefit
from this merge. By the way there are already 423 desktop files in Debian.

   There a many things, that make proper packaging of software a
   complex matter. Writing this single line to get a menu-item
   should really no problem. And if it was I really doubt the
   person involved was competent enough to look in the .desktop-file
   if it is reasonable...
  
  Now it becomes obvious you did not look at any .desktop files either...
  slashdot is dooming us all. A single Debian Developer _CAN NOT_ write
  decent menu entries _period_. See the attached konqueror desktop file,
  notice it has translations for 57 languages.
 
 If there is a proper wording for a menu-item upstream (Note that the
 item and its place in menu are two different things), then there is
 no reason not to use it in the debian package. And then there is also
 no problem to include all the translations.

This is just extra effort that is not needed, and likely to get screwed
up by inept developers munging utf8 characters.

  Debian people SHOULD NOT be writing the menu entries. And it is trivial
  to learn if a DD does want to submit a skeleton one to their upstream. As
  I already said above a menu entry written by only one person is of little
  value since it will have no or very little i18n support.
 
 A menu consisting of only original menu items by upstream has no value
 either. Having Gnome and KDE chosing a common policy where to place
 their core pieces and adopting such a layout might be nice. Placing all 
 the other free software on earth where

Re: Debian menu system update

2003-06-01 Thread Russell Coker

On Mon, 2 Jun 2003 11:54, Chris Cheney wrote:
 SVG icons are the only decent long term solution once screens go to
 200dpi+ those tiny icons will be worthless, of course you can always
 double or triple the size of fixed size icons automatically but they
 won't look very good. Microsoft is pushing for high resolution screens
 to be available in time for its new OS 'Longhorn' release, which is only
 around 2 years from now.

SVG icons sounds like a good concept.

However if an icon looks good at 100dpi then surely when doubled it should 
look just as good at 200gpi.

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

Re: ATI Linux Driver Packages

/me coughs

;)

Re: ATI Linux Driver Packages

Are these drivers much better then than XFree ones or is there a reason
to be promoting nonfree drivers? I orginally packaged up the nvidia ones
in the way they are done due to the fact the XFree ones had no 3d
acceleration at all and that it was illegal to distribute nvidia's
binaries directly.  Also binary only drivers will taint the kernel and
can cause the user to have trouble getting help with kernel related
issues. I got rid of my nvidia cards (some poor sucker took them) and
now use only ATI cards. 8)

Chris

Re: Celebrating Debian's 10th birthday?

2003-06-01 Thread Jonathan Oxer

On Mon, 2003-06-02 at 12:14, Kenshi Muto wrote:
 At Mon, 2 Jun 2003 03:24:39 +0200,
 Alexander Neumann wrote:
  Are there any parties planned already? ;)
 
 Debian JP Project, consists of Debian developers/users in Japan, are
 planning 'Debian 10th anniversary party' at Tokyo on Aug 15 midnight.

There has also been talk of a get-together in Melbourne, Australia on
the Debian-melb list. Looks like Martin will be back just in time for
it  :-)

Stewart Smith (VP of Linux Australia, the org that runs LCA) suggested
synchronising events in multiple venues, which could have the effect of
attracting some media attention to it.

A global multi-venue party sounds pretty cool to me  :-)

Cheers

Jonathan

Re: Second experimental version of APT with DDTP Support

2003-06-01 Thread Otavio Salvador

Fabio Massimo Di Nitto [EMAIL PROTECTED] writes:

 Have you use this version for testing?

 To be hounest no i didn't test it since i personally don't like to use
 other language than english on my computers. I was only curious about the
 integration status since i like to see big projects merging happily
 together :-)

So I have bad news. The process for this doesn't depend of me since
I'm not on APT Team. I really like to see some deity-people talking
about the code and suggesting patches.

In IMHO the big problem is the time to access the both data. The
current code doesn't enlarge the cache use so much but the time to
display one package with translations is more or less 2 times of
without.

The more clear solution is include the package header on cache and
then access only one file to show the record but this enlarge the
cache. Tips?

[]s

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

Re: Debian menu system update

2003-06-01 Thread Colin Walters

On Sun, 2003-06-01 at 15:58, Bill Allombert wrote:

 I have already answered about i18n. 

If you're referring to extracting the i18n information from .desktop
files; ok, that's a first step.  But then we have an ugly situation
where if someone wants to fix a Debian menu entry, they have to know
that for i18n, they edit the .desktop file, and for everything else,
they edit the Debian menu file.  We should again be processing .desktop
natively.

 I am not sure about the maintenance
 burden on Debian developers.

Besides just Debian developers, again, I think system administrators are
going to (and should) be expecting to be able to edit their menus using
the freedesktop.org standard.

We can also send menu entries we create upstream, where they belong.  We
automatically benefit from other operating system's menu entries.

 Is there stand-alone implementation of this standard ?

Inherently, the freedesktop menu system just defines the layout; so
implementing it in a void doesn't make a lot of sense.  I suppose the
menu merging algorithms could be shared between implementations, but I
can't see it as being too difficult to do.  

The true implementation is where you present the menu tree to the user. 
For Debian, that presentation is translating the menu to support
legacy software like fvwm.  

Note the cool part of this is that after we do this work (for e.g.
fvwm), we can send it upstream!  That might be a first step towards
getting them to support the freedesktop standard, and leaving us with
less work to do.

 I have read it, and I have still difficulty to understand its
 full implication.

The implication is basically that we use it as the format of our menu
database (instead of /usr/lib/menu), and convert the menu-methods to
taking that information and translating it to legacy formats such as the
fvwm menu system.

Accepted apt-move 4.2.16 (i386 source)

2003-06-01 Thread Herbert Xu

-BEGIN PGP SIGNED MESSAGE-

Format: 1.7
Date: Sat, 31 May 2003 22:16:23 +1000
Source: apt-move
Binary: apt-move
Architecture: source i386
Version: 4.2.16
Distribution: unstable
Urgency: low
Maintainer: Herbert Xu [EMAIL PROTECTED]
Changed-By: Herbert Xu [EMAIL PROTECTED]
Description: 
 apt-move   - Maintain Debian packages in a package pool
Closes: 189335
Changes: 
 apt-move (4.2.16) unstable; urgency=low
 .
   * Clarified meaning of DIST in apt-move(8).
   * Sort keys after filling in blanks in make_pkg_list (Dub Spencer,
 closes: #189335).
Files: 
 1431f2392270c7d8cedbc9de71c41658 647 admin optional apt-move_4.2.16.dsc
 dea18ba4bb2031f6fc4e612500933d8b 44972 admin optional apt-move_4.2.16.tar.gz
 93d99a86df021e6e3fba5388e3028a8c 46652 admin optional apt-move_4.2.16_i386.deb

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQCVAwUBPtidc4fMnsf5AzQhAQEy9QP+KRq7z1REyQ9tyYAV5KbFtucuLCpar15Z
iUB90MeYUAOs8ttfl92F1NOafneLiNld4CMgPBCZREiCA4YSgJ1ySHNNcC8fo7AL
MNoOEEi8CvqhxdsJgIRT0vh1jB4l0QQ2QFL+A30z6JZR2TR4Q6bsZI3UK681GMxU
3WIAyrcPxQg=
=oDIz
-END PGP SIGNATURE-


Accepted:
apt-move_4.2.16.dsc
  to pool/main/a/apt-move/apt-move_4.2.16.dsc
apt-move_4.2.16.tar.gz
  to pool/main/a/apt-move/apt-move_4.2.16.tar.gz
apt-move_4.2.16_i386.deb
  to pool/main/a/apt-move/apt-move_4.2.16_i386.deb


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

Accepted rtf2latex 1.0fc2-2 (i386 source)

2003-06-01 Thread Ivo Timmermans

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 14:49:38 +0200
Source: rtf2latex
Binary: rtf2latex
Architecture: source i386
Version: 1.0fc2-2
Distribution: unstable
Urgency: low
Maintainer: Ivo Timmermans [EMAIL PROTECTED]
Changed-By: Ivo Timmermans [EMAIL PROTECTED]
Description: 
 rtf2latex  - Convert RTF files to LaTeX
Closes: 119754
Changes: 
 rtf2latex (1.0fc2-2) unstable; urgency=low
 .
   * Copy /usr/share/automake/missing to Unix.
   * pref/TeX-map.latin1: Recoded from MacRoman to ISO-8859-1.
 (Closes: #119754)
Files: 
 836e32d3b2d9aeccf801ce60da3f3261 560 tex optional rtf2latex_1.0fc2-2.dsc
 1a17539c2b97f81a3961a641723a449d 2 tex optional rtf2latex_1.0fc2-2.diff.gz
 29ac561f5c04073cae68713f34831cd3 239730 tex optional rtf2latex_1.0fc2-2_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2KUlbTEMl+oVcvERAum/AJ9Um7WRpbkKslxK0RFjGVO43nzX4wCgocVc
kGYeEj67xmPc4Y7hq08S1Xo=
=jgQ4
-END PGP SIGNATURE-


Accepted:
rtf2latex_1.0fc2-2.diff.gz
  to pool/main/r/rtf2latex/rtf2latex_1.0fc2-2.diff.gz
rtf2latex_1.0fc2-2.dsc
  to pool/main/r/rtf2latex/rtf2latex_1.0fc2-2.dsc
rtf2latex_1.0fc2-2_i386.deb
  to pool/main/r/rtf2latex/rtf2latex_1.0fc2-2_i386.deb


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

Accepted gcc-snapshot 20030531-1 (i386 source)

2003-06-01 Thread Matthias Klose

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 10:03:51 +0200
Source: gcc-snapshot
Binary: gcc-snapshot
Architecture: source i386
Version: 20030531-1
Distribution: unstable
Urgency: low
Maintainer: Debian GCC maintainers [EMAIL PROTECTED]
Changed-By: Matthias Klose [EMAIL PROTECTED]
Description: 
 gcc-snapshot - A SNAPSHOT of the The GNU Compiler Collection.
Changes: 
 gcc-snapshot (20030531-1) unstable; urgency=low
 .
   * CVS 20030531, taken from HEAD.
Files: 
 b238fab081426687d6f42b678bd594c7 1498 devel extra gcc-snapshot_20030531-1.dsc
 4a819154c9ec184c715d94ba340f5911 21506280 devel extra 
gcc-snapshot_20030531.orig.tar.gz
 9575b5cb35685666296a2cb27f9b1df5 64548 devel extra gcc-snapshot_20030531-1.diff.gz
 4484784c3696376b96c438dab3107819 40404460 devel extra gcc-snapshot_20030531-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2JdyStlRaw+TLJwRAk8RAJ9AL4cHZmuFaUR2tdLWMpTkrT/QEgCgnrXT
aKiNtcFIkFG8vYNoJHA+3eU=
=O+NB
-END PGP SIGNATURE-


Accepted:
gcc-snapshot_20030531-1.diff.gz
  to pool/main/g/gcc-snapshot/gcc-snapshot_20030531-1.diff.gz
gcc-snapshot_20030531-1.dsc
  to pool/main/g/gcc-snapshot/gcc-snapshot_20030531-1.dsc
gcc-snapshot_20030531-1_i386.deb
  to pool/main/g/gcc-snapshot/gcc-snapshot_20030531-1_i386.deb
gcc-snapshot_20030531.orig.tar.gz
  to pool/main/g/gcc-snapshot/gcc-snapshot_20030531.orig.tar.gz


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

Accepted tetex-base 2.0.2-4 (all source)

2003-06-01 Thread Atsuhito KOHDA

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 20:24:38 +0900
Source: tetex-base
Binary: tetex-extra tetex-doc tetex-base
Architecture: source all
Version: 2.0.2-4
Distribution: unstable
Urgency: low
Maintainer: teTeX maintainers [EMAIL PROTECTED]
Changed-By: Atsuhito KOHDA [EMAIL PROTECTED]
Description: 
 tetex-base - basic teTeX library files
 tetex-doc  - teTeX documentation
 tetex-extra - extra teTeX library files
Closes: 189886 192716
Changes: 
 tetex-base (2.0.2-4) unstable; urgency=low
 .
   * Fixed tetex-extra.postinst, it would now call updmap.  [kohda]
 (Closes: #192716)
   * Fixed newhelpindex.html with a patch by Hilmar Preusse [EMAIL PROTECTED]
 Thanks to his contribution.  cf. #188150, couldn't close yet?  [kohda]
   * Added sharutils to Build-Depends-Indep: field.  [kohda]  (Closes: #189886)
- Note for maintainers: this is only for generating euler.dvi which was
  lost by mistake so when the next upstream would be released, this should
  be unnecessary.
Files: 
 9f7c62aef565a0448a6e788282f18080 816 tex optional tetex-base_2.0.2-4.dsc
 a0e1082f21fb40cfdd2f1767f2719492 131469 tex optional tetex-base_2.0.2-4.diff.gz
 f1147251442a71f319e36927cceeda7f 14000582 tex optional tetex-base_2.0.2-4_all.deb
 debf292a20d0d36cd6c6cb1e50f53573 10515930 tex optional tetex-extra_2.0.2-4_all.deb
 bfa4216c9479290cf2b19694817ded9f 27522964 doc optional tetex-doc_2.0.2-4_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2Jsu1IXdL1v6kOwRAjbQAJ41eaS2JloBuSHxc9/oBkhmlIANXACgiyWi
XvKxRYhhMWy+TRFG0vByQAg=
=z+/y
-END PGP SIGNATURE-


Accepted:
tetex-base_2.0.2-4.diff.gz
  to pool/main/t/tetex-base/tetex-base_2.0.2-4.diff.gz
tetex-base_2.0.2-4.dsc
  to pool/main/t/tetex-base/tetex-base_2.0.2-4.dsc
tetex-base_2.0.2-4_all.deb
  to pool/main/t/tetex-base/tetex-base_2.0.2-4_all.deb
tetex-doc_2.0.2-4_all.deb
  to pool/main/t/tetex-base/tetex-doc_2.0.2-4_all.deb
tetex-extra_2.0.2-4_all.deb
  to pool/main/t/tetex-base/tetex-extra_2.0.2-4_all.deb


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

Accepted pcsc-lite 1.1.2-ubeta5-1 (i386 source)

2003-06-01 Thread Ludovic Rousseau

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 14:42:27 +0200
Source: pcsc-lite
Binary: libpcsclite-dev libpcsclite0 pcscd
Architecture: source i386
Version: 1.1.2-ubeta5-1
Distribution: unstable
Urgency: low
Maintainer: Ludovic Rousseau [EMAIL PROTECTED]
Changed-By: Ludovic Rousseau [EMAIL PROTECTED]
Description: 
 libpcsclite-dev - Middleware to access a smart card using PC/SC (development files)
 libpcsclite0 - Middleware to access a smart card using PC/SC (library)
 pcscd  - Middleware to access a smart card using PC/SC (daemon side)
Changes: 
 pcsc-lite (1.1.2-ubeta5-1) unstable; urgency=low
 .
   * New upstream release
   * pcscd Depends: libgempc430 | pcsc-ifd-handler to install the USB driver
 libgempc430 instead of a serial one which may cause conflict with an
 already installed serial device. This only occurs if no package providing
 pcsc-ifd-handler is installed yet.
   * debian/control: specify debhelper version in Build-Depends:
Files: 
 b0397010077fb9ae4b14500b96ee2b5b 640 misc extra pcsc-lite_1.1.2-ubeta5-1.dsc
 1e5645eb64f8cb14ea7fc00f4f29f5dd 683230 misc extra pcsc-lite_1.1.2-ubeta5.orig.tar.gz
 4d17cd6ea27ab8e866fed2d985880fe5 44130 misc extra pcsc-lite_1.1.2-ubeta5-1.diff.gz
 8531f01e792bb1e42b78a236d74edf6e 60366 misc extra pcscd_1.1.2-ubeta5-1_i386.deb
 a3493c4d9d824b3ab3cb420cd351d859 338312 libdevel extra 
libpcsclite-dev_1.1.2-ubeta5-1_i386.deb
 2b3f5bfb51b6e935eccb4aca8198ecb6 38850 libs extra libpcsclite0_1.1.2-ubeta5-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2KbXP0qKj+B/HPkRApxnAJ9Pp93/bIePiHLahJRn1u+gmLnFPwCcCfHH
YfAGiVFiqDUAz2AI9yQKrcc=
=fH/q
-END PGP SIGNATURE-


Accepted:
libpcsclite-dev_1.1.2-ubeta5-1_i386.deb
  to pool/main/p/pcsc-lite/libpcsclite-dev_1.1.2-ubeta5-1_i386.deb
libpcsclite0_1.1.2-ubeta5-1_i386.deb
  to pool/main/p/pcsc-lite/libpcsclite0_1.1.2-ubeta5-1_i386.deb
pcsc-lite_1.1.2-ubeta5-1.diff.gz
  to pool/main/p/pcsc-lite/pcsc-lite_1.1.2-ubeta5-1.diff.gz
pcsc-lite_1.1.2-ubeta5-1.dsc
  to pool/main/p/pcsc-lite/pcsc-lite_1.1.2-ubeta5-1.dsc
pcsc-lite_1.1.2-ubeta5.orig.tar.gz
  to pool/main/p/pcsc-lite/pcsc-lite_1.1.2-ubeta5.orig.tar.gz
pcscd_1.1.2-ubeta5-1_i386.deb
  to pool/main/p/pcsc-lite/pcscd_1.1.2-ubeta5-1_i386.deb


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

Accepted gnutls5 0.8.7-1 (i386 source all)

2003-06-01 Thread Ivo Timmermans

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 14:59:50 +0200
Source: gnutls5
Binary: libgnutls5 libgnutls5-dev libgnutls-doc
Architecture: source i386 all
Version: 0.8.7-1
Distribution: unstable
Urgency: low
Maintainer: Ivo Timmermans [EMAIL PROTECTED]
Changed-By: Ivo Timmermans [EMAIL PROTECTED]
Description: 
 libgnutls-doc - GNU TLS library - documentation and examples
 libgnutls5 - GNU TLS library - runtime library
 libgnutls5-dev - GNU TLS library - development files
Changes: 
 gnutls5 (0.8.7-1) unstable; urgency=low
 .
   * New upstream release.
   * debian/control: Updated Standards-Version.
Files: 
 14542906f1f10e03721b1b48e554e41f 750 devel optional gnutls5_0.8.7-1.dsc
 09c9003dbc9f189b3c652675930d218e 998594 devel optional gnutls5_0.8.7.orig.tar.gz
 b605fd23f5dbda38252a0bf4b9e3eaa6 30362 devel optional gnutls5_0.8.7-1.diff.gz
 e854c5975f765516d87e158af284d6e2 425804 doc optional libgnutls-doc_0.8.7-1_all.deb
 8541325e1b147816750bc4bfdd920423 250096 libdevel optional 
libgnutls5-dev_0.8.7-1_i386.deb
 3ed5f573b9c68721fd8396e5174f539b 181828 libs optional libgnutls5_0.8.7-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2KnMbTEMl+oVcvERApAdAJ4kprlL2XFlYlFpE6A6mssbrmrfsgCfe3EE
/CoWJiEcEU51WoSCq3TjkmQ=
=+Pjh
-END PGP SIGNATURE-


Accepted:
gnutls5_0.8.7-1.diff.gz
  to pool/main/g/gnutls5/gnutls5_0.8.7-1.diff.gz
gnutls5_0.8.7-1.dsc
  to pool/main/g/gnutls5/gnutls5_0.8.7-1.dsc
gnutls5_0.8.7.orig.tar.gz
  to pool/main/g/gnutls5/gnutls5_0.8.7.orig.tar.gz
libgnutls-doc_0.8.7-1_all.deb
  to pool/main/g/gnutls5/libgnutls-doc_0.8.7-1_all.deb
libgnutls5-dev_0.8.7-1_i386.deb
  to pool/main/g/gnutls5/libgnutls5-dev_0.8.7-1_i386.deb
libgnutls5_0.8.7-1_i386.deb
  to pool/main/g/gnutls5/libgnutls5_0.8.7-1_i386.deb


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

Accepted tetex-bin 2.0.2-4 (i386 source)

2003-06-01 Thread Atsuhito KOHDA

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 20:28:15 +0900
Source: tetex-bin
Binary: libkpathsea3 tetex-bin libkpathsea-dev
Architecture: source i386
Version: 2.0.2-4
Distribution: unstable
Urgency: low
Maintainer: teTeX maintainers [EMAIL PROTECTED]
Changed-By: Atsuhito KOHDA [EMAIL PROTECTED]
Description: 
 libkpathsea-dev - kpathsea.a and include files for teTeX
 libkpathsea3 - shared libkpathsea for teTeX
 tetex-bin  - teTeX binary files
Closes: 189370 191942
Changes: 
 tetex-bin (2.0.2-4) unstable; urgency=low
 .
   * Fixed update-* scripts, postinst etc. so that they could preserve user
 midifications.  [kohda]  (Closes: #189370)
   * Fixed rules so that flex didn't cause trouble.  [kohda]  (Closes: #191942)
   * Installed es.po contributed by Carlos Valdivia Yagüe
 [EMAIL PROTECTED] and many thanks to his contribution.  [kohda]
Files: 
 ff1ae47aa933a9415f6488deb8c2f325 974 tex optional tetex-bin_2.0.2-4.dsc
 da75a891885d3cb497927135f4bcc574 57144 tex optional tetex-bin_2.0.2-4.diff.gz
 08bf67605953b4cc79806592d716740a 3774334 tex optional tetex-bin_2.0.2-4_i386.deb
 baabfb7f70e858c72801232eb1eda0b5 48778 libs optional libkpathsea3_2.0.2-4_i386.deb
 fdfe5b17e6a0d743728271a3e79bcf97 64214 libdevel optional 
libkpathsea-dev_2.0.2-4_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2KGw1IXdL1v6kOwRAkm9AJ9zBfsYo6z1+xfiSE2sXG+YfVk+lQCeOU7b
Fc7ytR4oyswktcHqG+kT6XE=
=spsg
-END PGP SIGNATURE-


Accepted:
libkpathsea-dev_2.0.2-4_i386.deb
  to pool/main/t/tetex-bin/libkpathsea-dev_2.0.2-4_i386.deb
libkpathsea3_2.0.2-4_i386.deb
  to pool/main/t/tetex-bin/libkpathsea3_2.0.2-4_i386.deb
tetex-bin_2.0.2-4.diff.gz
  to pool/main/t/tetex-bin/tetex-bin_2.0.2-4.diff.gz
tetex-bin_2.0.2-4.dsc
  to pool/main/t/tetex-bin/tetex-bin_2.0.2-4.dsc
tetex-bin_2.0.2-4_i386.deb
  to pool/main/t/tetex-bin/tetex-bin_2.0.2-4_i386.deb


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

Accepted spacearyarya 1.0.2-2 (i386 source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 12:02:45 +0200
Source: spacearyarya
Binary: spacearyarya
Architecture: source i386
Version: 1.0.2-2
Distribution: unstable
Urgency: low
Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Description: 
 spacearyarya - a first person shoot'em-up in pseudo-3D
Changes: 
 spacearyarya (1.0.2-2) unstable; urgency=low
 .
   * Added 'space' as an alternate shot key (Fixes: #191500).
   * Set policy to 3.5.10.
Files: 
 7e7a8d813604c9cdfa49e3173089a403 607 games optional spacearyarya_1.0.2-2.dsc
 255be04533f19a30f2023c9710f6b898 14636 games optional spacearyarya_1.0.2-2.diff.gz
 fea27c4a1910ecb41fbc1c50768d2727 241770 games optional spacearyarya_1.0.2-2_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2LC8fPP1rylJn2ERAp6hAJwOnmT8KX5Mlatx5RnNXGzrnNh9VACfcPdF
+U6cl3D5E2b3h0as6ePgXys=
=Nw8f
-END PGP SIGNATURE-


Accepted:
spacearyarya_1.0.2-2.diff.gz
  to pool/main/s/spacearyarya/spacearyarya_1.0.2-2.diff.gz
spacearyarya_1.0.2-2.dsc
  to pool/main/s/spacearyarya/spacearyarya_1.0.2-2.dsc
spacearyarya_1.0.2-2_i386.deb
  to pool/main/s/spacearyarya/spacearyarya_1.0.2-2_i386.deb


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

Accepted cl-postoffice 1.8.2.2-1 (all source)

2003-06-01 Thread Kevin M. Rosenberg

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 07:41:30 -0600
Source: cl-postoffice
Binary: cl-postoffice
Architecture: source all
Version: 1.8.2.2-1
Distribution: unstable
Urgency: low
Maintainer: Kevin M. Rosenberg [EMAIL PROTECTED]
Changed-By: Kevin M. Rosenberg [EMAIL PROTECTED]
Description: 
 cl-postoffice - SMTP, POP,  IMAP interface library for Common Lisp Programs
Changes: 
 cl-postoffice (1.8.2.2-1) unstable; urgency=low
 .
   * Fix typo
Files: 
 1482955e05f144dcdd92a86a58c3125f 601 devel optional cl-postoffice_1.8.2.2-1.dsc
 8c558ad14149071bf0a84835ca181193 32795 devel optional 
cl-postoffice_1.8.2.2.orig.tar.gz
 6a492090c4522ac6e13788dee21283cc 4167 devel optional cl-postoffice_1.8.2.2-1.diff.gz
 4a0678492175d8d1a994c425e64c6fb9 37952 devel optional cl-postoffice_1.8.2.2-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2LG6ES7N8sSjgj4RApjyAKCRjs6C1DfPSnhv1yrMhGVzdg72UQCdG8kb
CNeYjcrL8HNY8uVeHd4WwFc=
=W7Pi
-END PGP SIGNATURE-


Accepted:
cl-postoffice_1.8.2.2-1.diff.gz
  to pool/main/c/cl-postoffice/cl-postoffice_1.8.2.2-1.diff.gz
cl-postoffice_1.8.2.2-1.dsc
  to pool/main/c/cl-postoffice/cl-postoffice_1.8.2.2-1.dsc
cl-postoffice_1.8.2.2-1_all.deb
  to pool/main/c/cl-postoffice/cl-postoffice_1.8.2.2-1_all.deb
cl-postoffice_1.8.2.2.orig.tar.gz
  to pool/main/c/cl-postoffice/cl-postoffice_1.8.2.2.orig.tar.gz


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

Accepted geki3 1.0.3-2 (i386 source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 30 May 2003 18:53:02 +0200
Source: geki3
Binary: geki3
Architecture: source i386
Version: 1.0.3-2
Distribution: unstable
Urgency: low
Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Description: 
 geki3  - an R-Type-like horizontal shoot'em-up
Changes: 
 geki3 (1.0.3-2) unstable; urgency=low
 .
   * Added 'space' as an alternate shot key (Fixes: #191500).
   * The Esc key now escapes to main menu.
   * Rephrased the package description.
   * Set policy to 3.5.10.
Files: 
 281b5242d09057736b2f13d447ee63da 579 games optional geki3_1.0.3-2.dsc
 304ec07cfb7c1247860e4b3b96aa971a 14529 games optional geki3_1.0.3-2.diff.gz
 ee8632e02ce75f17450443e5d7ae3c6d 653402 games optional geki3_1.0.3-2_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2LBFfPP1rylJn2ERAn2YAKCJJXhvulayr13gcwDQUdilIY3UqgCfRhzU
LBORhHnRIj0YqEf2hxmQjMA=
=ysf9
-END PGP SIGNATURE-


Accepted:
geki3_1.0.3-2.diff.gz
  to pool/main/g/geki3/geki3_1.0.3-2.diff.gz
geki3_1.0.3-2.dsc
  to pool/main/g/geki3/geki3_1.0.3-2.dsc
geki3_1.0.3-2_i386.deb
  to pool/main/g/geki3/geki3_1.0.3-2_i386.deb


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

Accepted geki2 2.0.3-2 (i386 source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 30 May 2003 18:48:29 +0200
Source: geki2
Binary: geki2
Architecture: source i386
Version: 2.0.3-2
Distribution: unstable
Urgency: low
Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Description: 
 geki2  - a Xenon-like vertical shoot'em-up
Changes: 
 geki2 (2.0.3-2) unstable; urgency=low
 .
   * Added 'space' as an alternate shot key (Fixes: #191500).
   * The Esc key now escapes to main menu.
   * Rephrased the package description.
   * Set policy to 3.5.10.
Files: 
 cf88442029ee5fb8002fec1eba8b24ad 579 games optional geki2_2.0.3-2.dsc
 b1f3a326b12c0dc82d2b450c16ae98e2 14579 games optional geki2_2.0.3-2.diff.gz
 861a8c70a7a3d5177d448c0f9c133057 666766 games optional geki2_2.0.3-2_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2K+4fPP1rylJn2ERArEfAKCgMKauwn7mshFKyeg7XPnbH4rmsgCfUDAk
CYWKXhdz1XlXjvMT2jPk8OM=
=lx0l
-END PGP SIGNATURE-


Accepted:
geki2_2.0.3-2.diff.gz
  to pool/main/g/geki2/geki2_2.0.3-2.diff.gz
geki2_2.0.3-2.dsc
  to pool/main/g/geki2/geki2_2.0.3-2.dsc
geki2_2.0.3-2_i386.deb
  to pool/main/g/geki2/geki2_2.0.3-2_i386.deb


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

Accepted grande 0.6-2 (i386 source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 12:01:35 +0200
Source: grande
Binary: grande
Architecture: source i386
Version: 0.6-2
Distribution: unstable
Urgency: low
Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Description: 
 grande - a vertical shoot'em-up
Closes: 191500
Changes: 
 grande (0.6-2) unstable; urgency=low
 .
   * Added 'space' as an alternate shot key (Closes: #191500).
   * Minor spelling fixes.
   * Set policy to 3.5.10.
Files: 
 33cb0dcc41c9eacef67670409fdfd920 577 games optional grande_0.6-2.dsc
 0200807cd47dd869294fad3c5912a4c7 13980 games optional grande_0.6-2.diff.gz
 932dac0baa23a2e4491333082057db2e 202202 games optional grande_0.6-2_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2K7FfPP1rylJn2ERAnxxAJ9QS++9lw+lV7t9LD1nKD4k6rdKSgCeOOLo
RFw7DhK0a5TVU0LcC8c8TqE=
=wUlj
-END PGP SIGNATURE-


Accepted:
grande_0.6-2.diff.gz
  to pool/main/g/grande/grande_0.6-2.diff.gz
grande_0.6-2.dsc
  to pool/main/g/grande/grande_0.6-2.dsc
grande_0.6-2_i386.deb
  to pool/main/g/grande/grande_0.6-2_i386.deb


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

Accepted libidl 0.8.2-1 (i386 source)

2003-06-01 Thread Sebastian Rittau

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 16:05:47 +0200
Source: libidl
Binary: libidl-dev libidl0
Architecture: source i386
Version: 0.8.2-1
Distribution: unstable
Urgency: low
Maintainer: Sebastian Rittau [EMAIL PROTECTED]
Changed-By: Sebastian Rittau [EMAIL PROTECTED]
Description: 
 libidl-dev - development files for programs that use libIDL
 libidl0- library for parsing CORBA IDL files
Closes: 195464
Changes: 
 libidl (0.8.2-1) unstable; urgency=low
 .
   * New upstream version, which obsoletes Daniel's flex patch.
   * Standards-Version 3.5.10 (no changes required).
   * Added debian/libidl-dev.manpages to ensure libIDL-config-2(1) is installed
 correctly.
   * Use cdbs.
 + Build-Depend on cdbs.
 + Build-Depend on debhelper = 4.1.0
 + Replaced debian/rules.
 + Closes: #195464 libidl build-dependends on debhelper =4.0.0, but uses
   --source-dir introduced in 4.0.4
Files: 
 ffb5f7058bbc2a6cec2135582a169ab7 631 - optional libidl_0.8.2-1.dsc
 cba8eecb55dfb58f2a535014db12fdd1 318923 - optional libidl_0.8.2.orig.tar.gz
 5691609d941883535e7bea5d2b8eeba5 3032 - optional libidl_0.8.2-1.diff.gz
 083949ce95f56183de976d4d96aa15f0 80068 libs optional libidl0_0.8.2-1_i386.deb
 ead40f9b5f2d6e9e58713a125d8f0f2a 97770 libdevel optional libidl-dev_0.8.2-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2LdKcU5mtElqGCcRAg0/AJ9nwJLNcKjBbMjUfwzpTWfRAFvNUQCdGO//
OT4mdfw0banFGetdj69RjBI=
=/x6b
-END PGP SIGNATURE-


Accepted:
libidl-dev_0.8.2-1_i386.deb
  to pool/main/libi/libidl/libidl-dev_0.8.2-1_i386.deb
libidl0_0.8.2-1_i386.deb
  to pool/main/libi/libidl/libidl0_0.8.2-1_i386.deb
libidl_0.8.2-1.diff.gz
  to pool/main/libi/libidl/libidl_0.8.2-1.diff.gz
libidl_0.8.2-1.dsc
  to pool/main/libi/libidl/libidl_0.8.2-1.dsc
libidl_0.8.2.orig.tar.gz
  to pool/main/libi/libidl/libidl_0.8.2.orig.tar.gz


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

Accepted kernel-image-speakup-i386 2.4.20-3 (i386 source all)

2003-06-01 Thread Deedra Waters

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 30 May 2003 15:40:42 -0400
Source: kernel-image-speakup-i386
Binary: kernel-image-2.4.20-speakup kernel-doc-2.4.20-speakup 
kernel-headers-2.4.20-speakup
Architecture: source i386 all
Version: 2.4.20-3
Distribution: unstable
Urgency: low
Maintainer: Deedra Waters [EMAIL PROTECTED]
Changed-By: Deedra Waters [EMAIL PROTECTED]
Description: 
 kernel-doc-2.4.20-speakup - Linux kernel specific documentation for version 
2.4.20-speakup
 kernel-headers-2.4.20-speakup - Header files related to Linux kernel version 
2.4.20-speakup
 kernel-image-2.4.20-speakup - Linux kernel binary image for version 2.4.20-speakup
Closes: 189177 191378
Changes: 
 kernel-image-speakup-i386 (2.4.20-3) unstable; urgency=low
 .
   * New maintainer
   * added -initrd to the make-kpkg call (Closes: #189177)
   * removed support for the doubletalk driver in the kernel
   * added util-linux to the build depends
 (Closes: #191378)
   * built the package against kernel-source-2.4.20-7 and updated the build
 depends
Files: 
 03db139ad36af7103a6a0a8973b90fc3 767 devel optional 
kernel-image-speakup-i386_2.4.20-3.dsc
 d547f5ca8e931391640149aae09f9d4b 13339 devel optional 
kernel-image-speakup-i386_2.4.20-3.tar.gz
 0d4ec7c0329887855c5efde4e72edd27 4215724 devel optional 
kernel-headers-2.4.20-speakup_2.4.20-3_i386.deb
 d5795646653c7a0d38b87a6292ea9de9 2120052 doc optional 
kernel-doc-2.4.20-speakup_2.4.20-3_all.deb
 fec83523577396d09f35c0f553ae 10256744 base optional 
kernel-image-2.4.20-speakup_2.4.20-3_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2LK63/wCKmsRPkQRArUzAJ0TEWxqbZG7PLCfG2XripHN5pbI4wCeN+pd
PgkD16fNrTuM3OCYiIhFgM0=
=M33C
-END PGP SIGNATURE-


Accepted:
kernel-doc-2.4.20-speakup_2.4.20-3_all.deb
  to pool/main/k/kernel-image-speakup-i386/kernel-doc-2.4.20-speakup_2.4.20-3_all.deb
kernel-headers-2.4.20-speakup_2.4.20-3_i386.deb
  to 
pool/main/k/kernel-image-speakup-i386/kernel-headers-2.4.20-speakup_2.4.20-3_i386.deb
kernel-image-2.4.20-speakup_2.4.20-3_i386.deb
  to 
pool/main/k/kernel-image-speakup-i386/kernel-image-2.4.20-speakup_2.4.20-3_i386.deb
kernel-image-speakup-i386_2.4.20-3.dsc
  to pool/main/k/kernel-image-speakup-i386/kernel-image-speakup-i386_2.4.20-3.dsc
kernel-image-speakup-i386_2.4.20-3.tar.gz
  to pool/main/k/kernel-image-speakup-i386/kernel-image-speakup-i386_2.4.20-3.tar.gz


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

Accepted xsane 0.91-3 (i386 source)

2003-06-01 Thread Julien BLACHE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 15:50:12 +0200
Source: xsane
Binary: xsane
Architecture: source i386
Version: 0.91-3
Distribution: unstable
Urgency: low
Maintainer: Julien BLACHE [EMAIL PROTECTED]
Changed-By: Julien BLACHE [EMAIL PROTECTED]
Description: 
 xsane  - A gtk-based X11 frontend for SANE (Scanner Access Now Easy)
Closes: 194222
Changes: 
 xsane (0.91-3) unstable; urgency=low
 .
   * GCC 3.3 is in unstable, arm should now build with -O2 (hopefully).
   * Fix libpng breakage, build-depends on libpng2-dev again.
   * Do not ship sane-backends-doc.html, sane-pnm-doc.html, they're out-of-date
 and not useful at all. Also use xsane-logo2.jpg in sane-problems-doc.html
 and sane-scantips-doc.html (closes: #194222).
   * Use /usr/bin/sensible-browser rather than www-browser as the default
 browser.
   * Standards-Version bumped to 3.5.10 (no changes).
Files: 
 85aed37a9e4df4281ed0685f86b0bb2a 773 graphics optional xsane_0.91-3.dsc
 fe10b145c9a353feb1a719189ddeaa9e 7542 graphics optional xsane_0.91-3.diff.gz
 db6ef33b05a768525a04a994906b717f 1617932 graphics optional xsane_0.91-3_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2LbszWFP1/XWUWkRAqOKAKC/k8hH4+7n//OzNKiTlzv6sB72vwCfVvtY
1yvc5kdPt1itOOfuGlFkoFE=
=Nbfm
-END PGP SIGNATURE-


Accepted:
xsane_0.91-3.diff.gz
  to pool/main/x/xsane/xsane_0.91-3.diff.gz
xsane_0.91-3.dsc
  to pool/main/x/xsane/xsane_0.91-3.dsc
xsane_0.91-3_i386.deb
  to pool/main/x/xsane/xsane_0.91-3_i386.deb


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

Accepted radiusd-livingston 2.1-9 (i386 source)

2003-06-01 Thread Paul Martin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 15:04:12 +0100
Source: radiusd-livingston
Binary: radiusd-livingston
Architecture: source i386
Version: 2.1-9
Distribution: unstable
Urgency: low
Maintainer: Paul Martin [EMAIL PROTECTED]
Changed-By: Paul Martin [EMAIL PROTECTED]
Description: 
 radiusd-livingston - Remote Authentication Dial-In User Service (RADIUS) server
Closes: 195497
Changes: 
 radiusd-livingston (2.1-9) unstable; urgency=low
 .
   * Removed #include of varargs.h from src/testuser.c. It doesn't
 use it, and GCC 3.3 has deprecated varargs.h. (Closes: #195497)
   * Fixed radiusd.8 and builddbm.8 NAME section heading.
   * Fix debian/copyright to stop lintian moaning.
   * Written a manpage for radtest.1.
   * Cleaned up compiler warnings:
 + added #include string.h to md5test.c, dbmrec.c, dbmkeys.c
 + changed sys_errlist[] reference to strerror() call in
   builddbm.c, dbmkeys.c, dbmrec.c, radiusd.c, proxy.c
 + commented out extra stuff after #endif in radiusd.c
   * Standards-Version: 3.5.10
Files: 
 d8c0c8bb0bca8c4dd339d3885d521fd5 601 net optional radiusd-livingston_2.1-9.dsc
 309a4221b067f153223b2f638fc5593f 16447 net optional radiusd-livingston_2.1-9.diff.gz
 7c35b463e8f5e2ce6edee1f0d022d710 69888 net optional radiusd-livingston_2.1-9_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2LfZ+gi+rt7UWRIRAkfEAJ9AiHQOqvjVIMBcZ0/ijaJW+jD+hwCeLrNU
fuvM+HkX26SbWZFJ/19AYtk=
=DirY
-END PGP SIGNATURE-


Accepted:
radiusd-livingston_2.1-9.diff.gz
  to pool/main/r/radiusd-livingston/radiusd-livingston_2.1-9.diff.gz
radiusd-livingston_2.1-9.dsc
  to pool/main/r/radiusd-livingston/radiusd-livingston_2.1-9.dsc
radiusd-livingston_2.1-9_i386.deb
  to pool/main/r/radiusd-livingston/radiusd-livingston_2.1-9_i386.deb


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

Accepted tth 3.37-1 (i386 source)

2003-06-01 Thread Ian Maclaine-cross

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 26 May 2003 10:21:22 +1000
Source: tth
Binary: tth
Architecture: source i386
Version: 3.37-1
Distribution: unstable
Urgency: low
Maintainer: Ian Maclaine-cross [EMAIL PROTECTED]
Changed-By: Ian Maclaine-cross [EMAIL PROTECTED]
Description: 
 tth- TeX/LaTeX to HTML converter
Changes: 
 tth (3.37-1) unstable; urgency=low
 .
   * New upstream release
Files: 
 8444be4400c28837cd6c0a2b4ae5a88b 510 non-free/tex optional tth_3.37-1.dsc
 d683ed85a23f025e4a6c9eeeb0f3def2 307098 non-free/tex optional tth_3.37.orig.tar.gz
 f83e73cef1f238aed160077ee74754f9 11436 non-free/tex optional tth_3.37-1.diff.gz
 dfcb8c762e367314afb59aa9f175fee9 270966 non-free/tex optional tth_3.37-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+2MVcqLuzZh0d+1MRAvwQAJ4lBQ2V0mIaaI53YZdviDQFlW7chQCeISdV
MCIXlf/s8V+Z0Kj+EDWh1kY=
=QoRd
-END PGP SIGNATURE-


Accepted:
tth_3.37-1.diff.gz
  to pool/non-free/t/tth/tth_3.37-1.diff.gz
tth_3.37-1.dsc
  to pool/non-free/t/tth/tth_3.37-1.dsc
tth_3.37-1_i386.deb
  to pool/non-free/t/tth/tth_3.37-1_i386.deb
tth_3.37.orig.tar.gz
  to pool/non-free/t/tth/tth_3.37.orig.tar.gz


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

Accepted mgp 1.09a.20030519-2 (i386 source)

2003-06-01 Thread Fumitoshi UKAI

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sun,  1 Jun 2003 00:30:59 +0900
Source: mgp
Binary: mgp
Architecture: source i386
Version: 1.09a.20030519-2
Distribution: unstable
Urgency: low
Maintainer: Fumitoshi UKAI [EMAIL PROTECTED]
Changed-By: Fumitoshi UKAI [EMAIL PROTECTED]
Description: 
 mgp- MagicPoint- an X11 based presentation tool
Closes: 194084 195494
Changes: 
 mgp (1.09a.20030519-2) unstable; urgency=low
 .
   * debian/control: build-depends: imlib11-dev. closes: Bug#195494
   * image/rlelib.c: no need varargs.h. closes: Bug#194084
Files: 
 f6c3f3ec5e538d8c7f8ea55aea3fb7c0 734 x11 optional mgp_1.09a.20030519-2.dsc
 f92f3013c8a9b08780074e09d53bf45e 18855 x11 optional mgp_1.09a.20030519-2.diff.gz
 45cc9d6b58e914e4357787dcf004a95e 625102 x11 optional mgp_1.09a.20030519-2_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2M5T9D5yZjzIjAkRAqTHAKCcRwZ5v0gcO3nY3WbQTpOVn2P+8QCfc+sr
kn1YtBvtNZRCjM2DLUXfowU=
=n/h4
-END PGP SIGNATURE-


Accepted:
mgp_1.09a.20030519-2.diff.gz
  to pool/main/m/mgp/mgp_1.09a.20030519-2.diff.gz
mgp_1.09a.20030519-2.dsc
  to pool/main/m/mgp/mgp_1.09a.20030519-2.dsc
mgp_1.09a.20030519-2_i386.deb
  to pool/main/m/mgp/mgp_1.09a.20030519-2_i386.deb


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

Accepted xsane 0.91-4 (i386 source)

2003-06-01 Thread Julien BLACHE

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 17:31:31 +0200
Source: xsane
Binary: xsane
Architecture: source i386
Version: 0.91-4
Distribution: unstable
Urgency: low
Maintainer: Julien BLACHE [EMAIL PROTECTED]
Changed-By: Julien BLACHE [EMAIL PROTECTED]
Description: 
 xsane  - A gtk-based X11 frontend for SANE (Scanner Access Now Easy)
Changes: 
 xsane (0.91-4) unstable; urgency=low
 .
   * Okay, the ICE on arm still exists, build with -O1 again.
Files: 
 74f921bf0257a48f295ce25d04693856 773 graphics optional xsane_0.91-4.dsc
 2acdedc946d8612a9f5ac75dae8fc467 7617 graphics optional xsane_0.91-4.diff.gz
 97ff6d74f34ad6325ce4a737295c33aa 1617970 graphics optional xsane_0.91-4_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2Mt9zWFP1/XWUWkRAkVSAKCpUPdwLHU/iM5Po/TmQp92Qt/JQQCfQueG
FY+sSljMQ9qfW2dZ3NKyWUI=
=2gZB
-END PGP SIGNATURE-


Accepted:
xsane_0.91-4.diff.gz
  to pool/main/x/xsane/xsane_0.91-4.diff.gz
xsane_0.91-4.dsc
  to pool/main/x/xsane/xsane_0.91-4.dsc
xsane_0.91-4_i386.deb
  to pool/main/x/xsane/xsane_0.91-4_i386.deb


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

Accepted gaim 1:0.64-2 (i386 source)

2003-06-01 Thread Robert McQueen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 16:56:18 +0100
Source: gaim
Binary: gaim
Architecture: source i386
Version: 1:0.64-2
Distribution: unstable
Urgency: low
Maintainer: Robert McQueen [EMAIL PROTECTED]
Changed-By: Robert McQueen [EMAIL PROTECTED]
Description: 
 gaim   - GPL multi-protocol instant messenger client
Closes: 188821 189511 189662 192366
Changes: 
 gaim (1:0.64-2) unstable; urgency=low
 .
   * Updated to standards version 3.5.10.
   * Replaced the Debian menu icon with a nice-looking one now that the menu
  policy doesn't mandate a crappy pallete.
   * So I spent a day cleaning the BTS for the Gaim package. Closed about 20
  bugs, reassigned 3 and fixed 7. This is the second batch of fixes.
   * Adjust wording so iconaway plugin no longer claims to minimise the away
  window, which is a dialog and shouldn't (or sometimes can't) be
  minimised. It wasn't doing it anyway. (closes: #188821)
   * Linkify text appended by the history plugin if the option is enabled
  to do this for conversations. (closes: #189511)
   * Validate UTF8 for incoming server-stored aliases because clients like
  Trillian send us random encodings but call them UTF-8. Avoids nasty
  crashing. (closes: #189662)
   * Added a Close button to the file transfer dialog.(closes: #192366)
Files: 
 a2eef9661643961327b42e91756b414d 654 net optional gaim_0.64-2.dsc
 e5ad3f498c6aa9fea994c9105421ae80 19341 net optional gaim_0.64-2.diff.gz
 d86091b643193aaffc004c5046690b3f 1813078 net optional gaim_0.64-2_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2NQJXcrf4TUB5sURAv5yAKCDNd/NTjBPUBZB0eetmNlJvHL4DQCfU5XP
2rAFZylGbJee9xox7mAXg/w=
=CeZs
-END PGP SIGNATURE-


Accepted:
gaim_0.64-2.diff.gz
  to pool/main/g/gaim/gaim_0.64-2.diff.gz
gaim_0.64-2.dsc
  to pool/main/g/gaim/gaim_0.64-2.dsc
gaim_0.64-2_i386.deb
  to pool/main/g/gaim/gaim_0.64-2_i386.deb


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

Accepted base-config 1.64 (all source)

2003-06-01 Thread Joey Hess

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 31 May 2003 12:17:51 -0400
Source: base-config
Binary: base-config
Architecture: source all
Version: 1.64
Distribution: unstable
Urgency: low
Maintainer: Joey Hess [EMAIL PROTECTED]
Changed-By: Joey Hess [EMAIL PROTECTED]
Description: 
 base-config - Debian base configuration package
Closes: 195442
Changes: 
 base-config (1.64) unstable; urgency=low
 .
   * Add Spanish man pages from Rubén Porras. Closes: #195442
Files: 
 55a10ee859a32d6ce67fb0c34973412c 518 base optional base-config_1.64.dsc
 a7aef742ac6b2d2c8b2f2a81188715bf 150087 base optional base-config_1.64.tar.gz
 62a9bc849b89d98fb3f371e6f39b824c 126324 base optional base-config_1.64_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+2NZI2tp5zXiKP0wRAra3AJ461+YXSmWkh5zjZBUinm+AqC1nuACePUFK
6s7sruPvxBEtyCAveOKUFuM=
=IFzE
-END PGP SIGNATURE-


Accepted:
base-config_1.64.dsc
  to pool/main/b/base-config/base-config_1.64.dsc
base-config_1.64.tar.gz
  to pool/main/b/base-config/base-config_1.64.tar.gz
base-config_1.64_all.deb
  to pool/main/b/base-config/base-config_1.64_all.deb


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

Accepted xbat 1.11-6 (i386 source)