Application for Employment / Contract Work

[Anthony Heller]

*** Please Note:  Do Not Use your Reply button if you wish to respond to
this email *** 
*** Please reply to [EMAIL PROTECTED]  ***


Hello,

I came across your website, and thought I would send you a copy of  my CV
/ Resume (please scroll down the page) to see if you are in need of any
help in promoting your site with regards to Search Engines or if your
company requires any Accounting help.  I am currently living in Thailand
and would like to assist you in any way I can.  Please contact me
015151302 or on [EMAIL PROTECTED] and we can discuss your immediate
needs.   Thank you and have a nice day.

Tony Heller


--

Finance Manager / Accounting Consultant / LAN Administrator

 My name is Tony Heller and I am a 33-year-old Canadian male,
presently living in Jomtien, Thailand.  I am seeking employment as a
Finance Manager or for contract work as an Independent Consultant for a
company based in South East Asia.  I am willing to re-locate anywhere in
Thailand and would also consider a position in another South East Asian
country.

 I recently moved to Thailand, largely as a result of September 11th,
after eight years of living and working in Indonesia. (I worked for four
years in Jakarta and another four in Bali.)  I can speak Bahasa Indonesia
(Indonesian language) fluently.  

 I am a Certified General Accountant and have a Finance Degree from
the British Columbia Institute of Technology located in Vancouver, B.C.
Canada.  I have held positions as both Finance Manager and Computer
Consultant for several large companies in Asia. My primary roles have been
consolidating accounting data and organizing that data into clear and
precise Financial Statements that Managers, Directors and Owners can
clearly understand. 

 My past 3 years were spent building Bali System Development, a
computer software company that focuses on writing software databases,
multi media presentations and general LAN support issues.  As an owner of
that company with 30 programming staff, I have a great deal of experience
with regard to most computerized accounting methods and solutions.  I have
especially worked extensively with ACCPAC, MYOB and Peachtree.  

  

Personal Information
   
  My Background
 I lived with my family in West Vancouver, B.C. Canada until I
attended University.  I was actively involved in many sports and excelled
at soccer and gymnastics during my younger years.  After high school, I
worked on a kibbutz in Israel for 6 months and then backpacked through
most of Asia, the Middle East and Europe.  
 Upon my return to Vancouver in 1987, I enrolled, and completed my
degree in the Finance Management program at The British Columbia Institute
of Technology (B.C.I.T).  After graduating, I enrolled in the final
two-year program of the Certified General Accountants of Canada at night,
and worked for Azcom Information Systems in Vancouver as a Network
Engineer during the day.  After passing the Certified Network Engineer
Program, also at B.C.I.T., I was promoted to the role as LAN Administrator
of  the British Columbia Medical Association and was in charge of more
than 400 personal computers running on a Novell network. 
 In 1994, I decided to take my skills and expertise to Asia, and seek
employment. I moved to Jakarta, Indonesia and started consulting for
companies, generally helping them computerize their accounting systems,
troubleshooting various LAN problems, and assisting in any Internet
(Website) assistance required. 
 In 1997 I left Jakarta to take on the position of Finance Manager for
the Bali Golf and Country Club.  I worked there for 1 1/2 years and
decided to leave the position and open my own company.  Bali didn't have
any professional computer companies, at that time, so I opened Bali System
Development. ("BSD")
 BSD grew from 4 programmers to 30 in two years. (Our clientele
included more than 75 companies and individuals.  Business was very good
until September 11th.  
In November 2001, I moved my family to Pattaya, Thailand.  BSD is still a
functional company with 15 programmers and is currently being run by my
partner.  I, however, am now a silent partner and am seeking employment as
either a Finance Manager or Accounting Consultant in South East Asia. I
would also consider the position as a LAN Administrator or any position
that utilizes my skills and expertise.
I am willing to re-locate if necessary, on either a salaried or hourly
contract work basis. I can utilize the programmers at Bali System
Development to help with any necessary programming that may be required.
If you have any further questions regarding my background, please email
me.  
  
Education

I spent my teenage years studying at Hillside Secondary School in West
Vancouver, B.C. Canada.  Shortly after graduation, in 1986, I attended The
British Columbia Institute of Technology in Burnaby, B

Re: Please compile treetool on alpha, arm, hppa, ia64, powerpc and s390

[Andreas Tille]

On Fri, 30 Aug 2002, Branden Robinson wrote:

> Okay.  What you have is a license, then; it's just a very informal one.
>
> Email from a person granting you permission to do things not ordinarily
> permitted by copyright law is a "license", when that person has
> appropriate legal standing to grant such permission.  Such
> communications are just as valid as the GNU GPL or BSD licenses, if less
> formal.
Well but it avoids §8 of DFSG and what I intended to say was there is
"no license for upstream source" - and that's really a pitty in this case
because this program which is obviousely used by a lot of biologists
needs some work and nobody can do it because of the missinging
upstream license.

Kind regards

 Andreas.

Re: woody CD not bootable with adaptec + scsi-cdrom

[Goswin Brederlow]

Richard Atterer <[EMAIL PROTECTED]> writes:

> So the final solution was to use multiboot only on the first CD, the
> other CDs use the same method as potato. The few machines on which it
> fails are either old or have a SCSI CD-ROM, booting from one of the
> later CDs should work for them. AFAIK if the woody release multiboot
> CD fails, it even prints a message which tells you to do that.

Haven't seen that. But maybe that wasn't ready or not included on the
Linuxtag CDs. They are pre stable.

MfG
Goswin

PS: I will see if I can get a real woody to test this. Don't want to
waste the traffic though.

Re: woody CD not bootable with adaptec + scsi-cdrom

[Goswin Brederlow]

Andreas Metzler <[EMAIL PROTECTED]> writes:

> Disclaimer: Because I do not work on the debian-cd, bf or installer
> and do not follow the mailing lists regularily, I do not know much
> about this issue and there are probably lots of errors in this mail.
> 
> Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> > I just crasht my system working on libsafe and hat to boot from CD.
> 
> > I the discovered that the woody CD (linuxtag prerelease) doesn't
> > boot. I heard of similar for the real woody release CDs on irc.
> 
> > Can anyone boot the CDs, which one of the set and what hardware?
> > Same if you can't boot.
> 
> Hello,
> Lots of people can, the official CD-image _were_ tested. - I think the
> linuxtag prerelease CD is similar to the official CD1.
> 
> I can boot from CD1, on a PentiumMMX-class machine (SiS 5591/5), an
> iirc 1 year old Athlon 800 (VIA 133) and a 2 month old Duron1200
> (VIA 266A).

Who cares about your cpu?
What cdrom? ide or scsi? What controler?


> > Also whats different between potato and woody?
> 
> potato used floppy-emulation, woody _CD1_ uses isolinux(??).

That explains the difference in output. The floppy emulation shows up
when the adaptec detects the bootable cdrom. Or is that unrelated?


> > potato has this multiboot thing and woody not anymore, right? What
> > was wrong with it?  Seems to be more compatible the old way.
> 
> It is not, search the Debian-CD mailing-list.
> 
> IIRC: Basically Microsoft switched the CD-boot method they used for
> their OS CDs, the BIOS manufacturers followed suit and dropped support
> for or did not fix bugs in the old method and added support for the
> "new" method. For maximum compatibility with old computers you need
> floppy-emulation, for new computers you need the new method. BTW
> RedHat et al. don't use floppy-emulation, too.
> 
> If your computer cannot boot woody CD1 try CD2-CD7 - they use
> floppy-emulation and should work on old computers.

Good to know. Is that in the install docs somewhere?

MfG
Goswin

Re: Improper NMU (Re: NMU for libquota-perl)

[Bas Zoetekouw]

Hi Elie!

You wrote:

> The NMU was made before I was in any way contacted.

That's exactly why it was uploaded to DELAYED instead of incoming.

> I don't think anyone is arguing that the fix isn't needed; I don't,
> however, appreciate being treated like an MIA maintainer and having

If so, why didn't you upgrade the package before? There has been ample
warning about the perl 5.8 transition and the BSP.

> my responsibilities coopted. There is no urgency that requires an
> NMU if it's not important enough to file a bug.

Oh, I could very well have filed a grave bug along with the NMU. I just
found it more convenient to mail the maintainer directly. I agree with
you that the guidelines state that this communication should be done via
the BTS (I wasn't aware of that, and I will do that in the future), but
I find this a minor issue, because it wouldn't have changed anything. 

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
| [EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 

Re: The harden-*flaws packages.

[Ola Lundqvist]

Hi

Thanks for the arguing.

On Sun, Sep 01, 2002 at 09:22:56PM -0400, Daniel Martin wrote:
> Martin Schulze <[EMAIL PROTECTED]> writes:
> 
> > Please see the thread summarized in 
> > :
> > 
> > Policy for Woody Point-Releases. [4]Several [5]developers [6]would
> > [7]like to add new packages and updates to their packages to the
> > recently released stable distribution of Debian. Adding new packages
> > and random updates to the stable distribution, however, would nullify
> > the entire idea of having a stable release, Joey [8]explained. Hence,
> > the same policy as before will be used for point-releases of woody.
> 
> Yes, but how does this apply to a package that does nothing but
> conflict with existing packages?  (As is the case with most of the
> harden-* packages)
> 
> Agreed, _random_ updates would be a bad thing.  However, what the
> maintainer is proposing here is updates that are driven by DSAs.
> Although I find it a slight stretch, one could easily argue that the
> updates to the harden-*flaws packages are security updates.
> 
> These updates share another feature with security updates.  Imagine
> the package netostrich, which helps you bury your head in the sand
> remotely.  Now, suppose the upstream authors discover a flaw in the
> 2.0 series of netostrich prior to version 2.33 which allows random
> network users to bury other people's heads in the sand.  Sarge soon
> contains 2.34 with the security fix, yet woody contains 2.29.1 with a
> backported fix.  Then there would similarly need to be two
> harden-remoteflaws; one for woody, which conflicts with netostrich
> prior to 2.29.1, and one for sarge, which conflicts with netostrich
> prior to 2.34.  The harden-*flaws update has to be backported along
> with the backported fix to netostrich.
> 
> Now, if we want the harden-remoteflaws package to be at all useful, it
> needs to be updated along with DSAs...

Yes. Luckily I just saw someone that have written a script that checks
the DSA:s and tell the maintainer that he/she has a vulnerable package.
That is a good solution (best?). The problem is that the DSA is 
not able to distinguish between local/remote/3rdparty flaws but
that is not always interesting.

> Hrm.  The more I think about this the more I wonder if maybe the
> harden-*flaws packages make much sense in stable at all.  If someone
> is apt-get'ing from security.debian.org, they're already replacing
> vulnerable versions with fixed ones.  If someone is updating from a
> point release CD, the same thing applies.  The only case where I can
> see it making sense is with someone following testing with most of
> their packages on hold (they really want a stable system, and only
> upgrade a package when they need to).  Am I missing a scenario?

Yes. When you have a lot of own-compiled debs in an other archive
which can be more or less stable.

So my suggestion (which it probably will be) is that the harden-*flaws
package either contain that (or such a) script or depend on it.

Maybe I will merge the *flaws into a flaws package.

Regards,

// Ola

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

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Re: Security notification script

[Ola Lundqvist]

Hi again,

I'm I right when I say that this script only can follow the
DSA:s that cover woody? It is nice but I would really like a
version that can handle sid too. :) It would be some
more text processing but I think it is doable.

Do you want me to make a dependency/recommend from
harden-*flaws to this package?

Regards,

// Ola

On Fri, Aug 30, 2002 at 01:13:18PM +0200, Ola Lundqvist wrote:
> On Mon, Aug 26, 2002 at 09:31:34PM +0100, Rob Bradford wrote:
> > I have written a python script that allows you to compares locally
> > installed  packages with those on security.debian.org. Furthermore it
> > provides a description of the problem/DSA name if the package is
> > mentioned in the DSA RDF.
> 
> That looks really interesting for the harden packages. Especially for
> the harden-*flaws packages. It is probably a better approach than 
> uploading new harden-fooflaws everytime. Is it possible for your script
> to differentiate between local and remote flaws?
> 
> > The script is intended to be run as a normal user in a crontab, and thus
> > produces no output if the system is completely upto date.
> > 
> > You will need to install python2.2 and python2.2-xml prior to using the
> > script which can be found at
> > http://www.robster.org.uk/files/security-update-check.py
> > 
> > Any feedbacl/ideas would be much appreciated. I plan to make some minor
> > changes and package this up later this week :)
> 
> Maybe you want to have it in the harden-*flaws package or simply make
> these depend on your package. The later is maybe better.
> 
> Regards,
> 
> // Ola
> 
> > Cheers
> > 
> > Rob
> > -- 
> > Rob 'robster' Bradford
> > Founder: http://www.debianplanet.org/
> > Developer: http://www.debian.org/
> > Monkey with keyboard: http://www.robster.org.uk/
> 
> 
> 
> -- 
>  - Ola Lundqvist ---
> /  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
> |  [EMAIL PROTECTED] 584 36 LINKÖPING |
> |  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
> |  http://www.opal.dhs.org UIN/icq: 4912500 |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
>  ---
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Re: Improper NMU (Re: NMU for libquota-perl)

[Goswin Brederlow]

Elie Rosenblum <[EMAIL PROTECTED]> writes:

> On Mon, Sep 02, 2002 at 02:25:30AM +0100, Colin Watson wrote:
> > On Sun, Sep 01, 2002 at 09:19:17PM -0400, Elie Rosenblum wrote:
> > > On Mon, Sep 02, 2002 at 02:16:11AM +0100, Colin Watson wrote:
> > > > Technically it wasn't. The upload is still in the DELAYED queue, which
> > > > is really just a convenient automated way of saying "I'll NMU this
> > > > package in  days if I don't hear anything", with the added bonus of
> > > > allowing the maintainer to poke at it and see exactly what would go in
> > > > in the absence of a maintainer upload. I usually explain this when using
> > > > the delayed queue.
> > > 
> > > I assume you also submit a bug.
> > 
> > Quite.
> 
> Would you agree that performing an NMU without a BTS entry is wrong?
> 
> > > Do you generally do this without leaving a bug for a few days first?
> > 
> > In the case of the perl transition I've been given to understand by the
> > actions of other developers that the -devel-announce post on 31st July
> > was enough. Otherwise no.
> 
> I see.
> 
> Well, I disagree with this (as do I believe some others), but only
> in that no NMU should be done until the bug has existed for a few
> days (if nothing else, this addresses the distinct possibility of
> NMUs actually breaking stuff, which has already been brought up in
> this thread). I'm probably not going to convince you of this, any

The Bug existet since 31st July even if it wasn't formaly in the BTS
against your package.

> more than you will convince me that I'm wrong here. I have not,
> however, been hit with this general case...I've been hit with an
> irresponsible maintainer performing an NMU without submitting a
> bug at all, even if it was 5 minutes before he uploaded. This is
> just plain wrong, and something that can cause us really serious
> problems if people start to imagine that it's acceptable - 
> especially since we have little control over which keys can
> successfully upload any given package.

In the case of something so trivial as causing a recompile for a
problem that has been known for some time the warning given by the
delayed upload should be enough.

Do we realy need to mass-file bugreports for this? Thats the
alternative to mentioning something like the perl transition on -devel
and then fix it in a group effort some time afterwards.


You might have a point in general but not in this case.

Just my 2c of though, don't blame anyone else.
Goswin

Re: The harden-*flaws packages.

[Goswin Brederlow]

Daniel Martin <[EMAIL PROTECTED]> writes:

> Martin Schulze <[EMAIL PROTECTED]> writes:
> 
> Hrm.  The more I think about this the more I wonder if maybe the
> harden-*flaws packages make much sense in stable at all.  If someone
> is apt-get'ing from security.debian.org, they're already replacing
> vulnerable versions with fixed ones.  If someone is updating from a
> point release CD, the same thing applies.  The only case where I can
> see it making sense is with someone following testing with most of
> their packages on hold (they really want a stable system, and only
> upgrade a package when they need to).  Am I missing a scenario?

They should have stable as their distribution with highest priority
for apt. That includes security for stable.

On top of that the few packages they want more current can be
installed from woody or sid. No need to keep everything else on hold,
making stable first priority for apt should be enough.

And then they would get security updates.

MfG
Goswin

Re: Packages affected by removal of free mp3 players

[Goswin Brederlow]

Joe Drew <[EMAIL PROTECTED]> writes:

> If the worst does happen, and we need to remove all mp3 players from
> Debian, many packages will be affected. Most of these are because of

Why no non-free versions?

> their dependency on libsmpeg, which is the SDL MPEG audio and video
> decoder. Others depend on other MP3-playing libraries, such as libmad,
> mpeglib (which is named oddly), etc. (Please let me know if I've
> forgotten some.) A few packages depend on mpg321 as well - mostly
> front-ends.

"un" versions or "dummy" versions could be provided to make the
software work but not the mp3 features. Would be quite stupid for
mpg321 but for ogg it would make sense. People could then get a real
mp3lib from non-free or somewhere else and replace the "un" version
with that without recompile of the debs.

MfG
Goswin

Bug#159271: ITP: ogmtools -- Tools for handling Ogg media streams

[Marc Leeman]

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

* Package name: ogmtools
  Version : 0.901
  Upstream Author : Moritz Bunkus <[EMAIL PROTECTED]>
* URL : http://www.bunkus.org/videotools/ogmtools/
* License : GPL, LGPL, BSD, MIT/X, etc.
  Description : Tools for handling Ogg media streams


These tools allow information about (ogminfo) or extraction from
(ogmdemux) or creation of (ogmmerge) OGG media streams. 

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux mykene 2.4.19-xfs #1 Mon Aug 26 14:55:46 CEST 2002 i686
Locale: LANG=C, LC_CTYPE=C

Re: Java policy

[Ola Lundqvist]

Hi again.

I have not seen very much complains on the policy. Actually none
on fact.

So what further steps should I take in order to make this an
official policy?

On Sat, Aug 31, 2002 at 01:56:15PM +0200, Robert Bihlmeyer wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> writes:
> 
> > There are some things that might want to be added before it
> > becomes truly official.
> > 
> > See the policy at:
> > http://www.debian.org/doc/packaging-manuals/java-policy/
> > 
> > * gcj and how to handle that (should it be mentioned at all?).
> 
> I don't have the specifics to that handy. URL?

Somewhere in the [EMAIL PROTECTED] archives, do not remember.

> > * should all virtual machines that provides a java2 virtual machine
> >   also provide a 'java2' command (not 'java').
> 
> As the originator of this request, I'd be happy to have an "official"
> version without this and punt this to the next version.

Ok.

> > * How to handle jar dependencies? Should there be some kind of
> >   mechanism for that?
> 
> Since nobody is currently on top of that, I'd suggest leaving it out,
> too.

Agreed.

Regards,

// Ola

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Re: woody CD not bootable with adaptec + scsi-cdrom

[Andreas Metzler]

Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> Andreas Metzler <[EMAIL PROTECTED]> writes:
[...]
>> Goswin Brederlow <[EMAIL PROTECTED]> wrote:
[...] 
>>> I the discovered that the woody CD (linuxtag prerelease) doesn't
>>> boot. I heard of similar for the real woody release CDs on irc.
 
>>> Can anyone boot the CDs, which one of the set and what hardware?
[...]
>> I can boot from CD1, on a PentiumMMX-class machine (SiS 5591/5), an
>> iirc 1 year old Athlon 800 (VIA 133) and a 2 month old Duron1200
>> (VIA 266A).

> Who cares about your cpu?

Hello,
Nobody does, but mentioning CPU and mainboard chipset should give a
good idea how old the system was. (I do not know the exact dates, else
I would have mentioned them.)

> What cdrom? ide or scsi? What controler?

Sorry, all machines were IDE only.

>>> Also whats different between potato and woody?
 
>> potato used floppy-emulation, woody _CD1_ uses isolinux(??).

> That explains the difference in output. The floppy emulation shows up
> when the adaptec detects the bootable cdrom. Or is that unrelated?

Afaik no, my old computer's BIOS showed too whether it was using floppy
emulation.

[...]
>> If your computer cannot boot woody CD1 try CD2-CD7 - they use
>> floppy-emulation and should work on old computers.

> Good to know. Is that in the install docs somewhere?

Of course.

| 5.2 Booting from a CD-ROM
[...]
| CD #1
[...]
| If your hardware doesn't support booting of multiple images, put
| one of the other CDs in the drive. It appears that most SCSI CD-ROM
| drives do not support isolinux multiple image booting, so users
| with SCSI CD-ROMs should try either CD2 (vanilla) or CD3 (compact),
| or CD5 (bf2.4).

BTW it'd be nice if could respect Mail-Followup-To and did not cc me,
I would be very surprised if your MUA Gnus did not support this.
TIA, cu andreas
-- 
Unofficial _Debian-packages_ of latest _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

[PHP] Standard placement of PHP libraries?

[Matthew Palmer]

I guess this is probably going to turn into a mini-policy discussion, and I
hope so, because I think we need some level of standardisation.

There are several PHP extension libraries packaged for Debian; I guess the
most famous is probably pear, but I maintain one (phtml, used by some other
packages I maintain) and I know there are a couple of others out there, too.
By these libraries I'm not talking about binary modules, I'm talking about
extension libraries written in PHP and available by include('whatever'). 
It's the 'whatever' that I'm mostly interested in discussing for now.

PEAR uses /usr/share/pear, and has an entry in include_path for it.  Hence,
to use any PEAR-shipped function, simply refer to the file by name, relative
to that directory.  Nice, very simple, I highly approve.  Since PEAR holds a
special status, perhaps that should change.

But what about every other PHP extension library out there?  libphp-adodb,
for instance, uses /usr/lib/adodb - in violation of the FHS, I believe,
since PHP scripts shouldn't be architecture specific.  But that's not really
the issue here - the point is, where *should* PHP includes go?

I would like to propose /usr/share/php4 as the place for all scripts
intended to run under php4 (whatever subversion) and intended for inclusion
in other PHP scripts.  All packages would install their inclusion hierarchy
under /usr/share/php4/, and scripts which wanted to use their
functionality would include('/include.php').  Naming of
include files, including their extension, would be left to the discretion of
individual maintainers.

The bonus would be that the php4 maintainer would only have to add one
(fairly self-explanatory) directory entry to php4.ini for all time, no other
package would have to worry about modifying php4.ini or getting the user to
do so (BTDT, not much fun).

I can't see any real downsides, as long as everybody plays along.  I'd like
to know of any that anyone can think of.  If there are no objections, and
anyone else thinks it's a worthwhile idea, I'll put my thoughts into a
formal proposal to Policy, for official comment.  I'd rather get shot down
in flames now than get my hopes up.


-- 
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org

Re: Improper NMU (Re: NMU for libquota-perl)

[Sebastian Rittau]

On Sun, Sep 01, 2002 at 09:06:20PM -0400, Elie Rosenblum wrote:

> The NMU was made before I was in any way contacted.

Would you please stop bitching, you're getting on my nerves. Except you
nearly nobody sees this as a problem. If you're not able to maintain
your packages properly and in a timely manner, and your holding up a
major part of the distribution, it's your fault. The was no harm done,
it was pointed out several times how you can prevent the NMU'ed package
from entering unstable, so you have absolutely no point.

Remember: You're just the package maintainer. The package does not belong
to you and it's not "yours" by any means.

 - Sebastian

[PHP] Placement of PHP programs?

[Matthew Palmer]

As a kind of an adjunct to the other discussion on PHP libraries, what about
PHP programs?  Not quite so touchy, as I can't see a single way forward here
(and there's no blazingly obvious reason to do so).  So what are people's
best thoughts on the matter?  Most packages I've seen put their
web-accessible content in /usr/share/, then either set up a
separate apache config and include it from the main apache config
(phpgroupware does it this way, for one example) while other packages modify
apache.conf more intrusively.  I'm a fan of the phpgroupware method, which
at least minimises pain.

So where to put the program itself?  /usr/share is the common place, I guess
that's the place to go.  Does anyone think there's another good place, and
has a reason for it?  Config should, of course, go in /etc/,
including (if appropriate) the apache config to allow apache to find it.

But what if people are using a different Web server?  It's possible, so why
are we blindly assuming apache?  Should we cater for the default, and anyone
doing differently should know enough to fix the problem themselves?  That's
a possibility.

And what about where in the docroot we put our program for accessability? 
Right in the docroot might squash something already there.  How about
letting the user choose?  Ooh, there's something that could start a hornet's
nest.  Check if something's already there - but how do we do that?  ls
/var/www/ *might* work, grep '/'
/etc/apache/*.conf would help too.  We'd probably find most cases between
those two checks.

Anyway, I want to know your thoughts.  Please share.

-- 
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org

RFC: A regression test framework for Debian packages?

[Jérôme Marant]

One year ago, Martin Michlmayr made a speach at the Debian
Conference 1 about Quality Assurance within Debian and the
progress that have been made so far.
He mentioned that we lack regression tests for packages,
but as far as I know, no solution has been found.

What are regression tests?
--

  Regression tests are tests that are made to ensure that 
  the behaviour of a given program has not changed across
  releases.

Why?


  Currently, we have some way to check a package before it
  gets installed. That is what Lintian (and Linda as well ;-)
  is here for: checks are performed on the content of the
  binary and source package.

  However, we have no way to check a package after its
  installation. And in most of the cases, Lintian checks
  cannot prevent software breakages.

  Until now, developers need to test packages manually:
  installation, upgrade, removal, purge, failures and so on.
  This can be very painful and boring when you have different
  ways to configure your packages, especially when they
  have to be configured through debconf.
  Furthermore, some packages may perform some complex
  tasks like database creation/upgrades, web server configuration,
  mail aliases management, etc and user configuration and
  environment may vary, making the success of such tasks
  unpredictable.

What?
-

  The main idea is to make tests on package installation
  and after their installation is completed.

  Here is a list of possible tests that come to my mind
  (in no special order):

  - tests on maintainer scripts: maintainer scripts perform
  some very simple tasks like: changing ownerships and
  permissions, starting daemons, creating users/groups, etc.
  They are likely to change across releases, and as they
  are mostly written in shell, they are error prone.

  This could be as complex as checking that a database has
  been properly configured, that a LDAP directory has been
  properly populated, that a web server has been correctly
  modified.

  - debconf tests: there are usually many possible answer
  to debconf question and different paths within. Some
  tests can be written to simulate user interaction, providing
  a broader set of configuration answer. Checks would be
  made with respect to some given answers.

  - configuration files tests: some behaviours may vary with
  respect to configuration options. Tests would provide
  a set of configuration files and their matching expected
  behaviour.

  - application-specific tests: sometimes Debian customize
  applications and we may want to see if nothing has been
  broken.

  - ...

How?


  In a chrooted environment, we can install deboostrap and
  package dependencies through APT.

  Then, we need some program that would execute some simple
  scripts in a pseudo language (for safety purpose, tests must
  be error prone as much as possible) describing what tests have
  to be performed, and how they would be performed.

  This is only a short summary :-)

Do we need this?
-

  Although this may look boring for small packages, I have
  many reasons to think that this can be usefull for complex
  packages. We can imagine running such test overnight for
  packages maintained via CVS.


Comments are welcome.

Thanks.

Cheers,

PS: Please, no CC on reply, I'm subscribed to the list.

-- 
Jérôme Marant

Re: Improper NMU (Re: NMU for libquota-perl)

[Tomas Pospisek's Mailing Lists]

On Mon, 2 Sep 2002, Sebastian Rittau wrote:

> Remember: You're just the package maintainer. The package does not belong
> to you and it's not "yours" by any means.

Oh, I think you are very mistaken. It is not his in the sense that it's
under GPL. But it's his in the sense that since he is its official
maintainer others should respect that.

And as is the case in the GPL world - everybody is free to fork his
package and maintain his own, if he thinks some maintainer is not doing
his work or refusing to let someone else do it in a better way.

This being said I'm not refering here to the quality of anybody's work nor
to what has been discussed in this thread here - just to the basic
principle.
*t

--
---
 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11
---

Re: Improper NMU (Re: NMU for libquota-perl)

[Raphael Hertzog]

Le Mon, Sep 02, 2002 at 12:20:22AM -0400, Elie Rosenblum écrivait:
> Would you agree that performing an NMU without a BTS entry is wrong?

Nope.

The strict minimum is :
- create a patch for the NMU
- make the patch available to the maintainer (via direct mail or bts)

If you upload the package to DELAYED, it is enough to respect the spirit
of the NMUs guidelines (which are in developers-reference).

BTW, the developers-reference evolved quite a bit since the good old
days, and the DELAYED stuff is mentionned in the NMU guidelines...
please read it again.

http://www.debian.org/doc/manuals/developers-reference/index.en.html

> I've been hit with an
> irresponsible maintainer performing an NMU without submitting a
> bug at all, even if it was 5 minutes before he uploaded.

This is ridiculous. An NMU is not a punishment for bad maintainers,
it's an offer of help to help you catch up in your Debian work.

No one should be offended by an NMU.

> especially since we have little control over which keys can
> successfully upload any given package.

You want respect for yourself, you don't want to be treated like
an "irresponsible maintainer", but you show absolutely no respect to
people who are doing NMUs to help you.

Think about it, people doing NMUs are other Debian developers like you 
who take their free time to help you, and look how you thank them.

Even if he made a mistake, it's not a big one, the upload was to
DELAYED, the package has not yet been installed, you have a chance
to dump the NMU by uploading your own fix.

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: Improper NMU (Re: NMU for libquota-perl)

[Martin Wheeler]

On Mon, 2 Sep 2002, Sebastian Rittau wrote:

>  If you're not able to maintain
> your packages properly and in a timely manner, and your holding up a
> major part of the distribution, it's your fault.

I'm interested in this.
Individuals differ greatly in their working methods.
So what is considered: "in a timely manner"?  (Seriously.)

I have dropped out of several co-operative projects in the past simply
because I'm a relatively "slow" worker -- i.e. I don't tend to give three
or four fast responses to collective development _in the same day_.
I find that sort of speed of progression highly de-motivating.
Am I alone in this?  (I might take up to a week to respond to any
particular event -- this is normal for _me_.)

I'm curious as to what the expectations of other debian-developers are --
for example, does not being online 24/7 -- or even once a day --
effectively create a barrier to participation in collective development
projects in debian?  (Theory would say: No.  But what does _practical_
experience dictate?)

So I guess my question really is: what is "timely"; and what is
"untimely"?
Where is it defined?  By whom?  Does it make sense?

Just curious.

msw
-- 
Martin Wheeler   -StarTEXT - Glastonbury - BA6 9PH - England
[EMAIL PROTECTED]http://startext.demon.co.uk/
GPG pub key:8D6B948B  ECC6 D98E 4CC8 60E3 7E32  D594 BB27 3368 8D6B 948B
 - Share your knowledge. It's a way of achieving immortality. -

Re: Improper NMU (Re: NMU for libquota-perl)

[Martin Wheeler]

On Mon, 2 Sep 2002, Raphael Hertzog wrote:

> This is ridiculous. An NMU is not a punishment for bad maintainers,
> it's an offer of help to help you catch up in your Debian work.
>
> No one should be offended by an NMU.

 ... and might I add, that in the case of documentation, it should be
actively sought after?   (From each and every reader?)

That is, insofar as text presentation (grammar; syntax; orthography;
punctuation; etc.) is concerned; factual content of the text should be
subject to discussion with the author[s] of the documentation.  Although
when information given is plain wrong, or out of date, I'm all in favour
of instantaneous amendment by the reader without reference to the author.
(I speak in knowledge of cause; I'm guilty of not updating out-of-date
information myself in most documents I maintain.)

In this respect, maintainership of documentation is vastly different to
maintainership of code; but the basic principle of intervention to
*help* (and not obliquely castigate), holds true.

msw
-- 
Martin Wheeler   -StarTEXT - Glastonbury - BA6 9PH - England
[EMAIL PROTECTED]http://startext.demon.co.uk/
GPG pub key:8D6B948B  ECC6 D98E 4CC8 60E3 7E32  D594 BB27 3368 8D6B 948B
 - Share your knowledge. It's a way of achieving immortality. -

Re: RFC: A regression test framework for Debian packages?

[Jamie Wilkinson]

This one time, at band camp, Jérôme Marant wrote:
>  In a chrooted environment, we can install deboostrap and
>  package dependencies through APT.

About 6 months ago I started writing some code in expect to do just this, to
test my quake2-data installer package.  I was able to install the package
into an UML machine, answer the debconf questions, and check the location of
the installed files (being an installer package, not all files installed by
the package are in the deb).

I haven't touched this code for a long time, but I've been meaning to clean
it up and start doing regression testing on parts of the archive.  I envisage
being able to run it once a week on the entire archive, testing the
ability of every pacakge to cleanly upgrade from woody to sarge, and back
again.

-- 
[EMAIL PROTECTED]   http://spacepants.org/jaq.gpg

Re: Improper NMU (Re: NMU for libquota-perl)

[Glenn Maynard]

On Mon, Sep 02, 2002 at 09:32:42AM +, Martin Wheeler wrote:
> I have dropped out of several co-operative projects in the past simply
> because I'm a relatively "slow" worker -- i.e. I don't tend to give three
> or four fast responses to collective development _in the same day_.
> I find that sort of speed of progression highly de-motivating.
> Am I alone in this?  (I might take up to a week to respond to any
> particular event -- this is normal for _me_.)

I treat mailing list discussions as a lagged IRC conversation--when I
see a message, time permitting, I reply to it.  If I'm actively working
on a project, I'm generally monitoring related lists, so I don't have a
problem with any number of replies a day.

I don't expect the same from all developers (especially when time zones,
sleeping habits and employment cause us to be active on lists at different
times of day), but when I'm being forced-delayed pending a discussion,
having less than an interaction a day is frustrating.  A week would
probably drive me away from a project completely, at least for active
development.

If, by the time I get a reply, I've forgotton that I was waiting for
one--a couple days--it's no longer a cohesive discussion, in my mind, but
a series of related but disconnected emails.

-- 
Glenn Maynard

Re: Improper NMU (Re: NMU for libquota-perl)

[Mark Brown]

On Mon, Sep 02, 2002 at 09:16:24AM +0200, Goswin Brederlow wrote:

> In the case of something so trivial as causing a recompile for a
> problem that has been known for some time the warning given by the
> delayed upload should be enough.

While a recompile *should* be trivial they still have the potential to
break things.

For example, I'm currently in the middle of preparing a NMU for a
package.  As in this case the NMU involves no code changes (a tweak to
the control file is all) but unfortunately a simple recompile of the
package produces binaries that fail to work.  This is unquestionably a
bug in the package but it's not something that would have been shown up
if someone simply rebuilt without properly testing.

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

Re: Improper NMU (Re: NMU for libquota-perl)

[Raphael Hertzog]

Le Mon, Sep 02, 2002 at 09:32:42AM +, Martin Wheeler écrivait:
> Individuals differ greatly in their working methods.
> So what is considered: "in a timely manner"?  (Seriously.)

In this case, it is "several weeks" since the first announce of the perl
5.8 update.

And we don't have a generic response, it depends on the package you
maintain and so on. If you just uploaded dpkg with a very annoying bug,
it would be almost unacceptable to disappear for a full week. For a
secondary package it doesn't matter...

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: [PHP] Placement of PHP programs?

[Fabien Penso]

Matthew a écrit : 

 > As a kind of an adjunct to the other discussion on PHP libraries, what about
 > PHP programs?  Not quite so touchy, as I can't see a single way forward here
 > (and there's no blazingly obvious reason to do so).  So what are people's
 > best thoughts on the matter?  Most packages I've seen put their
 > web-accessible content in /usr/share/, then either set up a
 > separate apache config and include it from the main apache config
 > (phpgroupware does it this way, for one example) while other packages modify
 > apache.conf more intrusively.  I'm a fan of the phpgroupware method, which
 > at least minimises pain.

Shouldn't webpage go to /var/www or at least /var/, and _not_ /usr/share
? We are talking about PHP, but it's still webpages after all.

The apache configuration should go into a separate file in /etc/apache/
which would be included in httpd.conf later; easier to modify I guess.

The software configuration should stay into the its location, the
software directory.

-- 
Fabien Penso <[EMAIL PROTECTED]> | LinuxFr a toujours besoin de :
http://perso.LinuxFr.org/penso/  | http://linuxFr.org/dons/
A PHP Template Engine ? Take the best ! http://templeet.org/


pgpmL8cOmeRRY.pgp
Description: PGP signature

Re: RFC: A regression test framework for Debian packages?

[Junichi Uekawa]

On Mon, 2 Sep 2030 11:20:05 +0200

> How?
> 
> 
>   In a chrooted environment, we can install deboostrap and
>   package dependencies through APT.
> 
>   Then, we need some program that would execute some simple
>   scripts in a pseudo language (for safety purpose, tests must
>   be error prone as much as possible) describing what tests have
>   to be performed, and how they would be performed.
> 
>   This is only a short summary :-)

pbuilder has hooks to provide such checkings.


regads,
junichi

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

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Dmitry Borodaenko]

On Fri, Aug 30, 2002 at 01:42:26PM +0200, Richard Atterer wrote:
 RA> As usual Heise got it right:
 RA>  (German).

c't is a good info source, but this time they seem biased. First of all,
they completely miss the point that you made below:

 RA> Thomson tolerate violations against their license are far as
 RA> *de*coders are concerned. <...> However, such a statement is not
 RA> enough for us to keep MP3 decoders in the distribution, I'm afraid.

Next, their take on Ogg smells FUD:

   It is not a good idea as yet to rely exclusively on Ogg Vorbis,
   however: Even if Ogg Vorbis manages to close the quality gap between
   it and MP3 or even manages to get ahead of the latter, it will still
   take some time before Ogg-capable portable players make their
   appearance as hardware.

IFAIK (IANA Musician) Ogg Vorbis outmatches quality of MP3 for quite
some time. The hardware issue is indeed present, there is no free
fixed-point Vorbis decoder yet, but there is proprietary one, which
matches situation with hardware MP3 players that require loyalty fee.

If I'm not missing something and there is no other obstacles to adoption
of Ogg Vorbis save for inertia, the above sentence is just that, FUD.

-- 
Dmitry Borodaenko

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Dmitry Borodaenko]

On Fri, Aug 30, 2002 at 04:55:24PM +0200, Robert Millan wrote:
 RM> we definitely need an mp3 decoder in debian if we want to fight the
 RM> patent oppression at all. i think we need another branch for that
 RM> kind of problems.

Debian/liberty in APT over FreeNet, anyone?

-- 
Dmitry Borodaenko

Re: RFC: A regression test framework for Debian packages?

[Jérôme Marant]

On Mon, Sep 02, 2002 at 08:19:19PM +0900, Junichi Uekawa wrote:
> On Mon, 2 Sep 2030 11:20:05 +0200
> 
> > How?
> > 
> > 
> >   In a chrooted environment, we can install deboostrap and
> >   package dependencies through APT.
> > 
> >   Then, we need some program that would execute some simple
> >   scripts in a pseudo language (for safety purpose, tests must
> >   be error prone as much as possible) describing what tests have
> >   to be performed, and how they would be performed.
> > 
> >   This is only a short summary :-)
> 
> pbuilder has hooks to provide such checkings.

Good, this is a good place to do such test IMO, I'll have a deeper
look at it.

Thanks. 

-- 
Jérôme Marant

Re: Some proposals about the Email-subsystem, was Re: RFC: OpenLDAP and TLS/SSL

[Javier Fernández-Sanguino Peña]

On Sun, Aug 25, 2002 at 02:56:46PM +1000, Martijn van Oosterhout wrote:
> On Sat, Aug 24, 2002 at 10:10:24PM -0600, Georg Lehner wrote:
> > Hello!
> > 
> > El sáb, 24-08-2002 a las 17:28, Martijn van Oosterhout escribió:
> > ...
> > > > Proposal: By default no MTA will be installed.
> > > 
> > > Umm, this may sound silly, but how will you do local delivery if there is 
> > > no
> > > MTA installed?
> > ...
> > 
> > Not silly.  MDA's like procmail can do local delivery standalone.
> > Obviously no queue needed.
> 
(..)
> What I'm saying is that to must have a mail-server install, even if it is
> just ssmtp or something like that.

Yes, however the mail server should not be running as a daemon nor
listening for incoming port 25 connections.

> 
> I hope this is clearer.

Yes.

Javi

Re: shouldn't root.adm , -rw-r----- , be policy for all non-public log files?

[Javier Fernández-Sanguino Peña]

On Mon, Aug 26, 2002 at 06:13:30PM +0200, Joost van Baal wrote:
> Hi,
> 
> I maintain the Lire package, which processes log files from e.g.
> sendmail, bind, apache, boa and lots of other services.  I don't want to
> run any Lire processes as root.  However, of course, the processes need

Which is quit sensible on your behalf.

> read access to log files.  Unfortunately, there seems to be no rule or
> policy on how access permissions for log files should be.  Wouldn't it
> be nice if all non-public log files were owned by group `adm', and
> groupreadable?  (World readability for public log files is fine too, of
> course.)  Currently, this is the case for quite a lot of commonly found
> log files.


I recently added a FAQ item in the "Securing Debian Manual" 
(http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.1)

AFAIK there is no policy regarding log files, however, there *should* be one.

> 
(...)
> , although similar issues were raised, no conclusion seems to have been
> reached on this specific subject (other than "adm is to read logs".)
> 
If so then policy should tell package maintainers to create logs
as root.adm or package_user.adm. IMHO the problem should be fixed by clarifying 
the
policy and having it written down. How about submitting a policy proposal?

Regards

Javi

Re: Security notification script

[Javier Fernández-Sanguino Peña]

On Mon, Sep 02, 2002 at 08:58:43AM +0200, Ola Lundqvist wrote:
> Hi again,
> 
> I'm I right when I say that this script only can follow the
> DSA:s that cover woody? It is nice but I would really like a
> version that can handle sid too. :) It would be some
> more text processing but I think it is doable.
> 

There are no DSAs for sids.. 

Javi

Re: Security notification script

[Javier Fernández-Sanguino Peña]

On Mon, Aug 26, 2002 at 09:31:34PM +0100, Rob Bradford wrote:
> I have written a python script that allows you to compares locally
> installed  packages with those on security.debian.org. Furthermore it
> provides a description of the problem/DSA name if the package is
> mentioned in the DSA RDF.
> 
Notice that the RDF does not include *all* the DSAs, just the latest
(10?). Thus, if there is a week with *many* security updates your script might
miss vulnerable packages if not run daily.

> The script is intended to be run as a normal user in a crontab, and thus
> produces no output if the system is completely upto date.
> 
> You will need to install python2.2 and python2.2-xml prior to using the
> script which can be found at
> http://www.robster.org.uk/files/security-update-check.py
> 

Why Python? If you plan this script to be included in Debian-standard (such
as the cron task in checksecurity) python is out of the question. 
Could you write it in Perl? 

> Any feedbacl/ideas would be much appreciated. I plan to make some minor
> changes and package this up later this week :)
> 

Well, it's already done. Check out Tiger: 
http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s-keep-up-to-date
The problem with Tiger is that it has to be updated (both by the maintainer and 
the
administrator) to work effectively until a create a 'tiger-signatures' package 
that
can be updated regularly. 

But probably a stand-alone script is a good idea, it would appreciate it better
in another language. You cannot consider installing python in a production
environment where it's not really need it. Tiger, for example, is completely
shell-based (does not even need Perl).

Regards

Javi


pgpjgOEwiMxk7.pgp
Description: PGP signature

Re: Security notification script

[Ola Lundqvist]

On Mon, Sep 02, 2002 at 02:00:21PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Mon, Sep 02, 2002 at 08:58:43AM +0200, Ola Lundqvist wrote:
> > Hi again,
> > 
> > I'm I right when I say that this script only can follow the
> > DSA:s that cover woody? It is nice but I would really like a
> > version that can handle sid too. :) It would be some
> > more text processing but I think it is doable.
> > 
> 
> There are no DSAs for sids.. 

Well there are no DSA for sid but in the DSA released for potato,
woody (and sarge?) unstable packages is mentioned. That is at least
true for the latest DSA:s.

See for example: http://www.debian.org/security/2002/dsa-159

"... For the unstable distribution (sid) this has been fixed in version
1.5.2-24 of Python 1.5, in version 2.1.3-6a of Python 2.1 and in version
2.2.1-8 of Python 2.2. Python 2.3 is not affected by this problem..."

Yes it is in the text but it would be really nice to parse this kind
of stuff.

Regards,

// Ola

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

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Re: RFC: A regression test framework for Debian packages?

[Jérôme Marant]

On Mon, Sep 02, 2002 at 08:19:23PM +1000, Jamie Wilkinson wrote:
> This one time, at band camp, Jérôme Marant wrote:
> >  In a chrooted environment, we can install deboostrap and
> >  package dependencies through APT.
> 
> About 6 months ago I started writing some code in expect to do just this, to
> test my quake2-data installer package.  I was able to install the package
> into an UML machine, answer the debconf questions, and check the location of
> the installed files (being an installer package, not all files installed by
> the package are in the deb).
> 
> I haven't touched this code for a long time, but I've been meaning to clean
> it up and start doing regression testing on parts of the archive.  I envisage
> being able to run it once a week on the entire archive, testing the
> ability of every pacakge to cleanly upgrade from woody to sarge, and back
> again.

Nice! How does it work exactly? How do you write tests? Do you have scenarii
or something?

-- 
Jérôme Marant

Re: RFC: A regression test framework for Debian packages?

[Junichi Uekawa]

On Mon, 2 Sep 2030 13:51:42 +0200
(B
(B
(B> > >   This is only a short summary :-)
(B> > 
(B> > pbuilder has hooks to provide such checkings.
(B> 
(B> Good, this is a good place to do such test IMO, I'll have a deeper
(B> look at it.
(B
(B
(BCurrently I only have: 
(B$ ls -l pbuilder-script/
(B-rwxr-xr-x1 dancer   dancer 96  6$B7n(B 20 13:44 B90linda
(B
(B
(Bwhich runs B90linda script when build succeeds, which does:
(B
(B#!/bin/bash
(B# run linda on generated deb files
(Bapt-get install -y linda
(Blinda /tmp/buildd/*.deb
(B
(B
(B
(Band I've been running this through all of archive for a while now.
(B
(B
(Bregards,
(Bjunichi
(B
(B
(B-- 
(B[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer

Re: Improper NMU (Re: NMU for libquota-perl)

[Andrew Suffield]

On Mon, Sep 02, 2002 at 09:32:42AM +, Martin Wheeler wrote:
> On Mon, 2 Sep 2002, Sebastian Rittau wrote:
> 
> >  If you're not able to maintain
> > your packages properly and in a timely manner, and your holding up a
> > major part of the distribution, it's your fault.
> 
> I'm interested in this.
> Individuals differ greatly in their working methods.
> So what is considered: "in a timely manner"?  (Seriously.)

"Before somebody else is sufficiently motivated to do it".

I see no point in holding it against somebody if they don't fix it
first - as long as either somebody fixes it, or nobody cares, why does
it matter?

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


pgpbmRjrFdgxe.pgp
Description: PGP signature

Re: Security notification script

[Ola Lundqvist]

On Mon, Sep 02, 2002 at 02:07:34PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Mon, Aug 26, 2002 at 09:31:34PM +0100, Rob Bradford wrote:
> > I have written a python script that allows you to compares locally
> > installed  packages with those on security.debian.org. Furthermore it
> > provides a description of the problem/DSA name if the package is
> > mentioned in the DSA RDF.
> > 
>   Notice that the RDF does not include *all* the DSAs, just the latest
> (10?). Thus, if there is a week with *many* security updates your script might
> miss vulnerable packages if not run daily.

That is a good point. Is it possible to get this kind of information from
elsewhere (yes it is possible to dig it out of the html-pages) in a
similar (easy) manner?

> > The script is intended to be run as a normal user in a crontab, and thus
> > produces no output if the system is completely upto date.
> > 
> > You will need to install python2.2 and python2.2-xml prior to using the
> > script which can be found at
> > http://www.robster.org.uk/files/security-update-check.py
> > 
> 
> Why Python? If you plan this script to be included in Debian-standard (such
> as the cron task in checksecurity) python is out of the question. 
> Could you write it in Perl? 

Well I do not think it is suitable for standard (yet). It is a little bit
too non-mature for that. But I could rewrite his (I'm not the author) code
into perl if that is really needed.

But of course it should be better to write it in shell-code but that is
not that easy as to use xml interfaces within perl or python.

> > Any feedbacl/ideas would be much appreciated. I plan to make some minor
> > changes and package this up later this week :)
> > 
> 
> Well, it's already done. Check out Tiger: 
> http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s-keep-up-to-date
> The problem with Tiger is that it has to be updated (both by the maintainer 
> and the
> administrator) to work effectively until a create a 'tiger-signatures' 
> package that
> can be updated regularly. 

It is about the same problem as harden-*flaws.

> But probably a stand-alone script is a good idea, it would appreciate it 
> better
> in another language. You cannot consider installing python in a production
> environment where it's not really need it. Tiger, for example, is completely
> shell-based (does not even need Perl).

Good point.

Regards,

// Ola

>   Regards
> 
>   Javi



-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Re: Improper NMU (Re: NMU for libquota-perl)

[Andrew Suffield]

On Sun, Sep 01, 2002 at 12:42:20PM -0400, Elie Rosenblum wrote:
> On Sun, Sep 01, 2002 at 06:37:52PM +0200, Bas Zoetekouw wrote:
> > Hi Elie!
> > 
> > You wrote:
> > 
> > > Why did you NMU this instead of submitting a bug?
> > > This is inappropriate.
> > 
> > Well, it's the intent of a bug squashing party to _decrease_ the number
> > of RC bugs, not to increase it. Also, we're trying to get the perl
> > transition done this weekend. 
> > Of course, I could've mailed you beforehand, but the fix is trivial, so
> > I didn't really see the need for that.
> > 
> > > I maintain several perl libraries, and it would be easier if I just did
> > > them all at once.
> > 
> > Which you can still do. I uploaded to DELAYED, so sooner uploads will
> > be prefered by the installer.
> 
> I also don't see a bug submitted with this. If you're submitting
> NMU's, you sure as hell better be submitting bugs with patches (or
> the fact that no patch is required other than rebuilding with an
> updated system).

The latter is the case here - the only changes are those clearly
documented in the mails to debian-perl and debian-devel-announce,
specifically:
 - The usual changelog entry
 - Increase of the version for perl in Build-Depends to >= 5.8.0

All maintainers are supposed to be subscribed to -devel-announce, so
you must have received the mail warning you this would happen quite
some time ago.

> Please delete your uploads.

There's no need. DELAYED exists for precisely this purpose. An upload
to DELAYED says this:

"I have built this fix, and it will be NMUed in X days unless you
upload something first".

If you upload a fixed package before the time runs out, then the
version of the package in DELAYED will be lower than the one in the
pool, so the upload will be rejected.

If you don't, the package is fixed anyway by the NMU.

Either way, everybody wins. The whole point of DELAYED is (AIUI) to
allow this kind of upload, where the maintainer has advance
notification and a chance of override it, but if they don't then the
new package will go into the pool.

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


pgpZRaydU8uZy.pgp
Description: PGP signature

Re: RFC: A regression test framework for Debian packages?

[Jamie Wilkinson]

This one time, at band camp, Jérôme Marant wrote:
>On Mon, Sep 02, 2002 at 08:19:23PM +1000, Jamie Wilkinson wrote:
>> This one time, at band camp, Jérôme Marant wrote:
>> >  In a chrooted environment, we can install deboostrap and
>> >  package dependencies through APT.
>> 
>> About 6 months ago I started writing some code in expect to do just this, to
>> test my quake2-data installer package.  I was able to install the package
>> into an UML machine, answer the debconf questions, and check the location of
>> the installed files (being an installer package, not all files installed by
>> the package are in the deb).
>> 
>> I haven't touched this code for a long time, but I've been meaning to clean
>> it up and start doing regression testing on parts of the archive.  I envisage
>> being able to run it once a week on the entire archive, testing the
>> ability of every pacakge to cleanly upgrade from woody to sarge, and back
>> again.
>
>Nice! How does it work exactly? How do you write tests? Do you have scenarii
>or something?

The expect script starts up a user-mode-linux on a pre-built chroot, and
then attempts to install the package in it.  If that succeeds, it tries to
purge it.  Testing an upgrade/downgrade requires a trivial bit of hacking in
the script.  Debconf questions/answers are read from a file, the questions
are watched for in the console output.

It's horridly inefficient, though---I chose uml over chroot because I wanted
ordinary users to be able to run it.

-- 
[EMAIL PROTECTED]   http://spacepants.org/jaq.gpg

Re: Improper NMU (Re: NMU for libquota-perl)

[Junichi Uekawa]

On Sun, 1 Sep 2002 19:14:37 +0200
Raphael Hertzog <[EMAIL PROTECTED]> wrote:

> > I also don't see a bug submitted with this. If you're submitting
> > NMU's, you sure as hell better be submitting bugs with patches (or
> > the fact that no patch is required other than rebuilding with an
> > updated system).
> 
> The NMUer has to send the patch of the NMU to the maintainer, either
> through the BTS or directly, yes.

Please use the BTS for tracking patches.
It's often very hard to track, and NMUs do get lost.


regards,
junichi

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

Re: The harden-*flaws packages.

[Javier Fernández-Sanguino Peña]

On Mon, Sep 02, 2002 at 08:47:53AM +0200, Ola Lundqvist wrote:
> 
> Yes. Luckily I just saw someone that have written a script that checks
> the DSA:s and tell the maintainer that he/she has a vulnerable package.
> That is a good solution (best?). The problem is that the DSA is 
> not able to distinguish between local/remote/3rdparty flaws but
> that is not always interesting.

Why duplicate the work the Tiger package is already doing? I do not see the 
merit
of checking *only* for DSAs published in the RDF file (since that RDF file is
limited to a few DSAs only).

If you want a program to check for security flaws please use one designed for 
that
precisely. Tiger is such a program. Just have the *flaws package recommend: or
depend: on tiger.

Of course, there is room for improvement, the DSAs could be parsed from the WML
source to retrieve both the description *and* wether it's a local or remote 
issue
and populate the report accordingly (it currently just checks against version
packages) *also* we could provide MD5sums of know vulnerable packages (in the
stable distribution and proposed-updates).

Also, this information needs to be splitted off the package so it can work like
antivirus updates. Thus, signature updates could go to proposed-updates without
needing to update the program itself.

Regards

Javi

Re: RFC: A regression test framework for Debian packages?

[Jérôme Marant]

On Mon, Sep 02, 2002 at 10:42:32PM +1000, Jamie Wilkinson wrote:
> >Nice! How does it work exactly? How do you write tests? Do you have scenarii
> >or something?
> 
> The expect script starts up a user-mode-linux on a pre-built chroot, and
> then attempts to install the package in it.  If that succeeds, it tries to
> purge it.  Testing an upgrade/downgrade requires a trivial bit of hacking in
> the script.  Debconf questions/answers are read from a file, the questions
> are watched for in the console output.
> 
> It's horridly inefficient, though---I chose uml over chroot because I wanted
> ordinary users to be able to run it.

Thanks.

-- 
Jérôme Marant

Re: RFC: A regression test framework for Debian packages?

[Jérôme Marant]

On Mon, Sep 02, 2002 at 09:27:27PM +0900, Junichi Uekawa wrote:
> On Mon, 2 Sep 2030 13:51:42 +0200
> 
> 
> > > >   This is only a short summary :-)
> > > 
> > > pbuilder has hooks to provide such checkings.
> > 
> > Good, this is a good place to do such test IMO, I'll have a deeper
> > look at it.
> 
> 
> Currently I only have: 
> $ ls -l pbuilder-script/
> -rwxr-xr-x1 dancer   dancer 96  6$B7n(B 20 13:44 B90linda
> 
> 
> which runs B90linda script when build succeeds, which does:
> 
> #!/bin/bash
> # run linda on generated deb files
> apt-get install -y linda
> linda /tmp/buildd/*.deb
> 
> 
> 
> and I've been running this through all of archive for a while now.

Thanks.

-- 
Jérôme Marant

Re: Packages affected by removal of free mp3 players

[Joe Drew]

On Mon, 2002-09-02 at 03:23, Goswin Brederlow wrote:
> Joe Drew <[EMAIL PROTECTED]> writes:
> 
> > If the worst does happen, and we need to remove all mp3 players from
> > Debian, many packages will be affected. Most of these are because of
> 
> Why no non-free versions?

Non-free versions aren't in Debian, and so "removal" doesn't really
affect them. However, for free packages, "Removal" could be moving them
to non-free or contrib, which notwithstanding Branden's thoughts is
still a possibility.

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

"This particular group of cats is mostly self-herding." -- Bdale Garbee

Re: [PHP] Placement of PHP programs?

[Henrique de Moraes Holschuh]

On Mon, 02 Sep 2002, Fabien Penso wrote:
>  > As a kind of an adjunct to the other discussion on PHP libraries, what 
> about
>  > PHP programs?  Not quite so touchy, as I can't see a single way forward 
> here
>  > (and there's no blazingly obvious reason to do so).  So what are people's
>  > best thoughts on the matter?  Most packages I've seen put their
>  > web-accessible content in /usr/share/, then either set up a
>  > separate apache config and include it from the main apache config
>  > (phpgroupware does it this way, for one example) while other packages 
> modify
>  > apache.conf more intrusively.  I'm a fan of the phpgroupware method, which
>  > at least minimises pain.

This is probably the best way to do it.

> Shouldn't webpage go to /var/www or at least /var/, and _not_ /usr/share
> ? We are talking about PHP, but it's still webpages after all.

Don't you dare stuff my /var up with constant, non-arch-specific, program
text that should be in /usr in the first place :)

Hint: the fact it is in php4 makes it no more special than anything else.

> The software configuration should stay into the its location, the
> software directory.

As long as this is outside the exported "url-space" of the program.  The
braindamage has to be stopped somewhere...

-- 
  "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: The harden-*flaws packages.

[Ola Lundqvist]

Hi

On Mon, Sep 02, 2002 at 03:09:28PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Mon, Sep 02, 2002 at 08:47:53AM +0200, Ola Lundqvist wrote:
> > 
> > Yes. Luckily I just saw someone that have written a script that checks
> > the DSA:s and tell the maintainer that he/she has a vulnerable package.
> > That is a good solution (best?). The problem is that the DSA is 
> > not able to distinguish between local/remote/3rdparty flaws but
> > that is not always interesting.
> 
> Why duplicate the work the Tiger package is already doing? I do not see the 
> merit
> of checking *only* for DSAs published in the RDF file (since that RDF file is
> limited to a few DSAs only).

Well my thought was to check for all DSA:s which apparently this script do not.

> If you want a program to check for security flaws please use one designed for 
> that
> precisely. Tiger is such a program. Just have the *flaws package recommend: or
> depend: on tiger.

On the other hand tigher does a lot of other things too. But the link
you gave me was very interesting.

> Of course, there is room for improvement, the DSAs could be parsed from the 
> WML
> source to retrieve both the description *and* wether it's a local or remote 
> issue
> and populate the report accordingly (it currently just checks against version
> packages) *also* we could provide MD5sums of know vulnerable packages (in the
> stable distribution and proposed-updates).
> 
> Also, this information needs to be splitted off the package so it can work 
> like
> antivirus updates. Thus, signature updates could go to proposed-updates 
> without
> needing to update the program itself.

Agreed. Without having too much digging in tiger it might be a good
idea. The contact I have had with tiger is not very pleasant because it
bugged me with a lot of non-issues. That is maybe the reason why I
deinstalled it. :)

Regards,

// Ola

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

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#159302: ITP: mcvs -- a version control system that is layered on top of CVS.

[Jesus Climent]

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

* Package name: mcvs
  Version : 0.22-1
  Upstream Author : Kaz Kylheku <[EMAIL PROTECTED]>
* URL : http://users.footprints.net/~kaz/mcvs.html
* License : GPL
  Description : a version control system that is layered on top of CVS.

 It is more capable than CVS, and is easier to use. Its main features are:
 .
  * Directory structure versioning.
  * Sane corner cases.
  * Simple branching and merging.
  * Support for symbolic links.
  * Tracking of third party code containing moves and renames.
  * Ease of deployment.

testing versions will be available from

http://pumuki.hispalinux.es/debian/packages/

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux reypastor 2.2.20HL1 #4 mar may 21 15:35:56 CEST 2002 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: The harden-*flaws packages.

[Javier Fernández-Sanguino Peña]

On Mon, Sep 02, 2002 at 04:09:21PM +0200, Ola Lundqvist wrote:
> Hi
> 
> > If you want a program to check for security flaws please use one designed 
> > for that
> > precisely. Tiger is such a program. Just have the *flaws package recommend: 
> > or
> > depend: on tiger.
> 
> On the other hand tigher does a lot of other things too. But the link
> you gave me was very interesting.

Tiger can be configured easily to just check *one* thing. Just customize the 
cron
job at will.

(..)
> 
> Agreed. Without having too much digging in tiger it might be a good
> idea. The contact I have had with tiger is not very pleasant because it
> bugged me with a lot of non-issues. That is maybe the reason why I
> deinstalled it. :)

There are still false positives in tiger, the template mechanism, however, takes
care so that an admin just sees a security warning *once* and not in every run 
of
the security test script (It's a simple diff, mind you, but it works)

Regards

Javi

Orphaning websec...

[Joop Stakenborg]

I am orphaning websec, here is the description:

Web Secretary is a web page monitoring software. However, it goes beyond
the normal functionalities offered by such software. Not only does it detect
changes based on content analysis (instead of date/time stamp or simple
textual comparison), it will email the changed page to you WITH THE NEW
CONTENT HIGHLIGHTED! 

It is a small but very useful package, which is unmaintained upstream.
I have kept it inside debian, because users still request for small changes
now and then. 

You will need a bit of perl knowledge to maintain it.

Joop

Re: The harden-*flaws packages.

[Ola Lundqvist]

On Mon, Sep 02, 2002 at 05:01:14PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Mon, Sep 02, 2002 at 04:09:21PM +0200, Ola Lundqvist wrote:
> > Hi
> > 
> > > If you want a program to check for security flaws please use one designed 
> > > for that
> > > precisely. Tiger is such a program. Just have the *flaws package 
> > > recommend: or
> > > depend: on tiger.
> > 
> > On the other hand tigher does a lot of other things too. But the link
> > you gave me was very interesting.
> 
> Tiger can be configured easily to just check *one* thing. Just customize the 
> cron
> job at will.

That can be interesting for the harden-*flaws pacakges (or similar).

> (..)
> > 
> > Agreed. Without having too much digging in tiger it might be a good
> > idea. The contact I have had with tiger is not very pleasant because it
> > bugged me with a lot of non-issues. That is maybe the reason why I
> > deinstalled it. :)
> 
> There are still false positives in tiger, the template mechanism, however, 
> takes
> care so that an admin just sees a security warning *once* and not in every 
> run of
> the security test script (It's a simple diff, mind you, but it works)

Ahh that looks great. Last time I checked it did not. Now I might be
able to use it again. :)

Now we just have to solve the upload-to-security problem, or simply
write some other check that scans the security.d.o web pages and
make clever things of it. Maybe using tiger, maybe some other things. But
because tiger can do similar things that might be useful.

Regards,

// Ola

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

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Dmitry Borodaenko]

On Sun, Sep 01, 2002 at 03:28:23AM +0300, Richard Braakman wrote:
 RB> I do think that discouraging the use of patent-encumbered
 RB> "standards" is a useful way to fight patent oppression.  It sends
 RB> the message that a patented standard is a dead standard.  Maybe
 RB> companies will review their habits in that light.

As a one who lives in a post-communist dictatorship, I have a different
moral position on this issue.

Discouraging use of patent-encumbered technologies is the same as
political emigration: it is the easy way out of the oppression, but it
is nothing else but a defeat, and when you are fleeing to another
country, this defeat will follow you there. If you want to fight
oppression, you should fight where you stand, and not run away until
you're locked in a corner.

When you are retreating in such a way, you agree to abandon things that
are important to you: useful technologies become casaulty to patents and
your home and friends become casaulty to politics. Thus, you suffer
major immediate damage, while damage you deliver to oppressor is minor
and, honestly speaking, merely potential. Even worse, the fact that you
retreat without a fight actually encourages further oppression, both on
the territory you left and on territory you enter.

Instead, I would try to do some actual damage to the oppressors, in this
case by finding or creating such a way to ignore their limitations that
will not put the whole Debian project in a danger. I think making
patents practically unenforceable over free software would deliver much
stronger message.

Quoting Declan McCullagh: "Put another way, who made a bigger
difference: Yet another letter-scribbling activist or Phil Zimmermann?"
If you want to make a difference, don't just take your ball and walk
away: they don't need your ball.

-- 
Dmitry Borodaenko

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Russell Coker]

On Mon, 2 Sep 2002 17:22, Dmitry Borodaenko wrote:
> Discouraging use of patent-encumbered technologies is the same as
> political emigration: it is the easy way out of the oppression, but it
> is nothing else but a defeat, and when you are fleeing to another
> country, this defeat will follow you there. If you want to fight
> oppression, you should fight where you stand, and not run away until
> you're locked in a corner.

That moral stance makes sense.

However it can be applied in a different way to this situation.  Resolving to 
not use your PC for audio or video applications because of patents would be 
fleeing from opression.  Writing and supporting new programs to perform the 
same tasks without the patents is actively fighting back.

If the MP3 patents become worthless because everyone wants to use Vorbis 
technologies instead then the Frauhofer Institute will lose significant 
amounts of money!

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

Re: Improper NMU (Re: NMU for libquota-perl)

[Joey Hess]

John Goerzen wrote:
> I'm concerned that a single person has the power to dictate such dramatic
> changes in our procedures.  Why is the NMU procedure not codified in Debian
> Policy?  There, at least, we have a better mechanism of updating it.

Debian policy does not dictate how developers do stuff, it describes the
proper content of debian packages.

Aj's pronouncement that we should loosen NMU procedures was accepted
because it made it clear that this was a good idea and people agreed
with it, and because we generally respect Aj to make decisions that are
good for the release, not because it was a pronouncement from on high.

-- 
see shy jo


pgpumu6609ey5.pgp
Description: PGP signature

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Dmitry Borodaenko]

On Mon, Sep 02, 2002 at 05:56:08PM +0200, Russell Coker wrote:
 DB>> Discouraging use of patent-encumbered technologies is the same as
 DB>> political emigration: it is the easy way out of the oppression,
 DB>> but it is nothing else but a defeat, and when you are fleeing to
 DB>> another country, this defeat will follow you there. If you want to
 DB>> fight oppression, you should fight where you stand, and not run
 DB>> away until you're locked in a corner.
 RC> That moral stance makes sense.
 RC> 
 RC> However it can be applied in a different way to this situation.
 RC> Resolving to not use your PC for audio or video applications
 RC> because of patents would be fleeing from opression.  Writing and
 RC> supporting new programs to perform the same tasks without the
 RC> patents is actively fighting back.

Agreed. But, encouraging development of patent-free and better
alternative is not exactly the same as discouraging the use of
patent-encumbered _free_ software. I'm all for the former, but I
disagree with the latter.

-- 
Dmitry Borodaenko

Re: The harden-*flaws packages.

[Javier Fernández-Sanguino Peña]

On Mon, Sep 02, 2002 at 05:13:51PM +0200, Ola Lundqvist wrote:
> 
> Now we just have to solve the upload-to-security problem, or simply
> write some other check that scans the security.d.o web pages and
> make clever things of it. Maybe using tiger, maybe some other things. But
> because tiger can do similar things that might be useful.
> 
It's in my todo list. Now DSAs are much more easy to parse. Some older DSAs
(pre-1999) might need special parsing however. Also, DSAs could be improved to 
add
an 'affected versions' tag (currently only the package name is provider, you can
infer the affected versions by looking the versions which *fix* the 
vulnerability).

Javi

Re: Improper NMU (Re: NMU for libquota-perl)

[Elie Rosenblum]

On Mon, Sep 02, 2002 at 10:41:48AM +0200, Raphael Hertzog wrote:
> Le Mon, Sep 02, 2002 at 12:20:22AM -0400, Elie Rosenblum ?crivait:
> > Would you agree that performing an NMU without a BTS entry is wrong?
> 
> Nope.
> 
> The strict minimum is :
> - create a patch for the NMU
> - make the patch available to the maintainer (via direct mail or bts)
> 
> If you upload the package to DELAYED, it is enough to respect the spirit
> of the NMUs guidelines (which are in developers-reference).
> 
> BTW, the developers-reference evolved quite a bit since the good old
> days, and the DELAYED stuff is mentionned in the NMU guidelines...
> please read it again.
> 
> http://www.debian.org/doc/manuals/developers-reference/index.en.html

Please also read section 5.2.3. The exceptions everyone is talking
about are documented there as well, and that's during the release
cycle. As for _unstable_:
 Bug fixes to unstable by non-maintainers are also acceptable, but only
 as a last resort or with permission.  The following protocol should be
 respected to do an NMU:

And the rules following it make sense, and should really be
followed.

DELAYED is fine. Not submitting a bug is not fine.

> > I've been hit with an
> > irresponsible maintainer performing an NMU without submitting a
> > bug at all, even if it was 5 minutes before he uploaded.
> 
> This is ridiculous. An NMU is not a punishment for bad maintainers,
> it's an offer of help to help you catch up in your Debian work.
> 
> No one should be offended by an NMU.

I am offended with how the NMU was done. I've had one other NMU done
before and it was done right; however, it also broke the package in
question. I don't think I bitched that it was done though.

> > especially since we have little control over which keys can
> > successfully upload any given package.
> 
> You want respect for yourself, you don't want to be treated like
> an "irresponsible maintainer", but you show absolutely no respect to
> people who are doing NMUs to help you.
> 
> Think about it, people doing NMUs are other Debian developers like you 
> who take their free time to help you, and look how you thank them.
> 
> Even if he made a mistake, it's not a big one, the upload was to
> DELAYED, the package has not yet been installed, you have a chance
> to dump the NMU by uploading your own fix.

I just want him to follow the guidelines.

I think he would have been within the guidelines by something as
incredibly simple as a BTS entry. How fucking hard is that?

-- 
Elie Rosenblum That is not dead which can eternal lie,
http://www.cosanostra.net   And with strange aeons even death may die.
Admin / Mercenary / System Programmer - _The Necronomicon_

Re: [PHP] Standard placement of PHP libraries?

[Ian Zimmerman]

Matthew> I would like to propose /usr/share/php4 as the place for all
Matthew> scripts intended to run under php4 (whatever subversion) and
Matthew> intended for inclusion in other PHP scripts.  

I agree, but let's not forget about php3.

-- 
Ian Zimmerman, Oakland, California, U.S.A.
GPG: 433BA087  9C0F 194F 203A 63F7 B1B8  6E5A 8CA3 27DB 433B A087
EngSoc adopts market economy: cheap is wasteful, efficient is expensive.

Re: [PHP] Standard placement of PHP libraries?

[Steve Langasek]

On Mon, Sep 02, 2002 at 07:05:40PM +1000, Matthew Palmer wrote:
> I guess this is probably going to turn into a mini-policy discussion, and I
> hope so, because I think we need some level of standardisation.

> There are several PHP extension libraries packaged for Debian; I guess the
> most famous is probably pear, but I maintain one (phtml, used by some other
> packages I maintain) and I know there are a couple of others out there, too.
> By these libraries I'm not talking about binary modules, I'm talking about
> extension libraries written in PHP and available by include('whatever'). 
> It's the 'whatever' that I'm mostly interested in discussing for now.

> PEAR uses /usr/share/pear, and has an entry in include_path for it.  Hence,
> to use any PEAR-shipped function, simply refer to the file by name, relative
> to that directory.  Nice, very simple, I highly approve.  Since PEAR holds a
> special status, perhaps that should change.

> But what about every other PHP extension library out there?  libphp-adodb,
> for instance, uses /usr/lib/adodb - in violation of the FHS, I believe,
> since PHP scripts shouldn't be architecture specific.  But that's not really
> the issue here - the point is, where *should* PHP includes go?

Adam Conrad and I have begun hammering out a PHP mini-policy (not yet
ready for public consumption) that calls for all PHP classes to be
shipped in /usr/share/php.  Yes, PEAR obviously violates this at present
-- so transitioning to the new scheme will require shipping a default
include path that looks in both /usr/share/php and /usr/share/pear.

In discussing this, we concluded that most PHP classes currently use
their own directories as a means of eliminating namespace collisions;
however, this is clearly inappropriate, as it pushes the burden of
resolving collisions on the user, rather than on the maintainer.  PHP's
handling of classes should be the same as that of other scripting
languages, such as perl and python.

> I would like to propose /usr/share/php4 as the place for all scripts
> intended to run under php4 (whatever subversion) and intended for inclusion
> in other PHP scripts.  All packages would install their inclusion hierarchy
> under /usr/share/php4/, and scripts which wanted to use their
> functionality would include('/include.php').  Naming of
> include files, including their extension, would be left to the discretion of
> individual maintainers.

We had ruled out /usr/share/php4, on the grounds that many, if not most,
PHP classes are not specific to php4; some will work with php3, and many
should be forward-compatible with php5.

As far as using /usr/share/php4/, I'm not aware of any such
requirement for other scripting languages.  I think it's reasonable to
allow PHP packages to install their classes in the manner which is most
convenient, and let package conflict resolution take care of the rest. 
PEAR already provides us a structure for the namespace, which we ought to
take advantage of.

Steve Langasek
postmodern programmer


pgpO8d4Z534BQ.pgp
Description: PGP signature

Re: RFC: Handling of certificates in Debian

[Stephen Frost]

* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
> On Sat, 31 Aug 2002, Brian May wrote:
> > (note that I really like this realiance on checking the hostname, for
> > instance it doesn't work properly with virtual name domains under https,
> > but it somehow seems to have become the defacto default, and we seem to
> > be stuck with it for now).
> 
> It can, if the [EMAIL PROTECTED]@#$ browsers implement the altName extension.

Uh, except that on the server side if you're going to have different
certs for different virtual servers then unless they each have their own
IP there's no way for apache to know which cert to use because the SSL
connection and whatnot is set up prior to the HTTP headers being sent.
That's my understanding anyway.

Stephen


pgpKRbTKYiJPJ.pgp
Description: PGP signature

Re: RFC: A regression test framework for Debian packages?

[Ian Zimmerman]

Jérôme> One year ago, Martin Michlmayr made a speach at the Debian
Jérôme> Conference 1 about Quality Assurance within Debian and the
Jérôme> progress that have been made so far.  He mentioned that we
Jérôme> lack regression tests for packages, but as far as I know, no
Jérôme> solution has been found.

>> kronstadt:~# dpkg --status debian-test
>> Package: debian-test
>> Status: install ok installed
>> Priority: extra
>> Section: devel
>> Installed-Size: 34
>> Maintainer: Philip Hands <[EMAIL PROTECTED]>
>> Version: 0.0.5
>> Depends: perl5 | perl
>> Description: Scripts used to run tests against an installed Debian system
>>  This package contains tests and the framework to run them, and test provided
>>  by other packages to test themselves.
>>  .
>>  The intent is that this should build into a test suite that provides a
>>  reasonable level of confidence that a Debian system is working correctly.

Wasn't this at least a start?  Shouldn't we build on it instead of
starting from scratch?

-- 
Ian Zimmerman, Oakland, California, U.S.A.
GPG: 433BA087  9C0F 194F 203A 63F7 B1B8  6E5A 8CA3 27DB 433B A087
EngSoc adopts market economy: cheap is wasteful, efficient is expensive.

Re: RFC: Handling of certificates in Debian

[Henrique de Moraes Holschuh]

Hi Stephen!

On Mon, 02 Sep 2002, Stephen Frost wrote:

> * Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
> > On Sat, 31 Aug 2002, Brian May wrote:
> > > (note that I really like this realiance on checking the hostname, for
> > > instance it doesn't work properly with virtual name domains under https,
> > > but it somehow seems to have become the defacto default, and we seem to
> > > be stuck with it for now).
> > 
> > It can, if the [EMAIL PROTECTED]@#$ browsers implement the altName 
> > extension.
> 
> Uh, except that on the server side if you're going to have different
> certs for different virtual servers then unless they each have their own
> IP there's no way for apache to know which cert to use because the SSL
> connection and whatnot is set up prior to the HTTP headers being sent.
> That's my understanding anyway.

That is why you have more than one name in the cert.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: RFC: Handling of certificates in Debian

[Stephen Frost]

* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
> On Mon, 02 Sep 2002, Stephen Frost wrote:
> > * Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
> > > On Sat, 31 Aug 2002, Brian May wrote:
> > > > (note that I really like this realiance on checking the hostname, for
> > > > instance it doesn't work properly with virtual name domains under https,
> > > > but it somehow seems to have become the defacto default, and we seem to
> > > > be stuck with it for now).
> > > 
> > > It can, if the [EMAIL PROTECTED]@#$ browsers implement the altName 
> > > extension.
> > 
> > Uh, except that on the server side if you're going to have different
> > certs for different virtual servers then unless they each have their own
> > IP there's no way for apache to know which cert to use because the SSL
> > connection and whatnot is set up prior to the HTTP headers being sent.
> > That's my understanding anyway.
> 
> That is why you have more than one name in the cert.

I would think most places want their own cert and not to share with
other, probably totally unrelated, people.

Stephen


pgpMb3Edydz7l.pgp
Description: PGP signature

Re: RFC: A regression test framework for Debian packages?

[Jérôme Marant]

Ian Zimmerman <[EMAIL PROTECTED]> writes:

> Jérôme> One year ago, Martin Michlmayr made a speach at the Debian
> Jérôme> Conference 1 about Quality Assurance within Debian and the
> Jérôme> progress that have been made so far.  He mentioned that we
> Jérôme> lack regression tests for packages, but as far as I know, no
> Jérôme> solution has been found.
>
>>> kronstadt:~# dpkg --status debian-test
>>> Package: debian-test
>>> Status: install ok installed
>>> Priority: extra
>>> Section: devel
>>> Installed-Size: 34
>>> Maintainer: Philip Hands <[EMAIL PROTECTED]>
>>> Version: 0.0.5
>>> Depends: perl5 | perl
>>> Description: Scripts used to run tests against an installed Debian system
>>>  This package contains tests and the framework to run them, and test 
>>> provided
>>>  by other packages to test themselves.
>>>  .
>>>  The intent is that this should build into a test suite that provides a
>>>  reasonable level of confidence that a Debian system is working correctly.
>
> Wasn't this at least a start?  Shouldn't we build on it instead of
> starting from scratch?

Where did you see we want to start from scratch? RFC are made for people who
want to add such information.
Thanks for this, BTW.

-- 
Jérôme Marant

http://marant.org

Re: RFC: Handling of certificates in Debian

[Henrique de Moraes Holschuh]

Hi Stephen!

On Mon, 02 Sep 2002, Stephen Frost wrote:

> * Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
> > On Mon, 02 Sep 2002, Stephen Frost wrote:
> > > * Henrique de Moraes Holschuh ([EMAIL PROTECTED]) wrote:
> > > > On Sat, 31 Aug 2002, Brian May wrote:
> > > > > (note that I really like this realiance on checking the hostname, for
> > > > > instance it doesn't work properly with virtual name domains under 
> > > > > https,
> > > > > but it somehow seems to have become the defacto default, and we seem 
> > > > > to
> > > > > be stuck with it for now).
> > > > 
> > > > It can, if the [EMAIL PROTECTED]@#$ browsers implement the altName 
> > > > extension.
> > > 
> > > Uh, except that on the server side if you're going to have different
> > > certs for different virtual servers then unless they each have their own
> > > IP there's no way for apache to know which cert to use because the SSL
> > > connection and whatnot is set up prior to the HTTP headers being sent.
> > > That's my understanding anyway.
> > 
> > That is why you have more than one name in the cert.
> 
> I would think most places want their own cert and not to share with
> other, probably totally unrelated, people.

For that, you need a specification that allows you to send a number of certs
(instead of only one) and let the browser select the one that matches the
domain it wants, and verify that single one.

I am not sure the current specs allow for that.  But one that does is
certainly needed.

-- 
  "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: Migration to /usr/share/doc

[Shaya Potter]

might it be more friendly to tab'ers to rename the dir base-doc instead
of doc-base

On Thu, 2002-08-29 at 02:01, Oliver Elphick wrote:
> On Mon, 2002-08-26 at 23:11, Giorgio Mandolfo wrote:
> ...
> > I am trying not to use exclusively the simbolic link to /usr/share/doc/ 
> > but to look directly to the new folder. Well, I there is a (very) 
> > simple and boring fact: the  completion locks because there is 
> > /usr/share/doc-base/ too.
> > I searched for some explanations about it in the Debian Policy, even if 
> > its name is self-explanatory. I did not find anything.
> > Couri
> > So my questions/proposals are:
> > - Why this directory exists? And what is it about?
> 
> It contains control files for the doc-base package.  See
> /usr/share/doc/doc-base/doc-base.html/index.html
> 
> > - Is it possible to move their contents to /usr/share/doc/ allowing a 
> > faster search through the filesystem?
> 
> No.  The files in /usr/share/doc-base/ are not documentation and do not
> belong in /usr/share/doc/
> 
> -- 
> Oliver Elphick[EMAIL PROTECTED]
> Isle of Wight, UK
> http://www.lfix.co.uk/oliver
> GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
>  
>  "Preach the word; be instant in season, out of season; 
>   reprove, rebuke, exhort with all longsuffering and 
>   doctrine."  II Timothy 4:2 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Migration to /usr/share/doc

[Clint Adams]

> might it be more friendly to tab'ers to rename the dir base-doc instead
> of doc-base

That seems like overkill.  Just do something like

zstyle ':completion:*' ignored-patterns 'doc-base'

Re: [PHP] Standard placement of PHP libraries?

[Thorsten Sauter]

Hello,

> But what about every other PHP extension library out there?  libphp-adodb,
> for instance, uses /usr/lib/adodb - in violation of the FHS
not true. :)
since version 2.31-1 libphp-adodb is now installed in /usr/share/adodb,
this should now conform to the FHS.

> I would like to propose /usr/share/php4 as the place for all scripts
> intended to run under php4 (whatever subversion) and intended for inclusion
> in other PHP scripts.
I agree. It make the live easier for php-developers.

Bye
Thorsten

-- 
Thorsten Sauter
<[EMAIL PROTECTED]>

(Is there life after /sbin/halt -p?)



pgprjDxJHVeTN.pgp
Description: PGP signature

Where are tasks now and how are they handled? (Woody sucks because there is no Task: Spanish)

[Javier Fernández-Sanguino Peña]

(I have skimmed this year's debian-devel-announce as well as the developer's
policy and haven't found this explained)

One simple question: how are tasks managed? what policy is there for
creation/addition of packages to it?

Aj[1] seems to say that this is managed by override files. But I wonder if 
whomever
did this checked if the changes were made properly. Why do I know?

1.- Because 'tasksel' does not show up any "Task: Spanish" when in fact there 
was
one in potato.

2.- Because this seems to be a consequence of *no* packages having "Task: 
spanish"

Should I have done something (as maintainer of the task-spanish package), how 
can
we fix this? could it be fixed for woody r1 ??

Regards

Javi


[1] http://lists.debian.org/debian-boot/2001/debian-boot-200105/msg00075.html

Re: install-info and LSB

[Matthew Woodcraft]

> I am wondering if we aren't violating the spirit if not the letter of
> LSB by using a non-standard version of install-info.

While of course the LSB says nothing about install-info, the fact that
Debian distributes a program under the name 'install-info' which is
incompatible with the GNU version can cause trouble for users.

For example:

% tar xzf texinfo-4.2.tar.gz
% cd texinfo-4.1
% make
% sudo make install

will put GNU install-info into /usr/local/bin. As, by default in Debian,
this is in front of /usr/bin in root's path, package upgrades will
break.

I think Debian would be a better distribution if its install-info were
renamed. I appreciate that the transition might take years, but that's
no reason not to do it.

-M-

Re: Migration to /usr/share/doc

[Shaya Potter]

that just solves a single instance, most people including me are not
experts on this, and just want it to work, while I get around it by
adding a '/' at the end of doc others might be just very annoyed.

On Mon, 2002-09-02 at 14:25, Clint Adams wrote:
> > might it be more friendly to tab'ers to rename the dir base-doc instead
> > of doc-base
> 
> That seems like overkill.  Just do something like
> 
> zstyle ':completion:*' ignored-patterns 'doc-base'

Re: Where are tasks now and how are they handled? (Woody sucks because there is no Task: Spanish)

[Erich Schubert]

> One simple question: how are tasks managed? what policy is there for
> creation/addition of packages to it?

See debian-policy...

Excerpt from the changelog:
  * we no longer have task packages, instead, we define tasks using a
special field in the control file (and these should be added only
after discussion on the mailing lists) closes: Bug#97755


-- 
erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C
To understand recursion you first need to understand recursion.
Ein Freund ist ein Geschenk, das man sich selbst macht.
Für jedes Problem gibt es eine Lösung, die einfach, klar und falsch ist.

task-spanish exists: expansion proposal (was Re: Where are tasks now and how are they handled? (Woody sucks because there is no Task: Spanish))

[Javier Fernández-Sanguino Peña]

On Mon, Sep 02, 2002 at 09:00:40PM +0200, Erich Schubert wrote:
> 
> Excerpt from the changelog:
>   * we no longer have task packages, instead, we define tasks using a
> special field in the control file (and these should be added only
> after discussion on the mailing lists) closes: Bug#97755
> 

Thanks. Then is everyone ok if I include (or submit bug against the packages 
that
don't) Task: spanish to the control files for

doc-linux-es
doc-debian-es
debrecipes-es
apt-howto-es
user-es
aspell-es
ispanish
wspanish
language-env
manpages-es
manpages-es-extra
wordtrans
i2e (should be superceeded by wordrtans for next release)
ayuda
xfonts-intl-european

Ummm... wait a minute... some of these already are in tasksel!
It seems that the following are:
 wspanish
 ispanish
 doc-linux-es
 manpages-es
 user-es


However, when I installed with some brand-new woody CDs the 'Spanish' task 
would not show up... I will try to dig this bug out.

In any case... anybody against broadening the Task package? It's just to make it
similar to task-german, task-french et al..

Regards

Javi

Re: Migration to /usr/share/doc

[Martin Wheeler]

On 2 Sep 2002, Shaya Potter wrote:

>  while I get around it by
> adding a '/' at the end of doc others might be just very annoyed.

Hear, hear!

Try teaching a lab. full of newbies how to access local documentation via a
browser, and see just *how* annoyed they can get.
-- 
Martin Wheeler   -   StarTEXT / AVALONIX - Glastonbury - BA6 9PH - England
[EMAIL PROTECTED]  http://startext.demon.co.uk/
GPG pub key : 8D6B948B  ECC6 D98E 4CC8 60E3 7E32  D594 BB27 3368 8D6B 948B
  - Share your knowledge. It's a way of achieving immortality. -

Re: RFC: Handling of certificates in Debian

[Richard Braakman]

On Mon, Sep 02, 2002 at 02:22:52PM -0300, Henrique de Moraes Holschuh wrote:
> > I would think most places want their own cert and not to share with
> > other, probably totally unrelated, people.
> 
> For that, you need a specification that allows you to send a number of certs
> (instead of only one) and let the browser select the one that matches the
> domain it wants, and verify that single one.

I don't think thats scales sufficiently well.  Some sites have
*thousands* of virtual domains.  Sending all those certificates for
every https request would be expensive.

If you're going to tinker with the specification anyway, I would
suggest one where the client states up front whose certificate it wants.

Richard Braakman

Re: RFC: Handling of certificates in Debian

[Andrew McDonald]

On Mon, Sep 02, 2002 at 10:10:07PM +0200, Richard Braakman wrote:
[on TLS]
> If you're going to tinker with the specification anyway, I would
> suggest one where the client states up front whose certificate it wants.

Such the Server Name Indication mechanism described in:


Or, using a "TLS upgrade" procedure as in RFC2817 where the server name
can be specified in a Host: header before the TLS handshake is started.
For other protocols, e.g. IMAP and SMTP, the STARTTLS method is used to
do something similar.

-- 
Andrew McDonald
E-mail: [EMAIL PROTECTED]
http://www.mcdonald.org.uk/andrew/

Re: Where are tasks now and how are they handled? (Woody sucks because there is no Task: Spanish)

[Tollef Fog Heen]

* Erich Schubert 

| > One simple question: how are tasks managed? what policy is there for
| > creation/addition of packages to it?
| 
| See debian-policy...
| 
| Excerpt from the changelog:
|   * we no longer have task packages, instead, we define tasks using a
| special field in the control file (and these should be added only
| after discussion on the mailing lists) closes: Bug#97755

uhm, they should _not_ be added to the control file.  They should be
added by the override files plucked from base-config's CVS.  Skim the
archives on -boot for information.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

MySQL cannot connect (using mysqlclientlibs v3.23.49-8)

[Joel Maxwell]

I am using fpc 1.0.4 [2001/08/31] for i386.  The program I am trying to run 
uses mysql unit, and i unit i have masde to simplify 
mysql usage.  When it get to
dbrec.sock:=mysql_connect(PMysql(@dbrec.qmysql),dbrec.host,dbrec.user,dbrec.password);

This error arises.

An unhandled exception occurred at 0x4002468F :
 Access violation
 0x4002468F
 0x0805F503
 0x0805F6B1
 0x080648E4
 0x08065FC9
 0x080486FF
 0x080486EC
 0x

I am using debian 3.0.  When I was using 2.2 (and mysqlibs 6 instead of 10, I 
would never get this error.)
Please help.  I think the problem lies with mysqlibs10-dev yet there is no 
other package abvailable to replace it.

-- 
Joel Maxwell,
WWHCN System Administrator
-
program sig
// uses ggi, gtk, mysql;
begin
WriteLn('Content-type: text/plain');
WriteLn('Our social strategy is lacking but it is the future,');
WriteLn('it is what takes us away from the caves');
end.

Re: install-info and LSB

[Josip Rodin]

On Mon, Sep 02, 2002 at 07:38:08PM +0100, Matthew Woodcraft wrote:
> > I am wondering if we aren't violating the spirit if not the letter of
> > LSB by using a non-standard version of install-info.
> 
> While of course the LSB says nothing about install-info, the fact that
> Debian distributes a program under the name 'install-info' which is
> incompatible with the GNU version can cause trouble for users.

As it has been pointed out hundreds of times, it is GNU that distributes a
program under then name 'install-info' which is incompatible with the dpkg
version. :)

(The version in dpkg has seniority.)

> For example:
> 
> % tar xzf texinfo-4.2.tar.gz
> % cd texinfo-4.1
> % make
> % sudo make install
> 
> will put GNU install-info into /usr/local/bin. As, by default in Debian,
> this is in front of /usr/bin in root's path, package upgrades will
> break.

No Debian user would never do such a silly thing in the first place...

apt-get install {tex,}info

-- 
 2. That which causes joy or happiness.

Re: old ITP's

[Noah Meyerhans]

On Mon, Aug 26, 2002 at 08:30:13PM +0200, Bas Zoetekouw wrote:
>   #89421 tcptrace filed:  531, changed  531

This was mine, and I do still intend to package it.  The issue that
prevented me from doing so was that it wants to use another software
package called xplot, written by Tim Shepard of the MIT Lab for Computer
Science (see www.xplot.org).  This is not compatible with the xplot
package in Debian, and I didn't have time to get things straightened
out.

noah

-- 
 ___
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 


pgphRY52sAERA.pgp
Description: PGP signature

Re: install-info and LSB

[Matthew Woodcraft]

On Mon, Sep 02, 2002 at 11:19:26PM +0200, Josip Rodin wrote:
> As it has been pointed out hundreds of times, it is GNU that distributes a
> program under then name 'install-info' which is incompatible with the dpkg
> version. :)
> 
> (The version in dpkg has seniority.)

It's not a matter of seniority, it's a matter of producing the highest
quality distribution.

The dpkg-iasearch package used to contain a program called dpkg-query.
When the dpkg maintainers added a program with the same name, the
dpkg-iasearch maintainer renamed his file, without worrying about
'seniority'. I think he did well to do so, don't you?

Debian would do well to rename its install-info for the same reasons.

-M-

Re: install-info and LSB

[Josip Rodin]

On Mon, Sep 02, 2002 at 10:40:02PM +0100, Matthew Woodcraft wrote:
> > As it has been pointed out hundreds of times, it is GNU that distributes a
> > program under then name 'install-info' which is incompatible with the dpkg
> > version. :)
> > 
> > (The version in dpkg has seniority.)
> 
> It's not a matter of seniority, it's a matter of producing the highest
> quality distribution.

Superficial restating of the issue certainly doesn't make your point
clear...

> The dpkg-iasearch package used to contain a program called dpkg-query.
> When the dpkg maintainers added a program with the same name, the
> dpkg-iasearch maintainer renamed his file, without worrying about
> 'seniority'. I think he did well to do so, don't you?
> 
> Debian would do well to rename its install-info for the same reasons.

"dpkg-query" was obviously very much inside the dpkg namespace. On the other
hand, dpkg's install-info is both not really in texinfo namespace because it
its name is pretty generic as it is and is older than texinfo's version so
this doesn't score well on the list of good reasons to swap them.

Anyway, this discussion is superfluous too, as the dpkg maintainers have
already decided to move over to the C, GNU version in the future. (See
debian-dpkg list archives for details.)

-- 
 2. That which causes joy or happiness.

Re: install-info and LSB

[Matthew Woodcraft]

On Mon, Sep 02, 2002 at 11:57:03PM +0200, Josip Rodin wrote:
> Anyway, this discussion is superfluous too, as the dpkg maintainers have
> already decided to move over to the C, GNU version in the future. (See
> debian-dpkg list archives for details.)

I am pleased to hear this.

-M-

Re: Where are tasks now and how are they handled? (Woody sucks because there is no Task: Spanish)

[Philip Charles]

On 2 Sep 2002, Tollef Fog Heen wrote:

> * Erich Schubert
>
> | > One simple question: how are tasks managed? what policy is there for
> | > creation/addition of packages to it?
> |
> | See debian-policy...
> |
> | Excerpt from the changelog:
> |   * we no longer have task packages, instead, we define tasks using a
> | special field in the control file (and these should be added only
> | after discussion on the mailing lists) closes: Bug#97755
>
> uhm, they should _not_ be added to the control file.  They should be
> added by the override files plucked from base-config's CVS.  Skim the
> archives on -boot for information.
>   `. `'
The info for the Tasks is in debian/indices/override.woody.extra.main.gz
if you want to have a look.  debian-cd then adds this info to the Packages
file.

Phil.
--
  Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand
   +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420
 [EMAIL PROTECTED] - preferred.  [EMAIL PROTECTED]
 I sell GNU/Linux & GNU/Hurd CDs.   See http://www.copyleft.co.nz

Re: install-info and LSB

[Adam Heath]

On Mon, 2 Sep 2002, Josip Rodin wrote:

> Anyway, this discussion is superfluous too, as the dpkg maintainers have
> already decided to move over to the C, GNU version in the future. (See
> debian-dpkg list archives for details.)

We have?

Bug#159385: general: install a package but don't have it's magic funcionality on by default

[Dan Jacobson]

Package: general
Version: N/A; reported 2002-09-03
Severity: minor

First examine a bug report I sent regarding a typical package, "bl":

My idea of inviting bl onto my computer was that it would be there
when i need it, but not on by default.  as there is no easy way of
configuring it not to start on login, therefore i am removing it.

That's the problem with debian, for me.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux debian 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686
Locale: LANG=zh_TW.Big5, LC_CTYPE=zh_TW.Big5

Re: install-info and LSB

[Josip Rodin]

On Mon, Sep 02, 2002 at 05:47:23PM -0500, Adam Heath wrote:
> > Anyway, this discussion is superfluous too, as the dpkg maintainers have
> > already decided to move over to the C, GNU version in the future. (See
> > debian-dpkg list archives for details.)
> 
> We have?

I remember you saying so yourself on -dpkg.

-- 
 2. That which causes joy or happiness.

Re: [PHP] Placement of PHP programs?

[Matthew Palmer]

On Mon, 2 Sep 2002, Fabien Penso wrote:

>  > As a kind of an adjunct to the other discussion on PHP libraries, what 
> about
>  > PHP programs?  Not quite so touchy, as I can't see a single way forward 
> here
>  > (and there's no blazingly obvious reason to do so).  So what are people's
>  > best thoughts on the matter?  Most packages I've seen put their
>  > web-accessible content in /usr/share/, then either set up a
>  > separate apache config and include it from the main apache config
>  > (phpgroupware does it this way, for one example) while other packages 
> modify
>  > apache.conf more intrusively.  I'm a fan of the phpgroupware method, which
>  > at least minimises pain.
> 
> Shouldn't webpage go to /var/www or at least /var/, and _not_ /usr/share
> ? We are talking about PHP, but it's still webpages after all.

I don't know of any web server which doesn't support an equivalent concept
to Apache's aliases; I feel that /var/www (and I think practice bears me out)
is pretty much local space - we don't fiddle with it (except when putting an
*initial* web site in on install - which is never again touched after that).

Imagine if the sysadmin had a whole pile of stuff in a directory of /var/www
which had the same name as a web-based package he'd just installed.  Without
any warning, a whole block of his files go bye-bye, to be replaced with
files from the package just installed.  As a sysadmin, I'd be seriously
annoyed - homicidally so, in fact.

> The apache configuration should go into a separate file in /etc/apache/
> which would be included in httpd.conf later; easier to modify I guess.

If the files were in /var/www, then there would be no need for an apache
config in most cases.  The fact that the package scripts go in
/usr/share/ means that there needs to be apache directives to make
that accessible, so we put Alias directives in that config file.  Link it
into the apache config using an IncludeFile, and we're off.  If it's in
/var/www then I don't think there'd typically be much need for an apache
config (I may be wrong on that).

> The software configuration should stay into the its location, the
> software directory.

Configuraton goes in /etc; The 'software directory' I would take to be where
the actual program is located - /var/www in your proposal,
/usr/share/ in mine.  Either way, config lives in /etc.


-- 
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org

Re: [PHP] Standard placement of PHP libraries?

[Matthew Palmer]

On 2 Sep 2002, Ian Zimmerman wrote:

> Matthew> I would like to propose /usr/share/php4 as the place for all
> Matthew> scripts intended to run under php4 (whatever subversion) and
> Matthew> intended for inclusion in other PHP scripts.  
> 
> I agree, but let's not forget about php3.

I have no recent experience with php3; I don't use it any more, I've
upgraded everything I've got.  Since it is possible to have both php3 and
php4 on a system at once, making a /usr/share/php and putting both 3&4
scripts in there would be a Bad Idea (IMO).  If you believe there is still
enough life in php3 (there may be, I don't know) then I think that, by
analogy, a /usr/share/php3 directory, with a similar purpose, would be
practical.

Or, alternately, we could go with a more Perl-like system -
/usr/share/php/{version}.  {version} would be either 3 or 4, and then we
could easily go into subversions if there was any sense in it.  Since PHP
packages are only available in major versions (unlike Perl, which is
packaged as (eg) perl5.6) I don't think that /usr/share/php/4.1.2 is really
feasible.  If your PHP library needs a particular version of PHP, you just
make a versioned depends on whatever the minimum version of php4 is that you
need.


-- 
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org

Re: [PHP] Placement of PHP programs?

[Ian Zimmerman]

Fabien> Shouldn't webpage go to /var/www or at least /var/, and _not_
Fabien> /usr/share ? We are talking about PHP, but it's still webpages
Fabien> after all.

Matthew> I don't know of any web server which doesn't support an
Matthew> equivalent concept to Apache's aliases; I feel that /var/www
Matthew> (and I think practice bears me out) is pretty much local
Matthew> space - we don't fiddle with it (except when putting an
Matthew> *initial* web site in on install - which is never again
Matthew> touched after that).

hmmm ...

kronstadt:~# ls -l /var/www
total 9
lrwxrwxrwx1 root root   55 Aug 21 23:27 docbook-dsssl -> 
/usr/share/sgml/docbook/stylesheet/dsssl/modular/images
lrwxrwxrwx1 root root   18 Aug 31 19:20 dwww -> 
/var/lib/dwww/html
-rw-r--r--1 root root 4110 Jun 19 10:16 index.html
drwxr-xr-x2 root root  264 Aug 31 18:57 info2www
kronstadt:~# dpkg -S /var/www/*
docbook-dsssl: /var/www/docbook-dsssl
dwww: /var/www/dwww
dpkg: /var/www/index.html not found.
info2www: /var/www/info2www

i'm not necessarily saying it's a good thing, though :)

-- 
Ian Zimmerman, Oakland, California, U.S.A.
GPG: 433BA087  9C0F 194F 203A 63F7 B1B8  6E5A 8CA3 27DB 433B A087
EngSoc adopts market economy: cheap is wasteful, efficient is expensive.

Re: [PHP] Placement of PHP programs?

[Matthew Palmer]

On 2 Sep 2002, Ian Zimmerman wrote:

> Matthew> I don't know of any web server which doesn't support an
> Matthew> equivalent concept to Apache's aliases; I feel that /var/www
> Matthew> (and I think practice bears me out) is pretty much local
> Matthew> space - we don't fiddle with it (except when putting an
> Matthew> *initial* web site in on install - which is never again
> Matthew> touched after that).
> 
> kronstadt:~# ls -l /var/www
> total 9
> lrwxrwxrwx1 root root   55 Aug 21 23:27 docbook-dsssl -> 
> /usr/share/sgml/docbook/stylesheet/dsssl/modular/images
> lrwxrwxrwx1 root root   18 Aug 31 19:20 dwww -> 
> /var/lib/dwww/html
> -rw-r--r--1 root root 4110 Jun 19 10:16 index.html
> drwxr-xr-x2 root root  264 Aug 31 18:57 info2www
> kronstadt:~# dpkg -S /var/www/*
> docbook-dsssl: /var/www/docbook-dsssl
> dwww: /var/www/dwww
> dpkg: /var/www/index.html not found.
> info2www: /var/www/info2www
> 
> i'm not necessarily saying it's a good thing, though :)

It's a very bad thing, in my opinion.  If (for whatever reason) you'd
had a directory called dwww when you'd installed dwww, you'd have lost it
all (I think - I don't think I've ever hit the situation personally).  Not a
preferred outcome, in my eyes.


-- 
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org

Re: [PHP] Placement of PHP programs?

[Ian Zimmerman]

Matthew> On 2 Sep 2002, Ian Zimmerman wrote:
Matthew> I don't know of any web server which doesn't support an
Matthew> equivalent concept to Apache's aliases; I feel that /var/www
Matthew> (and I think practice bears me out) is pretty much local
Matthew> space - we don't fiddle with it (except when putting an
Matthew> *initial* web site in on install - which is never again
Matthew> touched after that).

itz> kronstadt:~# ls -l /var/www
itz> total 9
itz> lrwxrwxrwx1 root root   55 Aug 21 23:27 docbook-dsssl -> 
/usr/share/sgml/docbook/stylesheet/dsssl/modular/images
itz> lrwxrwxrwx1 root root   18 Aug 31 19:20 dwww -> 
/var/lib/dwww/html
itz> -rw-r--r--1 root root 4110 Jun 19 10:16 index.html
itz> drwxr-xr-x2 root root  264 Aug 31 18:57 info2www
itz> kronstadt:~# dpkg -S /var/www/*
itz> docbook-dsssl: /var/www/docbook-dsssl
itz> dwww: /var/www/dwww
itz> dpkg: /var/www/index.html not found.
itz> info2www: /var/www/info2www
itz> 
itz> i'm not necessarily saying it's a good thing, though :)

Matthew> It's a very bad thing, in my opinion.  If (for whatever
Matthew> reason) you'd had a directory called dwww when you'd
Matthew> installed dwww, you'd have lost it all (I think - I don't
Matthew> think I've ever hit the situation personally).  Not a
Matthew> preferred outcome, in my eyes.

Well, I have always held (right or wrong) pretty much the opposite
view to yours: /var/www _is_ for Debian content, and local content
belongs in /usr/local.  (thats why you don't see all that much in my
/var/www :-] )

-- 
Ian Zimmerman, Oakland, California, U.S.A.
GPG: 433BA087  9C0F 194F 203A 63F7 B1B8  6E5A 8CA3 27DB 433B A087
EngSoc adopts market economy: cheap is wasteful, efficient is expensive.

Re: Improper NMU (Re: NMU for libquota-perl)

[Anthony Towns]

On Mon, Sep 02, 2002 at 10:41:39AM +0200, Sebastian Rittau wrote:
> On Sun, Sep 01, 2002 at 09:06:20PM -0400, Elie Rosenblum wrote:
> > The NMU was made before I was in any way contacted.
> Would you please stop bitching, you're getting on my nerves. Except you
> nearly nobody sees this as a problem.

Well, it is, for the simple reason that it annoys most maintainers
immensely. See either:

] Bug fixes to unstable by non-maintainers are also acceptable, but only
] as a last resort or with permission.  The following protocol should be
] respected to do an NMU:
]
]* Make sure that the package's bug is in the Debian Bug Tracking
]  System (BTS).  If not, submit a bug.

-- developers-reference

or

] If the bug
] hasn't been filed yet, or the patch hasn't been sent to the bug,
] you almost certainly shouldn't be making an NMU... yet.

-- "It's Huntin' Season", posted to -devel-announce in January

You do need to file the bug reports before NMUing. Not necessarily all
that much before -- doing an NMU *doesn't* actually make it any harder
for the maintainer to do an upload later, whether it feels like it or
not -- but before, nevertheless. Anyway, I've already said everything
I might want to say about it in the -devel-announce post, so I'll leave
it at that.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''


pgpoo1mQ4uTrb.pgp
Description: PGP signature

Re: [PHP] Standard placement of PHP libraries?

[Matthew Palmer]

On Mon, 2 Sep 2002, Steve Langasek wrote:

> > But what about every other PHP extension library out there?  libphp-adodb,
> > for instance, uses /usr/lib/adodb - in violation of the FHS, I believe,
> > since PHP scripts shouldn't be architecture specific.  But that's not really
> > the issue here - the point is, where *should* PHP includes go?
> 
> Adam Conrad and I have begun hammering out a PHP mini-policy (not yet
> ready for public consumption)

Oops, I must have missed that discussion.  Is there any particular reason
why it's been a private thing, rather than a public process?

> that calls for all PHP classes to be
> shipped in /usr/share/php.  Yes, PEAR obviously violates this at present
> -- so transitioning to the new scheme will require shipping a default
> include path that looks in both /usr/share/php and /usr/share/pear.

Indeed.

> In discussing this, we concluded that most PHP classes currently use
> their own directories as a means of eliminating namespace collisions;
> however, this is clearly inappropriate, as it pushes the burden of
> resolving collisions on the user, rather than on the maintainer.  PHP's
> handling of classes should be the same as that of other scripting
> languages, such as perl and python.

Well, Perl uses version-specific directories, and I'm not a Python person,
so I can't comment on that.  But yes, PHP is another scripting language with
most of the same issues, so it makes sense to follow the conventions of
other languages were appropriate.

> > I would like to propose /usr/share/php4 as the place for all scripts
> > intended to run under php4 (whatever subversion) and intended for inclusion
> > in other PHP scripts.  All packages would install their inclusion hierarchy
> > under /usr/share/php4/, and scripts which wanted to use their
> > functionality would include('/include.php').  Naming of
> > include files, including their extension, would be left to the discretion of
> > individual maintainers.
> 
> We had ruled out /usr/share/php4, on the grounds that many, if not most,
> PHP classes are not specific to php4; some will work with php3, and many
> should be forward-compatible with php5.

I'm happy to concede that point.  I'm pretty much a php4-only person, and
don't take an active hand in the larger world of PHP development.

> As far as using /usr/share/php4/, I'm not aware of any such
> requirement for other scripting languages.  I think it's reasonable to
> allow PHP packages to install their classes in the manner which is most
> convenient, and let package conflict resolution take care of the rest. 
> PEAR already provides us a structure for the namespace, which we ought to
> take advantage of.

I was modelling that from what I'd done with phtml; to reduce possible
conflict (and to provide a migration path from what I'd been doing prior to
my stuff becoming Debianised).  Removing the package name requirement is not
a big issue for me; I'm just a little excessively orderly.  

Could I request that you open up your PHP mini-policy a little?  I'm sure
there are a lot of people interested in this issue; and I for one would like
to see the direction you're heading.


-- 
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org

Re: RFC: A regression test framework for Debian packages?

[Anthony Towns]

On Mon, Sep 02, 2030 at 11:20:05AM +0200, J?r?me Marant wrote:
> He mentioned that we lack regression tests for packages,
> but as far as I know, no solution has been found.

Yay! 'bout time someone took this particular ball and ran with it!

> What?
> -
>   The main idea is to make tests on package installation
>   and after their installation is completed.

Build time is important too: that's the only time you can attempt fine
grained testing of modules rather than executables, and it lets you catch
problems before you upload too. eg, after some irritating bugs that happened
to only show up on one or two architectures, I added some regression tests
to ifupdown, which basically:

(1) made up a fake interfaces file
(2) made up a file with the expected output
(3) invoked ./ifup -nv --force -a -i  
(4) checked the results matched

It's a fairly straightforward shell script, albeit a bit messy and
confusing. At least I can be fairly confident that the particular bug
that caused me enough grief to write all that won't appear again quite
so subtly. It probably only work since ifup can act, essentially, as
a "filter" so you can run it without having to worry about hardware
requirements and such. A lot of programs, and a lot of problems,
that you'd like to have regression tests for can't do that. Dunno if
it matters.

>   - tests on maintainer scripts: 
>   - debconf tests: 
>   - configuration files tests:
>   - application-specific tests: 

These all seem pretty hard to actually do. Useful, but hard. Something
that might also be useful, and isn't that hard could be letting you
check that particular files actually end up in the .deb you're creating,
with particular ownerships and permissions.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''

Bug#159392: ITP: tetrinetx -- GNU Tetrinet server

[Helios de Creisquer]

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

* Package name: tetrinetx
  Version : 1.13.16
  Upstream Author : Brendan Grieve <[EMAIL PROTECTED]>
* URL : http://tetrinetx.sf.net/
* License : GPL
  Description : GNU Tetrinet server

 The GNU tetrinet server, very complete configuration options,
 includes qirc IRC server.

I saw a mail about it in debian-devel long time ago (2000) saying that
no packaging should be done unless the license change. This is it,
license is now GPL. But I cant find any ITP in the BTS about this
package, just a recent RFP, so I close it in the meantime.

You can check preliminary package at http://balios.org/tetrinetx/

Cheers,
-- 
   Helios de Creisquer  <[EMAIL PROTECTED]>
http://www.tuxfamily.org/<[EMAIL PROTECTED]>
http://www.vhffs.org/<[EMAIL PROTECTED]>
http://www.gnu.org/<[EMAIL PROTECTED]>
GPG(1024D/96EB1C44): FB11 8B80 4D86 D9C2 DE0C 11D7 2FA8 A5CC 96EB 1C44


pgp5plrcGjZ8h.pgp
Description: PGP signature

Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my

[Brian May]

On Sat, Aug 31, 2002 at 01:38:52PM +0200, Peter Palfrader wrote:
> Still, the Packages files should only be removed after no software in
> our stable distribution depends on it. If you remove the Packages file
> from unstable now you will break apt-proxy (and perhaps other tools
> too).

Does apt-proxy use Packages? In my tests, it always seems to use
Packages.gz, even for rsync. Or maybe I am getting confused between
requested file by client and the file downloaded by apt-proxy?

pbuilder does seem to require downloading Packages, not Packages.gz.
Why? Is this a debootstrap bug?

scrooge:/home/bam/source/debian/amavis/amavis-20020517# pbuilder create 
--basetgz base-unstable.tgz --distribution unstable
W: /root/.pbuilderrc does not exist
Distribution is unstable.
Building the build environment
 -> running debootstrap
I: Retrieving http://snoopy.apana.org.au:8081/debian/dists/unstable/Release
I: Validating 
/var/cache/pbuilder/build/8772/./var/lib/apt/lists/debootstrap.invalid_dists_unstable_Release
I: Retrieving 
http://snoopy.apana.org.au:8081/debian/dists/unstable/main/binary-i386/Packages

This means it has to download the entire uncompressed file, when the
compressed file is already cached by apt-proxy.
-- 
Brian May <[EMAIL PROTECTED]>

Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my

[Anthony Towns]

On Tue, Sep 03, 2002 at 11:15:14AM +1000, Brian May wrote:
> pbuilder does seem to require downloading Packages, not Packages.gz.
> Why? Is this a debootstrap bug?

debootstrap downloads Packages.bz2, Packages.gz, or Packages in order
of preference, depending on which are listed in the Release file. 

> I: Retrieving 
> http://snoopy.apana.org.au:8081/debian/dists/unstable/main/binary-i386/Packages

So that seems a bit odd.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''

Re: [PHP] Placement of PHP programs?

[Matthew Palmer]

On 2 Sep 2002, Ian Zimmerman wrote:

> Matthew> It's a very bad thing, in my opinion.  If (for whatever
> Matthew> reason) you'd had a directory called dwww when you'd
> Matthew> installed dwww, you'd have lost it all (I think - I don't
> Matthew> think I've ever hit the situation personally).  Not a
> Matthew> preferred outcome, in my eyes.
> 
> Well, I have always held (right or wrong) pretty much the opposite
> view to yours: /var/www _is_ for Debian content, and local content
> belongs in /usr/local.  (thats why you don't see all that much in my
> /var/www :-] )

That's a reasonable interpretation.  Not what I'd go with, though.  Do you
have your DocumentRoot reconfigured?  How do you handle having both Debian
content and local content available side-by-side?


-- 
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org