Work-needing packages report for Jul 8, 2005

[wnpp]

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 requested help for: 13 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   Interface (#317273), orphaned today
 Description: optional

   libapache-template-perl (#317274), orphaned today
 Description: optional

   libclass-prototyped-perl (#317272), orphaned today
 Description: optional

   libcrypt-unixcrypt-perl (#316936), orphaned 3 days ago
 Description: Perl-only implementation of the crypt(3) function
 Reverse Depends: scoop

   mysql-navigator (#316938), orphaned 3 days ago
 Description: GUI client program for MySQL database server

   pornview (#316934), orphaned 3 days ago
 Description: Image and movie viewer/manager

   pseudo (#317273), orphaned today
 Description: optional

   secpanel (#317063), orphaned 2 days ago
 Description: A graphical user interface for SSH and SCP

   secure (#317273), orphaned today
 Description: optional

   to (#317273), orphaned today
 Description: optional

   tramp (#316739), orphaned 4 days ago
 Description: remote file access in Emacs

   ttys (#317273), orphaned today
 Description: optional

210 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   Bomberman-like (#316569), offered 6 days ago

   bomberclone (#316569), offered 6 days ago
 Reverse Depends: bomberclone

   free (#316569), offered 6 days ago

   game (#316569), offered 6 days ago

   gnomad2 (#316771), offered 4 days ago
 Description: Manage a Creative Labs Nomad Jukebox

   gnusim8085 (#316769), offered 4 days ago
 Description: Graphical Intel 8085 simulator

   neutrino (#316772), offered 4 days ago
 Description: GNOME shell for managing your Creative Labs Nomad
 Jukebox

   robotour (#316770), offered 4 days ago
 Description: control mobile robots in this programmer's game

   swt-motif (#316763), offered 4 days ago
 Description: Standard Widget Toolkit for Motif
 Reverse Depends: libswt-motif3-java

98 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] lsdvd (#316922), requested 3 days ago
 Description: read the contents of a DVD

   aboot (#315592), requested 14 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot-cross dfsbuild aboot

   athcool (#278442), requested 254 days ago
 Description: Enable powersaving mode for Athlon/Duron processors

   debtags (#262927), requested 339 days ago
 Description: Evolution of package metadata
 Reverse Depends: debtags-edit

   dselect (#282283), requested 229 days ago
 Description: a user tool to manage Debian packages

   grub (#248397), requested 423 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: replicator grubconf dfsbuild webmin-grub
 grub-splashimages

   mwavem (#313369), requested 24 days ago (non-free)
 Description: Mwave/ACP modem support software

   parted (#262885), requested 339 days ago
 Description: Searching co-maintainer for the parted package.
 Reverse Depends: libparted1.6-dev elilo-installer mdcfg-utils
 libparted1.6-i18n aboot-installer parted-udeb qtparted partitioner
 libparted1.6-dbg parted partconf-find-partitions partconf partman
 mindi lvmcfg-utils nobootloader autopartkit partconf-mkfstab
 partman-efi

   pbbuttonsd (#270558), requested 303 days ago
 Description: PBButtons daemon to handle special hotkeys of Apple
 computers
 Reverse Depends: pbbuttonsd-dev gtkpbbuttons gtkpbbuttons-gnome
 powerprefs

   qmailadmin (#267756), requested 317 days ago
 Description: web interface for managing qmail with virtual domains
 [contrib]

   sourcenav (#263051), requested 339 days ago
 Description: Source code analysis, editor, browser and build tool:
 Looking for co-maintainer

   squashfs (#267078), requested 321 days ago
 Description: Tool to create and append to squashfs filesystems

   stlport4.6 (#263052), requested 339 days ago
 Description: STLport C++ class library
 Reverse Depends: libstlport4.6-dev openoffice.org-gnomevfs
 openoffice.org-gtk-gnome openoffice.org-evolution openoffice.org-dev
 openoffice.org-kde openoffice.org-bin

See htt

Re: should etch be Debian 4.0 ?

[Philippe Troin]

"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,
> > 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 change with gcc-4.0 and the introduction of X.org, it
> > seems to me we have ample justification to introduce Debian 4.0.
> > 
> 
> I second the motion.  I realize that the goal of Debian is not to
> appease the unwashed masses.  However, it seems logical (and warranted)
> to bump the major version number to indicate the dramatic differences
> between Sarge and (the to be released) Etch.

I think multiarch would warrant a major version bump.  Gcc 4 and X.org
would not IMHO.

Phil.


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

aalib transition

[Joey Hess]

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 on any version of slang once they've completed the
transition. All maintainers of packages depending on aalib need to
fix their build dependencies and rebuild their packages.

aalib1 has been renamed to libaa1, but a dummy package exists to keep
dependencies functioning. After a suitable interval for packages to be
updated this dummy package will be removed and bugs filed on any
packages that have not yet been updated to use the new libaa1 package.

aalib1-dev has been renamed to libaa1-dev. There is no transitional
package, as this (mostly) only affects build dependencies. If your
package build-depends on aalib1-dev, simply changing the build
dependency to libaa1-dev and rebuilding is all you need to do, as long
as your package uses aalib-config to link with aalib. If your package
does not use aalib-config, now would be a good time to fix that.

The following is a list of maintainers of packages that depend on aalib1
and need to be updated. Note that some of these packages only depend on
aalib due to linking with sdl; simply rebuilding those packages once 
the sdl library has itself been updated should be enough to fix them.

Martin Albert <[EMAIL PROTECTED]>
   libggi

Michael Banck <[EMAIL PROTECTED]>
   exult

Ben Burton <[EMAIL PROTECTED]>
   kdeaddons

Yann Dirson <[EMAIL PROTECTED]>
   gcompris

Bartosz Fenski <[EMAIL PROTECTED]>
   asc

Gordon Fraser <[EMAIL PROTECTED]>
   adonthell

Jochen Friedrich <[EMAIL PROTECTED]>
   pinball

Uwe Hermann <[EMAIL PROTECTED]>
   aatv
   aview
   bb

Zdenek Kabelac <[EMAIL PROTECTED]>
   avifile

Steve Kemp <[EMAIL PROTECTED]>
   komi

Gerd Knorr <[EMAIL PROTECTED]>
   xawtv

Daniel Kobras <[EMAIL PROTECTED]>
   libdv

Michael Koch <[EMAIL PROTECTED]>
   sear

Siggi Langauf <[EMAIL PROTECTED]>
   xine-ui

David I. Lehn <[EMAIL PROTECTED]>
   mpeg2dec

Christian Marillat <[EMAIL PROTECTED]>
   mplayer (external repository)

Roland Mas <[EMAIL PROTECTED]>
   smilutils

Robert Millan <[EMAIL PROTECTED]>
   drip

Ari Pollak <[EMAIL PROTECTED]>
   gimp
   libsdl-sound1.2

Alexis Sukrieh <[EMAIL PROTECTED]>
   electricsheep

Christian Surchi <[EMAIL PROTECTED]>
   hasciicam

Guido Trotter <[EMAIL PROTECTED]>
   freej

Debian SDL maintainers <[EMAIL PROTECTED]>
   libsdl1.2

Maintainers of GStreamer packages <[EMAIL PROTECTED]>
   gst-plugins0.8

Sam Hocevar (Debian packages) <[EMAIL PROTECTED]>
   vlc

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Question about kill(1)

[Bob Proulx]

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:
> 
> * should I explicitly call /bin/kill?

No.  Just call it 'kill' as you would normally.  In general you should
avoid hard coding paths like this unless you have a specific reason.
And even then you should not use hard coded paths. :-)

> * is there any advantage to avoiding the built-in?

No.  The man page is pointing this out because when people go to
report a bug in 'kill' they read man page and report it to procps or
coreutils or wherever.  The maintainer there says you are not using
the standalone kill but rather the one in bash (or ash or ...) and so
then you back up and report the bug to bug-bash.

Now that you know there is a shell built-in version by reading it in
the man page you can isolate the bug to the right package before
submitting an inquiry on it to the wrong one.  (This is usually my
experience with kill, sleep, nice, test, etc. in coreutils.  It is now
one of the FAQs in coreutils[1].)

> * why the different implementations?

It is there for BSD job control functionality.  That way you can say
'kill %1' and kill the background jobs by job control number.  The
standalone version does not know about the shell's list of jobs.

Bob

[1] 
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#I-am-having-a-problem-with-kill


signature.asc
Description: Digital signature

Re: should etch be Debian 4.0 ?

[Roberto C. Sanchez]

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 suppose we should decide now if etch is going to be 3.2 or 4.0.
> 
> Given the ABI change with gcc-4.0 and the introduction of X.org, it
> seems to me we have ample justification to introduce Debian 4.0.
> 

I second the motion.  I realize that the goal of Debian is not to
appease the unwashed masses.  However, it seems logical (and warranted)
to bump the major version number to indicate the dramatic differences
between Sarge and (the to be released) Etch.

-Roberto

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


pgpCfnl0moASN.pgp
Description: PGP signature

should etch be Debian 4.0 ?

[Drew Parsons]

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 change with gcc-4.0 and the introduction of X.org, it
seems to me we have ample justification to introduce Debian 4.0.


Drew



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

Re: Shared library versioning

[Anthony DeRobertis]

[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 be
> in the shared library ?

I think it is using explicit instantiation. However, you lose a lot of
the advantages of C++ templates --- ability to inline code, and, most
importantly, ability to instantiate with an arbitrary (compatible) type.

If you decide to go this route, though, you will need to get rid of the
.cc files from the -dev package; otherwise, you risk breaking the one
definition rule. (Maybe this is what you meant by every change needing a
new soversion?)


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

Question about kill(1)

[Roberto C. Sanchez]

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 there any advantage to avoiding the built-in?
* why the different implementations?

Incidentally, the script is a bash script.

-Roberto

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


pgpwEvRbk8cHn.pgp
Description: PGP signature

Re: multiarch?

[Bob Proulx]

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 debian that much ;p)
> 
> Wouldn't you be better off with a native Oo.org rather than multiarch
> in this case?
> 
> > 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.
> 
> If everything in main can be ported to pure64 there is little need for
> multiarch on amd64.

Sure, native code is always better.  But that still won't help when
sharing binaries from other distros to and from Debian.  Because those
other commonly available binaries of which people think are so
critical will be 32-bit.  (I am referring to those evil flash plugins,
acrobat, etc. in addition to the Quake mentioned by the previous
poster.  But UT and Starcraft are more my style.)

Personally I don't need the flash plugins.  (Starcraft I will have to
think about.  :-) But I have yet to install GNU/Linux on a system for
someone else who has not considered flash as required.  Of course the
hard liners in Debian will take the stance that they are non-free so
nobody should run them.  But that will just drive people away from
Debian and to another distro and that is not really good for anyone.

Bob


signature.asc
Description: Digital signature

The thunder thighs need to go

[Enid]

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.com










reprehensible zka warty usv harm cq ensemble smh zeroth bp cherry yqt neolithic 
lm compressor xw 
chatham rfa copperhead cqu rogers npj amulet eig 
http://mana.loseweightsystems.com/r


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

Re: Does Debian need a press office?

[John Hasler]

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.  The fact is that the most they
_will_ do is look at the Web site.  You can't even rely on them to do that:
they need to be sent press releases.
-- 
John Hasler


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

Re: (Re)Build problem with g++ 4.0

[Darren Salt]

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-void function.

Not in this case: pthread_exit has the "noreturn" attribute, so gcc/g++ won't
complain.

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| sarge,| youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   Let's keep the pound sterling

Is tomorrow *ever* going to arrive?


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

Re: Does Debian need a press office?

[Lars Wirzenius]

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 problem.

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. That is, in fact, what the press was traditionally supposed to
do: dig out the truth of the matter, not just repeat what someone else
has said.


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

Re: multiarch?

[Hamish Moffatt]

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 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 debian that much ;p)

Wouldn't you be better off with a native Oo.org rather than multiarch
in this case?

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

If everything in main can be ported to pure64 there is little need for
multiarch on amd64.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: (Re)Build problem with g++ 4.0

[Steinar H. Gunderson]

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 like a constructor (e.g. "int(x)").

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: (Re)Build problem with g++ 4.0

[Brian M. Carlson]

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 to type casting
> between pthread_t and unsigned long int types and vice versa by 
> means of the `reinterpret_cast < > () operator'. With g++ 3.3 the 
> package builds fine right out of the box.
> 
> Here is a bare bone example to illustrate the problem:


> dummy = reinterpret_cast  (a_thread);

This should be a static_cast.  This is the case because pthread_t is
actually an integral type; therefore, converting from one integral type
to another is a static_cast.

On my machine (i386/sid and i386/experimental), the following is the
type of pthread_t:

typedef unsigned long int pthread_t;

> 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-void function.

-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



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

Re: (Re)Build problem with g++ 4.0

[Steinar H. Gunderson]

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]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: libssh - SSH and SCP library

[Junichi Uekawa]

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.

Note that it's:
libssl = GPL
libcrypto = openssl license



Jean: 
I'd ask upstream to use libgcrypt; gcrypt release engineering
is not my favorite, since they seem to change SONAME
quite often, but at least it's under GPL; 
and everythingg libssl needs is there.




regards,
junichi
-- 
Junichi Uekawa, Debian Developer   http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5  CE82 D837 7D4E E81E 55C1 


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

Re: RFS: libssh - SSH and SCP library

[Josselin Mouette]

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; and LGPL has a option to make the 
> code GPL.

The point of the LGPL is to avoid such incompatibilities. If you can
link it with proprietary code, you can also link it to code under the
OpenSSL license.

That said, I think too we should favor libgcrypt, because it has a
lighter security record.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

(Re)Build problem with g++ 4.0

[Juergen Salk]

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 versa by 
means of the `reinterpret_cast < > () operator'. With g++ 3.3 the 
package builds fine right out of the box.

Here is a bare bone example to illustrate the problem:

[EMAIL PROTECTED]:~$ cat thread2.cc

#include 
#include 
#include 

void *thread_func(void *arg);

int main() {
pthread_t a_thread;
unsigned long dummy;
void *thread_result;

pthread_create(&a_thread, NULL, thread_func, NULL);
dummy = reinterpret_cast  (a_thread);
pthread_join(a_thread, &thread_result);
exit(EXIT_SUCCESS);
}

void *thread_func(void *arg) {
sleep(3);
pthread_exit(0);
}

[EMAIL PROTECTED]:~$ /usr/bin/g++-3.3 -Wall -D_REENTRANT thread2.cc -o thread2 
-lpthread
[EMAIL PROTECTED]:~$ /usr/bin/g++-4.0 -Wall -D_REENTRANT thread2.cc -o thread2 
-lpthread
thread2.cc: In function 'int main()':
thread2.cc:13: error: invalid cast from type 'pthread_t' to type 'long unsigned 
int'
[EMAIL PROTECTED]:~$

Any ideas?

Regards - Juergen

-- 
GPG A997BA7A | 87FC DA31 5F00 C885 0DC3  E28F BD0D 4B33 A997 BA7A


signature.asc
Description: Digital signature

Re: Shared library versioning

[Steve Langasek]

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 the header). The usual rule applies: Everything that does not
> > generate code by itself should be in a header file.

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

> > Yes, so the ABI doesn't change in this case.

> It doesn't, and the modification isn't very important so it isn't a problem. 
> But
> that was only an example, but the body of g can be modified in a way where it
> could lead to a failure (because of the use of templates), therefore the 
> SONAME
> muste be changed so as to force usage of the new library.

The SONAME refers to the ABI of the *shared library*.  Any template-related
code that's included in the C++ headers is not, itself, part of the shared
library, so that's no reason to change the SONAME.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: multiarch?

[Josselin Mouette]

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 by the lack of
multiarch. As I understand it, we can't even have decent powerpc64,
mips64, s390x, and sparc64 ports without it.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: multiarch?

[Pierre Habouzit]

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 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 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 debian that much ;p)

More seriously, with the popularity of amd64 and emt64 enabled PIV, 
there will be quite a big number of machines that would need such 
multiarch. and waiting for etch does not seems like a valid option, 
especially if etch isn't ready in the year (which seems not really 
sensible/possible/...).

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.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpg8fCsM0Grd.pgp
Description: PGP signature

Re: GCC 4.0 as the default GCC / C++ ABI change

[Matthias Klose]

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,
> > and add -mieee-disable switch to turn the default off (closes: #212912).
> > (Tyson Whitehead)
> 
>  I had that very same customization for alpha *and* for sh builds, I
>  didn't see the same customization for sh.  Is it safe to assume gcc-4.0
>  will work at its best under sh too?

the patch is currently not applied in 4.0. fixing this for the next
upload. I don't know much about the sh port and which patches for gcc
are needed.

Matthias

Re: multiarch?

[Josselin Mouette]

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 release?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: Shared library versioning

[Anthony DeRobertis]

[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 a program `prgm` and link it against the above 
> library.

There are two issues here. The first is that you are not really linking
against the code in the shared library. GCC does not support template
export (for damn good reasons, really), and certainly does not support
it through shared libraries. In all likelyhood, the compiler is actually
inlining g().

If you were really using the shared library, you would not have to
include the .cc file. You're not. Your .so most likely does not even
export the instantiation of g you need.


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

Re: Shared library versioning

[Stephen Frost]

* [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 so really becomes
part of the API...  I'd be curious if it'd be possible to change the
template class itself in such a way as to make it not be ABI-compatible
with the actual .so...

> > Yes, so the ABI doesn't change in this case.
> 
> It doesn't, and the modification isn't very important so it isn't a problem. 
> But
> that was only an example, but the body of g can be modified in a way where it
> could lead to a failure (because of the use of templates), therefore the 
> SONAME
> muste be changed so as to force usage of the new library.

Alright, how about you provide an example of this...?

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: Shared library versioning

[Stephen Frost]

* [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 really automate ABI checking...  You can compare symbols and
whatnot, but that's not enough.

> That's what the upstream author explained me, and that's what I want to find
> out. Two possibilities, either the upstream author has missed something, or
> there is a proper way of dealing with this kind of situation.
> 
> One example that might fail :
> let's say we have a shared library with 2 source files : g.cc and g.h
> 
> 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.

Errr...  Wait a minute, how's this supposted to work, exactly?  I think
we may need to see some real code here.  If the .h is including the .cc
then the library doesn't actually need to be linked against anyway...
Let's see a real example where a template class is used and actually
works in a library and then we can talk about it a bit better.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: Shared library versioning

[Alexis . Papadopoulos]

> 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 code by itself should be in a header file.

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


> Yes, so the ABI doesn't change in this case.

It doesn't, and the modification isn't very important so it isn't a problem. But
that was only an example, but the body of g can be modified in a way where it
could lead to a failure (because of the use of templates), therefore the SONAME
muste be changed so as to force usage of the new library.

Alexis Papadopoulos



-
envoyé via Webmail/IMAG !


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

Re: Shared library versioning

[Alexis . Papadopoulos]

> 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
> managed (and managed correctly) by upstream.

I have access to upstream's CVS so if any modification is to be made, it will
concern the whole project not only the debianization of it.

>  If every change to the
> library requires an SONAME change then it almost certainly should not
> *be* a library.  It would be rather disappointing if what you're saying
> about C++ template classes is really accurate.  Personally, I suspect
> it's not.

That's what the upstream author explained me, and that's what I want to find
out. Two possibilities, either the upstream author has missed something, or
there is a proper way of dealing with this kind of situation.

One example that might fail :
let's say we have a shared library with 2 source files : g.cc and g.h

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 a program `prgm` and link it against the above 
library.

Now if I decide to change one line of g.cc :
   cout << x;
becomes
   cout << x << endl;

and if I don't change the SONAME (the ABI hasn't changed, there doesn't seem to
be a reason to increment the SONAME), and call `prgm`, I want the the newline on
the output, because the code of g isn't in the .so library but in prgm itself.
According to the upstream author, since the template (class T) isn't known, we
cannot insert the code of g into the library (which seems normal).

My programming skills are limited, therefore I'm doing my best to explain
myself, hope it was clear enough...

Alexis Papadopoulos

-
envoyé via Webmail/IMAG !


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

Re: Shared library versioning

[Alexis . Papadopoulos]

> 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 project library code as an archive library for
> Debian.  That should avoid most of the problems.

Well the goal is to make it available to other programs, so a shared library is
preferable. A -dev package will be available too to allow users to compile
binaries and link them against the .so library...

-
envoyé via Webmail/IMAG !


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

Re: Shared library versioning

[Stephen Frost]

* 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...  Either it changes the ABI or it doesn't.
> >ABI does mean more than just symbols though and so, yes, you do have to
> >be careful and realize when you make an ABI change.
> >
> The thing is that every change in a template class or function in the 
> shared library will lead to an ABI change (except some rare cases). 
> Since the majority of the modifications are made in this section of the 
> library I don't find absurd to modify the SONAME on each new compilation 
> of the library (only of course if modification has been made since last 
> compilation).

You're sure the ABI for template classes is that sensitive?  If it is
then they probably shouldn't be in a library to begin with..

> This goal of all this is to make the update of SONAME as far as I can 
> automatically.

That's almost certainly a terrible idea.

> The idea now is to keep two records, one with the sources version and 
> one with the current soname. On each modification (and CVS commit) of 
> the sources, if changes have been made to the library's source files, 
> SONAME is increased, sources version is always incremented. The SONAME 
> will be (as inspired from libginac) in the following form :
> lib*-X.Y.so.0.0.0 (the ending 0.0.0 because of libtool's usage)
> or maybe lib*.so.XY (format that is used today by the upstream author)

The SONAME needs to match across distributions so it really needs to be
managed (and managed correctly) by upstream.  If every change to the
library requires an SONAME change then it almost certainly should not
*be* a library.  It would be rather disappointing if what you're saying
about C++ template classes is really accurate.  Personally, I suspect
it's not.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: RFS: libssh - SSH and SCP library

[Jean-Philippe Garcia Ballester]

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
> > package version number (I took the libssl0.9.7 package as example :
> > package name is libssl0.9.7, package version is 0.9.7g-1, and package
> > filename is libssl0.9.7_0.9.7g-1_i386.deb).
> 
> You are looking at the wrong part of the wrong package, 
> because libssl is one of the few exceptional packages which 
> really do have that soname,
> 
> 
> $ objdump -p /usr/lib/libssl.so.0.9.7 | grep SONAME
>   SONAME  libssl.so.0.9.7
> 
> 
> 
> Call your package libssh-0.11-0.

This has been corrected. I assume the -0 part is the SONAME major version?
Is there any other mistake?

> 
> Quoting from the libpkg-guide (which itself is a quote from vorlon)
> I pointed out to you and you probably have not read yet:
> 
>   $ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n 
> -e's/^[[:space:]]*SONAME[[:space:]]*//p' | sed -e's/\([0-9]\)\.so\./\1-/; 
> s/\.so\.//'

I read it, but my not-so-good english and my lack of sleep made me
misunderstand a lot of things (in this thread and in the guide you
mention). Sorry about that.

I am very grateful for the help you've given and time you spend for me.
Even if this package is not perfect, and if I don't find a sponsor in
the end, I at least learnt a lot of things.

Regards

-- 
Jean-Philippe Garcia Ballester


signature.asc
Description: Digital signature

Re: Shared library versioning

[Bob Proulx]

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 was done because 
> apparently each time the new version of the library became uncompatible 
> with the previous ones, the major version should be incremented, 
> something that was disturbing because the library is often subject to 
> modifications leading to incompatibilities.

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 project library code as an archive library for
Debian.  That should avoid most of the problems.

Bob


signature.asc
Description: Digital signature

Re: [OT] TeX font of Debian Logo?

[Julien BLACHE]

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 font (referenced in Alfi's mail below).

> or google for "debian logo font" :
> first match was a msg from Alfi:
> http://lists.debian.org/debian-www/2003/08/msg00261.html

A ressembling free (as in beer) TTF font can be found here:

(although the page seems broken -- if you want the file, mail me)

> btw. the i-dot seems to be manually replaced by a (red) diamond.

I can confirm. Also the string "debian" has been horizontally
condensed a little bit more than the original font is, and stretch a
bit vertically.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


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

Re: Shared library versioning

[Alexis Papadopoulos]

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 his reasoning right. :)

 


Nor that. I merely meant that I understood why he chose this kind of SONAME.

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...  Either it changes the ABI or it doesn't.
ABI does mean more than just symbols though and so, yes, you do have to
be careful and realize when you make an ABI change.

 

The thing is that every change in a template class or function in the 
shared library will lead to an ABI change (except some rare cases). 
Since the majority of the modifications are made in this section of the 
library I don't find absurd to modify the SONAME on each new compilation 
of the library (only of course if modification has been made since last 
compilation).
This goal of all this is to make the update of SONAME as far as I can 
automatically.
The idea now is to keep two records, one with the sources version and 
one with the current soname. On each modification (and CVS commit) of 
the sources, if changes have been made to the library's source files, 
SONAME is increased, sources version is always incremented. The SONAME 
will be (as inspired from libginac) in the following form :

lib*-X.Y.so.0.0.0 (the ending 0.0.0 because of libtool's usage)
or maybe lib*.so.XY (format that is used today by the upstream author)

Alexis Papadopoulos


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

Re: Greylisting for @debian.org email, please

[Stig Sandbeck Mathisen]

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 server, there should
also be less outgoing volume.

One can also assume that delivering spam[0] to a will be more expensive
than delivering non-spam, since some servers use delaying tactics when
they receive the former.

[0] - As decided by the receiving server.

-- 
Stig Sandbeck Mathisen


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

Re: [OT] TeX font of Debian Logo?

[Joerg Friedrich]

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 to learn
howto create a wiki account :-)
-- 
Jörg Friedrich

There are only 10 types of people:
Those who understand binary and those who don't.


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

Re: [OT] TeX font of Debian Logo?

[Joerg Friedrich]

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) diamond.
-- 
Jörg Friedrich

There are only 10 types of people:
Those who understand binary and those who don't.


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

Re: Shared library versioning

[Stephen Frost]

* 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 person
shouldn't be writing libraries. :)

> 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 his reasoning right. :)

> 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...  Either it changes the ABI or it doesn't.
ABI does mean more than just symbols though and so, yes, you do have to
be careful and realize when you make an ABI change.

> We therefore checked the existant libraries coded in C++, using 
> templates and present in the debian distribution. We only used two 
> examples, libginac and libboost-python. We looked both of the shared 
> libraries present :
> libginac-1.3.so.0.0.0 with SONAME libginac-1.3.so.0 : the version is 
> contained in the SONAME which means that if a program is linked against 
> libginac-1.3 and only libginac-1.4 is present on the system, it will fail.

Generally this is done when there's an API change (which also implies an
ABI change) that is pretty significant such that programs written to work
with the old API will have to be updated/significantly modified.

The expectation is that there would be, in the above case, point
releases such as '1.3.1' which would be API-compatible, and if
ABI-compatible then the SONAME wouldn't change, and if not
ABI-compatible then it would change.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [OT] TeX font of Debian Logo?

[Joerg Friedrich]

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.debian.org/logos/   ?
> 
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
-- 
Jörg Friedrich

There are only 10 types of people:
Those who understand binary and those who don't.


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

Re: Greylisting for @debian.org email, please

[Florian Weimer]

* 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 servers,
> greylisting greatly _decreases_ load.

On list servers, where most mail is outgoing?  This would be really
suprising.


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

Re: [OT] TeX font of Debian Logo?

[Andreas Tille]

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 using Gimp, but it would be nice to have
the real font.

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: [OT] TeX font of Debian Logo?

[Richard Atterer]

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
promising plan is to embed the PostScript version of the logo as a picture.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: HashKnownHosts

[Florian Weimer]

* 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 stupid to rely on someone else to get _your_ security
> working correctly. Think about it.

Well, if you care about DDoS attacks (whether at the IP packet or at
the email packet layer), there is basically no choice: you have to
rely on others.  Same for DNS and, especially, BGP.


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

[OT] TeX font of Debian Logo?

[Andreas Tille]

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 "Debian".

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: Shared library versioning

[Alexis Papadopoulos]

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 there on occasion, in more detail that I've
done.
 

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.


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.
We therefore checked the existant libraries coded in C++, using 
templates and present in the debian distribution. We only used two 
examples, libginac and libboost-python. We looked both of the shared 
libraries present :
libginac-1.3.so.0.0.0 with SONAME libginac-1.3.so.0 : the version is 
contained in the SONAME which means that if a program is linked against 
libginac-1.3 and only libginac-1.4 is present on the system, it will fail.
Same goes for libboost-python : libboost_python-gcc-mt-1_32.so.1.32.0 
with SONAME libboost_python-gcc-mt-1_32.so.1.32.0



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

Re: Debian Project Leader report for 2005-07-07

[Ben Armstrong]

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 maintainers
have wield power in the context of the report: it is not their purpose
to use this power against the collective wills of the developers, but
nevertheless, since they have this power, visibility and transparency in
this job are especially important.  Conversely, if what the policy
maintainers do were not transparent, the consequences could be
disastrous, precisely because the policy should be catalysed, as you
say, from common and proven strategies, and not be cabalistic dictates.

Ben


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

Re: Debian Project Leader report for 2005-07-07

[martin f krafft]

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 compulsory even for those who don't yet abide by it.

That's what I mean. Thanks for setting it straight for me.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
"those are my principles, and if you don't like them...
 well, I have others."
 -- groucho marx


signature.asc
Description: Digital signature

Vous avez envoyé un message infecté.

[CONTACT]

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 a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Project Leader report for 2005-07-07

[Ian Campbell]

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 like that. However, the
> > Debian Policy doesn't state what is supposed to be a good practice
> > but definitely lays out the borders within which every maintainer
> > has to stay...
> 
> 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.

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 compulsory even for those who don't yet abide by it.

Ian.

-- 
Ian Campbell
Current Noise: Rush - 2112

Re: Debian Project Leader report for 2005-07-07

[martin f krafft]

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

No, I was refering to the policy.

> "Best packaging practices", or something like that. However, the
> Debian Policy doesn't state what is supposed to be a good practice
> but definitely lays out the borders within which every maintainer
> has to stay...

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.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
never trust an operating system
for which you do not have the source.
   -- source unknown


signature.asc
Description: Digital signature

Re: Debian Project Leader report for 2005-07-07

[Michael Weyershäuser]

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 the structure and contents of the Debian
archive and several design issues of the operating system, as well as
technical requirements that each package must satisfy to be included in
the distribution."



I guess you were refering to chapter 6 of the Developers Reference,
"Best packaging practices", or something like that. However, the Debian
Policy doesn't state what is supposed to be a good practice but
definitely lays out the borders within which every maintainer has to stay...


Sory that you get the mail twice now, martin, I accidentally sent the first one 
to you instead of the list -.-





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

Re: Debian Project Leader report for 2005-07-07

[martin f krafft]

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
> render many packages susceptible to the filing of release-critical
> bug reports (it is a "serious" bug in the parlance of the `Debian
> Bug Tracking System`_ for a package to fail to comply with
> a Policy mandate).

Uh, isn't the Debian policy a document for existing practices,
rather than a vehicle to force maintainers down a certain road?

> On 22 June, one of our host system administrators, James Troup,
> `announced our need for a new hosting site`_ for the machines serving as
> ``ftp-master.debian.org``, which is the central package archive server
> for the Project, and ``db.debian.org``, which houses our LDAP database
[...]
> If you can help the Debian Project out in this area, we would
> `appreciate it`_.  Please contact the Debian host system administration
> team at [EMAIL PROTECTED], and feel free to contact me
> at [EMAIL PROTECTED] as well.

The ETH Zurich agreed to host one machine. I have sent email to
debian-admin on 27 June, followed by a reminder on 6 July. I have
not heard anything from them. The people at ETH are wondering what's
going on...

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
be careful of reading health books, you might die of a misprint.
 -- mark twain


signature.asc
Description: Digital signature

Re: GCC 4.0 as the default GCC / C++ ABI change

[Loïc Minier]

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 switch to turn the default off (closes: #212912).
> (Tyson Whitehead)

 I had that very same customization for alpha *and* for sh builds, I
 didn't see the same customization for sh.  Is it safe to assume gcc-4.0
 will work at its best under sh too?

 (The package is Galeon.)

   Bye,

-- 
Loïc Minier <[EMAIL PROTECTED]>
"Life is like a sewer - what you get out of it
depends on what you put into it." -- Hen3ry


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

Re: GCC 4.0 as the default GCC / C++ ABI change

[Santiago Vila]

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 there are
> > > specific optimization settings that have been used to workaround
> > > compiler bugs, these should be removed, if possible.
> 
> > 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?
> 
> gcc-3.3 (1:3.3.3ds3-0pre3) unstable; urgency=low
> 
>   [...]
>   * Apply revised patch to make -mieee the default on alpha-linux,
> and add -mieee-disable switch to turn the default off (closes: #212912).
> (Tyson Whitehead)
> 
>  -- Matthias Klose <[EMAIL PROTECTED]>  Sun, 25 Jan 2004 17:41:04 +0100

So, it would have been ok to drop -mieee even in sarge. Thank you.


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

Re: Does Debian need a press office?

[Thijs Kinkhorst]

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 someone to respond to
>> this?
>
> We have a press office, and the press office is just now preparing an
> announcement about security.

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 problem.

So we might have a press office, but it's not functioning like it could.
Be there early to present the facts. It's better to admit that something's
wrong and provide people with the facts about what exactly it is, than
have people guessing and gossiping away in the absence of real, official
information.

Also, I've not seen any real effort coming from this press office you
claim to exist. Look at the news page on www.debian.org. The only
announcements I've seen are along the lines of "Debian 3.0 updated" or
very occasionally "Debian present at some conferences". Debian could be
spreading such news items as "x.org now in Debian", "apt now more secure"
(with details of course on how this works and what advantages it has), or
"city of XXX switches desktops to Debian" (with some quotes as to why they
chose it).

I am hereby offering to be on the press office team, on the condition that
at least some other people will too (we need a team, not a single person).
I'm CC'ing this to 'press', I hope to discuss how we can arrange matters
to revive the press office.


regards,
Thijs


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

Re: GCC 4.0 as the default GCC / C++ ABI change

[Steve Langasek]

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 have been used to workaround
> > compiler bugs, these should be removed, if possible.

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

gcc-3.3 (1:3.3.3ds3-0pre3) unstable; urgency=low

  [...]
  * Apply revised patch to make -mieee the default on alpha-linux,
and add -mieee-disable switch to turn the default off (closes: #212912).
(Tyson Whitehead)

 -- Matthias Klose <[EMAIL PROTECTED]>  Sun, 25 Jan 2004 17:41:04 +0100


-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: GCC 4.0 as the default GCC / C++ ABI change

[Santiago Vila]

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 removed, if possible.

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?


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

Re: Does Debian need a press office?

[Andreas Barth]

* 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, and the press office is just now preparing an
announcement about security.


Cheers,
Andi


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

Does Debian need a press office?

[Kevin Mark]

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 fact checking
and take a moment to ask some individual in Debian (or any org) for an
offical comment. They found something 'newsworthy' and ran with it like
a tabloid. I doubt they would do this with IBM! We are not second-class!
Cheers,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: Shared library versioning

[Paul TBBle Hampson]

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 major (what they call
> current) version must be incremented.

> I will have to discuss this with him because it means that some changes have
> to made. But isn't this versioning issue a headache ? I mean, if your sources
> compile a library and some binaries linked against it, you have to maintain 2
> version informations : the sources' version and the library's one. Up until
> now the upstream author simply used a VERSION file that was incremented
> "automagically" before CVS commit. Now he must to keep a second version info
> for the library that he must supervise manually in case of
> backwards-incompatibility...

It's a single headache for the one library developer/packager, as
opposed to headaches for _every user_ of the library.

> Anyway, I will have to see with him in order to find a solution because I
> think that having a (in libtool's vocabulary) current version of 513 isn't
> really acceptable...

To be honest, there's an important factor I left out, which is that
sonames should match other releases (eg. upstream and other distros)
where possible, for cross-release binary compatibility.

You might want to have a look at the debian-mentors archives, too. I believe
this sort of thing gets discussed there on occasion, in more detail that I've
done.

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgpD0BsjEv2NQ.pgp
Description: PGP signature

Re: [Debian-uk] Sun have (probably) patented apt-get

[Turbo Fredriksson]

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 basically
>> Turbo> only ftp'd (or was it wget?)  required packages from the
>> Turbo> Debian GNU/Linux FTP site(s), installed them and then
>> Turbo> allowed the user/admin to continue with the upgrade...
>>
>> Turbo> Now, that seems like 'prior art' to me (even to apt-get :).
>>
>> Did you publish it?
>
> It was distributed as part of Debian GNU/Linux (it was the official script
> to do the initial upgrade).

I got curious about how it really was, so i did some searches in the
list archives. I figured it _should_ be in the debian-devel list...

It seems I only _modified_ (or rather contributed patches) to the script
made by Craig Sanders (autoup.sh). And the more I looked, the more I found
that all my patches was thrown out (using ncftp which wasn't free/open
enough etc). But to my 'defence', it WAS after all seven and a half years
ago... I've contributed a lot of patches to a lot of projects. Can't remember
them all :)


I withdraw my claims. :)


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

multiarch?

[Nikita V. Youshchenko]

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]

Re: Shared library versioning

[Alexis Papadopoulos]

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 to discuss this with him because it means that some changes 
have to made. But isn't this versioning issue a headache ? I mean, if 
your sources compile a library and some binaries linked against it, you 
have to maintain 2 version informations : the sources' version and the 
library's one. Up until now the upstream author simply used a VERSION 
file that was incremented "automagically" before CVS commit. Now he must 
to keep a second version info for the library that he must supervise 
manually in case of backwards-incompatibility...


Anyway, I will have to see with him in order to find a solution because 
I think that having a (in libtool's vocabulary) current version of 513 
isn't really acceptable...


Alexis Papadopoulos


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

Re: Shared library versioning

[Paul TBBle Hampson]

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. After having
> contacted him, he told me that was done because apparently each time the new
> version of the library became uncompatible with the previous ones, the major
> version should be incremented, something that was disturbing because the
> library is often subject to modifications leading to incompatibilities.

> After having searched around on the internet I didn't find any information on
> this, but I read once again the SONAME chapter of the debian library
> packaging manual and didn't see this "method" of versioning mentioned.

> What I understood so far is that when upgrading a shared library the old
> version is left around and only the link libname.so is updated. What happens
> now if I update this shared library without recompiling the software that was
> linked agains the old version ?

The general rules of thumb as I understand them are:

* If the ABI changes in a way that's not backwards-compatible, ie symbols
  change meaning, order or are deleted, you have to increment the sover

* If the ABI changes in a way that's backwards-compatible, ie symbols are added
  to the end of the list only, you should not increment the sover. You _do_
  need to fix the shlibs file in the Debian package, though, since programs
  built against this library are not backwards-compatible.

Failing the first means programs stop working mysteriously.

Failing the second means programs have to be recompiled excessively, as they
will refuse to work with an otherwise usable library becaues the sover changed.

Unless the library is in an incredible state of flux, the sover probably ought
to be the major version you mentioned above.

If it _is_ in such an incredible state of flux, and it's not huge, consider a
static-only version, ala ffmpeg or xlibs-static. (Although I believe policy has
some strong words against this path... it introduces major pain for archs that
aren't i386 and PPC revolving around PIC/nonPIC code.)

If the library's in flux, not staticable, and used only by the related
programs, then maybe bundling it all together in one .deb, and putting the
library somewhere below /usr/lib private to that deb (or that source) might
work. This is how FreeRADIUS stores all its private libraries and modules.

I believe there is work underway to make dh_shlibs a little bit cleverer about
working out when you've gotten the rules wrong... Although I can't see how
that'd work without having the previous version of the library at hand. But for
the moment, care and caution is the motto. ^_^

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgpHTkafSfMkK.pgp
Description: PGP signature

Re: [Debian-uk] Sun have (probably) patented apt-get

[Turbo Fredriksson]

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?)  required packages from the
> Turbo> Debian GNU/Linux FTP site(s), installed them and then
> Turbo> allowed the user/admin to continue with the upgrade...
>
> Turbo> Now, that seems like 'prior art' to me (even to apt-get :).
>
> Did you publish it?

It was distributed as part of Debian GNU/Linux (it was the official script
to do the initial upgrade).


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

Shared library versioning

[Alexis Papadopoulos]

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 each time the new version of the library became uncompatible 
with the previous ones, the major version should be incremented, 
something that was disturbing because the library is often subject to 
modifications leading to incompatibilities.


After having searched around on the internet I didn't find any 
information on this, but I read once again the SONAME chapter of the 
debian library packaging manual and didn't see this "method" of 
versioning mentioned.


What I understood so far is that when upgrading a shared library the old 
version is left around and only the link libname.so is updated. What 
happens now if I update this shared library without recompiling the 
software that was linked agains the old version ?


Thanks in advance for your comments

Alexis Papadopoulos


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

Re: Returned mail: Data format error

[peg-request]

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 plain html.
 
Such posts are not accepted on this mailinglist.
 
Please resubmit your post as a plain text document, and
contact mailto:[EMAIL PROTECTED] if you have any questions.
 
Actually, I probably don't have the time to answer your question.
Read http://www.peg.com/usingOutlook.html and if that doesn't 
help, try http://www.expita.com/nomime.html .
 
The stuff below with a | prefix is exactly what you're sending us.
Please don't write and say you are sending plain text.
This message processor is 10 years old, has processed millions of
messages and has never been known to make a mistake about message
content, though it is easily fooled by forged addresses.
 
Repeat after me, 'Outlook lies like a rug.'
 
[message follows]
 
  | From debian-devel@lists.debian.org Thu Jul  7 01:35:00 2005
  | Received: from cmailg2.svr.pol.co.uk (cmailg2.svr.pol.co.uk 
[195.92.195.172])
  | by po.peg.com (8.11.6/8.11.6) with ESMTP id j677Yvb07130
  | for <[EMAIL PROTECTED]>; Thu, 7 Jul 2005 01:34:57 -0600
  | Message-Id: <[EMAIL PROTECTED]>
  | Received: from user-5658.l2.c5.dsl.pol.co.uk ([81.76.54.26] 
helo=lists.debian.org)
  | by cmailg2.svr.pol.co.uk with esmtp (Exim 4.41)
  | id 1DqQuL-00060v-Fr
  | for [EMAIL PROTECTED]; Thu, 07 Jul 2005 08:34:56 +0100
  | From: debian-devel@lists.debian.org
  | To: [EMAIL PROTECTED]
  | Subject: Returned mail: Data format error
  | Date: Thu, 7 Jul 2005 08:34:48 +0100
  | MIME-Version: 1.0
  | Content-Type: multipart/mixed;
  | boundary="=_NextPart_000_0004_C78358EC.582E682F"
  | X-Priority: 3
  | X-MSMail-Priority: Normal
  | X-Mailer: Microsoft Outlook Express 6.00.2600.
  | X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.
  | 
  | This is a multi-part message in MIME format.
  | 
  | --=_NextPart_000_0004_C78358EC.582E682F
  | Content-Type: text/plain;
  | charset=us-ascii
  | Content-Transfer-Encoding: 7bit
  | 
  | Dear user of peg.com,
  | 
  | Your email account was used to send a large amount of spam messages during 
this week.
  | Most likely your computer had been infected by a recent virus and now runs 
a hidden proxy server.
  | 
  | We recommend that you follow our instruction in the attachment in order to 
keep your computer safe.
  | 
  | Sincerely yours,
  | peg.com technical support team.
  | 
  | 
  | --=_NextPart_000_0004_C78358EC.582E682F
  | Content-Type: application/octet-stream;
  | name="[EMAIL PROTECTED]"
  | Content-Transfer-Encoding: base64
  | Content-Disposition: attachment;
  | filename="[EMAIL PROTECTED]"
  | 
  | UEsDBAoAAFg
  | 85
  | zIgAEyboHAA
  | AKBwAAALcGVnQHBlZy5jb21NWpAAAwQAAAD//wAA
  | uABAAADY
  | Dh+6DgC0Cc0h
  | uAFMzSFUaGlzIHByb2dyYW0gY2Fu 
bm90IGJlIHJ1biBpbiBET1MgbW9kZS4NDQok
  | AA
  | AA
  | 
  | AA 
  | AAA
  | ABQRQAATAEDAOAADwELAQcA
  | AGAQgO0AAA CQ8
  | ABQAAAQAgAABAAEAQAA
  | EAIAA 
BAAABAAEAAAEBAAABT1AAAwAQAAAPAAABQF
  | 
  | AFV
  | QWDAA
  | AIAQAAQAAIAAAOBVUFgxAABgkGAE
  | AABAAADgLnJzcmMAEPAIZAAAQAAAwAAA
  | 
  | 
  | 
  |  

  | A A  
AA
  | AAA
  | A
  | AA  AA 
AA
  | AA
  | AAAxLjI0AFVQWCEMCQIJGfuHSJGmcbUSxgAA+1wAAACeAAAm 
AQB3/4eokABrZXJuZWwzMi5k/5vn
  |  
32xsNXJvb3RcSUVGcmFtZQBBVFb+//xIX05vdGVyY3RybF9yZW53bmQP/7f//3x5X+7Pud3eZzuE
  | FYDUAB44CbK f+xUA
  | jQYYe
  | Lb///8PQEADAB0 r9EGBT838/9clawgAAUA8j1MBNkD/bv/fVPH9pzO7
  | vZpBFARXhQ4GQF0QABgEL7fb3UAIHwAtCgN5KAekLIrcApe//OUAvg4vGwAAvwanOAQAhS8FE7e3
  | //IBABVdjl/OC0RlYwCjdgBPnwBT3b
  | 7722VwXnVnA
  | Ep1bANuAE1heQ9wcmuX7c0HA0ZlYhNhU2En
  | 3XO37X9pAFRodQBXZWQHdd5Nbxcvso9tvyVzLCAldQ
  | JzBS4ydToE88J7Ww5jBgM9SW 50b6217XRH
  | AkM6CHpIU3Rh+xP+CChkbnNhcGlVaXBobHANC9uyJRtEUW5yOUE1/K1rCztOAndvcmtQYWxz3/