Re: RFS: pdfmerge

--- Esteban Manchado Velázquez <[EMAIL PROTECTED]> wrote: > On Tue, Mar 02, 2004 at 11:43:26PM -0800, Ben Young > wrote: > > On 03/03/04, Matthew Palmer wrote: > > > > > Make that at least two. And I haven't exactly > seen > > a huge clamour of people > > > rushing to your defence in any coheren

Re: RFS: pdfmerge

--- Esteban Manchado Velázquez <[EMAIL PROTECTED]> wrote: > On Tue, Mar 02, 2004 at 11:43:26PM -0800, Ben Young > wrote: > > On 03/03/04, Matthew Palmer wrote: > > > > > Make that at least two. And I haven't exactly > seen > > a huge clamour of people > > > rushing to your defence in any coheren

Re: RFS: pdfmerge

On Tue, Mar 02, 2004 at 11:43:26PM -0800, Ben Young wrote: > On 03/03/04, Matthew Palmer wrote: > > > Make that at least two. And I haven't exactly seen > a huge clamour of people > > rushing to your defence in any coherent fashion. > > It's not a bad concept, > > > > You are free to take your

Re: RFS: pdfmerge

On Tue, Mar 02, 2004 at 11:43:26PM -0800, Ben Young wrote: > On 03/03/04, Matthew Palmer wrote: > > > Make that at least two. And I haven't exactly seen > a huge clamour of people > > rushing to your defence in any coherent fashion. > > It's not a bad concept, > > > > You are free to take your

Re: RFS: pdfmerge

Hi Philipp! On Wed, Mar 03, 2004 at 12:33:39AM +0100, Philipp Gortan wrote: > >The proper place for the script (after doing things right) is > >ghostscript upstream. Take a look at pdf2ps and try to get your program > >next to that. There's no reason to produce packages for a one liner. > ok, so w

Re: RFS: pdfmerge

Hi Philipp! On Wed, Mar 03, 2004 at 12:33:39AM +0100, Philipp Gortan wrote: > >The proper place for the script (after doing things right) is > >ghostscript upstream. Take a look at pdf2ps and try to get your program > >next to that. There's no reason to produce packages for a one liner. > ok, so w

Re: RFS: pdfmerge

Kalle Kivimaa wrote: pdftk - A useful tool for manipulating PDF documents Totally right, but: depends: libgcj4 (>= 1:3.3.2-1) Java runtime library for use with gcj -- When in doubt, use brute force. -- Ken Thompson

Re: RFS: pdfmerge

On Wed, Mar 03, 2004 at 12:33:39AM +0100, Philipp Gortan wrote: > Thomas Viehmann wrote: > >The proper place for the script (after doing things right) is > >ghostscript upstream. Take a look at pdf2ps and try to get your program > >next to that. There's no reason to produce packages for a one line

Re: RFS: pdfmerge

Kalle Kivimaa wrote: pdftk - A useful tool for manipulating PDF documents Totally right, but: depends: libgcj4 (>= 1:3.3.2-1) Java runtime library for use with gcj -- When in doubt, use brute force. -- Ken Thompson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED]

Re: RFS: pdfmerge

On Wed, Mar 03, 2004 at 12:33:39AM +0100, Philipp Gortan wrote: > Thomas Viehmann wrote: > >The proper place for the script (after doing things right) is > >ghostscript upstream. Take a look at pdf2ps and try to get your program > >next to that. There's no reason to produce packages for a one line

Re: RFS: pdfmerge

Philipp Gortan <[EMAIL PROTECTED]> writes: > I think the question is: If I am a non-professional user and i wanted > to merge a bunch of pdf files, would I know what to look for in > dselect? killer ~ % apt-cache search merge pdf pdftk - A useful tool for manipulating PDF documents -- * Sufficie

Re: RFS: pdfmerge

--- Philipp Gortan wrote: > Hi mentors, > > thanks for your input, > > Ben Young wrote: > > In a way I agree w/ Jepri. If I want a specific > > script, I would like to be able to install it > right > > away (few Kbs of script in my system is ok!) and > not > > download the whole package of 32mb o

Re: RFS: pdfmerge

Hi mentors, thanks for your input, Ben Young wrote: In a way I agree w/ Jepri. If I want a specific script, I would like to be able to install it right away (few Kbs of script in my system is ok!) and not download the whole package of 32mb of a larger unknown program with another weird name jus

Re: RFS: pdfmerge

On Wed, 2004-03-03 at 09:52, Jepri wrote: > pretty much everything in coreutils could be done with a perl one > liner. Strictly speaking, anything could be done with a perl one-liner, it's just that the line might be rather long depending on what you want to do. :) > Matthew Palmer wrote: > >Eh

Re: RFS: pdfmerge

--- Jepri wrote: [...] > As a sysadmin, > using Solaris is about > as much fun as being beaten, thanks to the lack of > unecessary and > frivolous scripts like this one. I always prefer > working on the Debian > servers. > totally agree. w/o those frivolous scripts, we spend so many hours f

Re: RFS: pdfmerge

Philipp Gortan <[EMAIL PROTECTED]> writes: > I think the question is: If I am a non-professional user and i wanted > to merge a bunch of pdf files, would I know what to look for in > dselect? killer ~ % apt-cache search merge pdf pdftk - A useful tool for manipulating PDF documents -- * Sufficie

Re: RFS: pdfmerge

--- Philipp Gortan wrote: > Hi mentors, > > thanks for your input, > > Ben Young wrote: > > In a way I agree w/ Jepri. If I want a specific > > script, I would like to be able to install it > right > > away (few Kbs of script in my system is ok!) and > not > > download the whole package of 32mb o

Re: RFS: pdfmerge

On Wed, 2004-03-03 at 09:52, Jepri wrote: > pretty much everything in coreutils could be done with a perl one > liner. Strictly speaking, anything could be done with a perl one-liner, it's just that the line might be rather long depending on what you want to do. :) > Matthew Palmer wrote: > >Eh

Re: RFS: pdfmerge

Hi mentors, thanks for your input, Ben Young wrote: In a way I agree w/ Jepri. If I want a specific script, I would like to be able to install it right away (few Kbs of script in my system is ok!) and not download the whole package of 32mb of a larger unknown program with another weird name just

Re: RFS: pdfmerge

Matthew Palmer wrote: On Wed, Mar 03, 2004 at 01:23:39PM +0800, Didier Casse wrote: Well you can possibly argue that it's inefficient. You can list so many packages in Debian that we can find a one-liner turnaround. I believe you can list many, so why don't you start taking them off. Fi

Re: RFS: pdfmerge

--- Jepri wrote: [...] > As a sysadmin, > using Solaris is about > as much fun as being beaten, thanks to the lack of > unecessary and > frivolous scripts like this one. I always prefer > working on the Debian > servers. > totally agree. w/o those frivolous scripts, we spend so many hours f

Re: RFS: pdfmerge

On 03/03/04, Matthew Palmer wrote: > Make that at least two. And I haven't exactly seen a huge clamour of people > rushing to your defence in any coherent fashion. > It's not a bad concept, > > You are free to take your bat and ball wherever it suits you. > [...] Common guys I think you're be

Re: RFS: pdfmerge

On 03/03/04, at 16:09 +1100, Matthew Palmer <[EMAIL PROTECTED]> wrote: > On Wed, Mar 03, 2004 at 12:33:39AM +0100, Philipp Gortan wrote: > > >The proper place for the script (after doing things right) is > > >ghostscript upstream. Take a look at pdf2ps and try to get your program > > >next to that

Re: RFS: pdfmerge

Matthew Palmer wrote: On Wed, Mar 03, 2004 at 01:23:39PM +0800, Didier Casse wrote: Well you can possibly argue that it's inefficient. You can list so many packages in Debian that we can find a one-liner turnaround. I believe you can list many, so why don't you start taking them off. Find 'e

Re: RFS: pdfmerge

On Wed, Mar 03, 2004 at 01:23:39PM +0800, Didier Casse wrote: > On 02/03/04, at 15:31 +0100, Thomas Viehmann <[EMAIL PROTECTED]> wrote: > > There's no reason to produce packages for a one liner. > > As for your "another way of doing things": Just because there's not one > > exclusive right way doe

Re: RFS: pdfmerge

On 03/03/04, Matthew Palmer wrote: > Make that at least two. And I haven't exactly seen a huge clamour of people > rushing to your defence in any coherent fashion. > It's not a bad concept, > > You are free to take your bat and ball wherever it suits you. > [...] Common guys I think you're be

Re: RFS: pdfmerge

On 02/03/04, at 15:31 +0100, Thomas Viehmann <[EMAIL PROTECTED]> wrote: > > OK. Let's assume that I'm convinced that a pdfmerge script was useful. Good start :-) > There's no reason to produce packages for a one liner. > As for your "another way of doing things": Just because there's not one >

Re: RFS: pdfmerge

On Wed, Mar 03, 2004 at 12:33:39AM +0100, Philipp Gortan wrote: > >The proper place for the script (after doing things right) is > >ghostscript upstream. Take a look at pdf2ps and try to get your program > >next to that. There's no reason to produce packages for a one liner. > > ok, so we know the

Re: RFS: pdfmerge

On 03/03/04, at 16:09 +1100, Matthew Palmer <[EMAIL PROTECTED]> wrote: > On Wed, Mar 03, 2004 at 12:33:39AM +0100, Philipp Gortan wrote: > > >The proper place for the script (after doing things right) is > > >ghostscript upstream. Take a look at pdf2ps and try to get your program > > >next to that

Re: RFS: pdfmerge

On Wed, Mar 03, 2004 at 01:23:39PM +0800, Didier Casse wrote: > On 02/03/04, at 15:31 +0100, Thomas Viehmann <[EMAIL PROTECTED]> wrote: > > There's no reason to produce packages for a one liner. > > As for your "another way of doing things": Just because there's not one > > exclusive right way doe

Re: RFS: pdfmerge

On 02/03/04, at 15:31 +0100, Thomas Viehmann <[EMAIL PROTECTED]> wrote: > > OK. Let's assume that I'm convinced that a pdfmerge script was useful. Good start :-) > There's no reason to produce packages for a one liner. > As for your "another way of doing things": Just because there's not one >

Re: RFS: pdfmerge

On Wed, Mar 03, 2004 at 12:33:39AM +0100, Philipp Gortan wrote: > >The proper place for the script (after doing things right) is > >ghostscript upstream. Take a look at pdf2ps and try to get your program > >next to that. There's no reason to produce packages for a one liner. > > ok, so we know the

Re: RFS: pdfmerge

Thomas Viehmann wrote: The proper place for the script (after doing things right) is ghostscript upstream. Take a look at pdf2ps and try to get your program next to that. There's no reason to produce packages for a one liner. Hi mentors, ok, so we know the opinion of Thomas, what does the res

Re: RFS: pdfmerge

Thomas Viehmann wrote: The proper place for the script (after doing things right) is ghostscript upstream. Take a look at pdf2ps and try to get your program next to that. There's no reason to produce packages for a one liner. Hi mentors, ok, so we know the opinion of Thomas, what does the rest of

Re: RFS: pdfmerge

Hi. Didier Casse wrote: >>Which is bad, because I'm sure the package will raise the "why does >>every badly written, trivial script need to be included in Debian?" > Do you know how many people use this "trivial script"? You'll be surprise [...] OK. Let's assume that I'm convinced that a pdfmerge

Re: RFS: pdfmerge

Hi. Didier Casse wrote: >>Which is bad, because I'm sure the package will raise the "why does >>every badly written, trivial script need to be included in Debian?" > Do you know how many people use this "trivial script"? You'll be surprise [...] OK. Let's assume that I'm convinced that a pdfmerge

Re: RFS: pdfmerge

>From tv_AT_beamnet_de, >Which is bad, because I'm sure the package will raise the "why does >every badly written, trivial script need to be included in Debian?" Do you know how many people use this "trivial script"? You'll be surprise to know that at least 10 people are downloading it from a Fed

Re: RFS: pdfmerge

Hi Thomas, hi mentors, Thomas Viehmann wrote: - The script randomly overwrites files in the CWD. issue fixed, pdfmerge now uses File::Temp for secure creation... Version 1.0-5 as usual at Interested, anyone? :-) Regards, Philipp Gortan -- W

Re: RFS: pdfmerge

>From tv_AT_beamnet_de, >Which is bad, because I'm sure the package will raise the "why does >every badly written, trivial script need to be included in Debian?" Do you know how many people use this "trivial script"? You'll be surprise to know that at least 10 people are downloading it from a Fed

Re: RFS: pdfmerge

Hi Thomas, hi mentors, Thomas Viehmann wrote: why does it need autotools for a trivial perl script? I wasn't aware that the autotools are _not_ the tools of choice for platform-independent programs :-) To me, it's the easiest way to help dh_make building the rules... what is the differenc

Re: RFS: pdfmerge

Hi Thomas, hi mentors, Thomas Viehmann wrote: - The script randomly overwrites files in the CWD. issue fixed, pdfmerge now uses File::Temp for secure creation... Version 1.0-5 as usual at Interested, anyone? :-) Regards, Philipp Gortan -- When in

Re: RFS: pdfmerge

Philipp Gortan wrote: > I filed an ITP bug: http://bugs.debian.org/235659 > (didn't cc to debian-devel though, wrong header section) Which is bad, because I'm sure the package will raise the "why does every badly written, trivial script need to be included in Debian?" question. Just two things: - p

Re: RFS: pdfmerge

Hi Thomas, hi mentors, Thomas Viehmann wrote: why does it need autotools for a trivial perl script? I wasn't aware that the autotools are _not_ the tools of choice for platform-independent programs :-) To me, it's the easiest way to help dh_make building the rules... what is the difference? Y

Re: RFS: pdfmerge

Philipp Gortan wrote: > I filed an ITP bug: http://bugs.debian.org/235659 > (didn't cc to debian-devel though, wrong header section) Which is bad, because I'm sure the package will raise the "why does every badly written, trivial script need to be included in Debian?" question. Just two things: - p

Re: RFS: pdfmerge

On Mon, Mar 01, 2004 at 09:39:57PM +0100, Philipp Gortan wrote: > Should the perl script be in the "i386" architecture, or the "any"? Have a quick look at some other perl scripts, and see what they've got. And read the Debian Perl Policy, I would imagine it'd have some words of wisdom. - Matt

Re: RFS: pdfmerge

Hi Frank, hi mentors, thanks for your input! I filed an ITP bug: http://bugs.debian.org/235659 (didn't cc to debian-devel though, wrong header section) The version mismatch is corrected, README and NEWS are deleted, and dh_make is warnings-free and cleaned up. Should the perl script be in the

Re: RFS: pdfmerge

On Mon, Mar 01, 2004 at 09:39:57PM +0100, Philipp Gortan wrote: > Should the perl script be in the "i386" architecture, or the "any"? Have a quick look at some other perl scripts, and see what they've got. And read the Debian Perl Policy, I would imagine it'd have some words of wisdom. - Matt

Re: RFS: pdfmerge

Hi Frank, hi mentors, thanks for your input! I filed an ITP bug: http://bugs.debian.org/235659 (didn't cc to debian-devel though, wrong header section) The version mismatch is corrected, README and NEWS are deleted, and dh_make is warnings-free and cleaned up. Should the perl script be in the "i3

Re: RFS: pdfmerge

Philipp Gortan <[EMAIL PROTECTED]> schrieb: > Hi mentors, > > I packaged pdfmerge and would be happy to get it included into the > Debian distribution. > pdfmerge is a simple perl script used to merge multiple PDF files into a > single output file, using ghostscript. > > program: pdfmerge > versi

Re: RFS: pdfmerge

Philipp Gortan <[EMAIL PROTECTED]> schrieb: > Hi mentors, > > I packaged pdfmerge and would be happy to get it included into the > Debian distribution. > pdfmerge is a simple perl script used to merge multiple PDF files into a > single output file, using ghostscript. > > program: pdfmerge > versi

RFS: pdfmerge

Hi mentors, I packaged pdfmerge and would be happy to get it included into the Debian distribution. pdfmerge is a simple perl script used to merge multiple PDF files into a single output file, using ghostscript. program: pdfmerge version: 1.0 homepage: http://pdfmerge4unix.sf.net/ Author:

RFS: pdfmerge

Hi mentors, I packaged pdfmerge and would be happy to get it included into the Debian distribution. pdfmerge is a simple perl script used to merge multiple PDF files into a single output file, using ghostscript. program: pdfmerge version: 1.0 homepage: http://pdfmerge4unix.sf.net/ Author: Di