Re: Why am I receiving still mails from this list?

[Peter Makholm]

Joe Drew <[EMAIL PROTECTED]> writes:

> Which he obviously did, given that he stated that he unsubscribed once,
> apparently successfully, still received mails, and then tried again, and
> the list said he wasn't subscribed.

And did he then contact [EMAIL PROTECTED] when he had trouble?

I guess it is that line Matt was refering to.

-- 
 Peter Makholm |I congratulate you. Happy goldfish bowl to you, to
 [EMAIL PROTECTED] |  me, to everyone, and may each of you fry in hell
 http://hacking.dk |   forever
   |  -- The Dead Past

Re: Apache2

[Andres Salomon]

Are there any plans for php support for apache2?  I've played around w/
2.0.40 and a php cvs snapshot from sometime last week, w/ good results;
I'm looking forward to a php4-snapshot/php4-apache2 packages, or
something along those lines.


On Mon, Aug 19, 2002 at 04:35:13PM +0100, Thom May wrote:
> 
> * Matt Kern ([EMAIL PROTECTED]) wrote :
> > I have just installed apache2 (out of sid onto a woody based system)
> > and am having a little trouble understanding the new methodology.
> > 
> > I can see the advantages of all the separate configuration
> > directories, but cannot see quite how everything fits together.  I
> > understand the include mechanism and most of the files under
> > /etc/apache2, but where are the referred to binaries addhost,
> > ap2addhost and a2enhost (or whatever they are called in the files and
> > postings I have read)?  I can't find anything on my system that makes
> > use of the *.d directories in /etc/vhost.
> > 
> > Have I caught the apache2 package in a state of extreme development?
> 
> No, you've caught the vhost system in a state of extreme unworkingness -
> there was a very rough version that maybe worked a while back, but it
> seriously needs a rewrite and some love.
> 
> It is however entirely workable without vhost-base; add sites and modules to
> /etc/apache2/{sites,mods}-available, and enable them with a symlink into
> /etc/apache2/{sites,mods}-enabled 
> 
> 
> A more suitable list for further discussion is debian-apache, and the
> reply-to is set accordingly.
> -Thom
> 
> -- 
> Thom May -> [EMAIL PROTECTED]
> 
>  Hello!
>  What is the voting period? From Mar 24th until?
>  until the candidate manoj wants to win is in the lead
> * asuffield ducks into the icbm shelter
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
Broad surveillance is a mark of bad security.
-- Bruce Schneier

Re: Are libtool .la files in non-dev library packages bugs?

[Junichi Uekawa]

On 20 Aug 2002 01:50:22 +0200
Luca Barbieri <[EMAIL PROTECTED]> wrote:

> According to Junichi's manual they should be in -dev packages (that
> makes sense, since they are only used by libtool builds).

My "solution" to the problem would be to create 
libwhatever-la packages which contains .la file only,
if other runtime binaries want them.


It has other implications, and probably technically most clean,
but some people might disagree.
Nevertheless, it creates a lot of packages just for the 
sake of ltdl, which might be used or not used.

I am not confident enoughif it's better than using "Replaces" on 
every libwhatever* package, but it is probably 
cleaner.




regards,
junichi


-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer

GEIZ-KRAGEN Geimeindebrief

[Gemeindebrief]

Liebe Geiz-kragen Community,

Du erhälst diesen Brief aufgrund deines Eintrages in unseren
Newsletter auf WWW.GEIZ-KRAGEN.DE
Dort kannst Du dich jederzeit ganz einfach auch wieder austragen.



1.)  70% Umsatz für Umsteiger

Einer der Marktführer im Security Content Bereich bietet allen
Webmastern, die sich nun anmelden und von einem anderen Anbieter
wechseln, die möglichkeit, statt mit 55% Umsatzbeteiligung direkt
mit 70% einzusteigen.

Die Vorgehensweise: 
Melden Sie sich an unter 

http://bestersponsor.de.vu

und faxen Sie anschliessend eine Provisionsabrechnung Ihres alten
Anbieters (piratXX, hacker-spinner, hacker-downloads, hacker-arschiX) an
den neuen Anbieter (persönliche Daten können geschwärzt werden).
Schon wird Ihr Account auf 70% Umsatzbeteiligung gesetzt... 
Und die langen Haltezeiten sprechen für sich!



2.)  20 Pf (10 Cent) pro Click - wer bietet das noch?

Der Werbemarkt ist zusammengebrochen, kaum ein Anbieter
zahlt mehr als 5 Cent für einen Click.
Lassen Sie sich nicht damit abspeisen.
Wir haben einen Sponsor ausfindig gemacht,
der Ihnen 10 Cent pro Clicks zahlt, wenn Sie sich ueber uns
anmelden:

Melden Sie sich an unter
http://blacksponsor.de.vu   (im Menu "Partneprogramm")

Geben Sie bei "Geworben durch" unsere Kennung "geiz" an und
Sie starten bei 10 Cent pro Click. Und das bei den clickstärksten Bannern
die wir kennen!

Re: Menu system rewrite update (Aug 6 2002)

[Andreas Tille]

On Mon, 19 Aug 2002, Joey Hess wrote:

> Andreas Tille wrote:
> > In fact you are right.  I would vote for a mandatory menu entry for every
> > program which has a user interface.
>
> I "vote" that you get to write the menu file for gnuplot, which after
> all has a graphical user interface, if it's fed the proper data file.
Well, gnuplot has in fact a user interface even if is just a text
interface.  This could be opened via menu (even if I admit that this
makes not much sense).

My general idea was:  There are users under certain *roles* who need
a trace of the installed programs in the menu system.  To support those
users we should try to get every package which contains programs with
reasonable user interfaces with apropriate menu entries.

I went one step further in the Debian-Med packages and tried to display
reasonable information about the installed program (hint to manpages, offline
or online documentation) to inform the user about the program which is
installed and how to use it.  This might be overkill for many users
but there are users in certain roles who will like that.

Kind regards

   Andreas.

Re: Menu system rewrite update (Aug 6 2002)

[Andreas Tille]

On Mon, 19 Aug 2002, Peter S Galbraith wrote:

> > I "vote" that you get to write the menu file for gnuplot, which after
> > all has a graphical user interface, if it's fed the proper data file.
>
> Or fix my bug http://bugs.debian.org/139482
>
> I need a dialog utility to prompt for the file name (with a file
> browser) and then start the program with that as argument.
I do not know this program but it smells like an upstream bug.  So I
would try to explain the problem upstream and would tag the bug
accordingly.

Kind regards

 Andreas.

Re: tenative ITP linux-wlan-ng; soliciting advice

[Ian Eure]

On Monday 19 August 2002 05:33 pm, Michael Alan Dorman wrote:
> Ian Eure <[EMAIL PROTECTED]> writes:
> > On Monday 19 August 2002 02:39 pm, Michael Alan Dorman wrote:
> > > [EMAIL PROTECTED] (Paul Hedderly) writes:
> > > > No. the hostap dirver is excellent. Written by Jean Tour...
> > > > something. He works for SSH Corp. google for "linux prism2 driver".
> > > > It does pcmcia and pci brilliantly but doesnt support usb yet. works
> > > > with prism2/2.5/3 cards - and most orinoco cards too. supports
> > > > kysmet.
> > >
> > > Nope, you're confusing authors with the in-kernel orinoco driver,
> > > which Jean Tourrilhes (who works for HP) has maintained at various
> > > points, though the current "real" maintainer is David Gibson, IIRC.
> > >
> > > Apparently the 2.4.19 orinoco includes prism2/PCI (aka prism2.5, I
> > > believe) support.  Don't know about the prism3---is that 802.11a?
> >
> > Prism2 and Prism2.5 are not the same thing.
>
> My understanding, perhaps flawed, is that Prism2.5 is basically a
> Prism2 with a direct PCI interface---no pcmcia baggage, etc.  The
> Linksys WPM11, for instance.
>
My only experience with Prism2.5 is with a newer Linksys WPC11 PCMCIA card, 
which didn't work with my stock 2.4.x non-kernel pcmcia setup.

> Regardless, the orinoco driver in the 2.4.19 kernel supports them.
> From Configure.help:
>
> Prism 2.5 PCI 802.11b adaptor support
> CONFIG_PCI_HERMES
>   Enable support for PCI and mini-PCI 802.11b wireless NICs based on
>   the Prism 2.5 chipset.  These are true PCI cards, not the 802.11b
>   PCMCIA cards bundled with PCI<->PCMCIA adaptors which are also
>   common.  Some of the built-in wireless adaptors in laptops are of
>   this variety.
>
Doesn't this require kernel PCMCIA support?

> > I haven't used the driver in the kernel, but the Orinoco driver
> > shipped with pcmcia-source (pcmcia-cs 3.1.33) only supports Prism2
> > cards.
> >
> > I strongly recommend anyone with a Prism chipset use linux-wlan-ng,
> > since pcmcia-cs's Orinoco driver sucks pretty hard.
>
> To each their own---I have used the orinoco driver that comes with the
> kernel from day one with no particular problems---and it supports the
> standard (at least in-kernel-standard) interfaces for configuration,
> etc., whereas wlan-ng does its own thing.
>
Well, I've used the default Orinoco driver in pcmcia-cs, but the linux-wlan-ng 
driver just performs better for me. Also, the pcmcia-cs driver constantly 
complains about "Error -110 writing BAP" for me.

-- 
Komm auf meine Sonnenbarke!

Re: HELP - Screen is flooded with DHCP messages.

[Osamu Aoki]

On Sat, Aug 17, 2002 at 08:56:48PM +, Andrew M.A. Cater wrote:
> Firewall died, taking down disk.  New disk: clean install of Woody
> upgraded to testing.  Two network cards: 3COM 3C905C 10/100M as
> (internal) card (eth0) 3COM Etherlink III as cable modem facing
> (external) card eth1.
> 
> Simple Iptables firewall. DHCP needs to work, as does ddtc for
> resolving dynamic addresses to .ddts.net.
> 
> Now flooded with screens full of
> 
> IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:04:76:de:b9:53:08:00 SRC=0.0.0.0
> DST=255,255,255,255 LEN=328 TOS=0x10 PREC=0x00 TTL=64 ID=0 PROTO=UDP
> SPT=68 DPT=67 LEN=308
> 
> on all machines.

Because you installed 2.4 kernel :)

> Advice please - posting to debian-devel because I know I'll get some
> competence here!

Prevent this to happen again even if you want to log this, 

set in /etc/init.d/klogd

KLOGD="-k /boot/System.map-$(uname -r) -c 3"

I wonder why this script does not create /etc/default/klogd like other
init script.  Although it is conffile, I do not like editing it
directly for this trivial configuration.
-- 
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +
 Osamu Aoki @ Cupertino CA USA, GPG-key: A8061F32
 .''`.   Debian Reference: post-installation user's guide for non-developer
 : :' :http://www.debian.org/doc/manuals/reference/  http://qref.sf.net
 `. `'   "Our Priorities are Our Users and Free Software" - Social Contract


pgpEg2oNHYclf.pgp
Description: PGP signature

Re: Are libtool .la files in non-dev library packages bugs?

[Roberto Gordo Saez]

Ben Collins wrote:
> Then ltdl is broken. How does one install libfoo.so.1 and libfoo.so.2
> and only have libfoo.la, and ltdl expect to work?
> 
> Broken...

So, i guess that kdelibs3 (4:2.2.2-13) is also broken...

$ dpkg -L kdelibs3 | grep \\.la$
/usr/lib/libDCOP.la
/usr/lib/dcopserver.la
/usr/lib/libkdefakes.la
/usr/lib/libkdeui.la
/usr/lib/libkdesu.la
/usr/lib/libkssl.la
diverted by kdelibs3-crypto to: /usr/lib/libkssl-nossl.la
/usr/lib/libkjs.la
/usr/lib/libksycoca.la
/usr/lib/kio_uiserver.la
/usr/lib/klauncher.la
...


-- 
Roberto Gordo - Free Software Engineer
Linalco "Especialistas en Linux y Software Libre"
Tel: +34-91-5970074 Fax: +34-91-5970083

Bug#157375: ITP: wxglade -- GUI designer for wxPython

[Ivo Timmermans]

Package: wnpp
Version: N/A; reported 2002-08-20
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: wxglade
  Version : 0.1.2
  Upstream Author : Alberto Griggio <[EMAIL PROTECTED]>
* URL : http://wxglade.sf.net/
* License : GPL
  Description : GUI designer for wxPython

An interactive interface designer for wxPython.  It generates Python
code.  As you can guess by the name, its model is Glade, the famous
GTK+/GNOME GUI builder, with which wxGlade shares the philosophy and
the look & feel (but not a line of code).

It is not (and will never be) a full featured IDE, but simply a
"designer": the generated code does nothing apart from displaying the
created widgets. If you are looking for a complete IDE, maybe Boa
Constructor is the right tool. 


- -- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux spark 2.4.18-xfs-1.1 #2 za jun 15 15:26:59 CEST 2002 i586
Locale: LANG=C, [EMAIL PROTECTED]

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9YhhhbTEMl+oVcvERAjDTAKCjHTFLLTziSoNiP45xy77lCO3nOwCeK2SL
gsOfFGQOWCgsinXuiRx73wQ=
=7Fus
-END PGP SIGNATURE-

Re: Are libtool .la files in non-dev library packages bugs?

[Marcelo E. Magallon]

>> Roberto Gordo Saez <[EMAIL PROTECTED]> writes:

 > $ dpkg -L kdelibs3 | grep \\.la$
 > /usr/lib/libDCOP.la
 > /usr/lib/dcopserver.la
 > /usr/lib/libkdefakes.la
 > /usr/lib/libkdeui.la
 > /usr/lib/libkdesu.la
 > /usr/lib/libkssl.la
 > diverted by kdelibs3-crypto to: /usr/lib/libkssl-nossl.la
 > /usr/lib/libkjs.la
 > /usr/lib/libksycoca.la
 > /usr/lib/kio_uiserver.la
 > /usr/lib/klauncher.la

 A wild guess: I don't know about the files named lib*.la, but the other
 ones could be plug-ins.  ltdl opens the .la file to find out the actual
 filename of the shared object.  Remember that libtool generates
 different filenames under different platforms (e.g. libfoo.so.0 vs
 libfoo.so.9 -- for whatever reason -- vs libfoo.sl.1).  Jason is right
 that for *our* purposes this is The Wrong Thing To Do(TM).

-- 
Marcelo | This signature was automatically generated with
[EMAIL PROTECTED] | Signify v1.07.  For this and other cool products,
| check out http://www.debian.org/

Re: tenative ITP linux-wlan-ng; soliciting advice

[Ricardo Javier Cardenes Medina]

On Mon, Aug 19, 2002 at 08:33:08PM -0400, Michael Alan Dorman wrote:
> 
> My understanding, perhaps flawed, is that Prism2.5 is basically a
> Prism2 with a direct PCI interface---no pcmcia baggage, etc.  The
> Linksys WPM11, for instance.

My pcmcia card (TrendWare TEW-201PC) announces itself as a Prism2.5, soy I
think that's not the only difference.

> To each their own---I have used the orinoco driver that comes with the
> kernel from day one with no particular problems---and it supports the
> standard (at least in-kernel-standard) interfaces for configuration,
> etc., whereas wlan-ng does its own thing.

I'm running Epitest's HostAP driver, both on my desktop (base station) and
laptop, and it runs very well (to no surprise, as this driver is developed
only for Prism2/2.5/3). It provides a reasonably large subset of the
standard Wireless Extensions.

Re: tenative ITP linux-wlan-ng; soliciting advice

[Ricardo Javier Cardenes Medina]

On Tue, Aug 20, 2002 at 12:18:31AM -0700, Ian Eure wrote:
> > Prism 2.5 PCI 802.11b adaptor support
> > CONFIG_PCI_HERMES
> >   Enable support for PCI and mini-PCI 802.11b wireless NICs based on
> >   the Prism 2.5 chipset.  These are true PCI cards, not the 802.11b
> >   PCMCIA cards bundled with PCI<->PCMCIA adaptors which are also
> >   common.  Some of the built-in wireless adaptors in laptops are of
> >   this variety.
> >
> Doesn't this require kernel PCMCIA support?

If the card is a true PCI one, it doesn't. I own a TEW-203PI (TrendWare)
and it's a full PCI card. It doesn't requiere PCMCIA support.

Request for Assistance!

[George Frederick.]

George Frederick,
Banque Internationale Afrique,
Lome,Togo.

I am George Frederick,the director in charge of auditing and
accounting section of Banque internationale De l'Afrique(BIA) Togo-Lome West 
Africa.

With due respect and regard. I have decided to contact you on a business 
transaction that will be very beneficial to both of us at the end of the 
transaction .
During our investigation and auditing (year ending 2001) in this bank, my 
department came across a very huge sum of money belonging to a deceased person 
who died on October 31st 1999 in a plane crash and the fund has been dormant in 
his account with this Bank without any
claim of the fund in our custody either from his family or relation before our 
discovery to this development.

The said amount was U.S $3.2M(Three million two hundred Thousand United States 
dollars). Meanwhile all the whole arrangement to put claim over this fund as 
the bonafide next of kin to the deceased, get the required approval and 
transfer of this money to a foreign account
has been put in place and the directives and needed information will be relayed 
to you as soon as you indicate your interest and willingness to assist us and 
also benefit your self to this great business opportunity.

In fact I could have done this deal alone but because of my position in this 
country as a civil servant(A Banker),we are not allowed to operate a foreign 
account.moreover, this may eventually raise an eye
brow on my side during the time of transfer because I work in this bank. This 
is the actual reason why it will require a second party or fellow who will 
forward claims as the next of kin with affidavit of trust of oath to the Bank 
and also present a foreign account where
he will need the money to be re-transferred into on his request as it may be 
after due verification and clarification by the correspondent branch of the 
bank where the whole money will be remitted from to your own designation bank 
account.

I will not fail to inform you that this transaction is 100% risk free. On 
smooth conclusion of this transaction, you will be entitled to 25% of the total 
sum as gratification, while 5% will be set aside
to take care of expenses that may arise during the time of transfer and also 
telephone bills, while 70% will be for me and my partners.

Please, you are adviced to keep "top secret" as I am still in service and i 
intend to retire from service after we conclude this deal with you. I will be 
monitoring the whole situation here in this bank until you confirm the money in 
your account and ask me to come down to your country for subsequent sharing of 
the fund according to percentages
previously indicated and further investment, either in your country or any 
country you advice us to invest in. All other necessary vital information will 
be sent to you when I hear from you.

I look forward to receive your mail or your telephone call.

Yours faithfully,
George Frederick.

Re: Are libtool .la files in non-dev library packages bugs?

[Roberto Gordo Saez]

Marcelo E. Magallon wrote:
> A wild guess: I don't know about the files named lib*.la, but the other
> ones could be plug-ins.  ltdl opens the .la file to find out the actual

Yes, you are right, but... why does a plugin need both .so and .la files?

(Please, CC to me also)

-- 
Roberto Gordo - Free Software Engineer
Linalco "Especialistas en Linux y Software Libre"
Tel: +34-91-5970074 Fax: +34-91-5970083

Re: Are libtool .la files in non-dev library packages bugs?

[Eduard Bloch]

#include 
* Roberto Gordo Saez [Tue, Aug 20 2002, 02:01:44PM]:
> > A wild guess: I don't know about the files named lib*.la, but the other
> > ones could be plug-ins.  ltdl opens the .la file to find out the actual
> 
> Yes, you are right, but... why does a plugin need both .so and .la files?

Because of naivity of some programers. I suggest to begin getting rid of
such kludges and forbid usage of .la files at runtimer in the Policy for
Sarge.

Yes, that would hit KDE stuff, ltld and librep but the .la insanity must
be stoped. Here. Now. SuSE and Redhat do not care, they prefer
recompiling the whole stuff just to change the library version. We
should not follow bad examples.

Gruss/Regards,
Eduard.
-- 
Lieber ein Pinguin, der läuft, als ein Fenster, das hängt.

Re: Are libtool .la files in non-dev library packages bugs?

[Marcelo E. Magallon]

>> Roberto Gordo Saez <[EMAIL PROTECTED]> writes:

 > Marcelo E. Magallon wrote:
 > > A wild guess: I don't know about the files named lib*.la, but the other
 > > ones could be plug-ins.  ltdl opens the .la file to find out the actual
 > 
 > Yes, you are right, but... why does a plugin need both .so and .la files?

 Because when you use ltdl's dlopen replacement, the function looks for
 the .la file instead of the .so file.  Let me rephrase: the plug-in
 filename can be whatever you want (no dlopen-wanabe implementation that
 I've seen is *that* stupid), but libtool produces filanames named after
 the platform's own conventions.  So, under Linux you get libfoo.so and
 under HP/UX you get libfoo.sl.  *That* information is stored in the .la
 file.  You pass the .la filename to dl_open, which opens it, searches
 for the actual shared object filename and does whatever voodoo your
 platform requires in order to dlopen a file.

 Morale: if the .la file is there for this purpose (plug-ins), it
 shouldn't be in /usr/lib in the first place (and neither should the
 other libfoo.so* files).  If the .la file is just a regular
 libtool-feels-all-cozy-when-it-finds-it .la file, it should be in the
 -dev package.

-- 
Marcelo | It wasn't blood in general he couldn't stand the sight
[EMAIL PROTECTED] | of, it was just his blood in particular that was so
| upsetting.
| -- (Terry Pratchett, Sourcery)

Re: Are libtool .la files in non-dev library packages bugs?

[Christian Marillat]

Christian Marillat <[EMAIL PROTECTED]> writes:

> Adam Heath <[EMAIL PROTECTED]> writes:

> On Mon, 19 Aug 2002, Ben Collins wrote:

> Not only that, it's only useful for linking, so has no reason being in
> the primary runtime.

> ltdl needs them at runtime.

> and librep9 too.

I forgot my last changes in librep9 :

librep (0.16.1-2) unstable; urgency=low

  * Move librep.la in -dev package

 -- Christian Marillat <[EMAIL PROTECTED]>  Wed, 10 Jul 2002 16:28:40 +0200

Christian

Bug#157389: ITP: psad -- The Post Scan Attack Detector (psad)

[Daniel Gubser]

Package: wnpp
Version: N/A; reported 2002-08-20
Severity: wishlist

* Package name: psad
  Version : 0.9.9
  Upstream Author : Michael B. Rash <[EMAIL PROTECTED]>
* URL : http://www.cipherdyne.com/
* License : (GPL)
  Description : The Post Scan Attack Detector (psad)

=> This is a split from the Bastille package <=

 The Port Scan Attack Detector (psad) is a program written in Perl
 that is designed to work with Linux firewalling code (iptables in the
 2.4.x
 kernels, and ipchains in the 2.2.x kernels) to detect port scans.  It
 features a set of highly configurable danger thresholds (with
 sensible
 defaults provided), verbose alert messages that include the source,
 destination, scanned port range, begin and end times, tcp flags
 and
 corresponding nmap options (Linux 2.4.x kernels only), reverse
 DNS info,
 email alerting, and automatic blocking of offending ip addresses
 via dynamic
 configuration of ipchains/iptables firewall rulesets.  In
 addition, for the
 2.4.x kernels psad incorporates many of the tcp signatures
 included in Snort
 to detect highly suspect scans for various backdoor programs
 (e.g. EvilFTP,
 GirlFriend, SubSeven), DDoS tools (mstream, shaft), and
 advanced port scans
 (syn, fin, xmas) which are easily leveraged against a
 machine via nmap.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux tux 2.4.13win4lin #1 SMP Sun Nov 4 13:14:46 CET 2001 i686
Locale: LANG=de_CH, LC_CTYPE=de_CH

Re: Are libtool .la files in non-dev library packages bugs?

[Steve Langasek]

On Tue, Aug 20, 2002 at 12:25:57PM +0200, Roberto Gordo Saez wrote:
> Ben Collins wrote:
> > Then ltdl is broken. How does one install libfoo.so.1 and libfoo.so.2
> > and only have libfoo.la, and ltdl expect to work?

> > Broken...

> So, i guess that kdelibs3 (4:2.2.2-13) is also broken...

Absolutely.  libtool and libltdl are a flaming heap of cow dung that
encourage programmers to use black boxes to achieve portable results, at
the expense of simplicity and the ability of the individual programmer to
fix linking bugs.  Autoconf and automake are both tools that are useful
to developers on GNU platforms; the only people who benefit from the
existence of libltdl (and libtool to a lesser extent) are users of legacy
Unix platforms.

Steve Langasek
postmodern programmer


pgpBtSB2OhO1F.pgp
Description: PGP signature

ITO: bubblemon

[Bernd Eckenfels]

package: bubblemon
secerity: normal

i want to give away or orphan the bubblemon package, cause i cant maintein
gnome programs anymore. There are some issues with multiple versions which
may need to be resolved,. otherwise it is a very good load monitor, it realy
hels you to get a feeling for your load currently and in the last few
seconds.

DD Feel free to make a new upload. I will do one with qa as the maintainer
if i feel nobody cares for the package.

Greetings
Bernd

Re: Are libtool .la files in non-dev library packages bugs?

[Marcelo E. Magallon]

>> Eduard Bloch <[EMAIL PROTECTED]> writes:

 > Because of naivity of some programers. I suggest to begin getting rid
 > of such kludges and forbid usage of .la files at runtimer in the
 > Policy for Sarge.

 I beg your pardon?  Which naiveness?  That particular bit of libtool
 solves a very real problem: dlopen is *not* portable.

 I did said I was guessing.  This could be just a mistake on the
 maintainer's part.  This could be a plug-in installed in the wrong
 place.  Please figure out what the files are before spouting more bile.

-- 
Marcelo | "It's a god-eat-god world."
[EMAIL PROTECTED] | -- (Terry Pratchett, Small Gods)

Re: Are libtool .la files in non-dev library packages bugs?

[Eduard Bloch]

#include 
* Marcelo E. Magallon [Tue, Aug 20 2002, 02:24:21PM]:

>  I've seen is *that* stupid), but libtool produces filanames named after
>  the platform's own conventions.  So, under Linux you get libfoo.so and
>  under HP/UX you get libfoo.sl.  *That* information is stored in the .la
>  file.  You pass the .la filename to dl_open, which opens it, searches

Yes, and this breaks the whole idea of SONAMES. I wonder how such shit
has ever been allowed to enter Debian.

Gruss/Regards,
Eduard.
-- 
The feature you'd like to have is probably already installed on your
Linux system.

Re: How to transition to G++ 3.2 wthout any breakage

[Luca Barbieri]

I've managed to patch both dpkg and glibc.
However the resulting system does not work because some things like KDE
use absolute paths so they would too need to be fixed.

Furthermore, we have the problem of C++ library packages including
non-C++ files. This can only be handled by heavily modifying dpkg to use
a database for files and have a usage count for files in multiple
packages.

dpkg would also need to extract the archive in two passes so that all
files in /usr/lib can be moved. But if we do this, libraries that use
hardcoded paths won't work.
Filenames could be remapped by replacing open, etc. but that would cause
odd problems due to different applications differently viewing the
filesystem.

So there isn't a clean solution and even a "good enough" one would
require too much time, so I'll not fix this.

We could still use the dynamic loader patch without the dpkg one but if
the user has to install things of his own, he can solve this without the
modified loader.

If anyone is interested, I can make the current patches and programs
(dpkg, ld.so, c++abi and library mover) available on the web under the
GNU GPL.



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

Re: Why am I receiving still mails from this list?

[Matt Zimmerman]

On Tue, Aug 20, 2002 at 12:34:36AM -0400, Joe Drew wrote:
> On Mon, 2002-08-19 at 11:34, Matt Zimmerman wrote:
> > Read the instructions at the bottom of each message that you receive
> > from this list.
> 
> Which he obviously did, given that he stated that he unsubscribed once,
> apparently successfully, still received mails, and then tried again, and
> the list said he wasn't subscribed.
> [...]
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Which you obviously did not, or you would have noticed the part that I was
referring to.  Notably, what to do if you have trouble (don't mail the
entire list about it).

-- 
 - mdz

Re: Are libtool .la files in non-dev library packages bugs?

[Marcelo E. Magallon]

>> Eduard Bloch <[EMAIL PROTECTED]> writes:

 > Yes, and this breaks the whole idea of SONAMES. I wonder how such shit
 > has ever been allowed to enter Debian.

 Are we still talking about plug-ins here?  I had that impression.

 Say, how is a SONAME useful for a plugin?  A plug-in is not something
 you link directly into a program (that's the whole point of it), so it
 has no bussiness living in any directory that the dynamic linker
 searches.  For the purposes of a plug-in, a namespace is as good a
 soname.  If you desing your plug-in system in any sensible way, the
 user tells you "open foo" and your program will go looking for
 /usr/lib/bar/plugin-foo.so or whatever naming scheme makes you happy.
 The point is, you'll have your very own area where you can set up your
 very own mess.

-- 
Marcelo | He'd been particularly pleased with Manchester.
[EMAIL PROTECTED] | -- Crowley contemplating his achievements
|(Terry Pratchett & Neil Gaiman, Good Omens)

Re: Are libtool .la files in non-dev library packages bugs?

[Eduard Bloch]

#include 
* Marcelo E. Magallon [Tue, Aug 20 2002, 04:19:02PM]:

>  > Yes, and this breaks the whole idea of SONAMES. I wonder how such shit
>  > has ever been allowed to enter Debian.
> 
>  Are we still talking about plug-ins here?  I had that impression.
> 
>  Say, how is a SONAME useful for a plugin?  A plug-in is not something

Do we? Plugins do not need soname, but then they should be keeped
outside of ld.so search paths.

>  you link directly into a program (that's the whole point of it), so it
>  has no bussiness living in any directory that the dynamic linker

Exactly. A program should know how the plugin name called and it should
manage the binary compatibility in their own ways. Why does a plugin
solution need an additional magic file to resolve the plugin, stored in
between other, SONAMEd libs?

>  searches.  For the purposes of a plug-in, a namespace is as good a
>  soname.  If you desing your plug-in system in any sensible way, the
>  user tells you "open foo" and your program will go looking for
>  /usr/lib/bar/plugin-foo.so or whatever naming scheme makes you happy.
>  The point is, you'll have your very own area where you can set up your
>  very own mess.

Exactly. Get rid of .la files, their usage to resolve path names is a
nasty kludge.

Gruss/Regards,
Eduard.
-- 
-!- Gromitt_ is now known as Gromitt
<@Getty> oh scheisse, gromitt wird wach
<@Getty> da hab ich jetzt soviele lines gemacht in den letzten 24 std.
<@Getty> und jetzt kommt der wieder ;)
-- #debian.de

Bug#157400: ITP: libsdl-sge -- Set of graphic functions that use SDL

[Julien Danjou]

Package: wnpp
Version: N/A; reported 2002-08-20
Severity: wishlist

* Package name: libsdl-sge
  Version : 020104
  Upstream Author : Anders Lindström <[EMAIL PROTECTED]>
* URL : http://www.etek.chalmers.se/~e8cal1/sge/index.html
* License : LGPL
  Description : Set of graphic functions that use SDL

SDL is a low level API and if you don't want to spend time writing
your own graphic functions (put pixel, line, circle...) you could use
SGE instead.


-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux chulak 2.4.19 #1 lun aoû 5 02:25:33 CEST 2002 i686
Locale: LANG=fr_FR, LC_CTYPE=fr_FR

-- 
Julien Danjou

(°>  - http://jdanjou.org   <[EMAIL PROTECTED]> -
//\  - http://tuxfamily.org   <[EMAIL PROTECTED]> -
V_/_ GPG: 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD

Bug#157402: ITP: biopython -- Python modules for computational molecular biology

[Wartan Hachaturow]

Package: wnpp
Version: N/A; reported 2002-08-20
Severity: wishlist

* Package name: biopython
  Version : 1.00a4
  Upstream Author : Many, see http://www.biopython.org/Participants.shtml
* URL : http://www.biopython.org/
* License : Python-like, http://www.biopython.org/License.shtml
  Description : Python modules for computational molecular biology

Project current goals are to develop:

   * The basic data types for biological objects, such as sequences and
 maps,
   * The core analysis tasks, including database record lookup,
 sequence algnment and the ubiquitous BLAST and FASTA interfaces,
   * I/O routines for the standard file formats,
   * Scaffolding to get these parts talking to each other,
   * Freely-available, high-quality, well-documented source code and 
 documentation,
   * A regression suite to tell if we made any stupid mistakes. 


Preliminary packages are available at 
http://people.debian.org/~wart/biopython/

-- 
Regards, Wartan.
"Computers are not intelligent. They only think they are."

Possible mass filing of bugs, take #2.1

[Gergely Nagy]

Hi!

Some time ago, I assembled a list of packages which were arch: all,
yet used binary-arch to build the package, and another list of
packages whose debian/copyright did not have a pointer to the full
license.

Unfortunately, I wasn't able to file the bugs at that time, so I redid
the test now. Since there were no objections last time, and I already
filed reports about these kind of bugs, I will start filing tonight.

As always, the results weren't checked by hand, so there might be
false positives (but I highly doubt it). I did not check the BTS
either, since I'm writing this offline. If I happen to submit
duplicate bugs, feel free to merge it or close it right away.

So! Here is the list, categorised by the type of the bug:

debian/copyright problems
=
In the following packages, debian/copyright does not include a
verbatim copy of their copyright and distribution license, nor any
pointers to /usr/share/common-licenses/{Artistic,GPL} or
/usr/share/doc/perl/copyright.

Since including a verbatim copy of the _whole_ license (with the
exception that in case of the GPL and some other selected licenses,
for which a pointer is enough) is a must, I believe this is at least
an important bug.

So, the packages with this kind of problem:

appconfig-perl, chatbot-eliza, ciphersaber, crypt-ssleay, delimmatch
freedb-disc-cover, glade-perl, hns2, html-munger, libacme-poe-knee-perl
libalgorithm-diff-perl, libalias-perl, libapache-authnetldap-perl
libapache-authznetldap-perl, libapache-configfile-perl
libapache-dbilogconfig-perl, libapache-dbilogger-perl, libapache-dbi-perl
libapache-reload-perl, libapache-session-perl, libarchive-tar-perl
libauthen-pam-perl, libbit-vector-perl, libboulder-perl
libbusiness-onlinepayment-tclink-perl, libcache-cache-perl, libcgi-pm-perl
libclass-autouse-perl, libcompress-zlib-perl, libconfig-ini-perl
libconvert-asn1-perl, libconvert-ber-perl, libconvert-units-perl
libcrypt-cracklib-perl, libcrypt-smbhash-perl, libcurses-perl
libdata-compare-perl, libdata-showtable-perl, libdate-calc-perl, 
libdbd-mysql-perl
libdbd-pg-perl, libdbd-ram-perl, libdbd-sqlite-perl, libdbi-perl
libdevice-serialport-perl, libdigest-hmac-perl, libdigest-md2-perl
libdigest-md4-perl, libdigest-md5-perl, libdigest-perl, libdigest-sha1-perl
libemail-valid-perl, liberror-perl, libexpect-perl, libextutils-f77-perl
libfile-cache-perl, libfile-slurp-perl, libfilesys-diskfree-perl
libfile-tail-perl, libfilter-perl, libgd-gd2-perl, libgd-noxpm-perl, libgd-perl
libgnome-gnorba-perl, libhtml-embperl-perl, libhtml-format-perl
libhtml-parser-perl, libhtml-table-perl, libhttp-ghttp-perl, 
libi18n-charset-perl
libimage-info-perl, libio-socket-ssl-perl, libio-stty-perl, libipc-run-perl
libipc-sharelite-perl, libjcode-pm-perl, liblingua-ispell-perl
liblog-agent-logger-perl, liblog-agent-perl, liblog-agent-rotate-perl
libmail-bulkmail-perl, libmail-cclient-perl, libmail-pop3client-perl
libmailtools-perl, libmath-basecalc-perl, libmd5-perl, libnet-daemon-perl
libnet-dns-perl, libnet-finger-perl, libnet-google-perl, libnet-ipnetmember-perl
libnet-jabber-perl, libnet-ldap-perl, libnet-netmask-perl, libnet-perl
libnet-ph-perl, libnet-rawip-perl, libnet-scp-perl, libnetserver-generic-perl
libnet-server-perl, libnet-smtp-server-perl, libnet-snmp-perl, libnet-snpp-perl
libnet-ssh-perl, libnet-ssleay-perl, libnet-telnet-perl, libnet-tftp-perl
libnet-whois-perl, libnet-whois-raw-perl, libnews-newsrc-perl
libparse-syslog-perl, libplot-perl, libplrpc-perl
libpoe-component-client-dns-perl, libpoe-component-client-http-perl
libpoe-component-irc-perl, libpoe-component-jobqueue-perl, libpoe-perl
libprpc-perl, librtf-document-perl, libschedule-cron-perl, libset-intspan-perl
libset-object-perl, libstorable-perl, libstring-random-perl, libsys-cpuload-perl
libtangram-perl, libtemplate-perl, libterm-shell-perl, libtest-harness-perl
libtest-unit-perl, libtext-kakasi-perl, libtext-template-perl
libtime-modules-perl, libunicode-japanese-perl, libunicode-map8-perl
libunicode-map-perl, libunicode-maputf8-perl, libunicode-string-perl
libxml-csv-perl, libxml-dom-perl, libxml-dumper-perl, libxml-filter-xslt-perl
libxml-generator-perl, libxml-grove-perl, libxml-libxml-perl, 
libxml-libxslt-perl
libxml-parser-perl, libxml-sablot-perl, libxml-sax-machines-perl
libxml-sax-writer-perl, libxml-stream-perl, libxml-twig-perl, libxml-xerces-perl
libxtm-perl, mime-lite, net-hotline, pilot-link, soap-lite, timedate

binary-arch VS Arch: all

Some of the packages are fully Architecture: all, yet, they build the
.deb in the binary-arch target. Since policy states that

`binary-arch' builds the binary packages which are specific to
a particular architecture, and `binary-indep' builds those
which are not.

I consider this a policy violation, therefore a serious bug.
(Hint: one shouldn't follow the dh_make template blindly. A little
thought is always a good thing.)

And the list of packages who were caug

Re: Possible mass filing of bugs, take #2.1

[Anthony Towns]

On Tue, Aug 20, 2002 at 05:56:58PM +0200, Gergely Nagy wrote:
> Some time ago, I assembled a list of packages which were arch: all,
> yet used binary-arch to build the package, and another list of
> packages whose debian/copyright did not have a pointer to the full
> license.

Rather than mass filing bugs, can you write a lintian check for it
instead?

We've _finally_ got lintian running over the archive again, and it looks like
we'll have some chance of keeping it working. The URL is

http://people.debian.org/~joy/

until lintian.debian.org gets updated to point at the right site.

Having a lintian check helps ensure this won't happen again, and gives
QA folks a way of double checking your results and noticing stuff that's not
fixed more easily, too.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
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: Are libtool .la files in non-dev library packages bugs?

[Jason Gunthorpe]

On Tue, 20 Aug 2002, Marcelo E. Magallon wrote:

>  I beg your pardon?  Which naiveness?  That particular bit of libtool
>  solves a very real problem: dlopen is *not* portable.

Careful here, dlopen is defined by SUSv2, all the libtool hackage is does
is allow OS's to get away with not conforming to SUSv2 for longer :<

Jason

Re: Possible mass filing of bugs, take #2.1

[Josip Rodin]

On Wed, Aug 21, 2002 at 02:14:16AM +1000, Anthony Towns wrote:
> Rather than mass filing bugs, can you write a lintian check for it
> instead?

He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
others reverted it >:)

> We've _finally_ got lintian running over the archive again, and it looks like
> we'll have some chance of keeping it working. The URL is
> 
>   http://people.debian.org/~joy/
> 
> until lintian.debian.org gets updated to point at the right site.

Note that lintian.d.o at the current site will likely also be up to date in
about thirteen hours :)

-- 
 2. That which causes joy or happiness.

Re: Possible mass filing of bugs, take #2.1

[Sean 'Shaleh' Perry]

On 20-Aug-2002 Josip Rodin wrote:
> On Wed, Aug 21, 2002 at 02:14:16AM +1000, Anthony Towns wrote:
>> Rather than mass filing bugs, can you write a lintian check for it
>> instead?
> 
> He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
> others reverted it >:)
> 

I think we have better things to be nitpicky about.  Besides, lintian tries to
only enforce policy.

Re: Possible mass filing of bugs, take #2.1

[Josip Rodin]

On Tue, Aug 20, 2002 at 10:23:29AM -0700, Sean 'Shaleh' Perry wrote:
> >> Rather than mass filing bugs, can you write a lintian check for it
> >> instead?
> > 
> > He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
> > others reverted it >:)
> 
> I think we have better things to be nitpicky about.  Besides, lintian
> tries to only enforce policy.

Yeah, well, speaking of better things, when can we expect you to integrate
my lab code patches? I've initially sent them back in August 2001.

-- 
 2. That which causes joy or happiness.

Re: Possible mass filing of bugs, take #2.1

[Sean 'Shaleh' Perry]

On 20-Aug-2002 Josip Rodin wrote:
> On Tue, Aug 20, 2002 at 10:23:29AM -0700, Sean 'Shaleh' Perry wrote:
>> >> Rather than mass filing bugs, can you write a lintian check for it
>> >> instead?
>> > 
>> > He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
>> > others reverted it >:)
>> 
>> I think we have better things to be nitpicky about.  Besides, lintian
>> tries to only enforce policy.
> 
> Yeah, well, speaking of better things, when can we expect you to integrate
> my lab code patches? I've initially sent them back in August 2001.
> 

I just mailed AJ about that.

If all goes well I have the month of September for lintian hacking.

RFA: ifenslave -- Attach and detach slave interfaces to a bonding device.

[Guus Sliepen]

Package: wnpp
Version: N/A; reported 2002-08-20
Severity: normal

I request an adopter for the ifenslave package.
The package description is:
 This is a tool to attach and detach slave network interfaces to a bonding
 device. A bonding device will act like a normal Ethernet network device to
 the kernel, but will send out the packets via the slave devices using a simple
 round-robin scheduler. This allows for simple load-balancing, identical to
 "channel bonding" or "trunking" techniques used in switches.
 .
 The kernel must have support for bonding devices for ifenslave to be useful.

The problem is that ifenslave depends on kernel headers. I'd like
someone more experienced with working with kernel headers to take over
this package.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux haplo 2.4.19-ac4 #1 Tue Aug 6 09:51:40 CEST 2002 i686
Locale: LANG=nl_NL, LC_CTYPE=nl_NL

-- no debconf information

png2/3 problem apparently successfully solved with -Bsymbolic

[Luca Barbieri]

I propose to do the following to solve the libpng2/3 problem. I've
recompiled libpng2. libpng3 and libgtk2.0-0png3 locally and the system
seems to work correctly.
1. Recompile libpng2 and libpng3 with -Bsymbolic
2. Recompile all libraries that use either libpng2 or libpng3 to
   explicitly link to them and to use -Bsymbolic
3. Recompile all programs that use either libpng2 or libpng3 to
   explicitly link to them  [all programs should already do
   this]
4. Make either libgtk2.0-0 or libgtk2.0-0png3 a dummy package
   depending on the other

Note1: for GTK+ 2.0, only the png loader plugin needs to be recompiled
with -Bsymbolic

Note2: "recompile with -Bsymbolic" means "add -Wl,-Bsymbolic to the
flags passed to the compiler in the linking stage, rebuild and upload
the new package"

Doing this will allow applications using GTK+ to use either libpng2 or
libpng3 and still work correctly.


I'll now explain what the problem is and why this solution works.
The problem is that libpng2 and libpng3 have symbols with different
names and we want to have both loaded in the same address space.

Symbols are resolved by the GNU dynamic linker, part of glibc, that
normally uses the same search list for all modules.
This means that normally when two symbols have the same name everything
will use the symbol in the first module loaded.
What we instead want is to use the symbol in the library that the
calling module links to.

Fortunately the ELF object format offers a "flag" called DT_SYMBOLIC
that alters the search path so that symbols are first searched starting
from the calling module.
This is exactly what we need.

So we can solve this by making sure that anything that wants to use png
symbols:
1. Directly links to the desired version of libpng
2. Is either the main program or is linked with -Bsymbolic


Of course, there is a drawback: programs will no longer be able to
always redefine library symbols. AFAIK this is mostly irrelevant when
compared to the problems that come from not doing this.

Are there any problems that would be caused by these changes?



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

Re: Possible mass filing of bugs, take #2.1

[Anthony Towns]

On Tue, Aug 20, 2002 at 10:23:29AM -0700, Sean 'Shaleh' Perry wrote:
> On 20-Aug-2002 Josip Rodin wrote:
> > On Wed, Aug 21, 2002 at 02:14:16AM +1000, Anthony Towns wrote:
> >> Rather than mass filing bugs, can you write a lintian check for it
> >> instead?
> > He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
> > others reverted it >:)
> I think we have better things to be nitpicky about.  Besides, lintian tries to
> only enforce policy.

>From an archive management POV, that's probably not good enough:
we need a tool that can run automatic checks over *all* our archive,
whether it's stuff that's definitely wrong or only indicative, whether
it's for policy or just curiousity or whatever.

Things like libdb1 compliance, usage of nice(2), statistics for debhelper
versus debstd usage, are all better collected by lintian.debian.org than
by separate scripts. And we really need to be able to get those sorts
of things in an easy and automated fashion, trying to keep a handle on
the sheer scope of all the software in Debian is difficult, at best.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
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: Possible mass filing of bugs, take #2.1

[Wichert Akkerman]

Previously Sean 'Shaleh' Perry wrote:
> If all goes well I have the month of September for lintian hacking.

So how does lintian compare to linda these days? Will both be
actively maintained and do the exact same thing?

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.wiggy.net/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Possible mass filing of bugs, take #2.1

[Anthony Towns]

On Tue, Aug 20, 2002 at 09:33:39PM +0200, Wichert Akkerman wrote:
> Previously Sean 'Shaleh' Perry wrote:
> > If all goes well I have the month of September for lintian hacking.
> So how does lintian compare to linda these days? Will both be
> actively maintained and do the exact same thing?

linda doesn't run cleanly over the entire archive -- it misbehaves on
some packages (leaving /tmp/linda-* directories about), and just seems
to hang on others. I haven't tracked down what's causing this. I don't
believe it includes all the checks lintian does either, although in some
cases that might be a win...

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
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: Possible mass filing of bugs, take #2.1

[Florian Weimer]

Anthony Towns  writes:

> Things like libdb1 compliance, usage of nice(2), statistics for debhelper
> versus debstd usage, are all better collected by lintian.debian.org than
> by separate scripts.

Input for a database of historical MD5 hashes of individual files
would be nice, too.


-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT  fax +49-711-685-5898

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Henrique de Moraes Holschuh]

On Tue, 20 Aug 2002, Luca Barbieri wrote:
> I propose to do the following to solve the libpng2/3 problem. I've
> recompiled libpng2. libpng3 and libgtk2.0-0png3 locally and the system
> seems to work correctly.

> 1. Recompile libpng2 and libpng3 with -Bsymbolic

Well, either this or using versioned symbols is required, and would have
almost the same effect.

> 2. Recompile all libraries that use either libpng2 or libpng3 to
>explicitly link to them and to use -Bsymbolic

This should not be needed if versioned symbols are used. Do note that if you
compile something with -Bsymbolic, you cannot override the symbols it
both defines and uses.  So, -Bsymbolic is more prone to cause side-efects
than versioned symbols.

> Note2: "recompile with -Bsymbolic" means "add -Wl,-Bsymbolic to the
> flags passed to the compiler in the linking stage, rebuild and upload
> the new package"

Versioning would be -Wl,-soname,[EMAIL PROTECTED](MAJOR)  where $(MAJOR) is the
versioning we want to apply.

> I'll now explain what the problem is and why this solution works.
> The problem is that libpng2 and libpng3 have symbols with different
> names and we want to have both loaded in the same address space.

I would like to have them in different address spaces, thank you very much
:)  That's what symbol versioning does.

> So we can solve this by making sure that anything that wants to use png
> symbols:
> 1. Directly links to the desired version of libpng
> 2. Is either the main program or is linked with -Bsymbolic

(2) should NOT be needed. At least not if the explanation of -Bsymbolic drow
gave me on IRC (which seems to be what the ld info page says about the
matter) is correct.

Could you try that again without using -Bsymbolic in anything but png2 and
png3?

> Are there any problems that would be caused by these changes?

Well, -Bsymbolic is rumored not to be very portable, but as long as ld
supports it in all of our archs, that's a moot problem.

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

Bug#157439: ITP: blosxom -- A lightweight yet feature-packed weblog tool.

[Marc Nozell]

Package: wnpp
Version: 0+4i; reported 2002-08-20
Severity: wishlist


* Package name: blosxom
  Version : 0.4.0
  Upstream Author : Rael Dornfest <[EMAIL PROTECTED]>
* URL : 
http://www.oreillynet.com/~rael/lang/perl/blosxom/downloads/blosxom

* License : MIT
  Description : A lightweight yet feature-packed weblog tool.

Blosxom [pronounced "blossom" or "blogsome"] is a lightweight yet
feature-packed Weblog application designed from the ground up with
simplicity, usability, and interoperability in mind.

Features include permalinks for stories, by-day/month/year archives, 
style with CSS & HTML header/footer and RSS syndication

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux elephanttalk-wireless 2.4.18-5 #1 Mon Jun 10 15:31:48 EDT 2002 
i686
Locale: LANG=C, LC_CTYPE=C

-- no debconf information

orphaning most (of my) packages

[Robert van der Meulen]

Hi,

I'm going to orphan most of my packages. Before I upload them with
Maintainer: set to QA, i'd like people to look at them and see if they want
anything :)
Some of the - less intensive - packages I'm keeping, the others I can't keep
on maintaining due to several reasons (bought a house, plan to be busy with
that, busy time at work, social stuff).
Please contact me if you want to take anything; most of them will be
first-come, first-serve.

Orphaning:
kernel-patch-2.2.18-openwall (needs updating to more recent kernel, and
general maintenance)
libphp-adodb (a php database abstraction layer, required for 'acidlab')
lvm-common (this should go to the new lvm maintainer, I think. Cc to him
for this reason)
razor   ('needed' by spamasassin; needs updating)
xonix-jahu (ancient game)
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.

Greets,
Robert
-- 
( o>  Linux Generation  

pgpC7VWxy1vys.pgp
Description: PGP signature

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Steve Langasek]

On Tue, Aug 20, 2002 at 09:25:06PM +0200, Luca Barbieri wrote:
> I propose to do the following to solve the libpng2/3 problem. I've
> recompiled libpng2. libpng3 and libgtk2.0-0png3 locally and the system
> seems to work correctly.
> 1. Recompile libpng2 and libpng3 with -Bsymbolic
> 2. Recompile all libraries that use either libpng2 or libpng3 to
>explicitly link to them and to use -Bsymbolic
> 3. Recompile all programs that use either libpng2 or libpng3 to
>explicitly link to them  [all programs should already do
>this]
> 4. Make either libgtk2.0-0 or libgtk2.0-0png3 a dummy package
>depending on the other

> Note1: for GTK+ 2.0, only the png loader plugin needs to be recompiled
> with -Bsymbolic

> Note2: "recompile with -Bsymbolic" means "add -Wl,-Bsymbolic to the
> flags passed to the compiler in the linking stage, rebuild and upload
> the new package"

> Doing this will allow applications using GTK+ to use either libpng2 or
> libpng3 and still work correctly.

> I'll now explain what the problem is and why this solution works.
> The problem is that libpng2 and libpng3 have symbols with different
> names and we want to have both loaded in the same address space.

> Symbols are resolved by the GNU dynamic linker, part of glibc, that
> normally uses the same search list for all modules.
> This means that normally when two symbols have the same name everything
> will use the symbol in the first module loaded.
> What we instead want is to use the symbol in the library that the
> calling module links to.

>sing -Bsymbolic ensures that whenever the libpng library makes a call to
one of its own functions, the symbol is resolved internally instead of to
another version of libpng that's loaded.  This may account for a majority
of the segfaults that people are seeing.  It does not affect how symbols
are resolved when something /outside/ of libpng tries to call a function
belonging to libpng.

If the ABI has changed between libpng2 and libpng3 (which it supposedly
has), there is still a danger of segfaults whenever both of these
libraries are loaded into memory -- with or without -Bsymbolic.

Steve Langasek
postmodern programmer


pgprCf581oFIH.pgp
Description: PGP signature

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Luca Barbieri]

On Tue, 2002-08-20 at 21:46, Henrique de Moraes Holschuh wrote:
> On Tue, 20 Aug 2002, Luca Barbieri wrote:
> > I propose to do the following to solve the libpng2/3 problem. I've
> > recompiled libpng2. libpng3 and libgtk2.0-0png3 locally and the system
> > seems to work correctly.
> 
> > 1. Recompile libpng2 and libpng3 with -Bsymbolic
> 
> Well, either this or using versioned symbols is required, and would have
> almost the same effect.
Do they work without needing to recompile programs?
Versioned symbols (or simply symbols with a version number in the name)
are surely better but the damage is already done.
This is just a way to solve the current problem of having to choose
between a libpng2 or libpng3 system rather than a long-term plan for
shared library design.

> > 2. Recompile all libraries that use either libpng2 or libpng3 to
> >explicitly link to them and to use -Bsymbolic
> 
> This should not be needed if versioned symbols are used. Do note that if you
> compile something with -Bsymbolic, you cannot override the symbols it
> both defines and uses.  So, -Bsymbolic is more prone to cause side-efects
> than versioned symbols.
Surely. Are there any known real-world problems that would be caused by
this?

> > Note2: "recompile with -Bsymbolic" means "add -Wl,-Bsymbolic to the
> > flags passed to the compiler in the linking stage, rebuild and upload
> > the new package"
> 
> Versioning would be -Wl,-soname,[EMAIL PROTECTED](MAJOR)  where $(MAJOR) is 
> the
> versioning we want to apply.
Same problem about versioning not being transparent (AFAIK).

> > I'll now explain what the problem is and why this solution works.
> > The problem is that libpng2 and libpng3 have symbols with different
> > names and we want to have both loaded in the same address space.
> 
> I would like to have them in different address spaces, thank you very much
> :)  That's what symbol versioning does.
By "address space" I mean process address space, aka the thing described
by the kernel struct mm_struct that has its own set of pagetables and
mmap areas and that is shared if you pass the CLONE_VM flag to clone.

> > So we can solve this by making sure that anything that wants to use png
> > symbols:
> > 1. Directly links to the desired version of libpng
> > 2. Is either the main program or is linked with -Bsymbolic
> 
> (2) should NOT be needed. At least not if the explanation of -Bsymbolic drow
> gave me on IRC (which seems to be what the ld info page says about the
> matter) is correct.
It is necessary because otherwise the library/program will use the first
version of libpng in the global search list, which is exactly what we
want to avoid.
In case the module is the main program this is actually OK, so we don't
need -Bsymbolic.

> Could you try that again without using -Bsymbolic in anything but png2 and
> png3?
It won't work. -Bsymbolic affects the search path of the object that it
is applied to so applying it to just libpng? is not enough (AFAIK) (But
necessary because, as ridiculous as it may seem, one of the libpngs will
use symbols from the other one).

> > Are there any problems that would be caused by these changes?
> 
> Well, -Bsymbolic is rumored not to be very portable, but as long as ld
> supports it in all of our archs, that's a moot problem.
AFAIK it does, if all our archs use glibc, that I think is the case.
Anyway, this is a standard feature of the ELF object format, not the
loader, so it should work on all non-broken ELF platforms (even if they
aren't glibc-based).



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

Re: Possible mass filing of bugs, take #2.1

[Gergely Nagy]

> >> Rather than mass filing bugs, can you write a lintian check for it
> >> instead?
> > 
> > He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
> > others reverted it >:)
> > 
> 
> I think we have better things to be nitpicky about.  Besides, lintian tries to
> only enforce policy.

Spelling checks... But we had that argument already, interested
parties can check the bug logs.


pgpXmyamSAAic.pgp
Description: PGP signature

Re: Possible mass filing of bugs, take #2.1

[Gergely Nagy]

> On Tue, Aug 20, 2002 at 05:56:58PM +0200, Gergely Nagy wrote:
> > Some time ago, I assembled a list of packages which were arch: all,
> > yet used binary-arch to build the package, and another list of
> > packages whose debian/copyright did not have a pointer to the full
> > license.
> 
> Rather than mass filing bugs, can you write a lintian check for it
> instead?

Well, how about writing a lintian check AND reporting? There is no
guarantee that the maintainer will run lintian over the package, so
I'd like to notify them.

(No, I will not write a linda check, that is up to StevenK, if it is
not done yet. :)


pgpQAc1xupw8a.pgp
Description: PGP signature

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Luca Barbieri]

> using -Bsymbolic ensures that whenever the libpng library makes a call to
> one of its own functions, the symbol is resolved internally instead of to
> another version of libpng that's loaded.  This may account for a majority
> of the segfaults that people are seeing.  It does not affect how symbols
> are resolved when something /outside/ of libpng tries to call a function
> belonging to libpng.
That's why I said that all libraries that use libpng must also use
-Bsymbolic.
For programs -Bsymbolic has no effect since they are the first element
in the search list (so they automatically work correctly).



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

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Steve Langasek]

On Tue, Aug 20, 2002 at 10:16:23PM +0200, Luca Barbieri wrote:
> > using -Bsymbolic ensures that whenever the libpng library makes a call to
> > one of its own functions, the symbol is resolved internally instead of to
> > another version of libpng that's loaded.  This may account for a majority
> > of the segfaults that people are seeing.  It does not affect how symbols
> > are resolved when something /outside/ of libpng tries to call a function
> > belonging to libpng.
> That's why I said that all libraries that use libpng must also use
> -Bsymbolic.

No, that doesn't help at all.  -Bsymbolic only helps if the symbol you're
looking for is *inside the library calling it*.  It has no effect on how
resolving is done when a library calls a function from another library.

Steve Langasek
postmodern programmer


pgpXg7NsDg3or.pgp
Description: PGP signature

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Henrique de Moraes Holschuh]

On Tue, 20 Aug 2002, Luca Barbieri wrote:
> > Well, either this or using versioned symbols is required, and would have
> > almost the same effect.
> Do they work without needing to recompile programs?

They work without a recompile, BUT they fix nothing on that case: the first
symbol found will be used.  They don't worsen the breakage, though.

They do break the ABI in a backwards-compatible manner (old stuff will work
with either versioned or non-versioned libs.  New stuff will want the
versioned libs).

> This is just a way to solve the current problem of having to choose
> between a libpng2 or libpng3 system rather than a long-term plan for
> shared library design.

[...]

> > compile something with -Bsymbolic, you cannot override the symbols it
> > both defines and uses.  So, -Bsymbolic is more prone to cause side-efects
> > than versioned symbols.
> Surely. Are there any known real-world problems that would be caused by
> this?

Yes, if you apply -Bsymbolic to a lib you will need to override symbols for
some trickery.  I don't know if it won't cause trouble for debuggers,
either.

> > > 1. Directly links to the desired version of libpng
> > > 2. Is either the main program or is linked with -Bsymbolic
> > (2) should NOT be needed. At least not if the explanation of -Bsymbolic drow
> > gave me on IRC (which seems to be what the ld info page says about the
> > matter) is correct.
> It is necessary because otherwise the library/program will use the first
> version of libpng in the global search list, which is exactly what we
> want to avoid.

But -Bsymbolic is supposed to apply only to symbols that were defined AND
used (as in inclusive AND) in that module.  Either that, or drow is wrong,
the ld info page is broken:

  "When creating a shared library, bind references to global symbols  
   to the definition within the shared library, if any." -- ld info page

So, you're saying that it applies to all global symbols used within the
library (regardless of wether it defines the symbol or just uses it from
somewhere else) ?

> It won't work. -Bsymbolic affects the search path of the object that it
> is applied to so applying it to just libpng? is not enough (AFAIK) (But
> necessary because, as ridiculous as it may seem, one of the libpngs will
> use symbols from the other one).

The question is: *how* -Bsymbolic affects the search of symbols that are
external to the module it was applied to (as in used by the module, but
defined elsewhere)?

Your information about the issue clearly differs from mine, so that's why I
asked you to test it -- you already have a proper test case to do it at
hand.

-- 
  "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: Are libtool .la files in non-dev library packages bugs?

[Andrew Suffield]

On Mon, Aug 19, 2002 at 10:06:20PM -0600, Jason Gunthorpe wrote:
> 
> On Mon, 19 Aug 2002, Ben Collins wrote:
> 
> > > > Not only that, it's only useful for linking, so has no reason being in
> > > > the primary runtime.
> > > 
> > > ltdl needs them at runtime.
> > 
> > Then ltdl is broken. How does one install libfoo.so.1 and libfoo.so.2
> > and only have libfoo.la, and ltdl expect to work?
> 
> I was always under the impression that ltdl only really needed the .la
> files on defective OS's, not on linux.. 

It also needs them if:

a) the application makes an lt_dlopen() call explicitly on the .la
file (this should be replaced by lt_dlopenext(), but watch out for
#157230)

b) the .so is not in the same directory as the .la

Both of these issues can and should be corrected.

c) dlpreopen and related features have been used and libtool was
instructed to link statically.

I can't think of any sane reason why you would do that on Debian.

(Other reasons? I can't think of any)

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpPQizsoKUsI.pgp
Description: PGP signature

Re: Are libtool .la files in non-dev library packages bugs?

[Andrew Suffield]

On Tue, Aug 20, 2002 at 02:24:21PM +0200, Marcelo E. Magallon wrote:
> >> Roberto Gordo Saez <[EMAIL PROTECTED]> writes:
> 
>  > Marcelo E. Magallon wrote:
>  > > A wild guess: I don't know about the files named lib*.la, but the other
>  > > ones could be plug-ins.  ltdl opens the .la file to find out the actual
>  > 
>  > Yes, you are right, but... why does a plugin need both .so and .la files?
> 
>  Because when you use ltdl's dlopen replacement, the function looks for
>  the .la file instead of the .so file.

Not so.

lt_dlopen() looks for the exact file you specify.

lt_dlopenext() looks first for .la, then for whatever the local system
conventionally uses (.so on gnu platforms).

Both are quite capable of operating on the .so directly, as long as
you don't use some of the more arcane features (dlpreopen and so
forth).

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpSQVtnHIsyM.pgp
Description: PGP signature

Re: orphaning most (of my) packages

[Peter Palfrader]

On Tue, 20 Aug 2002, Robert van der Meulen wrote:

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

Please retitle them to RFP (request for package) rather than closing
them if you still think they'ld make a worthwhile addition to Debian.

yours,
peter

-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
messages preferred.| : :' :  The  universal
   | `. `'  Operating System
 http://www.palfrader.org/ |   `-http://www.debian.org/


pgpzJwnb6oWvz.pgp
Description: PGP signature

Re: Are libtool .la files in non-dev library packages bugs?

[Andrew Suffield]

On Tue, Aug 20, 2002 at 10:43:58AM -0600, Jason Gunthorpe wrote:
> 
> On Tue, 20 Aug 2002, Marcelo E. Magallon wrote:
> 
> >  I beg your pardon?  Which naiveness?  That particular bit of libtool
> >  solves a very real problem: dlopen is *not* portable.
> 
> Careful here, dlopen is defined by SUSv2, all the libtool hackage is does
> is allow OS's to get away with not conforming to SUSv2 for longer :<

It also supports platforms which do not have shared libraries. I
didn't think SuSv2 actually required them (can't see anything that
does, references welcome).

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgp6lyX23uthH.pgp
Description: PGP signature

Re: orphaning most (of my) packages

[Ivo Timmermans]

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.


Ivo

-- 
Deja moo: the feeling you've heard this bullshit before.

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Luca Barbieri]

Yes, you are right, by reading at the source it seems that ld.so only
searches the object with -Bsymbolic.

In fact there is this comment in the relevant file:
  /* Create an appropriate searchlist.  It contains only this map.

 XXX This is the definition of DT_SYMBOLIC in SysVr4.  The old
 GNU ld.so implementation had a different interpretation which
 is more reasonable.  We are prepared to add this possibility
 back as part of a GNU extension of the ELF format.  */

Apparently the "different interpretation" is what I was assuming the
current one.

How about the implementing the GNU extension? 
The value attached to the DT_SYMBOLIC entry is currently ignored but set
to 0 by ld so we could use it for the extension.
On non-Debian/non-GNU platforms this would interpreted just like
DT_SYMBOLIC.

This would only require modification of ld.so (add support for
DT_SYMBOLIC and value=1) and ld (add -Bgnusymbolic).

Or, alternatively, how about changing the semantics of DT_SYMBOLIC?
(shouldn't cause serious problems, would it?)



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

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Henrique de Moraes Holschuh]

On Tue, 20 Aug 2002, Luca Barbieri wrote:
> Apparently the "different interpretation" is what I was assuming the
> current one.

Yeah, I was in a severe headache for a while because I too knew about the
old interpretation apparently.

> How about the implementing the GNU extension? 

It would be useful, yes.  But I think it is completely out of the
possibilities for the near future -- you need to get it upstream, and let it
deploy first.

So can we go with versioned symbols (plus -Bsymbolic in key libraries if
just versioned symbols isn't enough for that particular library -- not many
have an API so broken that -Bsymbolic is actually required when versioned
symbols are in use).

> Or, alternatively, how about changing the semantics of DT_SYMBOLIC?
> (shouldn't cause serious problems, would it?)

I am somehow very not amused by the idea of tracking down the problems this
_could_ cause.  If we didn't have versioned symbols, I'd say go for it.  But
we do, so IMHO we really should take the clean path.

-- 
  "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: png2/3 problem apparently successfully solved with -Bsymbolic

[Steve Langasek]

On Tue, Aug 20, 2002 at 06:02:35PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 20 Aug 2002, Luca Barbieri wrote:
> > Apparently the "different interpretation" is what I was assuming the
> > current one.

> Yeah, I was in a severe headache for a while because I too knew about the
> old interpretation apparently.

> > How about the implementing the GNU extension? 

> It would be useful, yes.  But I think it is completely out of the
> possibilities for the near future -- you need to get it upstream, and let it
> deploy first.

> So can we go with versioned symbols (plus -Bsymbolic in key libraries if
> just versioned symbols isn't enough for that particular library -- not many
> have an API so broken that -Bsymbolic is actually required when versioned
> symbols are in use).

FWIW, I find that -Bsymbolic tends to be useful in its own right; I've
never met anyone who had a good reason for trying to override a library's
internal references, but I have seen many cases where not using
-Bsymbolic caused namespace conflicts and segfaults.  This is a
particularly popular source of bugs with Apache/PHP.

It's just that -Bsymbolic doesn't solve this particular problem.

Steve Langasek
postmodern programmer


pgp9eUcygeJQI.pgp
Description: PGP signature

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Luca Barbieri]

On Tue, 2002-08-20 at 23:02, Henrique de Moraes Holschuh wrote:
> On Tue, 20 Aug 2002, Luca Barbieri wrote:
> > Apparently the "different interpretation" is what I was assuming the
> > current one.
> 
> Yeah, I was in a severe headache for a while because I too knew about the
> old interpretation apparently.
> 
> > How about the implementing the GNU extension? 
> 
> It would be useful, yes.  But I think it is completely out of the
> possibilities for the near future -- you need to get it upstream, and let it
> deploy first.
Why?
Can't we just use it in Debian?
If we do it by using the tag associated with DT_SYMBOLIC it will be
completely compatible.

Libraries using it will be treated like normal -Bsymbolic ones on
non-Debian glibc systems (the user can tell the difference with
readelf).



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

Bug#157449: lintian: check for missing reference to he perl license terms (Was: Re: Possible mass filing of bugs, take #2.1)

[Gergely Nagy]

Package: lintian
Version: 1.20.17
Severity: wishlist
Tags: patch

> Rather than mass filing bugs, can you write a lintian check for it
> instead?

As promised, here is the check:

diff -u -urNad old/copyright-file new/copyright-file
--- old/copyright-file  2002-08-20 23:04:54.0 +0200
+++ new/copyright-file  2002-08-20 23:04:41.0 +0200
@@ -164,6 +164,11 @@
 print "W: $pkg $type: copyright-does-not-refer-to-common-license-file 
$1\n";
 }
 
+if (m,(under )?(the )?(same )?(terms )?as Perl itself,i &&
+!(m,usr/share/common-licenses/, || m,usr/share/doc/perl,)) {
+print "E: $pkg: $type: copyright-file-missing-pointer-to-perl-license\n";
+}
+
 exit 0;
 
 # ---
diff -u -urNad old/copyright-file.desc new/copyright-file.desc
--- old/copyright-file.desc 2002-08-20 23:04:54.0 +0200
+++ new/copyright-file.desc 2002-08-20 23:04:36.0 +0200
@@ -112,3 +112,10 @@
 Ref: policy 13.6
 Info: In the directory name /usr/share/common-licenses, licenses is spelt with 
  an `s', not with as licences with a `c'.
+
+Tag: copyright-file-missing-pointer-to-perl-license
+Type: error
+Ref: policy 13.6
+Info: If your package is released under the same terms as Perl itself,
+ it should either refer to the Artistic and GPL files in the
+ /usr/share/common/licenses directory, or to /usr/share/doc/perl/copyright.


Obviously, this is tuned for Perl modules released under the same
terms as Perl itself.

The check is tested outside of lintian, and appears to work
correctly. I hope it'll work in lintian too.

[Incident 020820-000518] For Jobs!

[teachervision]

---
Thank you for contacting Family Education Network!  We will respond to your 
inquiry as soon as possible. 

We have listed some solutions to your question below.  Please note that these 
are only suggested solutions.  Your email has been forwarded to the customer 
support group from which you will receive a response as soon as possible.  

Get help from Family Education Network's Online Support Center 24 hours a day, 
7 days a week. We have answers to all of your questions.  Whether you're a 
parent looking for great articles about kids, a teacher
looking for technical help with one of our online applications, whether you 
need to return an item you purchased, or if you've forgotten your password, 
Family Education Network's Online Support Center can help -immediately!


Title: When I print out my Email Card, the bottom part (containing the message) 
doesn't
Link: 
http://fen.custhelp.com/cgi-bin/learningnetwork.cfg/php/enduser/std_adp.php?p_faqid=266&p_created=1003935988

Title: How can I find current job openings?
Link: 
http://fen.custhelp.com/cgi-bin/learningnetwork.cfg/php/enduser/std_adp.php?p_faqid=212&p_created=998678372

Title: Why does it take so long for PDFs to download?
Link: 
http://fen.custhelp.com/cgi-bin/learningnetwork.cfg/php/enduser/std_adp.php?p_faqid=210&p_created=998678178

Title: I want to put HTML (or pictures, or attachments) in the Email Card.
Link: 
http://fen.custhelp.com/cgi-bin/learningnetwork.cfg/php/enduser/std_adp.php?p_faqid=282&p_created=1003935800



Sincerely,
Family Education Network Staff


You may update your incident at 
http://fen.custhelp.com/cgi-bin/learningnetwork.cfg/php/enduser/[EMAIL 
PROTECTED]&p_next_page=myq_upd.php&p_refno=020820-000518&p_created=1029878329


Question
---
RAV AntiVirus has deleted this file
 because it contained dangerous code!

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Henrique de Moraes Holschuh]

On Tue, 20 Aug 2002, Steve Langasek wrote:
> FWIW, I find that -Bsymbolic tends to be useful in its own right; I've

Oh, it is *very* useful when not using versioned symbols. It's just that it
gets far more difficult to have namespace clashes when using versioned
symbols (as long as the versioning ALSO has the library name as a prefix, I
suppose -- glibc does it this way), so -Bsymbolic is less necessary then.

> never met anyone who had a good reason for trying to override a library's
> internal references, but I have seen many cases where not using

Some tricks using LD_PRELOAD *might* just require that.  Well, since we will
NOT be compiling libc with -Bsymbolic (eek!), this is less of an issue.

> It's just that -Bsymbolic doesn't solve this particular problem.

Indeed.

-- 
  "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: png2/3 problem apparently successfully solved with -Bsymbolic

[Henrique de Moraes Holschuh]

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?

Do it upstream, or don't do it.  We also want the other distros to follow
whatever proper fix we make to the png (and other libraries causing such
trouble, such as libsasl and probably libldap in the future) if such a thing
is possible.

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

enter Chinese market

[zqcx]

Dear Sir or Madam:

Please reply to 
Receiver: China Enterprise Management Co., Ltd. (CMC)
E-mail: [EMAIL PROTECTED]

As one technical organization supported by China Investment and Technical 
Promotion Office of United Nation Industry Development Organization (UNIDO), we 
cooperate closely with the relevant Chinese Quality Supervision and 
Standardization Information Organization. We provide the most valuable 
consulting services to help you to open Chinese market within the shortest time:

1. Consulting Service on Mandatory National Standards of The People's Republic 
of China.

2. Consulting Service on Inspection and Quarantine Standards of The People's 
Republic of China.

3. Consulting Service for Permission to Enter Chinese Market

We are very sorry to disturb you! 

More information, please check our World Wide Web: http://www.chinatop.net

Sincerely yours

Bug#157450: ITP: libsdl-anim -- Library to load animations and blit them to surfaces

[Julien Danjou]

Package: wnpp
Version: N/A; reported 2002-08-20
Severity: wishlist

* Package name: libsdl-anim
  Version : 0.5.0
  Upstream Author : Michael Leonhard <[EMAIL PROTECTED]>
* URL : http://tamale.net/SDL_anim/
* License : LGPL
  Description : Library to load animations and blit them to surfaces

 This is a simple library to load animations and blit them to SDL surfaces.

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux chulak 2.4.19 #1 lun aoû 5 02:25:33 CEST 2002 i686
Locale: LANG=fr_FR, LC_CTYPE=fr_FR

-- 
Julien Danjou

(°>  - http://jdanjou.org   <[EMAIL PROTECTED]> -
//\  - http://tuxfamily.org   <[EMAIL PROTECTED]> -
V_/_ GPG: 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD


pgppdhdK2Tpdl.pgp
Description: PGP signature

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Luca Barbieri]

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.

IMHO this isn't something to worry about.



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

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Henrique de Moraes Holschuh]

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.

I have nothing against writing the patches and proposing them upstream, mind
you.  I don't think we should be _deploying_ it before upstream accepts
them, though.

-- 
  "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: png2/3 problem apparently successfully solved with -Bsymbolic

[Luca Barbieri]

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?
I forgot to mention that if they want binary compatibility, their
extension must be gracefully ignorable and if there are no symbol name
conflicts my proposed implementation is equivalent to ignoring the
field.



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

Re: png2/3 problem apparently successfully solved with -Bsymbolic

[Luca Barbieri]

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.



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

Re: Possible mass filing of bugs, take #2.1

[Joey Hess]

Anthony Towns wrote:
> Things like libdb1 compliance, usage of nice(2), statistics for debhelper
> versus debstd usage, are all better collected by lintian.debian.org than
> by separate scripts.

I quite agree, and I would love to stop churning auric each morning
grepping the whole archive for the last two of those. If I could hook
into something that would run my program incrementally each time a
updated package entered the archive, and give it a lintian source lab to
examine, much cpu would be saved. If the people working on lintian.d.o
are interested in supporting this type of thing, please get in touch
with me.

-- 
see shy jo

apt-get wants to upgrade package to same version?

[Brian May]

Hello,

I have just being playing around with apt-proxy, and noticed something
weird. Every time I run apt-get, it wants to upgrade the packages it
just upgraded 5 seconds ago (it only happens on this computer, too):

(note: se_apt-get is the same thing as apt-get, but sets
the selinux domain up correctly).

scrooge:/tmp# se_apt-get upgrade
Authenticating bam.
Password: 
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages have been kept back
  stat 
12 packages upgraded, 0 newly installed, 0 to remove and 1  not
upgraded.
Need to get 0B/1052kB of archives. After unpacking 0B will be used.
Do you want to continue? [Y/n] 
Reading changelogs... Done
(Reading database ... 104220 files and directories currently installed.)
Preparing to replace libkrb-1-kerberos4kth 1.1-11-2 (using
.../libkrb-1-kerberos4kth_1.1-11-2_i386.deb) ...
Unpacking replacement libkrb-1-kerberos4kth ...
Preparing to replace libacl1-kerberos4kth 1.1-11-2 (using
.../libacl1-kerberos4kth_1.1-11-2_i386.deb) ...
Unpacking replacement libacl1-kerberos4kth ...
Preparing to replace libcomerr1-kerberos4kth 1.1-11-2 (using
.../libcomerr1-kerberos4kth_1.1-11-2_i386.deb) ...
Unpacking replacement libcomerr1-kerberos4kth ...
Preparing to replace libkadm1-kerberos4kth 1.1-11-2 (using
.../libkadm1-kerberos4kth_1.1-11-2_i386.deb) ...
Unpacking replacement libkadm1-kerberos4kth ...
Preparing to replace libkdb-1-kerberos4kth 1.1-11-2 (using
.../libkdb-1-kerberos4kth_1.1-11-2_i386.deb) ...
Unpacking replacement libkdb-1-kerberos4kth ...
Preparing to replace libroken9-kerberos4kth 1.1-11-2 (using
.../libroken9-kerberos4kth_1.1-11-2_i386.deb) ...
Unpacking replacement libroken9-kerberos4kth ...
Preparing to replace libotp0-kerberos4kth 1.1-11-2 (using
.../libotp0-kerberos4kth_1.1-11-2_i386.deb) ...
Unpacking replacement libotp0-kerberos4kth ...
Preparing to replace libsl0-kerberos4kth 1.1-11-2 (using
.../libsl0-kerberos4kth_1.1-11-2_i386.deb) ...
Unpacking replacement libsl0-kerberos4kth ...
Preparing to replace libss0-kerberos4kth 1.1-11-2 (using
.../libss0-kerberos4kth_1.1-11-2_i386.deb) ...
Unpacking replacement libss0-kerberos4kth ...
Preparing to replace libkafs0-kerberos4kth 1.1-11-2 (using
.../libkafs0-kerberos4kth_1.1-11-2_i386.deb) ...
Unpacking replacement libkafs0-kerberos4kth ...
Preparing to replace kerberos4kth-dev 1.1-11-2 (using
.../kerberos4kth-dev_1.1-11-2_i386.deb) ...
Unpacking replacement kerberos4kth-dev ...
Preparing to replace kerberos4kth1 1.1-11-2 (using
.../kerberos4kth1_1.1-11-2_all.deb) ...
Unpacking replacement kerberos4kth1 ...
Setting up libkrb-1-kerberos4kth (1.1-11-2) ...

Setting up libacl1-kerberos4kth (1.1-11-2) ...

Setting up libcomerr1-kerberos4kth (1.1-11-2) ...

Setting up libkadm1-kerberos4kth (1.1-11-2) ...

Setting up libkdb-1-kerberos4kth (1.1-11-2) ...

Setting up libroken9-kerberos4kth (1.1-11-2) ...

Setting up libotp0-kerberos4kth (1.1-11-2) ...

Setting up libsl0-kerberos4kth (1.1-11-2) ...

Setting up libss0-kerberos4kth (1.1-11-2) ...

Setting up libkafs0-kerberos4kth (1.1-11-2) ...

Setting up kerberos4kth-dev (1.1-11-2) ...

Setting up kerberos4kth1 (1.1-11-2) ...


What is going on here? Why does it not realize the package it just
installed is the package it just downloaded?

scrooge:/tmp# apt-cache policy kerberos4kth1
kerberos4kth1:
  Installed: 1.1-11-2
  Candidate: 1.1-11-2
  Version Table:
 1.1-11-2 0
 -1 http://snoopy.apana.org.au unstable/main Packages
 1.1-11-2 0
700 http://snoopy.apana.org.au woody/main Packages
 *** 1.1-11-2 0
100 /var/lib/dpkg/status
 1.1-8-2 0
700 http://snoopy.apana.org.au woody/updates/main Packages
700 http://snoopy.apana.org.au woody/non-US/main Packages

scrooge:/tmp# md5sum /var/cache/apt/archives/kerberos4kth1_1.1-11-2_all.deb 
330d49310a3264f037875e06a1328458 
/var/cache/apt/archives/kerberos4kth1_1.1-11-2_all.deb

This is the same MD5SUM in 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

All I can think of is that apt-get is getting confused
for some reason between that entry and this unstable entry
(this version of kerberos4kth is not installable on my system
due to a dependancy on the new version of libc6, not shown
in this package):

Package: kerberos4kth1
Priority: optional
Section: net
Installed-Size: 68
Maintainer: Mikael Andersson <[EMAIL PROTECTED]>
Architecture: all
Source: krb4
Version: 1.1-11-2
Filename: pool/main/k/krb4/kerberos4kth1_1.1-11-2_all.deb
Size: 57584
MD5sum: d2578663139242eb543153aad6e46597
Description: Dummy library package for Kerberos4 From KTH.
 This is a dummy package. It should be safe to

Bug#157710: bug in compiler (cpp) internal error code 323 in main.cpp:174

[simon]

Package: general
Version: N/A; reported 2002-08-21
Severity: important



-- System Information
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux pentangle.dyndns.org 2.4.18-xfs-1.1 #1 Tue Aug 13 03:58:02 EDT 
2002 ppc
Locale: LANG=C, LC_CTYPE=fr_CA

more specifically, received this error when i was compiling source for
the newer version (1.4.x) of the xshipwars client. **REPRODUCIBLE**.

eric côté

[no subject]

[Ian Zimmerman]

subscribe

Re: apt-get wants to upgrade package to same version?

[Jason Gunthorpe]

On Wed, 21 Aug 2002, Brian May wrote:

> Can't apt realize that if it is going to install a package from source
> X, it should use the Packages entry from source X too?

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.

Jason

Re: apt-get wants to upgrade package to same version?

[Brian May]

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.

What is the problem here?
-- 
Brian May <[EMAIL PROTECTED]>