unsubscribe
Best regards / Mit freundlichen Grüßen Mathieu Fluhr Mathieu Fluhr IT Administration Ahead Software AG phone: +49 (0)7248 911 811 (direct line) Im Stoeckmaedle 18fax: +49 (0)7248 911 888 76307 Karlsbademail: [EMAIL PROTECTED] Germany webwww.nero.com
Re: Suivi par CVS d'un paquet utilisant dbs ?
Le mardi 20 août 2002 à 19:24, d'après Jérôme Marant [EMAIL PROTECTED] : À mon sens, DBS n'est bien que s'il y a plusieurs tarball upstream. Dans mon cas, l'auteur du paquet Debian officiel utilise DBS. Je ne fais que maintenir des modifications locales, et le but est de pouvoir les adapter facilement aux futures versions du paquet officiel : je ne vais donc pas tout changer juste pour ne pas utiliser DBS ... Personnellement, j'utilise dpatch pour gérer 1 tarball source + plusieurs patchs. [...] http://cvs.debian.org/gcc-3.1/?cvsroot=debian-gcc Ça a l'air de ressembler pas mal à DBS, du moins à l'utilisation que j'en fais. Mais où puis-je trouver de la documentation à ce sujet ? Les fichiers .dpatch ne sont pas générés à la main j'espère ... avec DBS le coupe dbs-edit-patch / dbs-update-patch est vraiment pratique pour réaliser cela. -- Thomas Parmelan -+- [EMAIL PROTECTED] -+- Proxad / Free
[Aide] Packaging de Sympa pour Debian
Bonjour, Afin de conserver un paquet de qualité et plus régulièrement à jour, je cherche un (ou deux) co-mainteneur sur le paquet Sympa. Je n'utilise plus Sympa depuis un moment (je ne gère plus de listes moi-même) et je n'ai pas le temps de suivre les listes. Les conditions : - être utilisateur de Sympa et suivre l'évolution du produit - connaître le shell et Perl - s'intéresser au packaging Debian dont Debconf - idéal : avoir déjà mis le nez dans le fonctionnement du paquet Le but étant de monter une (petite) équipe qui travaille sur le packaging via CVS. Me contacter si intéressé. -- Jérôme Marant http://marant.org
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
Packaging programs with all features or with most used?
Hi I used 'sid' for two years but now (as I don't have net access in home) I switched to 'woody' as base system and upgraded it a little with some sid packages. Yesterday ,when I want to install sylpheed-claws 0.8.1 from sid package, I discovered that I didn't get some packages to make it - but that's ok - I can live with it (or someday get source and recompile). The question is other: Do packages have to be build with all possible features or with most used (in sylpheed palm pda support is compiled by default - but does 50% of syl users needs it?) ? PS I think that I will start to change my Debian 'testing/unstable' to some kind of DFS (Debian From Scratch) - libgtk2.0-0 2.0.6-1 provides libgtk2.0-0png3 at my system ;) -- Marcin 'Szczepan|Hrw' Juszkiewicz mailto: marcinatamigadotpl my Debian packages: deb http://users.stone.pl/szczepan/ apt/
Re: ELF extension for starting symbol search from module dependencies
I think you can get the effect you need just by using -Bsymbolic. In your example, build the GTK+ library with -Bsymbolic. If that causes problems because some of the library's references should be resolved in the normal global scope, then confine the code that uses libpng to a wrapper library that you build with -Bsymbolic. Then link the GTK+ library against that shared object, and I think you will get the result you need: the GTK+ library code that uses libpng will be in a DT_SYMBOLIC object and thus resolve according to its own dependency on the desired libpng soname, while the application is free to link a conflicting libpng in directly.
Update excuses - please explain
Hello http://ftp-master.debian.org/testing/update_excuses.html#paul says: # paul (- to 0.1.0.2-5) * Maintainer: Andreas Tille * 76 days old (needed 2 days) * paul/m68k unsatisfiable Depends: libgtkdatabox (= 0.1.3) * paul/sparc unsatisfiable Depends: libgtkdatabox (= 0.1.3) * Valid candidate Moreover: auric:~ madison paul paul | 0.1-1 | oldstable | source, alpha, arm, i386, m68k, powerpc, sparc paul | 0.1.0.2-5 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc auric:~ madison libgtkdatabox libgtkdatabox | 0.1.12.3-1 | oldstable | source, alpha, arm, i386, m68k, powerpc, sparc libgtkdatabox | 1:0.1.13.0-6 | testing | source libgtkdatabox | 1:0.1.13.0-6 | unstable | source Sorry I can't verify the problem why paul has unsatisfiable Depends on m68k and sparc. Could anybody please enlighten me? Kind regards Andreas.
Re: Update excuses - please explain
On Thu, Aug 22, 2002 at 08:26:20AM +0200, Andreas Tille wrote: # paul (- to 0.1.0.2-5) * paul/m68k unsatisfiable Depends: libgtkdatabox (= 0.1.3) * paul/sparc unsatisfiable Depends: libgtkdatabox (= 0.1.3) Moreover: auric:~ madison libgtkdatabox libgtkdatabox | 0.1.12.3-1 | oldstable | source, alpha, arm, i386, m68k, powerpc, sparc libgtkdatabox | 1:0.1.13.0-6 | testing | source libgtkdatabox | 1:0.1.13.0-6 | unstable | source [EMAIL PROTECTED]:~$ madison libgtkdatabox-0.1.13-0 libgtkdatabox-0.1.13-0 | 1:0.1.13.0-6 | testing | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libgtkdatabox-0.1.13-0 | 1:0.1.13.0-6 | unstable | alpha, arm, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc Sorry I can't verify the problem why paul has unsatisfiable Depends on m68k and sparc. Could anybody please enlighten me? Which is to say libgtkdatabox no longer exists, but it used to, and that's what the m68k and sparc buildds used to build paul. The sparc and m68k debs need to be updated to reflect the new library. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
debian-devel@lists.debian.org
++ powersoftteam 1CRMOAERPMRPMIS 2 3 4 5 6 powersoftteam[EMAIL PROTECTED] [EMAIL PROTECTED] ++ 1 2ICCPU 35000 4 5 powersoftteam[EMAIL PROTECTED] [EMAIL PROTECTED] ++
Re: Update excuses - please explain
On Thu, 22 Aug 2002, Anthony Towns wrote: Which is to say libgtkdatabox no longer exists, but it used to, and Oh well, yes - I remember ;) that's what the m68k and sparc buildds used to build paul. The sparc and m68k debs need to be updated to reflect the new library. But what to do that these debs will be updated? The autobuilder leaves no trace that there went something wrong and I can see the debs in the archive. Isn't it strange? Kind regards Andreas.
Re: Sympa package: Seeking for co-developers
On Wed, Aug 21, 2002 at 11:35:52PM +0200, Jérôme Marant wrote: Hi, I'm seeking for co-developers who have some interests in the Perhaps I should have said co-maintainers than co-developers. -- Jérôme Marant
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote: 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. Maybe db.root just shouldn't be a conffile, that's all. 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. Sure there is: it's something like -o DPkg::Options=--force-confmiss. -- Colin Watson [EMAIL PROTECTED]
Re: OpenSSL-linked exim
On Wed, 21 Aug 2002, J.H.M. Dassen (Ray) wrote: :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? Oh, how I hate having to deal with licencing issues. I am not a legally competent person. (Also, I am not on any Debian lists.) If Debian would like such a statement, then please can somebody send me the wording that they want, and I will probably have no problem inserting it. Basically, I don't apply any restriction on linking Exim with any library you like, and distributing the resulting binary. (Obviously, the licencing terms of the library must be respected.) However, the usual GPL conditions apply: the people to whom it is distributed must have access to all the source of the Exim part. Philip -- Philip HazelUniversity of Cambridge Computing Service, [EMAIL PROTECTED] Cambridge, England. Phone: +44 1223 334714.
Re: Update excuses - please explain
On Thu, Aug 22, 2002 at 09:21:39AM +0200, Andreas Tille wrote: On Thu, 22 Aug 2002, Anthony Towns wrote: that's what the m68k and sparc buildds used to build paul. The sparc and m68k debs need to be updated to reflect the new library. But what to do that these debs will be updated? The autobuilder leaves no trace that there went something wrong and I can see the debs in the archive. Isn't it strange? No, nothing stange about it at all. paul got rebuilt before the new libgtkdatabox-* was available. It either needs to be binNMUed on those architectures, or a new source needs to be uploaded to get it rebuilt. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Re: When bind9 reinstalls, no db.root
On Thu, Aug 22, 2002 at 08:47:46AM +0100, Colin Watson wrote:
On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote:
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.
Maybe db.root just shouldn't be a conffile, that's all.
{Gesturing} That's what I'm saying.
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.
Sure there is: it's something like -o DPkg::Options=--force-confmiss.
OK. You got me. Is there any hope that's you'll at least cede that
that's not as straightforward as we *could* be?
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Update excuses - please explain
On Thu, 22 Aug 2002, Anthony Towns wrote: No, nothing stange about it at all. paul got rebuilt before the new libgtkdatabox-* was available. It either needs to be binNMUed on those architectures, or a new source needs to be uploaded to get it rebuilt. Well, now I understand the trouble. New upload just went to incoming. On the other hand I insist on my statement that this is not obviously to see using the update_excuses and madison and needs some guessing on developers side. Next question: Is there any trace of packages which are uploaded to stable and should go to woody-proposed-updates? How can I check if the moove to there is progressing or whether I need to do something? Kind regards Andreas.
Re: ELF extension for starting symbol search from module dependencies
On 21 Aug 2002, Luca Barbieri wrote: 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. Hmm, what if two functions which get imported from different versions of the same library operate on a static (private to the library) variable that is needed for a proper operation for some reason? You'd better rebuild the sources to use a single version of each library instead. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+
Re: When bind9 reinstalls, no db.root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Aug 2002, 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... Logcheck has a number of files under /etc/logcheck/ignore.d... that are marked as configuration files. Removing a configuration files means that more information is present in the log summary. (automaticly) Replacing these configuration files would result in unwanted behaviour. - -- arthur - [EMAIL PROTECTED] - http://tiefighter.et.tudelft.nl/~arthur -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE9ZKQgVYan35+NCKcRAoZSAJ4u1IeVFKCujBEuSr3yj9L9CZpCxQCfYgZO e+MVu8TbK1ViLL5zA6i9ui8= =W8zs -END PGP SIGNATURE-
Re: orphaning most (of my) packages
On Tue, Aug 20, 2002 at 10:43:52PM +0200, Ivo Timmermans wrote: Robert van der Meulen wrote: kernel-patch-int (should be superseded by cryptoapi; i can't find the time). Then there's some ITP's i (enthousiastically) did; i'm going to be closing them too. Interested people can upload and close at will, if they're faster than me: ricochet, loop-aes, cryptoapi, ipsec-tunnel. I would like to take over your ITP for cryptoapi. If noone else wants it, I can take kernel-patch-int too. Now that you are taking them over, some documentation to be included in the Debian Securing Manual regarding these packages could be useful too BTW. There's currently not a single paragraph on how to setup these patches to the kernel in Debian. Regards Javi
Re: When bind9 reinstalls, no db.root
On Thu, Aug 22, 2002 at 01:18:35AM -0700, Marc Singer wrote: On Thu, Aug 22, 2002 at 08:47:46AM +0100, Colin Watson wrote: On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote: 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. Sure there is: it's something like -o DPkg::Options=--force-confmiss. OK. You got me. Is there any hope that's you'll at least cede that that's not as straightforward as we *could* be? Yep, certainly. -- Colin Watson [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 22 Aug 2002, Arthur de Jong wrote:
For example...
Logcheck has a number of files under /etc/logcheck/ignore.d... that are
marked as configuration files. Removing a configuration files means that
more information is present in the log summary. (automaticly) Replacing
these configuration files would result in unwanted behaviour.
Oh I just thought of a better one: a lot of packages have configfiles in
/etc/cron.{daily,monthly,weekly}. Removind a configfile is clearly not the
same as having a default in this case.
Bluntly overwriting the db.root file is also not a good idea since some
people use alternative root nameservers. If you screwed up your package
configuration you should do:
apt-get --purge remove bind9
apt-get install bind9
(maybe apt-get --purge --reinstall install bind9 would be nice)
You either replace you whole configuration or just your binaries. I don't
think tat changing dpkg to do vodoo for you is a good idea.
- -- arthur - [EMAIL PROTECTED] - http://tiefighter.et.tudelft.nl/~arthur --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
iD8DBQE9ZKg+VYan35+NCKcRAoRDAKDpCk9sGyA1IhYEOx4uYSNfaivl3gCdHu+d
8wFw7M3PKUaMpmIiSTbEz3s=
=8G62
-END PGP SIGNATURE-
Re: ELF extension for starting symbol search from module dependencies
On Thu, Aug 22, 2002 at 10:35:33AM +0200, Maciej W. Rozycki wrote: On 21 Aug 2002, Luca Barbieri wrote: 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. Hmm, what if two functions which get imported from different versions of the same library operate on a static (private to the library) variable that is needed for a proper operation for some reason? You'd better rebuild the sources to use a single version of each library instead. Or, even better, introduce symbol versioning for libpng.so and maintain it ABI compatible from this point on... Jakub
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 10:19:49PM -0400, Scott K. Ellis wrote:
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.
One can change the database reference in named.conf to do this. The
difference is that db.root references 'the' root servers. You can
choose which ones you want to use in the zone file:
// prime the server with knowledge of the root servers
zone . {
type hint;
file /etc/bind/db.alternative_root;
};
The trouble with removing db.root is that it may not be obvious how to
recover when it is missing.
Re: orphaning most (of my) packages
Quoting Mako Hill ([EMAIL PROTECTED]):
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.
Taken - sorry ! :)
Greets,
Robert
--
( o Linux Generation o )
///\finger [EMAIL PROTECTED] for my GnuPG/PGP key./\\\
\V_/\_V/
All extremists should be taken out and shot.
pgpRxLKmXujIV.pgp
Description: PGP signature
Re: orphaning most (of my) packages
Quoting Thorsten Sauter ([EMAIL PROTECTED]): libphp-adodb (a php database abstraction layer, required for 'acidlab') I'll like to adopte the libphp-adodb package from you. Too late :/ Greets, Robert -- ( o Linux Generation o ) ///\finger [EMAIL PROTECTED] for my GnuPG/PGP key./\\\ \V_/\_V/ Invalid element 'rvdm' in content of 'p'. (WAP emulator error) pgpJU3s4BF443.pgp Description: PGP signature
¡°ËÉÆÕ¡±ÎªÄúµÄ²¼Ïß·½°¸ÌṩǿÓÐÁ¦µÄÖ§³ÖÓë±£ÕÏ
SUNPU Technology Co., Ltd. 1 2 3 http://www.broadlinker.com 0755-8366441183664422 83664433 0755-83664499 13823338529 E---mail: [EMAIL PROTECTED] == http://www.net001.net ;, +100M510M350 http://www.lovexin.com;
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 01:08:53PM -0700, 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. Removing /etc/snmp/snmpd.conf causes snmpd to _NOT_ start. Reinstalling the conffile would reenable snmpd, which is - given the history of snmp-related security-problems - dangerous. Regards, David -- Afrika kommt nach Europa. Das ist der Kontinentaldrift. Da kann man auch mit einem neuen Asylgesetz nichts dagegen machen. Das sollte mal wer denen von der FPÖ erklären! -- Dieter Nuhr (www.nuhr.de) in der Wiener Remise, 2002-08-02 pgpmc4wfwv0wW.pgp Description: PGP signature
debian-devel@lists.debian.org
++ powersoftteam 1CRMOAERPMRPMIS 2 3 4 5 6 powersoftteam[EMAIL PROTECTED] [EMAIL PROTECTED] ++ 1 2ICCPU 35000 4 5 powersoftteam[EMAIL PROTECTED] [EMAIL PROTECTED] ++
Re: RFC: OpenLDAP and TLS/SSL
On Wed, Aug 21, 2002 at 07:11:52PM -0300, 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). If versioned symbols means including the versions of the dependencies in the SONAME, the biggest drawback I see is that it using it will render all libraries binary-incompatible with programs / libraries developed elsewhere... or have I missed something? In the sense of being a widely-adopted standard, versioned symbols are *not* here now. Panu
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote: This terse reply is obviously inappropriate. If you are annoyed, stop writing. No less appropriate than your one-line dismissal of a reasonable and tactful response. 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. Are you saying that you think that the situation with this particular conffile is different enough, and that there are enough other similar conffiles, that it justifies different handling by dpkg? If so, I think that I would disagree. In the particular case of BIND, it is entirely reasonable to move the entire configuration somewhere else (such as into a chroot) and remove /etc/bind and its contents. It would be confusing to have them reappear when BIND is upgraded. 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. man 5 apt.conf, search for 'dpkg', 6th match. 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. The conffile system does nothing to break BIND's access to root nameservers; this only happens if an administrator explicitly removes db.root. If this was an accident, they need to reinstall with --force-confmiss. If not, then their change is preserved as it should be. What purpose would be served by making db.root not a conffile? -- - mdz
DVD(DivX)´Ù¿îÁ· ¸Å´Ï¾Æ ºÐµé¿¡°Ô...
!!! . !!! . 1400 GB DVD . 20GB. . 1 5GB. !!! . !!! . DVD 600MB Full . ... . . !!! . !!! . -> adult82.com <- !!! . !!! . adult82.com . DB . .
Re: ELF extension for starting symbol search from module dependencies
On Thu, 2002-08-22 at 08:13, Roland McGrath wrote: I think you can get the effect you need just by using -Bsymbolic. In your example, build the GTK+ library with -Bsymbolic. If that causes problems because some of the library's references should be resolved in the normal global scope, then confine the code that uses libpng to a wrapper library that you build with -Bsymbolic. Then link the GTK+ library against that shared object, and I think you will get the result you need: the GTK+ library code that uses libpng will be in a DT_SYMBOLIC object and thus resolve according to its own dependency on the desired libpng soname, while the application is free to link a conflicting libpng in directly. But -Bsymbolic only puts the module that uses it in front of the search list so the wrapper will use the library used by the program and will fail. You could do this by dlopen'ing libpng and getting symbols from it with dlsym but this requires source modifications and isn't exactly elegant (and lazy lookups require even more modifications). signature.asc Description: This is a digitally signed message part
Re: ELF extension for starting symbol search from module dependencies
Hmm, what if two functions which get imported from different versions of the same library operate on a static (private to the library) variable that is needed for a proper operation for some reason? You'd better rebuild the sources to use a single version of each library instead. I don't see how this could cause problems. Each png library should bind its own references to its own symbols. signature.asc Description: This is a digitally signed message part
Re: MailMan Security patch for Woody Broken?
* Matt Zimmerman
| If that is the only issue, then it is a simple matter to prepare fixed
| packages which use string.lower('string') rather than 'string'.lower(),
| which should work with both python 1.5 and python 2.x. Please let me know
| as soon as you are able to test this.
Fixed in proposed-updates now.
--
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
Re: Next Debconf
* Joe Drew | On Thu, 2002-08-15 at 12:20, Tollef Fog Heen wrote: | since nobody else has taken up the thread: | | I long ago declared my intention to organize debconf 3 in montreal or | vancouver, but I am absolutely not opposed to having the in-between | debconf outside of Canada. Ok, sorry about that, then. I guess you'll host debconf4 then. :) | I am planning Debconf 3 to be held in Oslo, from Friday July 18th to | Sunday July 20th. | | You'll be interested in bug#152529, which details the request for a | debian-conference list. This will help all debconfs in the future, | whenever it gets created. yup, looks good. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: ELF extension for starting symbol search from module dependencies
On Thu, 2002-08-22 at 11:23, Jakub Jelinek wrote: On Thu, Aug 22, 2002 at 10:35:33AM +0200, Maciej W. Rozycki wrote: On 21 Aug 2002, Luca Barbieri wrote: 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. Hmm, what if two functions which get imported from different versions of the same library operate on a static (private to the library) variable that is needed for a proper operation for some reason? You'd better rebuild the sources to use a single version of each library instead. Or, even better, introduce symbol versioning for libpng.so and maintain it ABI compatible from this point on... Yes, you could compatibly introduce versioning in libraries and continue to build unversioned binaries and it will work. However, this introduces a minor ABI modification that will cause libraries to break if they are used with libraries created by someone else that decided to do the same but invented a different versioning scheme. So this should be done in accordance with the library maintainers and other distributors while this extension can be introduced immediately and used until there is a universally accepted plan to add versioning. Also, libpng is not the only target: this can similarly be used in all the cases where the library maintainers decide to inconvenience everyone else by creating two incompatible libraries with conflicting symbols. BTW, how is RedHat handling this? signature.asc Description: This is a digitally signed message part
Re: orphaning most (of my) packages
On Thu, Aug 22, 2002 at 11:57:39AM +0200, Robert van der Meulen wrote: Too late :/ Has kernel-patch-int been adopted? As one of the upstream authors I would be glad to take it over. Regards, Kyle -- Kyle McMartin pgpkJ92sIv4YC.pgp Description: PGP signature
Re: orphaning most (of my) packages
Quoting Kyle McMartin ([EMAIL PROTECTED]): On Thu, Aug 22, 2002 at 11:57:39AM +0200, Robert van der Meulen wrote: Too late :/ Has kernel-patch-int been adopted? As one of the upstream authors I would be glad to take it over. I have agreed with Ivo ([EMAIL PROTECTED]), that he can take over the package. If you're interested - or more suitable, or whatever :) - you should discuss things with him; I Cc'd him on this message. Greets, Robert -- ( o Linux Generation o ) ///\finger [EMAIL PROTECTED] for my GnuPG/PGP key./\\\ \V_/\_V/ Never trust a child farther than you can throw it. pgpK8VEXqAKLR.pgp Description: PGP signature
gluck is down
To avoid the 'only heard on IRC' problem, gluck is down right now. I've been told (via irc) that an HP-er has been notified and that it is being worked on. -- Scott Dier [EMAIL PROTECTED] http://www.ringworld.org/
Re: When bind9 reinstalls, no db.root
On Thu, Aug 22, 2002 at 08:44:04AM -0400, Matt Zimmerman wrote: On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote: This terse reply is obviously inappropriate. If you are annoyed, stop writing. No less appropriate than your one-line dismissal of a reasonable and tactful response. So let me get this straight. You equate shut up with a request for concrete examples. How unfortunate. 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. Are you saying that you think that the situation with this particular conffile is different enough, and that there are enough other similar conffiles, that it justifies different handling by dpkg? If so, I think that I would disagree. In the particular case of BIND, it is entirely reasonable to move the entire configuration somewhere else (such as into a chroot) and remove /etc/bind and its contents. It would be confusing to have them reappear when BIND is upgraded. The idea is that db.root is a different kind of file. Most of the time, configuration files reflect the personality of the user's machine. db.root contains information about the root name servers. I would differentiate the presence of this information on a user's machine with the application of that information. It has a closer relationship to terminfo files or the POSIX timezone files than the global bash rc file. 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. man 5 apt.conf, search for 'dpkg', 6th match. That's a global change. Someone else pointed out that it can be passed with -o. 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. The conffile system does nothing to break BIND's access to root nameservers; this only happens if an administrator explicitly removes db.root. If this was an accident, they need to reinstall with --force-confmiss. If not, then their change is preserved as it should be. What purpose would be served by making db.root not a conffile? Albeit, this isn't a grave consideration, but one that make repairing a broken name server a little easier. Because --force-confmiss isn't a very desirable switch to use, because there is no compelling reason to keep db.root a configuration file, and because making this change would make restoring a missing db.root simple it seems that real question is qhy not?.
Re: exim vs. exim-tiny (was: RFC: OpenLDAP and TLS/SSL)
David Pashley [EMAIL PROTECTED] writes: 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? Yes, there is. It requires quite a few modifications to debian/rules. I have done this before for building our internal Exim packages with embedded Perl support. I just keep multpile EDITME files in the debian/ directory and have debian/rules copy them as needed. I have contacted Mark Baker about this before, but he seems not to have had the time to look at my patches. -Hilko
Re: When bind9 reinstalls, no db.root
On Thu, Aug 22, 2002 at 10:26:45AM -0700, Marc Singer wrote: On Thu, Aug 22, 2002 at 08:44:04AM -0400, Matt Zimmerman wrote: No less appropriate than your one-line dismissal of a reasonable and tactful response. So let me get this straight. You equate shut up with a request for concrete examples. How unfortunate. You are expecting others to do your homework for you. If you take a casual look around your system, it should be clear why things are done the way they are. In the particular case of BIND, it is entirely reasonable to move the entire configuration somewhere else (such as into a chroot) and remove /etc/bind and its contents. It would be confusing to have them reappear when BIND is upgraded. The idea is that db.root is a different kind of file. Most of the time, configuration files reflect the personality of the user's machine. db.root contains information about the root name servers. I would differentiate the presence of this information on a user's machine with the application of that information. It has a closer relationship to terminfo files or the POSIX timezone files than the global bash rc file. It sounds like you are arguing that DNS zone files should not be considered configuration files. If you read section 11.7.1 of the policy manual, it is clear that DNS zone files meet the policy manual's definition of 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. man 5 apt.conf, search for 'dpkg', 6th match. That's a global change. Someone else pointed out that it can be passed with -o. I pointed you to the documentation for the configuration option. You are complaining that it is a global configuration option, and in the same paragraph explaining how to set it for a particular invocation. This does not make sense to me. The conffile system does nothing to break BIND's access to root nameservers; this only happens if an administrator explicitly removes db.root. If this was an accident, they need to reinstall with --force-confmiss. If not, then their change is preserved as it should be. What purpose would be served by making db.root not a conffile? Albeit, this isn't a grave consideration, but one that make repairing a broken name server a little easier. Because --force-confmiss isn't a very desirable switch to use, because there is no compelling reason to keep db.root a configuration file, and because making this change would make restoring a missing db.root simple it seems that real question is qhy not?. If you want a db.root that is easy to restore, file a wishlist bug asking the maintainer to include a copy of the default db.root in /usr/share/doc/bind9/examples. -- - mdz
Re: RFC: OpenLDAP and TLS/SSL
Tore Anderson wrote: 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. How about moving postfix to priority important and exim to optional? :) LDAP support in postfix is already split off into a separate package. The postfix package still depends on postfix-ldap though. I suppose that dependency was added to prevent breaking LDAP support on upgrades. Now that woody is released, couldn't that dependency be dropped? /me runs Roland -- Roland Bauerschmidt
Re: Bug#152778: DBS feature request vs dpkg-source v2
On Thu, Aug 08, 2002 at 09:22:56AM +1000, Brian May wrote: I received this wish list request for dbs. Ideally, I want to make the transition as easy as possible from dbs to dpkg-source v2 once it comes out of being experimental. So I do not want to add new features to dbs that may make this transition harder because they are not supported by dpkg-source v2. However, I don't have time to look at dpkg-source v2 now, not until it becomes feasible to convert Heimdal (and this won't be while uploads are being rejected). So what should I do with this wishlist request? Hey Brian, sorry about the delay in responding. If you're comfortable that dpkg-source v2 is actually going to see the light in the next 6 months or so, I wouldn't worry about it. Because it's in experimental, I haven't looked at it at all, but I've been intending to move to it as soon as it's even minimally ready. If you have the feeling that it will take longer than 6 months to hit unstable, then you should maybe nudge me to write a patch for you. =) Tks, Jeff Bailey -- I reincarnated for this?
Re: ELF extension for starting symbol search from module dependencies
On 22 Aug 2002, Luca Barbieri wrote: Hmm, what if two functions which get imported from different versions of the same library operate on a static (private to the library) variable that is needed for a proper operation for some reason? You'd better rebuild the sources to use a single version of each library instead. I don't see how this could cause problems. Each png library should bind its own references to its own symbols. Do you suggest your proposed change should only be activated for the png library? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+
Re: pam_console for debian
On Thu, Jul 25, 2002 at 10:23:09AM -0700, David Caldwell wrote: Sounds like what you really want is a way to take exclusive access to the camera device somehow. Can you exclusively open the device and prevent others from opening it too? I suppose even that would have a timing splinter: Someone could take exclusive control before you got a chance... I would like to see someting like this for hotpluggable storage as well. If I want to keep private data (private keys etc) on a USB keyring I would like to be sure that nobody else can mount it before me. Perhaps the hotplug system could implement some kind of method for a user to say any device plugged in the next 1 minute is mine. Clearly this is vulnerable to DoS by others but this is far better than others being able to mount your disks/read your photos. sam -- sam clegg :: [EMAIL PROTECTED] :: http://superduper.net/ :: PGP :: D91EE369 $superduper: .signature,v 1.5 2002/05/17 10:23:59 samc Exp $ pgp9E4KeulXHJ.pgp Description: PGP signature
Re: ELF extension for starting symbol search from module dependencies
On Thu, 2002-08-22 at 21:35, Maciej W. Rozycki wrote: On 22 Aug 2002, Luca Barbieri wrote: Hmm, what if two functions which get imported from different versions of the same library operate on a static (private to the library) variable that is needed for a proper operation for some reason? You'd better rebuild the sources to use a single version of each library instead. I don't see how this could cause problems. Each png library should bind its own references to its own symbols. Do you suggest your proposed change should only be activated for the png library? The proposed change is activated for everything that is compiled with the -Blocal linker option. For the specific case of libpng, the problem can be solved by linking libpng.so.2 and libpng.so.3 with -Bsymbolic and all libraries that use them with -Blocal (alternatively you can also solve this with versioned symbols but this causes more potential compatibility problems). signature.asc Description: This is a digitally signed message part
Re: pam_console for debian
On Thu, 22 Aug 2002 21:46, Sam Clegg wrote: On Thu, Jul 25, 2002 at 10:23:09AM -0700, David Caldwell wrote: Sounds like what you really want is a way to take exclusive access to the camera device somehow. Can you exclusively open the device and prevent others from opening it too? I suppose even that would have a timing splinter: Someone could take exclusive control before you got a chance... I would like to see someting like this for hotpluggable storage as well. If I want to keep private data (private keys etc) on a USB keyring I would like to be sure that nobody else can mount it before me. Perhaps the hotplug system could implement some kind of method for a user to say any device plugged in the next 1 minute is mine. Clearly this is vulnerable to DoS by others but this is far better than others being able to mount your disks/read your photos. Ivo is apparently taking over crypto-api and hopefully he'll have it in sarge soon. That should solve your problem, just encrypt the device and only the user with the password can get access. -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field.
Re: When bind9 reinstalls, no db.root
On 22-Aug-02, 11:12 (CDT), Bernd Eckenfels [EMAIL PROTECTED] wrote: On Wed, Aug 21, 2002 at 11:38:36PM -0700, Marc Singer wrote: The trouble with removing db.root is that it may not be obvious how to recover when it is missing. the questions to replace/diff/keep a modified conffile, why dont they apply to missing conffiles, too? Because you only get that question if the distributed version of the conffile is changed also. 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: When bind9 reinstalls, no db.root
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: because there is no compelling reason to keep db.root a configuration file But there IS a compelling reason to keep db.root a configuration file: alternic I don't use them, but debian shouldn't trash files that a sysadmin needs to change to use them just because they arn't recomended. (See http://www.alternic.org/ for info on alternic. While I have my problems with the way icann runs the DNS, alternic doesn't show signs of being run better, just differently.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html Text is a way we cheat time. -- Patrick Nielsen Hayden
Re: When bind9 reinstalls, no db.root
On Thu, Aug 22, 2002 at 01:49:39PM -0700, Blars Blarson wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: because there is no compelling reason to keep db.root a configuration file But there IS a compelling reason to keep db.root a configuration file: alternic I don't use them, but debian shouldn't trash files that a sysadmin needs to change to use them just because they arn't recomended. (See http://www.alternic.org/ for info on alternic. While I have my problems with the way icann runs the DNS, alternic doesn't show signs of being run better, just differently.) Perhaps the file is poorly named db.root - db.internic-root
IO::Socket::INET question
Hello, on my mostly woody system, this line in /usr/sbin/amavisd
works fine:
my $sock = IO::Socket::INET-new('127.0.0.1:8127');
However, on another prewoody system where I have upgraded
all of perl and all perl modules to the woody version, it keeps
coming up with the following error:
Cannot determine remote port
Which appears to come from /usr/share/perl/5.6.1/IO/Socket/INET.pm,
in the configure routine. This file is from perl-base, and
it is the same version as in woody, and the same version that works
on all my other systems.
Does anyone have any ideas of why this doesn't work, but only on one
system that appears to be identical to every other system that does
work?
Am I missing some depends from amavis-postfix? I don't think so,
but still, this would be the most obvious source of the problem.
Thanks in advance.
--
Brian May [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
On Thu, 22 Aug 2002, Steve Greenland wrote: apt-get --option Dpkg::Options=--force-confmiss apt-get \ -o Dpkg::Options::=--force-confmiss \ -o Dpkg::Options::=--force-somethingelse \ Note the trailing ::
Re: RFC: OpenLDAP and TLS/SSL
On Thu, 22 Aug 2002, Panu A Kalliokoski wrote: If versioned symbols means including the versions of the dependencies in the SONAME, the biggest drawback I see is that it using it will Nothing of the sort. It stores the soname of the library along with its symbols, which then become known as soname + symbol. Dependencies are not in the scope at all. In the sense of being a widely-adopted standard, versioned symbols are *not* here now. No, they are not, except where the breakage is so bad even RedHat and the other vendors can't ignore them with an straight face. That means libc (upstream does it), and I believe we (Debian) forced down their throats versioning for libdb2 and libdb3 as well. -- 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: IO::Socket::INET question
On Fri, Aug 23, 2002 at 07:50:21AM +1000, Brian May wrote: Which appears to come from /usr/share/perl/5.6.1/IO/Socket/INET.pm, in the configure routine. This file is from perl-base, and it is the same version as in woody, and the same version that works on all my other systems. Russell Coker suggested I run cruft on the system, and I did so. It produced a long list of files several screen fulls long. I found some interesting entries: sat# grep usr.*perl /tmp/out /usr/lib/perl5/CGI/Carp.pm /usr/lib/perl5/CGI/Carp_dist.pm These files don't seem to exist, I am not sure why cruft reported them. More importantly: /usr/lib/perl5/IO/Socket.pm I strongly suspect this was the cause of my problems. Anyway I backed up all of these files with: sat# tar czvf /root/oldperl.tar.gz `grep usr.*perl /tmp/out` and deleted the originals, and now it seems to work fine. Thanks! -- Brian May [EMAIL PROTECTED]
question about --print-architecture
rum$ CC= dpkg --print-architecture i386-none rum$ CC=gcc dpkg --print-architecture i386 flow$ CC= dpkg --print-architecture i386-none flow$ CC=gcc dpkg --print-architecture i386 This is a problem when using make-kpkg because it can't find the architecture. dpkg complains about i386-none not being in it's mapping table. By using HOSTCC=gcc make-kpkg it works fine. kernel-package version 7.04.potato.3 dpkg version 1.9.9 Thanks, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ There are 10 kinds of people in the world, those that can do binary arithmetic and those that can't.
proposal for the gcc 3.2 transition
Hello, I would like to make a proposal for one aspect of the gcc 3.2 migration in sid. A critical part of this transition will be the discovery of how many arches still require creation of libgcc-compat code in glibc. Currently we are told by Jakub Jelinek that i386 is fine. Franz Sirl has just finished ppc in both branches of the glibc cvs. The ia64 arch has a version available in the glibc trunk that could be backported. Jakub also said alpha and sparc32 should be fine (not sure if that needs backported from the trunk though into glibc-2-2-branch). The rest will have to be handled by the arch maintainers here. After talking to Daniel Stone, I found out that the kde 3.0.3 introduction to sid was being delayed until the gcc 3.2 switchover has occurred. Since the scheme above will greatly delay kde 3.0.3 being added to sid, I would like to propose the following. Assuming each arch passes their gcc 3.2 testsuite and the most current binutils is mandated for use with gcc 3.2, we should be able to short-circuit the process as follows. 1) adjust the debian/control in glibc to build all arches at their current gcc 3.1 regardless if gcc 3.2 is installed. 2) switch the gcc-default to gcc 3.2 3) as each arch can demonstrate that their libgcc-compat issues are resolved, their arch would be switched over in the glibc debian/control file to build glibc with gcc 3.2. This approach has the advantages of making the transition to gcc 3.2 go much faster while removing the need for each arch to immediately resolve their issues with libgcc-compat. All comments and suggestions are welcome. Jack
CMap files to be shared
Hi all, PDF-viewers recently can handle CMap files to display mutibyte characters (CJK, for example). As far as I know, there are ghostscript(gs-cjk or cmap-adobe-japan1), xpdf(xpdf-japanese, for example) and dvipdfm-cjk which provide CMap files independently. Is it impossible to provide only one set of CMap files to be shared among these binaries? As I am not an expert of fonts nor PDF so I might misunderstand something important. Best regards, 2002/8/23 -- Debian Developer Debian JP Developer - much more I18N of Debian Atsuhito Kohda [EMAIL PROTECTED] Department of Math., Univ. of Tokushima
Accepted libgd-graph-perl 1.35-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 22 Aug 2002 09:19:18 +0200 Source: libgd-graph-perl Binary: libgd-graph-perl Architecture: source all Version: 1.35-2 Distribution: unstable Urgency: low Maintainer: Jonas Smedegaard [EMAIL PROTECTED] Changed-By: Jonas Smedegaard [EMAIL PROTECTED] Description: libgd-graph-perl - Graph Plotting Module for Perl 5 Closes: 157481 Changes: libgd-graph-perl (1.35-2) unstable; urgency=low . * Depend on unversioned libgd-perl, now that it is only a virtual package (and stable Debian contains libgd-perl way above the critical 1.9). * Build the package using binary-indep build-target (closes: #157481). * Add the non-clause to copyright, just to be on the safe side... Files: 110c3deed35d9f0641e3f45a598797f0 617 graphics extra libgd-graph-perl_1.35-2.dsc 0c4826c2b6677cad980538dcf32c3ac2 2712 graphics extra libgd-graph-perl_1.35-2.diff.gz ee0177846473ceeafbcabdc4550a138a 155186 graphics extra libgd-graph-perl_1.35-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9ZJCWn7DbMsAkQLgRAro+AKChVz7fbUhoiRR0GpOu2nDa38rKkACdE45j Ilaw4CePeEZ4wlVT5GxkRSI= =YKMv -END PGP SIGNATURE- Accepted: libgd-graph-perl_1.35-2.diff.gz to pool/main/libg/libgd-graph-perl/libgd-graph-perl_1.35-2.diff.gz libgd-graph-perl_1.35-2.dsc to pool/main/libg/libgd-graph-perl/libgd-graph-perl_1.35-2.dsc libgd-graph-perl_1.35-2_all.deb to pool/main/libg/libgd-graph-perl/libgd-graph-perl_1.35-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libdata-compare-perl 0.02-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 22 Aug 2002 19:03:07 +1000 Source: libdata-compare-perl Binary: libdata-compare-perl Architecture: source all Version: 0.02-2 Distribution: unstable Urgency: low Maintainer: Jean-Francois Dive [EMAIL PROTECTED] Changed-By: Jean-Francois Dive [EMAIL PROTECTED] Description: libdata-compare-perl - Compare two perl data structures recursively. Closes: 157472 157563 Changes: libdata-compare-perl (0.02-2) unstable; urgency=low . * Fixed copyright information (closes: #157563). * Changed maintainer address. * Fixed rule file (closes: #157472). Files: 6e575fda0950cc2d599cf35d0071704e 595 libs optional libdata-compare-perl_0.02-2.dsc 32f7fc42bf01df4670b918305d5b3324 3885 libs optional libdata-compare-perl_0.02-2.tar.gz 5301fc50b23cb0f2e4266575ec3dbf8a 6006 libs optional libdata-compare-perl_0.02-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9ZK4x43iCyIF2Si0RAiGMAJ9udN5q2WLJWn6SfH4kC2n7DK4MyACeO05B qvQqARwLU/N6tZUtU927Nhg= =1R+d -END PGP SIGNATURE- Accepted: libdata-compare-perl_0.02-2.dsc to pool/main/libd/libdata-compare-perl/libdata-compare-perl_0.02-2.dsc libdata-compare-perl_0.02-2.tar.gz to pool/main/libd/libdata-compare-perl/libdata-compare-perl_0.02-2.tar.gz libdata-compare-perl_0.02-2_all.deb to pool/main/libd/libdata-compare-perl/libdata-compare-perl_0.02-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted camlzip 1.01-6 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Thu, 22 Aug 2002 11:10:42 +0200 Source: camlzip Binary: libzip-ocaml libzip-ocaml-dev Architecture: source i386 Version: 1.01-6 Distribution: unstable Urgency: low Maintainer: Sven Luther [EMAIL PROTECTED] Changed-By: Sven Luther [EMAIL PROTECTED] Description: libzip-ocaml - ocaml compression libraries libzip-ocaml-dev - ocaml compression libraries Changes: camlzip (1.01-6) unstable; urgency=low . * Rebuilt for ocaml 3.06. Files: 698b537fb89c3f3aecb487bc863fcd9c 719 devel optional camlzip_1.01-6.dsc b618758c75135fb469fc5f5857450711 2441 devel optional camlzip_1.01-6.diff.gz 5c30ba545d509e12791955324420ec16 5806 libs optional libzip-ocaml_1.01-6_i386.deb c807fe2deb0579c682a973a7a1c07028 67084 devel optional libzip-ocaml-dev_1.01-6_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBPWSrMLnatikxM8h9AQEO9wP9F5pI1OkwM6a4mv3v9k66eoyGJODMjKdT LI4N3QxeoerTn/Kv+Hl6OBSuhncTtcFKhIdMwiZ1Tnmi5pgHn/d0nOR80D2VYI6O F1EpJSiQWRe6CDGq8VKcwCQLkQl5GXD9UHVOA5R/1qZMhbbX/yPLKTBYaYKFDS+3 xLGabwOeSiI= =E7iN -END PGP SIGNATURE- Accepted: camlzip_1.01-6.diff.gz to pool/main/c/camlzip/camlzip_1.01-6.diff.gz camlzip_1.01-6.dsc to pool/main/c/camlzip/camlzip_1.01-6.dsc libzip-ocaml-dev_1.01-6_i386.deb to pool/main/c/camlzip/libzip-ocaml-dev_1.01-6_i386.deb libzip-ocaml_1.01-6_i386.deb to pool/main/c/camlzip/libzip-ocaml_1.01-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fluxconf 0.8.8-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 20 Aug 2002 14:03:03 +0200 Source: fluxconf Binary: fluxconf Architecture: source i386 Version: 0.8.8-1 Distribution: unstable Urgency: low Maintainer: Emmanuel le Chevoir [EMAIL PROTECTED] Changed-By: Emmanuel le Chevoir [EMAIL PROTECTED] Description: fluxconf - FluxBox configuration utility Changes: fluxconf (0.8.8-1) unstable; urgency=low . * New Upstream Release * Acknowlegded previous changes to the control file. (Thanks to Marcelo E. Magallon for the NMU.) * Fix error messages. Fluxconf already allows modifications to conffile locations. * Happy birthday to the author :-) Files: 707b81f7b63d7d45b4f0f8a5b7407110 531 x11 optional fluxconf_0.8.8-1.dsc 77f31c72054b47194e7946fd5c630b7d 147357 x11 optional fluxconf_0.8.8-1.tar.gz a2d47726a427eb0a1d73515cbdf02bd9 21608 x11 optional fluxconf_0.8.8-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9ZLwhc29c8N2YKnURAuRzAKCbHxG+NvSZTLcIw+OTNcp6ukeBIQCeOwFF Ne8OdvMUeKD8NfrH+MTw3j8= =fi8+ -END PGP SIGNATURE- Accepted: fluxconf_0.8.8-1.dsc to pool/main/f/fluxconf/fluxconf_0.8.8-1.dsc fluxconf_0.8.8-1.tar.gz to pool/main/f/fluxconf/fluxconf_0.8.8-1.tar.gz fluxconf_0.8.8-1_i386.deb to pool/main/f/fluxconf/fluxconf_0.8.8-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted debbugs-el 7.10-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 22 Aug 2002 12:48:42 +0200 Source: debbugs-el Binary: debbugs-el Architecture: source all Version: 7.10-2 Distribution: unstable Urgency: low Maintainer: Roland Mas [EMAIL PROTECTED] Changed-By: Roland Mas [EMAIL PROTECTED] Description: debbugs-el - Access the Debian BTS from within Emacs Closes: 157798 Changes: debbugs-el (7.10-2) unstable; urgency=low . * Force compression of the compilation log, to allow for non-interactive installation (closes: #157798). Files: 9c202da08f16746f9e386d30ed8d2536 507 utils optional debbugs-el_7.10-2.dsc 39d9b4585aed57cb2398af86716ddd98 19756 utils optional debbugs-el_7.10-2.tar.gz f96e02baf19b001b5fd15c0b11b532b2 21056 utils optional debbugs-el_7.10-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9ZM+oDqdWtRRIQ/URAtZCAJ4ovZtHEvXZk7h/xGm4xbs+I79e1QCfesNb wGtURsMfvVSFKybk87B+LVY= =xTZI -END PGP SIGNATURE- Accepted: debbugs-el_7.10-2.dsc to pool/main/d/debbugs-el/debbugs-el_7.10-2.dsc debbugs-el_7.10-2.tar.gz to pool/main/d/debbugs-el/debbugs-el_7.10-2.tar.gz debbugs-el_7.10-2_all.deb to pool/main/d/debbugs-el/debbugs-el_7.10-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gtk+1.2 1.2.10-14 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 22 Aug 2002 19:33:00 +0900 Source: gtk+1.2 Binary: libgtk1.2-dev libgtk1.2-doc libgtk1.2 libgtk1.2-dbg libgtk1.2-common Architecture: source all i386 Version: 1.2.10-14 Distribution: unstable Urgency: low Maintainer: Akira TAGOH [EMAIL PROTECTED] Changed-By: Akira TAGOH [EMAIL PROTECTED] Description: libgtk1.2 - The GIMP Toolkit set of widgets for X libgtk1.2-common - Common files for the GTK+ library libgtk1.2-dbg - Debugging files for the GIMP Toolkit libgtk1.2-dev - Development files for the GIMP Toolkit libgtk1.2-doc - Documentation for the GIMP Toolkit Changes: gtk+1.2 (1.2.10-14) unstable; urgency=low . * debian/control: s/Recommends/Suggests/ for devhelp-book-gtk. Files: 1f0a197acc0a43d336737dadeff66e87 666 libs optional gtk+1.2_1.2.10-14.dsc 534aeec0d03567bde6e48208b8e3a020 97071 libs optional gtk+1.2_1.2.10-14.diff.gz f196a82dca0f550ffd1f4d4e25c36d2b 156 doc optional libgtk1.2-doc_1.2.10-14_all.deb eb7355b71040e132c61a15a988fc0681 207006 misc optional libgtk1.2-common_1.2.10-14_all.deb 03161b8e378bb562996558c491906e0b 795734 libs optional libgtk1.2_1.2.10-14_i386.deb f2c043ff49798dc3d2fcb89df787eea7 1109742 devel optional libgtk1.2-dev_1.2.10-14_i386.deb 5fa9a6adde30964115e2a6a8c57d06dd 1388190 devel extra libgtk1.2-dbg_1.2.10-14_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9ZNh+2QCnNZ2xmQQRAhWuAJ0eaJTWsGGvAoA/3tjOH9qsdP66CACgymHG c2CKrae6lvLyqCDs8qiB1no= =9Rrb -END PGP SIGNATURE- Accepted: gtk+1.2_1.2.10-14.diff.gz to pool/main/g/gtk+1.2/gtk+1.2_1.2.10-14.diff.gz gtk+1.2_1.2.10-14.dsc to pool/main/g/gtk+1.2/gtk+1.2_1.2.10-14.dsc libgtk1.2-common_1.2.10-14_all.deb to pool/main/g/gtk+1.2/libgtk1.2-common_1.2.10-14_all.deb libgtk1.2-dbg_1.2.10-14_i386.deb to pool/main/g/gtk+1.2/libgtk1.2-dbg_1.2.10-14_i386.deb libgtk1.2-dev_1.2.10-14_i386.deb to pool/main/g/gtk+1.2/libgtk1.2-dev_1.2.10-14_i386.deb libgtk1.2-doc_1.2.10-14_all.deb to pool/main/g/gtk+1.2/libgtk1.2-doc_1.2.10-14_all.deb libgtk1.2_1.2.10-14_i386.deb to pool/main/g/gtk+1.2/libgtk1.2_1.2.10-14_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted radiusd-livingston 2.1-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 22 Aug 2002 14:36:39 +0100 Source: radiusd-livingston Binary: radiusd-livingston Architecture: source i386 Version: 2.1-7 Distribution: unstable Urgency: low Maintainer: Paul Martin [EMAIL PROTECTED] Changed-By: Paul Martin [EMAIL PROTECTED] Description: radiusd-livingston - Remote Authentication Dial-In User Service (RADIUS) server Closes: 157754 Changes: radiusd-livingston (2.1-7) unstable; urgency=low . * Included radtest program in the package at the suggestion of Todd Charron [EMAIL PROTECTED]. * Use debhelper v4. * Standards-Version: 3.5.6 * Updated to use db2 includes, as the db1-compat header files are no longer supported by libc6. * Allow use of shadow passwords. (Closes: #157754) * Additions to README.Debian, and debian/rules clean now cleans up install-stamp. Files: a6e0869b226bdd3d59bc6172e86ab7b8 588 net optional radiusd-livingston_2.1-7.dsc cb44761fe81a5bbb4f71c3ba91439771 14367 net optional radiusd-livingston_2.1-7.diff.gz a51282fbf5815aef81aaec39233bbf6e 67976 net optional radiusd-livingston_2.1-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9ZOo8+gi+rt7UWRIRAmj4AJ9Nd2vEcDLWAjkvyDpbLKL4k+D5xQCbBI1z aWTqmODVLHb6b9cNU0AY9hg= =0Ehi -END PGP SIGNATURE- Accepted: radiusd-livingston_2.1-7.diff.gz to pool/main/r/radiusd-livingston/radiusd-livingston_2.1-7.diff.gz radiusd-livingston_2.1-7.dsc to pool/main/r/radiusd-livingston/radiusd-livingston_2.1-7.dsc radiusd-livingston_2.1-7_i386.deb to pool/main/r/radiusd-livingston/radiusd-livingston_2.1-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dpkg-dev-el 2.7-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 22 Aug 2002 15:38:07 +0200 Source: dpkg-dev-el Binary: dpkg-dev-el Architecture: source all Version: 2.7-2 Distribution: unstable Urgency: low Maintainer: Roland Mas [EMAIL PROTECTED] Changed-By: Roland Mas [EMAIL PROTECTED] Description: dpkg-dev-el - Emacs-related Debian development helpers Closes: 157811 Changes: dpkg-dev-el (2.7-2) unstable; urgency=low . * Changed the load-path used at install time, to fix installation problem on Xemacs (closes: #157811). Files: 5b5f2e5f5a1fd99b58bf497b63f2563d 508 utils optional dpkg-dev-el_2.7-2.dsc ecb78d0150f8d1531ca680f4c82055ec 36317 utils optional dpkg-dev-el_2.7-2.tar.gz 6044e942ac65a2ee41b8befc3d071889 25136 utils optional dpkg-dev-el_2.7-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9ZOm4DqdWtRRIQ/URAvVaAJ9feYzSxSmZlbnt3535HWG8O9xWfACeLfES f/RooLfDGUjdFsHE/U1272M= =Vxz8 -END PGP SIGNATURE- Accepted: dpkg-dev-el_2.7-2.dsc to pool/main/d/dpkg-dev-el/dpkg-dev-el_2.7-2.dsc dpkg-dev-el_2.7-2.tar.gz to pool/main/d/dpkg-dev-el/dpkg-dev-el_2.7-2.tar.gz dpkg-dev-el_2.7-2_all.deb to pool/main/d/dpkg-dev-el/dpkg-dev-el_2.7-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted control-center2 2.0.1.1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 22 Aug 2002 15:44:13 +0200 Source: control-center2 Binary: gnome-control-center2 Architecture: source i386 Version: 2.0.1.1-1 Distribution: experimental Urgency: low Maintainer: Christian Marillat [EMAIL PROTECTED] Changed-By: Christian Marillat [EMAIL PROTECTED] Description: gnome-control-center2 - The GNOME Control Center for GNOME 2 Changes: control-center2 (2.0.1.1-1) experimental; urgency=low . * New upstream release. * Remove fam from recommends should be in libgnomevfs2-0 package. Files: 827fa83d48d2484019e6b618dc5a362a 823 x11 optional control-center2_2.0.1.1-1.dsc 56870f56e5702586783b6888f0c15e47 1832423 x11 optional control-center2_2.0.1.1.orig.tar.gz 2aa0b6a007b6169cc5c1d5504d2b419f 6877 x11 optional control-center2_2.0.1.1-1.diff.gz d956a5e2fbc045147a5a8b21e832c1c5 938224 x11 optional gnome-control-center2_2.0.1.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9ZOwOB9xWPR9BuQcRAuEwAJ9OYA6Izc541TbNYu+ZvlwDLw+JcACeLH9f HceJ1rbMfDBphIEvP+4YzL8= =nLED -END PGP SIGNATURE- Accepted: control-center2_2.0.1.1-1.diff.gz to pool/main/c/control-center2/control-center2_2.0.1.1-1.diff.gz control-center2_2.0.1.1-1.dsc to pool/main/c/control-center2/control-center2_2.0.1.1-1.dsc control-center2_2.0.1.1.orig.tar.gz to pool/main/c/control-center2/control-center2_2.0.1.1.orig.tar.gz gnome-control-center2_2.0.1.1-1_i386.deb to pool/main/c/control-center2/gnome-control-center2_2.0.1.1-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hackmeeting 2002 -Madrid
Hola a todos, Por si todavía no lo sabeís, este año el HackMeeting nacional se organiza en Madrid a principios de octubre. Es un encuentro de geeks y hackers de todo tipo viniendo de toda España. El año pasado tuvo lugar en Leioa (Bilbao) y hace 2 años en Barcelona. Más detalles en la pagina web: http://www.sindomimio.net/wh2001 Estoy (modestamente) ayudando a la organización de este evento y se esta planeando la idea de tener un stand Debian durante los 3 días que dura la concentración. ¿Algunos estaríais interesados en venir montar y cuidar el stand durante esos días? Me imagino que se pueden organizar turnos. Por supuesto estaré yo también pero no podré estar todo el tiempo en el stand. Creo que jfs tiene contactos en lo que se refiere al material de promoción que pertenece a Debian (el 'kit móvil'): carteles, banderas, pegatinas, mecheros, condones, etc. Saludos, -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] pgp0AHmzD90Kc.pgp Description: PGP signature
