Re: apt-get wants to upgrade package to same version?
On Wed, 21 Aug 2002, Brian May wrote: > On Tue, Aug 20, 2002 at 09:50:21PM -0600, Jason Gunthorpe wrote: > > The entires in Packages files and those in the .deb must match exactly > > (ie byte for byte), otherwise it sees them as different packages. Since > > dpkg manipulates the status file and only has information from the .deb > > there is no way to force a particular contents into the status file. > > apt-get knows that it has to get the file from: > > deb http://snoopy.apana.org.au/~ftp/debian woody main > > and the md5sum of the Packages file from this source, as quoted > before matches exactly. Er, the md5sum of the deb is not kept by dpkg after you install a .deb. Jason
business assistance
Petroleum (Special) Trust Fund Contract Award Committee National Secretariat Victoria-Island Lagos-Nigeria. Email:[EMAIL PROTECTED] ATTENTION: THE MANAGING DIRECTOR, The Petroleum Special Trust Fund was set up by the late Head of State General Sani Abacha who died on 8th June 1998, to manage the excess revenue accruing from the sale of petroleum and its allied products as a result of domestic increase in the prices of petroleum products. The estimated annual revenue for 1999 was 45 billion US Dollars Ref. FMF A26 Unit 3B paragraph "D" of the Auditor General of the Federal Republic of Nigeria Report of NOV. 1999 on estimated revenue. I am the Chairman of the Contract Award committee and my committee is solely responsible for awarding and payment of contracts on behalf of the Federal Government of Nigeria . My Committee awarded contracts to foreign contractors for the supply of Agricultural Machines and spare parts to the Ministry of Agriculture and Natural Resources. We overshot the contract sum by USD35 Million. We have paid the contractors and withholding the balance of 35 Million United States Dollars. Beceause of existing domestic laws forbidding civil servants from opening, operating and maintaining foreign accounts, we do not have the expertise to transfer this balance of funds to a foreign account. However, this balance of 35 Million United States Dollars($35 million USD) has been secured in form of credit/payment to a foreign contractor.Hence, we wish to transfer into your bank account as the beneficiary of the funds. We have also arrived at a conclusion that you will be compensated to the tune of 25% of the total sum transfered while 5% will be reserved for incidental expenses that both parties will incur in the course of actualizing this transaction and the balance of 70% will be kept for the Committee members. If you know you are capable of helping us actualize our life's dream,You should send to me immediately the details of your bank particulars or open a new account where we can transfer the money(US$35M)which you will hold in trust for us until we come over there for our own share.Your nature of business does not matter in this transaction. As soon as you open the account, send by e-mail immediately with thedetails of the account viz: Name of bank, address, routing number, telex number, Account number, Tel and Fax number.You should also include the name of your company, your personal address, Tel and Fax numbers for further communication. Note that this transaction will be concluded within 10 working days from the day you give your consent. Sincerely yours, mr lawal bankole
Re: apt-get wants to upgrade package to same version?
On Tue, Aug 20, 2002 at 11:19:13PM -0600, Jason Gunthorpe wrote: > > apt-get knows that it has to get the file from: > > > > deb http://snoopy.apana.org.au/~ftp/debian woody main > > > > and the md5sum of the Packages file from this source, as quoted > > before matches exactly. > > Er, the md5sum of the deb is not kept by dpkg after you install a .deb. We seem to be going around in circles, or talking on different frequencies, or something. Lets try to go back to the basics: My apt-sources contains: deb http://snoopy.apana.org.au:8081/debian/ woody main non-free contrib deb http://snoopy.apana.org.au:8081/debian/ unstable main non-free contrib deb http://snoopy.apana.org.au/~ftp/debian woody main My apt/preferences file is setup so that the 2nd line has a priority -1, so it should effectively be ignored, right? Also, the version in woody is old, so that line should be ignored too, right? That leaves one line left to be processed, the last one. I then run an "apt-get update" operation. This will download this entry from the Packages file: Package: kerberos4kth1 Version: 1.1-11-2 Priority: optional Section: net Maintainer: Mikael Andersson <[EMAIL PROTECTED]> Architecture: all Filename: ./pool/krb4/kerberos4kth1_1.1-11-2_all.deb Size: 57786 MD5sum: 330d49310a3264f037875e06a1328458 Description: Dummy library package for Kerberos4 From KTH. This is a dummy package. It should be safe to remove it. installed-size: 76 source: krb4 This MD5sum matches that of the file on the server, exactly: [518] [snoopy:unstable:bam] /home/ftp/pub/debian >md5sum ./pool/krb4/kerberos4kth1_1.1-11-2_all.deb 330d49310a3264f037875e06a1328458 ./pool/krb4/kerberos4kth1_1.1-11-2_all.deb The MD5sum is also exactly the same on the file downloaded on the client. I then do "apt-get upgrade" two times in a row, and it upgrades the same set of packages twice. Why? -- Brian May <[EMAIL PROTECTED]>
Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System
Package: wnpp Version: N/A; reported 2002-08-21 Severity: wishlist * Package name: ffmpeg Version : 0.46 Upstream Author : Fabrice Bellard <[EMAIL PROTECTED]> * URL : http://ffmpeg.sourceforge.net/ * License : LGPL Description : FFmpeg Streaming Multimedia System FFmpeg is the first complete and free Internet Live Audio and Video Broadcasting solution. FFMpeg aims at being the command line tool to handle audio and video. It is a "three-in-one" solution. FFmpeg includes a soft VCR capable of encoding in many different formats simultaneously and a streaming server for Netcasting multimedia. Use FFmpeg to start your own Internet Radio or TV station, to stream live or pre-recorded content or to turn your video camera into a video monitoring system. NOTE: Prototype version are available at: [EMAIL PROTECTED] marc]$ cat /etc/apt/sources.list |grep lesbos deb http://lesbos.esat.kuleuven.ac.be/~mleeman/debian unstable/ deb-src http://lesbos.esat.kuleuven.ac.be/~mleeman/debian unstable/ With Prototype, I mean that they are packaged, nothing more (not clean, nor complete, ...) I need those sources for nvrec, so I decided to package them too. I should have more time get them into shape for debian within a month or two. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux scorpius 2.4.19-rc3 #1 Thu Aug 1 07:42:23 CEST 2002 i686 Locale: LANG=C, LC_CTYPE=C -- no debconf information
Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System
Le mer 21/08/2002 à 09:39, Marc Leeman a écrit : > * Package name: ffmpeg > Version : 0.46 > Upstream Author : Fabrice Bellard <[EMAIL PROTECTED]> > * URL : http://ffmpeg.sourceforge.net/ > * License : LGPL > Description : FFmpeg Streaming Multimedia System FYI, Christian Marillat has already some ffmpeg packages at http://marillat.free.fr/ -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System
On Wed, Aug 21, 2002 at 09:39:56AM +0200, Marc Leeman wrote: > * Package name: ffmpeg > Version : 0.46 > Upstream Author : Fabrice Bellard <[EMAIL PROTECTED]> > * URL : http://ffmpeg.sourceforge.net/ > * License : LGPL > Description : FFmpeg Streaming Multimedia System A lot of the code in ffmpeg is within the 'libavcodec' subdirectory, and this code has been incorporated by several other projects (xine and mplayer are all I can think of right now). I know that the libxine source, at least on the debian servers, contains a copy of libavcodec. Perhaps a dynamic libavcodec library should be built from the ffmpeg sources and packages like xine could link against it. Also, libavcodec contains some assembly routines that greatly enhance performance. I would make sure that these are enabled on your packages on all relevant architectures. They should not pose any problems because IIRC at least on i386 usage of nonstandard features like MMX, SSE, and 3DNow is decided at runtime based on the processor's features (CPUID).
Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System
> FYI, Christian Marillat has already some ffmpeg packages at > http://marillat.free.fr/ I'll check it out, since this package is not my main interest. If I can use the existing ones, the better. -- greetz, marc BOFH excuse #73: Daemons did it pgp Key ID: 0xD3562DE1 Key fingerprint = 890C E47F 1589 F240 9CC8 C60C 510A 63D3 D356 2DE1 Linux scorpius 2.4.19-rc3 #2 Thu Aug 1 05:23:31 CEST 2002 GNU/Linux pgpJrnXTrrBrh.pgp Description: PGP signature
Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System
> FYI, Christian Marillat has already some ffmpeg packages at > http://marillat.free.fr/ Hm, Christian's package is the same (at least the binary contents) as my quick solution. I'll see if we can use his packages (libffmpeg0 and ffmpeg), tnx. -- greetz, marc BOFH excuse #73: Daemons did it pgp Key ID: 0xD3562DE1 Key fingerprint = 890C E47F 1589 F240 9CC8 C60C 510A 63D3 D356 2DE1 Linux scorpius 2.4.19-rc3 #2 Thu Aug 1 05:23:31 CEST 2002 GNU/Linux pgp6zVwDkll8m.pgp Description: PGP signature
Bug#157729: ITP: gatos-drm-source -- DRM modules source from the GATOS project, with support for recent ATI chips
Package: wnpp Version: N/A; reported 2002-08-19 Severity: wishlist * Package name: gatos-drm-source Version : 1.2.0-14 Upstream Author : Vladimir Dergachev * URL : http://sourceforge.net/projects/gatos * License : GPL and additional rights Description : DRM modules source from the GATOS project, with support for recent ATI chips -- Yann Dirson <[EMAIL PROTECTED]> http://www.alcove.com/ Technical support managerResponsable de l'assistance technique Senior Free-Software Consultant Consultant senior en Logiciels Libres Debian developer ([EMAIL PROTECTED])Développeur Debian
Re: orphaning most (of my) packages
Quoting Peter Palfrader ([EMAIL PROTECTED]): > Please retitle them to RFP (request for package) rather than closing > them if you still think they'ld make a worthwhile addition to Debian. Thanks, good point :) Greets, Robert -- ( o> Linux Generation pgp4T6dYieG6z.pgp Description: PGP signature
Re: orphaning most (of my) packages
Quoting Ivo Timmermans ([EMAIL PROTECTED]): > I would like to take over your ITP for cryptoapi. If noone else wants > it, I can take kernel-patch-int too. As discussed yesterday night; they're yours. Greets, Robert -- ( o> Linux Generation
Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System
"Marc Leeman" <[EMAIL PROTECTED]> writes: > Package: wnpp > Version: N/A; reported 2002-08-21 > Severity: wishlist > * Package name: ffmpeg > Version : 0.46 > Upstream Author : Fabrice Bellard <[EMAIL PROTECTED]> > * URL : http://ffmpeg.sourceforge.net/ > * License : LGPL > Description : FFmpeg Streaming Multimedia System Are you aware that ffmpeg need lame ? Christian $ dlocate -s libffmpeg0 Package: libffmpeg0 Status: install ok installed Priority: optional Section: libs Installed-Size: 552 Maintainer: Christian Marillat <[EMAIL PROTECTED]> Source: ffmpeg Version: 0.4.6cvs20020521-0.0 Depends: libc6 (>= 2.2.4-4), liblame0 (>= 3.91-0.1)
Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System
> A lot of the code in ffmpeg is within the 'libavcodec' subdirectory, > and this code has been incorporated by several other projects (xine > and mplayer are all I can think of right now). I know that the libxine > source, at least on the debian servers, contains a copy of libavcodec. > Perhaps a dynamic libavcodec library should be built from the ffmpeg > sources and packages like xine could link against it. Well, I decided that I could not use the version of Christian because it was to old, but used his configuration to recompile with a latest snapshot. libavcodec and libavformat are now dinamically linked in nvrec (instead of included in the project). I'll see if there are no recording problems and if not, report the changes to upstream. libavformat was not compiled as a shlib in the original sources. Since Christian is basically maintaining the package, I'll confer with him about the best approach, I won't "branch" the package. -- greetz, marc BOFH excuse #73: Daemons did it pgp Key ID: 0xD3562DE1 Key fingerprint = 890C E47F 1589 F240 9CC8 C60C 510A 63D3 D356 2DE1 Linux scorpius 2.4.19-rc3 #2 Thu Aug 1 05:23:31 CEST 2002 GNU/Linux pgpSqrcgMNXUz.pgp Description: PGP signature
Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System
> Are you aware that ffmpeg need lame ? yes and no: yes I am aware of that and no not "need" --enable-mp3lame) mp3lame="yes" (the default is "no") but since nvrec requires mp3lame I am trouble anyway ;) -- greetz, marc We need a licensed electrician to replace the light bulbs in the computer room. Key fingerprint = 890C E47F 1589 F240 9CC8 C60C 510A 63D3 D356 2DE1 Linux mykene 2.4.19-pre4 #1 Tue Apr 2 22:47:06 CEST 2002 i686 unknown pgpEvAmNZgWLD.pgp Description: PGP signature
[buildd] brltty
Hello. I noticed that buildd doesn't build brltty since 2.98-2. Well, I know I originally just had i386 in the architecture field, but I am currently working with the upstream maintainer to fix alot of different architectures, and it would be nice if buildd could build brltty again on all archs listed in the architecture field. Could anyone tell me what to do to achieve this again, or whom to write about it? -- CYa, Mario
Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System
Marc Leeman <[EMAIL PROTECTED]> writes: > Are you aware that ffmpeg need lame ? > yes and no: > yes I am aware of that > and > no not "need" > --enable-mp3lame) mp3lame="yes" > (the default is "no") But you will lose a lot of fonctionnalities. This is the main reason I've never did an ITP for ffmpeg. > but since nvrec requires mp3lame I am trouble anyway ;) BTW the video codecs (MPEG4, MSMPEG4) are DFSG compliant ? Christian
Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System
On Wed, Aug 21, 2002 at 03:10:05PM +0200, Marc Leeman wrote: > > Are you aware that ffmpeg need lame ? > yes and no: > > yes I am aware of that > and > no not "need" > > --enable-mp3lame) mp3lame="yes" > (the default is "no") > > but since nvrec requires mp3lame I am trouble anyway ;) Well lame isn't included in the distribution because of patent problems And the same patents (and other ones) cover ffmpeg, which can encode (among other things) AC3, MPEG1 video, MPEG4, and MPEG 1 layer 2 audio. So it looks like either way you're in trouble.
RFC: OpenLDAP and TLS/SSL
Hi *,
Today I was convinced by Stephen Frost that I can just enable SSL support
in the OpenLDAP packages I maintain. No problem so far, but:
- libldap2 is Priority: important
- this change will make it depend on libssl0.9.6
- libssl0.9.6 is Priority: standard
So - what should I do to handle this? Can the priority of libssl0.9.6 be
easily changed? Or should I rather provide libldap2{,-ssl}? Technically
it would not be a big deal since the interface of libldap2 does not
change if you enable ssl. Also I wonder if a slapd package without
ssl would be in order. After all there are still people using Debian
who are not allowed to import all that crypto stuff from the US.
Any suggestions welcome
Torsten
pgpOXeElrL3N9.pgp
Description: PGP signature
Re: RFC: OpenLDAP and TLS/SSL
On Wed, Aug 21, 2002 at 03:18:38PM +0200, Torsten Landschoff wrote:
> Hi *,
Hi Torsten :-)
>
> Today I was convinced by Stephen Frost that I can just enable SSL support
> in the OpenLDAP packages I maintain. No problem so far, but:
>
> - libldap2 is Priority: important
> - this change will make it depend on libssl0.9.6
> - libssl0.9.6 is Priority: standard
>
> So - what should I do to handle this? Can the priority of libssl0.9.6 be
> easily changed? Or should I rather provide libldap2{,-ssl}? Technically
> it would not be a big deal since the interface of libldap2 does not
> change if you enable ssl. Also I wonder if a slapd package without
> ssl would be in order. After all there are still people using Debian
> who are not allowed to import all that crypto stuff from the US.
I would suggest that you make an extra -ssl package, along the lines of
eg. fetchmai{,-ssl}l. It reduces dependencies and solves your problem. Maybe
people want ldap, but not ssl.
Greetings,
Oliver
--
debian/rules http://zork.net/~nick/srom/
pgpwnehOIJqbw.pgp
Description: PGP signature
Re: RFC: OpenLDAP and TLS/SSL
Torsten Landschoff <[EMAIL PROTECTED]> writes:
> Today I was convinced by Stephen Frost that I can just enable SSL support
> in the OpenLDAP packages I maintain. No problem so far, but:
>
> - libldap2 is Priority: important
> - this change will make it depend on libssl0.9.6
> - libssl0.9.6 is Priority: standard
>
> So - what should I do to handle this? Can the priority of libssl0.9.6 be
> easily changed? Or should I rather provide libldap2{,-ssl}? Technically
> it would not be a big deal since the interface of libldap2 does not
> change if you enable ssl. Also I wonder if a slapd package without
> ssl would be in order. After all there are still people using Debian
> who are not allowed to import all that crypto stuff from the US.
As far as I know, exim is the only package with priority: important that
depend on libldap2. Howevery, the basic configuration generated by exim's
postinst doesn't use the LDAP functionality (AFAIK). So, I think exim
should be fixed so that it doesn't depend on libldap2 anymore.
Then lildap2 wouldn't need to be important anymore - your problem
would be solved, and base would shrink. :)
We could instead have an exim-bloated package with full
LDAP/MySQL/PostgreSQL/SSL functionality as priority extra.
--
Tore Anderson
Re: RFC: OpenLDAP and TLS/SSL
* Torsten Landschoff ([EMAIL PROTECTED]) wrote: > Today I was convinced by Stephen Frost that I can just enable SSL support > in the OpenLDAP packages I maintain. No problem so far, but: > > - libldap2 is Priority: important > - this change will make it depend on libssl0.9.6 > - libssl0.9.6 is Priority: standard [...] > Any suggestions welcome Hey all, I already explained my feelings about this to Torsten but since we're moving it to -devel I'll lay out my thoughts here too. First off, crypto is important to us and I think we tend to feel that it is important for our users as well. Thus, I see libssl0.9.6 being made Priority: Important as a good option. If there are too many other issues with making libssl0.9.6 important (though it only Depends: on libc and isn't very big?) then I would think that we are very concerned about the size and would therefore recommend that ldap support be removed from exim or exim be split into exim-tiny for Important and exim-big with everything enabled. Of course, exim support being modified to be modular would be an excellent option but would require a decent amount of work I think. Not having any exim with support for mysql in Debian has been a problem in the past for Debian users that I know. Thanks, Stephen pgp7KPVnPkPak.pgp Description: PGP signature
Re: png2/3 problem apparently successfully solved with -Bsymbolic
On Wed, Aug 21, 2002 at 12:04:40AM +0200, Luca Barbieri wrote: > On Tue, 2002-08-20 at 23:56, Henrique de Moraes Holschuh wrote: > > On Tue, 20 Aug 2002, Luca Barbieri wrote: > > > On Tue, 2002-08-20 at 23:28, Henrique de Moraes Holschuh wrote: > > > > On Tue, 20 Aug 2002, Luca Barbieri wrote: > > > > > Why? > > > > > Can't we just use it in Debian? > > > > > > > > Are you mad? What happens if the ELF format or gnu upstream start using > > > > that > > > > value for something else? > > > We notify them of the problem. > > > Furthermore the patch can be immediately sent to the glibc maintainers. > > > > This is sort of like asking your wife if she did not like the new color you > > paint*ed* the entire house with. > But that field has at least 32 bits and anyway there are other place > where extensions could be put so it's just a matter of having them put > the extension in another place. > > So yes, it is equivalent to declaring ownership of bit 0 of the > DT_SYMBOLIC value but I don't think this will piss anyone off especially > given the comment from GNU endorsing an extension like this. The comment is old. I don't think that attitude is current. I suspect that Ulrich will not look kindly at this sort of local linker hackery. And, yet again, you're ignoring the technical implementation/maintenance burden of such a patch. There will be _NO_ local linker hacks of this nature in Debian. Drop it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: RFC: OpenLDAP and TLS/SSL
* Oliver Kurth ([EMAIL PROTECTED]) wrote:
> On Wed, Aug 21, 2002 at 03:18:38PM +0200, Torsten Landschoff wrote:
> > - libldap2 is Priority: important
> > - this change will make it depend on libssl0.9.6
> > - libssl0.9.6 is Priority: standard
>
> I would suggest that you make an extra -ssl package, along the lines of
> eg. fetchmai{,-ssl}l. It reduces dependencies and solves your problem. Maybe
> people want ldap, but not ssl.
Oliver,
Personally I think we should do our best to avoid the ssl vs.
non-ssl dual packages. I think much of the point of crypto-in-main
was to do away with having so many dual packages.
I do wonder though why there is a fetchmail/fetchmail-ssl, is there
some good justification for keeping them seperate now that we have
crypto-in-main?
Thanks,
Stephen
pgpNdJz5f8OpA.pgp
Description: PGP signature
Re: RFC: OpenLDAP and TLS/SSL
On Wed, Aug 21, 2002 at 03:52:12PM +0200, Oliver Kurth wrote:
> On Wed, Aug 21, 2002 at 03:18:38PM +0200, Torsten Landschoff wrote:
> > So - what should I do to handle this? Can the priority of libssl0.9.6 be
> > easily changed? Or should I rather provide libldap2{,-ssl}? Technically
> > it would not be a big deal since the interface of libldap2 does not
> > change if you enable ssl. Also I wonder if a slapd package without
> > ssl would be in order. After all there are still people using Debian
> > who are not allowed to import all that crypto stuff from the US.
>
> I would suggest that you make an extra -ssl package, along the lines
> of eg. fetchmai{,-ssl}l. It reduces dependencies and solves your
> problem. Maybe people want ldap, but not ssl.
Now that we have crypto in main, I think we should have fewer -ssl
packages, not more.
--
Colin Watson [EMAIL PROTECTED]
ELF extension for starting symbol search from module dependencies
This is a proposal (including patches) for a GNU extension to the ELF
executable format that adds a flag that causes the dynamic loader to
start searching for symbols referenced by modules with the flag set from
the module itself and its immediate dependencies. If the symbol is not
found in this way, the dynamic linker continues the search as usual.
This extension would be useful to allow to load in the same address
space multiple libraries that define identical symbols, that would be
used by different modules possibly unaware of each other's use of such
symbols.
As a practical example, libpng.so.2 and libpng.so.3 define several
symbols with identical names.
With the current ELF format, other libraries that want to use libpng
symbols will use the symbols of the libpng library that is used by the
main program rather than the one they are compiled with.
Since GTK+ 2.0 uses libpng, this causes a major problem since GTK+
application must be recompiled to use the same libpng version that GTK+
uses.
With this extension, GTK+ could be recompiled with the new flag set and
this problem would be solved.
The extension is implemented using bit 0 of the value attached to the
DT_SYMBOLIC dynamic section entry. Current versions of the GNU dynamic
loader ignore this value and thus consider the object like one compiled
with the -Bsymbolic option.
An option is added to the GNU linker to allow it to produce executables
with the flag set. The proposed name for the option is -Blocal.
This option is treated like -Bsymbolic, but will cause the value
attached to the DT_SYMBOLIC entry to be written as 1 rather than 0.
The attached patches implement the two modifications. The libc patch
also changes the -Bsymbolic list to be statically allocated rather than
malloc'ed and leaked.
Patch for GNU binutils:
--- a/bfd/elflink.h 2002-07-17 20:38:29.0 +0200
+++ b/bfd/elflink.h 2002-08-21 15:27:17.0 +0200
@@ -3042,7 +3042,7 @@ NAME(bfd_elf,size_dynamic_sections) (out
if (info->symbolic)
{
if (! elf_add_dynamic_entry (info, (bfd_vma) DT_SYMBOLIC,
- (bfd_vma) 0))
+ (bfd_vma) (info->local ? 1 : 0)))
return false;
info->flags |= DF_SYMBOLIC;
}
--- a/include/bfdlink.h 2002-07-17 20:38:29.0 +0200
+++ b/include/bfdlink.h 2002-08-21 15:27:58.0 +0200
@@ -216,6 +216,10 @@ struct bfd_link_info
/* true if BFD should pre-bind symbols in a shared object. */
boolean symbolic;
+ /* true if BFD should pre-bind symbols in a shared object and tell
+ dynamic linker to start searching from local dependencies. */
+ boolean local;
+
/* true if BFD should export all symbols in the dynamic symbol table
of an executable, rather than only those used. */
boolean export_dynamic;
--- a/ld/ldmain.c 2002-07-17 20:38:29.0 +0200
+++ b/ld/ldmain.c 2002-08-21 15:27:08.0 +0200
@@ -234,6 +234,7 @@ main (argc, argv)
link_info.emitrelocations = false;
link_info.shared = false;
link_info.symbolic = false;
+ link_info.local = false;
link_info.export_dynamic = false;
link_info.static_link = false;
link_info.traditional_format = false;
--- a/ld/lexsup.c 2002-05-24 00:10:11.0 +0200
+++ b/ld/lexsup.c 2002-08-21 15:26:52.0 +0200
@@ -133,6 +133,7 @@ int parsing_defsym = 0;
#define OPTION_NO_DEFINE_COMMON(OPTION_SPARE_DYNAMIC_TAGS + 1)
#define OPTION_NOSTDLIB(OPTION_NO_DEFINE_COMMON + 1)
#define OPTION_MULTILIB_DIR(OPTION_NOSTDLIB + 1)
+#define OPTION_LOCAL (OPTION_MULTILIB_DIR + 1)
/* The long options. This structure is used for both the option
parsing and the help text. */
@@ -283,6 +284,8 @@ static const struct ld_option ld_options
'\0', NULL, NULL, ONE_DASH },
{ {"Bsymbolic", no_argument, NULL, OPTION_SYMBOLIC},
'\0', NULL, N_("Bind global references locally"), ONE_DASH },
+ { {"Blocal", no_argument, NULL, OPTION_LOCAL},
+ '\0', NULL, N_("Bind global references locally and start searching from
local dependencies"), ONE_DASH },
{ {"check-sections", no_argument, NULL, OPTION_CHECK_SECTIONS},
'\0', NULL, N_("Check section addresses for overlaps (default)"),
TWO_DASHES },
{ {"no-check-sections", no_argument, NULL, OPTION_NO_CHECK_SECTIONS},
@@ -924,6 +927,10 @@ parse_args (argc, argv)
case OPTION_SYMBOLIC:
link_info.symbolic = true;
break;
+ case OPTION_LOCAL:
+ link_info.symbolic = true;
+ link_info.local = true;
+ break;
case 't':
trace_files = true;
break;
Patch for GNU libc:
--- a/elf/dl-deps.c 2001-09-21 16:52:54.0 +0200
+++ b/elf/dl-deps.c 2002-08-21 14:55:17.0 +0200
@@ -261,7 +261,8 @@ _dl_map_object_deps (struct link_map *ma
Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System
> But you will lose a lot of fonctionnalities. This is the main reason > I've never did an ITP for ffmpeg. Yep, it's the same with nvrec. But I discussed this with my mentor, and we're still not clear on this: if a package needs linking with some troublesome package, does this break the DFSG? I guess it depends if you consider "the software" as "the source" or "the binary". > > but since nvrec requires mp3lame I am trouble anyway ;) > BTW the video codecs (MPEG4, MSMPEG4) are DFSG compliant ? depends, unless an xvid version is written, cf. previous point. In practice, this would mean that _anything_ that uses a lame call is not fitted for debian? And yes, I am in trouble, most of the packages that ITP (mostly video related) depend on lame. -- greetz, marc Did you pay the new Support Fee? Key fingerprint = 890C E47F 1589 F240 9CC8 C60C 510A 63D3 D356 2DE1 Linux mykene 2.4.19-pre4 #1 Tue Apr 2 22:47:06 CEST 2002 i686 unknown pgpsjiBzVLcmG.pgp Description: PGP signature
Re: RFC: OpenLDAP and TLS/SSL
Tore Anderson <[EMAIL PROTECTED]> writes: > As far as I know, exim is the only package with priority: important that > depend on libldap2. Exim is GPL, so the author currently does not allow the distribution of binaries which also contain OpenSSL code. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
Re: RFC: OpenLDAP and TLS/SSL
On Wed, Aug 21, 2002 at 03:05:48PM +0100, Colin Watson wrote:
> On Wed, Aug 21, 2002 at 03:52:12PM +0200, Oliver Kurth wrote:
> > On Wed, Aug 21, 2002 at 03:18:38PM +0200, Torsten Landschoff wrote:
> > > So - what should I do to handle this? Can the priority of libssl0.9.6 be
> > > easily changed? Or should I rather provide libldap2{,-ssl}? Technically
> > > it would not be a big deal since the interface of libldap2 does not
> > > change if you enable ssl. Also I wonder if a slapd package without
> > > ssl would be in order. After all there are still people using Debian
> > > who are not allowed to import all that crypto stuff from the US.
> >
> > I would suggest that you make an extra -ssl package, along the lines
> > of eg. fetchmai{,-ssl}l. It reduces dependencies and solves your
> > problem. Maybe people want ldap, but not ssl.
>
> Now that we have crypto in main, I think we should have fewer -ssl
> packages, not more.
Alright, if this is consensus.
Greetings,
Oliver
--
debian/rules http://zork.net/~nick/srom/
pgpEdmy7OQgov.pgp
Description: PGP signature
OpenSSL-linked exim
On Wed, Aug 21, 2002 at 16:19:48 +0200, Florian Weimer wrote: > Exim is GPL, so the author currently does not allow the distribution of > binaries which also contain OpenSSL code. Quoting the NOTICE file from the Exim 3.36 source: :Copyright (c) 1999 University of Cambridge : :This program is free software; you can redistribute it and/or modify it :under the terms of the GNU General Public License as published by the Free :Software Foundation; either version 2 of the License, or (at your option) :any later version. : :In addition, for the avoidance of any doubt, permission is granted to link :this program with OpenSSL or any other library package. This seems to be intended as the kind of exception statement Debian needs in order to be able to include OpenSSL-linked exim binaries (or OpenLDAP-linked-against-OpenSSL exim binaries) in its main archive, although people on debian-legal would probably point out that this doesn't spell out permission to redistribute the result of such linking. Philip, if I recall correctly, previous discussions on debian-legal have resulted in a recommended phrasing for such an exception statement (unfortunately, I can't seem to find a link for it at the moment); would you please consider getting the NOTICE updated along the lines of that phrasing so as to make it clear that redistribution of OpenSSL-linked exim binaries is allowed? Ray -- "Perhaps they spent some of the time writing the patent application. That task was surely harder than thinking of the technique." RMS on Amazon's 1-Click(R) patent, http://linuxtoday.com/story.php3?sn=13652
Re: RFC: OpenLDAP and TLS/SSL
On Wed, 21 Aug 2002, Torsten Landschoff wrote: > Today I was convinced by Stephen Frost that I can just enable SSL support > in the OpenLDAP packages I maintain. No problem so far, but: What can I do to convince you that you need to help me convince the SASL maintainer to have versioned symbols so that LDAP can use SASL as well without segfaulting every damn system using ldap-nss? And of course, version the LDAP symbols as well right now so that at the next LDAP soname change, we don't have ldap causing the trouble sasl is causing now? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: RFC: OpenLDAP and TLS/SSL
On Wed, 21 Aug 2002, Stephen Frost wrote: > I do wonder though why there is a fetchmail/fetchmail-ssl, is there > some good justification for keeping them seperate now that we have > crypto-in-main? Just the fact that I have all but orphaned it and will not spend time joining the two packages right now. RFA bug is in the BTS... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
RE: CST81669854ID - A special excite game
Thank you for your e-mail message to MSN webmaster. We would like to assist you with your question and request you go to the appropriate link below for the product you are inquiring about. The link will take you directly to that product’s online help with instructions on how you may contact us directly. This will provide you the timeliest response. For MSN Internet Access, go to http://supportservices.msn.com/us/help.asp. For Hotmail, go to http://www.hotmail.com, then click “Help” on the upper middle part of your screen. For MSN Messenger, go to http://messenger.microsoft.com, select the applicable Messenger client on the left navigation bar, then click "Help." For MSN Gaming Zone, go to http://support.microsoft.com/directory/content.asp?ID=FH;EN-US;gmz. For MSN MoneyCentral, go to http://support.microsoft.com/directory/content.asp?ID=FH;EN-US;mnyc&SD=GN&FR=0&LN=EN-US. For Microsoft Passport, go to http://www.passport.com/Consumer/ConsumerQA.asp?lc=1033. For Microsoft software applications such as Office or Windows, go to http://support.microsoft.com/directory/. For MSN Web Communities, Member Directory or support for files you have saved to MSN, go to http://communities.msn.com/home, then click “Help” on the upper middle part of your screen. For MSN Chat, go to http://chat.msn.com/default.msnw, then click “Help” on the upper middle part of your screen. For bCentral, go to http://www.bcentral.com/help/overview.asp. For MSNBC, go to http://www.msnbc.com/m/info/help.asp. For help with MSN.com, MSN Search or any other MSN property not mentioned above, go to http://www.msn.com, then click “Help” on the upper right-hand part of your screen. This is an unmonitored e-mail address so please be sure to go to one of the links above.We value your business and thank you for using the Microsoft network of web sites.--- Original Message --- From: debian-devel-announce@lists.debian.org To: [EMAIL PROTECTED] Sent: Aug 20 2002 9:10PM Subject: A special excite gameThis is a special excite gameThis game is my first work.You're the first player.I wish you would enjoy it.
Re: RFC: OpenLDAP and TLS/SSL
On Wed, Aug 21, 2002 at 03:52:12PM +0200, Oliver Kurth wrote:
> Hi Torsten :-)
Hi Oliver :)
> I would suggest that you make an extra -ssl package, along the lines of
> eg. fetchmai{,-ssl}l. It reduces dependencies and solves your problem. Maybe
> people want ldap, but not ssl.
I also like that solution better but it has the drawback of getting
openssl into the base system and I really would like to have a GPL
compatible library there in the long run...
Thanks for your comments
Torsten
pgpJGFDA3owfl.pgp
Description: PGP signature
Re: RFC: OpenLDAP and TLS/SSL
Hi Henrique, On Wed, Aug 21, 2002 at 12:16:38PM -0300, Henrique de Moraes Holschuh wrote: > On Wed, 21 Aug 2002, Torsten Landschoff wrote: > > Today I was convinced by Stephen Frost that I can just enable SSL support > > in the OpenLDAP packages I maintain. No problem so far, but: > > What can I do to convince you that you need to help me convince the SASL > maintainer to have versioned symbols so that LDAP can use SASL as well > without segfaulting every damn system using ldap-nss? And of course, > version the LDAP symbols as well right now so that at the next LDAP soname > change, we don't have ldap causing the trouble sasl is causing now? Just explain why it is the right thing to do. And I would like to stay binary compatible with RedHat etc. if at all possible. cu Torsten pgpd9XmgOWa2h.pgp Description: PGP signature
Re: RFC: OpenLDAP and TLS/SSL
On Wed, 21 Aug 2002, Torsten Landschoff wrote: > Just explain why it is the right thing to do. And I would like to stay > binary compatible with RedHat etc. if at all possible. Well, apps like to be able to use libsasl, and libldap. They also like to use libc. And libc uses nss, which often admins want to use with nss-ldap. So libc ends up dlopening nss-ldap, that links to libldap, and through it, to libsasl. Now, apps often want libsasl2. ldap uses libsasl1. nss segfaults. It is the same libdb2/libdb3 hell we had a while back. The proper fix is to have libsasl with versioned symbols, libldap with versioned symbols (so that we don't go all over the same problem when libldap gets updated -- right now the problem is sasl, not libldap). Every lib and app that links to sasl needs to be recompiled, btw. The idea of versioning libldap now is to reduce the amount of recompiling we would need when the next libldap comes. As for RH, we should get them to version their libs exactly as we would be doing as well. Same for the LSB requirements. Versioning symbols is backwards-compatible: stuff compiled against non-versioned libs will work with the versioned ones. However, stuff compiled against the versioned libs will want a lib with that exact versioning, and it will not accept the non-versioned libs AFAIK. The versioning should use the soname, so that we avoid symbol clashes with other versions of the same libs, AND with other libs as well. This is how glibc does it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: How to transition to G++ 3.2 wthout any breakage
On Sunday 18 August 2002 20:36, Chris Cheney wrote: > On Sun, Aug 18, 2002 at 06:09:18PM +0200, Luca Barbieri wrote: >> For example, how about calc.cx KDE 3.0 packages that are obviously >> necessary for any KDE user? I don't see any mention of GCC 3.2 on their >> text file so I assume that they aren't ported. > Why is KDE 3.0 obviously necessary for any KDE user? Not strictly necessary but it could be good :) My very very short list: getting back from Kde 2.3 (on Kondara) to Kde 2.2 was painful because 2.3 had... 1) Features Better CSS support in Konqueror Kmail allowed you to have fonts for all the headers Konqueror didn't break loading pages without an .htm or .html extension 2) Bugfixes Anti-alias didn't break down randomly (and in konsole as well) Font support didn't break down randomly giving you fonts you don't want Konsole (IIRC) didn't left "dirty spots" on the screen using anti-aliased fonts I admit that Debian Kde mantainer did a very good job, since this is the most stable install of Kde 2.2 I've ever seen (Kde 2.2's kicker from Mandrake did crash one day yes and the second too as well, forcing me to restart it via alt-f2). Anyway, that's only a list for which any kde user could appreciate a supplement of woody packages with the latest release of kde :), actually using Kde 2.2 is good enough. -- Davide Inglima - limaCAT "Mana is rapidly disappearing from the World, even the" "Mana Tree has begun to wither" - Seiken Densetsu 3 http://digilander.iol.it/nekochan/
Re: orphaning most (of my) packages
> razor ('needed' by spamasassin; needs updating)
I've check out the bug list and the package and I'd like to take this
on unless some more qualified wants it.
--
B. Mako Hill
[EMAIL PROTECTED]
http://people.debian.org/~mako/
pgpMmajL0klnq.pgp
Description: PGP signature
Re: apt-get wants to upgrade package to same version?
On Wed, 21 Aug 2002, Brian May wrote: > On Tue, Aug 20, 2002 at 11:19:13PM -0600, Jason Gunthorpe wrote: > > > apt-get knows that it has to get the file from: > > > > > > deb http://snoopy.apana.org.au/~ftp/debian woody main > > > > > > and the md5sum of the Packages file from this source, as quoted > > > before matches exactly. > > > > Er, the md5sum of the deb is not kept by dpkg after you install a .deb. > This MD5sum matches that of the file on the server, exactly: Just ignore the md5sum, it isn't (can't be!) used for anything like this. If you do apt-cache show kerberos4kth1 after installing and look very carefully you will see that the two listed 1.1-11-2 stanzas are subtly different. The problem is that your package file does not accurately reflect the contents of the .deb. That is all. Jason
Re: Bug#157719: ITP: ffmpeg -- FFmpeg Streaming Multimedia System
Marc Leeman <[EMAIL PROTECTED]> writes: [...] > And yes, I am in trouble, most of the packages that ITP (mostly video > related) depend on lame. Marc ask in -legal. Christian
Keysigning/Meet in Italy
Hi all, I'll be travelling in Italy for a few weeks this September and I thought it might be fun to meet some Debian developers there for coffee and keysigning. Reply off-list if interested. Thanks! -- Brett pgplcBE5su1fw.pgp Description: PGP signature
Re: /bin/login hanging around
Russell Coker <[EMAIL PROTECTED]> writes: > Why is it that /bin/login seems to hang around for the duration of the user's > session on other distributions but not on Debian? Traditional Unix does it the we way do; login exec's the user's shell, etc. Other distributions seem to come with whiz-bang pam modules that need to do cleanup on logout, so login forks to run pam_close_session().; we don't configure things like that by default. If you love the other distribution's behavior, set CLOSE_SESSIONS to yes in /etc/login.defs. This may become a default in future versions of the shadow package. kcr
Re: RFC: OpenLDAP and TLS/SSL
On Aug 21, Colin Watson <[EMAIL PROTECTED]> wrote: >Now that we have crypto in main, I think we should have fewer -ssl >packages, not more. Agreed. -- ciao, Marco
When bind9 reinstalls, no db.root
I'm confused by the behavior of apt-get install --reinstall. I found out yesterday that the /etc/bind/db.root file was missing on my name server. I was able to recover by linking to an old copy and restarting bind9. However, when deleted the link and performed the --reinstall command, the db.root file was not restored. I verified that the file exists in the bind9 DEB and, in fact, is listed in the bind9.list file. My question is this. How can the reinstall fail to install the file when there is no extant file with the same name?
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 12:09:57PM -0700, Marc Singer wrote: > I'm confused by the behavior of apt-get install --reinstall. I found > out yesterday that the /etc/bind/db.root file was missing on my name > server. I was able to recover by linking to an old copy and > restarting bind9. However, when deleted the link and performed the > --reinstall command, the db.root file was not restored. Sounds like you want dpkg --force-confmiss. -- Colin Watson [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 08:24:58PM +0100, Colin Watson wrote: > On Wed, Aug 21, 2002 at 12:09:57PM -0700, Marc Singer wrote: > > I'm confused by the behavior of apt-get install --reinstall. I found > > out yesterday that the /etc/bind/db.root file was missing on my name > > server. I was able to recover by linking to an old copy and > > restarting bind9. However, when deleted the link and performed the > > --reinstall command, the db.root file was not restored. > > Sounds like you want dpkg --force-confmiss. I wouldn't expect that since the documentation states: confmiss: Always install a missing configuration file. This is dangerous, since it means not pre- serving a change (removing) made to the file. How could it be dangerous to install a *missing* configuration file?
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 12:32:00PM -0700, Marc Singer wrote: > > > I'm confused by the behavior of apt-get install --reinstall. I found > > > out yesterday that the /etc/bind/db.root file was missing on my name > > > server. I was able to recover by linking to an old copy and > > > restarting bind9. However, when deleted the link and performed the > > > --reinstall command, the db.root file was not restored. > > > > Sounds like you want dpkg --force-confmiss. > > I wouldn't expect that since the documentation states: > > confmiss: Always install a missing configuration > file. This is dangerous, since it means not pre- > serving a change (removing) made to the file. > > How could it be dangerous to install a *missing* configuration file? If the default configuration data in the file do something you don't want. -- 2. That which causes joy or happiness.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote: > > > Sounds like you want dpkg --force-confmiss. > > > > I wouldn't expect that since the documentation states: > > > > confmiss: Always install a missing configuration > > file. This is dangerous, since it means not pre- > > serving a change (removing) made to the file. > > > > How could it be dangerous to install a *missing* configuration file? > > If the default configuration data in the file do something you don't want. For example...
Re: When bind9 reinstalls, no db.root
On 21-Aug-02, 14:42 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote: > On Wed, Aug 21, 2002 at 12:32:00PM -0700, Marc Singer wrote: > > How could it be dangerous to install a *missing* configuration file? > > If the default configuration data in the file do something you don't want. > To be, perhaps, a little more explicit: there are programs for which the existence of an empty configuration file means something completely different than a missing a configuration file[1]. Thus, for dpkg conffile handling, removing a configuration file is a legitimate "edit". Steve [1] E.g. /etc/cron.allow (crontab(1)). -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > > > > Sounds like you want dpkg --force-confmiss. > > > > > > I wouldn't expect that since the documentation states: > > > > > > confmiss: Always install a missing configuration > > > file. This is dangerous, since it means not pre- > > > serving a change (removing) made to the file. > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > If the default configuration data in the file do something you don't want. > > For example... I don't know, but I know plenty of default configuration files that set something up. Maybe "dangerous" is a bit extreme choice of words, but the negative effect isn't implausible. -- 2. That which causes joy or happiness.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 10:04:28PM +0200, Josip Rodin wrote: > On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > > > > > Sounds like you want dpkg --force-confmiss. > > > > > > > > I wouldn't expect that since the documentation states: > > > > > > > > confmiss: Always install a missing configuration > > > > file. This is dangerous, since it means not pre- > > > > serving a change (removing) made to the file. > > > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > > > If the default configuration data in the file do something you don't want. > > > > For example... > > I don't know, but I know plenty of default configuration files that set > something up. Maybe "dangerous" is a bit extreme choice of words, but the > negative effect isn't implausible. Without a single example, I don't see how installing a configuration file where there is none can have *any* affect on the system. Admittedly, replacing a configuration file may be undesirable. Moreover, in this case, db.root is not really a configuration file. It is more like a library. If I ask for a package to be reinstalled, most users will expect all of the programs and libraries to be installed. Are you sure you agree that db.root should not be reinstalled with bind's programs? > > -- > 2. That which causes joy or happiness.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 03:00:52PM -0500, Steve Greenland wrote: > On 21-Aug-02, 14:42 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote: > > On Wed, Aug 21, 2002 at 12:32:00PM -0700, Marc Singer wrote: > > > How could it be dangerous to install a *missing* configuration file? > > > > If the default configuration data in the file do something you don't want. > > > > To be, perhaps, a little more explicit: there are programs for which > the existence of an empty configuration file means something completely > different than a missing a configuration file[1]. Thus, for dpkg > conffile handling, removing a configuration file is a legitimate "edit". > It would help to have an example. However, even if there is an example I don't see how db.root fits in this category.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote: > > > > Sounds like you want dpkg --force-confmiss. > > > > > > I wouldn't expect that since the documentation states: > > > > > > confmiss: Always install a missing configuration > > > file. This is dangerous, since it means not pre- > > > serving a change (removing) made to the file. > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > If the default configuration data in the file do something you don't want. > > For example... autofs. First thing I do when I install autofs in at networked environmemt is rm /etc/auto.* because I want to use the NIS maps. Greetings, Oliver -- Oliver Kurth mailto:[EMAIL PROTECTED] http://leinekanal.de pgps2x4kwT8dp.pgp Description: PGP signature
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 01:10:29PM -0700, Marc Singer wrote: > On Wed, Aug 21, 2002 at 03:00:52PM -0500, Steve Greenland wrote: > > To be, perhaps, a little more explicit: there are programs for which > > the existence of an empty configuration file means something completely > > different than a missing a configuration file[1]. Thus, for dpkg > > conffile handling, removing a configuration file is a legitimate "edit". > > It would help to have an example. However, even if there is an > example I don't see how db.root fits in this category. Unfortunately there's no way for a package to override this aspect of dpkg's conffile handling. It would have to be handled entirely in the maintainer scripts in some different (and careful!) way. -- Colin Watson [EMAIL PROTECTED]
Re: RFC: OpenLDAP and TLS/SSL
On Wed, 2002-08-21 at 19:13, Henrique de Moraes Holschuh wrote: > On Wed, 21 Aug 2002, Torsten Landschoff wrote: > > Just explain why it is the right thing to do. And I would like to stay > > binary compatible with RedHat etc. if at all possible. > > Well, apps like to be able to use libsasl, and libldap. They also like to > use libc. And libc uses nss, which often admins want to use with nss-ldap. > > So libc ends up dlopening nss-ldap, that links to libldap, and through it, > to libsasl. > > Now, apps often want libsasl2. ldap uses libsasl1. nss segfaults. It is > the same libdb2/libdb3 hell we had a while back. > > The proper fix is to have libsasl with versioned symbols, libldap with > versioned symbols (so that we don't go all over the same problem when > libldap gets updated -- right now the problem is sasl, not libldap). > > Every lib and app that links to sasl needs to be recompiled, btw. The idea > of versioning libldap now is to reduce the amount of recompiling we would > need when the next libldap comes. This is an another problem that would be easily and compatibly solved by my ELF extension (until the library gets properly fixed upstream). Anyway we really need to implant into the library developers' brains the concept that symbol names must be *globally* unique, not just unique to filename and that they either put the version number in the symbol (e.g. sasl1_explode vs. sasl2_explode) and use #define's to keep source compatibility or they use GNU/Solaris versioned symbols. We should also alert upstream of this kind of problems _before_ new versions get released and binary compatibility makes them untouchable. signature.asc Description: This is a digitally signed message part
Thank You!
Thank you for submitting your information to Delta Dallas. Your resume or request for information has been forwarded to the appropriate person. If, after review, it is determined that there is a good match between your skills and any current opportunities one of our Recruiters will be in contact with you via email or telephone. Unfortunately, due to the high number of responses that we receive on a daily basis we are not able to respond to each and every query. If there is not an immediate opportunity that matches your skills we will keep your information on file. Again, thank you for your interest.
Re: orphaning most (of my) packages
Hello, > libphp-adodb (a php database abstraction layer, required for 'acidlab') I'll like to adopte the libphp-adodb package from you. I have created the packages with the new upstream version. You can download it from: ftp://jade.viastore.de/debian/pool/main/libp/libphp-adodb/ All current outstanding bugs are fixed with this version. So, if noone is interessted... Bye Thorsten -- Thorsten Sauter <[EMAIL PROTECTED]> (Is there life after /sbin/halt -p?) pgpCS1m6fa0ip.pgp Description: PGP signature
xmmsarts
(d-devel please cc me, I'm not subscribed) On Wed, 2002-08-21 at 13:03, Steven Gardner wrote: > I am checking to see if you are planning to fix the package bug with > xmmsarts and when you think you would have the fix done. I'm a little stuck for bandwidth / a machine that isn't on KDE 3 yet (i.e. has KDE 2's libarts-dev) at the moment. If someone wants to just do this: * Put build-deps back to libarts-dev for the moment, as libarts1(-dev) (i.e. KDE 3) doesn't seem to be in unstable yet (closes: #153595) i.e. put that one build-dep back to libarts-dev (>= 4:2.2.2-1), and NMU, it would be much appreciated. Thanks, -- Chris Boyle - Debian Developer (cmb) - aewm++, sapphire, xmmsarts GPG: B7D86E0F, MSN: [EMAIL PROTECTED], ICQ: 24151961, AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on openprojects.net
Sympa package: Seeking for co-developers
Hi, I'm seeking for co-developers who have some interests in the sympa mailing list manager. I'm currently not using it but I know very well about the package so I think I can still be helpful in maintaining future versions. People who 1/ are running Sympa on their servers (***) 2/ have already used Debconf for packaging 3/ have basic Perl knowledge 4/ have basic MySQL/PostgreSQL knowledge (admin) are welcome. Not all skills are required but the more the better, as usual. Please contact me if interested. Thanks in advance. Cheers, -- Jérôme Marant http://marant.org
Re: apt-get wants to upgrade package to same version?
On Wed, Aug 21, 2002 at 11:18:09AM -0600, Jason Gunthorpe wrote: > If you do apt-cache show kerberos4kth1 after installing and look very > carefully you will see that the two listed 1.1-11-2 stanzas are subtly > different. The problem is that your package file does not > accurately reflect the contents of the .deb. That is all. I claim though that it it should be identical to the .deb file, because I ran dpkg-scanpackages on it myself, and haven't updated anything since (besides, if I had updated something, the MD5sum check would fail wouldn't it?) Packages entry: Package: kerberos4kth1 Version: 1.1-11-2 Priority: optional Section: net Maintainer: Mikael Andersson <[EMAIL PROTECTED]> Architecture: all Filename: ./pool/krb4/kerberos4kth1_1.1-11-2_all.deb Size: 57786 MD5sum: 330d49310a3264f037875e06a1328458 Description: Dummy library package for Kerberos4 From KTH. This is a dummy package. It should be safe to remove it. installed-size: 76 source: krb4 [504] [snoopy:unstable:bam] /home/ftp/pub/debian >dpkg -I ./pool/krb4/kerberos4kth1_1.1-11-2_all.deb new debian package, version 2.0. size 57786 bytes: control archive= 701 bytes. 288 bytes,10 lines control 229 bytes, 3 lines md5sums 281 bytes, 9 lines * postinst #!/bin/sh 208 bytes, 7 lines * prerm#!/bin/sh Package: kerberos4kth1 Version: 1.1-11-2 Section: net Priority: optional Architecture: all Installed-Size: 76 Maintainer: Mikael Andersson <[EMAIL PROTECTED]> Source: krb4 Description: Dummy library package for Kerberos4 From KTH. This is a dummy package. It should be safe to remove it. What is different? I wildly speculate that apt-get is making the assumption that package version 1.1-11-2 will be exactly the same regardless of where it was downloaded from, and is comparing the deb file against the Packages entry from the unused/wrong source (priority==-1). -- Brian May <[EMAIL PROTECTED]>
Re: apt-get wants to upgrade package to same version?
On Thu, 22 Aug 2002, Brian May wrote: > I ran dpkg-scanpackages on it myself, and haven't updated anything > since (besides, if I had updated something, the MD5sum check would fail > wouldn't it?) Nope. > Description: Dummy library package for Kerberos4 From KTH. > This is a dummy package. It should be safe to remove it. > installed-size: 76 > source: krb4 vs > Description: Dummy library package for Kerberos4 From KTH. > This is a dummy package. It should be safe to remove it. > What is different? The description? Looks like dpkg-scanpackages foobar'd you. Jason
Re: apt-get wants to upgrade package to same version?
On Wed, Aug 21, 2002 at 03:44:54PM -0600, Jason Gunthorpe wrote: > > Description: Dummy library package for Kerberos4 From KTH. > > This is a dummy package. It should be safe to remove it. > > installed-size: 76 > > source: krb4 If you mean the spacing is different, that is my fault (I use vim in mutt, and it automatically indents stuff pasted in using X... Arrghhh... Need to disable that by default in my config I think). Package: kerberos4kth1 Version: 1.1-11-2 Priority: optional Section: net Maintainer: Mikael Andersson <[EMAIL PROTECTED]> Architecture: all Filename: ./pool/krb4/kerberos4kth1_1.1-11-2_all.deb Size: 57786 MD5sum: 330d49310a3264f037875e06a1328458 Description: Dummy library package for Kerberos4 From KTH. This is a dummy package. It should be safe to remove it. installed-size: 76 source: krb4 vs [504] [snoopy:unstable:bam] /home/ftp/pub/debian >dpkg -I ./pool/krb4/kerberos4kth1_1.1-11-2_all.deb new debian package, version 2.0. size 57786 bytes: control archive= 701 bytes. 288 bytes,10 lines control 229 bytes, 3 lines md5sums 281 bytes, 9 lines * postinst #!/bin/sh 208 bytes, 7 lines * prerm#!/bin/sh Package: kerberos4kth1 Version: 1.1-11-2 Section: net Priority: optional Architecture: all Installed-Size: 76 Maintainer: Mikael Andersson <[EMAIL PROTECTED]> Source: krb4 Description: Dummy library package for Kerberos4 From KTH. This is a dummy package. It should be safe to remove it. The description looks the same now: Description: Dummy library package for Kerberos4 From KTH. This is a dummy package. It should be safe to remove it. Description: Dummy library package for Kerberos4 From KTH. This is a dummy package. It should be safe to remove it. -- Brian May <[EMAIL PROTECTED]>
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 10:21:17PM +0200, Oliver Kurth wrote: > On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > > On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote: > > > > > Sounds like you want dpkg --force-confmiss. > > > > > > > > I wouldn't expect that since the documentation states: > > > > > > > > confmiss: Always install a missing configuration > > > > file. This is dangerous, since it means not pre- > > > > serving a change (removing) made to the file. > > > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > > > If the default configuration data in the file do something you don't want. > > > > For example... > > autofs. First thing I do when I install autofs in at networked environmemt is > rm /etc/auto.* > because I want to use the NIS maps. I don't think that example works for all of the auto.* files. The master file references the other files. Removing the master eliminates the references to the others. However, adding auto.furball won't affect autofs unless auto.master references it. > > Greetings, > Oliver > -- > Oliver Kurth > mailto:[EMAIL PROTECTED] http://leinekanal.de
Re: RFC: OpenLDAP and TLS/SSL
On Wed, 21 Aug 2002, Luca Barbieri wrote: > This is an another problem that would be easily and compatibly solved by > my ELF extension (until the library gets properly fixed upstream). Yes and no. Versioned symbols are here NOW and can be used NOW, and they fix the issue cleanly without drawbacks: they are as painful as a do-it-only-once global soname increase (which is quite painful though). It has the potential of encoding C++ ABI (or any other identifiers we need) information as well, should that be desired. -Bsymbolic (your modified version of it) cannot fix that. > concept that symbol names must be *globally* unique, not just unique to > filename and that they either put the version number in the symbol (e.g. > sasl1_explode vs. sasl2_explode) and use #define's to keep source > compatibility or they use GNU/Solaris versioned symbols. Yes. We really should simply have *all* libraries using versioned symbols. The version symbol "tag" could always be at least the library soname (i.e. the ABI number, and library name). Is there a reason for not doing the above? It's not like it would be difficult to do (although it means a mass-recompile, but it certainly needs not to be done all in one day...). We could just try to set a standard that linux-based OSes *distributions* always versions its symbols with the ABI soname, and that's it... That won't fix the breakage caused by C++ compilers, unfortunately. The C++ ABI number would have to be added to the library versioning tag, too. It can be done without changes to the linkers, by the makefiles [we just need a way to query the compiling environment which stuff we should prefix/suffix the symbol versioning with]. It's cleaner to just have another ELF field with the compiler ABI, and have gcc and other C++ compilers for linux add that automatically... > We should also alert upstream of this kind of problems _before_ new > versions get released and binary compatibility makes them untouchable. ABIs are not really upstream's responsability... unless it is a Linux-only package, when upstream *might* take care of it, if they want to. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 09:21:39PM +0100, Colin Watson wrote: > On Wed, Aug 21, 2002 at 01:10:29PM -0700, Marc Singer wrote: > > On Wed, Aug 21, 2002 at 03:00:52PM -0500, Steve Greenland wrote: > > > To be, perhaps, a little more explicit: there are programs for which > > > the existence of an empty configuration file means something completely > > > different than a missing a configuration file[1]. Thus, for dpkg > > > conffile handling, removing a configuration file is a legitimate "edit". > > > > It would help to have an example. However, even if there is an > > example I don't see how db.root fits in this category. > > Unfortunately there's no way for a package to override this aspect of > dpkg's conffile handling. It would have to be handled entirely in the > maintainer scripts in some different (and careful!) way. Is the feature triggered for files appearing in /etc? > > -- > Colin Watson [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
Marc Singer <[EMAIL PROTECTED]> writes: > Without a single example, I don't see how installing a configuration > file where there is none can have *any* affect on the system. > Admittedly, replacing a configuration file may be undesirable. > There might be (and surely are) programs, that will, given the lack of a config file, use their compiled-in defaults. So the installation of a config file will change the configuration of the program, unless the installed config file contains just the (also compiled-in) defaults. Regards, Andy -- Andreas Rottmann | [EMAIL PROTECTED]| [EMAIL PROTECTED] | [EMAIL PROTECTED] http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 03:12:37PM -0700, Marc Singer wrote: > On Wed, Aug 21, 2002 at 09:21:39PM +0100, Colin Watson wrote: > > On Wed, Aug 21, 2002 at 01:10:29PM -0700, Marc Singer wrote: > > > It would help to have an example. However, even if there is an > > > example I don't see how db.root fits in this category. > > > > Unfortunately there's no way for a package to override this aspect of > > dpkg's conffile handling. It would have to be handled entirely in the > > maintainer scripts in some different (and careful!) way. > > Is the feature triggered for files appearing in /etc? The documentation on conffiles is in section 11.7 of policy. -- Colin Watson [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > For example... _Any_ program whose default (Debian) configuration file specifies options which are different from the compiled-in defaults. For specific examples, see almost any program on your system with a global config file. -- - mdz
Re: When bind9 reinstalls, no db.root
On Wednesday, August 21, 2002, at 09:08 PM, Marc Singer wrote: Without a single example, I don't see how installing a configuration file where there is none can have *any* affect on the system. Admittedly, replacing a configuration file may be undesirable. In addition to the example of configuration files that change compiled in defaults that has already been mentioned consider things like logcheck or apache2 which scan a directory processing all files within it.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 07:06:22PM -0400, Matt Zimmerman wrote: > On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > > > For example... > > _Any_ program whose default (Debian) configuration file specifies options > which are different from the compiled-in defaults. > > For specific examples, see almost any program on your system with a global > config file. Hand-waving doesn't constitute an example. > > -- > - mdz > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 04:23:16PM -0700, Marc Singer wrote: > On Wed, Aug 21, 2002 at 07:06:22PM -0400, Matt Zimmerman wrote: > > _Any_ program whose default (Debian) configuration file specifies > > options which are different from the compiled-in defaults. > > > > For specific examples, see almost any program on your system with a > > global config file. > > Hand-waving doesn't constitute an example. How about bash? A missing /etc/bash.bashrc has a different effect than the default /etc/bash.bashrc. A missing /etc/bash_completion has a different effect than the default /etc/bash_completion. Missing /etc/skel/.bash* will avoid having any .bash* files copied into new users' home directories. I think that you have bash installed (assuming you run Debian), so you now have an example that you can experiment with on your own system. And you didn't have to go to the trouble of figuring it out for yourself. You may shut up now. -- - mdz
Re: RFC: OpenLDAP and TLS/SSL
On Thu, 2002-08-22 at 00:11, Henrique de Moraes Holschuh wrote: > On Wed, 21 Aug 2002, Luca Barbieri wrote: > > This is an another problem that would be easily and compatibly solved by > > my ELF extension (until the library gets properly fixed upstream). > > Yes and no. Versioned symbols are here NOW and can be used NOW, and they fix > the issue cleanly without drawbacks: they are as painful as a > do-it-only-once global soname increase (which is quite painful though). I just got a Great Idea(tm). This is the explanation from Ulrich Drepper: In case only the object file with the reference does not use versioning but the object with the definition does, then the reference only matches the base definition. The base definition is the one with index numbers 1 and 2 (1 is the unspecified name, 2 is the name given later to the baseline of symbols once the library started using symbol versioning). The static linker is guaranteed to use this indeces for the base definition. If there is no symbol definition with such an version index and there is exactly one version for which this symbol is defined, then this version is accepted (this was mostly implemented for dlopen() calls as it will normally not happen when the static linker is used). However this the problem: Otherwise, if more then one version of the symbol is available, none of the definitions is accepted and the search continues with the next object. If we modify the loader so that it instead accepts the first one, this first one will be correct for the main program. So if we modify the loader to do this and recompile the conflicting libraries and the ones that use them we can address both the short-term and the long-term issues while still allowing symbols to overridden. With unmodified loaders and multiple versioned libraries in a program, the binaries will fail until they are recompiled to use versioned symbols. However this isn't worse than the current situation that causes them to pseudorandomly fail. Furthermore, since the binary would fail I don't think that anything relies on the existing behavior. Also, there is no chance of creating incompatible ELF formats since the format isn't changed. How about this? This seems better than using my patch. Am I missing something? signature.asc Description: This is a digitally signed message part
Re: When bind9 reinstalls, no db.root
On 21-Aug-02, 15:10 (CDT), Marc Singer <[EMAIL PROTECTED]> wrote: > It would help to have an example. I could have sworn I had a footnote about /etc/cron.allow, with a reference to the appropriate manpage :-). Okay, it's not the *best* example, because I don't actually ship a cron.allow, but the point is there: A missing cron.allow permits everybody to use crontab, while an empty cron.allow forbids use of crontab by anybody (except root, of course). Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: RFC: OpenLDAP and TLS/SSL
I forgot to consider what happens when a Debian-built versioned binary is used with a non-Debian no-versioned library. Here is Drepper's explanation: The last case is if the object with the references uses symbol versions but the object with the definitions has none. In this case a matching symbol is accepted unless the object's name matches the one in the Elfxx_Verneed entry. In the latter case this is a fatal error. In fact, this should never have happened in the first place since it would mean the list of required symbols was not correct and the steps required in the last section therefore haven't detected a too old version of an object file. It seems that this would cause an error... Argh. I'll look at the source to check whether this is true. If it is, we also have to somehow setup the toolchain so that binaries are built unversioned until everyone adopts versioning (or until everyone patches the dynamic linker to avoid this fatal error). signature.asc Description: This is a digitally signed message part
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 07:32:04PM -0400, Matt Zimmerman wrote: > On Wed, Aug 21, 2002 at 04:23:16PM -0700, Marc Singer wrote: > > > On Wed, Aug 21, 2002 at 07:06:22PM -0400, Matt Zimmerman wrote: > > > _Any_ program whose default (Debian) configuration file specifies > > > options which are different from the compiled-in defaults. > > > > > > For specific examples, see almost any program on your system with a > > > global config file. > > > > Hand-waving doesn't constitute an example. > > How about bash? A missing /etc/bash.bashrc has a different effect than the > default /etc/bash.bashrc. A missing /etc/bash_completion has a different > effect than the default /etc/bash_completion. Missing /etc/skel/.bash* will > avoid having any .bash* files copied into new users' home directories. I > think that you have bash installed (assuming you run Debian), so you now > have an example that you can experiment with on your own system. And you > didn't have to go to the trouble of figuring it out for yourself. > > You may shut up now. This terse reply is obviously inappropriate. If you are annoyed, stop writing. I was asking for real examples in order to discuss how the case of bind and db.root is *not* a member of that set and how there may be a genuine problem with the handling of installing over missing configuration files. As far as I can tell there is no way to pass --force-confmiss to dpkg when using apt-get. Perhaps this is the only real omission. Still, breaking bind's access to root name servers is particularly troublesome because it may tend to break all net access. It may be worthwhile to remove db.root from the list of configuration files. Especially, because this list isn't something anyone should need to change.
Re: RFC: OpenLDAP and TLS/SSL
Yes, unfortunately that situation triggers an assert... what a great feature :( So apart from the need to remove the unversioned-uses-versioned error, we also to produce unversioned binaries. The simplest way to this is is IMHO to add a /usr/lib/dev directory and make it the first directory searched by ld (this should be possible by either wrapping ld or adding it to linker scripts in the ld source). Then when we build the library package, we build a versioned library for the main package and an unversioned one for the -dev package that gets put in /usr/lib/dev (rather than relinking, we may write a tool to strip the versioning info). This way, Debian/non-Debian unversioned binaries work properly with Debian multiple versioned libraries because we patch the dynamic loader (easy to do) and Debian binaries work with non-Debian libraries because they are still unversioned. How about this? signature.asc Description: This is a digitally signed message part
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 06:39:55PM -0500, Steve Greenland wrote: > On 21-Aug-02, 15:10 (CDT), Marc Singer <[EMAIL PROTECTED]> wrote: > > It would help to have an example. > > I could have sworn I had a footnote about /etc/cron.allow, with a > reference to the appropriate manpage :-). Okay, it's not the *best* > example, because I don't actually ship a cron.allow, but the point is > there: A missing cron.allow permits everybody to use crontab, while an > empty cron.allow forbids use of crontab by anybody (except root, of > course). It does appear that there are a couple of good examples. In fact, this is not one of them since what you ought to ship is a cron.allow that blocks everything, right? That way the default behavior is obvious to someone browsing the configuration. As far as I can tell, there aren't many 'dangerous' examples. A package may install a crontab file in cron.d that is deleted by the user. Apparently, apache2 performs directory scanning for configuration files, too. Examples such as BASH are definitely *not* dangerous since the default file contains a single, innocuous directive. As I wrote in another message, given that there is an override switch in dpkg, that switch would be helpful if available in apt-get.
Bug#157799: ITP: anubis -- An outgoing mail processor.
Package: wnpp Version: N/A; reported 2002-08-22 Severity: wishlist * Package name: anubis Version : 3.4.0 Upstream Author : Wojciech Polak <[EMAIL PROTECTED]> * URL : http://anubis.sourceforge.net/ * License : GPL Description : An outgoing mail processor. Anubis is an outgoing mail processor, and provides the SMTP tunnel between the MUA and the MTA. It features extended regular expressions support, PerlRE support, TLS/SSL support, and GnuPG support. It is ka kind of next generation of premail, but less cypherpunk oriented and more powerful. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux FUCKUP.fantastyka.net 2.4.18 #3 pon sie 19 16:24:30 CEST 2002 i686 Locale: LANG=pl_PL.ISO-8859-2, LC_CTYPE=pl_PL.ISO-8859-2
exim vs. exim-tiny (was: RFC: OpenLDAP and TLS/SSL)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 21 August 2002 2:57 pm, Stephen Frost wrote: > * Torsten Landschoff ([EMAIL PROTECTED]) wrote: > > Today I was convinced by Stephen Frost that I can just enable SSL support > > in the OpenLDAP packages I maintain. No problem so far, but: > > > > - libldap2 is Priority: important > > - this change will make it depend on libssl0.9.6 > > - libssl0.9.6 is Priority: standard > > [...] > > > Any suggestions welcome > > Hey all, > > I already explained my feelings about this to Torsten but since we're > moving it to -devel I'll lay out my thoughts here too. > > First off, crypto is important to us and I think we tend to feel that > it is important for our users as well. Thus, I see libssl0.9.6 being > made Priority: Important as a good option. > > If there are too many other issues with making libssl0.9.6 important > (though it only Depends: on libc and isn't very big?) then I would > think that we are very concerned about the size and would therefore > recommend that ldap support be removed from exim or exim be split into > exim-tiny for Important and exim-big with everything enabled. Of > course, exim support being modified to be modular would be an > excellent option but would require a decent amount of work I think. > > Not having any exim with support for mysql in Debian has been a > problem in the past for Debian users that I know. > As the main person in #exim on OPN, I've seen several people ask about exim with mysql or postgres support. There is a bug about having mysql support in exim in debian. (Wouldn't it be nice to have voting in debbugs?). I realise that exim does not have the sanest of build systems, but is there any chance of getting two exim packages built? Maybe the ability to choose a different patch to enable mysql et al support via a envvar. That way I can instruct people to rebuild exim. - -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9ZDvSYsCKa6wDNXYRAoU3AJ9WNEf5881o6GOp3aJxBrYj1cGbrwCfYEV5 KaZa7qbKprMMjdNqsf4l1q4= =Ck+m -END PGP SIGNATURE-
Re: When bind9 reinstalls, no db.root
> Still, breaking bind's access to root name servers is particularly > troublesome because it may tend to break all net access. It may be > worthwhile to remove db.root from the list of configuration files. > Especially, because this list isn't something anyone should need to > change. I beg to disagree. Changing db.root is the primary way to use an alternate DNS root (either for an all-internal DNS, or to utilize an alternate DNS root than NetSol's). Just because you can't see why something might be configured differently doesn't mean other people can't.
Re: RFC: OpenLDAP and TLS/SSL
Both problems can be solved by simply writing the version scripts so
that only a version tag is mentioned in each:
libpng2.ver:
LIBPNG_2.0 {global: png_*);
libpng3.ver:
LIBPNG_3.0 {global: png_*);
However, we'll still get a warning message if versioned binaries are
used with unversioned libraries.
BTW, libraries that use one the conflicting ones must be compiled with
-fPIC, but that should already happen.
signature.asc
Description: This is a digitally signed message part
A better solution for png/sasl/etc problems using versioned symbols
This an alternative solution to the -Bsymbolic/-Blocal approach that I
exposed before. It doesn't require any loader/linker code modifications
but requires more work by the library maintainers and is better done
with upstream consensus (but this isn't strictly necessary).
First, we must define versioned symbols for the conflicting libraries.
This must be done by creating version scripts with only one version tag
(otherwise unversioned objects will not be able to bind to versioned
symbols).
Here is an example: (note: this might not be completely correct for
libpng)
libpng2.ver:
LIBPNG_2.0 {global: png_*; local: *;};
libpng3.ver:
LIBPNG_3.0 {global: png_*; local: *;};
Then, a --version-script argument should be added to LDFLAGS and the
affected libraries and all the libraries that use them should be
rebuilt.
After we do this, however, we have a problem: programs linking to the
libraries will be built with versioned symbols.
This reduces binary compatibility since having objects with different
versions schemes will cause failure and having versioned objects using
unversioned ones will cause warning messages.
This can be easily fixed by creating a /usr/lib/dev directory and
modifying the GNU binutils package so that it is in front of the linker
search path.
Then, conflicting libraries can be built in a normal versioned version
and in an unversioned one that is installed in /usr/lib/dev and put in
the -dev package for the library.
Not building programs with versioned symbols works because the library
they use is always the first one in the search path. However, if the
program is unversioned and more than one of the conflicting libraries is
used, all libraries that are or use one of the conflicting libraries
which is not the one used by the main program must be compiled with
-fPIC (otherwise the library symbols will be resolved by the undefined
symbols in the main program resulting in the wrong library version being
used). This should already be the case for all libraries so this
shouldn't be a problem.
signature.asc
Description: This is a digitally signed message part
Bug#157810: [ITP]: passivetex -- Macros to process XSL formatting objects
Package: wnpp Severity: wishlist Package name: passivetex Version : 1.18 Upstream Author : Sebastian Rahtz <[EMAIL PROTECTED]> URL : http://users.ox.ac.uk/~rahtz/passivetex/ License : BSD like (see below) Description : Macros to process XSL formatting objects PassiveTeX is a library of TeX macros which can be used to process an XML document which results from an XSL transformation to formatting objects. This package need xmltex >= 1.9 (not currently in Debian). I will contact xmltex maintainer about this. Working debs can be found at http://www.tzone.org/~fabien/debian/. LICENSE: % Copyright 2002 Sebastian Rahtz/Oxford University % <[EMAIL PROTECTED]> % % Permission is hereby granted, free of charge, to any person obtaining % a copy of this software and any associated documentation files (the % ``Software''), to deal in the Software without restriction, including % without limitation the rights to use, copy, modify, merge, publish, % distribute, sublicense, and/or sell copies of the Software, and to % permit persons to whom the Software is furnished to do so, subject to % the following conditions: % % The above copyright notice and this permission notice shall be included % in all copies or substantial portions of the Software.
Re: Accepted e16menuedit 0.1-5 (i386 source)
On Wed, 21 Aug 2002 23:47:17 -0400, Jon Bernard <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: upload sponsored by [EMAIL PROTECTED] another best packaging practice -- Oohara Yuuma <[EMAIL PROTECTED]> Debian developer PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695 Better just encrypt it all in your head :-). --- Derrick 'dman' Hudson, about encryption without any physical medium
