Re: Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation

[P.]

Hello.

I've talk to Stuart since a lot time ago about all this, but forgot to
look over his late work on the fonts part that was missing. I tough that
was a little bit more delyaed than it is. That is my fault for not
checking and I'm sorry.

Now I will test the fonts against my op-panel package, which is my own
responsability now.

I also want to apologize for the problems I had with my email account.
This was a situation that escaped my control and I hope you all people
never get in that situation so people like Rene Engelhard don't treat
you like this:

"Alejandro (in case you read that in the buglog since your §%&§
mailserver doesn't accept mail)..."

Regards, and thanks for your time.

-- 
Alejandro Ríos Peña



signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: Orphaning my packages

[P.]

El mar, 12-09-2006 a las 16:21 -0500, David Moreno Garza escribió:

> Here is the list:
> http://qa.debian.org/developer.php?login=damog&comaint=no
> 

I'll take gnome-schedule if none has done it.



-- 
Alejandro Ríos Peña



signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Bug#370192: ITP: python-pycairochart -- Python module for creating 2D-Charts using the Cairo library

[P.]

Package: wnpp
Severity: wishlist
Owner: "Alejandro Rios P." <[EMAIL PROTECTED]>

* Package name: python-pycairochart
  Version : 0.1.1
  Upstream Author : Martin Lesser <[EMAIL PROTECTED]>
* URL : http://bettercom.de/de/pycairochart
* License : GPL
  Description : Python module for creating 2D-Charts using the Cairo
library

 It is possible to draw charts with:
  * 2 y-axis with independent scaling
  * one or more values per x-segment, these may be stacked or drawn
  * side by side
  * legend added automatically
  * self defined fonts in any size
  * self defined colors in a "webish" style (i.e. "#FF")
  * localized formatted numbers (on y-axis)
  * self-defined margins between rectangles
  * suppressing null values



signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: Announcing a new book: The Debian System -- Concepts and Techniques

[p]

On Mon, Jun 27, 2005 at 03:05:03AM +0200, martin f krafft wrote:
> Dear all,
> 
> I am pleased to announce the availability of my new (English) book
> "The Debian System", which Open Source Press[0] introduced at the
> Linuxtag 2005. 

__deletia__

> -- 
>  .''`. martin f. krafft <[EMAIL PROTECTED]>
> : :'  :proud Debian developer and author: http://debianbook.info
> `. `'`
>   `-  Debian - when you have better things to do than fixing a system

//

mr. krafft:

i will never forget your genorisity in helping 
me, in rich detail,  with  an ethernet issue i 
posted on this list many years ago. therefore,
i look forward  to  buying  your  new book and 
proudly adding it to my linux library.  

congratulations!

//


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

Bug#301510: RFP: tinyerp -- ERP and CRM for small to medium businesses

[Fabien P.]

Package: wnpp
Severity: wishlist

* Package name : tinyerp
* Version: 2.0
* Upstream Author : Fabien Pinckaers <[EMAIL PROTECTED]>
* URL: http://tinyerp.org
* Licence: GPL
* Description:

Tiny ERP is a Enterprise Resource Planning and Customer Relationship
Management software for small to medium businesses. Written in Python,
using PostgreSQL and GTK.

Technical features include distributed server, flexible workflows,
object database, dynamic GUI, customizable reports, SOAP and XML-RPC
interface.

The main functional features are: CRM & SRM, analytic and financial
accounting, double-entry stock management, sales and purchases
management, tasks automation, help desk, marketing campaign, and
vertical modules for very specific businesses.

May be 2 packages; tinyerp-server & tinyerp-client ?


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

Stateless Debian Project

[gaurav p]

Hi,



We have just initiated  Stateless Debian Project and we are looking for 
active volunteers/developers

Detail of project are  given below  


Summary

This project was started by Fedora (Redhat) but is no longer in active 
development and  will  not be included in next release of fc4 , this 
projects aims to provide longterm commitment to the concept & port it to 
100% community based distro like Debian



Stateless Linux  converts normal Linux desktop/clients to Stateless 
machines or appliances, which means if throw your computer out of window 
you still will be able to get exactly same same settings/data when you log 
from any other pc in the network A single administrator can easily 
manage network  thousands of desktops ...Stateless Linux centralizes the 
state in a Gold server (different from CFengine) and  rest  of clients 
are updated regularly from it . This is different from thin clients as 
local processing power and memory of clients is used (or cached client)



http://sourceforge.net/projects/statelessdebian/

Project Goals



1) Port relevant parts of RH State Linux (http://fedora.redhat.com/projects/stateless/) to Debian

2)Extend/integrate/enhance Stateless Linux thru existing projects like  DBRL

http://drbl.sourceforge.net/debian/wiki-view/pmwiki-view.php/DRBL/WhatIsDRBL  


and Debian CCD infrastructure, FAI (Fully Automated Installation,http://www.informatik.uni-koeln.de/fai/) 
3) Add cluster support and node monitoring and autonomic capabilities 
4)Meets most of OSDL Desktop Linux specification

5) Long term community based , vendor neutral project

6) Member of "Move 2 Debian" project

7) Latter (2nd phase )Add p2p support for directory support(DHT),
file storage and retrieval(tuples), state transfer (Bittorent) to
elinimate any need of centralized servers/infrastructure and make it
highly scalable (to millions!!)





Right now this project is in pre beta stage and we are preparing
Stateless Linux White paper and started porting portions of RH
Stateless Linux to Debian .

Any  Suggestions/Ideas will appreciated  :-)  ..if anyone is interested from this  list then pl let me know 


Regards,

Gaurav 

Re: Stateless Debian Project

[gaurav p]

On 5/6/05, Christoph Berg <[EMAIL PROTECTED]> wrote:
Re: gaurav p in <[EMAIL PROTECTED]
>> We have just initiated Stateless Debian Project and we are looking for

its Stateless project by State full people ;-) 


Is the project itself also stateless such that it doesn't know whetherit already sent out an announcement?


oops !..sorry ... must due to  announcement mail did'nt reflect in mailing list for long time 

pretty girl

[dan p]

  howcome nobody talks anymore love lda   
		Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.

Re: i need urgent travel pr1

[j p]

i need seo, web design, logo design, animation, bpo, employment, HR related
sites ...
-- 
Thanking you,
webmaster regards,
seo.jets456 {...@} gmail.com
jets

Re: Convenient way to enable IDE DMA

[tomas p]

On Mon, 26 Aug 2002, Nate Eldredge wrote:

> Thoughts?

Propose a patch against the hdparm package?

debian transistion to gcc-3.2.1

[Frank P .]

Is there something holding back the transition? I have not noticed any 
discussion about it.

Debian 5.0 support for VMware ESX 3.5/4.0/ESXi 4.1

[Piotrek P]

Dear All,
Please be aware that VMware ESX 3.5 is NOT supporting any of Debian as Guest OS.
Please be aware that VMware ESXi 4.1 IS supporting Debian 4.0, 5.0 as Guest OS.
Please be aware that VMware ESX 5.0 IS supporting Debian 4.0, 5.0, 6.0
as Guest OS.

I would like to ask:
- What does it means for users of Debian 5.0 on ESXi 4.1 if support of
Debian 5.0 will end?
- What about repositories of Debian 5.0?
- How can I obtain informations about major changes in packages that
were changed in Debian 6.0 and future releases?
- What is official statement of VMware about not supporting newest
versions of Debian OS?
- How is it possible to be updated if VMware is not supporting newest
version of Debian OS?

Many thanks for answers.

Best regards,
Peter P.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMZ-jvqH981-e_J7fLAO1kDrX-HQBqV+tPMV8SCJ=oybhsq...@mail.gmail.com

Bug#743502: ITP: libip2location -- C library to query geolocation and other details of an IP

[Nahar P]

Package: wnpp
Severity: wishlist
Owner: Nahar P 

* Package name: libip2location
  Version : 6.0.2
  Upstream Author : Liew 
* URL : https://www.ip2location.com/downloads/c/
* License : GPL
  Programming Lang: C
  Description : C library to query geolocation and other details of an IP

 IP2Location C library enables the user to find the country, region, city,
 coordinates, zip code, time zone, ISP, domain name, connection type, area code,
 weather, MCC, MNC, mobile brand name, elevation and usage type that any IP
 address or hostname originates from. It has been optimized for speed and 
 memory utilization.
 This Package provides the header files and static libraries for development.

 The library had been there from 2005, is very stable and used by many people.
 They also have a opensource database to use with this library.
 I would like to maintain this package but would need a DD as sponsor. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140403134637.21187.12440.report...@earth.invothink.net

Bug#744376: ITP: grub-customizer -- Grub Customizer is a graphical interface to configure the GRUB2/BURG settings and menuentries.

[magnus p.]

Package: wnpp
Severity: wishlist
Owner: "magnus p." 

* Package name: grub-customizer
  Version : 4.0.4
  Upstream Author : Daniel Richter 
* URL : https://launchpad.net/grub-customizer/
* License : GPLv3
  Programming Lang: C++
  Description : Customize the bootloader (GRUB2 or BURG).

Grub Customizer is a graphical interface to configure the GRUB2/BURG settings 
and menuentries

Features:
 * move, remove or rename menuentries (they stαy updatable by update-grub)
 * edit the contents of menuentries or create new ones (internally it edits the 
40_custom)
 * support for GRUB2 and BURG
 * reinstallation of the bootloader to MBR
 * settings like default operating system, kernel params, background image and 
text colors etc.
 * changing the installed operating system by running on a live cd


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140413135035.4355.85636.reportbug@debian.magnus

Empowering Your Audience for Financial Success

[Amy P]

 Hi,

Financial wellness is a major concern for people in today's fast-paced
world. It may come as a surprise that 65% of Americans do not have access
to proper financial planning or advice.

As a publisher, you can curate and deliver your subscribers the right
content and tools. By connecting them with reputable financial advisors,
educational materials, and interactive tools, you empower them to make
informed decisions and take control of their financial well-being.

In addition to fostering loyalty, Kapitalwise Advisor Connect opens up new
revenue streams for your publishing business. By partnering with
Kapitalwise, you can generate revenue from your content while providing
value-added financial advice to your subscribers.

The AdvisorConnect

widget recommends local financial wellness resources to site visitors. On
the backend, it helps you earn additional revenue through lead generation
for our clients. Adding it to your site is super simple. You can signup for
a free account here
.

If you want to schedule a quick demo of how it works schedule it on my
calendar
and
I'll be happy to show you how you can get additional revenue.
I'm looking forward to hearing from you.
Speak soon!

All the best,

Amy Pablo

Account Executive

Kapitalwise
2013811845 <+1-630-400-1220>
a...@kapitalwise.com
www.kapitalwise.com 
43 W23rd Street, New York, NY, 10010
[image: facebook]

[image: twitter]

[image: linkedin]

Informatics

[p db]

What meant the term: "Informatics"?

The term: "Informatics"; was coined in 1962 by Philippe Dreyfus and derives
from the French language and would mean:

"Automatic Information" !

In Italian it means:

"Automatic Information"!

Subsequently the term " Automatic Information", over the decades, became:
"Informatics"; and no one took care to remember the roots of the word and
to highlight the true meaning in the French language.

Philippe Dreyfus, was born in Paris on 04 November 1925 and died on 30 July
2018 in Biarritz; he was a pioneer in the Informatics industry.

After taking the Master's Degree in Physics in 1950, at the Higher School
of Physics and Industrial Chemistry in Paris, he was hired as Professor of
Computer Science at Harvard University, where he used the computer:
"Harvard Mark I" which was funded by (IBM) International Business Machine
for its construction.

Please read carefully the website:

https://fr.m.wikipedia.org/wiki/Informatique

Best Regards,

Paolo Del Bene [17bdP]

Re: General Resolution: Richard Stallman's readmission to the FSF board

[T P]

On Thu, Mar 25, 2021 at 05:13:52PM -0400, Kurt Meyer wrote:
> On Thu, Mar 25, 2021, at 17:04, Debian Project Secretary - Kurt Roeckx wrote:
> > 
> > A General Resolution has been started about Richard Stallman's
> > readmission to the FSF board.
> > 
> > It currently has 1 available options, but other proposals have been 
> > suggested.
> > 
> > More information can be found at:
> > https://www.debian.org/vote/2021/vote_002
> > 
> > 
> > Kurt Roeckx
> > Debian Project Secretary
> > 
> 
> Based on the wording of the general resolution, it appears that you and
> others basically disagree with RMS on issues. Is that a good reason to
> do what you're doing? In my opinion, it is not. Work on Debian Linux,
> not participate in the hatefulness of Cancel Culture.


Silence is the best troll poison.

Bug#865757: ITP: node-ansistyles -- prints output in different styles

[Saravanan P]

Package: wnpp
Severity: wishlist
Owner: saravanan30erd 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-ansistyles
  Version : 0.1.3
  Upstream Author : Thorsten Lorenz  (thlorenz.com)
* URL : https://github.com/thlorenz/ansistyles
* License : Expat
  Programming Lang: JavaScript
  Description : prints output in different styles

 Functions that surround a string with ansistyle codes so it prints in style

 It is dependency package for NPM

Bug#866001: ITP: node-debuglog -- used for debugging

[Saravanan P]

Package: wnpp
Severity: wishlist
Owner: saravanan30erd 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-debuglog
  Version : 1.0.1
  Upstream Author : Sam Roberts 
* URL : https://github.com/sam-github/node-debuglog
* License : Expat
  Programming Lang: JavaScript
  Description : used for debugging

 used for debug logging.
 .
 This library is a dependency of npm, Node.js package manager.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#866242: ITP: node-editor -- Launch the $EDITOR in your program.

[Saravanan P]

Package: wnpp
Severity: wishlist
Owner: saravanan30erd 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-editor
  Version : 1.0.0
  Upstream Author : James Halliday  (http://substack.net)
* URL : https://github.com/substack/node-editor
* License : Expat
  Programming Lang: JavaScript
  Description : Launch the $EDITOR in your program

 Launch the $EDITOR (or opts.editor) for file.
 When the editor exits, cb(code, sig) fires.
 .
 This library is a dependency of npm, Node.js package manager.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#866787: ITP: node-iferr -- Higher-order functions for easier error handling

[Saravanan P]

Package: wnpp
Severity: wishlist
Owner: saravanan30erd 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-iferr
  Version : 0.1.5
  Upstream Author : Nadav Ivgi
* URL : https://github.com/shesek/iferr
* License : Expat
  Programming Lang: JavaScript
  Description : Higher-order functions for easier error handling

 Example: if (err) return cb(err); be gone!
 .
 This library is a dependency of npm, Node.js package manager.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#868323: ITP: node-lazy-property -- Adds a lazily initialized property to the object.

[Saravanan P]

Package: wnpp
Severity: wishlist
Owner: saravanan30erd 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-lazy-property
  Version : 1.0.0
  Upstream Author : Mikola Lysenko
* URL : https://github.com/mikolalysenko/lazy-property
* License : Expat
  Programming Lang: JavaScript
  Description : Adds a lazily initialized property to the object

 E.G. require("lazy-property")(obj, name, init[, enumerable])
 obj is the object to add the property to
 name is the name of the property
 init is a function that computes the value of the property
 enumerable if the property is enumerable (default false)
 .
 This library is a dependency of npm, Node.js package manager.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#1073553: ITP: libgeo-converter-wkt2kml-perl -- a package to convert between WKT and KML standards

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: "Francesco P. Lovergine" 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: libgeo-converter-wkt2kml-perl
  Version : 0.0.3
  Upstream Contact: OHTSUKA Ko-hei 
* URL : https://metacpan.org/release/Geo-Converter-WKT2KML
* License : Perl Artistic
  Programming Lang: Perl
  Description : A package to convert between WKT and KML standards

  Geo::Converter::WKT2KML provides two functions, wkt2kml and kml2wkt.
  They convert geometry formats WKT (Well-Known Text) and KML
  each other. While the WKT spec is completely implemented, the KML
  spec is not completely interpreted.

-- 
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Bug#1074409: ITP: jeolib-miallib -- JRC morphological and image processing library

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: Francesco Paolo Lovergine 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org

Package: wnpp
Severity: wishlist
Owner: Francesco Paolo Lovergine 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org

* Package name: jeolib-miallib
  Version : 1.1.3
  Upstream Contact: Pieter Kempeneers 
* URL : https://github.com/ec-jrc/jeolib-miallib
* License : GPL
  Programming Lang: C
  Description : JRC morphological and image processing library

 Miallib is a C library including image processing and
 mathematical morphology algorithms used by Join Research Center
 in their Big Data Analytics Platform, with binding for Python
 provided.
 .
 This is the first component of the JRC PyJeo C++ and Python
 library, but can be used as a standalone library too.

-- 
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Bug#1074581: ITP: libtie-aliashash-perl -- module to provide hash with aliases key (multiple keys, one value)

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: Francesco Paolo Lovergine 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtie-aliashash-perl
  Version : 1.02
  Upstream Contact: Aldo Calpini 
* URL : https://metacpan.org/release/Tie-AliasHash
* License : Artistic
  Programming Lang: Perl
  Description : module to provide hash with aliases key (multiple keys, one 
value)

 Tie::AliasHash creates hashes that can have multiple keys for a single value.
 This means that some keys are just 'aliases' for other keys.
 
 Two aliases keys share the same value, so that fetching either of them will
 always return the same value, and storing a value in one of them will change
 both.
 
 The only difference between the two keys is that aliased key is not reported
 by keys() and each().

-- 
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Bug#1078554: ITP: guile-commonmark -- module to parse CommonMark documents, a fully specified Mardkdown variant

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: "Francesco P. Lovergine" 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: guile-commonmark
  Version : 0.1.2
  Upstream Contact: Erik Edrosa 
* URL : https://github.com/OrangeShark/guile-commonmark
* License : LGPL-3+
  Programming Lang: Guile
  Description : module to parse CommonMark documents, a fully specified 
MardkDown variant

 A module written in Scheme to parse CommonMark documents, a Markdown variant 
fully specified
 here: https://commonmark.org/ which is a strongly defined specification 
without ambiguities.
 This module parse CM documents and convert them in SXML, by using only pure 
Guile Scheme.

-- 
⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61
⠈⠳⣄ ED02 0F02 A5E1 1636 86A4

Re: Bugzilla package in need of help

[Francesco P. Lovergine]

On Wed, Oct 20, 2004 at 09:55:19PM +0200, Moritz Muehlenhoff wrote:
> In gmane.linux.debian.devel.mentors, you wrote:
> > - I did not verify that the new .orig.tar.gz is indeed genuine
> 
> md5sums are identical with upstream's tarball, I just double checked.
> 
> > - the following duplicates the call to fix_www_data_perm for
> >   /var/cache/bugzilla, and in addition, this change should be mentioned in 
> > the
> >   changelog referring to a bugreport (I now cannot check the validitiy of 
> > this
> >   change since I don't see why this is changed)
> 
> I'm afraid I forgot why this was added (it's been roughly three months).
> Judging from the code it looks like some left over test code and can be
> removed.
> 
> Cheers,
> Moritz

I'm looking into the package now. Stay tuned.

-- 
Francesco P. Lovergine

Re: AMD64 Archive Key compromised!

[Francesco P. Lovergine]

On Fri, Oct 29, 2004 at 08:52:07AM +0200, Jens Schmalzing wrote:
> 
> I guess this is the modern version of "real men just upload their
> important stuff on ftp, and let the rest of the world mirror it."
> 

RMS used to have no password at MIT times, indeed :) 
How times changed!

-- 
Francesco P. Lovergine

Re: more current iproute

[Milan P. Stanic]

On Wed, Nov 10, 2004 at 11:18:46AM +0100, Andreas Barth wrote:
> I uploaded the current version of iproute (that also works with current
> 2.6-kernels) to experimental. As this is a major change, any test
> reports are appreciated. Also, a review of the source whether I managed
> to keep all security patches might be a good idea (I'm quite confident
> that I did, but - a independent look might be a good thing).

Finally. Thanks!
It is worth backport to woody. I'm doing that right now.

> Please note that I'm aware that the package documentation is not in the
> best state, but as this was a NMU, I didn't do the changes that I would
> have done with a normal maintainer upload.

Why version is iproute_20041019 while the upstream is
iproute2-2.6.9-041019? Upstream version is 2.6.9 actually. Date is
appended to serve as timestamp, I think.

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Milan P. Stanic]

On Wed, Dec 01, 2004 at 05:34:34PM +0100, Michelle Konzack wrote:
> I do not like to go to prison in Iran or may be killed
> because I have such application on one of my Desktops. 

If you can be killed because you have such application (picture) then
you are in big trouble, anyway.
I like to have such application (picture) not because I actully like
this sorts of pictures, but because I like to be free to choose what
I want to have.

If someone take this one from me today, I might have not a photo of
my daughter without the veil over her face tomorrow.

Freedom is taken out piece by piece, history tell us.

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Milan P. Stanic]

On Tue, Nov 30, 2004 at 06:17:37PM -0600, Ron Johnson wrote:
> However, I'd be *highly* agitated if someone gave my daughter a 
> CD-ROM with *any* nudy cartoons.

I'd rather live with this risk than with less freedom.

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Milan P. Stanic]

On Wed, Dec 01, 2004 at 09:10:30PM +, Andrew Suffield wrote:
> The only genuinely neutral content is the output of /dev/random; all
> else is subjective.

What if /dev/random produce picture of hot-babe :-)
[ It is possible, in theory at last. ]

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Milan P. Stanic]

On Thu, Dec 02, 2004 at 05:01:57PM +0100, Michelle Konzack wrote:
> Some of the islamic countries like Turkey, Jordania and Morocco

Turkey isn't islamic country but secular one, AFAIK.

Re: eleventh-hour transition for mysql-using packages related to apache

[Francesco P. Lovergine]

FYI: new mysql FLOSS includes OpenSSL license, so many packages could
migrate to current libmysqlclient starting from no starting from now..

-- 
Francesco P. Lovergine


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

Re: Bug#295122: RFA: iproute -- Professional tools to control the networking in Linux kernels

[Milan P. Stanic]

Hi Andi,

On Sun, Feb 13, 2005 at 09:39:15PM +0100, Andreas Barth wrote:
> Package: wnpp
> anyone who wants to work on iproute is greatly welcome, perhaps also as
> co-maintainer (and I'm also willing to sponsor people). The reason I 
> intend to give the package away is that I'm not really the great
> networking guy, but I'll try to give the package a warm home till I can
> pass it over to someone else -- and as iproute is quite vital for
> some purposes, I'll do some checks before giving the package away. It is
> _not_ orphaned, I'm "only" looking for somebody else for maintaining.

I raise my hand. I'm not DD so your sponsorship will be appreciated.
I'm subscribed to linux-net (but not netdev) for years so I follow
changes in package.


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

Re: Bug#295328: general: Help messages to stderr should be banned

[Francesco P. Lovergine]

On Tue, Feb 15, 2005 at 07:38:08AM -0600, John Hasler wrote:
> Francesco P. Lovergine writes:
> > It depends on programs, sometimes the same usage function is used for
> > either --help or invalid options.
> 
> Sure, but the output should still be directed correctly.

Quite difficult if the function is the same. In both cases it uses stderr.

-- 
Francesco P. Lovergine


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

Re: Bug#295328: general: Help messages to stderr should be banned

[Francesco P. Lovergine]

On Tue, Feb 15, 2005 at 09:13:32AM -0800, Thomas Bushnell BSG wrote:
> "Francesco P. Lovergine" <[EMAIL PROTECTED]> writes:
> 
> > Quite difficult if the function is the same. In both cases it uses stderr.
> 
> Oh good grief.  Add an argument to the function saying where to direct
> the output.  How hard is this?
> 

Oh, well guys, I did not say it's correct. Just, a lot of people out
there are too lazy to write the code in the right manner. Even if trivial. 
Well, a lot of people is also too lazy to use snprintf() instead of sprintf().
That is a bit worst :-D

-- 
Francesco P. Lovergine


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

Bug#341242: ITP: minisip -- SIP phone, with GTK+ interface

[Alejandro Rios P.]

Package: wnpp
Severity: wishlist

* Package name: minisip
  Version : 0.7.0 
  Upstream Author : Erik Eliasson <[EMAIL PROTECTED]>
Johan Bilien <[EMAIL PROTECTED]>
* URL : http://www.minisip.org/
* License : (GPL, LGPL)
  Description : SIP phone, with GTK+ interface

 minisip is a soft telephone which uses the SIP protocol. It provides
 additional security, such as encryption and authentication, by using
 the SRTP (RFC3711) and MIKEY (RFC 3830) protocols. It uses GTK+ for
 the graphical interface.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.10-5-386
Locale: LANG=es_CO, LC_CTYPE=es_CO (charmap=ISO-8859-1)


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

Re: cvs loginfo configuration for alioth?

[Francesco P. Lovergine]

On Tue, Dec 06, 2005 at 10:15:15AM +0100, Martin Schulze wrote:
> Junichi Uekawa wrote:
> > Hi,
> > 
> > I'm looking for a 'loginfo' file configuration that works 
> > for alioth.
> > I thought I have found a solution few days ago, but when 
> > I came back, it no longer seems to work correctly:
> > 

The script used in debian-gis repo (pkg-grass) works like a charm. 
Feel free to use it... I also looked around a bit to have a working program
after alioth upgrade.

-- 
Francesco P. Lovergine


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

Re: buildd.debian.org (was Re: buildd administration

[Francesco P. Lovergine]

On Wed, Dec 14, 2005 at 05:23:48AM +, Nathanael Nerode wrote:
> (The contact addresses and machine up/down statuses are a valuable part of 
> buildd.net which *isn't* there, but that's another matter entirely, which 
> requires different and additional work.)
> 
> However, even though this is on the same machine, this isn't linked from the 
> main http://buildd.debian.org webpage, or from the Developer's Corner.  
> Meanwhile, the andrea link on http://buildd.debian.org is completely dead.  
> (http://buildd.debian.org/andrea/)
> 
> I politely request that a prominent link to 
> http://buildd.debian.org/~jeroen/status/ be placed on 
> http://buildd.debian.org/, and that the andrea link be either fixed or 
> removed.  This should take less than five minutes for someone with access to 
> the web pages.
> 

Changes in DD's corner contents should be discussed on d-www, eventually.
It already links official and unofficial urls and it seems reasonable
for listing those kinds of things.

-- 
Francesco P. Lovergine


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

debian-devel@lists.debian.org

[Milan P. Stanic]

Hi!

I could try to arrange donation of one UltraSparc machine to Debian
project. I think that the transport would be to complicated from
Serbia to anywhere (because of our laws) but I can connect it to the
Net for DD's to use it.

Machine CPU is: (whatever it means)

[EMAIL PROTECTED]:~# cat /proc/cpuinfo
cpu : TI UltraSparc I   (SpitFire)
fpu : UltraSparc I integrated FPU
promlib : Version 3 Revision 1
prom: 3.1.1
type: sun4u
ncpus probed: 1
ncpus active: 1
Cpu0Bogo: 285.08
Cpu0ClkTck  : 088601c0
MMU Type: Spitfire

It has 64Mb RAM, two 2GB scsi HD's, one CD drive, two RS232, one
paralell port, tape drive.

Could that machine be useful for Debian?

[ It worked fine under Potato/Woody for more than 5 years. ]


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

Re: Maintainer for fftw 2.1.3 requested

[Francesco P. Lovergine]

On Tue, Mar 14, 2006 at 11:30:44PM -0500, James A. Treacy wrote:
> I am surprised, as fftw is an excellent fft package and is still used
> by the following (they really should be updated to use fftw version
> 3 though). I would expect the maintainer of one of these to take an
> interest in this matter.
> 

I would doubt change fftw2 -> fftw3 in support would appear anytime soon 
for many packages. They are at least not compatible at API level, and in
scientific area people do not change things without a very
good reason to do that. Both releases are maintained by upstream AFAIK.

Maybe the fftw3 maintainer could be interested in maintainace of fftw2 too...

-- 
Francesco P. Lovergine


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

Re: Maintainer for fftw 2.1.3 requested

[Francesco P. Lovergine]

> 
> Maybe the fftw3 maintainer could be interested in maintainace of fftw2 too...

Oh well he, filled the ITA about that on December...

-- 
Francesco P. Lovergine


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

perl module packages: why do they exist?

[Adam P. Harris]

I don't understand why the debian developers are undertaking to
maintain debianified version of Perl modules when the CPAN module and
its mechanisms are so much more native to Perl, are well-supported by
the Perl community, etc?  Besides, Perl already has it's own automated
upgrade system (CPAN), it's own configuration mgmt system (Config),
and it's own automated compilation and installation system (MakeMaker).

It seems like making work for no good reason.  Let all the Perl
modules be installed by way of CPAN.  You could even have simple
scripts driving installation.  I really feel we'd have a better and
more supported Perl product that way.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: perl module packages: why do they exist?

[Adam P. Harris]

Adam> I don't understand why the debian developers are undertaking to
Adam> maintain debianified version of Perl modules when the CPAN
Adam> module and its mechanisms are so much more native to Perl, are
Adam> well-supported by the Perl community, etc?

[Manoj Srivastava <[EMAIL PROTECTED]>]
>   How do I remove packages using cpan? Can I downgrade to a
> lower version?

I'm not sure but I don't think so.  Probably, if you can think of some
cases why you need this functionality, you could ask the CPAN
maintainer to update these.

> make sure that all modules I have installed are
> upgraded? 

"install r" in CPAN

> Ensure that the perl modules that are available for auto
> handling have been looked over by an expert, *for the Debian system*
> specifically?

Well, no, but what I was saying is that you could easily have package
installing either custom debian bundles or individual modules as seen
fit. 

> Can other packages, that need modules, determine that
> they have been installed on my machine? 

Sure, although not with dpkg's standard method.  It's pretty trivial
to determine from Perl availability and the current version.  As
I'm sure you know.

> Can I hold a module to a the current version, even if new versions
> are available, while updating the rest?

Sure.  Just as easily using a perl native installer like CPAN as
you'll have doing it by hand.  And once you've got it going, it'll be
a lot easier to maintain.  In fact, you wouldn't have to maintain it
at all, let the Perl maintainers maintain it.

>   I think you underestimate the work a systems integrator does.

No, I'm just trying to minimize the work a debian package maintainer
has to do.

>   I am planning on creating a make-ppkg package that shall
> create perl packages just like make-kpkg creates kernel-image
> packages, but I'm still recovering from a disk crash, and I have
> other commitments at the moment.

Well that will help, but again, when you have CPAN and bundles and all
that, why bother?

Manoj, I just think you should talk to perl-porters about your issues
and concerns and see what they have to recommend.  IMHO, it's pretty
rare that I need to hold on a Perl module version, or that I'm hitting
serious configuration mgmt issues with the modules.  And since
MakeMaker already has it's own dependancy and x-platform building
system, it seems wasteful to replicate that.  And I know as a user
that the version lag impose by debian can be annoying.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

perl module packages: why do they exist?

[Adam P. Harris]

[You ([EMAIL PROTECTED])]
>About two months ago, I upgraded a CPAN bundle on a production server.
>Two interesting things happened:
>
>(1) perl itself got upgraded, and
>(2) wais got upgraded.

Huh??? Perl itself?  I don't think this is possible.

[...]
>Also, there are CPAN modules whose installation has a step which says
>something to the effect of "you must read the README".  The DBD stuff
>that Tim Bunce wrote comes to mind.  We can do a lot better.
[...]
>Essentially, if you use CPAN, you're always working with UNSTABLE.

Well, of course, I've maintained perl manually on 2 production servers for more 
than 2 years now, and have never had a problem.  I just wait until s/w is a 
couple of weeks old before upgrading them.

I can see your point and I can see the reason for having official packages and 
blessed versions of perl modules and all that.  I guess it's kinda a moot issue 
since if I feel like it I can always maintain my modules outside of pacakage 
control, say, using CPAN.

One thing is gonna burn me is if a package wants, say, perl lwp installed, and 
I did it in /usr/local/lib/perl/site_perl (i.e., w/ CPAN), the package won't 
know about that and I'd have to force it to install.  Don't know if there's any 
solution to that.

[Manoj said]
>   I am planning on creating a make-ppkg package that shall
>  create perl packages just like make-kpkg creates kernel-image
>  packages, but I'm still recovering from a disk crash, and I have
>  other commitments at the moment

Seems to me it'd be better to mess with MakeMaker so you could make debian 
packages right outta the module w/o additional help.  Should be doable.

BTW, is anyone working on any Debian-specific Perl modules?

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Intent to package: umich-ldap

[Adam P. Harris]

[Brian Bassett <[EMAIL PROTECTED]>]
> I was wondering if anyone was working on packaging the University of
> Michigan's LDAP server and client suite.  I noticed that hamm does
> not contain anything LDAP related and thought this might be a good
> addition.

According to the debian prospective packages list, 
  http://www.debian.org/doc/prospective-packages.html
Dermot Bradley <[EMAIL PROTECTED]> is working on that package.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

bo-updates packages

[Adam P. Harris]

[You (Hamish Moffatt)]
> Or does any of this matter ? :-)

The issue of keeping Debian bo crunchy and fresh w/o inhibiting the bold
experimentalism of the hamm lineage is critical to Debian's success.  I
know a lot of people, even within my company, using Debian in a production
environment, but frustrated by the lagginess of package such as xemacs,
perl, etc. etc.

I guess this is probably a policy discussion, but I'm not on that list.  I
was pleased to see the version numbering std.  Since there's no existing
policy documentation on keeping bo fresh based on a recompile of a hamm
package, maybe someone familiar with the discussion can answer the
following questions:

* Is it kosher for a non-package maintainer to do an upload of a hamm
  package recompile for bo? 
* Where would this non-maintainer-created upload go?
* Do std maintainer created packages get upload to a wierd place or to 
  the std place?

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

perl module packages: why do they exist?

[Adam P. Harris]

[APH: I'm CC'ing the CPAN.pm maintainer here, since I though Mssr 
 König might be interested in the issues we're having.  I'm going to 
 recap that discussion, if everyone will tolerate me a little.  Note
 also I use CPAN.pm to refer to the Perl module, and CPAN to refer to
 the actual archive.  Andreas, I'm not sure if your interested or
 even the right party to talk to, but feel free to forward this to
 anyone who might be interested or just trash this message.]

Andreas, this is part of discussion we're having on the Debian developer's
list concerning what I consider some conflicts existing between
the Perl module maintainence subsystem, CPAN.pm, and Debian's
package maintanance system.  (BTW, Debian is a free linux distribution, 
and is widely hailed as having the premier Unix s/w packaging system.)
I raised this thread, asking why Debian developers bothered making 
packages out of CPAN modules, when Perl already had dependancy tracking 
and update featuers.  Said developers pointed out some problems
they have with CPAN.pm and it's operations.  I guess the major reasons we 
need a Perl module version control mechnaism are the following:

* no good way to sync Perl module version numbers w/ Debian version 
  tracking (see below)
* quality control for Perl modules; put them thru testing before release

[You ([EMAIL PROTECTED])]
>Raul Miller <[EMAIL PROTECTED]> wrote:
>> >About two months ago, I upgraded a CPAN bundle on a production server.
>> >Two interesting things happened:
>> >
>> >(1) perl itself got upgraded, and
>> >(2) wais got upgraded.
> 
>Adam P. Harris <[EMAIL PROTECTED]> wrote:
>> Huh??? Perl itself?  I don't think this is possible.
>
>Take a look at TIMB/perl5.004_04.tar.gz

Wow.  Guess I'm a little out of it.

>It is automatically brought in when you install something in 
>CPAN that requires a more recent perl version that what you
>have.

There should be a flag to disable this behavior!

>Of course, you can bail out of the install at that point, but that's not
>the issue here.
>
>In my opinion, once we've evolved a good cpan->debian packager, we
>should integrate it with the CPAN module so that it uses this mechanism
>to build, test and install cpan modules.  Presumably, it should also
>archive the installed package somewhere (at least as an option), and
>manage minor revision numbers automatically.

I completely agree.  I suppose this is a ExtUtils issue?  So as I under
stand you, say, the Makefile produced by `perl Makefile.pl' would, say, 
have a 'debian-pkg' rule or something.  Right?

>Further, it's going to be essential that we get dependencies *right*
>for the part of the system which can be managed via CPAN. This is going
>to be tricky -- since dependency information in cpan is embedded in
>makefile rules, we'll probably have to implement a shared database so
>that as people use the system we accumulate such information. [This
>might also be a fertile ground for people to get together when thrashing
>out problems with fringe packages.]

Can't you pull out module version numbers from the modules themselves?  I 
think this is what ExtUtils does when it makes `Makefile'.

I think the way to do this is to add some state to install Perl modules.
Modules installed with dpkg should be distinguishable from user installed
(say using CPAN.pm) modules.  Actually, no need to add state when it's
already there; user-installed modules are installed in 
/usr/local/lib/perl5/site_perl.  The next step would be to try to hack
CPAN.pm to disallow updating (or overriding by having copies in 
/usr/local/lib/ perl5) files which _must_ by Debian policy be under package
management control (i.e., /usr/lib/perl5). 

The corollary to this is that users who insist on installing a packaged
and installed module right from CPAN must first remove the package (?).
This would disallow installation of packages that rely on that Perl
module, which is probably desired behavior.  Debian hackers could always 
override the dependancies.

Manoj, I guess I just now have come around to where you were all along? ;)

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


pgp4nG9DwGnjB.pgp
Description: PGP signature

Re: Where's the SCSI support in Debian?

[Adam P. Harris]

["Marcelo E. Magallon" <[EMAIL PROTECTED]>]
>> at the time bo was released, the options for the kernel were 2.0.29
>> and 2.0.30. as 2.0.30 turned out to be unstable on some machines,
>> debian decided to use the 2.0.29 kernel. the only problem is :
>> buslogic flashpoint support started with 2.0.30 :-(

> Does that mean that Debian cann't be installed "easily" on a machine
> with a Buslogic FlashPoint PT and no IDE disks? 

There's already a bug on this:

#12747: 1997-08-01 Boot Disks lack FlashPoint SCSI Support
  Package: bootdisk; Reported by: Jeff Noxon <[EMAIL PROTECTED]>; 85 days 
old. 

See the long discussion at http://www.debian.org/Bugs/db/12/12747.html

[...]

> Is this going to change soon... I mean, 2.0 is still months away,
> and it kind of scares me to think of many users facing "way till
> 2.0"

Yes, well, the rescue/boot/base sequence should use 2.0.32 anyhow.
While they're at it, they should _confirm_ that the PCMCIA subsystem
(pcmcia-cs pcmcia-modules) all work with the kernel from the rescue
disk etc. (Actually I'm going to test this right now with the 15 Oct
boot disks.)

I had _very_ difficult time getting debian installed on my laptop by
way of an NFS served CDROM on another linux box.  Good think I had
another linux box on which I could compile stuff.  I basically had to
roll my own kernel and pcmcia stuff.

I assume Maintainer Group <[EMAIL PROTECTED]> is on this
list.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

[PGP]: can someone in NYC sign me?

[Adam P. Harris]

I'm hoping to get my PGP keys signed by a known and registered debian
developer in the NYC area so as to comply with the Debian Developer's
Reference Section 1.2.

I'm located in Manhattan; specifically on the Lower East Side.
Any takers?  Please reply to me offline.  Thanks.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Checklist request (was: RFC: Deb 2.0 testing process)

[Adam P. Harris]

>> For example, with the diff package:
>> 
>> Package: diff - cmp works on identical and different binary or text
>> files - diff works on files, directories, normal or 2 column -
>> sdiff correctly merges two files - diff3 correctly compares 3 files

"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
> It seems a shame to have to ask people to do this sort of thing.

Yes!  Maybe even against policy?  [Followups on this to debian-policy,
please.]

I applaud the ambitiousness of making test suites for debian core
packages, but I wonder whether Debian developers should focus the
packaging and installation system rather than trying to fix all the
bugs in GNU, etc.  In other words, I think the test suite should
focus, at least at the outset, on implementing the policy and making
sure that installation and upgrades go smoothly.  

Here's a draft of a checklist geared to that:

* init scripts, if any, comply with debian policy
  (probably only 20% do now;) 
* package does not modify any files from other packages
* any installation shell scripts work with /bin/sh -> /bin/ash,
  or they specifically have #!/bin/bash
* any installation perl scripts work w/ perl 5.003 (?)
* [de]installation script output complies with policy

Another big thing is that the transition from 1.3 to 2.0 is _very_
smooth, which is not the case now.  Have we defined the supported
upgrade paths?  I know this is all a moving target w/ pkg ordering
stuff apparently coming in and (?) dselect being dropped as the
default installation mechanism.

[BTW, I'm not trying to criticize the current state of hamm, I know
the freeze is a ways off and there's a lot of instability going on.]

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Bug#988: `script' is insecure, and general tty insecurity

[Adam P. Harris]

Hello, Mr. Nag.  You've probably already been notified of this, but
many of the URLs generated by this `nag' script are incorrect.  For
instance, you say:

"Nag" == Nag  <[EMAIL PROTECTED]> writes:
> The history of this bug can be found at:
> http://www.debian.org/Bugs/db/988.html or

Should be:
http://www.debian.org/Bugs/db/98/988.html

> http://www.chiark.greenend.org.uk/debian/Bugs/db/988.html

Likewise, should be:
http://www.chiark.greenend.org.uk/debian/Bugs/db/98/988.html

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: unstripped stuff in /usr/lib

[Adam P. Harris]

"Fabrizio" == Fabrizio Polacco <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>>  We could let the -dev versions of packages have diversions of the
>> libraries to unstripped versions, and have the runtime versions
>> have stripped versions.

Interesting idea.  I can't say I'm completely clear on what the status
quo is for this. 

> Since most of the times -dev packages are needed to compile only
> (headers and the symlink from lib.so), I think it'd be better to put
> unstripped libraries on a separate -dbg package (as lib_d.a). Those
> libs are easily 10 times the size.

> Usually we have: runtime pkg: shared lib stripped with
> --strip-unneeded develop pkg: static lib stripped with --strip-debug
> debug pkg: static lib unstripped

The use of strip on shared libraries, and the exact flags to give
strip (which is indeed --strip-uneeded), are stipulated in the Debian
Policy Manual (v2.3.0.1, Sec 3.3.2), and also there it states that a
separate package should be provided for debugging versions of the
library.

> I'm not sure on what to do for shared unstripped libs (are they
> supported by gdb, now?)

Any debian package which has non-compliant libraries installed should
have a bug reported against them.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

ppp's ip-{up,down} and possible utilization of 'run-parts'

[Adam P. Harris]

Maybe I should submit this as a wishlist to the bug system, but I was
interested in getting some comments first.

I think that /etc/ppp/ip-up and /etc/ppp/ip-down should use
'run-parts' against, say, the directories /etc/ppp/ip-{up,down}.d/.

This would allow, for instance, MTA packages to ship little scripts to
flush the mail queue when the link comes up, pop-deamons to start up,
bind to reload, clock sync daemons to re-sync, firewall and
masquerading rules to run, and dynamic PPP hosts to update some file
on some server indicating their current IP.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: ppp's ip-{up,down} and possible utilization of 'run-parts'

[Adam P. Harris]

"Brian" == Brian Mays <[EMAIL PROTECTED]> writes:
> Yann Dirson <[EMAIL PROTECTED]> writes:
>> Adam P. Harris writes: 
>>> I think that /etc/ppp/ip-up and /etc/ppp/ip-down should use
>>> 'run-parts' against, say, the directories /etc/ppp/ip-{up,down}.d/.
>>> 
>>> This would allow, for instance, MTA packages to ship little scripts to
>>> flush the mail queue when the link comes up, pop-deamons to start up,
[...]

>> I had the idea of adding such actions (flush mailqueue, fetch mail,
>> etc.) to my ip-up, but I didn't do that.

>> This is because some of these actions (eg. mail fetching) may be
>> quite long to complete,

That's just a question of looking into how run-parts serializes
execution, and maybe using backgrounded subshell for faster script
completion.

>> and may act badly if interrupted by a
>> 'poff' (eg. fetched messages from the interrupted session not
>> erased from my POP account - guess it's a security feature in
>> fetchmail).

Well, that's an example of an application that works fine when the
link goes down in midstream!  No worries!

I'm sure some processes aren't as graceful.  However, the system I'm
proposing (and there's no guarantee Phil Hands won't adopt some
radically different scheme), which just talks about:
  /etc/ppp/ip-up.d/
  /etc/ppp/ip-down.d/
Wouldn't be making the situation any worse than it already is.  Not
that that's an excuse, but the fact is, by the time the scripts in
ip-down.d are run, it's too late anyhow!

>> The solution I used was to manually ask to fetch my mail.

Yeah, me too, but that sucks!

>>  Another
>> would be to have a (hopefully generic) mean of forcing the line to
>> stay up while such an action is taking place.

Well, that's outside of the scope of what I was trying to propose, it
takes power away from the user, etc etc.

>> * we can't decide for the sysadmin what actions will take place on
>> boot.

We do have an initial descision, which is what 98% of users will
stick with.  Yes, allow them to override, of course.

>> * if we build such a system, a standard way of disabling parts of
>> these directories (maybe like what /etc/init.d/rc allows with 'S'
>> and 'K' names ?)

I just feel that the SYSVINIT model is too elaborate for what we're
doing here (running scripts on link up and link down).  'run-parts is
stock debian, and already used by cron etc.

> Yes.  Definitely ensure that it is easy to disable (and of course
> re-enable) these automatic scripts, and ship everything _off_ by
> default.  IMO nothing is more annoying than these kind of surprises.
> I want to know what is being started when I dial into my ISP.

But of course.  Actually, it would be up to the individual packages to
be reasonable.

The beauty of run-parts is that all a local sysadmin has to do is say
`chmod a-x ' to disable a file.

> For example, I have configured my ip-up script to start fetchmail
> (in daemon mode) and grab articles for my local news spool unless
> the file /etc/no_mail exists.  Therefore, if I need to quickly dial
> in, say to fetch a file, I create this file before starting pppd so
> that I can hang up as soon as I am done without waiting for POP and
> NNTP transfers to finish.

I'm not sure we can accomodate this ;)

My goal is to find a 90% solution.  If it doesn't work for 10%'ers,
well, those 10%ers are generally hacker types and they are generally
able to hack on the system to get it to work "their way".

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Questions about emacs20 file system layout.

[Adam P. Harris]

[You (Rob Browning)]
>Christian Schwarz <[EMAIL PROTECTED]> writes:
>> As the current emacs package installs its libs into
>> /usr/lib/emacs/19.34/..., will moving this below /usr/share break other
>> packages?
>
>I'll certainly make sure that's not a problem before I do it, but so
>far, I doubt it will be.  I don't think that the old and new emacs
>will be sharing many files.

Rob, you're talking about moving Xemacs arch-independant files from /usr/
lib/xemacs-XX.XX to /usr/share, right?

I think this is a good idea.  When we do this for Emacs 19.XX we'll need 
to make sure to change AucTeX and the lisp packages.

BTW, are .elc files arch-dependant or arch-indep?  I've always wondered 
about this.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: ppp's ip-{up,down} and possible utilization of 'run-parts'

[Adam P. Harris]

[You ([EMAIL PROTECTED])]
>FWIW I've been using run-parts in ip-up and ip-down for some time now,
>the scripts reconfigure stuff based on my ip address (2 ISPs)  etc.
>and everything works like a charm.  I dunno about packages placing
>scripts in ip-[up|down].d/ -- I'd rather put them in 
>/usr/doc//examples.

One question.  You're obviously carrying along the `ip-up' argument list, 
i.e.,
Arg  Name   Example
$1   Interface name ppp0
$2   The ttyttyS1
$3   The link speed 38400
$4   Local IP number12.34.56.78
$5   Peer  IP number12.34.56.99 

These variables are clearly being propogated to your (custom rolled) 
ip-up.d/* scripts.  How are you propogating these values?  Environment 
variables?  We'd have to std'ize the variable names too, if so.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Taking over production of emacs20 package.

[Adam P. Harris]

[CC trimmed to ]

[Raul Miller]
>Hmm.. seems like XEmacs should Provide: auctex.  I can't see any
>formal problem if auctex is installed as a separate package as
>well...  [Why someone would want to is beyond me.]

What if you have Xemacs *and* Emacs installed, and want to use auctex 
from both?

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: ppp's ip-{up,down} and possible utilization of 'run-parts'

[Adam P. Harris]

"Philip" == Philip Hands <[EMAIL PROTECTED]> writes:
> My first attempt at this was to add these lines to the scripts:
>
>  # These variables are for the use of the scripts run by run-parts
>  PPP_IFACE="$1"
>  PPP_TTY="$2"
>  PPP_SPEED="$3"
>  PPP_LOCAL="$4"
>  PPP_REMOTE="$5"
>  export PPP_IFACE PPP_TTY PPP_SPEED PPP_LOCAL PPP_REMOTE

>  run-parts /etc/ppp/ip-up.d

"Alex" == Alex Yukhimets <[EMAIL PROTECTED]> writes:
> Why not as the same command-line arguments?  

I like Phil's schema better, since it eliminates the evil coupling
between the ordering of the cmd-line arguments with the values we're
trying to pass.  So we'd have to change every ip-(up|down) script if
the ordering ever changed.   However, giving them names does introduce
a new convention, namely the variable names themselves.   Less of the
two evils I think.

> And there is one thing
> which I would qualify as a mistake in the above description: $2 is
> actually in the form "/dev/ttyS1" than just "ttyS1".

Doh!  I wish they wouldn't do that.  I guess it's for some kinda
security?

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Proxy server policy [was Re: gated]

[Adam P. Harris]

[You (Adrian Bridgett)]
>We should also standardize the environment variables that are used. Once
>again, if the program doesn't support environment variables, tough -
>although of course maintainers are encouraged to "fix" the programs :-)

Maybe just enforce the standards that are kinda sorta already there, or 
even just forward bugs upstream if these are not supported?

$http_proxy env variable is supported by lynx, W3 mode in Emacsen, and
Mosaic flavors.  Also don't forget WWW_HOME as your home page.

I think there's not really much way we can get them to get netscape to 
respect this; I don't think it's worth it to munge thru the (quite 
volatile) netscape preferences either.

>If people could be kind enough to email sample proxy configurations to me
>(ones that are supported by some non-customized program), then I'll come up
>with a proposed scheme. I'll include some sample code to make it easier for
>maintainers to convert a program.

Well, the less work the better ;)

BTW, my home scheme doesn't really fit into your map.  This is for squid, 
in this case, running on localhost:

gopher_proxy=http://localhost:3128/
http_proxy=http://localhost:3128/
ftp_proxy=http://localhost:3128/  

FWIW, there's also an experimental Linux feature, transparent proxy, I 
think, which could automatically redirect outbound HTTP requests to a 
local httpd cache.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: IconPath, menu

[Adam P. Harris]

[You (Karl M. Hegbloom)]
> I've created a directory "/usr/X11R6/icons" for my own use. 
> that we need to have something like that, and a keeper of the icons.

We already have the location, and it is standard:
  /usr/X11R6/include/X11/pixmaps/
There are over 300 pixmaps in there, a good deal of which are icons.

As for a "keeper",there are several alternate icons packages.   I think 
it would be a mistake to try to centralize icon maintenance. 
   
> All of the mini icons and whatnot from the various packages ought to
> be consolidated into one icon package.  

Why?   It sounds so hegemonic!  That person would have to maintain icons 
for every possible application/service.

> Other packages that require icons could suggest it, and the menu
> system could use them if they're present, or not if they're not.

The current flow is for application maintainers to bundle icons with 
their apps if possible, I believe.

[snip]
> Every package with a menu should have an icon.

That's what's happening AFAIK, but the package maintainers are 
responsible.  I don't know how their handling sizing issues and bit-depth 
issues but that's an issue for the debian-policy group I think.

> The emacs icon is an example of one that's way too huge. :-)

Yes, I use xemacs.xpm from the distribution, I put it in 
/usr/local/X11/include/pixmaps/ .

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: ldconfig warnings

[Adam P. Harris]

In message <[EMAIL PROTECTED]> you wrote:
[snip]
>Currently, on my 386 system...
>
>ldconfig: warning: can't open /usr/local/lib (No such file or directory), 
>skipping
>ldconfig: warning: can't open /usr/lib/i486-linuxaout/libdb.so.1 (No such file 
>or direct
>ory), skipping
>ldconfig: warning: can't open /usr/lib/libpthread.so (No such file or 
>directory), skippi
>ng
>ldconfig: warning: can't open /usr/lib/libjpeg.so.6a (No such file or 
>directory), skippi
>ng
[snip]
>Is the cause is due to incorrect packaging of the shared
>libraries?  I'm not sure.  

Yes, I think so.  BTW, I agree this is very annoying.

>I'm just wondering if there is a way of automatically
>cleaning up after those (buggy?) packages are long gone...
>
>Or perhaps we need to enforce policy a bit better.  If
>somebody could explain what exactly is going wrong in
>these packages - ie. what policy are they violating?

Yes, it is discussed in the Debian Packaging Manual, section 12.
See:
  /usr/doc/dpkg/packaging.html/ch-sharedlibs.html

You should just go ahead and file bugs against packages which don't
include the .so link as part of the package.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

menu category for personal info. manager apps

[Adam P. Harris]

I notice a flaw in menu placement for a number of packages which might
be categories as Personal Information Managers (PIMs).  Namely, `ical'
and `addressbook' are listed in the `Apps/Tools' category, while 
`xmaddressbook' is under `Apps/Misc'.

I can't say I'm extremely happy with either category.  I would propose
either `Apps/PIMs' or `Apps/Editors/PIMs', although that might be too
cryptic.  Other PIMs which might be likewise categories are Netscape
Calendar, xcalendar,  I'm sure there are or soon will be others.

Alternatively, we should pick either one of the two categories for
these type of applications.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: menu category for personal info. manager apps

[Adam P. Harris]

"joost" == joost witteveen <[EMAIL PROTECTED]> writes:
> I'll give my opinion here, but I'm running very low on time at the
> moment.  So, I'll probably not participate in much of this
> discussion untill (well?) after 1998/1/7. Joey Hess also has a great
> feel for these things, and I will gratefully adopt any desicion he
> makes (assuming he wants to participate)

Not like it's a high-intensity issue or anything ;)

> Personally, I would say that "xmaddressbook" should then be moved to
> Apps/Tools. I also think that "PIM" isn't very clear. I would prefer
> something like "Personal", that at least gives you an idea as to
> what it is.

Agreed.

> If netscape is a `PIM', then chimera, emacs, whathaveyou certainly
> also are `PIM's. I wouldn't want netscape to appear in any such
> catogary.

Um, not "Netscape Navigator", I meant "Netscape Calendar", i.e.,
`nscal'.  Not currently packaged, btw.

> joost witteveen, (I'm preparing for my promotion 1998/1/7, and have
> less than zero time to spend on anything that isn't really related
> to that (or esperanto)).

Good luck!

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>




--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

intent to maintain orphaned package `addressbook'

[Adam P. Harris]

-BEGIN PGP SIGNED MESSAGE-

I intend to take over maintenance of the orphaned `addressbook'
package.  I've spoken to the former maintainer, the upstream source
maintainer, and Mssr Fok, who was kind enough to do most the work
that needs to be done on the package, and gotten their blessing.

Expect an upload as soon as I get an account on master.

This package is listed as orphaned in packages.sgml,v 1.63.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNJ9Qu4/8QF79WmfNAQH9BwP/YlylbvoOYrcOr4fszGDLxQa/9U5aRmCm
vMWcgaDOJ12iCEdKMQf9JfL/FgscPNv4ls+V1CDHURrE45HC6Sn4nLEuis+2o0nh
9IZWl3a2YPN0PnNNXFd/q/z6eLUNr2qC1d01R0RKaH1MIyou1tWh2zKJssKnEBW/
slaNwTspEW0=
=xZgk
-END PGP SIGNATURE-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Motif Software

[Edmund P. Morgan]

Hi developers,

I would like to know which motif software package would you suggest for use
With debian 1.3.1? 

Thanks,

Edmund P. Morgan
[EMAIL PROTECTED]


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: AucTeX

[Adam P. Harris]

[Removed CC to ]

[You ("Davide G. M. Salvetti")]
>1) AucTeX has many .el's which should be shipped byte-compiled: should I
>compile them with some specific Emacs flavor or doesn't it matter which
>Emacs I'll use?  (Please consider that, AFAIK, XEmacs comes with its own
>AucTeX, so AucTeX should probably care only about GNU/Emacs; I'm not sure,
>about that, though, mainly 'cause I don't use XEmacs :-).)

Yes sir that is correct at this point.  Word is that eventually XEmacs 
will unbundle a lot of the lisp packages it comes with but for now that 
is the case.  With xemacs19-19.16-1 I have AucTeX v 9.7l.

>3) Current AucTeX package puts its data (.elc's) in /usr/lib/emacs/common;
>should I put them in /usr/share/emacs/whatever_is_more_appropriate or
>something else instead?  (Please, consider FHS and FSSTND, and the fact
>many packages already put stuff in /usr/share.)

I'd leave it where it is.  Or else put it in share and symlink from /usr/
lib/emacs/common.  We'll embrace FHS in 2.1 or so; right now it's FSSTD 
which is stipulated by policy.

>4) AucTeX needs to periodically scan (La)TeX style files to keep itself in
>touch with what one has installed on his machine;  it does this by
>cron.weekly.  Current AucTeX package puts resulting files under /usr
>(precisely just where it puts its data: /usr/lib/emacs/common);  I believe
>I should put things under /var, instead: any comments, please?

Yes, /var/lib/emacs/auctex perhaps?

>5) Current AucTeX package puts its configuration files directly under
>/etc/elisp: is this still good behavior?

Yes, I think so, although Robert Browning was doing some Emacs 20 (?) 
work which would imping upon all this and the byte-compilation issues.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

loop-root (was What's Debian's /usr/src policy)

[Adam P. Harris]

[You (Dale Scheetz)]
>On Wed, 7 Jan 1998, Turbo Fredriksson wrote:
>> A loop-root?

>With a small patch to the kernel and some modification of the loop device
>code, you can create a file-system-in-a-file. 

You can do this already in stock debian (rex and hamm) with 
  mount -o loop -t

Why do you need to patch the kernel for this?

>Using the loop device
>the internal file system can be mounted as the root file system for the
>kernel. These patches were never adopted by the kernel, and it is getting
>harder and harder to apply them, so I currently use a patched 2.0.27
>kernel to boot that system. 

Why do you have to patch the kernel at all?  I already have this
funcationality w/ initrd. Again, this is on an upatched 2.0.30 and 2.0.32 
kernels.

BTW, I use it on my custom-rolled boot floppies for debian booting off a
floppy for a laptop which runs an initrd w/ cardmgr on it so I could get
PCMCIA subsystem up and play with NFS-mounting root.  I have a little make
file which makes a pretty complete but small initrd file system (using
mount -o loop) complete w/ shared libs etc, even ash.  It all works, at
least to the extent that NFS-root works well at all (which is not much but
I haven't gotten around to pestering Joost about it).

Alternatively you could use the ramdisk and just mount root in the same 
basic fashion (although initrd is a little different -- not much really).

>The one I boot with lilo is on an ext2 partition (another beauty of the
>imbeded file system, it can be coppied to almost any other file system).
>Interesting point: on an ext2 file system, no care need be taken. On a DOS
>file system the file system must be un-fragmented (using dfrag) before the
>DiD installation will work properly. The funny part of this is that it
>doesn't matter whether you do the dfrag before you copy the file system,
>or afterwards, it still works. Without it you get file system errors.

Never noticed this issue on my 'mount -o loop' and initrd scheme.  Using 
SYSLINUX to boot I think.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Information

[Edmund P. Morgan]

Hi developers,

I would like to ask the following questions?

1. Does Debian 1.3.1 support the 3Com 3c905 NIC in 100 Mbps mode?
2. Does Debian support the above NIC without any kernel patches (native)?
3. When will the new version (2.0) of Debian be released?
4. Will Debian v2.0 support the above questions #1 and #2?
5. Will I be able to do a in place update of Debian from 1.3.1 to 2.0 without a 
fresh install?  (currently I'm running Slackware, but I would like to move to 
Debian)

Thanks,

Edmund P. Morgan
[EMAIL PROTECTED]


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Debian 2.0 release requirements

[Adam P. Harris]

"Richard" == Richard Braakman <[EMAIL PROTECTED]> writes:
>> Shared libraries are linked dynamically against other libraries
>> 
>> Linking shared libraries dynamically against other libraries
>> simplifies the upgrading process and saves disk and memory space.
>> All shared libraries included in the Debian distribution will be
>> compiled that way.
[...]
> As far as I can tell, it does not save disk and memory space.
> However, I am rather new at this.  Feel free to correct me.

You are wrong.  Shared libraries are able to use copy-on-write memory
space (hence the 'shared' category when you type 'free') which can
radically lower RAM requirements.  This is not the case on statically
linked libraries.

And, clearly, it saves disk space since the code resides on the disk
in only one place instead of being part of the executable.  (Little
confused on how you could get confused on this one!)

The final, and most important rationale is that bug fixes, say, in
libc, can be applied in one place and all programs which statically
link against the same major libc version are able to reap the benefits
of that bug fix.

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Maintainers and the Database

[Giuliano P Procida]

This mail message started out as a response to Marcus Brinkmann's
comment on the policy list:

> I think that [the multiple maintainer] issue can't be resolved
> properly ("we are stuck") without further input from all the other
> developers not participating on debian-policy.

I'm hardly a participant, but I do read it. This message is now mainly
about the database and only relates partly to the above. The real
questions are, IMO:

a) what is package ownership?

We need to know who put together a package, who to send bugs to and
who ping if the package needs to be updated. We need to know if a
package is orphaned (has no owner).

b) how well is this reflected in current practice (and policy)?
c) what changes are needed to improve the answer to b)?

I'm not touching these!

d) What about a database to handle some of this for us?

This is in progress and is what I ramble on about below (knowing
little about the existing db work).

*The Database*

It is important that the database reflect reality for it to be useful,
both in its design and in its content. This applies to all databases.
This is unexciting, but hopefully obvious.

  The Design

A database of Debian developers (package maintainers plus all those
helping with debian who do not actually emit .debs) is needed and in
preparation. Package ownership details are desired in the database.

Relational Databases 101 says you will need (at least) one relation
for the people and another for the packages. (It would be a bad design
to have an attribute "packages" which listed all their packages).

If each package has an attribute "owner" then there arises the problem
of what to put:

a) When there is no owner (orphaned). Answer: Easy, use NULL.

b) When there are multiple maintainers (maintainer group). Answer: say
   "oh dear", or enter only one of them (arguably incorrect), or
   create a fake maintainer which is actually a group (yuk yuk), or
   try and handle groups directly, in some moderately complicated
   fashion, OR:

If instead there is a separate relation for ownership linking people
and packages, then there is no problem with people having 0, 1 or more
packages or with packages having 0, 1 or more owners. Queries to list
orphaned packages, list a given person's packages, etc. are hardly any
more complicated than with the other design. Moreover, the data (and
schemas) are trivially convertible from the other design to this one.

Summary: it should not be a problem for the database what form of
"multiple maintainership" (if any) is eventually adopted.

* Could someone in the know say whether there is a separate ownership
* table? I am happy to give a hand with PostgreSQL hacking (I am in
* the process of setting up a (pg) db at work - a learning experience
* :-).

  The Content

Developer information should be at the control of the individuals and
I imagine this has been what most of the existing DB work has been on.

Package information is a different matter. One issue is what to do
when a package disappears for good, being deleted from the archive.
The corresponding entry in the database ought to be updated or deleted
to reflect this. Plenty of information can be extracted automatically
as each .deb arrives (including the _packager_ - via the PGP key).

Ownership information is a little more tricky (think NMUs, multiple
maintainer packages and orphaning) but it ought to be possible to
automate this to some extent.

Someone with ambition may want to do something to add summaries of
data in the bugs system.

* I am prepared to help with any of the miscellaneous scripting the
* above involves.

  DB Care

Once a design stabilises the db needs to be looked after in much the
same way that Guy (and helpers) look(s) after the archive. The web (or
whatever) interface is unlikely to be perfect initially and will need
maintainance.

  The "Maintainer:" field

This will probably be rather important in terms of generating data for
the db. It is supposed to be the canonical means of contact between
user and developer in relation to a given package. I know much less
about how this propagated and used by various things (bug db, bug
command, dinstall, dpkg-*). It is something you can mail (i.e., one or
more email addresses).

Whereas packages are nicely identified by their name. The same cannot
be said of developers and the "Maintainer:" field, at the moment. This
is unfortunate. Most email addresses found in the field correspond to
an entry in the PGP key ring and hence to real humans.

There are plenty of (technical) solutions to this problem and the with
luck a wider discussion of the "multiple maintainer" issue will fix
this as a consequence.

Enough rambling,
Giuliano Procida (Myxie)
-- 
mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] | public PGP key ID: 93898735
home: +44 1223 561237 / 547 Newmarket Road, Cambridge CB5 8PA, UK
work: +44 1223 332127 / Magdalene College, Cambridge CB3 0AG, UK
work: +44 1223 335333 / International Studies, Cambridge CB2 1QY, UK

Re: monochrome cards

[stephen . p . ryan]

On 30 Apr, Raul Miller wrote:
> Bear Giles <[EMAIL PROTECTED]> wrote:
>> That said, I can't see anyone using a MCA card as his primary 
>> interface.
> 
> I can see this, or serial console, being used for a server.
> 
> Also, don't forget the sorts of interfaces blind people use...
> 

> Berr Giles also wrote:
> I certainly wouldn't have objected if I had to install 
> a VGA card to run the installation program.  How much space would 
> be saved if the MCA code is dropped?

I suspect, not much space at all, since that should be something in the
kernel console code.  I just installed Debian on a spare parts machine
(i.e., one built out of spare parts that nobody else wanted plus some
old stuff I had from a machine that died last year) and I only have a
monochrome monitor available to use on it.  Ripping the display off my
laptop is not an option, nor is stealing the 60 pound monitor from
school and taking it home while I install Debian an option.  I for one
am happy for the monochrome option.

Just my $0.02, in case anybody cares.
-- 
Stephen Ryan   Debian GNU/Linux
Mathematics graduate student, Dartmouth College


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

Re: install-docs in prerm problem

[Adam P. Harris]

[Sorry to be so late reading debian-devel.  Please cc
 <[EMAIL PROTECTED]> next time.  I just don't always have time
 to keep up on this list.]

Elie Rosenblum <[EMAIL PROTECTED]> writes:
> Folks, make sure your prerm scripts don't fail if the install-docs doesn't
> want to uninstall docs that aren't installed.
> 
> I had developers-reference installed, but not doc-base. Installed doc-base,
> then tried to upgrade developers-reference, and the prerm refused to work,
> because it wasn't registered with install-docs.

Interesting case.  Clearly, this is a flaw in install-docs; I'm aware
of it by my vision is that when slink is around install-docs will be a
required package and installed very early on.  Aside from that, I'm
not sure whether we need additional facilities for picking up
documents installed before itself.

> Now, this isn't much of a problem for me; I can edit the prerm file myself
> and make it work. However, I don't expect production packages to need low
> level fixes like this, which are inappropriate for non-developers to need
> to use.

You might be interested to know that doc-base since version 0.3 (9 Apr
1998) has this entry in the changelog:

  * install-docs is idempotent for --remove, that is, if you try to remove
a docid which is already removed, it exits with a warning, but not a
non-zero exit status (closes Bug#19875, I think)

.A. P. [EMAIL PROTECTED]http://www.onShore.com/>


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

Re: Bug#304521: ITP: wanna-build -- Database management for package (re-)compilation/status control

[Francesco P. Lovergine]

On Wed, Apr 13, 2005 at 10:49:34PM +0200, Jesus Climent wrote:
> On Wed, Apr 13, 2005 at 09:12:47PM +0100, Roger Leigh wrote:
> > 
> > > * Package name: wanna-build
> > 
> > If you haven't already, you might like to pick up the manpages I wrote
> > from here: http://people.debian.org/~rleigh/buildd/
> 
> Thanks. I will (I had already taken wanna-build.1) and will modify them
> accordingly to the additions i have already made.
> 
> Thanks again!

If you would like to use alioth as infrastructure for development,
consider the already present buildd project at
https://alioth.debian.org/projects/buildd-tools/

-- 
Francesco P. Lovergine


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

Re: debian sarge is 3.2 or 4 ?

[Francesco P. Lovergine]

On Wed, May 04, 2005 at 08:38:17PM -0400, Joey Hess wrote:
> see shy jo, who argued for 4.0 at the appropriate time to discuss the
> version number to use

:-) right


-- 
Francesco P. Lovergine


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

Re: dhcp-client package in sarge

[Milan P. Stanic]

On Sun, Jun 12, 2005 at 10:19:03PM +1000, Andrew Pollock wrote:
> FWIW, I've recently become a co-maintainer, and now the Sarge has released,
> I'm planning on bringing dhcp3 up to date with the latest upstream and
> having a good bash at all the bugs.

Would you consider to incorporate LDAP patch to dhcp server?


signature.asc
Description: Digital signature

Bug#381992: ITP: libming-fonts-openoffice -- Fonts for use with the Ming Library for SWF Creation

[Alejandro Rios P.]

Package: wnpp
Severity: wishlist
Owner: "Alejandro Rios P." <[EMAIL PROTECTED]>

* Package name: libming-fonts-openoffice
  Version : 0.1
  Upstream Author : OpenOffice.org 
* URL : http://www.openoffice.org/
* License : GPL
  Description : Fonts for use with the Ming Library for SWF Creation

 These are the OpenOffice Fonts converted for use with libming,
.which is a library for SWF (Flash) File creation.
.These fonts canNOT be used with X11 or for printing.

-- System Information:
Debian Release: testing/unstable
  APT prefers breezy-updates
  APT policy: (500, 'breezy-updates'), (500, 'breezy-security'), (500, 'breezy')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-9-686
Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8)


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

Re: Request for virtual package ircd

[Milan P. Stanic]

On Wed, Oct 11, 2006 at 06:34:41PM -0500, Ron Johnson wrote:
> It's also possible to run multiple FTP servers, each listening on a
> different port, but all the packaged ftp daemons "Conflicts:
> ftp-server".

That is bad, IMO. (and chance to raise my opinion about virtual
packages ;) )

Conflicts tag is used overmuch. Sometimes I want to have more than one
ftp-server or mail-transport-agent installed but Conflicts tag does not
allow that. I know that inexperienced user or admin have benefit from
Conflicts (and some other tags) and virtual packages but experienced
ones have problem with them.

Regards


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

Re: Will IceWeasel be based on a fork or on vanilla FireFox?

[Milan P. Stanic]

[ Off-Topic, sorry ]
On Mon, Oct 16, 2006 at 11:43:51AM +1000, Ben Finney wrote:
> If it's not renamed, we can't legally ship it. What, IYO, should be
> done to ship the existing program currently known as Firefox?

FoxFire or FoxInFire, maybe ;)


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

Re: NEW processing slowdown (Was: FAQ, Re: new mplayer)

[Francesco P. Lovergine]

On Sat, Oct 21, 2006 at 01:34:14PM +0200, Petter Reinholdtsen wrote:
> I suspect something need to be done with the NEW process, as adding
> more people seem to only improve the situation for a limited time.
> Perhaps it could be optimized to make it less time consuming for those
> processing it, or perhaps it need a complete redesign to avoid the
> current bottleneck.  I'm not sure, as I only see it from the outside
> through http://ftp-master.debian.org/new.html>.

AFAIK the real issue is auditing. Auditing task is slow and prone 
to bothering who does that. IMHO adding people to do that is the
only way to go, but for removing auditing (which is not acceptable).
This is the same reason why none can sponsor dozen of packages
without lowering reviewing quality.

-- 
Francesco P. Lovergine


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

Re: apt hangs for ever

[Francesco P. Lovergine]

On Tue, Nov 28, 2006 at 01:34:54AM +1100, Andrew Vaughan wrote:
> > Get:1 http://ftp.au.debian.org etch Release.gpg [378B]
> > Get:2 http://ftp.au.debian.org etch Release [74.4kB]
> > Get:3 http://ftp.au.debian.org etch/main Packages/DiffIndex [2038B]
> > Get:4 http://ftp.au.debian.org etch/main Packages [5579kB]
> > Get:5 http://ftp.au.debian.org etch/main Packages [5579kB]
> > 99% [5 Packages gzip 0]
> >  (hangs for ever)
> >
> > I have tried waiting for it to timeout, but it doesn't.
> >
> 
> Don't know whether its related, I stopped using ftp.au.debian.org.  IIRC it 
> was replying to package requests with a 302 redirect, which apt-proxy 
> seemed to be unable to handle.
> 
> Is this a 302 redirect something debian package management/archive mirroring 
> tools are expected to handle, or are mirrors not expected to use redirects?
> 
> ftp.iinet.net.au/debian/ also seems to be intermittent partially updated.  I 
> wonder whether they're mirroring from ftp.au.debian.org, and also having 
> problems with the 302 responses. 

This is indepent on mirror choice I think. I got the same issue with ftp.it and 
solved
twice as pointed by henrique. Installing debian-archive-keyring in the
pbuilder chroot (with the new recent key) just before updating solved the
issue this time and in the previous case also. 

-- 
Francesco P. Lovergine


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

Re: out of date package with maintainer AWOL

[Francesco P. Lovergine]

On Wed, Jan 10, 2007 at 12:01:07PM -0500, Gravis wrote:
> im not entirely sure this is the proper list for this (i was told it
> should be).
> 
> in short, the gparted package is very out of date.  the current version
> that is still in testing is version 0.2.5 which is from May 2006
> (2006-05-13).  the latest version 0.3.3 (2006-12-06) is far more stable
> than 0.2.5.  ive tried to contact the maintainer a couple weeks ago but
> he does not respond and i suspect the address is defunct.
> 
> this is an important package to the Gnome Desktop so im requesting that
> i be allowed to become the new maintainer of this package.
> 
> any help is appreciated.
> 

Better contacting [EMAIL PROTECTED] in order to track the thing
properly.

-- 
Francesco P. Lovergine


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

Re: Best scheme for teams and Maintainer/Uploaders fields ?

[Francesco P. Lovergine]

On Mon, Jan 08, 2007 at 11:58:49AM +0100, Pierre Habouzit wrote:
> On Mon, Jan 08, 2007 at 11:24:50AM +0100, Stefano Zacchiroli wrote:
> > On Mon, Jan 08, 2007 at 09:03:03AM +0100, Lucas Nussbaum wrote:
> 
> > > - it's difficult to keep track of who is caring for that package (hint:
> > >   QA, MIA, ...)
> > 
> > Uh? Why? Your maintainer field seems to address this issue. In our
> > scheme that's would be more a problem, but if the mailing list is
> > responsive it's enough. Think for example at the debian-release mailing
> > list: it's a list, but it's really responsive for all packages in the
> > archive. So IMO not being able to identify a single person is not
> > necessarily an indicator of unresponsiveness for a given package.
> 
>   What he means is that when people are listed automatically as
> Maitnainer/Uploader, the fact that the package is well maintained may
> hide that a particular DD do nothing at all, and is in fact MIA.
> 

That would be avoided by removing entry on the basis of the changelog
containts. People who do not touch the package for +365 days would
be removed. I think to propose this policy for DebianGis.

-- 
Francesco P. Lovergine


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

Re: library for imap (client)

[Francesco P. Lovergine]

On Sat, Mar 18, 2006 at 03:49:07PM +0100, Michelle Konzack wrote:
> Currently I am starting a new project and want to know, if someone
> know the existence if an imapclient library for C programing?
> 
libc-client with some limitations...

-- 
Francesco P. Lovergine


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

[RFC] proftpd 1.3.0rc5 in experimental

[Francesco P. Lovergine]

I just uploaded the new pre-release of the proftpd daemon.
It has been completely repackaged to support apache-like DSO
and it is now a single binary package (no more proftpd-* flavors,
but for a few dummy packages used for upgrading).

Feedbacks are very welcome to find upgrading issues and whatever.

AFAIK it can upgrade by aptitude current sid packages. I was looking
for how managing dependencies for a plain apt-get dist-upgrade path,
but failed 'til now... Ideas? Maybe, I need to maintain a dummy package
for proftpd-common too, but I hate introducing too many pseudo-packages.
And yes, I know that aptitude is the sane choice for dist-upgrading :)
so I'm not too worried about.

-- 
Francesco P. Lovergine


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

Bug#364795: ITP: gwhere -- Manage a catalog of removable media contents

[Alejandro Rios P.]

Package: wnpp
Severity: wishlist
Owner: "Alejandro Rios P." <[EMAIL PROTECTED]>

* Package name: gwhere
  Version : 0.2.0
  Upstream Author : Sébastien LECACHEUR <[EMAIL PROTECTED]>
* URL : http://www.gwhere.org/
* License : GPL
  Description : Manage a catalog of removable media contents

GWhere allows you to manage a catalog of your CDs and any other
removable media (such as hard disks, floppy disks, Zip disks, CD-ROMs,
etc...) indexed in a database. With GWhere it is easy to browse your CDs
or to make a quick search without needing to insert each CD one after
another.

-- System Information:
Debian Release: testing/unstable
  APT prefers breezy-updates
  APT policy: (500, 'breezy-updates'), (500, 'breezy-security'), (500, 'breezy')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-10-386
Locale: LANG=es_CO, LC_CTYPE=es_CO (charmap=ISO-8859-1)

Re: Bug#366359: ITP: libnet-smtpauth-perl -- Simple Mail Transfer Protocol client with AUTHentication

[Milan P. Stanic]

On Mon, May 08, 2006 at 12:15:44AM +0200, Nacho Barrientos Arias wrote:
> * Package name: libnet-smtpauth-perl
>   Version : 0.08
>   Upstream Author : Alex Pleiner <[EMAIL PROTECTED]>
> * URL : http://search.cpan.org/dist/Net-SMTP_auth/
> * License : Perl
>   Programming Lang: Perl
>   Description : Simple Mail Transfer Protocol client with AUTHentication
> 
>  This module implements a client interface to the SMTP and ESMTP protocol
>  AUTH service extension, enabling a perl5 application to talk to and
>  authenticate against SMTP servers.
>  .
>  Homepage: http://search.cpan.org/dist/Net-SMTP_auth/

Net::SMTP already supports AUTH service extension (RFC2554), IIRC.

Is it wise to have two Perl modules for the same task with a different
syntax?


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

Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email

[Milan P. Stanic]

On Sun, May 14, 2006 at 01:20:20PM +0200, Krzysztof Krzyzaniak (eloy) wrote:
>  Email::Send provides a very simple, very clean, very specific interface
>  to multiple Email mailers. The goal if this software is to be small
   ^
>  and simple, easy to use, and easy to extend.

Isn't the term "Email mailers" vague a little?


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

Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

[Francesco P. Lovergine]

On Tue, May 23, 2006 at 09:46:10AM +0200, Frank Küster wrote:
> Florian Weimer <[EMAIL PROTECTED]> wrote:
> 
> > * Michael Prokop:
> >
> >> Using:
> >>
> >>   invoke-rc.d $PACKAGE stop || true
> >>   /etc/init.d/$PACKAGE stop || true
> >>
> >> would be a replacement already used in some packages like for
> >> example at, binfmt-support, dnsmasq, drbd0.7-utils, freeradius, hal,
> >> scanlogd, sl-modem-daemon, snort.
> >
> > I suppose it would be preferable to fix the "stop" target of the init
> > script top cope with the situation that the daemon has already been
> > terminated.  The current situation (stopping a daemon manually before
> > deinstallation makes it fail) is hardly acceptable.
> 
> I agree:  The only valid reason for a "stop" call to fail should be if
> it is actually impossible to stop a running daemon.  In this case, I
> think the package removal should indeed fail, because even if it just
> hangs completely, it might recover and then just continue to accept
> connections until the machine is rebooted.
> 

Unfortunately sometimes the daemon does not stop for an error in the
maintainer script and that prevents upgrading for ever, even when
the package has been corrected. BTW, it seems a lack in the policy
to specify how the maintainers scripts should work on stop (i.e. what
returning as exit code when stop does not work for secondary reasons)

-- 
Francesco P. Lovergine


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

Re: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

[Francesco P. Lovergine]

On Tue, May 23, 2006 at 10:21:53AM -0300, Henrique de Moraes Holschuh wrote:
> There is nothing preferable about it.  Stop targets *are* to exit with
> status 0 if the service is already stopped.
> 
> The fact that Debian policy still has this as a "should" clause is just
> cruft that needs to be addressed.  There are absolutely no acceptable
> exceptions to either this rule (stopping a stopped service is okay) nor to
> its counterpart (starting an already started service is okay), as far as I
> know.
> 

Absolutely ack.

-- 
Francesco P. Lovergine


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

Re: Using the SSL snakeoil certificate

[Milan P. Stanic]

On Thu, Jul 20, 2006 at 11:24:34AM +0200, Martin Schulze wrote:
> For example:
> 
>   Dovecot uses .
> 
>   This is a symbolic link to  if
>   the above file or link does not exist during configuration of
>   dovecot.
> 
> That way, the admin can easily replace the symlink with a real
> certificate if they want per-service certificates.
> 
> If, however, they want to have one real certificate for everything,
> they can replace the snakeoil certificate like Martin Pitt proposed.
 
Sorry if I misunderstand something, but is it okay to call it snakeoil
if it is real certificate? I like to say that the symbolic links for
per-service certificate shouldn't point to something called snake-oil.

Just my opinion.


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

Re: Using the SSL snakeoil certificate

[Milan P. Stanic]

On Sun, Jul 23, 2006 at 08:37:50PM +0200, Martin Schulze wrote:
> Milan P. Stanic wrote:
> > Sorry if I misunderstand something, but is it okay to call it snakeoil
> > if it is real certificate? I like to say that the symbolic links for
> > per-service certificate shouldn't point to something called snake-oil.
> 
> Nah, if you replace the snakeoil certificate by a real one, it's not
> snake-oil anymore, of course.

But then you must change all symlinks to that new real certificate.


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

Re: Using the SSL snakeoil certificate

[Milan P. Stanic]

On Mon, Jul 24, 2006 at 12:43:16PM +0200, Peter Palfrader wrote:
> On Mon, 24 Jul 2006, Milan P. Stanic wrote:
> > But then you must change all symlinks to that new real certificate.
> 
> That's why on my systems all the service names symlink to
> thishost.{pem,key} and that is itself a symlink to the current
> certificate.  Only one symlink to update when you rotate certs.

That is what I'm thinking about. All service certificates should be
symlink to one generic name (as Martin proposed) but that name
shouldn't be snake-oil because the meaning of the word "snake oil", IMO.
thishost.{pem,key,crt,p12} looks better.

Another idea is to make that decision to user/admin during installation
through debconf or something similar, but don't ask me for patch
because I don't know how to make it. :)


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

Status of iproute package for Etch

[Milan P. Stanic]

Hi,

[ I thought to post that message to Alexander Wirt but I don't like
  to send private mail to people before previous agreement ]

Default kernel in Etch will be 2.6.17 but the iproute package for now
is 20051007 version.

For new kernels there are new upstream releases at:
http://developer.osdl.org/dev/iproute2/download/ and they are named as
iproute2-kernel.version-releasedate

I made deb package of iproute2-2.6.15-060110 with some patches which
Stex (aka Stefano Melchior <[EMAIL PROTECTED]> ) made for
some older version of iproute2. It works but I'm not sure if it is
lintian clean. I'm ready to help as much as I can to move on.

What should be done to got new version of iproute in Etch?
Alexander?



signature.asc
Description: Digital signature

Re: Status of iproute package for Etch

[Milan P. Stanic]

On Wed, Jul 26, 2006 at 10:05:57PM +0200, Florian Weimer wrote:
> Do the newer versions include documentation of the semantics of the ip
> commands (and not just the syntax)?

I'm not sure if I understand you, but there are some documents which
describes ip command and some other programs (which comes with iproute
like ss and nstat) in package.

And there is nice howto about iproute and policy routing at
http://www.policyrouting.org/iproute2.doc.html which is not included
in iproute package but I hope it could.

Of course, there is also a famous LARTC HOWTO at http://lartc.org/howto/


signature.asc
Description: Digital signature

How to build libapache-mod

[Milan P. Stanic]

Hi!

Anyone can give a pointer for doc's how to build apache modules
for Debian? I already looked at some examples but that didn't
helped much.

Sorry if this question answered already or the location of doc's
(policy) is easy to find.

TIA


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

Re: How to build libapache-mod

[Milan P. Stanic]

On Wed, Jan 12, 2005 at 02:19:32PM +0100, Nico Golde wrote:
> Hello Milan,
> 
> * Milan P. Stanic <[EMAIL PROTECTED]> [2005-01-12 14:16]:
> > Anyone can give a pointer for doc's how to build apache modules
> > for Debian? I already looked at some examples but that didn't
  ^^^
> > helped much.
> > 
> > Sorry if this question answered already or the location of doc's
> > (policy) is easy to find.
> 
> have a look on the source of an existing apache modules. 

Did that (see above) but I had a hope that there is something like
"libapache-mod Debian policy". Never mind, I'll try to conclude from
examples.

Anyway, thx.


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

Re: How to build libapache-mod

[Milan P. Stanic]

On Wed, Jan 12, 2005 at 03:44:45PM +0100, Michael Ablassmeier wrote:
> On 2005-01-12, Milan P. Stanic <[EMAIL PROTECTED]> wrote:
> > Sorry if this question answered already or the location of doc's
> > (policy) is easy to find.
> 
> apache-dev includes `/usr/share/doc/apache-dev/README.modules' which
> contains a set of simple guidelines on how to integrate external Apache
> modules into Debian. Looking at existing libapache-mod-* package-sources
> should also help, though.

I thought such file is in the apache-dev and my first search was
there but without luck. After your answer I think that must be for
the testing/unstable, but not for stable.
And I have only stable/woody.

But, now I know where to search.

Thanks


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

Re: How to build libapache-mod

[Milan P. Stanic]

On Wed, Jan 12, 2005 at 09:25:12PM +0100, Tollef Fog Heen wrote:
> You really don't want to develop new packages for apache 1 and
> certainly not for the apache in woody.  Woody's apache is broken in
> so many and interesting ways it's beyond funny and into the scary
> territory.  Apache 1 is going away when sarge is released, so if you
> can, please package the module for apache 2 rather than apache 1.

I don't have much experience with apache2. Only tried once and stop
using it. With apache1 I work about eight or more years now.

BTW, module which I'm trying to package is psldap and there is in
source doc's which says it can be built with both apache version, so
I hope if I manage to build it with apache1 it should be easy with
apache2 :-)


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