Re: the ongoing xfree86 buildd saga

[Kevin Mark]

On Wed, Feb 23, 2005 at 12:35:50PM -0800, Thomas Bushnell BSG wrote:
> Ingo Juergensmann <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Feb 23, 2005 at 12:13:42PM -0800, Thomas Bushnell BSG wrote:
> > 
> > > Do the buildd people read this list?  How do we get this cleaned up?
> > 
> > As far as I can tell you: the m68k buildd people will have noticed that
> > problem much earlier than you. 
> > 
> > Furthermore, I don't know if that's a problem of the m68k folks, but of that
> > XF86 build... there are messages out there that this build (at least on
> > i386) is not stripped. No wonder it is way larger than the normal build. 
> > 
> > But yes, it's "in" these days to public shout about those slow archs...
> > *SIGH*
> 
> I'm not complaining about the slow archs, and the m68k buildd failure
> will surely be noticed.  It has not, however, been retried.  Why?
> 
> I'm asking for *information*.  How do I find out what the plans are?  
> 
> What about the mips and sparc failures?  The buildd logs look like
> FTBFS, even though that's not right; do they read this list?  How does
> one find out?  How does one say: "this is blocking my package, can you
> give me an estimate on how long it will take?"
> 
> I'm not trying to grind an axe or complain, I'm seeking information
> and to move the process along expeditiously because it's blocking a
> lot more than just an xfree86 upgrade.
> 
Hi Thomas,
it seems odd that the machines that build the packages for the countless
hordes have no current way to reach them.  If a compromise occured on
one of these, how would anyone know? How could they be reached? If all
buildd's are now DD, shouldn't they be reachable?
cordially,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!

(__)
(oo)
  /--\/
 / |||
*  /\---/\
   ~~   ~~
"Have you mooed today?"...


signature.asc
Description: Digital signature

Bug#296714: ITP: freepop -- game inspired by the classic Populous series

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs <[EMAIL PROTECTED]>


* Package name: freepop
  Version : 0.6.0
  Upstream Author : Brendon Higgins <[EMAIL PROTECTED]>
* URL : http://freepop.sf.net/
* License : GPL
  Description : game inspired by the classic Populous series

 FreePop is a multi-platform tile-based game based on the great old game
Populous 2 by Bullfrog Productions Ltd., but much improved.

 Hope you'll like it. It requires the clanlib0.7 packages currently
stuck in NEW[1], so don't expect the upload too soon. I'll put them up
on my own webpage at  for the
meantime when I'm ready with packages available for testing. I'm
stumbled into a compile problem though yesterday which I have to address
with upstream first.

 So long,
Alfie
[1] But also available at 
-- 
 You never learn anything  |   /"\  ,'~~.
   by doing it right.  |  / chaos \  http://alfie.ist.org   |o ?~\
   -- unknown  |  \inside!/  mailto:[EMAIL PROTECTED]  /_   ~<\
   |   \_/  \__,~ \>


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

Bug#296742: ITP: aspell-de-alt -- German dictionary for aspell (old spelling)

[Christoph Berg]

Package: wnpp
Severity: wishlist


* Package name: aspell-de-alt
  Version : 2.1-1
  Upstream Author : Kevin Atkinson <[EMAIL PROTECTED]>
Heinz Knutzen 
Björn Jacke 
* URL : ftp://ftp.gnu.org/gnu/aspell/dict/de/
* License : GPL v2
  Description : German dictionary for aspell (old spelling)

This is the German - Old Spelling dictionary for Aspell.  It requires
Aspell version 0.60 or better.


Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: the ongoing xfree86 buildd saga

[Goswin von Brederlow]

Adeodato Simó <[EMAIL PROTECTED]> writes:

> * Thomas Bushnell BSG [Wed, 23 Feb 2005 17:10:57 -0800]:
>
>> ONCE IT'S CLEANED UP, what should I do to get the package rebuilt?
>> Seems to me, I should requeue it.  Nothing else is an advertised or
>> reliable way.  Even the @buildd.debian.org I'm now told is not
>> reliable.
>
>   Thomas, just apply your best judgement, taking into account two
>   factors, mostly: number of affected arches, and 'heaviness' of your
>   package perhaps. If, e.g., at least half of the arches would need
>   manual intervention, probably re-uploading is ok.

If the package has failed (wanna-build state failed) before the buildd
will not build it again but mail the admin asking if it should or not.

If the package is still in state building a new upload will rebuild
automatically.

So a reupload might not do anything but anoy the admin. Check for
that.

MfG
Goswin


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

Re: amd64 is already the 2nd most important arch

[Goswin von Brederlow]

Joel Aelwyn <[EMAIL PROTECTED]> writes:

> But that's OK. Our amd64 users just use the Alioth site instead of our
> wonderful mirror network, and track it as unstable. I mean, it's so much
> more effective to have it all hitting alioth for download, right? Thought
> so.

Amd64 actualy has 14+ mirrors including some primary/country mirrors
like ftp.de.debian.org.

What now actualy happens is that by protecting some undersized debian
mirror somewhere double the load is put on other mirrors since now
they have 2 debian source archives to mirror.

> People will (often) do it the right way if it's convenient, but if it
> serves a use to them, they *will* do it, right way or not. We support amd64
> officially, or we support it unofficially and in a thoroughly half-assed
> manner, but it's what some number of developers and users care about, so we
> WILL end up supporting it (or rather, we ARE supporting it). The question
> is only 'how well?'.

It would be nice if the sarge security team would embrace
amd64. Debian has amd64 systems they can use as security buildd and
adding amd64 to security.debian.org when sarge becomes stable should
not cost overly much space. Would be better than an outside team
tracking debian DSAs and providing fixes always after the fact.

MfG
Goswin


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

Re: the ongoing xfree86 buildd saga

[Goswin von Brederlow]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> Screwing up in the postrm of a package in Build-Depends is about the
>> worst you can do to the current buildd. It is pretty sure to cripple
>> them all. The inability of buildds to rebuild their chroots from
>> scratch doesn't help. Shit happens, stop whining and improve the
>> buildd. You are welcome to join the alioth project.
>
> I'm not whining, I was looking for *information*.  Despite many people
> pretending to give information, only one person in this thread has
> said, "oh, mail here".
>
> Thomas

I saw the "mail here" message so why should I repeat it? And I'm not
giving you information about what is going on (since that is
impossible and even [EMAIL PROTECTED] will not give you any I
suspect), I'm giving you information how to prevent it from hapening
again.

You are complaining, like so many before you, about no
information. Part of the multibuild design is/was to make more
information available automatically and to share responcibilities
between many people when the one person fails to act.

Since trying to change certain people to be more responcive has failed
over and over during the last years changing the software to
circumvent such shortcomming intelligently should be tried instead.

MfG
Goswin


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

Does this break binary compatability on 64bit architectures?

[Nikita V. Youshchenko]

Hello.

Upstream of a library package that I maintain changed function prototypes 
in the followinf way:

>
> -int mailpop3_retr(mailpop3 * f, uint32_t index, char ** result,
> +int mailpop3_retr(mailpop3 * f, unsigned int index, char ** result,
>  size_t * result_len);

That is, 'uint32_t' was changed to 'unsigned int'.

Does this break binary compatability on any of debian architectures (so 
soname change is needed)?


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

Re: Does this break binary compatability on 64bit architectures?

[Falk Hueffner]

"Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes:

>> -int mailpop3_retr(mailpop3 * f, uint32_t index, char ** result,
>> +int mailpop3_retr(mailpop3 * f, unsigned int index, char ** result,
>>  size_t * result_len);
>
> That is, 'uint32_t' was changed to 'unsigned int'.
>
> Does this break binary compatability on any of debian architectures (so 
> soname change is needed)?

No.

-- 
Falk


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

ITP: ctapi-cyberjack-2.0.5mp - REINER SCT cyberJack pinpad/e-com USB chipcard reader driver

[Alexander List]

Hello folks,
I just filed the following ITP intended to resolve Bug #203976.
---cut here---
Package: ctapi-cyberjack
Version: 2.0.5mp
Short desription:
REINER SCT cyberJack pinpad/e-com USB chipcard reader driver
Long description:
  This driver for the REINER SCT cyberJack pinpad/e-com USB
  family of chipcard readers implements the CT-API 1.1
  interface.
  Depending on your particular device, the driver either
  consists of a kernel and userspace part, or is implemented
  completely in userspace.
  The following table provides an overview about the current
  situatiion:
   Product  ProductID Kernel Userspace
  REINER SCT cyberJack pinpad USB   0x100 yesold
  REINER SCT cyberJack e-com USB0x100 yesold
  REINER SCT cyberJack pinpad_a USB 0x300 no new
  For more information about the smart card reader itself please
  visit http://www.reiner-sct.com/. There is also a shop where
  the the readers can be ordered online.

Original authors:
Matthias Brüstle
Harald Welte
Copyright (c) 2004 REINER SCT GmbH
License: LGPL
Download location:
http://support.reiner-sct.de/downloads/LINUX/V2.0.5/ctapi-cyberjack-2.0.5mp.tar.bz2
Debian seems to be one of the few distributions without a packaged 
version of this driver. I intend to fix this :-).

REINER SCT mention that they're working on a Debian package in the 
README file. I contacted them about the package along with a dependency 
issue, but didn't get an answer on the packaging thing or a planned 
release date. As it's LGPL licensed, I think it makes sense to package 
it right away.

This library is needed for PKI applications using the CT-API[1] with the 
ReinerSCT USB card readers. I've successfully tested the lib with 
SecCommerce's SecSigner300 Java Applet[2], which is used by a large 
financial group here in Austria. In some cases, the applet commits 
suicide which will kill Firefox :-/. I'll debug this ASAP and ask 
SecCommerce to fix it. One of these cases is a running pcscd[3] - 
probably there's something wrong with the locking mechanism for the 
ttyUSBn port.

PKI is starting to fly here in Austria, as major banks, the postal 
service and other organizations are playing registration offices for a 
large certification service provider (A-Trust)[4]. Applications include 
of course all the bank transactions that were formerly using PINs and 
TANs (TransAktionsNummer, German for transaction code), signing e-mails, 
but also digital signatures that are legally binding according to the 
law.[5]

References (sorry, everything only available in German)
[1] http://www.tuvit.de/XS/c.000201/T3.CT-API/sprache.DE/SX/
[2] 
http://www.seccommerce.de/de/produkte/webcontrust/secsigner/secsigner.html
[3] http://packages.debian.org/testing/misc/pcscd
[4] http://www.a-trust.at/
[5] http://www.signatur.rtr.at/en/legal/sigg.html

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

Bug#296801: ITP: sblim-cmpi-params -- instrumentation providers for WBEM accessing kernel parameters

[Rafal Lewczuk]

Package: wnpp
Severity: wishlist

* Package name: sblim-cmpi-params
  Version : 1.2.3
  Upstream Author : Gareth S. Bestor <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/sblim
* License : Common Public License
  Description : instrumentation providers for WBEM accessing kernel 
parameters

This package contains a set of CIM providers (and according CIM class
definitions) allowing to manage kernel parameters (accessible via /proc fs).
 
To be able to use this package, you have to install CIMOM (for
example, owcimomd package) and some kind of WBEM client (for example,
sblim-wbemcli). 

CMPI is a standard for extending WBEM service (aka CIMOM) with capabilities
to manage some particular types of resources available in the local system.
  
WBEM stands for Web Based Enterprise Managment which is a set of standards
and technologies intended to manage various aspects of a computer systems
in standardized, object oriented manner. WBEM objects represent various
instances in the system (processes, network interfaces, partitions,
services etc.).

A bit older version of the package (1.2.0) is available at:
http://www.pronet.pl/~rlewczuk/debs/sblim-cmpi-params

All dependencies (those not in Debian) are also available on this site. 
Latest version will be available soon. 

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-ca9100
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) (ignored: LC_ALL set to 
pl_PL)


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

Bug#296803: ITP: sblim-cmpi-sysfs -- instrumentation providers for WBEM accessing sysfs device tree

[Rafal Lewczuk]

Package: wnpp
Severity: wishlist

* Package name: sblim-cmpi-sysfs
  Version : 1.1.7
  Upstream Author : Gareth S. Bestor <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/sblim
* License : Common Public License
  Description : instrumentation providers for WBEM accessing sysfs device 
tree

This package contains a set of CIM providers for accessing device parameters
exported via sysfs filesystem. It is possible to read and modify device
parameters, if applicable.

To be able to use this package, you have to install CIMOM (for
example, owcimomd package) and some kind of WBEM client (for example,
sblim-wbemcli).

CMPI is a standard for extending WBEM service (aka CIMOM) with capabilities
to manage some particular types of resources available in the local system.

WBEM stands for Web Based Enterprise Managment which is a set of standards
and technologies intended to manage various aspects of a computer systems
in standardized, object oriented manner. WBEM objects represent various
instances in the system (processes, network interfaces, partitions,
services, configuration settings etc.).

To get more information about WBEM standards, see http://www.dmtf.org

A bit older version of the package (1.2.0) is available at:
http://www.pronet.pl/~rlewczuk/debs/sblim-cmpi-sysfs

All dependencies (packages not in Debian) are also available on this site.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-ca9100
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) (ignored: LC_ALL set to 
pl_PL)


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

Re: the ongoing xfree86 buildd saga

[Blars Blarson]

In article <[EMAIL PROTECTED]> you write:
>On Wed, Feb 23, 2005 at 09:17:59PM +0100, Adeodato Simó wrote:
>> * Thomas Bushnell BSG [Wed, 23 Feb 2005 12:13:42 -0800]:
>> > Do the buildd people read this list?  How do we get this cleaned up?
>>   That's not relevant, really. What matters is if they read their logs,
>>   and they certainly do.
>Indeed. The logs you see on buildd.debian.org arrive there by mail; they
>are also sent to the buildd admin, because every build requires some
>manual action to be performed (signing the .changes file for a
>successful build, telling the autobuilder what to do with an
>unsuccessful build).

At least one buildd maintainer signs successfull builds but apparnetly
ignores failed ones.  After random intervals (usually several months)
all failed builds are requeued whether they should be or not.
Requesting a specific requeue works with a week or two delay at times.
I've been filing most of the ftbfs bugs for that architecture.

You may wish to see my question to the tecnical committe on this
matter.


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

Tips wanted for debugging and testing Debian

[Sascha Berkenkamp]

Hi,

I want to help the debian team and I also read  debian.org/devel ! So I
think I would like to help testing and debugging the debian system in
order to help to fix some bugs in some programs or debian sepcific
stuff. I'm not sure if I'm able to do this with mit taks but I'll try
and learn. 
I've never done something like this, and so I need some tips.
I don't know how to start! Do I need a second Debian Linux for testing
on my disk?
I use Debian unstable on my laptop, testing on my old PIII which runs
some server taks for my local net and a Debian stable on a Webserver. 
I prefer to work on my old PIII, but I don't want to destroy my running
Debian. Should I install Debian on a second partition or is there any
possibility to run one Debian (or twice... ) for debugging in a virtual
server, like bochs?

Thanks for your tips
Sascha

-- 
Diese E-Mails ist signiert um die Echtheit zu gewaehrleisten.
Weitere Informationen zum Verschluesseln und Signieren von E-Mails
finden Sie unter:
http://homepage.hs-bremen.de/~sabe


signature.asc
Description: Digital signature

Re: Does this break binary compatability on 64bit architectures?

[Kurt Roeckx]

On Thu, Feb 24, 2005 at 05:53:02PM +0300, Nikita V. Youshchenko wrote:
> Hello.
> 
> Upstream of a library package that I maintain changed function prototypes 
> in the followinf way:
> 
> >
> > -int mailpop3_retr(mailpop3 * f, uint32_t index, char ** result,
> > +int mailpop3_retr(mailpop3 * f, unsigned int index, char ** result,
> >  size_t * result_len);
> 
> That is, 'uint32_t' was changed to 'unsigned int'.
> 
> Does this break binary compatability on any of debian architectures (so 
> soname change is needed)?

Afaik, on all 64 bit arches in debian an int is still 32 bit.


Kurt


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

Re: Tips wanted for debugging and testing Debian

[Adam Majer]

Sascha Berkenkamp wrote:

>I use Debian unstable on my laptop, testing on my old PIII which runs
>some server taks for my local net and a Debian stable on a Webserver. 
>I prefer to work on my old PIII, but I don't want to destroy my running
>Debian. Should I install Debian on a second partition or is there any
>possibility to run one Debian (or twice... ) for debugging in a virtual
>server, like bochs?
>  
>

Read,

http://www.debian.org/doc/manuals/reference/ch-tips.en.html#s-chroot

You don't even need a second partition :)

- Adam



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

Re: Tips wanted for debugging and testing Debian

[Roberto C. Sanchez]

Quoting Sascha Berkenkamp <[EMAIL PROTECTED]>:

> Hi,
> 
> I want to help the debian team and I also read  debian.org/devel ! So I
> think I would like to help testing and debugging the debian system in
> order to help to fix some bugs in some programs or debian sepcific
> stuff. I'm not sure if I'm able to do this with mit taks but I'll try
> and learn. 
> I've never done something like this, and so I need some tips.
> I don't know how to start! Do I need a second Debian Linux for testing
> on my disk?
> I use Debian unstable on my laptop, testing on my old PIII which runs
> some server taks for my local net and a Debian stable on a Webserver. 
> I prefer to work on my old PIII, but I don't want to destroy my running
> Debian. Should I install Debian on a second partition or is there any
> possibility to run one Debian (or twice... ) for debugging in a virtual
> server, like bochs?

I found qemu much easier to setup and get running than bochs.  The bochs
documentation leaves something to be desired where the qemu documentation
is clear and concise.

-Roberto


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


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

Re: Tips wanted for debugging and testing Debian

[Wouter Verhelst]

On Thu, Feb 24, 2005 at 08:42:05PM +0100, Sascha Berkenkamp wrote:
> Hi,
> 
> I want to help the debian team and I also read  debian.org/devel ! So I
> think I would like to help testing and debugging the debian system in
> order to help to fix some bugs in some programs or debian sepcific
> stuff. I'm not sure if I'm able to do this with mit taks but I'll try
> and learn.
> I've never done something like this, and so I need some tips.
> I don't know how to start! Do I need a second Debian Linux for testing
> on my disk?

No. You can do that with your 'main' Debian installation. Helping out is
real simple: install the 'reportbug' package, and whenever you find
something that isn't quite right, use reportbug to report the bug.
Include as many information as you can in the bug, and be prepared to
answer any questions the maintainer may have. That's already a great
start.

If you want to take this one step further, actually trying to crash an
application in a reproducible way, or trying to narrow down a bug to a
specific set of actions can be really helpful as well; for instance, if
there's a bug that says something like 'If I run this application, it
sometimes segfaults when I close it', and you can narrow it down to 'if
you run it, and use this and this and that option and /then/ close it,
it will segfault', that's very nice.

You can browse our bug database at . A good way
to start is to search for any bugs in software you regularly use, and to
see if you can help out.

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

Bug#296810: ITP: owperlprovider -- another perl provider interface for OpenWBEM

[Rafal Lewczuk]

Package: wnpp
Severity: wishlist

* Package name: owperlprovider
  Version : 0.30
  Upstream Author : Jason Long <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/config4gnu
* License : GPL, Artistic
  Description : another perl provider interface for OpenWBEM

This is an OpenWBEM extension which lets you write OpenWBEM providers in
Perl. This is not the same as the Perl provider interface that is bundled
with OpenWBEM. This one is written directly for OpenWBEM and is using SWIG
to generate wrappers for the objects and classes. The Swig-generated code
provides an object-oriented way of accessing the CIM elements. It also
provides type-checking, so passing reference of wrong type will generate
error instead of crashing the CIMOM.

OpenWBEM is an WBEM standards compliant CIMOM server.

WBEM stands for Web Based Enterprise Managment which is a set of standards
and technologies intended to manage various aspects of a computer systems
in standardized, object oriented manner. WBEM objects represent various
instances in the system (processes, network interfaces, partitions,
services etc.).

Preliminary version of this package (still work-in-progress) is available at:
http://www.pronet.pl/~rlewczuk/debs/owperlprovider

All dependencies (packages not in Debian) are also available on this site.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-ca9100
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) (ignored: LC_ALL set to 
pl_PL)


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

Re: Would like to remove blas/lapack/atlas2/lapack99 at some point

[Camm Maguire]

Hi Kevin!  Of course, post-Sarge is just fine!  Please excuse me if I
implied otherwise.  You and I have already coordinated on this.  If
memory serves, libmathlib1 is not the only issue.  mpqc, ghemical, and
tela are there too.  I'm checking the BTS, and can't find the
analogous wishlist bugs against these which I thought I had filed at
the same time.  I guess my post boiled down to whether it would be
appropriate to NMU a blas/lapack upgrade on these, after of course
ensuring that sufficient time passes after the maintainer is
contacted.  Or perhaps the best way is to, just after sarge, remove
the packages and allow nature to take its course?  How much time is
left for Sarge anyway?  I've already received more bug reports on
these packages than I had anticipated could arrive pre-sarge.  I
suppose it is worth fixing them?

Thanks so much for your great work on supporting cernlib!

Take care,

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

> Camm Maguire wrote:
> 
> > Greetings!  The older versions were kept to ease the transition into a
> > minor API change, and to work around earlier gcc-induced tester
> > failures.  There are just a few packages using the older API now.
> > I've filed wishlist bugs with those requesting an upgrade about 100
> > days ago.  How should we proceed now?  Maintaining both sets is
> > becoming more burdensome.
> 
> Hi Camm,
> 
> When we exchanged emails a while ago after your wishlist bug against
> libmathlib1, I think you were intending to have the old blas/lapack/etc.
> removed only after the release of Sarge.  Is that still the case?
> 
> It would make things difficult for me if blas/lapack/atlas2 disappeared
> now, since I would have to bump sonames on most of Cernlib, change
> library package names, and somehow get the new binary packages through
> NEW and into testing before the release.  After Sarge, I have no objections.
> 
> As far as I'm concerned you can have lapack99 removed right now, since
> it's not just one, but two sonames behind the current version.
> 
> regards,
> 
> -- 
> Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
> WWW: http://www.princeton.edu/~kmccarty/Princeton University
> GPG public key ID: 4F83C751 Princeton, NJ 08544
> 
> 
> 

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


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

Become a homeowner with low rates

[Approved mortage]

Hello,
We tried contacting you a while ago about your low interest mort age rate.
You have qualified for the lowest rate in years.
You could get over $380,000 for as little as $500 a month!
Ba(d credit? Doesn't matter, low rates are fixed no matter what!

To get a free, no obli,gation consultation check Here:
http://www.nfrj384.com/m0rt.asp

Best Regards,
Morgan Haskins
http://www.nfrj384.com/m0rt.asp



no more
http://www.rgeg546.com/gone.asp

Re: Tips wanted for debugging and testing Debian

[Michael Tautschnig]

Hi!
[...]
If you want to take this one step further, actually trying to crash an
application in a reproducible way, or trying to narrow down a bug to a
specific set of actions can be really helpful as well; for instance, if
there's a bug that says something like 'If I run this application, it
sometimes segfaults when I close it', and you can narrow it down to 'if
you run it, and use this and this and that option and /then/ close it,
it will segfault', that's very nice.
You can browse our bug database at . A good way
to start is to search for any bugs in software you regularly use, and to
see if you can help out.
But what could one do, if the maintainer doesn't react (for some time) - 
such that even bugreport with fixes provided are never acted upon?

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

Re: mplayer, the time has come

[Sebastien NOEL]

Hi,

I have some questions about your package:

*   You removed libmpdvdkit2/ because US laws suck.
Why don't you remove also libfaad2/ which is full of patents problems ?
(according to /usr/share/doc/ffmpeg/patents.txt.gz)

*   Why the "--disable-mencoder" in debian/rules ? 

*   Why the "--disable-aa" ?
Ok caca is better than aa but it's not enabled either.

*   You build libavcodec and libavformat but that seems to me a waste of time.
FFmpeg is already in main, why not only link mplayer with
libavcodec.a (libavcodec-dev) and libavformat.a (libavformat-dev) ?


Qestion to all DD:
Without decss, faad, lame & xvid, mplayer insn't really mplayer.
Why debian doesn't have a semi-official structure similar to PLF ?
(Maybe it's time to resurrect non-us)


Regards,


Sebastien NOEL


pgpB8vjnVAinb.pgp
Description: PGP signature

Re: svn.debian.org: Automatically putting log message into debian/changelog?

[Joey Hess]

Roland Bauerschmidt wrote:
> I have thought about that before. However, I meant to implement it this
> way: Parse debian/changelog locally, and use new entries as default for
> Subversion's changelog. It would prevent debian/changelog to be
> cluttered with entries such as "forgot to add file foo last time; really
> add it now". (Yes, you could also clean debian/changelog up before
> uploading.)

I've done this for years using the attached script (which will work with
both svn and cvs (less well), and can also tag releases).

-- 
see shy jo
#!/bin/sh -e
# Commit changes, using the current changelog as the message.
# If $1 is "release", the package is also tagged for release.

if [ -d CVS ]; then
PROG=cvs
elif [ -d .svn ]; then
PROG=svn 
else
echo "not in a cvs or subversion directory" >&2
exit 1
fi
echo "Committing with $PROG ..."

if [ "$1" = "release" ] && [ -e debian/changelog ]; then
if head -1 debian/changelog | grep -q UNRELEASED; then
echo "Changelog says it's UNRELEASED, bud."
exit 1
fi
version=`dpkg-parsechangelog | grep Version: | cut -f 2 -d ' '`

$PROG commit -m "releasing version $version"
elif [ "$PROG" = svn ]; then
# use new part of changelog as commit entry
MSG=$(svn diff debian/changelog | grep '^\+  ' | sed 's/^+//')
if [ -n "$MSG" ]; then
$PROG commit -m "$(svn diff debian/changelog | grep '^\+  ' | 
sed 's/^+//')"
else
$PROG commit -m "`dpkg-parsechangelog | grep '^  '`"
fi
else
# cvs is too slow for that
$PROG commit -m "`dpkg-parsechangelog | grep '^  '`"
fi

if [ "$1" = "release" ]; then
# Generate the tag. This is compatable with the tag cvs-buildpackage
# uses except for debian native packages.
newversion=`expr $version : '[0-9]:\(.*\)'` 2>/dev/null || true
if [ "$newversion" ]; then
version=$newversion
fi
if [ -d CVS ]; then
# escape tag for cvs
if [ "`expr $version : '.*-.*'`" -gt 0 ]; then
tag="debian_version_$version"
else
tag="version_$version"
fi
tag=`echo "$tag" | tr . _`
cvs tag -f $tag
elif [ -d .svn ]; then
tag="$version"
echo "svn copy $(svnpath) $(svnpath tags)/$tag"
if ! svn copy $(svnpath) $(svnpath tags)/$tag -m "tagging 
version $version"; then
echo "svn mkdir $(svnpath tags)"
svn mkdir "$(svnpath tags)" -m "create tag subdirectory"
echo "svn copy $(svnpath) $(svnpath tags)/$tag"
svn copy $(svnpath) $(svnpath tags)/$tag -m "tagging 
version $version"
fi
fi
fi


signature.asc
Description: Digital signature

Re: Does this break binary compatability on 64bit architectures?

[Ron Johnson]

On Thu, 2005-02-24 at 20:52 +0100, Kurt Roeckx wrote: 
> On Thu, Feb 24, 2005 at 05:53:02PM +0300, Nikita V. Youshchenko wrote:
> > Hello.
> > 
> > Upstream of a library package that I maintain changed function prototypes 
> > in the followinf way:
> > 
> > >
> > > -int mailpop3_retr(mailpop3 * f, uint32_t index, char ** result,
> > > +int mailpop3_retr(mailpop3 * f, unsigned int index, char ** result,
> > >  size_t * result_len);
> > 
> > That is, 'uint32_t' was changed to 'unsigned int'.
> > 
> > Does this break binary compatability on any of debian architectures (so 
> > soname change is needed)?
> 
> Afaik, on all 64 bit arches in debian an int is still 32 bit.

Just out of curiosity, why would upstream change a library fun from
uint32_t, which will *always* be 32 bits, to int, which may or may 
not be 32 bits, depending on the arch and compiler?

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

$ python -c 'print len(str(2**300))'
903090



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

Re: the ongoing xfree86 buildd saga

[Steve Langasek]

On Wed, Feb 23, 2005 at 05:10:57PM -0800, Thomas Bushnell BSG wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:

> > On Wed, Feb 23, 2005 at 12:41:46PM -0800, Thomas Bushnell BSG wrote:
> > > Wouter Verhelst <[EMAIL PROTECTED]> writes:
> > > > That won't help, especially not in this case. Those who manage the
> > > > autobuilder are best suited to know when the autobuilder will be fixed,
> > > > since they are the ones who have to clean up...
> > > 
> > > What I'm saying is that once it's cleaned up, I have two options:
> > > 
> > > * ask for my package to be requeued;
> > > * do another upload.
> > > 
> > > And I'm almost certain that the latter option is faster, and that the
> > > former option will have an unpredictable delay of up to a week.
> > 
> > What I'm saying is that the delay is likely in cleaning up, not
> > necessarily in requeueing. Hence, your upload will likely break again,
> > in exactly the same way it did before.

> Once it's cleaned up.  Let me repeat.  ONCE IT'S CLEANED UP.

> There are two delays.  One is the delay waiting for it to be cleaned
> up.  The other is the delay waiting for the package to be rebuilt.

> I'm talking about the *second* delay.

> ONCE IT'S CLEANED UP, what should I do to get the package rebuilt?
> Seems to me, I should requeue it.  Nothing else is an advertised or
> reliable way.  Even the @buildd.debian.org I'm now told is not
> reliable.

I don't think it would hurt if maintainers whose packages are in this state
would email the relevant @buildd.debian.org addresses and cc:
debian-release on the message -- now, rather than waiting for the buildds to
be fixed.  Hopefully, this would save the buildd maintainers the trouble of
having to look through all the build logs to find the ones related to this
breakage, and they can requeue them as a batch.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

New Drug store Earnestine

[Weldon Weiss]

Refill Notification Ref: IT-94343548

Dear debian-i18n@lists.debian.org,

Our automated system has identified that you most likely are ready to refill 
your recent online pharmaceutical order.

To help you get your needed supply, we have sent this reminder notice.

Please use the refill system http://cecropia.discounthavenshop.com/?wid=100069 
to obtain your item in the quickest possible manner.

Thank you for your time and we look forward to assisting you.

Sincerely,

Weldon Weiss




botanic gs ripoff fi portfolio ph petrochemical uia 
preferred vgu capillary nf adverbial awx elgin wtw backwood asc brokerage tk 
chime mt christendom snw crosshatch dk dyeing duv 


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

Re: mplayer, the time has come

[Glenn Maynard]

On Thu, Feb 24, 2005 at 10:08:42PM +0100, Sebastien NOEL wrote:
> *   You removed libmpdvdkit2/ because US laws suck.
> Why don't you remove also libfaad2/ which is full of patents problems ?
> (according to /usr/share/doc/ffmpeg/patents.txt.gz)

I hope that isn't a file with descriptions of patents--anyone who reads
such a thing would risk increased patent liability.  I'd rather not look
for myself to find out, though.

That said, are the patents supposedly affecting libfaad2 actively being
enforced?  Debian's general policy on software patents is to ignore ones
which aren't, since that's the only policy that allows anyone to do
anything at all.

> *   Why the "--disable-mencoder" in debian/rules ? 
> 
> *   Why the "--disable-aa" ?
> Ok caca is better than aa but it's not enabled either.

libaa, the ASCII art library?  I'd hope that'd be disabled in the normal
build.  It's a useless novelty; I certainly wouldn't want to have to
install it to get a video player.  (Of course, if it can bind dynamically
at runtime, that's not an issue; I don't know if it does that.)

> (Maybe it's time to resurrect non-us)

I don't know how many times this can be said: non-us is *not a solution*
to patents affecting the US, and never has been.  AFAIK, non-us was an
archive that was uploaded to from outside the US, but could be freely and
legally used from inside the US--not an archive which was completely off-
limits to the US.

-- 
Glenn Maynard


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

Re: the ongoing xfree86 buildd saga

[Thomas Bushnell BSG]

Steve Langasek <[EMAIL PROTECTED]> writes:

> I don't think it would hurt if maintainers whose packages are in this state
> would email the relevant @buildd.debian.org addresses and cc:
> debian-release on the message -- now, rather than waiting for the buildds to
> be fixed.  Hopefully, this would save the buildd maintainers the trouble of
> having to look through all the build logs to find the ones related to this
> breakage, and they can requeue them as a batch.

So I've done this, but I am skeptical about how much it will help.

For example, if even *one* buildd maintainer doesn't requeue with some
kind of promptness, then the only way to deal with it will be to make
a new upload, which will force a recompile everywhere.


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

Re: ITP: ctapi-cyberjack-2.0.5mp - REINER SCT cyberJack pinpad/e-com USB chipcard reader driver

[Norbert Preining]

On Don, 24 Feb 2005, Alexander List wrote:
> Package: ctapi-cyberjack
> Version: 2.0.5mp

Hi Alex!

Good idea, but please send Reiner an email, I got 2.0.7 from them, so
don't start wiht a old version! If you need a contact email, ask me by
PM.

If you need test dummys, here I am. After I have returned from Japan I
can test the usb reader.

Best wishes

Norbert

---
Norbert Preining  Università di Siena
sip:[EMAIL PROTECTED] +43 (0) 59966-690018
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
WIKE (vb.)
To rip a piece of sticky plaster off your skin as fast as possible in
the hope that it will (a) show how brave you are, and (b) not hurt.
--- Douglas Adams, The Meaning of Liff


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

High-quality custom logos and business identities

[Terrell Slaughter]

Your business lacks visual identity?

Marketing efforts falling short?
Invisible among a sea of competitors?

You're on the right track for a solution - keep reading...
Our professional designers specialize in the creation of custom logos and 
business/corporate identities. Our design needs to be seen only once to gain 
customer attention and recognition. With one of our unique, eye-catching mages 
you'll never have to introduce yourself twice!
We promise fast turnaround and 100% cusotmer satisfaction. Choose from as any 
design ideas as necessary, select as many colors as you wish, order any 
modifications you like, and request any format. Our prcies are affordable for 
any size of business, and get this: there are no hidden fees.

Follow the link below to browse our portfolio and check out our Sweet Deals.
Wipe the "in" from "invisible" in just a few days - with us!

http://www.trylogos-llc.com/











---
crocodilian breakdown copywriter degum distribution accrual amort bicycle 
amalgamate bladderwort albuquerque 
calve colloquia affect botulism babysitter cowboy aristocrat 
chordate deign alexei dispersible counsel canine bateman baseband catastrophe 
addle 
decker acculturate blow clotho death banquet billion curia 


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

Re: the ongoing xfree86 buildd saga

[Ingo Juergensmann]

On Thu, Feb 24, 2005 at 08:44:04PM -0800, Thomas Bushnell BSG wrote:

> For example, if even *one* buildd maintainer doesn't requeue with some
> kind of promptness, then the only way to deal with it will be to make
> a new upload, which will force a recompile everywhere.

This is only valid on archs where there's only one buildd admin doing the
job. And then again, there might be other people with write access to the
wanna-build db. 

-- 
Ciao...  // 
  Ingo \X/


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