date:20050218

Le vendredi 18 fvrier 2005  12:35 +0100, Marcin Orlowski a crit :
 It enforces you to fetch and install 9 additional components you simply
 do not want. Going that way, why do not put i.e. all the PHP modules in
 one deb? or even better - we shall have it all with apache. or even better
 we shall have one big webserver package with all the stuff related.
 Got the point?

You have to find a good balance between putting everything in a single
package and putting every random file in a separate package.

   And if it does, there's nothing stopping you from updating the package,
   say, every three months (unless there's a critical bug in one of the
   themes), is there?
 
 The thing I don't like in debian is that it usually stays far behind
 in term of updating packages. I often hear Debian? no, I want be up
 to date.

Hey, we're talking about kwin themes. Not stuff that gets updated every
other week.

 Why do you imitate you care modem users? You care a few bytes more in
 Packages (text file! gzipped!) but ommit additional megabytes in the
 package? It's like promoting bloatware ;)

No, this is promoting clarity in our packages listing. Users will get
lost if they have to install separate packages for things as trivial as
kwin themes.

Our GDM themes are all in a single package; do you think it would do any
good to separate them, only to save 1 MB of download? Our users would be
lost; there's no way you can tell which GDM theme you want before having
seen what they look like. It's exactly the same for kwin themes: if the
user wants a specific theme, having a special package for it is almost
no gain, as the user can download the theme and install it in a few
seconds. If you don't know what theme you want, you'll have to install
all of them and test them. That's when a single package becomes handy.

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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread Bernd Eckenfels

In article [EMAIL PROTECTED] you wrote:
 I had a similar experience when I reported bugs in Unstable on the list 
 and was roundly flamed for not reading bug reports.

reportbug is pretty helpfull here, however some packages do have a very
large list, so misssing an already reported bug can happen and is nothing we
should flame our users for.

Greetings
Bernd


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

Re: Bug#286214: ITP: kwin-style-asteroid -- Pixel-for-pixel clone of Win2000 GUI style for KDE

2005-02-18 Thread Wouter Verhelst

On Fri, Feb 18, 2005 at 12:35:42PM +0100, Marcin Orlowski wrote:
 Wouter Verhelst wrote:
  Merging all these into one package will not do much harm to the user
  (who will be able to install a 2M package on top of his 250MB KDE
  installation to get all the choice of GUI themes he would ever want to
  have); OTOH, more packages do have a negative impact on everyone --
  increased size of the Packages file (which isn't good for modem users
  and people with slower hardware) and increased overall size of the
  archive.
 
 Why do you imitate you care modem users? You care a few bytes more in
 Packages (text file! gzipped!)

That has an impact on everyone, especially people with slower hardware.
I know what I'm talking about, I'm an m68k porter.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: please post listing and status of NEW queue

2005-02-18 Thread Jeroen van Wolffelaar

On Fri, Feb 18, 2005 at 08:46:19AM +0100, Igor Genibel wrote:
 On Thursday 17 February 2005 20:56, Joerg Jaspert wrote:
  One purpose of the new.html on newraff is to have less (or none)
  script running on merkel that wastes CPU cycles playing around with
  .changes files. Merkel is the wrong place for such stuff. :) (And
  merkel is updated only once a day, so it makes not much sense to run
  scripts hourly there, just to have mentioned that).
 
 I have never said that I will recompute the page but only integrate a per 
 developer extract from this result. As most of information provided by 
 qa.d.o/developer.php :)

FWIW, I think developer.php gives a useful DDPO, but I'm a bit puzzled
why also some kinds of per-developer or even per-package information is
all also generated from developer.php. The file as it is is already
quite large, I think it can better be in a new 'new.php' or something,
if you really want to add it, as it probably hardly shares any code from
developer.php (and if it does, that should IMHO be refactored into a
include file).

Similar for per-package popcon, per-maintainer wnpp, per-package
excuses: I think they are better off in separate files, and not in one
big php script behaving completely different depending on arguments.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber  MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl

Re: libpng evil setjmp 'fixes'

Le vendredi 18 fvrier 2005  12:12 +1030, Ron a crit : 
 Hi,
 
 Are you aware of this:
 
 /usr/include/pngconf.h:310:2: #error png.h already includes setjmp.h
  with some additional fixup.
 
 It occurs if you (or any other header you include) #include setjmp.h
 before png.h -- so the potential for conflict with other users of
 setjmp is very high.
 
 Is there anything we can do about this?  The sjlj error handling is
 nice, but what is needed here that (for eg.) libjpeg does not need to
 get much the same effect.  My first impression is that this should be
 fixed before the stable release, as I can't see what extenuating
 circumstances might justify it, but I'm always open to the idea they
 might exist...

This is to force the system not to use the BSD-compatibility setjmp.
According to the sources, the X includes set _BSD_SOURCE, and doing this
bring a different behaviour for setjmp.

However:
1) I cannot find any reference to _BSD_SOURCE or such stuff in the X
includes, at least for XFree. That would be a bug, as _BSD_SOURCE should
be defined by the user, not the includes.
2) The fix is dependent on glibc features, and with glibc 2.3, it is
moot. The features.h header is included before the _BSD_SOURCE stuff,
through sys/types.h. Thus, if _BSD_SOURCE is set, it will define
__FAVOR_BSD, and setjmp.h will still use the BSD version. I have just
tested that building libpng with -D_BSD_SOURCE actually makes use of the
BSD version of setjmp.
3) I don't really understand what can break when using the BSD version
of setjmp. Is it when an application uses the BSD semantics while the
library uses the Linux semantics? Are there really cases where it
matters, especially when the difference is so small? It should only
matter if the application uses longjmp on a context saved by libpng
*and* the signal mask was changed meanwhile.

If no one opposes, I can remove it from the Debian package, letting a
warning when _BSD_SOURCE is defined, but I'd like to be sure that
nothing will break, so I'd like some more opinions. Cc-ing the lists,
maybe someone will have more clues.

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

Re: problem of savelog

Atsuhito Kohda [EMAIL PROTECTED] schrieb:

 Thanks for your infomation.  I met the same problem today's morning
 so I changed exim to exim4 ;-)

Fine to hear this can be done today's morning.  Is the configuration
migrated to the new version (mine is pretty simple), or does one have to
start anew?

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

Bug#295835: ITP: trayer -- lightweight GTK2-based systray for UNIX desktop

2005-02-18 Thread Tomasz Melcer

Package: wnpp
Severity: wishlist
Owner: Tomasz Melcer [EMAIL PROTECTED]


* Package name: trayer
  Version : 1.0
  Upstream Author : Maciej Delmanowski [EMAIL PROTECTED]
* URL : http://fvwm-crystal.berlios.de/files/files/trayer/
* License : MIT
  Description : lightweight GTK2-based systray for UNIX desktop

trayer is small program designed to provide systray functionality
present in GNOME/KDE desktop enviroments for window managers which
does not support that function. System tray is a place, where various
applications put their icons, so they are always visible presenting
status of an application and allowing user to control the program.

trayer's code was extracted from fbpanel application, you can find
more about it on it's homepage: http://fbpanel.sourceforge.net/

You can find new versions of trayer and support on FVWM-Crystal
project homepage: http://fvwm-crystal.berlios.de/
  

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-k7
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)

--
Sprawdz NOWE parametry hostingu!
 http://link.interia.pl/f1857  



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

new.html per-developer data inclusion in developer.php (Was: please post listing and status of NEW queue)

2005-02-18 Thread Igor Genibel

On Friday 18 February 2005 13:33, Jeroen van Wolffelaar wrote:
[...]
 FWIW, I think developer.php gives a useful DDPO, but I'm a bit puzzled
 why also some kinds of per-developer or even per-package information
 is all also generated from developer.php. The file as it is is already
 quite large, I think it can better be in a new 'new.php' or something,
 if you really want to add it, as it probably hardly shares any code
 from developer.php (and if it does, that should IMHO be refactored
 into a include file).

No information is generated from developer.php. But I agree with you 
about the large generated file (by backends). 
I need to rewrite the backends in order to have a relational schema 
located in several data files. But the lack of time, and probably the 
lack of outer investment implies that this rework has not already been 
done.

 Similar for per-package popcon, per-maintainer wnpp, per-package
 excuses: I think they are better off in separate files, and not in one
 big php script behaving completely different depending on arguments.

That's what I wanted to do. Parse the new.html file in order to provided 
excuse/popcon like data files that could be included with php.
The popcon and the wnpp backend processes are standalone scripts that 
could be easily used out of the box.

To recall the main goal of developer.php is to provide a unique place 
where all the spreaded debian developer related infomation will be 
nicely displayed. IMHO this kind of information (new queue process 
per-developer) might be useful for all developers.
-- 
Igor Genibel
«Non bene pro toto libertas venditur auro»
Freedom is not sold for all the gold in the world.
Dubrovnik motto


pgp5X1frCC6pO.pgp
Description: PGP signature

Re: problem of savelog

2005-02-18 Thread Wouter Verhelst

On Fri, Feb 18, 2005 at 01:53:20PM +0100, Frank Küster wrote:
 Atsuhito Kohda [EMAIL PROTECTED] schrieb:
 
  Thanks for your infomation.  I met the same problem today's morning
  so I changed exim to exim4 ;-)
 
 Fine to hear this can be done today's morning.  Is the configuration
 migrated to the new version (mine is pretty simple), or does one have to
 start anew?

In all but the most complex cases, migrating exim v3 to exim v4 involves
running /usr/sbin/exim_convert4r4 on /etc/exim/exim.conf, and copying te
resulting file to /etc/exim4/exim4.conf. In the cases where this is not
true (or, better said, in the cases where there is a slim chance that
this might not be true if you're unlucky), exim_convert4r4 will warn
you about that.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

Re: problem of savelog

On Fri, 18 Feb 2005 13:53:20 +0100, Frank Küster [EMAIL PROTECTED]
wrote:
Atsuhito Kohda [EMAIL PROTECTED] schrieb:
 Thanks for your infomation.  I met the same problem today's morning
 so I changed exim to exim4 ;-)

Fine to hear this can be done today's morning.  Is the configuration
migrated to the new version (mine is pretty simple), or does one have to
start anew?

If your exim 3 configuration was generated by eximconfig, exim4 will
try to guess your answers you have given when configuring exim3, and
will pre-seed debconf accordingly.

Greetings
Marc

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

Re: problem of savelog

On Fri, 18 Feb 2005 14:51:39 +0100, Wouter Verhelst
[EMAIL PROTECTED] wrote:
In all but the most complex cases, migrating exim v3 to exim v4 involves
running /usr/sbin/exim_convert4r4 on /etc/exim/exim.conf, and copying te
resulting file to /etc/exim4/exim4.conf.

Actually, this is deprecated. The Debian Exim 4 maintainers strongly
recommend using the debconf-driven setup scheme.

See /usr/share/doc/exim4-base/README.Debian.gz.

Greetings
Marc

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

Re: problem of savelog

2005-02-18 Thread Atsuhito Kohda

From: Marc Haber [EMAIL PROTECTED]
Subject: Re: problem of savelog
Date: Fri, 18 Feb 2005 15:06:45 +0100

 Fine to hear this can be done today's morning.  Is the configuration
 migrated to the new version (mine is pretty simple), or does one have to
 start anew?

 If your exim 3 configuration was generated by eximconfig, exim4 will
 try to guess your answers you have given when configuring exim3, and
 will pre-seed debconf accordingly.

The above is exactly what I experienced today.
(To tell the truth, this was not my first migration but
I already migrated from exim to exim4 with another intel
machine recently.)

Regards,2005.2.18(Fri)

-- 
 Debian Developer  Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda [EMAIL PROTECTED]
 Department of Math., Univ. of Tokushima

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

Re: problem of savelog

On Fri, 18 Feb 2005 23:25:18 +0900 (JST), Atsuhito Kohda
[EMAIL PROTECTED] wrote:
From: Marc Haber [EMAIL PROTECTED]
 If your exim 3 configuration was generated by eximconfig, exim4 will
 try to guess your answers you have given when configuring exim3, and
 will pre-seed debconf accordingly.

The above is exactly what I experienced today.

Did it work and leave you with an operational exim 4?

Greetins
Marc

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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread Steve Greenland

On 17-Feb-05, 15:07 (CST), Tollef Fog Heen [EMAIL PROTECTED] wrote: 
 * John Hasler 
 | Does it tell you which is the upstream way?  Most new users won't know.
 
  The Debian exim4 packages can either use a single monolithic file
  (/etc/exim4/exim4.conf.template) or about 40 small files in
  /etc/exim4/conf.d/ to generate the final configuration.
  .
  The former is better suited for large modifications and is generally
  more stable, whereas the latter offers a comfortable way to make
  smaller
  modifications but is more fragile and might break if modified
  extensively.
  .
  If you are unsure then you should not use split configuration.
 
 I think the last point sums it up -- use monolithic configuration if
 you don't understand what the question is about.

No where in the Debconf note does it say which is the upstream way.

And does it default to one big file?

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Errors in RC-bug list (was: Release-critical Bugreport for February 18, 2005)

BugScan reporter [EMAIL PROTECTED] wrote:

 Package: tex4ht (debian/main)
 Maintainer: Debian QA Group [EMAIL PROTECTED]
   219482 [  UI] tex4ht: Documentation source file missing

 Package: texgd (debian/main)

But actually tex4ht has two RC-bugs (both tagged sarge-ignore, but the
package is being worked on, see [EMAIL PROTECTED]).

What happened to the other RC bug? 

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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

Le vendredi 18 fvrier 2005  08:37 -0600, Steve Greenland a crit :
 No where in the Debconf note does it say which is the upstream way.

This has nothing to do in a debconf note.

 And does it default to one big file?

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

Re: problem of savelog

2005-02-18 Thread Atsuhito Kohda

From: Marc Haber [EMAIL PROTECTED]
Subject: Re: problem of savelog
Date: Fri, 18 Feb 2005 15:55:15 +0100

 On Fri, 18 Feb 2005 23:25:18 +0900 (JST), Atsuhito Kohda
 [EMAIL PROTECTED] wrote:
 From: Marc Haber [EMAIL PROTECTED]
  If your exim 3 configuration was generated by eximconfig, exim4 will
  try to guess your answers you have given when configuring exim3, and
  will pre-seed debconf accordingly.

 The above is exactly what I experienced today.

 Did it work and leave you with an operational exim 4?

Yes, it works fine.  Further, with exim4-daemon-heavy and clamav,
I believe my system rejects virus emails as before (with exim,
exiscan and clamav).

Regards,2005.2.19(Sat)

-- 
 Debian Developer  Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda [EMAIL PROTECTED]
 Department of Math., Univ. of Tokushima

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

regarding mdnsresponder and dns-sd

2005-02-18 Thread narender baderia

Respected Sir
 Please tell me the standard or more efficient
 version of mdnsresponder which can be use on linux
 platform with dns-based service discovery
protocol.and
 multicast dns client.
If possible please tell me the approach to
 implement the dns-sd and the api which can be used to
 implement it.
 Please reply as soon as possible

thank you

narender



Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony


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

Re: Errors in RC-bug list (was: Release-critical Bugreport for February 18, 2005)

2005-02-18 Thread Colin Watson

On Fri, Feb 18, 2005 at 04:09:31PM +0100, Frank Küster wrote:
 BugScan reporter [EMAIL PROTECTED] wrote:
  Package: tex4ht (debian/main)
  Maintainer: Debian QA Group [EMAIL PROTECTED]
219482 [  UI] tex4ht: Documentation source file missing
 
  Package: texgd (debian/main)
 
 But actually tex4ht has two RC-bugs (both tagged sarge-ignore, but the
 package is being worked on, see [EMAIL PROTECTED]).
 
 What happened to the other RC bug? 

They're merged, so it only lists the first.

-- 
Colin Watson   [EMAIL PROTECTED]


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

[Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]

2005-02-18 Thread Clint Byrum

First let me say that I mean no offense to the debian community, or any
of the people in the forwarded message. I'm frustrated and I want to see
things improve...

Now, can someone please tell me how messages like the one below, and
others, aren't indicative that debian should drop s390, mipsel, and
maybe hppa from the list of architectures? How about we release for
i386, sparc, and powerpc, and let the others release on their own
schedule? This business of supporting 11 architectures and making sure
they're all 100% right before releasing is just about the worst idea
ever.

ARGH is all I can say. As a once die-hard debian fan, I'm ashamed to be
associated with it now. The once great, but now slow, lumbering beast
will never be what it could have been if things continue like this.

Please somebody convince me that I'm wrong.

:-|

 Forwarded Message 
From: Steve Langasek [EMAIL PROTECTED]
To: Aurélien Jarno [EMAIL PROTECTED]
Cc: debian-release@lists.debian.org
Subject: Re: GTK+2.0 2.6.2-3 and buildds running out of space
Date: Fri, 18 Feb 2005 08:57:18 -0800
On Thu, Feb 17, 2005 at 05:49:24PM +0100, Aurélien Jarno wrote:
 GTK+2.0 version 2.6.2 has been recently uploaded and it seems to fail to 
 build on some buildds because they ran out of space. Currently it is the 
 case of sparc, arm and s390 buildds.

 It seems that this is preventing a lot of packages to go to Sarge (even 
 if the package is only 2 days old), including gftp for which a security 
 alert has just been announced (DSA 686-1). That's mean we definitively 
 need to have this new version of GTK+2.0 in Sarge.

 I don't know if the problem with the buildds has been addressed or not, 
 but if need, I can build GTK+2.0 on a sparc machine into a fresh Sid 
 chroot. Please tell me if you find it could be useful.

Since any security updates for sarge will most certainly be built on the
buildds, we do need to ensure that our buildds can actually handle such a
package.  Do you know how much build space might be saved by disabling the
testsuite for static libs on all architectures, instead of just on the
mipsen?

-- 
Clint Byrum [EMAIL PROTECTED]


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

Re: The ghost of libc-dev

2005-02-18 Thread Bill Allombert

On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote:
 So, while discussing a bug in a -dev with the maintainer, recently, it
 reminded me to review an old thread from d-devel regarding the weird
 situation with libc-dev as a pure virtual package.
 
 The summary is this:
 
 *) The 'libc-dev' package is a pure virtual package, roughly meaning
 provides the headers and symlinks for C library development.
 
 *) The standard way of doing this today is to have a -dev package which
 needs libc headers Depend on 'libc6-dev | libc-dev' to avoid the situation
 of having only a pure-virtual package.

I have a genuine question:
Consider a -dev package that Depends on libc6-dev. Is there any drawback
to make it Depends on libc-dev instead ?

1) libc6-dev is a purely virtual dependency on alpha and ia64. libc-dev is
a purely virtual dependency evrywhere, but is it really worse ?

2) The 'Depends: libc6-dev' has no bearing on buildd, since a package
providing libc6-dev is always installed as part of build-essential.

So, am I overlooking something ? I am not objecting to make it depends on
'libc6-dev | libc-dev' but I don't see the point.

Thanks in advance for any enlightenment.
-- 
Bill. [EMAIL PROTECTED]

Imagine a large red swirl here. 


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

Re: The ghost of libc-dev

2005-02-18 Thread Kurt Roeckx

On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote:
 
 *) The standard way of doing this today is to have a -dev package which
 needs libc headers Depend on 'libc6-dev | libc-dev' to avoid the situation
 of having only a pure-virtual package.

Why does that rule exists anyway?  It's already part of
build-essential.  And build-essential is already defined for each
arch.

 *) On further reflection, and re-reading other parts of the thread, I think
 it might be more useful to try to implement the following, and I would like
 feedback on whether this needs adjustment, or people think it would be a
 good idea. If it works, I can publish it as it's own tool, or try to get it
 included in the debhelper package (the latter probably being prefferable).
 
 dh_devincludes

I was also thinking about something like that some time ago.  I'm
just afraid it's not going to be very easy to get correct.

 Searches the target package for *.h files, then searches each file found
 for #include lines. Attempts to resolve each include, checking first the
 package area, then the system library area. If the file is found in the
 package, it is ignored; if not found at all, it throws a warning. However,
 if the package is found in the system area, it checks the installed files
 information and extracts the name of the package which provides that file.
 The list of packages found is places into the substvar dev:Depends.

I was thinking about libtool .la files and pkgconfig .pc files
and looking at the libraries they require.  (In case they are
using it.)

 * Does it need some way (a la shlibs) to resolve problems with what
 version of the -dev package is needed for this, or is this likely to be
 uncommon enough to expect the maintainer to override it where necessary?

I think there are lots of cases where there currenctly is a
versioned dependency on a -dev package.  However, I'm not sure if
all of them are needed.


Kurt


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

Re: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]

Clint Byrum [EMAIL PROTECTED] wrote:

 Now, can someone please tell me how messages like the one below, and
 others, aren't indicative that debian should drop s390, mipsel, and
 maybe hppa from the list of architectures? How about we release for
 i386, sparc, and powerpc, and let the others release on their own
 schedule? 
[...]
 On Thu, Feb 17, 2005 at 05:49:24PM +0100, Aurélien Jarno wrote:
 GTK+2.0 version 2.6.2 has been recently uploaded and it seems to fail to 
 build on some buildds because they ran out of space. Currently it is the 
 case of sparc, arm and s390 buildds.

If the build fails on sparc, arm, and s390, how should this be
indicative that we should drop s390, mipsel, and hppa?

[Steve Langasek]

 Do you know how much build space might be saved by disabling the
 testsuite for static libs on all architectures, instead of just on the
 mipsen?

Or because there might be a simple way to solve the problem?

Regards, Frank

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

Re: Errors in RC-bug list

Colin Watson [EMAIL PROTECTED] schrieb:

 On Fri, Feb 18, 2005 at 04:09:31PM +0100, Frank Küster wrote:
 BugScan reporter [EMAIL PROTECTED] wrote:
  Package: tex4ht (debian/main)
  Maintainer: Debian QA Group [EMAIL PROTECTED]
219482 [  UI] tex4ht: Documentation source file missing
 
  Package: texgd (debian/main)
 
 But actually tex4ht has two RC-bugs (both tagged sarge-ignore, but the
 package is being worked on, see [EMAIL PROTECTED]).
 
 What happened to the other RC bug? 

 They're merged, so it only lists the first.

Stupid that I didn't notice. I fear they will have to be split, since
244276 is fixed upstream, while 219482 doesn't seem to be.

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

Re: problem of savelog

2005-02-18 Thread Wouter Verhelst

On Fri, Feb 18, 2005 at 03:07:49PM +0100, Marc Haber wrote:
 On Fri, 18 Feb 2005 14:51:39 +0100, Wouter Verhelst
 [EMAIL PROTECTED] wrote:
 In all but the most complex cases, migrating exim v3 to exim v4 involves
 running /usr/sbin/exim_convert4r4 on /etc/exim/exim.conf, and copying te
 resulting file to /etc/exim4/exim4.conf.
 
 Actually, this is deprecated. The Debian Exim 4 maintainers strongly
 recommend using the debconf-driven setup scheme.

Well, yes, but it works in many more cases, and it's what upstream
supports. And I personally prefer the one-file setup anyway -- if I
wanted many configuration files, I'd use Postfix.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


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

honest good time

2005-02-18 Thread trawlJohns



Nail a redhead on secretly


http://underpartnerbrachycatalectic.com/sse/









offa-dis : underpartnerbrachycatalectic.com/yap/


The dolphin metamorphism dignify .
She bridgeable jacksonville truly consummate inexpiable .
bryozoa cardinal classroom sieglinda .
lava stadia am funnel exposit .
The inland comrade foxglove embarcadero nickel .
She actaeon superstition atkinson . And
ambiguity excursus furrow lurid .
She chrysolite exigent colloquia .and
tail version heuser coefficient benedict .
The gaelic instep arduous breakdown ndjamena .
boorish huxley bilateral uris bearish acrimonious .and
irwin eavesdropping homeomorph durable .
peepy vassar laureate clyde punditry .
The autonomic bateman individuate catskill .
She flocculate tennessee corrector irritate lee .
The roundoff variac applicant deletion beautify circumcision .
della uremia wolfgang lawrencium cutaneous .

debian-devel@lists.debian.org

Re: pwc-source headed for unstable this weekend

2005-02-18 Thread Eric Lavarde

Hi,
(I assume everybody is on -devel, like I am, and as it seems the problem 
sits between keyboard and chair, no bug report either).

This might very well be, as I didn't compile the kernel myself (I just 
use the standard kernel-image-2.6.10-1-k7 package) but used 
kernel-source-2.6.10 with the .config from the image package, make 
oldconfig and make dep (which I was told is deprecated, so).

So, basically, your saying that the right way to do this kind of things 
is to use the corresponding kernel-headers package, and apt-get tells me 
that I need as well kernel-kbuild to build out-of-tree kernel modules 
which seems to be exactly what I need.

Thanks, Eric
Henning Makholm wrote:
Scripsit sean finney [EMAIL PROTECTED]
On Thu, Feb 17, 2005 at 09:08:11PM +0100, Eric Lavarde wrote:

pwc: no version for struct_module found: kernel tainted.

i'm guessing that this has to do with how you compiled the module.

IME, this message is typically seen when one complies a module against
a 2.6 kernel tree where 'make clean' has been run since the latest
kernel build.
The kernel-headers-2.6.*-foo packages should ship enough intermediate
files in /usr/src/kernel-headers/* to prevent this problem, but one
easily gets in trouble [1] if one compiles custom kernels without
being aware of the problem.
[1] Well, such as it is. As long as one does not get oneself in more
trouble by trying to use the module against a different kernel
build, the warning message at load time seems to be all that
happens.
--
Gewalt ist die letzte Zuflucht der Inkompetenz.
Violence is the Last Resort of the Incompetent.
Gwalt jest ostatnem schronieniem niekompetencji.
La violence est le dernier refuge de l'incompetence.
~ Isaac Asimov
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: problem of savelog

On Fri, 18 Feb 2005 16:43:48 +0100, Wouter Verhelst
[EMAIL PROTECTED] wrote:
Well, yes, but it works in many more cases, and it's what upstream
supports.

Frankly, upstream is not quite interested any more in supporting
convert4r4. I have forwarded a bug report regarding the script
upstream, and upstream said that convert4r4 is not being used any more
and that it is too much work to fix that bug.

Greetings
Marc

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

Re: problem of savelog

2005-02-18 Thread Clint Adams

 ii  debianutils2.12.0 Miscellaneous utilities specific to Debian
 ii  exim   3.36-13An MTA (Mail Transport Agent)
 
 Is there anyone who encountered the same problem or is this 
 Alpha specific or even specific to my machine?

This should be fixed in debianutils 2.13.0.


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

Re: The ghost of libc-dev

2005-02-18 Thread Joel Aelwyn

On Fri, Feb 18, 2005 at 06:30:42PM +0100, Bill Allombert wrote:
 On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote:
  So, while discussing a bug in a -dev with the maintainer, recently, it
  reminded me to review an old thread from d-devel regarding the weird
  situation with libc-dev as a pure virtual package.
  
  The summary is this:
  
  *) The 'libc-dev' package is a pure virtual package, roughly meaning
  provides the headers and symlinks for C library development.
  
  *) The standard way of doing this today is to have a -dev package which
  needs libc headers Depend on 'libc6-dev | libc-dev' to avoid the situation
  of having only a pure-virtual package.
 
 I have a genuine question:
 Consider a -dev package that Depends on libc6-dev. Is there any drawback
 to make it Depends on libc-dev instead ?
 
 1) libc6-dev is a purely virtual dependency on alpha and ia64. libc-dev is
 a purely virtual dependency evrywhere, but is it really worse ?
 
 2) The 'Depends: libc6-dev' has no bearing on buildd, since a package
 providing libc6-dev is always installed as part of build-essential.
 
 So, am I overlooking something ? I am not objecting to make it depends on
 'libc6-dev | libc-dev' but I don't see the point.
 
 Thanks in advance for any enlightenment.

The proposal for the debhelper script is actually to make the issue
obsolete; on any given platform, you would get only the libcX-dev that was
relevant to that platform (libc6-dev on i386, libc12-dev on netbsd-i386,
libc1-dev on kfreebsd-i386, libc6.1-dev on alpha and ia64, etc).

I suspect the reason we haven't seen more breakages than we already do is
that a versioned dependancy on libc*-dev seems to be fairly rare, and the
glibc ones all Provide: libc6-dev anyway, meaning that APT can resolve it
based on the (effectively mixed-virtual) libc6-dev, rather than falling
back to libc-dev.
-- 
Joel Aelwyn [EMAIL PROTECTED]   ,''`.
 : :' :
 `. `'
   `-


signature.asc
Description: Digital signature

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread Steve Greenland

On 18-Feb-05, 09:06 (CST), Josselin Mouette [EMAIL PROTECTED] wrote: 
 Le vendredi 18 f??vrier 2005 ?? 08:37 -0600, Steve Greenland a ??crit :
  No where in the Debconf note does it say which is the upstream way.
 
 This has nothing to do in a debconf note.

Sigh. Did you read the thread? W. Ballard wrote:

 The exim4 config asks you if you want itty bitty or one monolothic
 config file. It offers you the option of doing it the upstream way.

And J. Hassler asked:

 Does it tell you which is the upstream way?  Most new users won't know.

At which point Tollef quoted the debconf question, and the answer is
no, it doesn't.

And yes, it does belong there. It could easily add the something like:

   The single monolithic file is the normal upstream configuration,
   while the other choice is a Debian innovation that works better with
   large installations or ISPs needing to support many virtual domains.

For newbies, this is the first MTA installation they will have ever
seen. Help 'em out, for Pete's sake.

Steve


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

How to force an update if package names changed?

2005-02-18 Thread Hendrik Frenzel

Hi,

i got a question regarding package updates.

If I have a source pack-1.1 from which some packages including
pack-gui-lang-de-1.1_2 (Provides: pack-gui-lang) are build.

Now i want to build the languages in seperade packages say
pack-lang-de-1.1. How can it be done to force an update between the
package from the main source (pack-gui-lang-de-1.1_2) to the package
from the seperated lang source (pack-lang-de-1.1_?)?

Provides: pack-gui-lang-de, pack-gui-lang
Conflicts: pack-gui-lang-de

doesn't seem to work, since the old pack-gui-lang-de packages are still
installed.

Any hints?

Thanks in advice
Hendrik

-- 
I am chaos.
I am the substance from which your artists and scientists build rhythms.
I am the spirit with which your children an clowns laugh in happy anarchy.
I am chaoss. I am alive and tell you, that you are free.
   - Eris, Goddess of Chaos, Discord and Confusion


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread Mike Hommey

On Fri, Feb 18, 2005 at 02:15:16PM -0600, Steve Greenland [EMAIL PROTECTED] 
wrote:
(...)
 And yes, it does belong there. It could easily add the something like:
 
The single monolithic file is the normal upstream configuration,
while the other choice is a Debian innovation that works better with
large installations or ISPs needing to support many virtual domains.
 
 For newbies, this is the first MTA installation they will have ever
 seen. Help 'em out, for Pete's sake.

Do newbies understand the concept of upstream ?

Mike


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

Re: The ghost of libc-dev

2005-02-18 Thread Joel Aelwyn

On Fri, Feb 18, 2005 at 06:50:50PM +0100, Kurt Roeckx wrote:
 On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote:
  
  *) The standard way of doing this today is to have a -dev package which
  needs libc headers Depend on 'libc6-dev | libc-dev' to avoid the situation
  of having only a pure-virtual package.
 
 Why does that rule exists anyway?  It's already part of
 build-essential.  And build-essential is already defined for each
 arch.

The reason given in the origional thread was that these Depends are not
solely for building Debian packages (when Build-Essential is reasonable to
expect), but for I need to compile $userspace package, which does *not*
require B-E be installed, according to current policy.

The tool would also automatically pick up other build-dependancies based on
headers, not just libc*-dev, if your package's header files include those
of another package.

  *) On further reflection, and re-reading other parts of the thread, I think
  it might be more useful to try to implement the following, and I would like
  feedback on whether this needs adjustment, or people think it would be a
  good idea. If it works, I can publish it as it's own tool, or try to get it
  included in the debhelper package (the latter probably being prefferable).
  
  dh_devincludes
 
 I was also thinking about something like that some time ago.  I'm
 just afraid it's not going to be very easy to get correct.

Perhaps not, but that's why I brought up the topic - taking a first stab is
a good start at figuring out what else needs to be done.

  Searches the target package for *.h files, then searches each file found
  for #include lines. Attempts to resolve each include, checking first the
  package area, then the system library area. If the file is found in the
  package, it is ignored; if not found at all, it throws a warning. However,
  if the package is found in the system area, it checks the installed files
  information and extracts the name of the package which provides that file.
  The list of packages found is places into the substvar dev:Depends.
 
 I was thinking about libtool .la files and pkgconfig .pc files
 and looking at the libraries they require.  (In case they are
 using it.)

Hmmm. Possibly useful, that, yes; are there any other tools to provide
hints on what so-lib or headers coming from a -dev could be required? The
one concern I would have (since I'm not yet familiar with the innards of
.la or .pc files) is that a library could linked against, say, libfoo3,
but that doesn't mean you need libfoo{,3}-dev installed, only libfoo3
(the versioned .so is sufficient to deal with linking requirements, as I
understand it). Only if you use header files from libfoo would you need the
libfoo-dev (a package which links to you, and to libfoo3, would declare
it's own Build-Depends on libfoo3-dev).

Er. That may be a little unclear. So, let me try with a more concrete
example:

* libc, so major 8, with standard libc headers.

* libfoo, so major 3, linked against libc, with headers that include
  stdio.h from libc.

* libbar, so major 7, linked against libc and libfoo, with headers that
  include stderr.h from libc and footypes.h from libfoo.

* libbaz, so major 2, linked against libfoo and libbar, but does not
  provide any header files which link against libc or libfoo, only
  libbar. (Okay, so not linking directly to libc is unlikely in the real
  world, but it could happen in some cases).

libc Build-Depends on nothing, libc8-dev Depends on libc8 (usually exact
versioning).

libfoo does not Build-Depend on libc{8,}-dev, because it is provided by
Build-Essential (when building a Debian package). However, libfoo3-dev
Depends on libc8-dev, once built, because it references the headers (and,
as usual, on libfoo3). The libfoo3 package may have a versioned Depends on
libc8, as well, if that isn't somehow guaranteed already.

libbar Build-Depends on libfoo3-dev (needing headers and .so link), but not
libc8-dev (Build-Essential), and libbar7 Depends on libfoo3, as well as
probably having a versioned dependancy on libc8, while libbar7-dev Depends
on libc8-dev and libfoo3-dev, as well as libbar7.

libbaz Build-Depends on libfoo3-dev and libbar7-dev, and would not need
to Build-Depend on libc8-dev even if it were not Build-Essential. The
libbaz2 package Depends on libfoo3 and libbar7, but not (directly) on
libc8. libbaz2-dev Depends only on libbar7-dev and libbaz2; because there
is no header include dependancy on any libfoo header, and the shared
library already has the linking requirements for libfoo3 within the
library's NEEDED section (and it's guaranteed to be installed because of
the dependancy chain libbaz2-dev - libbaz2 - libfoo3), there is no need
to Depend on libfoo3-dev, since we need neither headers nor the .so link
from it.

  * Does it need some way (a la shlibs) to resolve problems with what
  version of the -dev package is needed for this, or is this likely to be
  uncommon enough to expect

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread Ron Johnson

On Fri, 2005-02-18 at 21:37 +0100, Mike Hommey wrote:
 On Fri, Feb 18, 2005 at 02:15:16PM -0600, Steve Greenland [EMAIL PROTECTED] 
 wrote:
 (...)
  And yes, it does belong there. It could easily add the something like:
  
 The single monolithic file is the normal upstream configuration,
 while the other choice is a Debian innovation that works better with
 large installations or ISPs needing to support many virtual domains.
  
  For newbies, this is the first MTA installation they will have ever
  seen. Help 'em out, for Pete's sake.
 
 Do newbies understand the concept of upstream ?

Yes.  Or vaguely.

Depends on the level of newbieness.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

Don't tell me peace has broken out.
Bertolt Brecht


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread Florian Weimer

* Steve Greenland:

 And yes, it does belong there. It could easily add the something like:

The single monolithic file is the normal upstream configuration,
while the other choice is a Debian innovation that works better with
large installations or ISPs needing to support many virtual domains.

But this isn't completely correct.  Even the single-file configuration
differs conceptually from upstream because some of the options are
managed through Debconf.  Some people still complain that this isn't
the upstream way.


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread Jeroen van Wolffelaar

On Fri, Feb 18, 2005 at 02:15:16PM -0600, Steve Greenland wrote:
 And J. Hassler asked:
  Does it tell you which is the upstream way?  Most new users won't know.
 
 At which point Tollef quoted the debconf question, and the answer is
 no, it doesn't.
 
 And yes, it does belong there.

I think a lot, if not most, Debian users do not care at all how upstream
does there stuff. So exim upstream puts the debian config in /usr/exim
by default, apache calls their binaries and config files httpd, and
upstream's cron doesn't have the concept of cron.d.

I'm running Debian, not LFS, gentoo or any other collection of upstream
sources without much changes. Debian uses external sources (upstream),
and changes it to behave like a Debian package. There's nothing wrong
documenting the changes in README.Debian or similar, but I don't think
that it should be required, and indeed, only cron of the three examples
I listed note this change in their documentation, for those really
interested, Debian distributes the diffs against upstream sources.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber  MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

On Thu, 2005-02-17 at 14:24 -0800, Blunt Jackson wrote:
 On Thu, 17 Feb 2005 19:31:20 +, Henning Makholm [EMAIL PROTECTED] wrote:
  Scripsit Blunt Jackson [EMAIL PROTECTED]
  
   As a general note, I find it annoying, frustrating, and confusing
   whenever ANY debian package has a substantially different
   installation or configuratin mechanism than the mechanism documented
   by the software publisher.
  
  Perhaps Debian is not the distribution for you, then.  We have always
  prioritized constistency across the entire Debian OS over adherence to
  what upstream authors somehow chose to do.
 
 Obviously there's a balance. I wasn't looking for flames. I believe I
 did explain *why* debian was my distribution of choice even so.
 
  I maintain one package whose upstream author apparently thought that
  $PATH would be a good place to look for a system-wide configuration
  file. I changed that to look in /etc instead, which makes the
  configuration mechanism in Debian substantially different from
  upstream's. You may find this annoying, frustrating and confusing, but
  it's how Debian operates.
 
 And clearly, *this* is a scenario in which the upstream author was way
 outside the *unix* standard way of doing things. I'm not saying
 there's any clear-cut answer, other than to hope that both upstream
 developers and debian package maintainers use common sense.
 
 One distinction is in applications that the majority of users just
 want to work out of the box, and forget about. If I had to tweak the
 configuration of every application on my servers, I would be a
 frothing maniac. But there are some biggies, some very well known
 applications, that, when installed for any practical purpose,
 generally require somewhat sophisticated user oversight. Exim is one,
 Apache is another. Mysql is a third. I put in the time to figure out
 the debian way of doing Exim (and I'm still not sure I understand it,
 but at for now I have it working). There was a substantial amount of
 hair pulling and cursing due to the disparity between what I saw on my
 hard drive and what I saw in the online documentation.

Okay, then generate the old fashionedHuge config file with
--keepcomments and If you don't remove the banners for each file you
will know which on the baddy.

Also, if you need to re-order the routers (the only one out side of
routers that need ordering is acl) then it is easy to do by simply
changing the number/letters at the beginning of the files name.

I DO NOT see what is so different from /etc/exim4/exim4.conf as compared
to /var/lib/exim4/config.autogenerated, especially if you use
--keepcomments. there really *IS* no difference. The pieces are just
packaged in small manageable ones to aid in the updating of.

Docs especially are like that Phil Hazel doesn't update them every time
he bumps the release. Marc Haber and Andreas Metzler are doing a great
job with exim.

  After that
 experience, when I installed apache and mysql, and saw they were doing
 their own thing as well, I decided I didn't want to learn go through
 the same frustration with applications I already knew pretty well. I
 removed the debian packages, and compiled my own from the upstream
 developers. Note that removing the debian packages did not remove all
 their config files and so forth, there was a fair bit of manual
 cleanup afterwards -- but I'm not using the stable distribution, so I
 don't expect perfection.
 
 As for you, Florian's snide comment:
 
  Just because the configuration file is called /etc/exim4/exim4.conf
  instead of /usr/exim/configure?  Oh dear.
 
 No, it was the stuff like this that made me pull out my hair:
 
 domainlist local_domains = DEBCONFlocal_domainsDEBCONF
 
 How do I figure out where that DEBCONF stuff is coming from? What it means?

When you use update-exim4.conf --keepsettings the generated fully
populated  is available at /var/lib/exim4/config.autogenerated.

Also, any debconf setting are in the file:

update-exim4.conf.conf

things like DEBCONFlocal_domainDEBCONF is changed to the setting(s) in
that file. Also, one other thing, look at the main directory in the
config... it has about 3 files in it. Those three files are the
important ones that define default actions for exim to take. Many of
those are also can be managed by debconf as well.

 Of course, it didn't help that during the install I didn't quite know
 what I was doing, so based on the advice of the install program I
 chose the big-file-install, which *was* what I wanted, but I forgot
 that I had done that, so when I went to look at the exim config and
 found, as the exim website told me I would find (because I was on
 debian), a gazillion little bitty config files, I got started figuring
 them out, editing them, and not realizing why it made no difference.
 Suggestion to exim package people: if someone chooses the big config
 file, don't even install the little ones.

Why does it matter if they were installed or not? They weren't being

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

On Fri, 2005-02-18 at 06:54 +0100, Marc Haber wrote:
 On Fri, 18 Feb 2005 10:01:45 +1100, Brian May [EMAIL PROTECTED] wrote:
 If something like this is different, then not only should Debian
 supplied documentation reflect the change, but a list of differences
 should appear in README.Debian.
 
 One thing I have learned in the last 24 hours is that people do not
 bother to read available documentation, regardless of where it is
 stored. You have to hurl it right into the user's face.
 
 I begin to understand the blurb of rants that cdrecord prints on
 invocation.

Indeedly-do.

Many people cannot find it then. Some people just WANT THE ANSWER, don;t
wanna learn anything to mayhaps fix it easy in the future.
-- 
greg, [EMAIL PROTECTED]

The technology that is
Stronger, better, faster:  Linux


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

On Thu, 2005-02-17 at 20:08 +0100, Marc Haber wrote:
 On Thu, 17 Feb 2005 12:16:24 -0500, Greg Folkert
 [EMAIL PROTECTED] wrote:
 Except I'd rather see --keepcomments as
 default and changed to --removecomments. My only gripe, pretty minimal.
 
 And fixed soon. #295735.

Wow, I didn't even consider it a problem. I just edited the scripts to
do it by default.. :)

Now I don't have to.

Thanks Marc.
-- 
greg, [EMAIL PROTECTED]

The technology that is
Stronger, better, faster:  Linux


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

Re: pwc-source headed for unstable this weekend

Scripsit Eric Lavarde [EMAIL PROTECTED]

 So, basically, your saying that the right way to do this kind of
 things is to use the corresponding kernel-headers package, and apt-get
 tells me that I need as well kernel-kbuild to build out-of-tree
 kernel modules which seems to be exactly what I need.

That's what I infer from my own experience. But the kbuild stuff in
2.6 is kinda hairy, and I did not attempt to trace the exact
conditions after I found a way to do thing that seems to work
consistently for me.

This may even be documented somewhere, although it did not jump out
and bite my nose when I tried to find out what went wrong.


Given the tendency of people like me to just repeat the procedures
that worked for 2.4, it might be a good idea for make-kpkg to check
whether the necessary files are present in the kernel tree (and warn
loudly if they are not) when one tries to build modules. On the other
hand I have no idea what would be involved in checking this, so it
might be probitively difficult.

-- 
Henning Makholm   Luk munden og se begavet ud!


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

Re: The ghost of libc-dev

Scripsit Joel Aelwyn [EMAIL PROTECTED]

 The reason given in the origional thread was that these Depends are not
 solely for building Debian packages (when Build-Essential is reasonable to
 expect), but for I need to compile $userspace package, which does *not*
 require B-E be installed, according to current policy.

But can one get a C compiler at all (at least a Debian-supplied one)
without also pulling in an appropriate libc-dev? I would think
that I need to compile $userspace package *did* require at least a
compiler to be installed, regardless of policy.

Libc6-dev does *recommend* c-compiler, but that does not help with
I need to compile $userspace package if $userspace package does not
happen to require any third-party libraries.

-- 
Henning MakholmMy fate? Servitude to the Embodiment of Whoops.


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

Re: pwc-source headed for unstable this weekend

On Fri, 2005-02-18 at 20:35 +0100, Eric Lavarde wrote:
 Hi,
 
 (I assume everybody is on -devel, like I am, and as it seems the problem 
 sits between keyboard and chair, no bug report either).
 
 This might very well be, as I didn't compile the kernel myself (I just 
 use the standard kernel-image-2.6.10-1-k7 package) but used 
 kernel-source-2.6.10 with the .config from the image package, make 
 oldconfig and make dep (which I was told is deprecated, so).
That is exactly what the package kernel-headers-2.6.10-1-k7 is for, it
depends on kernel-headers-2.6.10-1 and creates the symlink proper for
thrid party and external modules to use.

 
 So, basically, your saying that the right way to do this kind of things 
 is to use the corresponding kernel-headers package, and apt-get tells me 
 that I need as well kernel-kbuild to build out-of-tree kernel modules 
 which seems to be exactly what I need.

Yes, he is correct.
-- 
greg, [EMAIL PROTECTED]

The technology that is
Stronger, better, faster:  Linux


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

Le vendredi 18 février 2005 à 14:15 -0600, Steve Greenland a écrit :
On 18-Feb-05, 09:06 (CST), Josselin Mouette [EMAIL PROTECTED] wrote:
Le vendredi 18 f??vrier 2005 ?? 08:37 -0600, Steve Greenland a ??crit :
No where in the Debconf note does it say which is the upstream way.

This has nothing to do in a debconf note.

Sigh. Did you read the thread? W. Ballard wrote:

The exim4 config asks you if you want itty bitty or one monolothic
config file. It offers you the option of doing it the upstream way.

How is it relevant?

And yes, it does belong there. It could easily add the something like:

The single monolithic file is the normal upstream configuration,
while the other choice is a Debian innovation that works better with
large installations or ISPs needing to support many virtual domains.

For newbies, this is the first MTA installation they will have ever
seen. Help 'em out, for Pete's sake.

Such a question will never help them. Why the hell would a newbie care
of a package diverging from upstream (if he understands what an upstream
is)? The newbie wants a working installation, full stop. That's why this
question isn't high priority: it isn't even shown to the newbie.

And the fact exim4 diverges from upstream has *absolutely nothing* to do
in a debconf note. Debconf is here to promt users, not to document
changes. We have README.Debian and changelog.Debian for that.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom

signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: The ghost of libc-dev

2005-02-18 Thread Joel Aelwyn

On Fri, Feb 18, 2005 at 09:17:55PM +, Henning Makholm wrote:
 Scripsit Joel Aelwyn [EMAIL PROTECTED]
 
  The reason given in the origional thread was that these Depends are not
  solely for building Debian packages (when Build-Essential is reasonable to
  expect), but for I need to compile $userspace package, which does *not*
  require B-E be installed, according to current policy.
 
 But can one get a C compiler at all (at least a Debian-supplied one)
 without also pulling in an appropriate libc-dev? I would think
 that I need to compile $userspace package *did* require at least a
 compiler to be installed, regardless of policy.
 
 Libc6-dev does *recommend* c-compiler, but that does not help with
 I need to compile $userspace package if $userspace package does not
 happen to require any third-party libraries.

I guess that depends on whether one wants to rely on every package which
Provides c-compiler to also Depend on the correct libc*-dev package for
the relevant platform(s). If so, however, then it needs to become strictly
not-OK to Depend on libc*-dev unless you're doing a versioned Dependancy,
in which case you'll have to version every one of the various libc*-dev
packages correctly (since you can't rely on the Provides libc6-dev of
glibc packages to work in the presence of a versioned dependancy, and of
course the non-glibc ports don't even consider adding that header, as it
would be utterly bogus - they can't even pretend to be the same thing, only
equivalent, which is libc-dev).

Really, I think the simplest answer is a tool that detects *all* of the
relevant -dev packages, in a simple and automated fashion, for the exact
same reasons we don't expect people to try to hand-version and hand-impart
every shared library dependancy their package has, but instead provide
dpkg-shlibdeps and dh_shlibdeps.
-- 
Joel Aelwyn [EMAIL PROTECTED]   ,''`.
 : :' :
 `. `'
   `-


signature.asc
Description: Digital signature

Re: The ghost of libc-dev

Scripsit Joel Aelwyn [EMAIL PROTECTED]
 On Fri, Feb 18, 2005 at 09:17:55PM +, Henning Makholm wrote:

 But can one get a C compiler at all (at least a Debian-supplied one)
 without also pulling in an appropriate libc-dev? I would think
 that I need to compile $userspace package *did* require at least a
 compiler to be installed, regardless of policy.

 I guess that depends on whether one wants to rely on every package which
 Provides c-compiler to also Depend on the correct libc*-dev package for
 the relevant platform(s).

I don't think there can be much argument that anything that Provides
c-compiler also has to make sure that standard header files like
stdio.h or unistd.h are present on the system. Otherwise it
wouln't be able to do its job, namely compiling C programs.

I have no a priori opinion about whether such making sure should
involve virtual packages, and if so which.

However, a -dev packages that contains C(++) headers is obviously only
useful if one already has a C compiler, so there should be no need to
depend directly on a libc-dev. One might argue that any -dev package
that provides a C interface should depend on c-compiler themselves,
but our traditional answer to that one seems to be, don't be silly;
a user should be able to figure out *that* by himself.

 Really, I think the simplest answer is a tool that detects *all* of the
 relevant -dev packages, in a simple and automated fashion,

I agree with this - it would need some compile-time parallel to shlibs
files in order to discover which possibly virtual package is the right
one to depend on to get /usr/include/foo.h.

However, for as long as we have to trace the dependencies by hand, I
see little benefit in requiring an explicit dependency on a libc-dev.

-- 
Henning Makholm  En tapper tinsoldat. En dame i
 spagat. Du er en lykkelig mand ...


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

Re: First line in /etc/hosts

2005-02-18 Thread Junichi Uekawa


Hi

   Machines don't have IP numbers.  Interfaces have IP numbers.  Every 
   machine
  
  Actually, that's not quite the case (as a number of users of Linux's ARP
  implementation have found), though it's a good approximation.
 
 Indeed. For Linux, nodes have IP *numbers* which are all equal, and you have
 to take great pains to make sure it behaves in any different way.  iproute2,
 arptables and the relative black magic of arp_filter are your only ways to
 try to influence that.  Usual route, ifconfig, etc are useless.

This portion is unclear to me; could you shed some light ?

Do you mean:

1. on linux there is a principal IP address that is assigned to a 
   node regardless of NIC due to the implementation of ARP etc.

2. on linux there is some magic IP *number* that is assigned to a 
   node; and IP addresses are assigned to individual NICs.
  - if so, what is a IP number?


regards,
junichi


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread Steve Greenland

On 18-Feb-05, 17:45 (CST), Josselin Mouette [EMAIL PROTECTED] wrote: 
 Such a question will never help them. Why the hell would a newbie care
 of a package diverging from upstream (if he understands what an upstream
 is)?

Jesus H. Christ. Read the original post to this thread. It was a
complaint about how the upstream docs were not consistent with the
debian config.

 And the fact exim4 diverges from upstream has *absolutely nothing* to do
 in a debconf note. Debconf is here to promt users, not to document
 changes.

But how would it hurt to say that choice A is more standard?

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: First line in /etc/hosts

2005-02-18 Thread Blars Blarson

In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
   Machines don't have IP numbers.  Interfaces have IP numbers.  Every 
   machine
  
  Actually, that's not quite the case (as a number of users of Linux's ARP
  implementation have found), though it's a good approximation.

This portion is unclear to me; could you shed some light ?

Do you mean:

[wrong guesses omitted]

A machine may use the same IP on multiple interfaces.
A machine may use multiple IP addresses on a single interface.
The two may be combined.

A router may use proxy arp.

A machine may use the same ethernet address on multiple interfaces on
different physical networks.  This tends not to work well with vlans.
(switches pretending to be multiple networks)

-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

Steve Greenland [EMAIL PROTECTED] writes:

 Jesus H. Christ. Read the original post to this thread. It was a
 complaint about how the upstream docs were not consistent with the
 debian config.

Huh?  The original post AFAICT of this thread consisted of Marc Haber
complaining that it was inappropriate for Ian Jackson to complain
about Debian's packaging on the exim-users upstream mailing list.

Ian Jackson's complaint in that thread had nothing to do with
documentation, AFAICT.

Marc Haber also referenced a bug, number #295391, reported by Ian
Jackson which appears to have started this, and in this bug, Ian is
complaining that when you ask for the one-file configuration, you
still see the tools for the many-file configuration installed.  Ian
misunderstood what the exim package was doing; requesting the
single-file method does in fact get you the single-file method; he
incorrectly thought that this meant that /etc/exim4 shouldn't have
the other files in it at all.

He also reported a separate bug in the same bug report.  Most of the
discussion in the bug log consists of Ian insisting that the way to
fix the bug he was seeing was to throw out whatever Debian was doing.
He also deleted exim from his machine and switch to smail, so it
became impossible to track down whatever the second bug was, as it
does not occur for the developer.

It reads rather like Ian throwing a tantrum, complaining that his
proposed solution (this abomination should be thrown away and
rewritten) wasn't being taken seriously, and refusing to help find a
fix to the bug.

And then, taking his fight to the exim-users mailing list too.

Still, one piece of useful advice has come from the thread: that the
installation comment should tell the user what to do, rather than what
not to do.

Thomas


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

Steve Greenland [EMAIL PROTECTED] writes:

  And the fact exim4 diverges from upstream has *absolutely nothing* to do
  in a debconf note. Debconf is here to promt users, not to document
  changes.
 
 But how would it hurt to say that choice A is more standard?

What is more standard?  I think everyone agrees (am I wrong?) that
the question should say: if you don't know which to pick, then pick
the single-file method.



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

Re: First line in /etc/hosts

2005-02-18 Thread Henrique de Moraes Holschuh

On Fri, 18 Feb 2005, Blars Blarson wrote:
 In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
Machines don't have IP numbers.  Interfaces have IP numbers.  Every 
machine
   
   Actually, that's not quite the case (as a number of users of Linux's ARP
   implementation have found), though it's a good approximation.
 
 This portion is unclear to me; could you shed some light ?
 
 Do you mean:
 
 [wrong guesses omitted]
 
 A machine may use the same IP on multiple interfaces.
 A machine may use multiple IP addresses on a single interface.
 The two may be combined.
 
 A router may use proxy arp.
 
 A machine may use the same ethernet address on multiple interfaces on
 different physical networks.  This tends not to work well with vlans.
 (switches pretending to be multiple networks)

Also: As far as the kernel is concerned, any local IP is local to *all*
interfaces, and it will happly reply to it (ARP and so on) if allowed to.
The rp_filter will often avoid trouble here, BUT routers often have to
disable rp_filter.  So add some rules to the firewall make sure nothing gets
into 127.0.0.0/8 unless it is a local packet.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread William Ballard

On Sat, Feb 19, 2005 at 03:02:00AM +0100, Josselin Mouette wrote:
 Furthermore, how does a thing being standard help the user in his
 choice? The user only thinks of his own needs, thus a correct wording
 would be pick A if you don't care. However the current wording is even
 better; the question isn't even asked at high priority, and the single
 file method is silently chosen.

Is the multiple-file configuration logically equivalent to the 
single-file configuration?  If you #include'd all the tiny subfiles, 
would the resulting config be identical to the single-file config?

If so, then what are we really arguing about: they are isomorphic.  
Perhaps a tool could generate the single-file config for easier 
double-checking of the split-file config.

If not, then the user needs to know what will behave differently.


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread Stephen Gran

This one time, at band camp, William Ballard said:
 On Sat, Feb 19, 2005 at 03:02:00AM +0100, Josselin Mouette wrote:
  Furthermore, how does a thing being standard help the user in his
  choice? The user only thinks of his own needs, thus a correct
  wording would be pick A if you don't care. However the current
  wording is even better; the question isn't even asked at high
  priority, and the single file method is silently chosen.
 
 Is the multiple-file configuration logically equivalent to the
 single-file configuration?  If you #include'd all the tiny subfiles,
 would the resulting config be identical to the single-file config?
 
 If so, then what are we really arguing about: they are isomorphic.
 Perhaps a tool could generate the single-file config for easier
 double-checking of the split-file config.
 
 If not, then the user needs to know what will behave differently.

The only difference, AFAICT, is that when you pick the split file
option, the split files are concattenated together on /etc/init.d/exim4
{stop,restart,reload} (this is really handled by update-exim4.conf, but
that is irrelevant to the user perspective, IMHO).  They produce the
same initial configuration in any case.  The only difference from a user
experience is knowing that split files vs. monolithic is really related
to what to edit, rather than where configuration is read at runtime.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


pgpfuCekcqtDV.pgp
Description: PGP signature

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread William Ballard

On Fri, Feb 18, 2005 at 09:36:54PM -0500, Stephen Gran wrote:
 that is irrelevant to the user perspective, IMHO).  They produce the
 same initial configuration in any case.  The only difference from a user

Good lord, what are we arguing about then :-)
Do people who edit their exim config (I never do on my desktop)
really have a hard time grasping #include files?


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

William Ballard [EMAIL PROTECTED] writes:

 Good lord, what are we arguing about then :-)
 Do people who edit their exim config (I never do on my desktop)
 really have a hard time grasping #include files?

You've missed the point of the many-small-files config.  As a happy
user, let me explain what it's about.

The point is that I want to massage some parts of the configuration
and not others.  I want the others to continue to get updated by the
normal package installation process.

If I use the one-big-file method, I can't really do this.  I would
modify parts of the file, but then I can either install the new file
or not when the package updates it.  It's a PITA, to merge every time
a small change is made in some other part of such a large config file.

So the many-small-files is perfect for a site like mine.  Many changes
aren't even changes that get noticed by dpkg, because they involve
making new files to specify new router rules, for example.  They just
get automatically put into the generated config file.  And by
contrast, when nearly any change is made by the Debian package, it
just automatically goes into the new version without the need for me
to hand-edit the changes.

Really big sites will have their own config files anyway, so nothing
done by Debian matters much to them.  Small and ordinary sites may be
happy with the default big file, because they never need to modify it
anyway.  But middling sites, or sites like mine with small variations
on the normal model (in my case, I have a second domain that I MX for
through a special alias file) find the many-small-files just perfect.

Thomas


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread Stephen Gran

This one time, at band camp, Thomas Bushnell BSG said:
 The point is that I want to massage some parts of the configuration
 and not others.  I want the others to continue to get updated by the
 normal package installation process.
 
 If I use the one-big-file method, I can't really do this.  I would
 modify parts of the file, but then I can either install the new file
 or not when the package updates it.  It's a PITA, to merge every time
 a small change is made in some other part of such a large config file.

I wanted to mention that I completely agree with this sentiment.  We run a
couple of mail clusters, and we manage many single mail servers.  Thanks
to the split file approach, we can ship a couple of custom config files
that allows us to tweak everything we need with a few macros and ifdef's.
We still get the nice package management and improvement of routers and
transports and all the rest of it.

My only point in the previous mail is that there really is no difference
in what is happening at run time - the only thing the end user has to
know is that they when they pick one setting, they make edits here, and
if they choose the other, they make edits there.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


pgpIXM7SWdz48.pgp
Description: PGP signature

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

2005-02-18 Thread William Ballard

On Fri, Feb 18, 2005 at 07:27:27PM -0800, Thomas Bushnell BSG wrote:
 William Ballard [EMAIL PROTECTED] writes:
 
  Good lord, what are we arguing about then :-)
  Do people who edit their exim config (I never do on my desktop)
  really have a hard time grasping #include files?
 
 You've missed the point of the many-small-files config.  As a happy
 user, let me explain what it's about.

I use them too.  I never my exim config at all, so I read the debconf 
note and chose the many small files option.  I think you misunderstood 
my post.  I said something like who would be confused by what is in 
essence #include files?

Please spare me your moralizing when you don't even read my post very 
closely and I was already in favor of the current way Debian handles it.

Sheesh.


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

William Ballard [EMAIL PROTECTED] writes:

 Please spare me your moralizing when you don't even read my post very 
 closely and I was already in favor of the current way Debian handles it.

I wasn't moralizing; I'm sorry if I misunderstood your note.  Many
people here have failed to understand the point of the
many-small-files option, so I figured that a more complete explanation
would be independently useful.

I misunderstood you to be saying that since the two methods (when you
make no modifications) produce the same results, those of us who like
the many-small-files version should just use includes instead.  But I
see now that you weren't saying that.

Thomas


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

Bug#295927: ITP: drift -- type sensitive preprocessor for Haskell

2005-02-18 Thread Arjan Oosting

Package: wnpp
Severity: wishlist
Owner: Arjan Oosting [EMAIL PROTECTED]

* Package name: drift
  Version : 2.1.0
  Upstream Author : John Meacham [EMAIL PROTECTED]
* URL : http://repetae.net/john/computer/haskell/DrIFT/
* License : MIT
  Description : type sensitive preprocessor for Haskell

 DrIFT automates instance derivation for classes that aren't supported
 by the standard compilers. In addition, instances can be produced in
 separate modules to that containing the type declaration. This allows
 instances to be derived for a type after the original module has been
 compiled. As a bonus, simple utility functions can also be produced
 from a type.
 .
 Features:
   - DrIFT comes with a set of rules to produce instances for all
 derivable classes given in the Hasekell Prelude. There are also a
 number of extra useful rules to derive instances of a variety of
 useful classes.
   - DrIFT performs import chasing to find the definition of a type.
   - Code is generated using pretty-printing combinators. This means
 that the output is (fairly) well formatted, and easy on the eye.
   - Effort has been made to make the rule interface as easy to use as
 possible. This is to allow users to add rules to generate code
 specific to their own projects. As the rules are themselves
 written in Haskell, the user doesn't have to learn a new language
 to express rules.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (102, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-2-stardust
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

Scripsit Thomas Bushnell BSG [EMAIL PROTECTED]

 The point is that I want to massage some parts of the configuration
 and not others.  I want the others to continue to get updated by the
 normal package installation process.

So is the whole thing essentially a workaround for dpkg's current
lack of good conffile update management, or would you still prefer the
separate files way if dpkg magically gained a well-tested and stable
conflict resolution scheme with bells, whistles, and 3-way merges?

-- 
Henning Makholm  Gå ud i solen eller regnen, smil, køb en ny trøje,
   slå en sludder af med købmanden, puds dine støvler. Lev!

Re: The Debian exim 4 packages suck badly on exim-users@exim.org

Henning Makholm [EMAIL PROTECTED] writes:

 Scripsit Thomas Bushnell BSG [EMAIL PROTECTED]
 
  The point is that I want to massage some parts of the configuration
  and not others.  I want the others to continue to get updated by the
  normal package installation process.
 
 So is the whole thing essentially a workaround for dpkg's current
 lack of good conffile update management, or would you still prefer the
 separate files way if dpkg magically gained a well-tested and stable
 conflict resolution scheme with bells, whistles, and 3-way merges?

Um, no, I don't think I said that.  When I say, this is an important
thing that X provides, you cannot go and assume that I mean this is
the only reason to like X.

Thomas


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

Accepted getmail4 4.3.2-1 (all source)

2005-02-18 Thread Fredrik Steen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 08:28:01 +0100
Source: getmail4
Binary: getmail4
Architecture: source all
Version: 4.3.2-1
Distribution: unstable
Urgency: low
Maintainer: Fredrik Steen [EMAIL PROTECTED]
Changed-By: Fredrik Steen [EMAIL PROTECTED]
Description: 
 getmail4   - mail retriever with support for POP3, IMAP4 and SDPS
Changes: 
 getmail4 (4.3.2-1) unstable; urgency=low
 .
   * New upstream release
Files: 
 52b0526a8ec8a1fb85348faa7e8e075d 588 mail optional getmail4_4.3.2-1.dsc
 be863c1772bfd734ec118fb1e3d48780 131784 mail optional 
getmail4_4.3.2.orig.tar.gz
 a57681fe9c623cb87198a3d4e45971ab 2910 mail optional getmail4_4.3.2-1.diff.gz
 e16c573ffc91f594184d9bbd68e5ec9a 140580 mail optional getmail4_4.3.2-1_all.deb

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

iD8DBQFCFZvP2pHue6WOFk8RApQMAKCWuz07TGt12HXxTfLmZAnFSQHHtQCgl6+p
IDgwXlPM16OHL6HH0M5+y1c=
=ulvo
-END PGP SIGNATURE-


Accepted:
getmail4_4.3.2-1.diff.gz
  to pool/main/g/getmail4/getmail4_4.3.2-1.diff.gz
getmail4_4.3.2-1.dsc
  to pool/main/g/getmail4/getmail4_4.3.2-1.dsc
getmail4_4.3.2-1_all.deb
  to pool/main/g/getmail4/getmail4_4.3.2-1_all.deb
getmail4_4.3.2.orig.tar.gz
  to pool/main/g/getmail4/getmail4_4.3.2.orig.tar.gz


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

Accepted br.ispell 2.4.really.3.0.beta4-8 (i386 source all)

2005-02-18 Thread Rafael Laboissiere

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 22 Jan 2005 15:29:27 +0100
Source: br.ispell
Binary: ibrazilian myspell-pt-br brazilian-conjugate aspell-pt-br
Architecture: source all i386
Version: 2.4.really.3.0.beta4-8
Distribution: unstable
Urgency: low
Maintainer: Rafael Laboissiere [EMAIL PROTECTED]
Changed-By: Rafael Laboissiere [EMAIL PROTECTED]
Description: 
 aspell-pt-br - Brazilian Portuguese dictionary for GNU Aspell
 brazilian-conjugate - Brazilian Portuguese verb conjugator
 ibrazilian - Brazilian Portuguese dictionary for ispell
 myspell-pt-br - The Brazilian Portuguese dictionary for myspell
Changes: 
 br.ispell (2.4.really.3.0.beta4-8) unstable; urgency=low
 .
   * Built against aspell 0.60.2.
   * debian/control:
 - Changed the build-depends to aspell-bin ( 0.60).
 - Changed the aspell-pt-br provides from aspell-dictionary to
   aspell6-dictionary.
 - Removed the word The at the beginning of the short descriptions,
   as per Section 6.2.2 of the Debian Developer's Reference.
Files: 
 810b95b0a2315377f5c3ad4962569421 664 text optional 
br.ispell_2.4.really.3.0.beta4-8.dsc
 6f384d3b121e012e0f386f5cbc5cca12 247527 text optional 
br.ispell_2.4.really.3.0.beta4-8.tar.gz
 4598dc9caf8b9742558bf3e95bfc7607 63848 text extra 
brazilian-conjugate_2.4.really.3.0.beta4-8_all.deb
 6456974dab5a1ebdec594bad41c2b983 158140 text optional 
myspell-pt-br_2.4.really.3.0.beta4-8_all.deb
 5d71639ab8859d8fb6f03986463f169d 361886 text optional 
ibrazilian_2.4.really.3.0.beta4-8_i386.deb
 86c86b20b815eb4cc358c09f77eb1005 1886008 text optional 
aspell-pt-br_2.4.really.3.0.beta4-8_i386.deb

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

iD8DBQFCDbtPk3oga0pdcv4RAiF5AJ0WNxke1YdVLoH2v28XtE7ViMA5bACglXAl
pk3X/j1dmpNqMyGY7dpTqO0=
=SDgZ
-END PGP SIGNATURE-


Accepted:
aspell-pt-br_2.4.really.3.0.beta4-8_i386.deb
  to pool/main/b/br.ispell/aspell-pt-br_2.4.really.3.0.beta4-8_i386.deb
br.ispell_2.4.really.3.0.beta4-8.dsc
  to pool/main/b/br.ispell/br.ispell_2.4.really.3.0.beta4-8.dsc
br.ispell_2.4.really.3.0.beta4-8.tar.gz
  to pool/main/b/br.ispell/br.ispell_2.4.really.3.0.beta4-8.tar.gz
brazilian-conjugate_2.4.really.3.0.beta4-8_all.deb
  to pool/main/b/br.ispell/brazilian-conjugate_2.4.really.3.0.beta4-8_all.deb
ibrazilian_2.4.really.3.0.beta4-8_i386.deb
  to pool/main/b/br.ispell/ibrazilian_2.4.really.3.0.beta4-8_i386.deb
myspell-pt-br_2.4.really.3.0.beta4-8_all.deb
  to pool/main/b/br.ispell/myspell-pt-br_2.4.really.3.0.beta4-8_all.deb


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

Accepted nagios-plugins 1.4-1 (i386 source)

2005-02-18 Thread Guido Trotter

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 07:50:28 +
Source: nagios-plugins
Binary: nagios-plugins
Architecture: source i386
Version: 1.4-1
Distribution: unstable
Urgency: low
Maintainer: Guido Trotter [EMAIL PROTECTED]
Changed-By: Guido Trotter [EMAIL PROTECTED]
Description: 
 nagios-plugins - Plugins for the nagios network monitoring and management 
system
Closes: 276520 280700 280702 281016 281018 281019 281020 281700 281701 282015 
292124 294224 294298 294299
Changes: 
 nagios-plugins (1.4-1) unstable; urgency=low
 .
   * The I'm still around release
   * New upstream version (closes: #294224)
   * Remove useless patches:
 01_ldap21bind
 04_checkswap
 03_hostwithnumbers
 05_checkbreeze
 07_checkbyssh (apparently it wasn't considered a bug upstream)
   * Fix argument number in check_ldap (closes: #281700) (Thanks Joerg)
   * Fix hostname placeholder in mysql.cfg (closes: #281701)
   * Don't list check_imap twice (closes: #280702)
   * Add check_https command (closes: #292124)
   * Add check_dig command (closes: #281020)
   * Add check_breeze command (closes: #281019)
   * Add dummy commands (closes: #281018)
   * Add check_mailq_MTA commands for all supported mtas (closes: #281016, 
#282015)
   * Add check_spop and check_simap commands (closes: #280700)
   * Add check_nt command (closes: #294299)
   * Fix check_load command (closes: #294298)
   * Fix a reference to @libexec@ in snmp.cfg (closes: #276520)
Files: 
 8bfec908f6d59ff56aa94347ddb57938 869 net extra nagios-plugins_1.4-1.dsc
 d46ae53154a228614629d50ea56d46b6 973910 net extra 
nagios-plugins_1.4.orig.tar.gz
 cdb06953ed69564c4405d1f24d3c8a1f 15164 net extra nagios-plugins_1.4-1.diff.gz
 e5cdaa26ba570de6f074e595f33e2f9f 352786 net extra nagios-plugins_1.4-1_i386.deb

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

iD8DBQFCFa3LhImxTYgHUpsRAiQoAJ9KSNpY96i9xntEdYAjWRuC1R9aDgCfWRSj
iU9rcEp1VOfkVdtipsisLjc=
=qRE5
-END PGP SIGNATURE-


Accepted:
nagios-plugins_1.4-1.diff.gz
  to pool/main/n/nagios-plugins/nagios-plugins_1.4-1.diff.gz
nagios-plugins_1.4-1.dsc
  to pool/main/n/nagios-plugins/nagios-plugins_1.4-1.dsc
nagios-plugins_1.4-1_i386.deb
  to pool/main/n/nagios-plugins/nagios-plugins_1.4-1_i386.deb
nagios-plugins_1.4.orig.tar.gz
  to pool/main/n/nagios-plugins/nagios-plugins_1.4.orig.tar.gz


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

Accepted websvn 1.61-11 (all source)

2005-02-18 Thread Pierre Chifflier

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 09:28:53 +0100
Source: websvn
Binary: websvn
Architecture: source all
Version: 1.61-11
Distribution: unstable
Urgency: medium
Maintainer: Pierre Chifflier [EMAIL PROTECTED]
Changed-By: Pierre Chifflier [EMAIL PROTECTED]
Description: 
 websvn - interface for subversion repositories written in PHP
Closes: 294552 295701
Changes: 
 websvn (1.61-11) unstable; urgency=medium
 .
   * Mark file svn_deb_conf.inc readable for all users (Closes: #295701)
   * Mention fsfs during installation (Closes: #294552)
Files: 
 35186381e07fba46b0d39bfb2520cebb 579 devel optional websvn_1.61-11.dsc
 84272b70cfbb33346bfee7fb29a89397 12720 devel optional websvn_1.61-11.diff.gz
 be6234d70d9766899ea0d9fb3867ffd6 97754 devel optional websvn_1.61-11_all.deb

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

iD8DBQFCFbGHw3ao2vG823MRAkuHAJ97GtPYvJWily9WN/r4a6sp0xg17gCfW8Pp
SWUhZORAdICYavTVvqT+nUY=
=2QOz
-END PGP SIGNATURE-


Accepted:
websvn_1.61-11.diff.gz
  to pool/main/w/websvn/websvn_1.61-11.diff.gz
websvn_1.61-11.dsc
  to pool/main/w/websvn/websvn_1.61-11.dsc
websvn_1.61-11_all.deb
  to pool/main/w/websvn/websvn_1.61-11_all.deb


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

Accepted spheres-and-crystals 0.7-10 (all source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 17 Feb 2005 00:22:07 +0100
Source: spheres-and-crystals
Binary: gtk2-engines-spherecrystal
Architecture: source all
Version: 0.7-10
Distribution: unstable
Urgency: low
Maintainer: Josselin Mouette [EMAIL PROTECTED]
Changed-By: Josselin Mouette [EMAIL PROTECTED]
Description: 
 gtk2-engines-spherecrystal - A blue vector theme for GTK+ 2.x
Closes: 292638
Changes: 
 spheres-and-crystals (0.7-10) unstable; urgency=low
 .
   * SphereCrystal/gtk-2.0/gtkrc: use a blank image instead of a blank string
 (closes: #292638).
   * debian/{postinst,prerm}: use gtk-update-icon-cache to update
 icon-theme.cache files.
Files: 
 2bf98a3b8d96e8b1e7e7cfd75e7ea4d3 666 gnome optional 
spheres-and-crystals_0.7-10.dsc
 4d901f3d6ce2895a9053f35a67374102 6769 gnome optional 
spheres-and-crystals_0.7-10.diff.gz
 21299cc9a9c96a6e0895e2ba140aef94 319508 gnome optional 
gtk2-engines-spherecrystal_0.7-10_all.deb

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

iD8DBQFCE9bmrSla4ddfhTMRAuEyAJ9awzoYps3CggcWTaijUxJwC9jxXwCggnb2
pLb7Llxp8sT5bAtO/Z6yD4Y=
=jX7m
-END PGP SIGNATURE-


Accepted:
gtk2-engines-spherecrystal_0.7-10_all.deb
  to pool/main/s/spheres-and-crystals/gtk2-engines-spherecrystal_0.7-10_all.deb
spheres-and-crystals_0.7-10.diff.gz
  to pool/main/s/spheres-and-crystals/spheres-and-crystals_0.7-10.diff.gz
spheres-and-crystals_0.7-10.dsc
  to pool/main/s/spheres-and-crystals/spheres-and-crystals_0.7-10.dsc


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

Accepted bluez-utils 2.15-1 (i386 source)

2005-02-18 Thread Edd Dumbill

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat,  5 Feb 2005 18:09:24 +
Source: bluez-utils
Binary: bluez-pcmcia-support bluez-bcm203x bluez-cups bluez-utils
Architecture: source i386
Version: 2.15-1
Distribution: unstable
Urgency: low
Maintainer: Edd Dumbill [EMAIL PROTECTED]
Changed-By: Edd Dumbill [EMAIL PROTECTED]
Description: 
 bluez-bcm203x - Firmware loader for Broadcom 203x based Bluetooth devices
 bluez-cups - Bluetooth printer driver for CUPS
 bluez-pcmcia-support - PCMCIA support files for BlueZ 2.0 Bluetooth tools
 bluez-utils - Bluetooth tools and daemons
Changes: 
 bluez-utils (2.15-1) unstable; urgency=low
 .
   * New upstream release.
   * debian/control: require libbluetooth1-dev 2.15 or better to build.
   * Update 003_manpages.patch.
   * Retire 007_hidd_role_switch.patch as now in upstream.
Files: 
 a71e3ac06df4cd790176709d05498bcb 710 admin optional bluez-utils_2.15-1.dsc
 4e86dfd4449ff49e82696d8a3b254002 299709 admin optional 
bluez-utils_2.15.orig.tar.gz
 c526afda116938c220c89a6f11a58553 20830 admin optional 
bluez-utils_2.15-1.diff.gz
 01f54080eaafff9151c4431d187df7e2 149038 admin optional 
bluez-utils_2.15-1_i386.deb
 816ae9423b0d89911d1a3f46abc47184 13828 admin extra 
bluez-pcmcia-support_2.15-1_i386.deb
 b50c30f5c05872088a657696a02636bc 17934 admin optional 
bluez-cups_2.15-1_i386.deb
 2f8a8eead3d6a32256c6b78f5a41561c 16232 contrib/admin optional 
bluez-bcm203x_2.15-1_i386.deb

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

iD8DBQFCBQwirxbtsbubhxERAmnxAJ0aBuIPTiIv9yJGxQ4HV+D06Y4LZACfYcBA
Bqfsgbx8Mcc4FzM9pBrvhgY=
=C8wZ
-END PGP SIGNATURE-


Accepted:
bluez-bcm203x_2.15-1_i386.deb
  to pool/contrib/b/bluez-utils/bluez-bcm203x_2.15-1_i386.deb
bluez-cups_2.15-1_i386.deb
  to pool/main/b/bluez-utils/bluez-cups_2.15-1_i386.deb
bluez-pcmcia-support_2.15-1_i386.deb
  to pool/main/b/bluez-utils/bluez-pcmcia-support_2.15-1_i386.deb
bluez-utils_2.15-1.diff.gz
  to pool/main/b/bluez-utils/bluez-utils_2.15-1.diff.gz
bluez-utils_2.15-1.dsc
  to pool/main/b/bluez-utils/bluez-utils_2.15-1.dsc
bluez-utils_2.15-1_i386.deb
  to pool/main/b/bluez-utils/bluez-utils_2.15-1_i386.deb
bluez-utils_2.15.orig.tar.gz
  to pool/main/b/bluez-utils/bluez-utils_2.15.orig.tar.gz


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

Accepted rdiff-backup 0.13.4-5 (i386 source)

2005-02-18 Thread Daniel Baumann

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 00:29:00 +0100
Source: rdiff-backup
Binary: rdiff-backup
Architecture: source i386
Version: 0.13.4-5
Distribution: unstable
Urgency: high
Maintainer: Daniel Baumann [EMAIL PROTECTED]
Changed-By: Daniel Baumann [EMAIL PROTECTED]
Description: 
 rdiff-backup - incremental backups using binary deltas
Closes: 295638
Changes: 
 rdiff-backup (0.13.4-5) unstable; urgency=high
 .
   * Forgot debian/compat (Closes: #295638).
Files: 
 93c6c9234d5e248191b055b1fce4cc2a 724 utils optional rdiff-backup_0.13.4-5.dsc
 a668fe6a83c1d820204bd7673d04bfc0 7904 utils optional 
rdiff-backup_0.13.4-5.diff.gz
 eb577d1df8dee22b01205c856c4935c5 147782 utils optional 
rdiff-backup_0.13.4-5_i386.deb

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

iEYEARECAAYFAkIVuOQACgkQELuA/Ba9d8bkJQCeOloHG8C4BYRLpWYxPzz39RLE
LhgAoIAxBYLDdXrnjJAnehR9brPUmxCU
=g8jv
-END PGP SIGNATURE-


Accepted:
rdiff-backup_0.13.4-5.diff.gz
  to pool/main/r/rdiff-backup/rdiff-backup_0.13.4-5.diff.gz
rdiff-backup_0.13.4-5.dsc
  to pool/main/r/rdiff-backup/rdiff-backup_0.13.4-5.dsc
rdiff-backup_0.13.4-5_i386.deb
  to pool/main/r/rdiff-backup/rdiff-backup_0.13.4-5_i386.deb


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

Accepted bins 1.1.27-2 (all source)

2005-02-18 Thread Ludovic Rousseau

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 11:05:23 +0100
Source: bins
Binary: bins
Architecture: source all
Version: 1.1.27-2
Distribution: unstable
Urgency: low
Maintainer: Ludovic Rousseau [EMAIL PROTECTED]
Changed-By: Ludovic Rousseau [EMAIL PROTECTED]
Description: 
 bins   - Generate static HTML photo albums using XML and EXIF tags
Closes: 295716
Changes: 
 bins (1.1.27-2) unstable; urgency=low
 .
   * debian/patches/11_bins.dpatch: Closes: #295716 bins: consider path/a-b to
 a subdir of path/a. This should also really close bug #271150
Files: 
 40c2c294b4a1763ee6c20eb813a051a3 610 web optional bins_1.1.27-2.dsc
 f67185bcb1eabfcb263b879f2e067606 8893 web optional bins_1.1.27-2.diff.gz
 4bfa7a91f260121f8c63e8bf59ecf6db 209928 web optional bins_1.1.27-2_all.deb

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

iD8DBQFCFcH+P0qKj+B/HPkRAkH3AJ9axBOx9bES4kImDhXgpUUR8f1NQACff2KK
IcbF+HxIw2DQkCWhjUx+hZg=
=2MMI
-END PGP SIGNATURE-


Accepted:
bins_1.1.27-2.diff.gz
  to pool/main/b/bins/bins_1.1.27-2.diff.gz
bins_1.1.27-2.dsc
  to pool/main/b/bins/bins_1.1.27-2.dsc
bins_1.1.27-2_all.deb
  to pool/main/b/bins/bins_1.1.27-2_all.deb


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

Accepted openoffice.org-debian-files 1.1.3-5+1 (all source)

2005-02-18 Thread Rene Engelhard

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 14 Feb 2005 02:41:31 +0100
Source: openoffice.org-debian-files
Binary: openoffice.org-debian-files
Architecture: source all
Version: 1.1.3-5+1
Distribution: unstable
Urgency: low
Maintainer: Debian OpenOffice Team debian-openoffice@lists.debian.org
Changed-By: Rene Engelhard [EMAIL PROTECTED]
Description: 
 openoffice.org-debian-files - Debian specific parts of OpenOffice.org
Closes: 258074 267963 285012 291821 294885
Changes: 
 openoffice.org-debian-files (1.1.3-5+1) unstable; urgency=low
 .
   * update dictionary, thesauri and help section in README.Debian
 (and fix thesaurus sentence) - closes: #285012 [RE]
   * change $OOHOME/user/basic/script.xlc if we find /usr/lib/openoffice.org1.1
 referenced (closes: #267963) [RE]
   * mention that the GNOME and KDE file pickers are disabled by default [RE]
   * remove application/msexcel mimetype (closes: #291821)
   * remove Jan-Hendick Palic from Uploaders [RE]
   * add regcomp manpage; thanks Nathanael Nerode (closes: #294885) [RE]
   * generate a bash_completion file for
 oo{calc,writer,impress,draw,math,fromtemplate,master} (closes: #258074) 
[RE]
Files: 
 ce9ff781ea22b92f72aa59fe7fe20fc2 666 editors optional 
openoffice.org-debian-files_1.1.3-5+1.dsc
 a03324760d0dade76c4e0591ddf6922c 31917 editors optional 
openoffice.org-debian-files_1.1.3-5+1.tar.gz
 b01c166093ad9b8f7d8546ba645fe9f7 35480 editors optional 
openoffice.org-debian-files_1.1.3-5+1_all.deb

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

iD8DBQFCFFsK+FmQsCSK63MRAlgTAJ47umqQwmkJkb5LVy8RuiqL5Jnd2gCeJFeA
rTm0XsAPnK4EuACT5A0fX7Q=
=MDPR
-END PGP SIGNATURE-


Accepted:
openoffice.org-debian-files_1.1.3-5+1.dsc
  to 
pool/main/o/openoffice.org-debian-files/openoffice.org-debian-files_1.1.3-5+1.dsc
openoffice.org-debian-files_1.1.3-5+1.tar.gz
  to 
pool/main/o/openoffice.org-debian-files/openoffice.org-debian-files_1.1.3-5+1.tar.gz
openoffice.org-debian-files_1.1.3-5+1_all.deb
  to 
pool/main/o/openoffice.org-debian-files/openoffice.org-debian-files_1.1.3-5+1_all.deb


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

Accepted doc-gnome-hig 2.0-2 (all source)

2005-02-18 Thread Ross Burton

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 11:02:13 +
Source: doc-gnome-hig
Binary: doc-gnome-hig
Architecture: source all
Version: 2.0-2
Distribution: unstable
Urgency: low
Maintainer: Ross Burton [EMAIL PROTECTED]
Changed-By: Ross Burton [EMAIL PROTECTED]
Description: 
 doc-gnome-hig - GNOME Human Interface Guidelines
Changes: 
 doc-gnome-hig (2.0-2) unstable; urgency=low
 .
   * Put documentation into Apps/Programming
Files: 
 2d3fa429eacdda1650312574e81c969d 582 doc optional doc-gnome-hig_2.0-2.dsc
 9e53336ab041dada896a1a653e5cd6f9 8421 doc optional doc-gnome-hig_2.0-2.diff.gz
 2834623dc8d934d95199d2f828a208a5 1522374 doc optional 
doc-gnome-hig_2.0-2_all.deb

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

iD8DBQFCFcvVLQnkR9C0M98RAl5tAKDtEi41s9XfJ7/Q/F3kKn7cnfQCRgCfVClQ
ITOjHLXoFzqWa4XrKCZz0z4=
=jXid
-END PGP SIGNATURE-


Accepted:
doc-gnome-hig_2.0-2.diff.gz
  to pool/main/d/doc-gnome-hig/doc-gnome-hig_2.0-2.diff.gz
doc-gnome-hig_2.0-2.dsc
  to pool/main/d/doc-gnome-hig/doc-gnome-hig_2.0-2.dsc
doc-gnome-hig_2.0-2_all.deb
  to pool/main/d/doc-gnome-hig/doc-gnome-hig_2.0-2_all.deb


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

Accepted openoffice.org 1.1.3-5 (i386 source all)

2005-02-18 Thread Chris Halls

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 16 Feb 2005 23:11:25 +
Source: openoffice.org
Binary: openoffice.org-l10n-el openoffice.org-l10n-en openoffice.org-l10n-ja 
openoffice.org-l10n-zu openoffice.org-l10n-fr openoffice.org-l10n-zh-cn 
openoffice.org-l10n-pt-br openoffice.org-l10n-es openoffice.org 
openoffice.org-l10n-af openoffice.org-l10n-zh-tw openoffice.org-l10n-ru 
openoffice.org-l10n-tr openoffice.org-dev openoffice.org-l10n-hi 
openoffice.org-l10n-de openoffice.org-l10n-pl openoffice.org-l10n-eu 
openoffice.org-l10n-gl openoffice.org-l10n-lt openoffice.org-thesaurus-en-us 
openoffice.org-l10n-kn openoffice.org-gtk-gnome openoffice.org-l10n-da 
openoffice.org-kde openoffice.org-l10n-hu openoffice.org-mimelnk 
openoffice.org-l10n-sk openoffice.org-l10n-pt openoffice.org-l10n-nn 
openoffice.org-l10n-it openoffice.org-java openoffice.org-l10n-nb 
openoffice.org-l10n-ca openoffice.org-l10n-he openoffice.org-l10n-sl 
openoffice.org-l10n-ar ttf-opensymbol openoffice.org-evolution 
openoffice.org-l10n-et openoffice.org-l10n-ko openoffice.org-gnomevfs 
openoffice.org-bin openoffice
 .org-l10n-fi openoffice.org-l10n-cy openoffice.org-l10n-nl 
openoffice.org-l10n-tn openoffice.org-l10n-sv openoffice.org-l10n-th 
openoffice.org-l10n-ns openoffice.org-l10n-cs
Architecture: source all i386
Version: 1.1.3-5
Distribution: unstable
Urgency: high
Maintainer: Debian OpenOffice Team debian-openoffice@lists.debian.org
Changed-By: Chris Halls [EMAIL PROTECTED]
Description: 
 openoffice.org - high-quality office productivity suite
 openoffice.org-bin - OpenOffice.org office suite binary files
 openoffice.org-dev - OpenOffice.org SDK - development files
 openoffice.org-evolution - Evolution 2 Addressbook support for OpenOffice.org
 openoffice.org-gnomevfs - GNOME VFS support for OpenOffice.org
 openoffice.org-gtk-gnome - Gtk UI Plugin and GNOME File Picker for 
OpenOffice.org
 openoffice.org-kde - KDE UI Plugin and KDE File Picker for OpenOffice.org
 openoffice.org-l10n-af - Afrikaans language package for OpenOffice.org
 openoffice.org-l10n-ar - Arabic language package for OpenOffice.org
 openoffice.org-l10n-ca - Catalan language package for OpenOffice.org
 openoffice.org-l10n-cs - Czech language package for OpenOffice.org
 openoffice.org-l10n-cy - Welsh language package for OpenOffice.org
 openoffice.org-l10n-da - Danish language package for OpenOffice.org
 openoffice.org-l10n-de - German language package for OpenOffice.org
 openoffice.org-l10n-el - Greek language package for OpenOffice.org
 openoffice.org-l10n-en - English (US) language package for OpenOffice.org
 openoffice.org-l10n-es - Spanish language package for OpenOffice.org
 openoffice.org-l10n-et - Estonian language package for OpenOffice.org
 openoffice.org-l10n-eu - Basque language package for OpenOffice.org
 openoffice.org-l10n-fi - Finnish language package for OpenOffice.org
 openoffice.org-l10n-fr - French language package for OpenOffice.org
 openoffice.org-l10n-gl - Galician language package for OpenOffice.org
 openoffice.org-l10n-he - Hebrew language package for OpenOffice.org
 openoffice.org-l10n-hi - Hindi language package for OpenOffice.org
 openoffice.org-l10n-hu - Hungarian language package for OpenOffice.org
 openoffice.org-l10n-it - Italian language package for OpenOffice.org
 openoffice.org-l10n-ja - Japanese language package for OpenOffice.org
 openoffice.org-l10n-kn - Kannada language package for OpenOffice.org
 openoffice.org-l10n-ko - Korean language package for OpenOffice.org
 openoffice.org-l10n-lt - Lithuanian language package for OpenOffice.org
 openoffice.org-l10n-nb - Norwegian Bokmal language package for OpenOffice.org
 openoffice.org-l10n-nl - Dutch language package for OpenOffice.org
 openoffice.org-l10n-nn - Norwegian Nynorsk language package for OpenOffice.org
 openoffice.org-l10n-ns - Northern Sotho language package for OpenOffice.org
 openoffice.org-l10n-pl - Polish language package for OpenOffice.org
 openoffice.org-l10n-pt - Portuguese language package for OpenOffice.org
 openoffice.org-l10n-pt-br - Portuguese (Brazil) language package for 
OpenOffice.org
 openoffice.org-l10n-ru - Russian language package for OpenOffice.org
 openoffice.org-l10n-sk - Slovak language package for OpenOffice.org
 openoffice.org-l10n-sl - Slovenian language package for OpenOffice.org
 openoffice.org-l10n-sv - Swedish language package for OpenOffice.org
 openoffice.org-l10n-th - Thai language package for OpenOffice.org
 openoffice.org-l10n-tn - Tswana language package for OpenOffice.org
 openoffice.org-l10n-tr - Turkish language package for OpenOffice.org
 openoffice.org-l10n-zh-cn - Chinese Simplified language package for 
OpenOffice.org
 openoffice.org-l10n-zh-tw - Chinese Traditional language package for 
OpenOffice.org
 openoffice.org-l10n-zu - Zulu language package for OpenOffice.org
 openoffice.org-mimelnk - OpenOffice.org MIME bindings for KDE
 openoffice.org-thesaurus-en-us - English (US) Thesaurus for

Accepted wajig 2.0.23 (all source)

2005-02-18 Thread Graham Williams

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri,  18 Feb 2005 18:17:37 +1100
Source: wajig
Binary: wajig
Architecture: source all
Version: 2.0.23
Distribution: unstable
Urgency: low
Maintainer: Graham Williams [EMAIL PROTECTED]
Changed-By: Graham Williams [EMAIL PROTECTED]
Description: 
 wajig  - simplified Debian package management front end
Closes: 295455
Changes: 
 wajig (2.0.23) unstable; urgency=low
 .
   * Change plurality of a message
   * Fix problem with CHANGLOG when the source package is not an
 installable package, as in libgtk2.0-dev and source gtk+2.0.
 Bug reported by Matthew Hawkins (Closes: #295455).
Files: 
 1faf919d08ee4a0862b53b2b851b4057 546 admin optional wajig_2.0.23.dsc
 f4becf78b003a3193cec34128086781a 119596 admin optional wajig_2.0.23.tar.gz
 6d9089a62a0bbdc83bf14bc12a3b5c55 78928 admin optional wajig_2.0.23_all.deb

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

iD8DBQFCFd1FCZSR95Gw07cRAuzrAJ97qT3ceMpXBpqhy1Ar/qNYXvOM0gCfTKD0
fPnF1S2BgIKaATPNJsvg3YE=
=80Aa
-END PGP SIGNATURE-


Accepted:
wajig_2.0.23.dsc
  to pool/main/w/wajig/wajig_2.0.23.dsc
wajig_2.0.23.tar.gz
  to pool/main/w/wajig/wajig_2.0.23.tar.gz
wajig_2.0.23_all.deb
  to pool/main/w/wajig/wajig_2.0.23_all.deb


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

Accepted zziplib 0.12.83-4 (i386 source)

2005-02-18 Thread Aurelien Jarno

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 12:45:00 +0100
Source: zziplib
Binary: libzzip-0-12 libzzip-dev zziplib-bin
Architecture: source i386
Version: 0.12.83-4
Distribution: unstable
Urgency: low
Maintainer: Aurelien Jarno [EMAIL PROTECTED]
Changed-By: Aurelien Jarno [EMAIL PROTECTED]
Description: 
 libzzip-0-12 - library providing read access on ZIP-archives - library
 libzzip-dev - library providing read access on ZIP-archives - development
 zziplib-bin - library providing read access on ZIP-archives - binaries
Closes: 294730
Changes: 
 zziplib (0.12.83-4) unstable; urgency=low
 .
   * Libtool update for kfreebsd-gnu in zziplib/ directory (closes:
 bug#294730).
Files: 
 977b4cf3c057518c19d5b70ddda7ff30 641 libs optional zziplib_0.12.83-4.dsc
 9d850a9205955ec24851717bc6b71311 603167 libs optional zziplib_0.12.83-4.diff.gz
 9186e7cd5e5282498daf905e1fb975fa 29234 utils optional 
zziplib-bin_0.12.83-4_i386.deb
 0599aa5ac4ef3ada04efee564bf462e8 33584 libs optional 
libzzip-0-12_0.12.83-4_i386.deb
 554409b0679be8941ea3ff08133e8f69 92670 devel optional 
libzzip-dev_0.12.83-4_i386.deb

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

iD8DBQFCFeL/w3ao2vG823MRAmZvAJ45wC66VVg4SXkmqOfnfnaLnwhH3gCaAnm0
G5h3suagWkSK9xPv6Tb+01Q=
=iEHv
-END PGP SIGNATURE-


Accepted:
libzzip-0-12_0.12.83-4_i386.deb
  to pool/main/z/zziplib/libzzip-0-12_0.12.83-4_i386.deb
libzzip-dev_0.12.83-4_i386.deb
  to pool/main/z/zziplib/libzzip-dev_0.12.83-4_i386.deb
zziplib-bin_0.12.83-4_i386.deb
  to pool/main/z/zziplib/zziplib-bin_0.12.83-4_i386.deb
zziplib_0.12.83-4.diff.gz
  to pool/main/z/zziplib/zziplib_0.12.83-4.diff.gz
zziplib_0.12.83-4.dsc
  to pool/main/z/zziplib/zziplib_0.12.83-4.dsc


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

Accepted libgtkada2 2.4.0-2 (i386 source all)

2005-02-18 Thread Ludovic Brenta

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat,  5 Feb 2005 23:44:37 +0100
Source: libgtkada2
Binary: libgtkada-gl-2.4 libgtkada2-dev libgtkada-2.4 libgnomeada2-dev 
libgnomeada-2.4 libgtkada2-doc libgtkada-glade-2.4
Architecture: source i386 all
Version: 2.4.0-2
Distribution: unstable
Urgency: low
Maintainer: Ludovic Brenta [EMAIL PROTECTED]
Changed-By: Ludovic Brenta [EMAIL PROTECTED]
Description: 
 libgnomeada-2.4 - Ada binding for the Gnome Library
 libgnomeada2-dev - Development files for libgnomeada2
 libgtkada-2.4 - Ada binding for the GTK library
 libgtkada-gl-2.4 - Ada binding for OpenGL
 libgtkada-glade-2.4 - Ada binding for Glade generated applications
 libgtkada2-dev - Development files for libgtkada2
 libgtkada2-doc - Documentation for libgtkada2
Closes: 249663 249664 272663 293652
Changes: 
 libgtkada2 (2.4.0-2) unstable; urgency=low
 .
   * The sonames of the shared libraries have changed.  Change binary
 package names (with Conflicts and Replaces):
 libgnomeada2 - libgnomeada-2.4
 libgtkada2-0 - libgtkada-2.4
 libgtkada2-gl- libgtkada-gl-2.4
 libgtkaga2-glade - libgtkada-glade-2.4
 Closes: #293652.
   * The upstream release also Closes: #249663, #249664, #272663.
Files: 
 c96eb8b8f87f7911d09f1065771e39c6 866 libs optional libgtkada2_2.4.0-2.dsc
 e04f9a7e3436bd763d170b39b23a0141 18800 libs optional libgtkada2_2.4.0-2.diff.gz
 733ee6c2d58a29a367a0d64b082d1828 2036596 doc optional 
libgtkada2-doc_2.4.0-2_all.deb
 8eff6aba1e2849bb63365406b5e4d418 7112654 libdevel optional 
libgtkada2-dev_2.4.0-2_i386.deb
 a61b2e32f4c8f5cf42b1e48a1fe2436c 331588 libdevel optional 
libgnomeada2-dev_2.4.0-2_i386.deb
 e76d2c5f9ede3667939e5c7948ca0923 861196 libs optional 
libgtkada-2.4_2.4.0-2_i386.deb
 88edd128ede697de14d4f2bb86e4901b 77804 libs optional 
libgnomeada-2.4_2.4.0-2_i386.deb
 94f1922913be5a06e5bc411291d70efb 13522 libs optional 
libgtkada-glade-2.4_2.4.0-2_i386.deb
 a291a61e6f249adc2db07fbfc70e4b97 28868 libs optional 
libgtkada-gl-2.4_2.4.0-2_i386.deb

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

iD8DBQFCBjppStlRaw+TLJwRAvxdAKCpPxRRZ2GMBkRbgXHHd//V9b8T1QCfbCWi
b8+WH3J2QXPF/I4yyYDd/s0=
=yp/c
-END PGP SIGNATURE-


Accepted:
libgnomeada-2.4_2.4.0-2_i386.deb
  to pool/main/libg/libgtkada2/libgnomeada-2.4_2.4.0-2_i386.deb
libgnomeada2-dev_2.4.0-2_i386.deb
  to pool/main/libg/libgtkada2/libgnomeada2-dev_2.4.0-2_i386.deb
libgtkada-2.4_2.4.0-2_i386.deb
  to pool/main/libg/libgtkada2/libgtkada-2.4_2.4.0-2_i386.deb
libgtkada-gl-2.4_2.4.0-2_i386.deb
  to pool/main/libg/libgtkada2/libgtkada-gl-2.4_2.4.0-2_i386.deb
libgtkada-glade-2.4_2.4.0-2_i386.deb
  to pool/main/libg/libgtkada2/libgtkada-glade-2.4_2.4.0-2_i386.deb
libgtkada2-dev_2.4.0-2_i386.deb
  to pool/main/libg/libgtkada2/libgtkada2-dev_2.4.0-2_i386.deb
libgtkada2-doc_2.4.0-2_all.deb
  to pool/main/libg/libgtkada2/libgtkada2-doc_2.4.0-2_all.deb
libgtkada2_2.4.0-2.diff.gz
  to pool/main/libg/libgtkada2/libgtkada2_2.4.0-2.diff.gz
libgtkada2_2.4.0-2.dsc
  to pool/main/libg/libgtkada2/libgtkada2_2.4.0-2.dsc


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

Accepted hddtemp 0.3-beta12-13 (i386 source)

2005-02-18 Thread Aurelien Jarno

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 12:42:18 +0100
Source: hddtemp
Binary: hddtemp
Architecture: source i386
Version: 0.3-beta12-13
Distribution: unstable
Urgency: low
Maintainer: Aurelien Jarno [EMAIL PROTECTED]
Changed-By: Aurelien Jarno [EMAIL PROTECTED]
Description: 
 hddtemp- Utility to monitor the temperature of your hard drive
Closes: 295814
Changes: 
 hddtemp (0.3-beta12-13) unstable; urgency=low
 .
   * Don't display an error message if /proc/sys/dev/cdrom/info doesn't
 exist (systems without CDROM drives) (closes: bug#295814).
Files: 
 3324001bc75cd904813d049ffdb10bd1 618 utils extra hddtemp_0.3-beta12-13.dsc
 9b57ba5475fd27a9aa6ee1363ed03bca 34450 utils extra 
hddtemp_0.3-beta12-13.diff.gz
 236d186b6d545e08a7c221dac6415fed 45828 utils extra 
hddtemp_0.3-beta12-13_i386.deb

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

iD8DBQFCFdW4w3ao2vG823MRAgFJAKCBPIix4cZslMHoRFFurIVfJORKSQCffKAb
lCL3qUVcPz960JwVFzb8SaA=
=hrZU
-END PGP SIGNATURE-


Accepted:
hddtemp_0.3-beta12-13.diff.gz
  to pool/main/h/hddtemp/hddtemp_0.3-beta12-13.diff.gz
hddtemp_0.3-beta12-13.dsc
  to pool/main/h/hddtemp/hddtemp_0.3-beta12-13.dsc
hddtemp_0.3-beta12-13_i386.deb
  to pool/main/h/hddtemp/hddtemp_0.3-beta12-13_i386.deb


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

Accepted sctplib-stable 1.0.1a-1 (i386 source all)

2005-02-18 Thread Anibal Monsalve Salazar

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 23:26:52 +1100
Source: sctplib-stable
Binary: sctplib-stable-doc sctplib-stable1 sctplib-stable-dev
Architecture: source i386 all
Version: 1.0.1a-1
Distribution: unstable
Urgency: low
Maintainer: Anibal Monsalve Salazar [EMAIL PROTECTED]
Changed-By: Anibal Monsalve Salazar [EMAIL PROTECTED]
Description: 
 sctplib-stable-dev - stable userland implementation of the SCTP protocol RFC 
2960
 sctplib-stable-doc - stable userland implementation of the SCTP protocol RFC 
2960
 sctplib-stable1 - stable userland implementation of the SCTP protocol RFC 2960
Changes: 
 sctplib-stable (1.0.1a-1) unstable; urgency=low
 .
   * Removed non-free ITEF's RFCs from original upstream package.
   * New maintainer's email address.
Files: 
 70028d9e82382b3050aec197c3f9179d 638 net optional sctplib-stable_1.0.1a-1.dsc
 a6a3ff6d413f9c47571f1520f0327a7f 1140635 net optional 
sctplib-stable_1.0.1a.orig.tar.gz
 d497f71e4c1c5aa0f039596d7ecb0a1b 2980 net optional 
sctplib-stable_1.0.1a-1.diff.gz
 df56a22ff32aa41d871e8137f594fed0 643488 doc optional 
sctplib-stable-doc_1.0.1a-1_all.deb
 bafa0ac8f4625272e2f693db4ef89988 77048 libs optional 
sctplib-stable1_1.0.1a-1_i386.deb
 b31cae782751731ba7051048c8f06a74 86040 libdevel optional 
sctplib-stable-dev_1.0.1a-1_i386.deb

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

iD8DBQFCFeJUgY5NIXPNpFURAmANAJkB0Khy565jqsu6yjpRcQg+fhElLwCggTYe
cbPQ5T+ezz6bw/EcYdtpJnw=
=2wok
-END PGP SIGNATURE-


Accepted:
sctplib-stable-dev_1.0.1a-1_i386.deb
  to pool/main/s/sctplib-stable/sctplib-stable-dev_1.0.1a-1_i386.deb
sctplib-stable-doc_1.0.1a-1_all.deb
  to pool/main/s/sctplib-stable/sctplib-stable-doc_1.0.1a-1_all.deb
sctplib-stable1_1.0.1a-1_i386.deb
  to pool/main/s/sctplib-stable/sctplib-stable1_1.0.1a-1_i386.deb
sctplib-stable_1.0.1a-1.diff.gz
  to pool/main/s/sctplib-stable/sctplib-stable_1.0.1a-1.diff.gz
sctplib-stable_1.0.1a-1.dsc
  to pool/main/s/sctplib-stable/sctplib-stable_1.0.1a-1.dsc
sctplib-stable_1.0.1a.orig.tar.gz
  to pool/main/s/sctplib-stable/sctplib-stable_1.0.1a.orig.tar.gz


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

Accepted xmedcon 0.9.8.4-1 (i386 source)

2005-02-18 Thread Roland Marcus Rutschmann

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 17 Feb 2005 11:47:33 +0100
Source: xmedcon
Binary: xmedcon libmdc2 medcon libmdc2-dev
Architecture: source i386
Version: 0.9.8.4-1
Distribution: unstable
Urgency: low
Maintainer: Roland Marcus Rutschmann [EMAIL PROTECTED]
Changed-By: Roland Marcus Rutschmann [EMAIL PROTECTED]
Description: 
 libmdc2- Medical Image (DICOM, ECAT, ...) conversion tool
 libmdc2-dev - Medical Image (DICOM, ECAT, ...) conversion tool
 medcon - Medical Image (DICOM, ECAT, ...) conversion tool
 xmedcon- Medical Image (DICOM, ECAT, ...) conversion tool
Changes: 
 xmedcon (0.9.8.4-1) unstable; urgency=low
 .
   * New upstream release
Files: 
 c17df5f0136d68d4e539b144a4177309 667 graphics optional xmedcon_0.9.8.4-1.dsc
 af733d74566fe07c789941461122 802391 graphics optional 
xmedcon_0.9.8.4.orig.tar.gz
 bada2e247ca5cb80b52a1df025dddaaf 38837 graphics optional 
xmedcon_0.9.8.4-1.diff.gz
 884941b4660232b355e148bfb61286ad 237334 libs optional 
libmdc2_0.9.8.4-1_i386.deb
 1f6c47361735fbee05d19849821694a0 331214 libdevel optional 
libmdc2-dev_0.9.8.4-1_i386.deb
 447da67711c848e7b788323974f1095d 29282 graphics optional 
medcon_0.9.8.4-1_i386.deb
 67d7db6bc716ddd816bf65310799bd79 93948 graphics optional 
xmedcon_0.9.8.4-1_i386.deb

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

iD8DBQFCFHqtqE9wmu3T13kRAi6fAJ0T+Q7e5I+bF1iJOxyyZ2Tp/v8AYQCeKkMN
obUaRwCTMmxMpVhBZumOtZw=
=mb6t
-END PGP SIGNATURE-


Accepted:
libmdc2-dev_0.9.8.4-1_i386.deb
  to pool/main/x/xmedcon/libmdc2-dev_0.9.8.4-1_i386.deb
libmdc2_0.9.8.4-1_i386.deb
  to pool/main/x/xmedcon/libmdc2_0.9.8.4-1_i386.deb
medcon_0.9.8.4-1_i386.deb
  to pool/main/x/xmedcon/medcon_0.9.8.4-1_i386.deb
xmedcon_0.9.8.4-1.diff.gz
  to pool/main/x/xmedcon/xmedcon_0.9.8.4-1.diff.gz
xmedcon_0.9.8.4-1.dsc
  to pool/main/x/xmedcon/xmedcon_0.9.8.4-1.dsc
xmedcon_0.9.8.4-1_i386.deb
  to pool/main/x/xmedcon/xmedcon_0.9.8.4-1_i386.deb
xmedcon_0.9.8.4.orig.tar.gz
  to pool/main/x/xmedcon/xmedcon_0.9.8.4.orig.tar.gz


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

Accepted libbonobo 2.8.1-2 (i386 source)

2005-02-18 Thread Sebastien Bacher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 14:40:51 +0100
Source: libbonobo
Binary: libbonobo2-dev libbonobo2-common libbonobo2-0
Architecture: source i386
Version: 2.8.1-2
Distribution: unstable
Urgency: low
Maintainer: Takuo KITAME [EMAIL PROTECTED]
Changed-By: Sebastien Bacher [EMAIL PROTECTED]
Description: 
 libbonobo2-0 - Bonobo CORBA interfaces library
 libbonobo2-common - Bonobo CORBA interfaces library -- support files
 libbonobo2-dev - Bonobo CORBA interfaces library -- development files
Changes: 
 libbonobo (2.8.1-2) unstable; urgency=low
 .
   * debian/patches/ia64build.patch:
 - fix the FTBFS on ia64.
   * debian/rules:
 - specify the shlibs version.
Files: 
 ef770086917755000e281af265bb76ab 1618 devel optional libbonobo_2.8.1-2.dsc
 4506d190f30f467a714b512502429d16 32866 devel optional libbonobo_2.8.1-2.diff.gz
 91b91934934a3722c5ed492b767ef11f 709070 devel optional 
libbonobo2-common_2.8.1-2_i386.deb
 c37f82c7015e77516026616a0646b17e 238886 libdevel optional 
libbonobo2-dev_2.8.1-2_i386.deb
 73787d3a42b0f73130af2f1778663102 144842 libs optional 
libbonobo2-0_2.8.1-2_i386.deb

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

iD8DBQFCFfM7Qxo87aLX0pIRAscOAJwM0lZW4gkYSPBNYWDK69ZR2mQEqwCeMvDO
9mjEtMb6KWtYUgUDy2BG+eY=
=GVzF
-END PGP SIGNATURE-


Accepted:
libbonobo2-0_2.8.1-2_i386.deb
  to pool/main/libb/libbonobo/libbonobo2-0_2.8.1-2_i386.deb
libbonobo2-common_2.8.1-2_i386.deb
  to pool/main/libb/libbonobo/libbonobo2-common_2.8.1-2_i386.deb
libbonobo2-dev_2.8.1-2_i386.deb
  to pool/main/libb/libbonobo/libbonobo2-dev_2.8.1-2_i386.deb
libbonobo_2.8.1-2.diff.gz
  to pool/main/libb/libbonobo/libbonobo_2.8.1-2.diff.gz
libbonobo_2.8.1-2.dsc
  to pool/main/libb/libbonobo/libbonobo_2.8.1-2.dsc


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

Accepted cupsys 1.1.23-5 (i386 source all)

2005-02-18 Thread Kenshi Muto

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 21:23:10 +0900
Source: cupsys
Binary: cupsys-bsd libcupsys2-dev libcupsys2 cupsys libcupsys2-gnutls10 
libcupsimage2-dev libcupsimage2 cupsys-client
Architecture: source i386 all
Version: 1.1.23-5
Distribution: unstable
Urgency: low
Maintainer: Kenshi Muto [EMAIL PROTECTED]
Changed-By: Kenshi Muto [EMAIL PROTECTED]
Description: 
 cupsys - Common UNIX Printing System(tm) - server
 cupsys-bsd - Common UNIX Printing System(tm) - BSD commands
 cupsys-client - Common UNIX Printing System(tm) - client programs (SysV)
 libcupsimage2 - Common UNIX Printing System(tm) - image libs
 libcupsimage2-dev - Common UNIX Printing System(tm) - image development files
 libcupsys2 - Common UNIX Printing System(tm) - dummy libs for transition
 libcupsys2-dev - Common UNIX Printing System(tm) - development files
 libcupsys2-gnutls10 - Common UNIX Printing System(tm) - libs
Closes: 295642
Changes: 
 cupsys (1.1.23-5) unstable; urgency=low
 .
   * Improve postinst message (closes: #295642). Thanks Adam.
Files: 
 3b1bd005cc7f6fc810438695adfca446 819 net optional cupsys_1.1.23-5.dsc
 1706feff6e81c41cecdfa73a91649364 1273298 net optional cupsys_1.1.23-5.diff.gz
 f9e31fcc4371f7d7462b6645231c826e 966 libs optional libcupsys2_1.1.23-5_all.deb
 afc5e172decbabdaff87ea0629dcb725 8935440 net optional cupsys_1.1.23-5_i386.deb
 27c6cfaa0e2f830499a611b892cebac8 91390 net optional 
cupsys-client_1.1.23-5_i386.deb
 47bba0215944a5dae8346b3057ae5982 74346 libs optional 
libcupsys2-gnutls10_1.1.23-5_i386.deb
 a6f7ea3a582715ca24910e08374e2473 85202 libdevel optional 
libcupsys2-dev_1.1.23-5_i386.deb
 6086a72ab7a80e3ed952ffd8005586c1 35526 libs optional 
libcupsimage2_1.1.23-5_i386.deb
 80ba604b2b192c94f1c484bfc4a16e2b 45896 libdevel optional 
libcupsimage2-dev_1.1.23-5_i386.deb
 8dd1898f2ceff7a0d0d7745e1cd2d027 40874 net extra cupsys-bsd_1.1.23-5_i386.deb

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

iEYEARECAAYFAkIV6OwACgkQQKW+7XLQPLGU6QCgnNcaCZGI6yromD38j/8MonJU
Ef8AnijI8yguVMBxnDAzoB60lw7cq+as
=QDL5
-END PGP SIGNATURE-


Accepted:
cupsys-bsd_1.1.23-5_i386.deb
  to pool/main/c/cupsys/cupsys-bsd_1.1.23-5_i386.deb
cupsys-client_1.1.23-5_i386.deb
  to pool/main/c/cupsys/cupsys-client_1.1.23-5_i386.deb
cupsys_1.1.23-5.diff.gz
  to pool/main/c/cupsys/cupsys_1.1.23-5.diff.gz
cupsys_1.1.23-5.dsc
  to pool/main/c/cupsys/cupsys_1.1.23-5.dsc
cupsys_1.1.23-5_i386.deb
  to pool/main/c/cupsys/cupsys_1.1.23-5_i386.deb
libcupsimage2-dev_1.1.23-5_i386.deb
  to pool/main/c/cupsys/libcupsimage2-dev_1.1.23-5_i386.deb
libcupsimage2_1.1.23-5_i386.deb
  to pool/main/c/cupsys/libcupsimage2_1.1.23-5_i386.deb
libcupsys2-dev_1.1.23-5_i386.deb
  to pool/main/c/cupsys/libcupsys2-dev_1.1.23-5_i386.deb
libcupsys2-gnutls10_1.1.23-5_i386.deb
  to pool/main/c/cupsys/libcupsys2-gnutls10_1.1.23-5_i386.deb
libcupsys2_1.1.23-5_all.deb
  to pool/main/c/cupsys/libcupsys2_1.1.23-5_all.deb


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

Accepted sctplib 1.3.1-1 (i386 source all)

2005-02-18 Thread Anibal Monsalve Salazar

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 19 Feb 2005 00:23:25 +1100
Source: sctplib
Binary: sctplib-doc sctplib1 sctplib-dev
Architecture: source i386 all
Version: 1.3.1-1
Distribution: unstable
Urgency: low
Maintainer: Anibal Monsalve Salazar [EMAIL PROTECTED]
Changed-By: Anibal Monsalve Salazar [EMAIL PROTECTED]
Description: 
 sctplib-dev - userland implementation of the SCTP protocol (RFC 2960)
 sctplib-doc - userland implementation of the SCTP protocol (RFC 2960)
 sctplib1   - userland implementation of the SCTP protocol (RFC 2960)
Changes: 
 sctplib (1.3.1-1) unstable; urgency=low
 .
   * New upstream release.
 Removed non-free IETF's RFCs.
Files: 
 a58fca5cb47cf038518cf251f52b1adc 593 net optional sctplib_1.3.1-1.dsc
 9b93237e864e6185271cb5c62a917485 1031765 net optional sctplib_1.3.1.orig.tar.gz
 9e3fb83fccca98d47846a9a4ef2da120 3026 net optional sctplib_1.3.1-1.diff.gz
 a6ecefdb4f1435d5cac504876c6a7c45 590530 doc optional 
sctplib-doc_1.3.1-1_all.deb
 ff2fbabddd7834eb3e7d0d0e31f50e45 95466 libs optional sctplib1_1.3.1-1_i386.deb
 ad2a75276e2e67c1074dea5f69540348 102686 libdevel optional 
sctplib-dev_1.3.1-1_i386.deb

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

iD8DBQFCFfBGgY5NIXPNpFURAn0+AJ4xCEMZ/WGvZcW5ziFMCqy3NsMqcACgsU/+
iPl3M8AeOSN5D2GBu4V6QsY=
=mDtX
-END PGP SIGNATURE-


Accepted:
sctplib-dev_1.3.1-1_i386.deb
  to pool/main/s/sctplib/sctplib-dev_1.3.1-1_i386.deb
sctplib-doc_1.3.1-1_all.deb
  to pool/main/s/sctplib/sctplib-doc_1.3.1-1_all.deb
sctplib1_1.3.1-1_i386.deb
  to pool/main/s/sctplib/sctplib1_1.3.1-1_i386.deb
sctplib_1.3.1-1.diff.gz
  to pool/main/s/sctplib/sctplib_1.3.1-1.diff.gz
sctplib_1.3.1-1.dsc
  to pool/main/s/sctplib/sctplib_1.3.1-1.dsc
sctplib_1.3.1.orig.tar.gz
  to pool/main/s/sctplib/sctplib_1.3.1.orig.tar.gz


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

Accepted socketapi 1.3.1-5 (i386 source)

2005-02-18 Thread Anibal Monsalve Salazar

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Sat, 19 Feb 2005 00:59:24 +1100
Source: socketapi
Binary: socketapi1 socketapi-dev
Architecture: source i386
Version: 1.3.1-5
Distribution: unstable
Urgency: low
Maintainer: Anibal Monsalve Salazar [EMAIL PROTECTED]
Changed-By: Anibal Monsalve Salazar [EMAIL PROTECTED]
Description: 
 socketapi-dev - development package for socketapi1
 socketapi1 - socket API library for sctplib
Closes: 268600
Changes: 
 socketapi (1.3.1-5) unstable; urgency=low
 .
   * Removed Build-Depends on build-essential libstdc++-dev (Closes: #268600).
Files: 
 cc3b864907f604504a09ecceda397925 632 libs optional socketapi_1.3.1-5.dsc
 bd5661df4a4037b85b59c3ba0220e38e 2813 libs optional socketapi_1.3.1-5.diff.gz
 c594b7d19a3d6276e889de2640f84441 137732 libs optional 
socketapi1_1.3.1-5_i386.deb
 acf1dfa495f9d797d00b0edca0adfea7 186370 libdevel optional 
socketapi-dev_1.3.1-5_i386.deb

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

iD8DBQFCFfibgY5NIXPNpFURAm4PAJ4q+AjIj9L1lq6dj50TDQrAUV0mBACeLAV0
hAt6T3j97ItyH3v77FGuqso=
=ljg8
-END PGP SIGNATURE-


Accepted:
socketapi-dev_1.3.1-5_i386.deb
  to pool/main/s/socketapi/socketapi-dev_1.3.1-5_i386.deb
socketapi1_1.3.1-5_i386.deb
  to pool/main/s/socketapi/socketapi1_1.3.1-5_i386.deb
socketapi_1.3.1-5.diff.gz
  to pool/main/s/socketapi/socketapi_1.3.1-5.diff.gz
socketapi_1.3.1-5.dsc
  to pool/main/s/socketapi/socketapi_1.3.1-5.dsc


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

Accepted memcached 1.1.11-3 (i386 source)

2005-02-18 Thread Jay Bonci

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 09:11:55 -0500
Source: memcached
Binary: memcached
Architecture: source i386
Version: 1.1.11-3
Distribution: unstable
Urgency: low
Maintainer: Jay Bonci [EMAIL PROTECTED]
Changed-By: Jay Bonci [EMAIL PROTECTED]
Description: 
 memcached  - A high-performance memory object caching system
Changes: 
 memcached (1.1.11-3) unstable; urgency=low
 .
   * Rebuild against non-broken libevent
Files: 
 45e6d5822fb24abb8436c0006a1c70fc 586 web optional memcached_1.1.11-3.dsc
 d4e9922e7f396c3c586a1a1df3b663de 4563 web optional memcached_1.1.11-3.diff.gz
 1b499be6554b07b79626df457d2fc853 31778 web optional memcached_1.1.11-3_i386.deb

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

iD8DBQFCFfoOZNh5D+C4st4RAmudAJwILd7a14t6gZyBW1ckfKS0UTRcygCeOtgP
0sLiFpOy+PXlehZhd+m8VvE=
=YNga
-END PGP SIGNATURE-


Accepted:
memcached_1.1.11-3.diff.gz
  to pool/main/m/memcached/memcached_1.1.11-3.diff.gz
memcached_1.1.11-3.dsc
  to pool/main/m/memcached/memcached_1.1.11-3.dsc
memcached_1.1.11-3_i386.deb
  to pool/main/m/memcached/memcached_1.1.11-3_i386.deb


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

Accepted check 0.9.2-3 (i386 source)

2005-02-18 Thread Robert Lemmen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 15 Feb 2005 16:11:59 +0100
Source: check
Binary: check
Architecture: source i386
Version: 0.9.2-3
Distribution: unstable
Urgency: low
Maintainer: Robert Lemmen [EMAIL PROTECTED]
Changed-By: Robert Lemmen [EMAIL PROTECTED]
Description: 
 check  - unit test framework for C
Closes: 187986 261420 288213
Changes: 
 check (0.9.2-3) unstable; urgency=low
 .
   * fixed some problems with upstream files in debian/
 .
 check (0.9.2-2) unstable; urgency=low
 .
   * fixed FTBFS error when trying to copy the example data
 .
 check (0.9.2-1) unstable; urgency=low
 .
   * New upstream release (Closes: #261420)
   * Took over maintenance (Closes: #288213)
   * Updated to new policy version
   * Fixed copyright files (Closes: #187986)
   * General cleanups in debian/
   * Added watch file
Files: 
 1b7d3728e6b6a6747117fa5608d6b382 559 devel optional check_0.9.2-3.dsc
 9a4d5665b8be07513f5ac4e6eec537e6 161604 devel optional check_0.9.2.orig.tar.gz
 99b15d3032aa27e9fde2e9cfac34c091 5020 devel optional check_0.9.2-3.diff.gz
 15ac8ff37056709cc0b1265de090c4ad 55498 devel optional check_0.9.2-3_i386.deb

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

iD8DBQFCFgbR5UTeB5t8Mo0RAkYNAKCtW6YzNS2neSUc4M06cTVCOXIaJACeIi1C
uXChbVoHdjUmGPjAIWyCAUc=
=lgxt
-END PGP SIGNATURE-


Accepted:
check_0.9.2-3.diff.gz
  to pool/main/c/check/check_0.9.2-3.diff.gz
check_0.9.2-3.dsc
  to pool/main/c/check/check_0.9.2-3.dsc
check_0.9.2-3_i386.deb
  to pool/main/c/check/check_0.9.2-3_i386.deb
check_0.9.2.orig.tar.gz
  to pool/main/c/check/check_0.9.2.orig.tar.gz


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

Accepted gjdoc 0.7.0+cvs20050217-1 (all source)

2005-02-18 Thread Michael Koch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 17 Feb 2005 16:55:10 -0600
Source: gjdoc
Binary: gjdoc
Architecture: source all
Version: 0.7.0+cvs20050217-1
Distribution: unstable
Urgency: low
Maintainer: Debian Java Maintainers [EMAIL PROTECTED]
Changed-By: Michael Koch [EMAIL PROTECTED]
Description: 
 gjdoc  - free drop-in replacement for Sun's javadoc written in java
Changes: 
 gjdoc (0.7.0+cvs20050217-1) unstable; urgency=low
 .
   * New upstream release
   * Use CDBS and kaffe for building.
   * Fixed Build-Depends.
   * debian/control: Made short description start with a lower letter.
 Updated Standards-Version.
   * debian/README.Debian: Removed.
Files: 
 4610bde444f4e1b2b8bd505aa936a8be 850 devel optional 
gjdoc_0.7.0+cvs20050217-1.dsc
 851189b7a8f1f2f31e0f18a647e17747 702263 devel optional 
gjdoc_0.7.0+cvs20050217.orig.tar.gz
 4d9f6c3c8c5dbbbfb6fac677f986f576 32419 devel optional 
gjdoc_0.7.0+cvs20050217-1.diff.gz
 6ae6761d5dc78094cf43d0723ab6372b 424952 devel optional 
gjdoc_0.7.0+cvs20050217-1_all.deb

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

iD8DBQFCFg+J4vzFZu62tMIRAhROAKCZ4kIH+L0g+oxUJmgpVLQtr5xg3gCeI93r
FoG9AUanG8ZBDyeDoS+mKag=
=lc9x
-END PGP SIGNATURE-


Accepted:
gjdoc_0.7.0+cvs20050217-1.diff.gz
  to pool/main/g/gjdoc/gjdoc_0.7.0+cvs20050217-1.diff.gz
gjdoc_0.7.0+cvs20050217-1.dsc
  to pool/main/g/gjdoc/gjdoc_0.7.0+cvs20050217-1.dsc
gjdoc_0.7.0+cvs20050217-1_all.deb
  to pool/main/g/gjdoc/gjdoc_0.7.0+cvs20050217-1_all.deb
gjdoc_0.7.0+cvs20050217.orig.tar.gz
  to pool/main/g/gjdoc/gjdoc_0.7.0+cvs20050217.orig.tar.gz


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

Accepted php-imlib 0.4-2 (i386 source)

2005-02-18 Thread Steve Langasek

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 17 Feb 2005 17:01:49 -0800
Source: php-imlib
Binary: php-imlib
Architecture: source i386
Version: 0.4-2
Distribution: unstable
Urgency: low
Maintainer: Steve Langasek [EMAIL PROTECTED]
Changed-By: Steve Langasek [EMAIL PROTECTED]
Description: 
 php-imlib  - PHP Imlib2 Extension
Changes: 
 php-imlib (0.4-2) unstable; urgency=low
 .
   * Fix buggy version comparison in php-imlib.config.
   * Do explicit path checking for X, which is a good idea in general and
 works around current buildd breakage.
Files: 
 ebc49fb763c7a5ea071fb9ca27e3e10d 591 web optional php-imlib_0.4-2.dsc
 bd389e5aff8663d36c4e1fb5db1d0c77 9567 web optional php-imlib_0.4-2.diff.gz
 fc90c73a383a353eae2c98037c8ef3f5 33324 web optional php-imlib_0.4-2_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCFg3cKN6ufymYLloRAsvXAJ98gnsq+J6ImcSzBs13yDbJYUmBHwCdHuJI
uP7GOw1odJCl+Wm7gOZpFQ0=
=oQkZ
-END PGP SIGNATURE-


Accepted:
php-imlib_0.4-2.diff.gz
  to pool/main/p/php-imlib/php-imlib_0.4-2.diff.gz
php-imlib_0.4-2.dsc
  to pool/main/p/php-imlib/php-imlib_0.4-2.dsc
php-imlib_0.4-2_i386.deb
  to pool/main/p/php-imlib/php-imlib_0.4-2_i386.deb


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

Accepted libgnetwork 0.0.9-1 (i386 source)

2005-02-18 Thread Jordi Mallach

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Fri, 18 Feb 2005 14:28:24 +0100
Source: libgnetwork
Binary: libgnetwork1.0-0 libgnetwork1.0-dev
Architecture: source i386
Version: 0.0.9-1
Distribution: unstable
Urgency: low
Maintainer: Jordi Mallach [EMAIL PROTECTED]
Changed-By: Jordi Mallach [EMAIL PROTECTED]
Description: 
 libgnetwork1.0-0 - networking wrapper library using Glib/GObject
 libgnetwork1.0-dev - networking wrapper library using Glib/GObject 
(development files)
Closes: 292911
Changes: 
 libgnetwork (0.0.9-1) unstable; urgency=low
 .
   * New upstream release (really closes: #292911).
Files: 
 8000393c9a4c20fa4a1aa00f1351bc27 1521 libs optional libgnetwork_0.0.9-1.dsc
 f86c66cc76d60c16ecc13ee0e34d4277 754865 libs optional 
libgnetwork_0.0.9.orig.tar.gz
 b5a757823436585452faa0c8e09d04de 2812 libs optional libgnetwork_0.0.9-1.diff.gz
 c81b4c52706b41b97f255046dbbdf15a 159812 libdevel optional 
libgnetwork1.0-dev_0.0.9-1_i386.deb
 b6b590cfc5c7f7e5ecd6f9d927252407 155532 libs optional 
libgnetwork1.0-0_0.0.9-1_i386.deb

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

iD8DBQFCFhVPJYSUupF6Il4RAov4AKDD9C7TRznSHxYHQDBLJQxFPydk2ACgvjQX
dFW4zGXNQqKSefojdpOecPQ=
=lszs
-END PGP SIGNATURE-


Accepted:
libgnetwork1.0-0_0.0.9-1_i386.deb
  to pool/main/libg/libgnetwork/libgnetwork1.0-0_0.0.9-1_i386.deb
libgnetwork1.0-dev_0.0.9-1_i386.deb
  to pool/main/libg/libgnetwork/libgnetwork1.0-dev_0.0.9-1_i386.deb
libgnetwork_0.0.9-1.diff.gz
  to pool/main/libg/libgnetwork/libgnetwork_0.0.9-1.diff.gz
libgnetwork_0.0.9-1.dsc
  to pool/main/libg/libgnetwork/libgnetwork_0.0.9-1.dsc
libgnetwork_0.0.9.orig.tar.gz
  to pool/main/libg/libgnetwork/libgnetwork_0.0.9.orig.tar.gz


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

Accepted exim4 4.50-1 (i386 source all)