The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 222 (new: 12)
Total number of packages offered up for adoption: 107 (new: 9)
Total number of packages reques
"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes:
> On Fri, Jul 08, 2005 at 11:57:25AM +1000, Drew Parsons wrote:
> > I'm already seeing documentation referring to "Debian 3.2 (etch)". Is
> > this really what we want?
> >
> > I remember some of us belatedly suggested sarge should be Debian 4.0,
>
The aalib now in unstable has undergone a transition involving a library
package rename. As part of the slang2 upgrade, this new release of aalib
also improves the dependency situation, so packages that previously
inherited a dependency on slang1 via aalib will no longer have an
explcit dependency
Roberto C. Sanchez wrote:
> I was reading the kill man page today looking for some information for a
> script I am writing. The man page mentioned that some shells have a
> kill built-in command. On further investigation, I noticed that bash
> has this as a built-in.
>
> My questions are:
>
> *
On Fri, Jul 08, 2005 at 11:57:25AM +1000, Drew Parsons wrote:
> I'm already seeing documentation referring to "Debian 3.2 (etch)". Is
> this really what we want?
>
> I remember some of us belatedly suggested sarge should be Debian 4.0,
> though it was too late (May?) to accept that.
>
> I suppos
I'm already seeing documentation referring to "Debian 3.2 (etch)". Is
this really what we want?
I remember some of us belatedly suggested sarge should be Debian 4.0,
though it was too late (May?) to accept that.
I suppose we should decide now if etch is going to be 3.2 or 4.0.
Given the ABI cha
[I think you meant to sent this to -devel as well as just me
privately... I hope you don't mind me sending my response back to -devel]
[EMAIL PROTECTED] wrote:
> But is this possible ? If for instance I know that T will be double, int and a
> "custom" class, can I force the code for g, g and g to
I was reading the kill man page today looking for some information for a
script I am writing. The man page mentioned that some shells have a
kill built-in command. On further investigation, I noticed that bash
has this as a built-in.
My questions are:
* should I explicitly call /bin/kill?
* is
Hamish Moffatt wrote:
> Pierre Habouzit wrote:
> > I hope not ... I'm a quite happy owner of amd64 machines, so happy that
> > I've only amd64 machines for my desktops, and maintaining a chroot to
> > use openoffice is quite annoying (same is true for quake/et but I
> > assume it won't bother de
Body Wrap at Home to lose 6-20 inches in one hour.
With Bodywrap we guarantee:
you'll lose 6-8 Inches in one hour
100% Satisfaction or your money back
Bodywrap is soothing formula that contours,
cleanses and rejuvenates your body while
reducing inches.
http://mana.loseweightsystems.c
Lars Wirzenius writes:
> Not to belittle the fact that the project stumbled on security support,
> but the press certainly did not have to rely only on web log entries and
> postings to public mailing lists. They could have asked questions of
> people.
It doesn't matter what the _press_ should do.
I demand that Brian M. Carlson may or may not have written...
> On Thu, 2005-07-07 at 23:57 +0200, Juergen Salk wrote:
[snip]
>> void *thread_func(void *arg) {
>> sleep(3);
>> pthread_exit(0);
> You are also neglecting to return a value here. You must always return a
> value in a non-voi
to, 2005-07-07 kello 13:38 +0200, Thijs Kinkhorst kirjoitti:
> This sounds very after-the-facts to me: the press had to base its report
> on the statements that individuals make on mailinglists and blogs; what
> was needed was an official statement early, when it came appearent that
> there was a p
On Thu, Jul 07, 2005 at 10:03:09PM +0200, Pierre Habouzit wrote:
> Le Jeu 7 Juillet 2005 21:17, Josselin Mouette a écrit :
> > If we don't start the multiarch effort now, it won't be good for
> > etch. Are we postponing this to the next release?
>
> I hope not ... I'm a quite happy owner of amd64
On Fri, Jul 08, 2005 at 12:06:32AM +0200, Steinar H. Gunderson wrote:
> {static,dynamic,reinterpret}_cast are for pointers only.
Oops, I was wrong there, of course. You can use static_cast if you'd like.
For "simpler" types (ie. those with only one word) you can use
type(expression) as well, just
On Thu, 2005-07-07 at 23:57 +0200, Juergen Salk wrote:
> Hi,
>
> first of all: if this is not the appropriate list for this kind
> of question, please give me pointer to better one.
>
> I am having problems with rebuilding my dcmtk package with g++
> 4.0 on Sid. The problem seems to be related t
On Thu, Jul 07, 2005 at 11:57:23PM +0200, Juergen Salk wrote:
> dummy = reinterpret_cast (a_thread);
dummy = (unsigned long)(a_thread);
{static,dynamic,reinterpret}_cast are for pointers only.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Hi,
> >
> > I have two comments:
> >
> > 1. It's linking with openssl, and claiming to be LGPL, which
> > I understand to be incompatible.
>
> It is compatible.
Are you sure?
People were running around GPL is not compatible with
openssl license; and LGPL has a option to make the
code GPL.
Le vendredi 08 juillet 2005 à 06:46 +0900, Junichi Uekawa a écrit :
> > > 1. It's linking with openssl, and claiming to be LGPL, which
> > > I understand to be incompatible.
> >
> > It is compatible.
>
> Are you sure?
> People were running around GPL is not compatible with
> openssl license;
Hi,
first of all: if this is not the appropriate list for this kind
of question, please give me pointer to better one.
I am having problems with rebuilding my dcmtk package with g++
4.0 on Sid. The problem seems to be related to type casting
between pthread_t and unsigned long int types and vice
On Thu, Jul 07, 2005 at 06:45:13PM +0200, [EMAIL PROTECTED] wrote:
> > That is just plain wrong. :-) With templates, you are supposed to
> > provide the template implementation either in the header or in a file
> > included by the header (convention is to name them .tcc and place them
> > next to t
Le jeudi 07 juillet 2005 à 22:03 +0200, Pierre Habouzit a écrit :
> IMHO, either amd64/pure64/... will become a release arch and in that
> case we have to have a solution for multiarch, either amd64 is not a
> released arch .. and that bothers me.
The amd64 architecture is the least one affected
Le Jeu 7 Juillet 2005 21:17, Josselin Mouette a écrit :
> Le jeudi 07 juillet 2005 à 13:04 +0400, Nikita V. Youshchenko a
écrit :
> > Hello.
> >
> > Are multiarch ideas alive?
> > Do they have any future in Debian?
>
> I was going to ask the same question ;)
>
> If we don't start the multiarch eff
Loïc Minier writes:
> Hi,
>
> On Thu, Jul 07, 2005, Steve Langasek wrote:
> > > A package which I am about to sponsor (plotutils) has CFLAGS += -mieee
> > > for alpha. Does the above mean it is ok to remove that now?
> > * Apply revised patch to make -mieee the default on alpha-linux,
>
Le jeudi 07 juillet 2005 à 13:04 +0400, Nikita V. Youshchenko a écrit :
> Hello.
>
> Are multiarch ideas alive?
> Do they have any future in Debian?
I was going to ask the same question ;)
If we don't start the multiarch effort now, it won't be good for etch.
Are we postponing this to the next r
[EMAIL PROTECTED] wrote:
> g.h :
> template
> void g (T x);
>
> g.cc :
> template
> void g (T x) {
>cout << x;
> }
>
> The .h file has to include the .cc one in order for the compilation to work.
> That leads to a shared library that we'll call libg.so.1.0.0
> Let's say now that I compile
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Well I did say that : "The .h file has to include the .cc one in order for the
> compilation to work."
> Now if you decide to leave the code that I put into g.cc only the .h file, it
> works too...
The template class has to actually be included, and
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > That's almost certainly a terrible idea.
>
> I somehow expected that might come up. I didn't fell to comfortable with this
> idea, but I think there must be another solution than simply doing it "by
> hand",
> a more "elegant" way.
You can't rea
> That is just plain wrong. :-) With templates, you are supposed to
> provide the template implementation either in the header or in a file
> included by the header (convention is to name them .tcc and place them
> next to the header). The usual rule applies: Everything that does not
> generate cod
> That's almost certainly a terrible idea.
I somehow expected that might come up. I didn't fell to comfortable with this
idea, but I think there must be another solution than simply doing it "by hand",
a more "elegant" way.
> The SONAME needs to match across distributions so it really needs to be
> Is this shared library actually used by other programs? Or only
> within the internal use of this particular project? If the latter
> then I would avoid packaging it as a shared library at all. If the
> shared library is not used by other programs then I would covert the
> build to link the pr
* Alexis Papadopoulos ([EMAIL PROTECTED]) wrote:
> >>The thing is that the library is written in C++ and makes heavily use of
> >>templates which means that even a small change in the code, that doesn't
> >>change the ABI, might lead to incompatibility.
> >
> >There's no 'might' about it... Eith
On Thu, Jul 07, 2005 at 08:36:39AM +0900, Junichi Uekawa wrote :
>
> Hi,
>
> > > > Should the package name contain the version number? (like the libssl
> > > > packages)
> > >
> > > Yes, it should be called libssh-0.11-0.
> >
> > I'd rather call it libssh0.11 or libssh-0.11, since the -0 is the
Alexis Papadopoulos wrote:
> I'm actually making some .deb packages out of a single source archive.
> One of them should contain a shared library. The upstream author's
> package's version is 5.13 and the soname of his library has been set to
> 513. After having contacted him, he told me that wa
Joerg Friedrich <[EMAIL PROTECTED]> wrote:
>> Does anybody know whether there is a TeX font which is equal or at least
>> very similar to the font used in our Logo
>
> http://wiki.debian.net/?DebianLogo
It's actuall Poppl Laudatio *Condensed*. See the Berthold site for
more information on the fon
If that one person isn't willing to deal with it then that person
shouldn't be writing libraries. :)
Never said that...
I will take a look into debian-mentors, but I've just talked to the
upstream author and can now explain the reason of his choice.
Unfortunately that doesn't make
Florian Weimer <[EMAIL PROTECTED]> writes:
> On list servers, where most mail is outgoing? This would be really
> suprising.
Assume that the majority of the outgoing mail volume from a list
server depends on incoming mail to this list server.
If you reduce the incoming volume to this list serve
Ok, last mail:
searching the lists: the logo was created by Raul M. Silva.
http://www.debian.org/News/1999/19990826
Maybe you could ask him, if he can create a Debian-Med logo for you.
(http://www.silva.com / mailto:[EMAIL PROTECTED])
I try to put this information on wiki.debian.net, if I manage
Joerg Friedrich schrieb am Donnerstag, 07. Juli 2005 um 16:17:39 +0200:
> http://wiki.debian.net/?DebianLogo
> or google for "debian logo font" :
> first match was a msg from Alfi:
> http://lists.debian.org/debian-www/2003/08/msg00261.html
btw. the i-dot seems to be manually replaced by a (red) di
* Alexis Papadopoulos ([EMAIL PROTECTED]) wrote:
> >It's a single headache for the one library developer/packager, as
> >opposed to headaches for _every user_ of the library.
> >
> Yes indeed, but it's still a headache for one person ;).
If that one person isn't willing to deal with it then that
Andreas Tille schrieb am Donnerstag, 07. Juli 2005 um 15:46:20 +0200:
> Hi,
>
> it's surely off topic here but I don't know which is the relevant list ...
>
> Does anybody know whether there is a TeX font which is equal or at least
> very similar to the font used in our Logo
>
> http://www.
* Elie Rosenblum:
> On Fri, Jun 17, 2005 at 07:41:04AM +0200, Florian Weimer wrote:
>> * Wouter Verhelst:
>>
>> > What's painful about it?
>>
>> I wouldn't be surprised if it already increases load on
>> lists.debian.org significantly.
>
> Actually, in my experience on very heavily utilized mail
On Thu, 7 Jul 2005, Richard Atterer wrote:
Do you only need the Debian logo in your TeX document? Then a far more
promising plan is to embed the PostScript version of the logo as a picture.
No, as I said I want to have the String "Debian-Med" and I need the "M".
I could build the other letters
On Thu, Jul 07, 2005 at 03:46:20PM +0200, Andreas Tille wrote:
> Does anybody know whether there is a TeX font which is equal or at least
> very similar to the font used in our Logo
I've never seen a Debian-ish TeX font.
Do you only need the Debian logo in your TeX document? Then a far more
promi
* Wouter Verhelst:
>> > -- and relying on other people's security to increase your own isn't
>> > pretty clever, actually.
>>
>> Currently, it's the foundation of Internet security, I'm afraid.
>
> Well, then the 'foundation of Internet security' is very weak, I'm
> afraid.
It is.
> It's plain
Hi,
it's surely off topic here but I don't know which is the relevant list ...
Does anybody know whether there is a TeX font which is equal or at least
very similar to the font used in our Logo
http://www.debian.org/logos/ ?
I would need to scale the Debian text and add a "-Med" behind
It's a single headache for the one library developer/packager, as
opposed to headaches for _every user_ of the library.
Yes indeed, but it's still a headache for one person ;).
You might want to have a look at the debian-mentors archives, too. I believe
this sort of thing gets discussed th
On Thu, 2005-07-07 at 14:39 +0200, martin f krafft wrote:
> Sure. But I am talking about changes. Those are not made and then
> everyone is expected to abide by them. Instead, they are catalysed
> from common and proven strategies.
True enough. But read the statement of the fact that policy maint
also sprach Ian Campbell <[EMAIL PROTECTED]> [2005.07.07.1501 +0200]:
> I don't think that having policy be determined by existing practises and
> forcing maintainers to follow it are mutually exclusive.
>
> Once a strategy is common and proven it enters policy, at which point it
> becomes compuls
Kaspersky AV a découvert que le message
De: debian-devel@lists.debian.org
A: [EMAIL PROTECTED]
Copie :
Copie invisible :
Date : jeudi 7 juillet 2005
Heure : 13:42
Objet : test
contient des virus.
Vérifiez-le à l'aide de Kaspersky AV Scanner.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
On Thu, 2005-07-07 at 14:39 +0200, martin f krafft wrote:
> also sprach Michael Weyershäuser <[EMAIL PROTECTED]> [2005.07.07.1431 +0200]:
> > I guess you were refering to chapter 6 of the Developers Reference,
>
> No, I was refering to the policy.
>
> > "Best packaging practices", or something li
> Sory that you get the mail twice now, martin, I accidentally sent
> the first one to you instead of the list -.-
Here's my (also) personal reply:
also sprach Michael Weyershäuser <[EMAIL PROTECTED]> [2005.07.07.1431 +0200]:
> I guess you were refering to chapter 6 of the Developers Reference,
martin f krafft wrote:
>Uh, isn't the Debian policy a document for existing practices,
>rather than a vehicle to force maintainers down a certain road?
>
>
>
"Debian Policy Manual
Abstract
This manual describes the policy requirements for the Debian GNU/Linux
distribution. This includes th
also sprach Branden Robinson / Debian Project Leader <[EMAIL PROTECTED]>
[2005.07.07.0836 +0200]:
> The power of the maintainers of the Debian Policy Manual is
> substantial; they have the power to mandate standards of behavior
> for Debian packages, and a significant change to Debian Policy can
>
Hi,
On Thu, Jul 07, 2005, Steve Langasek wrote:
> > A package which I am about to sponsor (plotutils) has CFLAGS += -mieee
> > for alpha. Does the above mean it is ok to remove that now?
> * Apply revised patch to make -mieee the default on alpha-linux,
> and add -mieee-disable switc
On Thu, 7 Jul 2005, Steve Langasek wrote:
> On Thu, Jul 07, 2005 at 12:49:51PM +0200, Santiago Vila wrote:
> > On Tue, 5 Jul 2005, Matthias Klose wrote:
>
> > > * If you have workarounds to build with a specific gcc version on
> > > certain architectures, these should be removed. Also if th
On Thu, July 7, 2005 12:46, Andreas Barth wrote:
> * Kevin Mark ([EMAIL PROTECTED]) [050707 12:33]:
>> With the recent article from Zdnet, does Debian need a press officer or
>> www.debian.org/press? If harm is done to the reputation to the Debian
>> organization by word or deed, should there be so
On Thu, Jul 07, 2005 at 12:49:51PM +0200, Santiago Vila wrote:
> On Tue, 5 Jul 2005, Matthias Klose wrote:
> > * If you have workarounds to build with a specific gcc version on
> > certain architectures, these should be removed. Also if there are
> > specific optimization settings that h
On Tue, 5 Jul 2005, Matthias Klose wrote:
> * If you have workarounds to build with a specific gcc version on
> certain architectures, these should be removed. Also if there are
> specific optimization settings that have been used to workaround
> compiler bugs, these should be remove
* Kevin Mark ([EMAIL PROTECTED]) [050707 12:33]:
> With the recent article from Zdnet, does Debian need a press officer or
> www.debian.org/press? If harm is done to the reputation to the Debian
> organization by word or deed, should there be someone to respond to
> this?
We have a press office, a
Hi members of Debian at large,
With the recent article from Zdnet, does Debian need a press officer or
www.debian.org/press? If harm is done to the reputation to the Debian
organization by word or deed, should there be someone to respond to
this? Any legitimate news organization should do adequet f
On Thu, Jul 07, 2005 at 10:54:15AM +0200, Alexis Papadopoulos wrote:
> Thanks for that one,
> the thing is that the upstream author is using libtool which has a somehow
> "special" versioning method. Apparently when the library's interface changes
> in a way backwards-compatibility is broken, the
Quoting Turbo Fredriksson <[EMAIL PROTECTED]>:
> Quoting Brian May <[EMAIL PROTECTED]>:
>
>>> "Turbo" == Turbo Fredriksson <[EMAIL PROTECTED]> writes:
>>
>> Turbo> YEARS (!) ago I wrote the script that did the pre-upgrades
>> Turbo> to 'bo' (I _think_ it was to 'bo' any way :). It basi
Hello.
Are multiarch ideas alive?
Do they have any future in Debian?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Thanks for that one,
the thing is that the upstream author is using libtool which has a
somehow "special" versioning method. Apparently when the library's
interface changes in a way backwards-compatibility is broken, the major
(what they call current) version must be incremented.
I will have
On Thu, Jul 07, 2005 at 10:13:20AM +0200, Alexis Papadopoulos wrote:
> Hello,
> I'm actually making some .deb packages out of a single source archive. One of
> them should contain a shared library. The upstream author's package's version
> is 5.13 and the soname of his library has been set to 513.
Quoting Brian May <[EMAIL PROTECTED]>:
>> "Turbo" == Turbo Fredriksson <[EMAIL PROTECTED]> writes:
>
> Turbo> YEARS (!) ago I wrote the script that did the pre-upgrades
> Turbo> to 'bo' (I _think_ it was to 'bo' any way :). It basically
> Turbo> only ftp'd (or was it wget?) requir
Hello,
I'm actually making some .deb packages out of a single source archive.
One of them should contain a shared library. The upstream author's
package's version is 5.13 and the soname of his library has been set to
513. After having contacted him, he told me that was done because
apparently
Our mail system thinks you've sent us a message.
If you didn't, your address was forged, and you can delete this
message
If you did send us (PEG.COM) a message, then be advised that
your post to the mailinglist appears to contain an attachment or
enriched text or multipart HTML or maybe just pla
69 matches
Mail list logo
