Re: RFS: php-ezcomponents

[Thomas Koch]

I've updated the package to the new upstream version 2009.1.1.

> Dear mentors,
>
> I am looking for a sponsor for my package "php-ezcomponents".
>
> * Package name: php-ezcomponents
>   Version : 2009.1-1
>   Upstream Author : eZ Systems AS
> * URL : http://ezcomponents.org
> * License : New BSD
>   Section : web
>
> It builds these binary packages:
> php-ezcomponents-all - Super package to install a complete release of eZ
> Components
> php-ezcomponents-archive - create, modify, and extract archive files
> php-ezcomponents-authentication - support for different authentication
> mechanisms
> php-ezcomponents-authenticationdatabasetiein - Tie-In to connect the
> authentication and database components
> php-ezcomponents-base - The Base package provides the basic infrastructure
> for eZ Compone
> php-ezcomponents-cache - A solution for caching, supporting multiple
> backends php-ezcomponents-configuration - support for configuration files
> in different formats
> php-ezcomponents-consoletools - A set of classes to interact with the
> console php-ezcomponents-database - A lightweight database layer on top of
> PHPs PDO php-ezcomponents-databaseschema - Classes that allow you to
> extract information from a database sch
> php-ezcomponents-debug - provides a set of classes that help you to debug
> php-ezcomponents-document - general conversion framework for document
> formats php-ezcomponents-eventlog - log events or audit trails into files
> or other storage spaces
> php-ezcomponents-eventlogdatabasetiein - database writer backend for the
> EventLog component
> php-ezcomponents-execution - functionality to show errors to your
> applications users
> php-ezcomponents-feed - parsing and creating RSS1, RSS2 and ATOM feeds
> php-ezcomponents-file - file operations which are not covered by PHP
> php-ezcomponents-graph - creates pie charts, line graphs and other kinds of
> diagrams
> php-ezcomponents-graphdatabasetiein - GraphDatabaseTiein to directly use
> PDO statements
> php-ezcomponents-imageanalysis - analyse image files in different ways
> php-ezcomponents-imageconversion - apply different filters on images
> php-ezcomponents-mail - construct and/or parse Mail messages
> php-ezcomponents-mvcauthenticationtiein - Authentication filters for the
> MvcTools components
> php-ezcomponents-mvcfeedtiein - View handler to render data as ATOM or RSS
> feed
> php-ezcomponents-mvcmailtiein - extracts request data from e-mail
> php-ezcomponents-mvctemplatetiein - view handler that renders result data
> with the Template component
> php-ezcomponents-mvctools - Infrastructure for MVC applications
> php-ezcomponents-persistentobject - ORM Mapper for PHP
> php-ezcomponents-persistentobjectdatabaseschematiein - automatic generation
> of PersistentObject definition
> php-ezcomponents-phpgenerator - interface for creating PHP files and
> executing PHP code
> php-ezcomponents-search - interface to index and query documents from
> search engines
> php-ezcomponents-signalslot - implements a mechanism for object
> communication php-ezcomponents-systeminformation - access to common system
> variables, such as CPU type and speed
> php-ezcomponents-template - Templating system like smarty, but better
> php-ezcomponents-templatetranslationtiein - use translations inside
> templates php-ezcomponents-translation - reads XML translation definitions
> (the Qt Linguist format)
> php-ezcomponents-translationcachetiein - adds the TranslationCache backend
> to the Translation component
> php-ezcomponents-tree - creating, manipulating and querying of tree
> structures php-ezcomponents-treedatabasetiein - TieIn to store tree
> structures in databases
> php-ezcomponents-treepersistentobjecttiein - TieIn to handle persistent
> objects in tree structures
> php-ezcomponents-url - basic operations to handle urls
> php-ezcomponents-userinput - Filters user input
> php-ezcomponents-webdav - classes to set up and run a WebDAV (RFC 2518)
> server php-ezcomponents-workflow - Core of an Activity-Based WorkFlow
> System php-ezcomponents-workflowdatabasetiein - database backend for the
> Workflow component
> php-ezcomponents-workfloweventlogtiein - EventLog listener for the Workflow
> component
> php-ezcomponents-workflowsignalslottiein - SignalSlot links for the
> Workflow component
>
> The package appears to be lintian clean.
>
> The upload would fix these bugs: 478755
>
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/p/php-ezcomponents
> - Source repository: deb-src http://mentors.debian.net/debian unstable main
> contrib non-free
> - dget http://mentors.debian.net/debian/pool/main/p/php-ezcomponents/php-
> ezcomponents_2009.1-1.dsc
>
> I would be glad if someone uploaded this package for me.
>
> Kind regards
>
> Thomas Koch, http://www.koch.ro
Thomas Koch, http://www.koch.ro


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "u

Re: [php-maint] RFS: php-ezcomponents

[Ondřej Surý]

Do you really need to split ALL components into separate packages?

For me it would make more sense to:

- strip all tests out (huge save of disk space)
- separate */docs to separate package (php-ezcomponents-docs)
- remove */design or move it to docs if needed
- strip all kind of useless junk in */

Resulting php-ezcomponents would be just ~17M uncompressed after the
modifications, instead of 125M with test/, design/ and docs/.

Ondrej

On Tue, Jul 28, 2009 at 13:25, Thomas Koch wrote:
> I've updated the package to the new upstream version 2009.1.1.
>
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "php-ezcomponents".
>>
>> * Package name    : php-ezcomponents
>>   Version         : 2009.1-1
>>   Upstream Author : eZ Systems AS
>> * URL             : http://ezcomponents.org
>> * License         : New BSD
>>   Section         : web
>>
>> It builds these binary packages:
>> php-ezcomponents-all - Super package to install a complete release of eZ
>> Components
>> php-ezcomponents-archive - create, modify, and extract archive files
>> php-ezcomponents-authentication - support for different authentication
>> mechanisms
>> php-ezcomponents-authenticationdatabasetiein - Tie-In to connect the
>> authentication and database components
>> php-ezcomponents-base - The Base package provides the basic infrastructure
>> for eZ Compone
>> php-ezcomponents-cache - A solution for caching, supporting multiple
>> backends php-ezcomponents-configuration - support for configuration files
>> in different formats
>> php-ezcomponents-consoletools - A set of classes to interact with the
>> console php-ezcomponents-database - A lightweight database layer on top of
>> PHPs PDO php-ezcomponents-databaseschema - Classes that allow you to
>> extract information from a database sch
>> php-ezcomponents-debug - provides a set of classes that help you to debug
>> php-ezcomponents-document - general conversion framework for document
>> formats php-ezcomponents-eventlog - log events or audit trails into files
>> or other storage spaces
>> php-ezcomponents-eventlogdatabasetiein - database writer backend for the
>> EventLog component
>> php-ezcomponents-execution - functionality to show errors to your
>> applications users
>> php-ezcomponents-feed - parsing and creating RSS1, RSS2 and ATOM feeds
>> php-ezcomponents-file - file operations which are not covered by PHP
>> php-ezcomponents-graph - creates pie charts, line graphs and other kinds of
>> diagrams
>> php-ezcomponents-graphdatabasetiein - GraphDatabaseTiein to directly use
>> PDO statements
>> php-ezcomponents-imageanalysis - analyse image files in different ways
>> php-ezcomponents-imageconversion - apply different filters on images
>> php-ezcomponents-mail - construct and/or parse Mail messages
>> php-ezcomponents-mvcauthenticationtiein - Authentication filters for the
>> MvcTools components
>> php-ezcomponents-mvcfeedtiein - View handler to render data as ATOM or RSS
>> feed
>> php-ezcomponents-mvcmailtiein - extracts request data from e-mail
>> php-ezcomponents-mvctemplatetiein - view handler that renders result data
>> with the Template component
>> php-ezcomponents-mvctools - Infrastructure for MVC applications
>> php-ezcomponents-persistentobject - ORM Mapper for PHP
>> php-ezcomponents-persistentobjectdatabaseschematiein - automatic generation
>> of PersistentObject definition
>> php-ezcomponents-phpgenerator - interface for creating PHP files and
>> executing PHP code
>> php-ezcomponents-search - interface to index and query documents from
>> search engines
>> php-ezcomponents-signalslot - implements a mechanism for object
>> communication php-ezcomponents-systeminformation - access to common system
>> variables, such as CPU type and speed
>> php-ezcomponents-template - Templating system like smarty, but better
>> php-ezcomponents-templatetranslationtiein - use translations inside
>> templates php-ezcomponents-translation - reads XML translation definitions
>> (the Qt Linguist format)
>> php-ezcomponents-translationcachetiein - adds the TranslationCache backend
>> to the Translation component
>> php-ezcomponents-tree - creating, manipulating and querying of tree
>> structures php-ezcomponents-treedatabasetiein - TieIn to store tree
>> structures in databases
>> php-ezcomponents-treepersistentobjecttiein - TieIn to handle persistent
>> objects in tree structures
>> php-ezcomponents-url - basic operations to handle urls
>> php-ezcomponents-userinput - Filters user input
>> php-ezcomponents-webdav - classes to set up and run a WebDAV (RFC 2518)
>> server php-ezcomponents-workflow - Core of an Activity-Based WorkFlow
>> System php-ezcomponents-workflowdatabasetiein - database backend for the
>> Workflow component
>> php-ezcomponents-workfloweventlogtiein - EventLog listener for the Workflow
>> component
>> php-ezcomponents-workflowsignalslottiein - SignalSlot links for the
>> Workflow component
>>
>> The package appears to be lintian clean.
>>
>> The upload would f

Re: [php-maint] RFS: php-ezcomponents

[Thomas Koch]

Hi Ondrej,

thanks for looking at my package.

Does it matter, how big the source package is? Since the files you mention 
don't end up in the binary package, I'd rather just leave it as is.

Yes, upstream and me really like to have each component in an individual 
binary package. Upstream puts big efforts into makeing each component 
independent and usable as standalone. This also allows you to update each 
component separately and install only the needed components on production 
machines.

Can I convince you? :-)

Thomas

> Do you really need to split ALL components into separate packages?
>
> For me it would make more sense to:
>
> - strip all tests out (huge save of disk space)
> - separate */docs to separate package (php-ezcomponents-docs)
> - remove */design or move it to docs if needed
> - strip all kind of useless junk in */
>
> Resulting php-ezcomponents would be just ~17M uncompressed after the
> modifications, instead of 125M with test/, design/ and docs/.
>
> Ondrej
>
> On Tue, Jul 28, 2009 at 13:25, Thomas Koch wrote:
> > I've updated the package to the new upstream version 2009.1.1.
> >
> >> Dear mentors,
> >>
> >> I am looking for a sponsor for my package "php-ezcomponents".
> >>
> >> * Package name: php-ezcomponents
> >>   Version : 2009.1-1
> >>   Upstream Author : eZ Systems AS
> >> * URL : http://ezcomponents.org
> >> * License : New BSD
> >>   Section : web
> >>
> >> It builds these binary packages:
> >> php-ezcomponents-all - Super package to install a complete release of eZ
> >> Components
> >> php-ezcomponents-archive - create, modify, and extract archive files
> >> php-ezcomponents-authentication - support for different authentication
> >> mechanisms
> >> php-ezcomponents-authenticationdatabasetiein - Tie-In to connect the
> >> authentication and database components
> >> php-ezcomponents-base - The Base package provides the basic
> >> infrastructure for eZ Compone
> >> php-ezcomponents-cache - A solution for caching, supporting multiple
> >> backends php-ezcomponents-configuration - support for configuration
> >> files in different formats
> >> php-ezcomponents-consoletools - A set of classes to interact with the
> >> console php-ezcomponents-database - A lightweight database layer on top
> >> of PHPs PDO php-ezcomponents-databaseschema - Classes that allow you to
> >> extract information from a database sch
> >> php-ezcomponents-debug - provides a set of classes that help you to
> >> debug php-ezcomponents-document - general conversion framework for
> >> document formats php-ezcomponents-eventlog - log events or audit trails
> >> into files or other storage spaces
> >> php-ezcomponents-eventlogdatabasetiein - database writer backend for the
> >> EventLog component
> >> php-ezcomponents-execution - functionality to show errors to your
> >> applications users
> >> php-ezcomponents-feed - parsing and creating RSS1, RSS2 and ATOM feeds
> >> php-ezcomponents-file - file operations which are not covered by PHP
> >> php-ezcomponents-graph - creates pie charts, line graphs and other kinds
> >> of diagrams
> >> php-ezcomponents-graphdatabasetiein - GraphDatabaseTiein to directly use
> >> PDO statements
> >> php-ezcomponents-imageanalysis - analyse image files in different ways
> >> php-ezcomponents-imageconversion - apply different filters on images
> >> php-ezcomponents-mail - construct and/or parse Mail messages
> >> php-ezcomponents-mvcauthenticationtiein - Authentication filters for the
> >> MvcTools components
> >> php-ezcomponents-mvcfeedtiein - View handler to render data as ATOM or
> >> RSS feed
> >> php-ezcomponents-mvcmailtiein - extracts request data from e-mail
> >> php-ezcomponents-mvctemplatetiein - view handler that renders result
> >> data with the Template component
> >> php-ezcomponents-mvctools - Infrastructure for MVC applications
> >> php-ezcomponents-persistentobject - ORM Mapper for PHP
> >> php-ezcomponents-persistentobjectdatabaseschematiein - automatic
> >> generation of PersistentObject definition
> >> php-ezcomponents-phpgenerator - interface for creating PHP files and
> >> executing PHP code
> >> php-ezcomponents-search - interface to index and query documents from
> >> search engines
> >> php-ezcomponents-signalslot - implements a mechanism for object
> >> communication php-ezcomponents-systeminformation - access to common
> >> system variables, such as CPU type and speed
> >> php-ezcomponents-template - Templating system like smarty, but better
> >> php-ezcomponents-templatetranslationtiein - use translations inside
> >> templates php-ezcomponents-translation - reads XML translation
> >> definitions (the Qt Linguist format)
> >> php-ezcomponents-translationcachetiein - adds the TranslationCache
> >> backend to the Translation component
> >> php-ezcomponents-tree - creating, manipulating and querying of tree
> >> structures php-ezcomponents-treedatabasetiein - TieIn to store tree
> >> structures in databases
> >> php-ezc

Can't open man1/optin.so: No such file or directory

[Mathieu Malaterre]

Hi there,

 I am working on the dicom3tools package. The dicom3tools is writing
the man page using groff '.so' macro (source) (*). Which leads to the
following lintian warning :

W: dicom3tools: manpage-has-errors-from-man
usr/share/man/man1/andump.1.gz  can't open man1/optin.so: No such file
or directory
...
W: dicom3tools: manpage-has-errors-from-man
usr/share/man/man1/rawtodc.1.gz  can't open man1/genin.so: No such
file or directory


 Because the naming convention of those common parameter is bla.*so*,
lintian is not happy to install something called optin.*so*.1 in the
man1 path. Has anyone dealt with this before ? Can I simply rename
optin.so file to optin, and then install optin.1, or am I missing
something with groff ?

Ref:
http://svn.debian.org/wsvn/debian-med/trunk/packages/dicom3tools/trunk/

Thanks,
--
Mathieu


(*)http://www.schweikhardt.net/man_page_howto.html


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [php-maint] RFS: php-ezcomponents

[Ondřej Surý]

Hi Thomas,

On Tue, Jul 28, 2009 at 14:09, Thomas Koch wrote:
> Hi Ondrej,
>
> thanks for looking at my package.
>
> Does it matter, how big the source package is? Since the files you mention
> don't end up in the binary package, I'd rather just leave it as is.

It's not about size of source file. I didn't even start checking what
do you really put into binary files.

> Yes, upstream and me really like to have each component in an individual
> binary package. Upstream puts big efforts into makeing each component
> independent and usable as standalone.

They're not - some of components have dependencies on another
components (*/DEPS)

> This also allows you to update each component separately

No, it doesn't since they all have 2009.1.1 version.

> and install only the needed components on production machines.

How big is each component - tiny. I am not convinced it's worth
splitting them into separate packages. This will clutter packages list
etc.,etc.

And in the end the most common scenario would be to install
php-ez...-all, because user will be tired for searching his bit of
code among all those packages.

Ondrej.

> Can I convince you? :-)
>
> Thomas
>
>> Do you really need to split ALL components into separate packages?
>>
>> For me it would make more sense to:
>>
>> - strip all tests out (huge save of disk space)
>> - separate */docs to separate package (php-ezcomponents-docs)
>> - remove */design or move it to docs if needed
>> - strip all kind of useless junk in */
>>
>> Resulting php-ezcomponents would be just ~17M uncompressed after the
>> modifications, instead of 125M with test/, design/ and docs/.
>>
>> Ondrej
>>
>> On Tue, Jul 28, 2009 at 13:25, Thomas Koch wrote:
>> > I've updated the package to the new upstream version 2009.1.1.
>> >
>> >> Dear mentors,
>> >>
>> >> I am looking for a sponsor for my package "php-ezcomponents".
>> >>
>> >> * Package name    : php-ezcomponents
>> >>   Version         : 2009.1-1
>> >>   Upstream Author : eZ Systems AS
>> >> * URL             : http://ezcomponents.org
>> >> * License         : New BSD
>> >>   Section         : web
>> >>
>> >> It builds these binary packages:
>> >> php-ezcomponents-all - Super package to install a complete release of eZ
>> >> Components
>> >> php-ezcomponents-archive - create, modify, and extract archive files
>> >> php-ezcomponents-authentication - support for different authentication
>> >> mechanisms
>> >> php-ezcomponents-authenticationdatabasetiein - Tie-In to connect the
>> >> authentication and database components
>> >> php-ezcomponents-base - The Base package provides the basic
>> >> infrastructure for eZ Compone
>> >> php-ezcomponents-cache - A solution for caching, supporting multiple
>> >> backends php-ezcomponents-configuration - support for configuration
>> >> files in different formats
>> >> php-ezcomponents-consoletools - A set of classes to interact with the
>> >> console php-ezcomponents-database - A lightweight database layer on top
>> >> of PHPs PDO php-ezcomponents-databaseschema - Classes that allow you to
>> >> extract information from a database sch
>> >> php-ezcomponents-debug - provides a set of classes that help you to
>> >> debug php-ezcomponents-document - general conversion framework for
>> >> document formats php-ezcomponents-eventlog - log events or audit trails
>> >> into files or other storage spaces
>> >> php-ezcomponents-eventlogdatabasetiein - database writer backend for the
>> >> EventLog component
>> >> php-ezcomponents-execution - functionality to show errors to your
>> >> applications users
>> >> php-ezcomponents-feed - parsing and creating RSS1, RSS2 and ATOM feeds
>> >> php-ezcomponents-file - file operations which are not covered by PHP
>> >> php-ezcomponents-graph - creates pie charts, line graphs and other kinds
>> >> of diagrams
>> >> php-ezcomponents-graphdatabasetiein - GraphDatabaseTiein to directly use
>> >> PDO statements
>> >> php-ezcomponents-imageanalysis - analyse image files in different ways
>> >> php-ezcomponents-imageconversion - apply different filters on images
>> >> php-ezcomponents-mail - construct and/or parse Mail messages
>> >> php-ezcomponents-mvcauthenticationtiein - Authentication filters for the
>> >> MvcTools components
>> >> php-ezcomponents-mvcfeedtiein - View handler to render data as ATOM or
>> >> RSS feed
>> >> php-ezcomponents-mvcmailtiein - extracts request data from e-mail
>> >> php-ezcomponents-mvctemplatetiein - view handler that renders result
>> >> data with the Template component
>> >> php-ezcomponents-mvctools - Infrastructure for MVC applications
>> >> php-ezcomponents-persistentobject - ORM Mapper for PHP
>> >> php-ezcomponents-persistentobjectdatabaseschematiein - automatic
>> >> generation of PersistentObject definition
>> >> php-ezcomponents-phpgenerator - interface for creating PHP files and
>> >> executing PHP code
>> >> php-ezcomponents-search - interface to index and query documents from
>> >> search engines
>> >> php-ezcomponents-signals

Re: [php-maint] RFS: php-ezcomponents

[Thomas Koch]

Hi Ondrej,

> > Yes, upstream and me really like to have each component in an individual
> > binary package. Upstream puts big efforts into makeing each component
> > independent and usable as standalone.
>
> They're not - some of components have dependencies on another
> components (*/DEPS)
There are few components with direct dependencies, like PersistentObject on 
Database. In rest there are so called TieIn components, that provide the 
functionality of one component for another. For example The 
AuthenticationDatabaseTieIn provides storage of user credentials in the 
database.


> > This also allows you to update each component separately
>
> No, it doesn't since they all have 2009.1.1 version.
As soon as php-ezcomponents is in Debian, I'll match the dependencies defined 
in the release-info.xml to the individual releases.

> > and install only the needed components on production machines.
>
> How big is each component - tiny. I am not convinced it's worth
> splitting them into separate packages. This will clutter packages list
> etc.,etc.
>
> And in the end the most common scenario would be to install
> php-ez...-all, because user will be tired for searching his bit of
> code among all those packages.
If you do it one way or the other, there will be users complaining. If I 
package everything in one package, then there are people naging: "I don't like 
to install all this eZComponents things, if I only want the template engine"

You can see this kind of discussions often with javascript frameworks. People 
complained, that YUI is too big, but in fact you only ever load a small subset 
for each request.

I also think it's nicer to have only the code you need on the machine. You 
don't need to bother about security issues in code you don't have installed.

Finaly I think that people indeed use individual components instead of 
ezcomponents-all. Since it's a library, it will come to your machine most time 
in form of dependencies. So the package maintainer using ezcomponents can 
pick, what he actually needs for his package.

Hope you still have patience with me,

Thomas Koch, http://www.koch.ro


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

ldconfig symlink issue

[Harry Rickards]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I apologize for this question, as it's probably easy to answer for
someone experienced in packaging libraries.

When packaging a shared library, I can't seem to create the symlinks
correctly. If I let the Makefile create the symlinks I get
ldconfig-symlink-is-not-a-symlink, however if I remove the lines that
make the symlinks I get ldconfig-symlink-missing-for-shlib from lintian.

Again, I apologize for this being a noob question.

- --
Thanks
Harry Rickards 

GPG Key Info:
pub   1024R/58449F6F 2009-06-12
uid  Harry Rickards (OpenPGP Card) 
sub   1024R/D775CCEE 2009-06-12
sub   1024R/9394048C 2009-06-12
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAkpvKYcACgkQ+9DWHFhEn2+zpQP+JvJtsZxiZebt2F9XpMIapuJ5
zOwsSq8K7cGaRB20viIBt6IOfX7+CbD9H0jt2ULvmiWzm2AEtYPB3BCAj39uXyEJ
paoxFTUU0mAAW/6oUz8LRUFpvCdMZrdbG5hRGlV+XeO0lCj3WXWGixcdoitDbhDw
rd+CzmGcZdNyvV9N9+I=
=7rQA
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: MUMmer patches and Artistic license.

[Andreas Tille]

On Sun, Jul 12, 2009 at 10:50:10PM +0900, Charles Plessy wrote:
> > This patch is a good idea -- fixed length buffers are rarely considered 
> > user-friendly.  However, it is executed poorly; it's not ready for upstream 
> > in its current state.
> 
> Hi, thank you for the comment.
> 
> I will stop to apply this patch until a better solution is found.

Quite late comment after working down my batch of unread mail:
The patch was *not* *only* to avoid fixed length buffers - it was
invented to stop mummer from *crashing*.  I do not remember the
case exactly nor do I find the data any more but I *clearly*
remember that we actually had example data which were causing
mummer to crash without the patch.

Kind regards

 Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ldconfig symlink issue

[Chow Loong Jin]

On Wednesday 29,July,2009 12:38 AM, Harry Rickards wrote:
> I apologize for this question, as it's probably easy to answer for
> someone experienced in packaging libraries.
> 
> When packaging a shared library, I can't seem to create the symlinks
> correctly. If I let the Makefile create the symlinks I get
> ldconfig-symlink-is-not-a-symlink, however if I remove the lines that
> make the symlinks I get ldconfig-symlink-missing-for-shlib from lintian.
> 
> Again, I apologize for this being a noob question.
> 
A library package should contain the following:
/usr/lib/libfoo.so.X (link) => libfoo.so.X.Y.Z
/usr/lib/libfoo.so.X.Y.Z (regular file)

A library -dev package should contain the following:
/usr/lib/libfoo.so (link) => libfoo.so.X.Y.Z
and optionally:
/usr/lib/libfoo.a (regular file)
/usr/lib/libfoo.la (regular file)

If I am not mistaken, ldconfig-symlink-is-not-a-symlink arises from a
package that contains a file /usr/lib/libfoo.so.X, rather than a
symlink, as I've shown above, while ldconfig-symlink-missing-from-shlib
arises from a package that does not contain the /usr/lib/libfoo.so.X
symlink.

You can get more information about a lintian tag by running:
$ lintian-info -t 

http://www.debian.org/doc/debian-policy/ch-sharedlibs.html is a good
read, by the way.

-- 
Kind regards,
Chow Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: MUMmer patches and Artistic license.

[Boyd Stephen Smith Jr.]

In <20090728163525.gc31...@an3as.eu>, Andreas Tille wrote:
>On Sun, Jul 12, 2009 at 10:50:10PM +0900, Charles Plessy wrote:
>> > This patch is a good idea -- fixed length buffers are rarely
>> > considered user-friendly.  However, it is executed poorly; it's not
>> > ready for upstream in its current state.
>>
>> Hi, thank you for the comment.
>> I will stop to apply this patch until a better solution is found.
>
>Quite late comment after working down my batch of unread mail:
>The patch was *not* *only* to avoid fixed length buffers - it was
>invented to stop mummer from *crashing*.

In that case I recommend leaving the patch applied, opening a bug, and 
assigning it to me.  I can re-write the patch to avoid having statements 
with side-effects inside assert() calls.

I may be able to reply with a corrected patch later today.

P.S.  Please CC me if you drop debian-mentors, I am not subscribed to 
debian-med.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/



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

Re: ldconfig symlink issue

[Harry Rickards]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chow Loong Jin wrote:
> On Wednesday 29,July,2009 12:38 AM, Harry Rickards wrote:
>> I apologize for this question, as it's probably easy to answer for
>> someone experienced in packaging libraries.
>>
>> When packaging a shared library, I can't seem to create the symlinks
>> correctly. If I let the Makefile create the symlinks I get
>> ldconfig-symlink-is-not-a-symlink, however if I remove the lines that
>> make the symlinks I get ldconfig-symlink-missing-for-shlib from lintian.
>>
>> Again, I apologize for this being a noob question.
>>
> A library package should contain the following:
> /usr/lib/libfoo.so.X (link) => libfoo.so.X.Y.Z
> /usr/lib/libfoo.so.X.Y.Z (regular file)
> 
> A library -dev package should contain the following:
> /usr/lib/libfoo.so (link) => libfoo.so.X.Y.Z
> and optionally:
> /usr/lib/libfoo.a (regular file)
> /usr/lib/libfoo.la (regular file)
> 
> If I am not mistaken, ldconfig-symlink-is-not-a-symlink arises from a
> package that contains a file /usr/lib/libfoo.so.X, rather than a
> symlink, as I've shown above, while ldconfig-symlink-missing-from-shlib
> arises from a package that does not contain the /usr/lib/libfoo.so.X
> symlink.

That's what I've got. Symbolic links are created with 'ln -s' right? I
seem to have fixed this myself anyway somehow. I was just playing around
with the Makefile and debian/rules. Thanks for the help anyway.

> You can get more information about a lintian tag by running:
> $ lintian-info -t 
> 
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html is a good
> read, by the way.
> 
Thanks for the link.

- --
Thanks
Harry Rickards 

GPG Key Info:
pub   1024R/58449F6F 2009-06-12
uid  Harry Rickards (OpenPGP Card) 
sub   1024R/D775CCEE 2009-06-12
sub   1024R/9394048C 2009-06-12
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAkpvQAQACgkQ+9DWHFhEn28t5AQApY0HWOcSM5txSS60rdKHD+Gu
1UuHbpgZ7mTZtZ3VwHD4ohPvCFe2FKNUGs09HwCta2yfq+kBUA6FxWnXChFguZsB
u3lyaPSaDuajZ+R9J21819g8vNRXGKVY34gUO0V/C9LSjXXTAONXO/b0SPuYOMDv
TQDr0p9OaYfZ/7H6fHs=
=DIUP
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

RFS: libpcapnav

[eriberto]

Dear mentors,

I am looking for a sponsor for my package "libpcapnav".

* Package name: libpcapnav
 Version : 0.8-1
 Upstream Author : Christian Kreibich 
* URL : http://netdude.sourceforge.net
 Section : libs

It builds these binary packages:
libpcapnav0 - wrapper to libpcap
libpcapnav0-dev - development files for libpcapnav

The package appears to be lintian clean.

The upload would fix these bugs: 535206

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/libpcapnav
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/l/libpcapnav/libpcapnav_0.8-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards,

Eriberto - Brazil






signature.asc
Description: OpenPGP digital signature

Re: MUMmer patches and Artistic license.

[Boyd Stephen Smith Jr.]

In <200907281303.42301@iguanasuicide.net>, Boyd Stephen Smith Jr. wrote:
>In <20090728163525.gc31...@an3as.eu>, Andreas Tille wrote:
>>On Sun, Jul 12, 2009 at 10:50:10PM +0900, Charles Plessy wrote:
>>> > This patch is a good idea -- fixed length buffers are rarely
>>> > considered user-friendly.  However, it is executed poorly; it's not
>>> > ready for upstream in its current state.
>>>
>>> Hi, thank you for the comment.
>>> I will stop to apply this patch until a better solution is found.
>>
>>Quite late comment after working down my batch of unread mail:
>>The patch was *not* *only* to avoid fixed length buffers - it was
>>invented to stop mummer from *crashing*.
>
>I may be able to reply with a corrected patch later today.

Attached is my new patch that removes the errors I saw in the original 
patch.  I welcome any comments on the new patch.

I've also attached a interdiff between the old and new patches for 
reference.

In case anyone feels this work is copyrightable[1], I license my 
contributions under the same license as the original patch.

P.S.  Please CC me if you drop debian-mentors, I am not subscribed to
debian-med.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/

[1] I don't.
Description: Dynamically allocates space for the strings, instead allocating a predefined size.
Origin: vendor : Debian
Bug: https://sourceforge.net/tracker/?func=detail&aid=1215086&group_id=133157&atid=726404
Index: ./src/tigr/annotate.cc
===
--- ./src/tigr/annotate.cc
+++ ./src/tigr.orig/annotate.cc
@@ -10,6 +10,7 @@
 */
 
 #include "tigrinc.hh"
+#include 
 
 #define  FIELD_LEN  20
 #define  MAX_ALIGN  1
@@ -138,19 +139,26 @@ void  Show_Alignment (char A [], long in
 //  Print the alignment between strings  A [1 .. M]  and  B [1 .. N] .
 
   {
-   static int  D [MAX_ALIGN] [MAX_ALIGN];
-   static char  Op [MAX_ALIGN] [MAX_ALIGN];
-   static char  Show_A [2 * MAX_ALIGN];
-   static char  Show_B [2 * MAX_ALIGN];
+   int  **D,  *D_buf;
+   char **Op, *Op_buf;
+   char  *Show_A;
+   char  *Show_B;
int  Errors, Tmp;
long int  i, j, Ct;
 
-   if  (M >= MAX_ALIGN || N >= MAX_ALIGN)
-   {
-printf ("\n   *** Too long ***\n\n");
-fprintf (Gaps_With_Errors_File, "%s %7s\n", Line, "-");
-return;
-   }
+   assert ( SIZE_MAX / (M+1) >= (N+1) ) ;
+   D_buf  = (int  *) calloc ( (M+1)*(N+1), sizeof(int) ) ;
+   assert ( D_buf ) ;
+   D  = &D_buf ;
+   Op_buf = (char *) calloc ( (M+1)*(N+1), sizeof(char) ) ;
+   assert ( Op_buf ) ;
+   Op = &Op_buf ;
+
+   assert ( SIZE_MAX >> 1 >= (M+1) ) ;
+   Show_A = (char *) calloc ( 2*(M+1) , sizeof(char) ) ;
+   assert ( Show_A ) ;
+   Show_B = (char *) calloc ( 2*(N+1) , sizeof(char) ) ;
+   assert ( Show_B ) ;
 
D [0] [0] = 0;
Op [0] [0] = 'a';
@@ -229,5 +237,10 @@ void  Show_Alignment (char A [], long in
   putchar ('\n');
   Ct -= WIDTH;
  }  while  (Ct > 0);
+
+   free ( D_buf ) ;
+   free ( Op_buf ) ;
+   free ( Show_A ) ;
+   free ( Show_B ) ;
return;
   }
diff -u ./src/tigr/annotate.cc ./src/tigr.orig/annotate.cc
--- ./src/tigr/annotate.cc	2007-11-07 21:47:03.0 +0100
+++ ./src/tigr.orig/annotate.cc
@@ -146,12 +146,19 @@
int  Errors, Tmp;
long int  i, j, Ct;
 
-   assert ( D_buf  = (int  *) calloc ( (M+1)*(N+1), sizeof(int) ) ) ;
+   assert ( SIZE_MAX / (M+1) >= (N+1) ) ;
+   D_buf  = (int  *) calloc ( (M+1)*(N+1), sizeof(int) ) ;
+   assert ( D_buf ) ;
D  = &D_buf ;
-   assert ( Op_buf = (char *) calloc ( (M+1)*(N+1), sizeof(char) ) ) ;
+   Op_buf = (char *) calloc ( (M+1)*(N+1), sizeof(char) ) ;
+   assert ( Op_buf ) ;
Op = &Op_buf ;
-   assert ( Show_A = (char *) calloc ( 2*(M+1) , sizeof(char) ) ) ;
-   assert ( Show_B = (char *) calloc ( 2*(N+1) , sizeof(char) ) ) ;
+
+   assert ( SIZE_MAX >> 1 >= (M+1) ) ;
+   Show_A = (char *) calloc ( 2*(M+1) , sizeof(char) ) ;
+   assert ( Show_A ) ;
+   Show_B = (char *) calloc ( 2*(N+1) , sizeof(char) ) ;
+   assert ( Show_B ) ;
 
D [0] [0] = 0;
Op [0] [0] = 'a';


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

Re: Can't open man1/optin.so: No such file or directory

[George Danchev]

> Hi there,

Hi,

>  I am working on the dicom3tools package. The dicom3tools is writing
> the man page using groff '.so' macro (source) (*). Which leads to the
> following lintian warning :
>
> W: dicom3tools: manpage-has-errors-from-man
> usr/share/man/man1/andump.1.gz  can't open man1/optin.so: No such file
> or directory
> ...
> W: dicom3tools: manpage-has-errors-from-man
> usr/share/man/man1/rawtodc.1.gz  can't open man1/genin.so: No such
> file or directory
>
>
>  Because the naming convention of those common parameter is bla.*so*,
> lintian is not happy to install something called optin.*so*.1 in the

These are accepted (for instance: vsftpd.conf.5), what is not accepted is 
uncompressed manpages or a missing files referenced for inclusion by other 
manpages, which are actually incomplete when parts of them are missing.

> man1 path. Has anyone dealt with this before ? Can I simply rename
> optin.so file to optin, and then install optin.1, or am I missing
> something with groff ?
>
> Ref:
> http://svn.debian.org/wsvn/debian-med/trunk/packages/dicom3tools/trunk/
>
> Thanks,
> --
> Mathieu
>
>
> (*)http://www.schweikhardt.net/man_page_howto.html

There is no easy way for dh_installman to guess that optin.so as found in 
source directory is actually a manpage content meant for inclusion, so you 
should take the control yourself and install that files in place from 
debian/rules either by copying it or by calling dh_install + 
.install file containing something as follows:

path/to/optin.so   usr/share/man/man1

However there are two issues here: 

* optin.so should not be compressed since it is referenced to by other 
manpages as `optin.so' as I see it, thus you should also call  dh_compess -
Xoption.so -Xgenin.so and so on... in order to prevent that.

* lintian would later complain that your package actually provides an 
uncompressed manpages, since optin.so and friends are left in place 
uncompressed as they are referenced that way. You can of course override this, 
however I don't think that populating /usr/share/man/man1/ with random named 
uncompressed files meant for inclusion is a sane way to go or at least that 
would need a discussion and conventions agreed upon. A better solution would 
to include compressed manpage files, however I'm not sure if that is at all 
possible.

-- 
pub 4096R/0E4BD0AB 2003-03-18 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Define files for multiple packages from one tarball

[Harry Rickards]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry to bother everyone again with a noob question (Google was no
help), but how do you define which files go in which package when you
have multiple packages for one tarball. I've got 4 packages,
libweed-dev, libweed0, lives and lives-data. I've created a
package.install file for each of them.

$ cat libweed-dev.install
usr/include
usr/lib/*.a
usr/lib/*.so

$ cat libweed0.install
usr/lib/*.so.0*

$ cat lives-data.install
usr/share
usr/lib/lives/plugins/effects/rendered
usr/lib/lives/plugins/encoders

$cat lives.install
usr/bin
usr/lib/lives/plugins/effects/realtime/weed
usr/lib/lives/plugins/playback
usr/lib/lives/plugins/decoders
hricka...@siddy:~/downloads/lives/weed/lives-1.


However, everything apart from the changelog and copyright goes into
lives? I've got them separated out line after line in debian/control and
dh_listpackages shows them correctly:

$ dh_listpackages
lives
libweed0
libweed-dev
lives-data

Also, everything under binary-indep in debian/rules comes up with 'You
asked that all arch in(dep) packages be built, but there are none of
that type'.

Also, possibly of some relevance is the fact that I originally specified
the type as 'single binary' when dh_make asked me. However, I've created
blank packages for both single and multiple binaries, and I can't find
any difference.

Thanks for any help


- --
Thanks
Harry Rickards 

GPG Key Info:
pub   1024R/58449F6F 2009-06-12
uid  Harry Rickards (OpenPGP Card) 
sub   1024R/D775CCEE 2009-06-12
sub   1024R/9394048C 2009-06-12
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAkpvUKAACgkQ+9DWHFhEn29lkgP/Ygy7gELqEVICf4bv371J/d+K
dbZxtKi2ifGRhhh775i38QDJeqldT1uzKVBmuwVvh9i9bo0FgHmMPr9fwkGKXStD
zz+UvAyCWWEAX8aka3yJl4I8TgHInOsy36BmyQ2DGpix8JnxVAEymTmIO8TCvv+h
ICA9xTzW3Nq2rQ9qVKs=
=FcPh
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Define files for multiple packages from one tarball

[Harry Rickards]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Harry Rickards wrote:
> Sorry to bother everyone again with a noob question (Google was no
> help), but how do you define which files go in which package when you
> have multiple packages for one tarball. I've got 4 packages,
> libweed-dev, libweed0, lives and lives-data. I've created a
> package.install file for each of them.
> 
> $ cat libweed-dev.install
> usr/include
> usr/lib/*.a
> usr/lib/*.so
> 
> $ cat libweed0.install
> usr/lib/*.so.0*
> 
> $ cat lives-data.install
> usr/share
> usr/lib/lives/plugins/effects/rendered
> usr/lib/lives/plugins/encoders
> 
> $cat lives.install
> usr/bin
> usr/lib/lives/plugins/effects/realtime/weed
> usr/lib/lives/plugins/playback
> usr/lib/lives/plugins/decoders
> hricka...@siddy:~/downloads/lives/weed/lives-1.
> 
> 
> However, everything apart from the changelog and copyright goes into
> lives? I've got them separated out line after line in debian/control and
> dh_listpackages shows them correctly:
> 
> $ dh_listpackages
> lives
> libweed0
> libweed-dev
> lives-data
> 
> Also, everything under binary-indep in debian/rules comes up with 'You
> asked that all arch in(dep) packages be built, but there are none of
> that type'.
> 
> Also, possibly of some relevance is the fact that I originally specified
> the type as 'single binary' when dh_make asked me. However, I've created
> blank packages for both single and multiple binaries, and I can't find
> any difference.
> 
> Thanks for any help
> 
> 
Actually, ignore that. I've found out it was a dodgy rule in debian/rules.

- --
Thanks
Harry Rickards 

GPG Key Info:
pub   1024R/58449F6F 2009-06-12
uid  Harry Rickards (OpenPGP Card) 
sub   1024R/D775CCEE 2009-06-12
sub   1024R/9394048C 2009-06-12
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAkpvUccACgkQ+9DWHFhEn2+5lwP/faMIVIeAByoKBngbQOQdS218
Ca/iPKauD4wrWQPq/JAm3//5neOjTY6OHwU1OEIH/8/u50VZiei/MvIz4ueN54KT
NqdAy9jtPa/RMiUoWDMzIGbAt3gkVlxwPDNnzu9GyDbuQ+d0H5wOMsIayudVUssL
WpaAW+fflQlynLhULKQ=
=XfmS
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

RFS: dict-devil (adopted package)

[Sven Joachim]

Dear mentors,

I am looking for a sponsor for the new version 1.0-11
of my package "dict-devil".

It builds this binary package:
dict-devil - The Devil's Dictionary by Ambrose Bierce

This package contains The Devil's Dictionary, a satirical, cynical and
irreverent dictionary of common words, formatted for use by the
dictionary server in the dictd package.

An entry from this dictionary is shown in the signature of this mail.

The upload would the ITA bug #436116 and three minor bugs in the
package, #283796, #314607, and #458207.


Lintian reports three issues at the --pedantic level:

,
| P: dict-devil: no-homepage-field
| P: dict-devil: no-upstream-changelog
| P: dict-devil source: direct-changes-in-diff-but-no-patch-system devils.txt
`

There is no upstream homepage or changelog, and since the orig.tar.gz
contains only a single file, a patch system seems overkill to me.


The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/d/dict-devil
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/d/dict-devil/dict-devil_1.0-11.dsc

I would be glad if someone uploaded this package for me.

Regards,
Sven

-- 
IGNORAMUS, n.  A person unacquainted with certain kinds of knowledge
 familiar to yourself, and having certain other kinds that you know
 nothing about.


pgpqngKb20jPt.pgp
Description: PGP signature

Re: Can't open man1/optin.so: No such file or directory

[Russ Allbery]

George Danchev  writes:

> There is no easy way for dh_installman to guess that optin.so as found
> in source directory is actually a manpage content meant for inclusion,
> so you should take the control yourself and install that files in place
> from debian/rules either by copying it or by calling dh_install +
> .install file containing something as follows:
>
> path/to/optin.so   usr/share/man/man1
>
> However there are two issues here: 
>
> * optin.so should not be compressed since it is referenced to by other 
> manpages as `optin.so' as I see it, thus you should also call  dh_compess -
> Xoption.so -Xgenin.so and so on... in order to prevent that.
>
> * lintian would later complain that your package actually provides an
> uncompressed manpages, since optin.so and friends are left in place
> uncompressed as they are referenced that way. You can of course override
> this, however I don't think that populating /usr/share/man/man1/ with
> random named uncompressed files meant for inclusion is a sane way to go
> or at least that would need a discussion and conventions agreed upon. A
> better solution would to include compressed manpage files, however I'm
> not sure if that is at all possible.

Another option would be to install the extra man page data into a
/usr/share/ directory and then modify the man page to include it
via its full path instead of expecting it to live in the man directory
alongside the man pages.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: joystick (updated package fixing a serious bug)

[Stephen Kitt]

On Tue, 21 Jul 2009 14:44:18 -0400, Barry deFreese 
wrote:
> Uploaded.  Thanks!

Thank you (belatedly), and also for sponsoring the previous upload!

Regards,

Stephen


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Can't open man1/optin.so: No such file or directory

[George Danchev]

> George Danchev  writes:
> > There is no easy way for dh_installman to guess that optin.so as found
> > in source directory is actually a manpage content meant for inclusion,
> > so you should take the control yourself and install that files in place
> > from debian/rules either by copying it or by calling dh_install +
> > .install file containing something as follows:
> >
> > path/to/optin.so   usr/share/man/man1
> >
> > However there are two issues here:
> >
> > * optin.so should not be compressed since it is referenced to by other
> > manpages as `optin.so' as I see it, thus you should also call  dh_compess
> > - Xoption.so -Xgenin.so and so on... in order to prevent that.
> >
> > * lintian would later complain that your package actually provides an
> > uncompressed manpages, since optin.so and friends are left in place
> > uncompressed as they are referenced that way. You can of course override
> > this, however I don't think that populating /usr/share/man/man1/ with
> > random named uncompressed files meant for inclusion is a sane way to go
> > or at least that would need a discussion and conventions agreed upon. A
> > better solution would to include compressed manpage files, however I'm
> > not sure if that is at all possible.
>
> Another option would be to install the extra man page data into a
> /usr/share/ directory and then modify the man page to include it
> via its full path instead of expecting it to live in the man directory
> alongside the man pages.

That would be much better indeed. However, I suspect that the path to the files 
sourced via 'so' macro is relative to /usr/share/man/ (as 'so man1/foobar.so' 
was given in the example above) so having 'so ..//foobar.so' in the 
man page should deal with it.

-- 
pub 4096R/0E4BD0AB 2003-03-18 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: UNS: Re: RFS: lshell (3rd try)

[Ignace Mouzannar]

On Tue, Jul 28, 2009 at 05:31, Maximiliano Curia wrote:
> Hola Ignace Mouzannar!

Hola Maximiliano!

> There a few ways to check if a group exists, calling sg group_name true is a
> creative one, I not against the solution, but using getent group
> group_name is probably a more traditional approach used in a few other
> packages, in general, it's good to accept the de facto standard.

Thank you for the tip. This has been corrected.

>> The debian/rules file has been modified to use debhelper without cdbs.
>
> Great, I appreciate the effort, I didn't mean "do it right away", though.

No worries, it was very useful for me to create a debian/rules file
from scratch using only debhelper.

> Extra comments:
>  - control claims Build-Dependency of debhelper >= 7, but compat says 5, one
>   or the other is wrong, please fix it.

debian/compat has been set to 7.

>  - manpage:

As the manpage is gunzip'ed in the source of lshell-0.9.4, I released
a new upstream version with a non compressed manpage including the
modifications below.
The new lshell version is 0.9.5 [1].

>   - Refers to group lshellg instead of lshell

This has been corrected.

>   - Doesn't mention the default config file (/etc/lshell.conf)

I added this to the "CONFIGURATION" section.

>   - ¿Why is there a section called TODO?

I renamed this section as "NOTES" and moved it to the end of the manpage.

>  - It would be great if you document how to use lshell inside a chroot, maybe
>   even using makejail.

I am planning to work on this in the upcoming release.

A new package has been uploaded on m.d.n [2].

Thank you again for your help.

Regards,
Ignace M

[1] http://lshell.ghantoos.org/
[2] The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/lshell
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/l/lshell/lshell_0.9.5-1.dsc


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: UNS: Re: RFS: lshell (3rd try)

[Maximiliano Curia]

Hola Ignace Mouzannar!

El 29/07/2009 a las 01:20 escribiste:
> >  - It would be great if you document how to use lshell inside a chroot, 
> > maybe
> >   even using makejail.

> I am planning to work on this in the upcoming release.

Ok, a few other things to add to the TODO list:
 - Upstream changelog gets installed twice (CHANGES.gz and changelog.gz)
 - A little document describing some useful setups lshell, as git, bzr, cvs, 
svn, rsync.

> Thank you again for your help.

You are welcome, good work so far, keep it up.

Uploaded.

-- 
Confucius say: He who play in root, eventually kill tree.
Saludos /\/\ /\ >< `/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Can't open man1/optin.so: No such file or directory

[Peter Miller]

On Tue, 2009-07-28 at 16:10 +0200, Mathieu Malaterre wrote: 
> Hi there,
> 
>  I am working on the dicom3tools package. The dicom3tools is writing
> the man page using groff '.so' macro (source) (*). Which leads to the
> following lintian warning :
> 
> W: dicom3tools: manpage-has-errors-from-man
> usr/share/man/man1/andump.1.gz  can't open man1/optin.so: No such file
> or directory

I use the gsoelim command from the groff package to resolve all of the
includes, and install the output.  I do not install the include files at
all.  The makefile fragments look like this, although you will need to
modify them to suit the particular project:

$(mandir)/man1/%.1: man1/%.1
 gsoelim %.1 > $@

Advantages:
- there are no include directives in the installed .gz files
- you don't have to worry about whether or not to keep the .so file
uncompressed, and
- there is no ambiguity as to whether or not a .so file is a shared
library or something else.

Disadvantages:
- line numbers will be wrong in error messages from groff when
processing broken installed man pages.


-- 
Regards
Peter Miller 
/\/\*http://miller.emu.id.au/pmiller/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.


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