Re: Installed wajig 0.2.11-1 (i386 source)

[Junichi Uekawa]

On Tue, 08 Jan 2002 15:13:08 -0500
Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:

> Description: 
>  wajig  - Simplified Debian package management front end
> Changes: 
>  wajig (0.2.11-1) unstable; urgency=low
>  .
>* Upgraded to new upstream release
> Files: 
>  e2a0aaa255f1fd9404ccc176c82969c2 619 admin optional wajig_0.2.11-1.dsc
>  33e519867e30638235b9611f5dc51d0c 37539 admin optional 
> wajig_0.2.11.orig.tar.gz
>  b96f5f99b6df7a748a2b53cb16cd67b5 2459 admin optional wajig_0.2.11-1.diff.gz

I just wondered: 
What part of this python script makes it requisite to be 
built for each architecture ?
Why isn't it "all" instead of "any"?

Is byte-compiled python script platform-dependent?


regards,
junichi

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

serious bug. Evolution and Microsoft mentality.

[Jonathan Walther]

--- Begin Message ---
I tried evolution tonight.  It is impressive work.  I wanted to import
my 62 mbox mailboxes and 6 maildirs.  Well, for whatever reason, it
didn't let me import my maildirs.  And the interface for importing
mailboxes is painful for 62 different mailboxes.  So I looked at how to
do it "by hand", as any nice Unix application will easily allow one to
do.

It turns out to be fairly easy.  Find a mail folder of the same type as
the one you want to copy over, duplicate it with its new name, then
symlink your original mbox to Foldername/mbox.  It even has a nice
function to convert my mboxes to maildirs, although new mailboxse are
unfortunately not created in maildir format.  I started evolution up,
my folders were seen, I was happy.  Then I exited.

What happened?  My symlink was erased!  Gone!  A new mbox file had been
created from the contents of the original.  This was bad enough, but it
was a file of different size, indicating that QP (Quoted Printable) encoding
had been redone, which is the cause of the GnuPG compatibility bug.  So
first evolution screwed me by making it so new mails going into the old
mailbox won't be seen from evolution, but then it redoes the emails,
causing GnuPG signatures to yield bogus "bad" matches!

I hope that Evolution won't fall into the grave and anti-Unix error of
assuming it is the only mail handling software on the system, nor that
it can possibly know about all the mail software that is or might be in
use on a system.

Hopefully the symlink-being-erased bug will be fixed soon.  I think
overall Evolution has made great strides and become a great program.
I look forward to further evaluating it when this issue is fixed.

Jonathan
--- End Message ---


pgp7spa0QUuly.pgp
Description: PGP signature

Re: ITP: libtar - c library for manipulating tar archives

[Adam Majer]

On Wed, Jan 09, 2002 at 03:45:52PM +1100, Glenn McGrath wrote:
> I must admit i am somewhat confused by all the different version numbers
> for shared libraries, the libtool manual didnt help a lot either.
> 
> e.g. The definition of the age field in -version-info
> current:revision:age
> 
> age
> The difference between the newest and oldest interfaces that this
> library implements. In other words, the library implements all the
> interface numbers in the range from number current - age to current.
> 
> I must be misinterpreting it, because read this as saying
> mathematically, age < current, and
> age >= current - age, which simplifies to age >= 1/2 * current
> 
> So "in the range from number current - age to current",  could be
> replaced with "in the range from (current/2) to current"
> 
> I think they intended to say age has to be less than current... i
> decided to ignore age completely at that stage.

IMO, if upstream is using libtool, then they should use the
libtool's specification for shared libraries. Then you just have
libtar and libtar-dev packages.

Plus, the current:revision:age is designed to accomodate library
portability. It has nothing to do with version. It is suppose to
provide transparent compatability b/w compatable versions of the
library.

Of course, it only works with C style libraries - C++ libraries 
do not exacly follow this current:revision:age guidelines as C++ 
libraries are difficult to be portable when the library is 
changed.


Sincerely,
Adam

RE: ITP: libtar - c library for manipulating tar archives

[Yves Arrouye]

> e.g. The definition of the age field in -version-info
> current:revision:age
> 
> age
> The difference between the newest and oldest interfaces that this
> library implements. In other words, the library implements all the
> interface numbers in the range from number current - age to current.

Age indicates how many revisions of the library have been upwards
compatible. If you are at revision 7 and still have all the interfaces from
revision 6 unchanged, and 6 had the same for 5, and ... 4 for 3, then age is
7 - 3 = 4.

YA

Re: serious bug. Evolution and Microsoft mentality.

[Jonathan Walther]

On Mon, Jan 07, 2002 at 01:56:24PM -0500, Jeffrey Stedfast wrote:
Yea, this is kinda painful currently but hopefully by 1.2 this will be
much easier. We plan on making it so that you can add a new account
using "Standard Unix Mail Spool" as the source type and pointing it at a
directory and have our code automatically show all the mailboxes in the
directory. Currently it will only accept single mbox files as sources.
That will be very nice.  Will you also let us point to Maildir's and
have it Just Work?  Maildir format allows us to continue using procmail
and related programs without worrying about locking issues between
Evolution and outside mail delivery programs and filters.
It's not really a good idea to use symlinks because Evolution will lock
the symlink file and if you have procmail running, it will lock the real
mbox file and so if you try and access the same mbox file with both
Evolution and procmail, things will end badly for you (ie corrupt
mailbox).
Correct.  Thats why I plan to switch over completely to Maildir format.
What happened?  My symlink was erased!  Gone!  A new mbox file had been
created from the contents of the original.
Did you delete/expunge messages? I presume that you must have because
otherwise the mbox would not have been rewritten. The only way to remove
Unfortunately, no.  I made no changes whatsoever to the mailboxes.  I
just entered them to see if the messages showed up, they did, then I
exited.  Thats when I noticed the symlinks had been blown away, and the
resulting "copied" mailbox was bigger in size than the original!
messages from an mbox file is to rewrite it to a new tmp file (minus the
messages to be deleted) and then rename that tmp file back to its
original name. Unfortunately, UNIX's rename() function clobbers symlinks
and thus your problem.
Well, alright.  I did some research tonight.  Before calling "rename()",
a call to realpath() would resolve the symlink to the correct "real"
filename, and using that would give the correct result.  An extra 3
lines of code (to find out how much storage is needed for the real path,
to allocate it, then finally to call realpath()).
Actually, Evolution plays very nice with other mail software on the
system - you just have to not use symlinks.
Supporting symlinks is easy.  Not supporting them is un-Unixy.
Evolution locks all
mailboxes when it goes to access them to avoid mailbox corruption and so
as long as the other system mail software does the same (which it
should) then they will all live in harmony.
Again, provided one uses Maildir mailboxes, things will be fine.  But
the thought occurs, Evolution should do its "locking" on the file
returned from realpath() too.
Hopefully the symlink-being-erased bug will be fixed soon.  I think
overall Evolution has made great strides and become a great program.
I look forward to further evaluating it when this issue is fixed.
This isn't a bug at all (as explained above).
I vehemently maintain it is a bug, and until it is fixed I can't
recommend Evolution.
Cheers!
Jonathan


pgp9xbcr1NMtH.pgp
Description: PGP signature

Re: ITP: libtar - c library for manipulating tar archives

[Glenn McGrath]

On Wed, 9 Jan 2002 00:15:02 -0600
"Adam Majer" <[EMAIL PROTECTED]> wrote:

> IMO, if upstream is using libtool, then they should use the
> libtool's specification for shared libraries. Then you just have
> libtar and libtar-dev packages.
> 
No, unstream isnt using libtool, upstream only produces static
libraries, i modified the build system to use libtool because i thought
it would make it easier to build the shared library.

> Plus, the current:revision:age is designed to accomodate library
> portability. It has nothing to do with version. It is suppose to
> provide transparent compatability b/w compatable versions of the
> library.
> 

Ahh, i see where i got confused now.. i thought it was based on the
version.


Thanks

Glenn

Re: ITP: libtar - c library for manipulating tar archives

[Glenn McGrath]

On Tue, 8 Jan 2002 22:19:13 -0800 
"Yves Arrouye" <[EMAIL PROTECTED]> wrote:

> 
> > e.g. The definition of the age field in -version-info
> > current:revision:age
> > 
> > age
> > The difference between the newest and oldest interfaces that this
> > library implements. In other words, the library implements all the
> > interface numbers in the range from number current - age to current.
> 
> Age indicates how many revisions of the library have been upwards
> compatible. If you are at revision 7 and still have all the interfaces
from> revision 6 unchanged, and 6 had the same for 5, and ... 4 for 3,
then age is> 7 - 3 = 4.
> 

I see what your saying, but dont you mean current instead of revision ?

So age should always be >= 0 and <= current.



Glenn

Bug#128396: general: /usr/lib/menu/doc-base-happydoc breaks update-menu

[Rich Rudnick]

Package: general
Version: N/A; reported 2002-01-08
Severity: normal
Tags: patch



-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux aias 2.4.16 #3 Tue Nov 27 09:14:26 PST 2001 i686
Locale: LANG=en_US, LC_CTYPE=

dpkg -S /usr/lib/menu/doc-base-happydoc does not return any package 
owning this file, so I'm submitting this as general; please reassign
as needed.

For edification:

rich: ~ $ dpkg -S *happy*
dpkg: *doc-base-happydoc* not found.
rich: ~ $ dpkg -l *happy*
No packages found matching doc-base-happydoc.

Well, the above I don't understand at all :)

Currently, the file on my box contains:

?package(doc-base):needs="dwww" section=""\
 title="HappyDoc Source Documentation"\
 description="This is the Source documentation for HappyDoc"\
 command="/usr/share/doc/python-happydoc-doc/srcdocs/index.html"

With this file in place, update-menu complains that 'section' is empty
and fails out, leaving the Debian sub-menu in my Gnome menu empty.

After examining other python doc packages, I modified as follows:

?package(doc-base):needs="dwww" section="Apps/Programming"\
 title="HappyDoc Source Documentation"\
 description="This is the Source documentation for HappyDoc"\
 command="/usr/share/doc/python-happydoc-doc/srcdocs/index.html"

After adding "Apps/Programming" to 'section', update-menus succeeds,
and the Debian submenu is populated.

Re: serious bug. Evolution and Microsoft mentality.

[Erik Steffl]

Jonathan Walther wrote:
> 
> Subject:
> 
> I tried evolution tonight.  It is impressive work.  I wanted to import
> my 62 mbox mailboxes and 6 maildirs.  Well, for whatever reason, it
> didn't let me import my maildirs.  And the interface for importing
> mailboxes is painful for 62 different mailboxes.  So I looked at how to
> do it "by hand", as any nice Unix application will easily allow one to
> do.
> 
> It turns out to be fairly easy.  Find a mail folder of the same type as
> the one you want to copy over, duplicate it with its new name, then
> symlink your original mbox to Foldername/mbox.  It even has a nice
> function to convert my mboxes to maildirs, although new mailboxse are
> unfortunately not created in maildir format.  I started evolution up,
> my folders were seen, I was happy.  Then I exited.
> 
> What happened?  My symlink was erased!  Gone!  A new mbox file had been
> created from the contents of the original.  This was bad enough, but it
> was a file of different size, indicating that QP (Quoted Printable) encoding
> had been redone, which is the cause of the GnuPG compatibility bug.  So
> first evolution screwed me by making it so new mails going into the old
> mailbox won't be seen from evolution, but then it redoes the emails,
> causing GnuPG signatures to yield bogus "bad" matches!
> 
> I hope that Evolution won't fall into the grave and anti-Unix error of
> assuming it is the only mail handling software on the system, nor that
> it can possibly know about all the mail software that is or might be in
> use on a system.
> 
> Hopefully the symlink-being-erased bug will be fixed soon.  I think
> overall Evolution has made great strides and become a great program.
> I look forward to further evaluating it when this issue is fixed.

  IMO the good solution for this kind of problems is to use IMAP. don't
trust MUAs to work with files.

  (of course, Evolution should play nice with symlinks)

erik

inactivity, and orphaned packages

[Leon Breedt]

Hi,

I don't have the time available at the moment to make any meaningful 
contributions
to Debian, neither do I have access to any Debian Linux systems, so I've 
orphaned
the following packages:

libucl
libucl-dev
libpam-pgsql

I'm also the upstream author of libpam-pgsql, but I'm no longer developing on
that either, if anyone wants to hijack it, go ahead (the code is 'orrible and
has security problems in the SQL access, a rewrite is probably a better option).

Since I don't have access to any Debian Linux machines (RedHat/FreeBSD only),
I was not able to upload changed packages with the maintainer set to
Debian-QA.

Anyhow, I'm not leaving the project, just retreating to an even more low-profile
position.

If there are any responses I need to know about, please CC me as I'm not 
subscribed
to -devel.

Regards,

Leon.

-- 
in theory, there is no difference between theory and practice.

Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]

[Daniel Stone]

On Wed, Jan 09, 2002 at 10:07:13AM +0900, Junichi Uekawa wrote:
> Daniel Stone <[EMAIL PROTECTED]> cum veritate scripsit:
> 
> > > It's only the -dev package, which is only required
> > > for the compile time, and I believe it is quite small, only
> > > with the symlinks and the static link files...
> > > 
> > > Or better, libqt2-dev depend on libpng2-dev.
> > 
> > They generally Build-Depend on libpng2-dev, I believe. 
> 
> If libqt-dev depends on libpng2-dev, and libpng2-dev
> conflicts with libpng3-dev, whic is the case,
> any package build-depending on libqt-dev AND libpng3-dev
> will not build, which is probably the thing 
> we want. Isn't it?

Right.

-- 
Daniel Stone<[EMAIL PROTECTED]>
NEW YORK (CNN) -- Internet users who spend even a few hours a week
online at home experience higher levels of depression and loneliness
than if they had used the computer network less frequently, The New
York Times reported Sunday.  The result ... surprised both
researchers and sponsors, which included Intel Corp., Hewlett Packard,
AT&T Research and Apple Computer.


pgpYat7x2L9Vu.pgp
Description: PGP signature

Re: serious bug. Evolution and Microsoft mentality.

[Jonathan Walther]

On Tue, Jan 08, 2002 at 11:49:12PM -0800, Erik Steffl wrote:
 IMO the good solution for this kind of problems is to use IMAP. don't
trust MUAs to work with files.
 (of course, Evolution should play nice with symlinks)
Note that in his reply, the Evolution maintainer said "the Unix rename()
function erases symlinks, therefore your symlinks being erased is not a bug".
What?  It's not a bug?  Oy vey.
Let's see.  Then there is the "bug" with GnuPG signatures not being
verified correctly due to a Quoted Printable problem.  The answer to
that one was "The problem is the fault of one of our libraries, and it
isn't changing anytime soon, so this is not a bug".
See a trend?  That attitude scares me.  Saying "this would involve a
major rewrite; we'll take care of it later" would be acceptable.  Saying
"the code does things this way; ergo it's not a bug" just SCARES me.  I
feel like GNOME is just going to return us to the land of Microsoft,
where software does unexpected things, and assumes all users are idiots,
even if they are smart enough to use such fine Unix utilities as
"touch", "chown", "chmod", and "ln".
A user who doesn't know what he is doing will attempt to do everything
from the provided GUI.  Its shameful to assume that people that attempt
to use vi to edit their configurations are also idiots.
Jonathan


pgpzpFxCMEfwz.pgp
Description: PGP signature

Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]

[Daniel Stone]

On Wed, Jan 09, 2002 at 12:11:40AM +0100, Adrian Bunk wrote:
> On 7 Jan 2002, Philippe Troin wrote:
> > How do you plan to prevent programs that link with libqt2 to also link
> > with libpng3 ? Manual check ?
> 
> Another possiblility is the following (only the new dependencies are
> listed):
> 
> Package: libqt2-dev
> Conflicts: libpng3
> Build-Conflicts: libpng3
> 
> [note that libpng3 is the library package _not_ the -dev package]
> 
> 
> This way neither a program that links with libqt2 nor a library libqt2 is
> linked with can be linked with libpng3.

What? That means that you can't have a libpng3 program on a machine with
libqt2-dev installed ... icky.

-d

-- 
Daniel Stone<[EMAIL PROTECTED]>
Craig Sanders isn't a real man; he's a social degenerate.
-- Branden Robinson to debian-devel


pgpw6NaFE7bDB.pgp
Description: PGP signature

Re: Bug#127252: kmerlin: Nope, it broke it

[Daniel Stone]

On Wed, Jan 09, 2002 at 07:38:47AM +1100, Mark Purcell wrote:
> Ok I see what has happened now.
> 
> The libpng2/3 fiasco continues.
> 
> It appears that after having to recompile kmerlin to work with libqt2/libpng3
> that they (maintainers of those pacakages) have decided that I again
> have to recompile, but this time with libqt2/libpng2. :-(

Ivan decided that libpng3 was the way forward for libqt2 people, but
then Chris (rightly, IMHO) decided that libqt2 would keep libpng2, and
libqt3 would have libpng3.

> I'll upload something in the next couple of days. If you are really 
> desperate an `apt-get build-dep && apt-get source -b kmerlin` will
> build your own kmerlin package for you which is usable.

kdebase will be uploaded today and kdemultimedia tomorrow; the rest
should be OK.

-- 
Daniel Stone<[EMAIL PROTECTED]>
 hmm, someone remind me, what's the English term for startup lag?
 "netscape effect"


pgpQdq7kxre67.pgp
Description: PGP signature

Re: Processed: Fixed in NMU of tkstep8.0 8.0.4p2-4.1

[Daniel Stone]

On Tue, Jan 08, 2002 at 11:30:49PM +0100, Adrian Bunk wrote:
> On Thu, 3 Jan 2002, LaMont Jones wrote:
> 
> > > Additionally I see that you did other changes to unix/tkstepConfig.sh that
> > > aren't even mentioned in the changelog!
> >
> > Here is the complete diff between what I uploaded, and what was in the
> > archive.  Dunno what change you're seeing in tkstepConfig.sh, but it
> > was there in 4p2-4.
> 
> I see why I saw the changed file: The file is generated during the buld of
> the package. My mail was perhaps a bit too fast because I was (and I'm
> still a bit) very angry that you did NMU less than 24 hours after I got
> the bug report and without contacting me before - being angry is
> unfortunately not the best thing for thinking rationale about why
> something happened...

Let me note that this is *at least* the second time lamont did this. He
did a no-notice NMU to kdegraphics to fix a couple of small bugs,
without informing anyone. Can someone please beat him upside the head
with a copy of the Developer's Reference?

-- 
Daniel Stone<[EMAIL PROTECTED]>
 what does wu-ftpd do that proftpd doesn't (other than reveal new
security holes every couple of months)


pgpoWFPAPy48W.pgp
Description: PGP signature

Fw: Bug#128089: kdegraphics: Build failure: including non-PIC code in shared object (ia64/unstable)

[Daniel Stone]

Can someone please help me with this?

:) d

- Forwarded message from LaMont Jones <[EMAIL PROTECTED]> -

Subject: Bug#128089: kdegraphics: Build failure: including non-PIC code in 
shared object (ia64/unstable)
From: LaMont Jones <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Sun,  6 Jan 2002 23:42:43 -0700 (MST)

Package: kdegraphics
Version: 4:2.2.2-6
Severity: serious

Build fails on ia64.  Serious because this is keeping kdegraphics out of
woody.  Build log at:
http://buildd.debian.org/build.php?arch=ia64&pkg=kdegraphics

libgphoto.a has non-PIC code in it, and gets used in the link of
libkcm_kamera.so

-- System Information
Debian Release: 3.0
Kernel Version: Linux smallone 2.4.9-pa79 #2 Thu Nov 8 18:18:02 MST 2001 
parisc64 unknown



- End forwarded message -

-- 
Daniel Stone<[EMAIL PROTECTED]>
 hmm, someone remind me, what's the English term for startup lag?
 "netscape effect"


pgpWvm9iQlTeI.pgp
Description: PGP signature

Re: serious bug. Evolution and Microsoft mentality.

[Josselin Mouette]

le mer 09-01-2002 à 09:16, Jonathan Walther a écrit :

> Let's see.  Then there is the "bug" with GnuPG signatures not being
> verified correctly due to a Quoted Printable problem.  The answer to
> that one was "The problem is the fault of one of our libraries, and it
> isn't changing anytime soon, so this is not a bug".

*This* is the real problem with Evolution. It should use another GnuPG
system. Evolution's behavior with mboxes is the right thing to do, as
mboxes need to be locked.

FYI, Evo handles perfectly Maildir trees, including those with symlinks,
and can be used along with another MUA.

> "the code does things this way; ergo it's not a bug" just SCARES me.  I
> feel like GNOME is just going to return us to the land of Microsoft,

Calm down. Evolution is free software, that makes a huge difference with
Microsoft software.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'
  `-  Debian GNU/Linux -- The power of freedom


pgpO82zrsrU5F.pgp
Description: PGP signature

Bug#128396: general: /usr/lib/menu/doc-base-happydoc breaks update-menu

[Colin Watson]

reassign 128396 python-happydoc-doc
thanks

On Tue, Jan 08, 2002 at 11:44:25PM -0800, Rich Rudnick wrote:
> dpkg -S /usr/lib/menu/doc-base-happydoc does not return any package 
> owning this file, so I'm submitting this as general; please reassign
> as needed.

It's generated from /usr/share/doc-base/happydoc, owned by
python-happydoc-doc. The first paragraph of that file needs to include a
Section: line.

Regards,

-- 
Colin Watson  [EMAIL PROTECTED]

Processed: Re: Bug#128396: general: /usr/lib/menu/doc-base-happydoc breaks update-menu

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 128396 python-happydoc-doc
Bug#128396: general: /usr/lib/menu/doc-base-happydoc breaks update-menu
Bug reassigned from package `general' to `python-happydoc-doc'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Re: Bug#127252: kmerlin: Nope, it broke it

[Mark Purcell]

On Wed, Jan 09, 2002 at 07:38:31PM +1100, Daniel Stone wrote:
> On Wed, Jan 09, 2002 at 07:38:47AM +1100, Mark Purcell wrote:
> Ivan decided that libpng3 was the way forward for libqt2 people, but
> then Chris (rightly, IMHO) decided that libqt2 would keep libpng2, and
> libqt3 would have libpng3.

Understood.

> > I'll upload something in the next couple of days. If you are really 
> > desperate an `apt-get build-dep && apt-get source -b kmerlin` will
> > build your own kmerlin package for you which is usable.
> 
> kdebase will be uploaded today and kdemultimedia tomorrow; the rest
> should be OK.

I still need to upload a libpng2 version of kmerlin as I jumped the
gun and uploaded a libpng3, which no longer works after libqt2
jumped there.

Mark

Re: serious bug. Evolution and Microsoft mentality.

[Jonathan Walther]

On Wed, Jan 09, 2002 at 10:29:43AM +0100, Josselin Mouette wrote:
*This* is the real problem with Evolution. It should use another GnuPG
system. Evolution's behavior with mboxes is the right thing to do, as
mboxes need to be locked.
Could you explain that?  Using realpath() before locking the mbox would
prevent any possible bad interactions between symlinking and locking.
Its the Right Thing to do.  What Evolution currently does is NOT.
I object to attempts to lock me in to a single MUA.  While I'm
evaluating I expect to be able to continue using Mutt until I am
confident enough in Evolution to cut the umbilical cord.
FYI, Evo handles perfectly Maildir trees, including those with symlinks,
and can be used along with another MUA.
Yes, that is true.  It will be nice if in the future Evolution will
default to creating mailboxes in Maildir format, instead of mbox format.
Or at least make it an option to create new Folders in Maildir format
instead of assuming mbox.
"the code does things this way; ergo it's not a bug" just SCARES me.  I
feel like GNOME is just going to return us to the land of Microsoft,
Calm down. Evolution is free software, that makes a huge difference with
Microsoft software.
In the words of Eric Raymond:  "I dream of a world in which software does
not suck".  If free software isn't as much about software not sucking as
it is about source being open, is there much point?
I was trying to draw attention to the arrogant attitude that says "this
isn't a bug because I don't know how to fix it, or its hard to fix".  Or
worse, that ignores the tenets of the Unix Philosophy which made Unix so
powerful in the first place.  Even the bestest most uptodate modern GUI
program can adhere to the Unix philosophy without compromising its ease
of use in any way.  And by adhering to its tenets, it lets itself be
used with the rest of the Unix system in the most powerful way.
Jonathan
q.v. principle of of least surprise.


pgpwAOgmiuDHA.pgp
Description: PGP signature

Re: prism2 driver package anyone ?

[Eric Van Buggenhaut]

On Tue, Jan 08, 2002 at 11:41:59PM +0100, Rene Mayrhofer wrote:
> Hi Bastiaan,
> 

[...]

> > You can find everything you need here:
> > http://people.ssh.com/jkm/Prism2/
> > 
> > I have compiled the driver on my laptop and it seems to work fine (did
> > not actually test networking though, that would require swapping PC
> > intestins).
> If I understand the web page correctly, it is mainly a user-space
> software and a stand-alone kernel module that can be compiled when the
> kernel source is available, but does not need a patched kernel tree.
> Therefore it would be very easy if there was a Debian package for the
> user-space software and a package containing the module source code
> (ready for being automatically compiled with make-kpkg). 
> 

I use my laptop with a wireless prism2 pcmcia card. I indeed need 2
parts, the kernel module as you describe it (needs the kernel headers
to compile) and user-space tools.

Not sure what you're talking about but I think the user-space program
you're talking about is wireless-tools which has already entered
Debian.

Does this answer your question ?

-- 
Eric VAN BUGGENHAUT "Hay tampones y tampones..." (Eva Serrano)
Andago
\_|_/   Av. Santa Engracia, 54
   \/   \/  E-28010 Madrid - tfno:+34(91)2041100
a n d a g o  |--http://www.andago.com
   /\___/\  "Innovando en Internet"
/ | \   [EMAIL PROTECTED]

Re: Bug#127252: kmerlin: Nope, it broke it

[Daniel Stone]

On Wed, Jan 09, 2002 at 08:43:40PM +1100, Mark Purcell wrote:
> On Wed, Jan 09, 2002 at 07:38:31PM +1100, Daniel Stone wrote:
> > kdebase will be uploaded today and kdemultimedia tomorrow; the rest
> > should be OK.
> 
> I still need to upload a libpng2 version of kmerlin as I jumped the
> gun and uploaded a libpng3, which no longer works after libqt2
> jumped there.

Don't worry; the fact that half of KDE is broken shows that it wasn't
really planned.

-- 
Daniel Stone<[EMAIL PROTECTED]>
* asako launches into a great fable of love, desperation, honor, and
  coffee spilled on motherboards.


pgpr8oAG08Yoq.pgp
Description: PGP signature

Re: inactivity, and orphaned packages

[David D.W. Dowey]

I'm willing to take this package if you are willing to assign it to me.

I've got enough time free to take care of it.


- Original Message -
From: Leon Breedt <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, January 09, 2002 12:00 AM
Subject: inactivity, and orphaned packages


> Hi,
>
> I don't have the time available at the moment to make any meaningful
contributions
> to Debian, neither do I have access to any Debian Linux systems, so I've
orphaned
> the following packages:
>
> libucl
> libucl-dev
> libpam-pgsql
>
> I'm also the upstream author of libpam-pgsql, but I'm no longer developing
on
> that either, if anyone wants to hijack it, go ahead (the code is 'orrible
and
> has security problems in the SQL access, a rewrite is probably a better
option).
>
> Since I don't have access to any Debian Linux machines (RedHat/FreeBSD
only),
> I was not able to upload changed packages with the maintainer set to
> Debian-QA.
>
> Anyhow, I'm not leaving the project, just retreating to an even more
low-profile
> position.
>
> If there are any responses I need to know about, please CC me as I'm not
subscribed
> to -devel.
>
> Regards,
>
> Leon.
>
> --
> in theory, there is no difference between theory and practice.
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
>
>

Re: We still need sponsors!

[Tille, Andreas]

On Wed, 9 Jan 2002, Raphael Hertzog wrote:

> So, dear co-developers, please join debian-mentors@lists.debian.org and
> respond to future maintainers, and sponsor those who are asking it.
> Also check out the sponsor page that is listing about 30 future
> maintainers who are looking for a sponsor :
> http://www.internatif.org/bortzmeyer/debian/sponsor/
Thanks for your effort Raphael!

I'll take over sponsorship for the person who wants to take over
the package mozilla-locale-de-at which was orphaned by myself and perhaps
other packages.

Currently I have the problem that I can't find a detailed description,
how to sponsor.

At first please try a search at the Debian Web pages "Sponsor" which is
not very helpful :-(  but it should if your intention to find more
sponsors should be fitted.  After some more sophistcated search I found:

http://www.debian.org/devel/join/newmaint

  Sponsor:
   A sponsor is an existing Debian Developer (see Member) who acts as the
   mentor of an Applicant: he checks the package done by the applicant and
   helps him improving the packaging. When the sponsor is satisfied with
   the package, he uploads it on behalf of the applicant to the Debian
   archive. The package is called a sponsored package which means that the
   applicant is the official maintainer but that a member has uploaded it
   (since applicants are not allowed yet to upload packages themselves).
   You can find a sponsor by sending an email to
describing your package and asking
   for a sponsor.

OK.  If I understand this right that would mean that the control file
would state

  Maintainer: Future Maintainer <[EMAIL PROTECTED]>

and my own address will be in the changelog (like in an NMU).  Where
is the place to make clear that:
   "The package is called a sponsored package ..."
Are there any fields/conventions?

Kind regards

 Andreas.

PS: I wonder why your
 "Sponsorship of future Debian developers" - page
is not in the debian.org domain!

Re: serious bug. Evolution and Microsoft mentality.

[Mark Brown]

On Wed, Jan 09, 2002 at 01:47:02AM -0800, Jonathan Walther wrote:

> I object to attempts to lock me in to a single MUA.  While I'm
> evaluating I expect to be able to continue using Mutt until I am
> confident enough in Evolution to cut the umbilical cord.

Calm down.  It could just be a bug and screaming about attempts to lock
you into the software is probably not going to help convince people that
what you're saying is sensible.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


pgpNbzcMBdeJV.pgp
Description: PGP signature

Re: [wish] buildd.debian.org that shows success/failure

[Stefano Zacchiroli]

On Tue, Jan 08, 2002 at 09:03:50PM -0600, Adam Majer wrote:
> Different color.. something like keep it black for successful build but 
> mark it bold and red if it fails.. So at least bold would show up in lynx
> if someone is still using it.
> 
> No pictures, please...

Yes, sure.
I've just sent a few line patch to rmurray that output between brackets
the results of the last build log if it resulted in a status of
"failed", "given-back" or "skipped".

So the output is a table that may contains entry like:
  1.02   <<-- all works well
  1.02 (failed)
  1.02 (given-back)
  1.02 (skipped)

Currently I don't know if the patch works correctly because:
1) I can't test it on my home machine.
2) The "good luck" was really needed and I only hope to understand
rightly the behaviour of a class used by rmurray :)

Anyway I have no more time to spend on this but I hope the help will be
appreciated.

Cheers.

-- 
Stefano "Zack" Zacchiroli <[EMAIL PROTECTED]> ICQ# 33538863
Home Page: http://www.cs.unibo.it/~zacchiro
Undergraduate student of Computer Science @ University of Bologna, Italy
 - Information wants to be Open -


pgpgDLob9DsZc.pgp
Description: PGP signature

Re: inactivity, and orphaned packages

[Leon Breedt]

On Wed, Jan 09, 2002 at 02:16:19AM -0800, David D.W. Dowey wrote:
> I'm willing to take the libpam-pgsql if you are willing to assign it to me.
Go for it. If you want to take ownership of the code, I'd be very happy
as well :)

There is a security problem with the way it accesses the database, in that
single quotes are not escaped.

A discussion of the problem, and a suggested fix, is here:

http://cert.uni-stuttgart.de/advisories/apache_auth.php

I myself don't have the time to look into this...

Regards,
Leon.

Re: We still need sponsors!

[Michael Bramer]

On Wed, Jan 09, 2002 at 11:18:05AM +0100, Tille, Andreas wrote:
> OK.  If I understand this right that would mean that the control file
> would state
> 
>   Maintainer: Future Maintainer <[EMAIL PROTECTED]>
> 
> and my own address will be in the changelog (like in an NMU).  Where
> is the place to make clear that:
>"The package is called a sponsored package ..."
> Are there any fields/conventions?

I make a 
 ~/.forward-PACKAGENAME 
on master.d.o  and put [EMAIL PROTECTED] and the not-yet-maintainer
address in this file.

I use [EMAIL PROTECTED] in the controll file and all is ok...

Gruss
Grisu
-- 
Michael Bramer  -  a Debian Linux Developer  http://www.debsupport.de
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"Windows gehört zu den von sich aus unlogischen Systemen ohne Tradition."
  Anselm Lingnau in de.comp.os.unix.discussion


pgpO6U3TryErq.pgp
Description: PGP signature

Re: inactivity, and orphaned packages

[David D.W. Dowey]

This problem looks to be in the libpq itself, not the pam library module
itself.

I could probably extend the module to include the escape check itself.
Shouldn't hurt any queries adding that check before making submissions,
whether this patch has been added or not.

Simple check for formatting should do it.

Want to discuss this fix privately or on the list? Or do you just want me to
take the package and fix on my own?

Also, who would be sponsering my package once I took this over? Would you be
doing it or do I need to make a request for a different sponser?

Either is fine for me. All depends on _your_ time allowance.

> There is a security problem with the way it accesses the database, in that
> single quotes are not escaped.
>
> A discussion of the problem, and a suggested fix, is here:
>
> http://cert.uni-stuttgart.de/advisories/apache_auth.php
>
> I myself don't have the time to look into this...
>
> Regards,
> Leon.

Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]

[Philippe Troin]

Daniel Stone <[EMAIL PROTECTED]> writes:

> On Wed, Jan 09, 2002 at 10:07:13AM +0900, Junichi Uekawa wrote:
> > Daniel Stone <[EMAIL PROTECTED]> cum veritate scripsit:
> > 
> > > > It's only the -dev package, which is only required
> > > > for the compile time, and I believe it is quite small, only
> > > > with the symlinks and the static link files...
> > > > 
> > > > Or better, libqt2-dev depend on libpng2-dev.
> > > 
> > > They generally Build-Depend on libpng2-dev, I believe. 
> > 
> > If libqt-dev depends on libpng2-dev, and libpng2-dev
> > conflicts with libpng3-dev, whic is the case,
> > any package build-depending on libqt-dev AND libpng3-dev
> > will not build, which is probably the thing 
> > we want. Isn't it?
> 
> Right.

No it is not the case. Libpng-dev provides libpng2-dev (both are
source-compatible). Libqt-dev should depend on libpng2-dev
(<<1.2.0). That should work.

Phil.

Re: need help with an xpdf bug

[Hamish Moffatt]

On Tue, Jan 08, 2002 at 02:08:29PM +, Andrew Suffield wrote:
> OK, this is probably a bug in libfreetype6-dev.
> 
> The problem is that libfreetype6-dev puts headers in
> /usr/include/freetype2/freetype when they were intended to go in
> /usr/include/freetype. The headers use #include  to get
> each other. libttf-dev includes /usr/include/freetype/ stuff as well,
> but presumably at a different version, and gcc is finding the wrong
> one.

[...]

> Eliminating -I/usr/include from this fixes the problem at this
> level. I'm not sure how to modify the build system to handle this
> offhand, and neither am I sure that it is desireable.

Alternatively, Build-Conflicts: libttf-dev makes the problem go
away. That seems like the best solution (?).


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

Re: inactivity, and orphaned packages

[David D.W. Dowey]

Actually the more I look at this, the more I think it would be better to log
an entry about unescaped chars to the system log and deny the query. At
least until the patch
(http://cert.uni-stuttgart.de/doc/postgresql/escape/postgresql-escape-2001-0
9-04.diff) has been added to the pgsql mainstream package.

I can return an error message stating why the query was denied. This would
also force the developer to monitor their code as well.

Like the alert says, this would put the responsibility on the developer. The
PAM module should just check for a correctly formed string complete with
security check.

Any thoughts?

- Original Message -
From: David D.W. Dowey <[EMAIL PROTECTED]>
To: Leon Breedt <[EMAIL PROTECTED]>
Cc: 
Sent: Wednesday, January 09, 2002 3:14 AM
Subject: Re: inactivity, and orphaned packages


> This problem looks to be in the libpq itself, not the pam library module
> itself.
>
> I could probably extend the module to include the escape check itself.
> Shouldn't hurt any queries adding that check before making submissions,
> whether this patch has been added or not.
>
> Simple check for formatting should do it.
>
> Want to discuss this fix privately or on the list? Or do you just want me
to
> take the package and fix on my own?
>
> Also, who would be sponsering my package once I took this over? Would you
be
> doing it or do I need to make a request for a different sponser?
>
> Either is fine for me. All depends on _your_ time allowance.
>
> > There is a security problem with the way it accesses the database, in
that
> > single quotes are not escaped.
> >
> > A discussion of the problem, and a suggested fix, is here:
> >
> > http://cert.uni-stuttgart.de/advisories/apache_auth.php
> >
> > I myself don't have the time to look into this...
> >
> > Regards,
> > Leon.
>
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
>
>

Re: We still need sponsors!

[Adrian Bunk]

On Wed, 9 Jan 2002, Tille, Andreas wrote:

>...
> OK.  If I understand this right that would mean that the control file
> would state
>
>   Maintainer: Future Maintainer <[EMAIL PROTECTED]>

no, the control field states:
  Maintainer: My Name <[EMAIL PROTECTED]>

Where "My Name <[EMAIL PROTECTED]>" is a working email address of the maintainer
of the package. When he gets his account he can change the maintainer
field to his @debian.org address in the next upload - or he could leave
the other email address (if you look at my packages you'll find that I
never use my @debian.org address).

> and my own address will be in the changelog (like in an NMU).  Where
> is the place to make clear that:
>"The package is called a sponsored package ..."
> Are there any fields/conventions?

The way I prefer is:

The maintainer makes the package as if he was an official developer.
The sponsor rebuilds the package, checks it, and if it's OK he signs it
with his key (using "debsign -m") and uploads it.

Note that the name of the sponsor doesn't appear anywhere except in the
gpg signature of the .changes and the .dsc files and there's nothing that
makes the upload look like a NMU.

If you want to make it clear that the upload is sponsored an entry in the
changelog should be the right solution. Before I became a maintainer I
added to the changelog entry of every package that was sponsored for me a
line

  * Upload sponsored by Tony Mancill <[EMAIL PROTECTED]>.


> Kind regards
>
>  Andreas.
>...

cu
Adrian

Re: inactivity, and orphaned packages

[Leon Breedt]

On Wed, Jan 09, 2002 at 04:01:14AM -0800, David D.W. Dowey wrote:
> Actually the more I look at this, the more I think it would be better to log
> an entry about unescaped chars to the system log and deny the query. At
> least until the patch
> (http://cert.uni-stuttgart.de/doc/postgresql/escape/postgresql-escape-2001-0
> 9-04.diff) has been added to the pgsql mainstream package.
> 
> I can return an error message stating why the query was denied. This would
> also force the developer to monitor their code as well.
> 
> Like the alert says, this would put the responsibility on the developer. The
> PAM module should just check for a correctly formed string complete with
> security check.
> 
> Any thoughts?
I like it, define a set of allowed SQL characters (this must be
in an ANSI standard doc somewhere) and deny everything else, that way you're 
always
covered for any suspicious characters..

Regarding the sponsoring, I don't have access to a Debian machine at the
moment, and I don't want to put my private key on another machine, so it may
be a problem unless Debian works in FreeBSD's binary emulation mode :)

Lets take further discussion off the list?

Regards,
Leon.

Re: /dev/plex86 permissions

[Tommi Virtanen]

Russell Coker <[EMAIL PROTECTED]> writes:

> Currently /dev/plex86 defaults to mode 666 on devfs.  Is this really desired?
> 
> Perhaps we should have a plex86 group and make the device node default to 
> mode 660 and group plex86?

Note to people who are unfamiliar with devfs..

Access modes for files come from two locations:

1. The kernel, from the code that creates the entry

2. From devfsd


The kernel has no knowledge of groups, and does not want to
set any policy, so the only thing the kernel can do is make
the gid be 0.

That means /dev/plex86 has to default to u=rw,go= (just about
equal to ug=rw,o=), or to ugo=rw (which I understand is
unwanted). Then devfsd can chgrp it and set it to be g+rw.

What does the kernel code currently register as the default
mode?

-- 
[EMAIL PROTECTED],havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
double a,b=4,c;main(){for(;++a<2e6;c-=(b=-b)/a++);printf("%f\n",c);}

Re: Installed wajig 0.2.11-1 (i386 source)

[Dirk Eddelbuettel]

On Wed, Jan 09, 2002 at 03:06:52PM +0900, Junichi Uekawa wrote:
> On Tue, 08 Jan 2002 15:13:08 -0500
> Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:
> 
> > Description: 
> >  wajig  - Simplified Debian package management front end
> > Changes: 
> >  wajig (0.2.11-1) unstable; urgency=low
> >  .
> >* Upgraded to new upstream release
> > Files: 
> >  e2a0aaa255f1fd9404ccc176c82969c2 619 admin optional wajig_0.2.11-1.dsc
> >  33e519867e30638235b9611f5dc51d0c 37539 admin optional 
> > wajig_0.2.11.orig.tar.gz
> >  b96f5f99b6df7a748a2b53cb16cd67b5 2459 admin optional wajig_0.2.11-1.diff.gz
> 
> I just wondered: 
> What part of this python script makes it requisite to be 
> built for each architecture ?
> Why isn't it "all" instead of "any"?
> 
> Is byte-compiled python script platform-dependent?

It is my (naive) understanding that it is not. 

Is that not correct?  Or does an i386 .pyc/.pyo work on other architectures?

Dirk


-- 
Good judgment comes from experience; experience comes from bad judgment. 
-- F. Brooks

Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]

[Steve M. Robbins]

On Wed, Jan 09, 2002 at 03:21:34AM -0800, Philippe Troin wrote:
> Daniel Stone <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Jan 09, 2002 at 10:07:13AM +0900, Junichi Uekawa wrote:
> > > Daniel Stone <[EMAIL PROTECTED]> cum veritate scripsit:
> > > 
> > > > > It's only the -dev package, which is only required
> > > > > for the compile time, and I believe it is quite small, only
> > > > > with the symlinks and the static link files...
> > > > > 
> > > > > Or better, libqt2-dev depend on libpng2-dev.
> > > > 
> > > > They generally Build-Depend on libpng2-dev, I believe. 
> > > 
> > > If libqt-dev depends on libpng2-dev, and libpng2-dev
> > > conflicts with libpng3-dev, whic is the case,
> > > any package build-depending on libqt-dev AND libpng3-dev
> > > will not build, which is probably the thing 
> > > we want. Isn't it?
> > 
> > Right.
> 
> No it is not the case. Libpng-dev provides libpng2-dev (both are
> source-compatible). Libqt-dev should depend on libpng2-dev
> (<<1.2.0). That should work.

That would work.  But that would require changing all the
existing packages that build-depend on libpng2-dev.

It would be better (easier, less disruptive) if libpng-dev did not
provide libpng2-dev.  (c.f. Bug #128384)

Regards,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: serious bug. Evolution and Microsoft mentality.

[tpo2]

Zitiere Erik Steffl <[EMAIL PROTECTED]>:


[1935 lines uselessly quoted]
> 
> IMO the good solution for this kind of problems is to use IMAP.
> don't trust MUAs to work with files.

IMO IMAP is still a PITA, AFAIK the only well and out of the box interoperating
combination of MUA and IMAPd is pine together with uw-imapd which is about as
configurable as your sunglasses. With other Linux combinations you'll have to
go fiddling with Prefix&|View = INBOX. | INBOX* | INBOX.% | INBOX etc.

IMO nothing for newbies.

*Tomas Pospisek

Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]

[Adrian Bunk]

On Wed, 9 Jan 2002, Daniel Stone wrote:

> > > How do you plan to prevent programs that link with libqt2 to also link
> > > with libpng3 ? Manual check ?
> >
> > Another possiblility is the following (only the new dependencies are
> > listed):
> >
> > Package: libqt2-dev
> > Conflicts: libpng3
> > Build-Conflicts: libpng3
> >
> > [note that libpng3 is the library package _not_ the -dev package]
> >
> >
> > This way neither a program that links with libqt2 nor a library libqt2 is
> > linked with can be linked with libpng3.
>
> What? That means that you can't have a libpng3 program on a machine with
> libqt2-dev installed ... icky.

Yes, but that's the only way I see to ensure that there aren't some ugly
problems like e.g.

Package: abc
Depends: libqt2, libxyz

Package: libqt2
Depends: libpng2

Package: libxyz
Depends: libpng3

> -d

cu
Adrian

Re: serious bug. Evolution and Microsoft mentality.

[Mark Brown]

On Wed, Jan 09, 2002 at 02:36:01PM +0100, [EMAIL PROTECTED] wrote:

> IMO IMAP is still a PITA, AFAIK the only well and out of the box
> interoperating combination of MUA and IMAPd is pine together with
> uw-imapd which is about as configurable as your sunglasses. With other
> Linux combinations you'll have to go fiddling with Prefix&|View =
> INBOX. | INBOX* | INBOX.% | INBOX etc.

Most things (certainly mutt and kmail, I can't think of anything else I
tried that gave me problems) interoperate quite happily with both UW
IMAP and Courier IMAP.  I can't think off-hand of a client that wouldn't
play with UW IMAP.

MUAs that don't interoperate happily with both could probably be
considered buggy - the main problem is likely to be namespacing and
there's standard ways for the server to inform the client about the
namespaces it uses.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


pgp6KJXB1Bew6.pgp
Description: PGP signature

Re: serious bug. Evolution and Microsoft mentality.

[Bernd Eckenfels]

On Wed, Jan 09, 2002 at 02:36:01PM +0100, [EMAIL PROTECTED] wrote:
> IMO IMAP is still a PITA, AFAIK the only well and out of the box 
> interoperating
> combination of MUA and IMAPd is pine together with uw-imapd

Mozilla at least works now with exchange :)

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: Do not link GNOME apps with libpng3

[Christian Marillat]

reassign 128377 gdk-imlib1
thanks

>> "SMR" == Steve M Robbins <[EMAIL PROTECTED]> writes:

> reassign 128377 gnome-help
> thanks

> Hi Folks,

> GNOME's imlib1 library is linked with libpng2, and nobody
> knows how to gracefully handle the change from libpng2-->libpng3

>   http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg00015.html
>   http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg00243.html

> So for the moment, I'm NOT planning to change imlib's linkage.  Therefore,
> all GNOME apps that build with both imlib1 and libpng, should build-depend
> on libpng2-dev NOT libpng-dev.

> In particular, gnome-core should revert this change:

> gnome-core (1.4.0.4-15) unstable; urgency=low

>   * debian/control Replace libpng2-dev by libpng-dev in Build-Depends.


> Now, the question is: should GNOME move to libpng3, and how?  The QT/KDE
> folks have sidestepped the problem by declaring that libqt2 is
> remaining linked against libpng2, while libqt3 links with libpng3.  I
> don't see why we shouldn't adopt the same approach: leave imlib1
> linked with libpng2 and let imlib's successor libraries link against
> libpng3.  Comments?

I disagree completely. We should *always* compile all packages against
the latest library version and not downgrade the builg dependency to an
old library. We have did the same change to move to libdb3.

I really want to know why recompiling gdk-imlib1 is too hard ?

Christian

Re: Do not link GNOME apps with libpng3

[Christian Marillat]

>> "SMR" == Steve M Robbins <[EMAIL PROTECTED]> writes:

> On Wed, Jan 09, 2002 at 03:09:08PM +0100, Christian Marillat wrote:

[...]

>> I really want to know why recompiling gdk-imlib1 is too hard ?

> Recompiling isn't hard.  Managing the transition is hard.  Did you
> read the threads in debian-devel and debian-kde?  Do you have a solution
> to managing the transition?

Yes I've read the thread in -devel. For Gnome we only need to recompile
your package and dgk-pixbuf.

BTW for now gnome-libs, gnome-core, are compiled against libpng3-dev,
and nothing is broken execpt the warning message in gnome-help.

Christian

Bug#128427: ITP: txt2regex -- An txt2regex wizard

[Martin Butterweck]

Package: wnpp
Version: N/A; reported 2002-01-09
Severity: wishlist

* Package name: txt2regex
  Version : 0.6
  Upstream Author : [EMAIL PROTECTED]
* URL : http://txt2regex.sourceforge.net/
* License : GPL
  Description : An txt2regex wizard

^txt2regex$ is a Regular Expression "wizard", all written with bash2
builtins, that converts human sentences to RegExs. with a simple
interface, you just answer to questions and build your own RegEx for a
large variety of programs, like awk, emacs, grep, perl, php, procmail,
python, sed and vim. there are more than 20 supported programs.


-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux martin 2.4.16 #1 Tue Nov 27 13:06:54 CET 2001 i686
Locale: LANG=C, [EMAIL PROTECTED]

Re: linux.conf.au and Debian conference

[Tille, Andreas]

On Wed, 9 Jan 2002, James Bromberger wrote:
[at debian-private - but of course it can be also discussed open and so
 I move here ...]

> On Wed, Jan 09, 2002 at 10:35:47AM +0100, Tille, Andreas wrote:
> > there were some rumors that there would be the Debian Conference 2
> > connected to
> >
> >  http://www.linux.org.au/conf
> >
> > I did not found any hint on the pages and parsing for Debian only
> > brought up only:
> >
> >   Bdale Garbee
> > Bdale sacrificed many of the letters from his first name to join
> us
> > at the conference. He'll be talking about porting Debian GNU/Linux
> > to PA/RISC and ia64.
>
>
> Hey Andreas,
>
> Its very very small. We have a few speakers: the details of which
> Anthony
> is about to put up on the web site. I have the following people talking:
>   Jason Andrade - Australian Debian mirror maintainer
>   Bdale Garbee - porting Debian
>   Russel Coker - portslave
>   Anthony Towns - Woody
>   Brendan O'Dea - Perl and apt with perl
>
>
> I'll take anyone else who wants to talk as well. Its two days before the
> LCA (Linux.conf.au) conference (Mon 4, Tue 5 Feb). For the time we don't
> have speakers, we'll be down the pub or working on stuff. I arrive in
> Brisbane on the Saturday around lunchtime. I'm staying at Emmanuel
> College at the University in a flat.
I have thought about speaking about my plans for Debian-Med.  The problem
is that there seem to be no medical related topics at LCA
and so I'm not able to find a sponsor for the trip down under :-(.

> I'm going to start pushing the publicity barrel around when the web
> site is updated any moment now.
That's fine.

> This is never suppose dto be Debian Conference 2. This is merely a
> random collection of people from the region; I am thus calling it
> a "mini-conference"; there is no set organisation apart from a place,
> date, and a list of people to talk.
Understood.  Perhaps some trouble with my mind ...

> Anyone who is in the region; come on down and share a beer:
>   www.linux.conf.au/debaincon.html
I'm afraid we have to share a virtual beer.  Is there any apt-get able
beer ;-) ?

>   James
> [PS: my comments may be repubished outside of -private; Andreas' are
> his property and I can't speak for him/his]

Kind regards

 Andreas.

Re: Do not link GNOME apps with libpng3

[Colin Watson]

On Wed, Jan 09, 2002 at 03:09:08PM +0100, Christian Marillat wrote:
> reassign 128377 gdk-imlib1
> thanks
> 
> > Now, the question is: should GNOME move to libpng3, and how?  The QT/KDE
> > folks have sidestepped the problem by declaring that libqt2 is
> > remaining linked against libpng2, while libqt3 links with libpng3.  I
> > don't see why we shouldn't adopt the same approach: leave imlib1
> > linked with libpng2 and let imlib's successor libraries link against
> > libpng3.  Comments?
> 
> I disagree completely. We should *always* compile all packages against
> the latest library version and not downgrade the builg dependency to an
> old library. We have did the same change to move to libdb3.
> 
> I really want to know why recompiling gdk-imlib1 is too hard ?

It would change imlib's interface in an incompatible way, and therefore
require imlib's soname to be changed.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: We still need sponsors!

[Francesco P. Lovergine]

On Wed, Jan 09, 2002 at 01:00:28PM +0100, Adrian Bunk wrote:
> On Wed, 9 Jan 2002, Tille, Andreas wrote:
> 
> >...
> > OK.  If I understand this right that would mean that the control file
> > would state
> >
> >   Maintainer: Future Maintainer <[EMAIL PROTECTED]>
> 
> no, the control field states:
>   Maintainer: My Name <[EMAIL PROTECTED]>
> 
> Where "My Name <[EMAIL PROTECTED]>" is a working email address of the 
> maintainer
> of the package. When he gets his account he can change the maintainer
> field to his @debian.org address in the next upload - or he could leave
> the other email address (if you look at my packages you'll find that I
> never use my @debian.org address).
> 
> > and my own address will be in the changelog (like in an NMU).  Where
> > is the place to make clear that:
> >"The package is called a sponsored package ..."
> > Are there any fields/conventions?
> 
> The way I prefer is:
> 
> The maintainer makes the package as if he was an official developer.
> The sponsor rebuilds the package, checks it, and if it's OK he signs it
> with his key (using "debsign -m") and uploads it.
> 
> Note that the name of the sponsor doesn't appear anywhere except in the
> gpg signature of the .changes and the .dsc files and there's nothing that
> makes the upload look like a NMU.
> 
> If you want to make it clear that the upload is sponsored an entry in the
> changelog should be the right solution. Before I became a maintainer I
> added to the changelog entry of every package that was sponsored for me a
> line
> 
>   * Upload sponsored by Tony Mancill <[EMAIL PROTECTED]>.
> 
> 

Sounds good. Maybe we should provide a description of this technique 
somewhere within webml or ddp.

WWW/doc folks: any hint about sponsorship uploading practices?

-- 
Francesco P. Lovergine

Re: Do not link GNOME apps with libpng3

[Steve M. Robbins]

On Wed, Jan 09, 2002 at 03:23:25PM +0100, Christian Marillat wrote:
> >> "SMR" == Steve M Robbins <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Jan 09, 2002 at 03:09:08PM +0100, Christian Marillat wrote:
> 
> [...]
> 
> >> I really want to know why recompiling gdk-imlib1 is too hard ?
> 
> > Recompiling isn't hard.  Managing the transition is hard.  Did you
> > read the threads in debian-devel and debian-kde?  Do you have a solution
> > to managing the transition?
> 
> Yes I've read the thread in -devel. For Gnome we only need to recompile
> your package and dgk-pixbuf.

You think only two packages need recompiling?  I can only conclude
that, while you may have read the thread, you did not understand it.
The best summary (in my humble opinion) is

http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg00243.html

The main conclusion is this: if imlib1 (and gdk-imlib1) change their linkage
from libpng2 to libpng3, then ANY APPLICATION THAT LINKS WITH ONE OF THOSE
AND ALSO WITH LIBPNG NEEDS TO BE RECOMPILED.  That's a whole lot more than
two packages.

I have tried it --- I rebuilt imlib1 against libpng3, and everything
I care about breaks, starting from the splash screen, to sawfish, to the
"Mail Check"  applet.

But you needn't take my word for it: try it for yourself.  You can
find the changed imlib sources and i386 debs in my home directory
on auric.


> BTW for now gnome-libs, gnome-core, are compiled against libpng3-dev,
> and nothing is broken execpt the warning message in gnome-help.

I guess you got lucky.  Perhaps only gnome-help links against both
imlib and libpng.


The fact remains that we cannot change the linkage of the library
NOR of applications piecemeal.  The changes must be coordinated.
In the absence of a transition plan, I see no reason to introduce 
instability in GNOME by changing imlib.  If you have a workable
plan, I'm all ears.

-Steve

P.S.  Just for the record: what specifically are the benefits to
recompiling everything with libpng3?

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: We still need sponsors!

[Tille, Andreas]

On Wed, 9 Jan 2002, Francesco P. Lovergine wrote:

> Sounds good. Maybe we should provide a description of this technique
> somewhere within webml or ddp.
>
> WWW/doc folks: any hint about sponsorship uploading practices?
At least an FAQ would be apropriate in my opinion.
A better solution would be a paragraph in the developers reference.

Kind regards

Andreas.

Re: Do not link GNOME apps with libpng3

[Christian Marillat]

>> "SMR" == Steve M Robbins <[EMAIL PROTECTED]> writes:

[...]

> The fact remains that we cannot change the linkage of the library
> NOR of applications piecemeal.  The changes must be coordinated.
> In the absence of a transition plan, I see no reason to introduce 
> instability in GNOME by changing imlib.  If you have a workable
> plan, I'm all ears.

See Colin's answer. Change the library soname and shlibs. This will
solve this bug.

Christian

Re: Do not link GNOME apps with libpng3

[Gustavo Noronha Silva]

On 09 Jan 2002 15:09:08 +0100
Christian Marillat <[EMAIL PROTECTED]> wrote:

> > Now, the question is: should GNOME move to libpng3, and how?  The QT/KDE
> > folks have sidestepped the problem by declaring that libqt2 is
> > remaining linked against libpng2, while libqt3 links with libpng3.  I
> > don't see why we shouldn't adopt the same approach: leave imlib1
> > linked with libpng2 and let imlib's successor libraries link against
> > libpng3.  Comments?
> 
> I disagree completely. We should *always* compile all packages against
> the latest library version and not downgrade the builg dependency to an
> old library. We have did the same change to move to libdb3.
> 
> I really want to know why recompiling gdk-imlib1 is too hard ?
I can see your point, but the change from db2 to db3 happened months
ago, and I really think libpng3 should be investigated before
we move all gnome apps to use it... we must take care, because the
freeze is going and this can delay it more and more or remove
some gnome programs from woody

[]s!

-- 
Gustavo Noronha Silva - kov 
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+
|  .''`.  | Debian GNU/Linux:  |
| : :'  : + Debian BR...: +
| `. `'`  + Q: "Why did the chicken cross the road?"  +
|   `-| A: "Upstream's decision." -- hmh  |
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+

Re: We still need sponsors!

[Gustavo Noronha Silva]

On Wed, 9 Jan 2002 13:00:28 +0100 (CET)
Adrian Bunk <[EMAIL PROTECTED]> wrote:

> The way I prefer is:
> 
> The maintainer makes the package as if he was an official developer.
> The sponsor rebuilds the package, checks it, and if it's OK he signs it
> with his key (using "debsign -m") and uploads it.
> 
> Note that the name of the sponsor doesn't appear anywhere except in the
> gpg signature of the .changes and the .dsc files and there's nothing that
> makes the upload look like a NMU.
I agree with this way and that's  how I do it myself...

dpkg-buildpackage -rfakeroot -kyou_keyID

will do the job for you... IMO sponsoring is not NMU and it should not
be marked as such

[]s!

-- 
Gustavo Noronha Silva - kov 
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+
|  .''`.  | Debian GNU/Linux:  |
| : :'  : + Debian BR...: +
| `. `'`  + Q: "Why did the chicken cross the road?"  +
|   `-| A: "Upstream's decision." -- hmh  |
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+

Re: Do not link GNOME apps with libpng3

[Steve M. Robbins]

On Wed, Jan 09, 2002 at 04:37:17PM +0100, Christian Marillat wrote:
> >> "SMR" == Steve M Robbins <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> > The fact remains that we cannot change the linkage of the library
> > NOR of applications piecemeal.  The changes must be coordinated.
> > In the absence of a transition plan, I see no reason to introduce 
> > instability in GNOME by changing imlib.  If you have a workable
> > plan, I'm all ears.
> 
> See Colin's answer. Change the library soname and shlibs. This will
> solve this bug.

It's a reasonable transition plan.

However, introducing a new imlib library with a new SONAME will not
solve Bug #128377, as gnome-help-browser binary is linked with
libgdk_imlib's current SONAME.

If you favour doing the libpng2 -> libpng3 transition by introducing
new imlib packages (and SONAMES), then all packages that link with the
current imlib package need to link with libpng2.

Cheers,
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: need help with an xpdf bug

[Andrew Suffield]

On Wed, Jan 09, 2002 at 10:46:40PM +1100, Hamish Moffatt wrote:
> On Tue, Jan 08, 2002 at 02:08:29PM +, Andrew Suffield wrote:
> > OK, this is probably a bug in libfreetype6-dev.
> > 
> > The problem is that libfreetype6-dev puts headers in
> > /usr/include/freetype2/freetype when they were intended to go in
> > /usr/include/freetype. The headers use #include  to get
> > each other. libttf-dev includes /usr/include/freetype/ stuff as well,
> > but presumably at a different version, and gcc is finding the wrong
> > one.
> 
> [...]
> 
> > Eliminating -I/usr/include from this fixes the problem at this
> > level. I'm not sure how to modify the build system to handle this
> > offhand, and neither am I sure that it is desireable.
> 
> Alternatively, Build-Conflicts: libttf-dev makes the problem go
> away. That seems like the best solution (?).

It's still a bug in libfreetype6-dev. That should either fix the
headers or conflict with libttf-dev. The best solution would be one of
those two ;)

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


pgpezgri76oMZ.pgp
Description: PGP signature

Re: Do not link GNOME apps with libpng3

[Christian Marillat]

>> "SMR" == Steve M Robbins <[EMAIL PROTECTED]> writes:

> On Wed, Jan 09, 2002 at 04:37:17PM +0100, Christian Marillat wrote:

[...]

>> See Colin's answer. Change the library soname and shlibs. This will
>> solve this bug.

> It's a reasonable transition plan.

> However, introducing a new imlib library with a new SONAME will not
> solve Bug #128377, as gnome-help-browser binary is linked with
> libgdk_imlib's current SONAME.

This bug isn't important (I downgraded the severity to
normal). gnome-help display the libpng error messagess, but he can
display png image.

> If you favour doing the libpng2 -> libpng3 transition by introducing
> new imlib packages (and SONAMES), then all packages that link with the
> current imlib package need to link with libpng2.

Then i'll rebuild gnome-help and my other packages who depends on imlib
against the new imlib. This will take 2 hours, and the problem is gone.

Christian

Re: inactivity, and orphaned packages

[Martin Michlmayr]

* David D.W. Dowey <[EMAIL PROTECTED]> [20020109 02:17]:
> I'm willing to take this package if you are willing to assign it to me.

Please retitle the appropriate bug then (#128400 in the case of
libpam-pgsql).

Bug#128400: O: libpam-pgsql
Bug#128399: O: ucl (libucl and libucl-dev)

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]

[Junichi Uekawa]

Philippe Troin <[EMAIL PROTECTED]> cum veritate scripsit:

> No it is not the case. Libpng-dev provides libpng2-dev (both are
> source-compatible). Libqt-dev should depend on libpng2-dev
> (<<1.2.0). That should work.


That sounds wrong.

libpng3 is not binary compatible with libpng2.
Silently being able to replace libpng2 with libpng3 
is very very disruptive.

regards,
junichi

-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4

Re: serious bug. Evolution and Microsoft mentality.

[Federico Di Gregorio]

Il mer, 2002-01-09 alle 09:16, Jonathan Walther ha scritto:

> Let's see.  Then there is the "bug" with GnuPG signatures not being
> verified correctly due to a Quoted Printable problem.  The answer to
> that one was "The problem is the fault of one of our libraries, and it
> isn't changing anytime soon, so this is not a bug".
> 
> See a trend?  That attitude scares me.  Saying "this would involve a

it's called ximianite, from the company were it started. after it gets
you, you'll suddenly start to answer to bug reports with phrases like
"it is not a bug", "it is not our fault", "it is XXX library", "but we
wrote 100.000 lines of GPL code." :)

evolusion is a great program, really. but assumes way too much about the
QI of the user.

> A user who doesn't know what he is doing will attempt to do everything
> from the provided GUI.  Its shameful to assume that people that attempt
> to use vi to edit their configurations are also idiots.

perfectly worded.

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
INIT.D Developer   [EMAIL PROTECTED]
  All programmers are optimists. -- Frederick P. Brooks, Jr.


pgpV1Y0138CUC.pgp
Description: PGP signature

Re: Fw: Bug#128089: kdegraphics: Build failure: including non-PIC code in shared object (ia64/unstable)

[Steve Langasek]

On Wed, Jan 09, 2002 at 08:20:00PM +1100, Daniel Stone wrote:
> Can someone please help me with this?

Have you identified why libkcm_karea.so is linking against libgphoto2.a 
instead of against libgphoto2.so?  Is libgphoto2.so absent or 
inaccessible, or is something in the Makefile forcing the selection of
the static lib?

I notice that libtool is manually passing as arguments to the compiler 
all of the files that gcc/g++ is supposed to take care of automagically 
(crtn, crti, etc).  Does libtool always do this, or is this a strange 
version of libtool?

Steve Langasek
postmodern programmer

> - Forwarded message from LaMont Jones <[EMAIL PROTECTED]> -
> 
> Subject: Bug#128089: kdegraphics: Build failure: including non-PIC code in 
> shared object (ia64/unstable)
> From: LaMont Jones <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Date: Sun,  6 Jan 2002 23:42:43 -0700 (MST)
> 
> Package: kdegraphics
> Version: 4:2.2.2-6
> Severity: serious
> 
> Build fails on ia64.  Serious because this is keeping kdegraphics out of
> woody.  Build log at:
> http://buildd.debian.org/build.php?arch=ia64&pkg=kdegraphics
> 
> libgphoto.a has non-PIC code in it, and gets used in the link of
> libkcm_kamera.so
> 
> -- System Information
> Debian Release: 3.0
> Kernel Version: Linux smallone 2.4.9-pa79 #2 Thu Nov 8 18:18:02 MST 2001 
> parisc64 unknown
> 
> 
> 
> - End forwarded message -
> 
> -- 
> Daniel Stone  <[EMAIL PROTECTED]>
>  hmm, someone remind me, what's the English term for startup lag?
>  "netscape effect"




pgpARzJnGXvG2.pgp
Description: PGP signature

Re: Fw: Bug#128089: kdegraphics: Build failure: including non-PIC code in shared object (ia64/unstable)

[James Troup]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Wed, Jan 09, 2002 at 08:20:00PM +1100, Daniel Stone wrote:
> > Can someone please help me with this?
> 
> Have you identified why libkcm_karea.so is linking against libgphoto2.a 
> instead of against libgphoto2.so?

It's a broken symlink; I seem to recall having this conversation with
Daniel at least once already...

-- 
James

Re: Installed wajig 0.2.11-1 (i386 source)

[Junichi Uekawa]

Dirk Eddelbuettel <[EMAIL PROTECTED]> cum veritate scripsit:

> > Is byte-compiled python script platform-dependent?
> 
> It is my (naive) understanding that it is not. 
> 
> Is that not correct?  Or does an i386 .pyc/.pyo work on other architectures?

I am not quite sure.

I also wondered if it was customary to have byte-compiled
python scripts.

regards,
junichi

-- 
[EMAIL PROTECTED] : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4

RE: ITP: libtar - c library for manipulating tar archives

[Yves Arrouye]

> > Age indicates how many revisions of the library have been upwards
> > compatible. If you are at revision 7 and still have all the interfaces
> from> revision 6 unchanged, and 6 had the same for 5, and ... 4 for 3,
> then age is> 7 - 3 = 4.
> >
> 
> I see what your saying, but dont you mean current instead of revision ?
> 
> So age should always be >= 0 and <= current.

Yes, age cannot be higher than current since since the best case is that all
interfaces from the first revision on are still implemented. It should even
be age < current since numbering starts at 1, I think.

I do not know of a way to put this age information in a Linux shared lib? Or
is there? It is possible for example on Mach (or at least on Mach-derived
systems like NeXTStep/OPENSTEP/Mac OS X).

YA

 

Gopher Turns 10; Gopher 3.0 (FurryTerror) Released

[John Goerzen]

Thought some of you might be interested in this.  And yes, packages
have been uploaded to sid.  For those of you that did not know, UMN
GPL'd gopher about a year ago and several of us have been working on
the codebase since then.

 Gopher Turns 10 / Gopher 3.0 (Furry Terror) Released

   January 8, 2002

   The  Internet  Gopher Server and Curses Client is 10 years old!* Since
   its  [1]announcement  in late 1991, Gopher quickly sprang up to be one
   of  the  most  innovative technologies of its time. Gopher today still
   provides  features  not  found on Web servers -- namely, its idea that
   the  entire planet is just one big filesystem. Modern browsers such as
   Konqueror  and Mozilla show it to us that way, even with drag-and-drop
   integration with the desktop.

   Today we release the Internet Gopher Server and Client version 3.0.

   After  having  been  totally  unmodified  for five years, the Internet
   Gopher has kicked back to life. The University of Minnesota placed the
   code  under  the GNU General Public License and an interested group of
   hackers set to work on it. A year later, we have this release.

 About Gopher

   To   learn   about   Gopher,   please   visit   The   Gopher   Project
   [[2]gopher/[3]web],ABriefIntroductiontoGopherspace
   [[4]gopher/[5]web], or The Gopher Manifesto [[6]gopher/[7]web].

 Obtaining Gopher/Gopherd 3.0

   Debian sid users may run "apt-get install gopher gopherd" beginning on
   approximately January 11.

   The source distribution may be downloaded from:
 * [8]gopher://gopher.quux.org/1/devel/gopher
 * [9]Quux.Org's Web-To-Gopher Interface to the Above
 * [10]http://www.quux.org/give-me-gopher/  for  people  that  want a
   more conventional HTTP presentation.

 Release Notes

 * You are encouraged to use ./configure --disable-auth to build.
 * BSD users should use "gmake" to build.

Changes since UMN Gopher release 2.3.1

   In Brief:
 * Many security and buffer overrun fixes
 * New security features in gopherd
 * Improved handling of MIME types
 * Modified  to work on modern operating systems. Verified to work in
   Linux for multiple platforms and NetBSD/i386. Should also work for
   HURD.
 * Many other modifications, see below.

   A  more  detailed listing is below -- but it is still abbreviated. The
   most current is available from CVS.
gopher (3.0.0-1) unstable; urgency=low

  * Patched to work with Hurd.  Closes: #115511.  Uses
suggestions from James Morrison
but not his patch.
* gopher.c, gopherd/error.c, gopher/download.c:
  Modified to use HAVE_STRERROR
* configure.in: Modified with checks for sys/param.h, HURD header files,
  get_current_dir_name, etc.
* configure.h.in, configure: rebuilt.
  * Moved the current UMN Copyright notice in "COPYING" into "copyright"
  * Updated copyright files, etc. with current info.
  * Updated the locales with semi-current copyright stuff.
  * Updated greeting in gopher and gopherd.
  * This is Gopher 3.0.0, the Furry Terror release.

 -- John Goerzen   Tue,  8 Jan 2002 15:31:00 -0500

gopher (2.3.1-15) unstable; urgency=low

  * NetBSD port effort began.
  * Added crypt.h to configure.in's list of headers to look for.
Reran autoconf/autoheader.
  * Modified gopherd/AUTH.h to include crypt.h only if it's available
and to include unistd.h if it's available.  (NetBSD)
  * Integrated patches from David Allen
(may have been done earlier anyway)
  * config.h.in: rebuilt by autoheader
  * configure: rebuilt by autoconf
  * configure.in:
* Added REGEXLIBS test for NetBSD -- look for re_comp in -lcompat
* Added checkes for term.h, re_comp.h, regex.h
  * gopher/ourutils.c, gopher/CURcurses.c: Use term.h check
  * gopher/Makefile.in, gopherd/Makefile.in, gophfilt/Makefile.in:
* Use REGEXLIBS
  * gopher/globals.h, gopher/gopher.c: Remove sys_errlist
  * object/GSgopherobj.c: Removed  #include, now use
"Regex.h" that has proper regex determining logic
  * object/Regex.h: Moved regex.h include to here.  Make it conditional
based on configure test.  Add conditional re_comp.h include.
  * gopherd/gopherd.c: Add init of view and filter after setjmp
to eliminate clobbering due to longjmp and a warning.  Cast
parameters to *printf to long as appropriate.
  * AUTH.h: Add missing AUTHITEMSprocessLine prototype
  * AUTH.h: Add a check to prevent including twice.
  * gopherdconf.c: Add a missing prototype.
  * AUTH.c: add missing include of GGroup.h
  * download.c: Added cast to long for some *printf's
  * Now compiles with only one warning on NetBSD.
  * This is Gopher 20020108-01.cvs
  * object/Regex.h: now conditionally includes sys/types.h for regex.h
  * This is Gopher 20020108-02.cvs

 -- John Goerzen   Tue,  8 Jan 2002 13:11:00 -0500

gopher (2.3.1-14) unstabl

Re: inactivity, and orphaned packages

[Joerg Wendland]

Hi,

Leon Breedt, on 2002-01-09, 12:42, you wrote:
> On Wed, Jan 09, 2002 at 02:16:19AM -0800, David D.W. Dowey wrote:
> > I'm willing to take the libpam-pgsql if you are willing to assign it to me.
> Go for it. If you want to take ownership of the code, I'd be very happy
> as well :)

I am the author of another pam-pgsql module. It was written to go along
with my libnss-pgsql which is already in Debian. You may want to have a
look at it. It is IMHO more stable than the one already packaged and I
will work on it in the next few weeks. Find it at

   http:// sf.net/projects/sysauth-pgsql
 
> There is a security problem with the way it accesses the database, in that
> single quotes are not escaped.

Note that my module has the problem fixed. I would also be willing
to maintain Debian packages if no one else wants to.

Regards, Joerg

-- 
Joerg "joergland" Wendland
GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A  F318 57A3 7FBD 51CF 8417


pgpiz8MJQICLT.pgp
Description: PGP signature

Bug#128446: ITP: elpoint -- Yet another presentation tool on Emacsen

[OHASHI Akira]

Package: wnpp
Version: N/A; reported 2002-01-10
Severity: wishlist

Hi, 

I intend to package elpoint.

* Package name: elpoint
  Version : 0.1.0
  Upstream Author : Yuuichi Teranishi <[EMAIL PROTECTED]>
* URL : http://www.gohome.org/elpoint/
* License : GPL
  Description : Yet another presentation tool on Emacsen

Elpoint is a presentation tool which runs on Emacs.

Features

 * Easy to create and display a presentation.
 * Dynamic presentation content can be developed using emacs lisp.
 * A major mode `ept-mode' is included which supports editing
   elpoint presentation.
 * Inline images. Images can be retrieved from Internet.

Regards,

-- 
OHASHI Akira
[EMAIL PROTECTED] [EMAIL PROTECTED]
Share what you know. Learn what you don't.

Re: IBM "Key alliances" ?

[Eric Van Buggenhaut]

On Tue, Jan 08, 2002 at 09:20:29AM -0800, Karl M. Hegbloom wrote:
>  http://www-1.ibm.com/linux/>
> 
>  On the right is a panel listing "Key Alliances".  Why are we not
>  listed?  It would be a good thing for Debian to ally with IBM,
>  wouldn't it?  If I had a job as a system admin at an IBM shop, I'd
>  much prefer to use Debian than RH.
> 

Helas, AFAIK, when IBM sells Linux, it sells RH.

There's more, if you replace the RH system they pre-install, you're
losing the warranty on the hardware.

-- 
Eric VAN BUGGENHAUT "Hay tampones y tampones..." (Eva Serrano)
Andago
\_|_/   Av. Santa Engracia, 54
   \/   \/  E-28010 Madrid - tfno:+34(91)2041100
a n d a g o  |--http://www.andago.com
   /\___/\  "Innovando en Internet"
/ | \   [EMAIL PROTECTED]

Re: IBM "Key alliances" ?

[Otavio Real Salvador]

 > Helas, AFAIK, when IBM sells Linux, it sells RH.
Why don't change this?

 > There's more, if you replace the RH system they pre-install, you're
 > losing the warranty on the hardware.
When change the first, this will change too.

-- 
  O T A V I OR E A LS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

 

Should I rename scalable-cyrfonts?

[Anton Zinoviev]

Hi!

I'am the maintainer of the package scalable-cyrfonts.  It's purpose was
to contain all free scalable Cyrillic fonts I know about.  However
recently the upstream of most of these fonts has added many non-Cyrillic
letters to them.  Now they cover also ISO 8859-1,2,15 and will be some
of the best scalable Unicode fonts in Debian.

That's why I have a question: Should I rename this package?  It is
a three-binary package:

scalable-cyrfonts -- only fonts, but the next version will support Defoma
scalable-cyrfonts-x11 -- installs the fonts in X
scalable-cyrfonts-tex -- installs them for use in TeX

How to rename these packages?  May be

scalable-cyrfonts ->  scalable-fonts
scalable-cyrfonts-x11 ->  scalable-fonts-x11
scalable-cyrfonts-tex --  no name renaming

The last package is not renamed because TeX can't use more than 256
symbols per font.

I suppose that Provides and Replaces should be sufficient to handle
renaming properly.  However scalable-cyrfonts-x11 is a task-package, and
its renaming will force corresponding change in tasksel.

Anton Zinoviev, [EMAIL PROTECTED]

Re: Do not link GNOME apps with libpng3

[Havoc Pennington]

Hi,

FWIW, the solution we're planning for Red Hat is to create a symlink
"libpng10.so" to the old libpng, then link imlib and gnome-libs
against -lpng10. This way the ABI of imlib/gnome-libs is preserved,
but -lpng can be moved to libpng3.

I'll attach the imlib and gnome-libs patches. (This step also requires
creating /usr/include/png-1.0/png.h and killing off all -I/usr/include
in imlib.)

It would be nice to encourage the upstream png maintainer to support
parallel install as the GNOME 1/2 platforms do, but I haven't yet had
a chance to write a long explanation of how and why in order to send
that off to him.
 
I think it would be bad for Debian to break the GNOME 1 ABI for this
trivial reason, since GNOME upstream has gone to huge lengths not to
break it. And the libpng ABI changes are really trivial (renamed a
global variable, added a struct field, I think - very small changes).
After the enormous effort of upstream GNOME to maintain ABI it'd be
pretty lame to break ABI because of a variable rename or two in
libpng.

Havoc

--- imlib-1.9.10/configure.in.png10 Mon Jan  7 18:34:18 2002
+++ imlib-1.9.10/configure.in   Mon Jan  7 18:36:56 2002
@@ -40,6 +40,8 @@
 else 
AC_MSG_RESULT(yes)
 
+CFLAGS="-I /usr/include/png-1.0 $CFLAGS"
+
 if test "x$GDK_IMLIB" != x; then
   oLIBS="$LIBS"
   oCFLAGS="$CFLAGS"
@@ -280,7 +282,7 @@
 $GX_LIBS),
   AC_MSG_WARN(*** Native GIF support will not be built (GIF header not found) 
***))
 
-AC_CHECK_LIB(png, png_read_info,
+AC_CHECK_LIB(png10, png_read_info,
   AC_CHECK_HEADER(png.h,
 png_ok=yes,
 png_ok=no),
@@ -310,9 +312,9 @@
 #fi
 
 if test "$png_ok" = yes; then
-   PNGLIBS="-lpng -lz"
+   PNGLIBS="-lpng10 -lz"
AC_SUBST(HAVE_LIBPNG)
-   SUPPORT_LIBS="$SUPPORT_LIBS -lpng -lz"; AC_DEFINE(HAVE_LIBPNG)
+   SUPPORT_LIBS="$SUPPORT_LIBS -lpng10 -lz"; AC_DEFINE(HAVE_LIBPNG)
 else
AC_MSG_WARN(*** Native PNG support will NOT be built (PNG version us 
1.0.2, get 1.0.3) ***)
 fi

--- imlib-1.9.10/configure.in.cppflags  Tue Jan  8 15:05:58 2002
+++ imlib-1.9.10/configure.in   Tue Jan  8 15:06:11 2002
@@ -160,8 +160,6 @@
   GX_LIBS="$GTK_LIBS"
 fi
 
-CPPFLAGS="$CPPFLAGS -I$includedir -I$prefix/include"
-
 SUPPORT_LIBS=""
 
 dnl Test for shared memory headers and semantics, unless we are

--- gnome-libs-1.4.1.2.90/configure.in.png10Tue Jan  8 14:25:31 2002
+++ gnome-libs-1.4.1.2.90/configure.in  Tue Jan  8 14:49:16 2002
@@ -296,7 +296,7 @@
png_ok=yes,png_ok=no)
   AC_MSG_RESULT($png_ok)
   if test "$png_ok" = yes; then
-PNG_LIBS="-lpng $Z_LIBS"; AC_DEFINE(HAVE_LIBPNG)
+PNG_LIBS="-lpng10 $Z_LIBS"; AC_DEFINE(HAVE_LIBPNG)
   fi
 fi
 

Re: [ccheney@cheney.cx: libqt2 libpng2 resolution]

[Adam Heath]

On Wed, 9 Jan 2002, Adrian Bunk wrote:

> On Wed, 9 Jan 2002, Daniel Stone wrote:
>
> > > > How do you plan to prevent programs that link with libqt2 to also link
> > > > with libpng3 ? Manual check ?
> > >
> > > Another possiblility is the following (only the new dependencies are
> > > listed):
> > >
> > > Package: libqt2-dev
> > > Conflicts: libpng3
> > > Build-Conflicts: libpng3
> > >
> > > [note that libpng3 is the library package _not_ the -dev package]
> > >
> > >
> > > This way neither a program that links with libqt2 nor a library libqt2 is
> > > linked with can be linked with libpng3.
> >
> > What? That means that you can't have a libpng3 program on a machine with
> > libqt2-dev installed ... icky.
>
> Yes, but that's the only way I see to ensure that there aren't some ugly
> problems like e.g.

No, completely wrong.  You want to keep the -dev packages from being installed
at once.  It's the -dev package for a library that says what a program gets
linked to.  Just having the library on the machine does not mean packages can
be linked to it.

Get a clue.

Re: serious bug. Evolution and Microsoft mentality.

[Jeffrey Stedfast]

On Wed, 2002-01-09 at 01:43, Jonathan Walther wrote:
> On Mon, Jan 07, 2002 at 01:56:24PM -0500, Jeffrey Stedfast wrote:
> >Yea, this is kinda painful currently but hopefully by 1.2 this will be
> >much easier. We plan on making it so that you can add a new account
> >using "Standard Unix Mail Spool" as the source type and pointing it at a
> >directory and have our code automatically show all the mailboxes in the
> >directory. Currently it will only accept single mbox files as sources.
> 
> That will be very nice.  Will you also let us point to Maildir's and
> have it Just Work?  Maildir format allows us to continue using procmail
> and related programs without worrying about locking issues between
> Evolution and outside mail delivery programs and filters.

Actually, Evolution already supports pointing to outside Maildir
directories ;-)

> 
> >It's not really a good idea to use symlinks because Evolution will lock
> >the symlink file and if you have procmail running, it will lock the real
> >mbox file and so if you try and access the same mbox file with both
> >Evolution and procmail, things will end badly for you (ie corrupt
> >mailbox).
> 
> Correct.  Thats why I plan to switch over completely to Maildir format.
> 
> >> What happened?  My symlink was erased!  Gone!  A new mbox file had been
> >> created from the contents of the original.
> >
> >Did you delete/expunge messages? I presume that you must have because
> >otherwise the mbox would not have been rewritten. The only way to remove
> 
> Unfortunately, no.  I made no changes whatsoever to the mailboxes.  I
> just entered them to see if the messages showed up, they did, then I
> exited.  Thats when I noticed the symlinks had been blown away, and the
> resulting "copied" mailbox was bigger in size than the original!

Ah, I bet I know why... Evolution added an X-Evolution header to each
message for status purposes. The X-Evolution header contains an encoded
UID and message flags. That would also explain why it got bigger than
the original file.

> 
> >messages from an mbox file is to rewrite it to a new tmp file (minus the
> >messages to be deleted) and then rename that tmp file back to its
> >original name. Unfortunately, UNIX's rename() function clobbers symlinks
> >and thus your problem.
> 
> Well, alright.  I did some research tonight.  Before calling "rename()",
> a call to realpath() would resolve the symlink to the correct "real"
> filename, and using that would give the correct result.  An extra 3
> lines of code (to find out how much storage is needed for the real path,
> to allocate it, then finally to call realpath()).

Actually, this isn't guaranteed to work :-(
rename() is unfortunately limited to renaming files on the same file
system, once you add symlinks to the equation - you could be leaping
across file system boundaries and there isn't a way to tell (well, ok,
so you can check st.st_dev and compare the 2).

The only way I can think of to get around this is to create the tmp mbox
file in the same directory as the original (after being realpath()'d).
This may also have problems - what if you don't have write-permission in
that directory?

> 
> >Actually, Evolution plays very nice with other mail software on the
> >system - you just have to not use symlinks.
> 
> Supporting symlinks is easy.  Not supporting them is un-Unixy.

Not as easy as you seem to think, you missed that rename doesn't work
across file systems ;-)

Anyways, I'll look into it...

> 
> >Evolution locks all
> >mailboxes when it goes to access them to avoid mailbox corruption and so
> >as long as the other system mail software does the same (which it
> >should) then they will all live in harmony.
> 
> Again, provided one uses Maildir mailboxes, things will be fine.  But
> the thought occurs, Evolution should do its "locking" on the file
> returned from realpath() too.

You are probably right.

-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
[EMAIL PROTECTED]  - www.ximian.com

OT Re: serious bug. Evolution and Microsoft mentality.

[Manfred Wassmann]

On Wed, 9 Jan 2002, Jonathan Walther wrote:

[...]
> A user who doesn't know what he is doing will attempt to do everything
> from the provided GUI.  Its shameful to assume that people that attempt
> to use vi to edit their configurations are also idiots.

(humor-mode t)
  Why?  They would use emacs if they were not!
(humor-mode nil)

Re: serious bug. Evolution and Microsoft mentality.

[John Hasler]

> Evolution added an X-Evolution header to each message for status
> purposes.

Merely _looking_ at a message with Evolution alters it?  That is _truly_
evil.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: Preparing Debian GNU/Linux 2.2r5

[Florian Weimer]

Martin Schulze <[EMAIL PROTECTED]> writes:

> Development for 2.2r5 is near being finished ready to be released.

Will the glob() problem in GNU libc be fixed in 2.2r5?

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

BUG: Quake2 and mailcap file (mime-support)

[Pete Ryland]

Hi,

Not sure where to file a bug on this one.  (Nor how, actually, but that
shouldn't be too hard to work out)

I regularly check for new software and perform an upgrade to my system.  The
last time I did this, I installed quake2.

Getting the shareware data down caused quite a drama since my /tmp is only
about 100M and the download is bigger.  No problem, I had room elsewhere,
and reinstalled the quake2-data deb, kindly asking it to download to there.
When I woke up the next day, I found that the download had worked fine, but
it then tried to unpack the data into tmp obviously filling the device and
causing all sorts of troubles.  This was resolved without too much pain
(although still no quake2 - that can wait for now), but something I noticed
a bit later was that my mailcap entry was 0 byted.  I'm figuring that one of
the things upgraded was mime-support, and the configure step needs room on
/tmp otherwise bye bye mailcap.

So is this a bug with mime-support (shouldn't have blown away mailcap when
/tmp was full), quake2-data (shouldn't have filled /tmp in the first place),
both, or should I have been monitoring /tmp and it's really my own silly
fault? (100M is surely enough for most things, no?)

But I say thank you for the software, and releasing it as free... ;)

Best regards,
Pete Ryland


pgprlKaI0bqMy.pgp
Description: PGP signature

Re: BUG: Quake2 and mailcap file (mime-support)

[Henrique de Moraes Holschuh]

On Wed, 09 Jan 2002, Pete Ryland wrote:
> So is this a bug with mime-support (shouldn't have blown away mailcap when

Grave bug against mime-support IF it is the package that generates
/etc/mailcap.  It must be able to detect write errors, and avoid data loss.

> /tmp was full), quake2-data (shouldn't have filled /tmp in the first place),

quake2-data should use TMPDIR, and you (the user) should have it pointing
somewhere with enough space. quake2-data should warn you it will need space
to unpack whatever in TMPDIR.

> fault? (100M is surely enough for most things, no?)

Well, I usually have a 0.5GB /tmp because of silly software that wants to
eat up huge amounts of /tmp space for installs. Quake2-data is in that
league, apparently.

-- 
  "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: serious bug. Evolution and Microsoft mentality.

[Branden Robinson]

On Wed, Jan 09, 2002 at 12:55:34PM -0600, John Hasler wrote:
> > Evolution added an X-Evolution header to each message for status
> > purposes.
> 
> Merely _looking_ at a message with Evolution alters it?  That is _truly_
> evil.

Maybe, but it's also commonplace.

Consider how elm has for many years added "Status: OR" flags to read
messages.

-- 
G. Branden Robinson| Communism is just one step on the
Debian GNU/Linux   | long road from capitalism to
[EMAIL PROTECTED] | capitalism.
http://people.debian.org/~branden/ | -- Russian saying


pgpx53DaSLvKM.pgp
Description: PGP signature

Re: Do not link GNOME apps with libpng3

[Philippe Troin]

"Steve M. Robbins" <[EMAIL PROTECTED]> writes:

> On Wed, Jan 09, 2002 at 03:23:25PM +0100, Christian Marillat wrote:
> > >> "SMR" == Steve M Robbins <[EMAIL PROTECTED]> writes:
> > 
> > > On Wed, Jan 09, 2002 at 03:09:08PM +0100, Christian Marillat wrote:
> > 
> > [...]
> > 
> > >> I really want to know why recompiling gdk-imlib1 is too hard ?
> > 
> > > Recompiling isn't hard.  Managing the transition is hard.  Did you
> > > read the threads in debian-devel and debian-kde?  Do you have a solution
> > > to managing the transition?
> > 
> > Yes I've read the thread in -devel. For Gnome we only need to recompile
> > your package and dgk-pixbuf.
> 
> You think only two packages need recompiling?  I can only conclude
> that, while you may have read the thread, you did not understand it.

[EMAIL PROTECTED] egrep '^Depends:.*libpng' /var/lib/dpkg/available | wc -l
377
[EMAIL PROTECTED] egrep '^Depends:.*gdk-imlib1' /var/lib/dpkg/available | wc -l
254
[EMAIL PROTECTED] egrep '^Depends:.*gdk-imlib1' /var/lib/dpkg/available |egrep 
'^Depends:.*libpng' | wc -l
 24

It would be at most 24 packages.

> The best summary (in my humble opinion) is
> 
> 
> http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg00243.html
> 
> The main conclusion is this: if imlib1 (and gdk-imlib1) change their linkage
> from libpng2 to libpng3, then ANY APPLICATION THAT LINKS WITH ONE OF THOSE
> AND ALSO WITH LIBPNG NEEDS TO BE RECOMPILED.  That's a whole lot more than
> two packages.

24 at most.

8< snip >8

> P.S.  Just for the record: what specifically are the benefits to
> recompiling everything with libpng3?

What are the benefits of recompiling eveything with libc6? ;-)

Phil.

Gnome 2 packages?

[Martin Sjögren]

I'm starting to port my Gnome programs to Gnome 2, and was a bit stumped
when there was lots of Gnome 2 packages missing from unstable. The ones I
found right now were libbonoboui and libgnomecanvas, but I'm sure there
are others missing too.

Are there any plans on packaging this soon? The wnpp pages seem to be
broken (or is there not supposed to be ANY ITPs/RFPs?) so it's hard to see
anything there... I'd be happy to help, 'though I'm not an official
developer.

Cheers,
Martin

-- 
Martin Sjögren
  [EMAIL PROTECTED]   ICQ : 41245059
  Phone: +46 (0)31 405242Cell: +46 (0)739 169191
  GPG key: http://www.mdstud.chalmers.se/~md9ms/gpg.html

Re: BUG: Quake2 and mailcap file (mime-support)

[Adam Heath]

On Wed, 9 Jan 2002, Pete Ryland wrote:

I solve the small space problem in /tmp this way.

/tmp is a real directory, and exists on the root filesystem.  This allows boot
programs to create temp files.

Upon bootup, I bind mount /tmp to some other place, that has lots of place.
This allows larger programs after booting to create larger files.  This only
works on linux 2.4, however.  It's done with the following entry in
/etc/fstab:

/home.local/tmp /tmpnonebind0   0

Bug#128487: ITP: ferite -- Ferite programming language

[Eric Dorland]

Package: wnpp
Version: N/A; reported 2002-01-09
Severity: wishlist

* Package name: ferite
  Version : 0.99.4
  Upstream Author : Chris Ross (boris) <[EMAIL PROTECTED]>
* URL : http://www.ferite.org/
* License : BSD
  Description : Ferite programming language

Ferite is a language that incorporates the design philosophies of other
languages, but without many of their drawbacks. It has strong
similiarities to perl, python, C, Java and pascal, while being both
lightweight, modular, and embeddable.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux apocalypse 2.4.16 #1 Fri Nov 30 14:38:38 EST 2001 i686
Locale: LANG=en_US, LC_CTYPE=

Re: serious bug. Evolution and Microsoft mentality.

[Jonathan Walther]

On Wed, Jan 09, 2002 at 01:41:28PM -0500, Jeffrey Stedfast wrote:
Unfortunately, no.  I made no changes whatsoever to the mailboxes.  I
just entered them to see if the messages showed up, they did, then I
exited.  Thats when I noticed the symlinks had been blown away, and the
resulting "copied" mailbox was bigger in size than the original!
Ah, I bet I know why... Evolution added an X-Evolution header to each
message for status purposes. The X-Evolution header contains an encoded
UID and message flags. That would also explain why it got bigger than
the original file.
Fair enough.  Pine does something similar.  Can it be gauranteed that
the Quoted Printable encoding hasn't been decoded then reencoded in
the process?
Actually, this isn't guaranteed to work :-(
rename() is unfortunately limited to renaming files on the same file
system, once you add symlinks to the equation - you could be leaping
across file system boundaries and there isn't a way to tell (well, ok,
so you can check st.st_dev and compare the 2).
The only way I can think of to get around this is to create the tmp mbox
file in the same directory as the original (after being realpath()'d).
This may also have problems - what if you don't have write-permission in
that directory?
You solved the problem.  That is the correct solution.  After running
realpath(), use dirname() and make the tmpfile in the same directory
as the mailbox.
The perception of a possible permissions problem is bogus.  If you don't
have permission in that directory to create the tmp mailbox, then you
probably didn't have permission to blast over the original mailbox
either.  Suppose you successfully created the tmp file, but the rename()
failed?  I mean, it *could* happen.  But its not likely.
If such operations as creating the tmp file, or renaming it  fail, that
means the user has set the permissions himself, in which case he probably
wanted that to happen.  So don't complain, and leave the mailbox as is.
Remember, "stupid" users will try to do everything from the GUI you
provide.  Users savvy enough to fiddle with ln, touch, chown, and chmod
will get angry and exceedingly frustrated if you treat their actions the
same as you treat those of your target "stupid" user.
Again, provided one uses Maildir mailboxes, things will be fine.  But
the thought occurs, Evolution should do its "locking" on the file
returned from realpath() too.
You are probably right.
I've thought about it some more, and I'm upgrading my "maybe" to a
strong "this is the proper way to do it".  Symlinks should not be
locked.  They should be followed with realpath() and the real mailbox
should be locked, like other MUA's do.  This will truly make it
compatible and play nicely on the Unix system.
Cheers!
Jonathan
--
I am working to subvert from within ...
umm ...  by writing shoddy code ... and
charging too much. -- Colin, Aug 21, 2001


pgpcOfMEOuAPT.pgp
Description: PGP signature

Re: Do not link GNOME apps with libpng3

[Colin Watson]

On Wed, Jan 09, 2002 at 04:37:17PM +0100, Christian Marillat wrote:
> >> "SMR" == Steve M Robbins <[EMAIL PROTECTED]> writes:
> > The fact remains that we cannot change the linkage of the library
> > NOR of applications piecemeal.  The changes must be coordinated.
> > In the absence of a transition plan, I see no reason to introduce 
> > instability in GNOME by changing imlib.  If you have a workable
> > plan, I'm all ears.
> 
> See Colin's answer. Change the library soname and shlibs. This will
> solve this bug.

I was proposing that as a reason not to change it during a freeze, not
as a practical short-term transition plan. :)

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Gnome 2 packages?

[Christian Marillat]

>> "MS" == Martin Sjögren <[EMAIL PROTECTED]> writes:

> I'm starting to port my Gnome programs to Gnome 2, and was a bit stumped
> when there was lots of Gnome 2 packages missing from unstable. The ones I
> found right now were libbonoboui and libgnomecanvas, but I'm sure there
> are others missing too.

libgnomecanvas will be uploaded tomorrow with libgnomeprintui and
libgnomeui

Christian

Re: BUG: Quake2 and mailcap file (mime-support)

[Joey Hess]

Adam Heath wrote:
> /tmp is a real directory, and exists on the root filesystem.  This allows boot
> programs to create temp files.
> 
> Upon bootup, I bind mount /tmp to some other place, that has lots of place.
> This allows larger programs after booting to create larger files.  This only
> works on linux 2.4, however.  It's done with the following entry in
> /etc/fstab:
> 
> /home.local/tmp /tmpnonebind0   0

It's a lot easier to just use ~/tmp via TMPDIR. The only thing that
ever writes to my (90 MB) /tmp is X. You also don't need to worry about
/tmp races as much..

-- 
see shy jo

Re: serious bug. Evolution and Microsoft mentality.

[Jeffrey Stedfast]

On Wed, 2002-01-09 at 16:20, Jonathan Walther wrote:
> On Wed, Jan 09, 2002 at 01:41:28PM -0500, Jeffrey Stedfast wrote:
> >> Unfortunately, no.  I made no changes whatsoever to the mailboxes.  I
> >> just entered them to see if the messages showed up, they did, then I
> >> exited.  Thats when I noticed the symlinks had been blown away, and the
> >> resulting "copied" mailbox was bigger in size than the original!
> >
> >Ah, I bet I know why... Evolution added an X-Evolution header to each
> >message for status purposes. The X-Evolution header contains an encoded
> >UID and message flags. That would also explain why it got bigger than
> >the original file.
> 
> Fair enough.  Pine does something similar.  Can it be gauranteed that
> the Quoted Printable encoding hasn't been decoded then reencoded in
> the process?

not easily. Michael Zucchi and I will have to redesign libcamel to be
able to guarantee this and so must wait until we have time.

> 
> >Actually, this isn't guaranteed to work :-(
> >rename() is unfortunately limited to renaming files on the same file
> >system, once you add symlinks to the equation - you could be leaping
> >across file system boundaries and there isn't a way to tell (well, ok,
> >so you can check st.st_dev and compare the 2).
> >
> >The only way I can think of to get around this is to create the tmp mbox
> >file in the same directory as the original (after being realpath()'d).
> >This may also have problems - what if you don't have write-permission in
> >that directory?
> 
> You solved the problem.  That is the correct solution.  After running
> realpath(), use dirname() and make the tmpfile in the same directory
> as the mailbox.
> 
[snip]

The attached patch will fix this issue.

> 
> >> Again, provided one uses Maildir mailboxes, things will be fine.  But
> >> the thought occurs, Evolution should do its "locking" on the file
> >> returned from realpath() too.
> >
> >You are probably right.
> 
> I've thought about it some more, and I'm upgrading my "maybe" to a
> strong "this is the proper way to do it".  Symlinks should not be
> locked.  They should be followed with realpath() and the real mailbox
> should be locked, like other MUA's do.  This will truly make it
> compatible and play nicely on the Unix system.

It also fixes this.

-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
[EMAIL PROTECTED]  - www.ximian.com
Index: ChangeLog
===
RCS file: /cvs/gnome/evolution/camel/ChangeLog,v
retrieving revision 1.1311.2.11
diff -u -r1.1311.2.11 ChangeLog
--- ChangeLog   2002/01/04 22:17:52 1.1311.2.11
+++ ChangeLog   2002/01/09 21:44:15
@@ -1,3 +1,11 @@
+2002-01-09  Jeffrey Stedfast  <[EMAIL PROTECTED]>
+
+   * providers/local/camel-local-folder.c
+   (camel_local_folder_construct): If the mbox file is a symlink,
+   follow the symlink and get the One True Path so that we can
+   rewrite the mbox later without worrying about clobbering the
+   symlink.
+
 2001-12-12  Jeffrey Stedfast  <[EMAIL PROTECTED]>
 
* camel-folder-summary.c (content_info_load): Don't try setting a
Index: providers/local/camel-local-folder.c
===
RCS file: /cvs/gnome/evolution/camel/providers/local/camel-local-folder.c,v
retrieving revision 1.22
diff -u -r1.22 camel-local-folder.c
--- providers/local/camel-local-folder.c2001/10/28 05:10:55 1.22
+++ providers/local/camel-local-folder.c2002/01/09 21:44:15
@@ -24,6 +24,7 @@
 #endif
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -191,7 +192,14 @@
lf->folder_path = g_strdup_printf("%s/%s", root_dir_path, full_name);
lf->summary_path = g_strdup_printf("%s/%s.ev-summary", root_dir_path, 
full_name);
lf->index_path = g_strdup_printf("%s/%s.ibex", root_dir_path, 
full_name);
-
+   
+   /* follow any symlinks to the mailbox */
+   if (lstat (lf->folder_path, &st) != -1 && S_ISLNK (st.st_mode) &&
+   realpath (lf->folder_path, folder_path) != NULL) {
+   g_free (lf->folder_path);
+   lf->folder_path = g_strdup (folder_path);
+   }
+   
lf->changes = camel_folder_change_info_new();
 
/* if we have no index file, force it */

Re: serious bug. Evolution and Microsoft mentality.

[Bernd Eckenfels]

On Wed, Jan 09, 2002 at 01:20:16PM -0800, Jonathan Walther wrote:
> The perception of a possible permissions problem is bogus.  If you don't
> have permission in that directory to create the tmp mailbox, then you
> probably didn't have permission to blast over the original mailbox
> either.

It is very likely. Allowing to create files in the spooldir of a mbox style
spool means you are able to actually fake or dos other's mail receiving. It
is prefered to have only write access to you own mailbox. Normally a trusted
application is granted more access by running it sgid mail.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: why is 'dbf' in non-free?

[DvB]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> On Mon, Jan 07, 2002 at 02:46:47PM -0600, DvB wrote:
> 
> The best place to look for this information is in the copyright file
> contained in the package.  In this case, the problem is with the copyright
> for libdbf:
> 

> This is non-free because it restricts commercial use of the software, and
> charging for copies.  The laterr makes it impossible to sell a Debian CD
> containing this software.


I see... that makes sense.

Anyway, I've just released my version under the LGPL and anyone's
welcome to try it out and send me feedback. Note that it hasn't been
very widely tested and only with Xbase v3 files since I don't have
access to any other version at the moment. I also intend to redesign it
in the (hopefully near) future to make it more extensible, since I
would like to add more file formats.

You can download the source tarball at
http://home.jam.rr.com/dvb/DBFTools.tar.gz

Re: We still need sponsors!

[Raphael Hertzog]

Le Wed, Jan 09, 2002 at 11:18:05AM +0100, Tille, Andreas écrivait:
> OK.  If I understand this right that would mean that the control file
> would state
> 
>   Maintainer: Future Maintainer <[EMAIL PROTECTED]>
> 
> and my own address will be in the changelog (like in an NMU).

No, you don't need to change the changelog. I usually build without
signatures (dpkg-buildpackage -us -uc) and then use debsign on the
.changes. You can add a line to the changelog entry if you want to
expressly mention that the upload was sponsored.

> Where is the place to make clear that:
>"The package is called a sponsored package ..."
> Are there any fields/conventions?

No, you aren't forced to make it clean anywhere. Since the uploads are
checked by the sponsor, they are as trustable as any other upload.

> PS: I wonder why your
>  "Sponsorship of future Debian developers" - page
> is not in the debian.org domain!

Historical reasons mainly. The sponsor system was not not supported by
people who had the possibilty to transfer it to debian at that time.
So it stayed here ... not a big deal anyway.

Cheers,
-- 
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com

Re: serious bug. Evolution and Microsoft mentality.

[Erik Steffl]

[EMAIL PROTECTED] wrote:
> 
> Zitiere Erik Steffl <[EMAIL PROTECTED]>:
> 
> [1935 lines uselessly quoted]
> >
> > IMO the good solution for this kind of problems is to use IMAP.
> > don't trust MUAs to work with files.
> 
> IMO IMAP is still a PITA, AFAIK the only well and out of the box 
> interoperating
> combination of MUA and IMAPd is pine together with uw-imapd which is about as
> configurable as your sunglasses. With other Linux combinations you'll have to

  uw-imap is a good choice for beginner (you only need to apt-get
install it), while it's true that it cannot be configured much (and the
configuration is compile-time) it already provides much better
functionality then file based mail storage (no file access conflicts,
access to email over network (supports ssl), access to other stuff)

  as far as MUAs go I think the new ones have fairly good support for
IMAP (mutt (could be better), netscape, evolution etc.) [I use netscape
and mutt mostly]

> go fiddling with Prefix&|View = INBOX. | INBOX* | INBOX.% | INBOX etc.
> 
> IMO nothing for newbies.

  I only have experience with cyrus (with sieve) and it's quite a hell,
it provides almost no feedback, docs are all over the place etc. works
well but very unpleasant to handle. also,the version in debian is
extremely old.

erik

Re: BUG: Quake2 and mailcap file (mime-support)

[Matt Zimmerman]

On Wed, Jan 09, 2002 at 05:13:48PM -0200, Henrique de Moraes Holschuh wrote:

> On Wed, 09 Jan 2002, Pete Ryland wrote:
> > So is this a bug with mime-support (shouldn't have blown away mailcap when
> 
> Grave bug against mime-support IF it is the package that generates
> /etc/mailcap.  It must be able to detect write errors, and avoid data loss.

/etc/mailcap is not a conffile, so it could possibly be modified by other
packages.  I think they are all supposed to use update-mime, though, so look
there first.

> > /tmp was full), quake2-data (shouldn't have filled /tmp in the first place),
> 
> quake2-data should use TMPDIR, and you (the user) should have it pointing
> somewhere with enough space. quake2-data should warn you it will need space
> to unpack whatever in TMPDIR.

quake2-data should prompt the admin where to download the files, since
TMPDIR is not expected to have such large amounts of space, wherever it
points to.

> > fault? (100M is surely enough for most things, no?)
> 
> Well, I usually have a 0.5GB /tmp because of silly software that wants to
> eat up huge amounts of /tmp space for installs. Quake2-data is in that
> league, apparently.

I use tmpfs for /tmp.

-- 
 - mdz

Re: forking packages and private archive

[Petter Reinholdtsen]

[Peter Jordan]
> I am not sure if I should create my own installer package
> (non-interactive) using debian-installer and a forked rootskel [...]

This sounds interesting and highly relevant to the work I'm currently
doing.  Do you have a complete automatic non-interactive installation
working?  Please tell me more.

Re: BUG: Quake2 and mailcap file (mime-support)

[Pete Ryland]

On Wed, Jan 09, 2002 at 06:16:54PM -0500, Matt Zimmerman wrote:
> quake2-data should prompt the admin where to download the files, since
> TMPDIR is not expected to have such large amounts of space, wherever it
> points to.

It does prompt for a download location, but after downloading unpacks to
/tmp anyway.

Pete


pgp9o4oD4VlNw.pgp
Description: PGP signature

Re: Fw: Bug#128089: kdegraphics: Build failure: including non-PIC code in shared object (ia64/unstable)

[Daniel Stone]

On Wed, Jan 09, 2002 at 04:38:20PM +, James Troup wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Jan 09, 2002 at 08:20:00PM +1100, Daniel Stone wrote:
> > > Can someone please help me with this?
> > 
> > Have you identified why libkcm_karea.so is linking against libgphoto2.a 
> > instead of against libgphoto2.so?
> 
> It's a broken symlink; I seem to recall having this conversation with
> Daniel at least once already...

Somewhere in the mists of time, which I forgot about, which is mainly
why I've been trying to find you for the last week. So does the problem
lie in libgphoto2?

-- 
Daniel Stone<[EMAIL PROTECTED]>
 hmm, someone remind me, what's the English term for startup lag?
 "netscape effect"


pgpUgtCY7Kl6J.pgp
Description: PGP signature

Re: serious bug. Evolution and Microsoft mentality.

[Anders Jackson]

Branden Robinson <[EMAIL PROTECTED]> writes:

> On Wed, Jan 09, 2002 at 12:55:34PM -0600, John Hasler wrote:
> > > Evolution added an X-Evolution header to each message for status
> > > purposes.
> > 
> > Merely _looking_ at a message with Evolution alters it?  That is _truly_
> > evil.
> 
> Maybe, but it's also commonplace.
> 
> Consider how elm has for many years added "Status: OR" flags to read
> messages.

Even Gnus (in Emacs) does this.  Adding status-headers I at least
doesn't find any problems with.  Changing coding to QP is a bad thing
though.

/Jackson

lock files in /home???

[Brian May]

Hello,

Recently with one of my upgrades Nautils stopped working.

The reason? It requires gconfd to be running, but gconfd kept
crashing.

The reason gconfd keeps crashing? According to strace, it tries
to create a lock file under $HOME/.gconfd/locks/.

However, on this system /home is NFS mounted with file locking
disabled, hence the file locking operation fails. This in turn causes
gconfd to fail, which in turn causes Nautils to fail.

Is it really required to have file locks under $HOME? Wouldn't, say
/tmp be more appropriate?
-- 
Brian May <[EMAIL PROTECTED]>

Re: BUG: Quake2 and mailcap file (mime-support)

[Matt Zimmerman]

On Wed, Jan 09, 2002 at 11:27:51PM +, Pete Ryland wrote:

> On Wed, Jan 09, 2002 at 06:16:54PM -0500, Matt Zimmerman wrote:
> > quake2-data should prompt the admin where to download the files, since
> > TMPDIR is not expected to have such large amounts of space, wherever it
> > points to.
> 
> It does prompt for a download location, but after downloading unpacks to
> /tmp anyway.

File a bug.

-- 
 - mdz

Re: Fw: Bug#128089: kdegraphics: Build failure: including non-PIC code in shared object (ia64/unstable)

[Steve Langasek]

On Thu, Jan 10, 2002 at 10:54:03AM +1100, Daniel Stone wrote:
> On Wed, Jan 09, 2002 at 04:38:20PM +, James Troup wrote:
> > Steve Langasek <[EMAIL PROTECTED]> writes:
> > 
> > > On Wed, Jan 09, 2002 at 08:20:00PM +1100, Daniel Stone wrote:
> > > > Can someone please help me with this?
> > > 
> > > Have you identified why libkcm_karea.so is linking against libgphoto2.a 
> > > instead of against libgphoto2.so?
> > 
> > It's a broken symlink; I seem to recall having this conversation with
> > Daniel at least once already...
> 
> Somewhere in the mists of time, which I forgot about, which is mainly
> why I've been trying to find you for the last week. So does the problem
> lie in libgphoto2?

I checked over the ia64 binary for gphoto2-dev -- yes, it's a bug with 
this package.

Steve Langasek
postmodern programmer

Re: serious bug. Evolution and Microsoft mentality.

[Jonathan Walther]

Thank you for the patch.  To make it work, you need to define the
variable "folder_path".  I would recommend this:
char folder_path[4096];
And then before using it, do this:
memset(folder_path, 0, sizeof folder_path);
Cheers.
Jonathan
On Wed, Jan 09, 2002 at 04:57:34PM -0500, Jeffrey Stedfast wrote:
You solved the problem.  That is the correct solution.  After running
realpath(), use dirname() and make the tmpfile in the same directory
as the mailbox.
[snip]
The attached patch will fix this issue.
>> Again, provided one uses Maildir mailboxes, things will be fine.  But
>> the thought occurs, Evolution should do its "locking" on the file
>> returned from realpath() too.
>
>You are probably right.
I've thought about it some more, and I'm upgrading my "maybe" to a
strong "this is the proper way to do it".  Symlinks should not be
locked.  They should be followed with realpath() and the real mailbox
should be locked, like other MUA's do.  This will truly make it
compatible and play nicely on the Unix system.
It also fixes this.


pgpUE6uxH7my2.pgp
Description: PGP signature