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
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
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
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.
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
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]
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
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
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
* 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
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
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 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, 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
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
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
>
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
> 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,
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
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
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
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
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
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
* 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
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
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
* 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
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.
* 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
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
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
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
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
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
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
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 ([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
> 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
> 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
> 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
* [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
* [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] 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
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
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 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
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
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
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
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,
> >
> > 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.
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]
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 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, 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
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
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
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.
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
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
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
[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'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
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
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:
>
> *
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" <[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 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
69 matches
Mail list logo
