Re: Please upload: netpbm-10.30
On Tue, Jan 03, 2006 at 04:40:28PM -0600, Yaakov S (Cygwin Ports) wrote: >ftp://sunsite.dk/projects/cygwinports/release/netpbm/libnetpbm-devel/libnetpbm-devel-10.30-1.tar.bz2 >ftp://sunsite.dk/projects/cygwinports/release/netpbm/libnetpbm-devel/setup.hint >ftp://sunsite.dk/projects/cygwinports/release/netpbm/libnetpbm10/libnetpbm10-10.30-1.tar.bz2 >ftp://sunsite.dk/projects/cygwinports/release/netpbm/libnetpbm10/setup.hint >ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-10.30-1-src.tar.bz2 >ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-10.30-1.tar.bz2 >ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-doc/netpbm-doc-10.30-1.tar.bz2 >ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-doc/setup.hint >ftp://sunsite.dk/projects/cygwinports/release/netpbm/setup.hint > >Please keep 10.29-1 as prev, anything older (if present) can be removed. Uploaded. cgf
Please upload: netpbm-10.30
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please upload: ftp://sunsite.dk/projects/cygwinports/release/netpbm/libnetpbm-devel/libnetpbm-devel-10.30-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/netpbm/libnetpbm-devel/setup.hint ftp://sunsite.dk/projects/cygwinports/release/netpbm/libnetpbm10/libnetpbm10-10.30-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/netpbm/libnetpbm10/setup.hint ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-10.30-1-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-10.30-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-doc/netpbm-doc-10.30-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-doc/setup.hint ftp://sunsite.dk/projects/cygwinports/release/netpbm/setup.hint Please keep 10.29-1 as prev, anything older (if present) can be removed. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDuv1bpiWmPGlmQSMRAmDNAJ9+ClyM9pFpQ13N1cbQKBzEAX06wwCg3ZuE 1aX1XlHuV+Y7dEack4N2WHc= =Rp7e -END PGP SIGNATURE-
Re: Please upload (SECURITY): netpbm-10.29-1
On Fri, Nov 04, 2005 at 09:33:46AM -0600, Yaakov S (Cygwin Ports) wrote: >Christopher Faylor wrote: >>Uploaded. > >Thanks. Could you please remove all previous versions now? I just did a rm **/*28* in the netpbm directory. cgf (zsh is great)
Re: Please upload (SECURITY): netpbm-10.29-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Faylor wrote: > Uploaded. Thanks. Could you please remove all previous versions now? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDa39apiWmPGlmQSMRAgYTAKCWloz1n7L7e8h5SfKeBA3WKV02xQCg+0Jj Okk16IyCLscv6kwNaKsZ5o4= =d/97 -END PGP SIGNATURE-
Re: Please upload (SECURITY): netpbm-10.29-1
On Thu, Oct 20, 2005 at 05:59:09PM -0500, Yaakov S (Cygwin Ports) wrote: >The pnmtopng utility, part of the Netpbm tools (< 10.29), contains a >vulnerability which can potentially result in the execution of >arbitrary code. > >Please upload ASAP: > >ftp://sunsite.dk/projects/cygwinports/release/netpbm/libnetpbm-devel/libnetpbm-devel-10.29-1.tar.bz2 >ftp://sunsite.dk/projects/cygwinports/release/netpbm/libnetpbm10/libnetpbm10-10.29-1.tar.bz2 >ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-10.29-1-src.tar.bz2 >ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-10.29-1.tar.bz2 >ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-doc/netpbm-doc-10.29-1.tar.bz2 >ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-doc/setup.hint Uploaded. cgf
Please upload (SECURITY): netpbm-10.29-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The pnmtopng utility, part of the Netpbm tools (< 10.29), contains a vulnerability which can potentially result in the execution of arbitrary code. Please upload ASAP: ftp://sunsite.dk/projects/cygwinports/release/netpbm/libnetpbm-devel/libnetpbm-devel-10.29-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/netpbm/libnetpbm10/libnetpbm10-10.29-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-10.29-1-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-10.29-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-doc/netpbm-doc-10.29-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/netpbm/netpbm-doc/setup.hint Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDWCE9piWmPGlmQSMRAqgjAJ9nAaNVj+9ruphLnHGDaZ6ZBiOscQCgteKR DQu6Sejnf58cgCTigw1lXFw= =jzHh -END PGP SIGNATURE-
Re: [ITP] netpbm-10.28
Yaakov S wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: Charles (and me) used to use a separate directory for the headers which I still would prefer: But there's no netpbm-config script or the like, so how would a dependant package know to look for the headers there? FWIW, debian[1] and gentoo[2] also package netpbm like I did. [1] http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=libnetpbm10-dev&version=unstable&arch=i386 [2] http://www.gentoo.org/cgi-bin/viewcvs.cgi/media-libs/netpbm/netpbm-10.28.ebuild?view=markup Besides the headers listed here for debian[1] there are (with more or less useful names)[2] and these[3] in the Cygwin package: [2] usr/include/pam.h usr/include/pammap.h usr/include/pbm.h usr/include/pbmfont.h usr/include/pgm.h usr/include/pm.h usr/include/pm_config.h usr/include/pm_gamma.h usr/include/pm_system.h usr/include/pnm.h usr/include/ppm.h usr/include/ppmcmap.h usr/include/ppmfloyd.h [3] usr/include/bitio.h usr/include/colorname.h usr/include/mallocvar.h usr/include/nstring.h usr/include/shhopt.h E.g. debian seems to have renamed shhopt.h to netpbm-shhopt.h instead of using a separate directory while the others are not present at all. Gerrit -- =^..^=
Re: [ITP] netpbm-10.28
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: > Charles (and me) used to use a separate directory for the headers > which I still would prefer: But there's no netpbm-config script or the like, so how would a dependant package know to look for the headers there? FWIW, debian[1] and gentoo[2] also package netpbm like I did. [1] http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=libnetpbm10-dev&version=unstable&arch=i386 [2] http://www.gentoo.org/cgi-bin/viewcvs.cgi/media-libs/netpbm/netpbm-10.28.ebuild?view=markup > Makefile.config: > CFLAGS_SHLIB = -DPIC > is a noop. Well, -fPIC is the real no-op, -DPIC is just a define and is at the worst only extraneous; I believe there was some discussion about this a while ago on [EMAIL PROTECTED] Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDARs9piWmPGlmQSMRArbvAKCqxP0HisuKLTY0LvecppRyQr+WRgCgr73T psAUVNrU2rpkOngSLZpLUis= =YUtv -END PGP SIGNATURE-
Re: [ITP] netpbm-10.28
Yaakov S wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Due to popular request: http://cygwin-ports.sourceforge.net/install/temp/netpbm/netpbm-10.28-1-src.tar.bz2 http://cygwin-ports.sourceforge.net/install/temp/netpbm/netpbm-10.28-1.tar.bz2 http://cygwin-ports.sourceforge.net/install/temp/netpbm/setup.hint http://cygwin-ports.sourceforge.net/install/temp/netpbm/libnetpbm10/libnetpbm10-10.28-1.tar.bz2 http://cygwin-ports.sourceforge.net/install/temp/netpbm/libnetpbm10/setup.hint http://cygwin-ports.sourceforge.net/install/temp/netpbm/libnetpbm-devel/libnetpbm-devel-10.28-1.tar.bz2 http://cygwin-ports.sourceforge.net/install/temp/netpbm/libnetpbm-devel/setup.hint Charles (and me) used to use a separate directory for the headers which I still would prefer: usr/include/ usr/include/bitio.h usr/include/colorname.h usr/include/mallocvar.h ... usr/include/netpbm/... Other than this binary package looks ok. After extracting the source package I see this (I am in the root): $ ./netpbm-10.28-1.sh prep tar (child): //netpbm-10.28.tgz: Cannot open: No such host or network path tar (child): Error is not recoverable: exiting now [...more...] Moving in a subdirectory is ok. Makefile.config: CFLAGS_SHLIB = -DPIC is a noop. Anyway, the build works ok. GTG and uploaded, Gerrit -- =^..^=
[ITP] netpbm-10.28
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Due to popular request: http://cygwin-ports.sourceforge.net/install/temp/netpbm/netpbm-10.28-1-src.tar.bz2 http://cygwin-ports.sourceforge.net/install/temp/netpbm/netpbm-10.28-1.tar.bz2 http://cygwin-ports.sourceforge.net/install/temp/netpbm/setup.hint http://cygwin-ports.sourceforge.net/install/temp/netpbm/libnetpbm10/libnetpbm10-10.28-1.tar.bz2 http://cygwin-ports.sourceforge.net/install/temp/netpbm/libnetpbm10/setup.hint http://cygwin-ports.sourceforge.net/install/temp/netpbm/libnetpbm-devel/libnetpbm-devel-10.28-1.tar.bz2 http://cygwin-ports.sourceforge.net/install/temp/netpbm/libnetpbm-devel/setup.hint Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC/PZepiWmPGlmQSMRAnT9AKC+U22uimqV2gIiv2iuVwSTEdHG/ACg1Ams tOomzzvp+u5Keak62uJhKpc= =NiOJ -END PGP SIGNATURE-
Re: [SM] netpbm
Yaakov S wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: Is it really not possible to find a maintainer who is willing to adopt Ch. Wilsons netpbm package? Hmmm, I've built it once; looks like there's an update upstream (including a security fix). If there's really interest, then I'll consider it. FWIW, see http://cygutils.fruitbat.org/testing/ADOPT-ME/netpbm/ Already method-2 packaged; only needs updating to current release. Feel free to adopt it. -- Chuck
Re: [SM] netpbm
> want to say: Search Maintainer for netpbm > > Is it really not possible to find a maintainer who is willing > to adopt Ch. Wilsons netpbm package? http://netpbm.alioth.debian.org/ claims there are some licensing problems. But the project is hosted at Sourceforge, and http://sourceforge.net/projects/netpbm/ lists a variety of free licenses for it. http://netpbm.sourceforge.net/ links to some Cygwin builds, supposedly maintined by Pierre Humblet. But they're dated, and aren't proper Cygwin packages.
Re: [SM] netpbm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerrit P. Haase wrote: > Is it really not possible to find a maintainer who is willing > to adopt Ch. Wilsons netpbm package? Hmmm, I've built it once; looks like there's an update upstream (including a security fix). If there's really interest, then I'll consider it. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+QPspiWmPGlmQSMRAgD9AJ95goPxDPg3FzMcsNU8/Ijo5OfDYwCgllBb vnqQaXeYkcFchbcdK7XTYgM= =B32V -END PGP SIGNATURE-
[SM] netpbm
Hello, want to say: Search Maintainer for netpbm Is it really not possible to find a maintainer who is willing to adopt Ch. Wilsons netpbm package? Regards, Gerrit -- =^..^=
Re: netpbm?
On Fri, 1 Oct 2004, Charles Wilson wrote: > Igor Pechtchanski wrote: > > > Chuck, if you could dig it up, that'd be great. Did you adapt it to use > > the generic-build-script? If so, how did you deal with the weird > > configure? > > It uses a variant of the gbs, IIRC. I'm on dailup right now, so I'll let you > download it... > > http://users.ece.gatech.edu/~cwilson/cygutils/testing/index.php?dir=release%2Fnetpbm/ Thanks. I was hoping for a less invasive set of changes to the GBS, but most of them seem unavoidable. I'll see what I can do, though. The division into libnetpbm* and netpbm is good -- I hadn't thought of that. I'll get it working for myself first, and then see if I can find the time to ITP it properly. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing." -- Dr. Jubal Harshaw
Re: netpbm?
Igor Pechtchanski wrote: Chuck, if you could dig it up, that'd be great. Did you adapt it to use the generic-build-script? If so, how did you deal with the weird configure? It uses a variant of the gbs, IIRC. I'm on dailup right now, so I'll let you download it... http://users.ece.gatech.edu/~cwilson/cygutils/testing/index.php?dir=release%2Fnetpbm/ -- Chuck
Re: netpbm?
On Thu, 30 Sep 2004, Charles Wilson wrote: > Igor Pechtchanski wrote: > > > There is a netpbm binary distributed on Pierre Humblet's ftp area at > > <ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/porters/Humblet_Pierre_A/V1.1/>. > > Any particular reason why it's not part of the Cygwin distribution (other > > than "nobody bothered to make it into a package")? > > Yep. I even made an "ADOPT-ME" package of it, because I didn't want to be > responsible for maintaining it. But nobody adopted it. I still have it > around, somewhere... > Chuck On Thu, 30 Sep 2004, Pierre A. Humblet wrote: > At 04:58 PM 9/30/2004 -0400, you wrote: > >There is a netpbm binary distributed on Pierre Humblet's ftp area at > ><ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/porters/Humblet_Pierre_A/V1.1/>. > >Any particular reason why it's not part of the Cygwin distribution (other > >than "nobody bothered to make it into a package")? > > Although I helped port it to Cygwin, I have not used netpbm in years > and I am not interested in maintaining it. It now compiles OOTB but be > forewarned that there is a new version almost every month (at least, > it used to). I recompile it on demand, when people ask me to. > > Pierre Well, as far as I understand, there's the "latest" release, which has a change rate of about once in two months (on average), and is now up to 10.24, and the "stable" release, which is based on 10.15 and has minor changes every month or so. Based on the history of Cygwin packages (where everyone is "used" to living on the bleeding edge, so to speak), I'd say the "latest" branch is more appropriate. Opinions? Turns out I'll need latex2html on Cygwin, and that requires netpbm, so I guess I'll end up maintaining both... :-) Chuck, if you could dig it up, that'd be great. Did you adapt it to use the generic-build-script? If so, how did you deal with the weird configure? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing." -- Dr. Jubal Harshaw
Re: netpbm?
At 04:58 PM 9/30/2004 -0400, you wrote: >Hi, > >There is a netpbm binary distributed on Pierre Humblet's ftp area at ><ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/porters/Humblet_Pierre_A/ V1.1/>. >Any particular reason why it's not part of the Cygwin distribution (other >than "nobody bothered to make it into a package")? Although I helped port it to Cygwin, I have not used netpbm in years and I am not interested in maintaining it. It now compiles OOTB but be forewarned that there is a new version almost every month (at least, it used to). I recompile it on demand, when people ask me to. Pierre
Re: netpbm?
Igor Pechtchanski wrote: There is a netpbm binary distributed on Pierre Humblet's ftp area at <ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/porters/Humblet_Pierre_A/V1.1/>. Any particular reason why it's not part of the Cygwin distribution (other than "nobody bothered to make it into a package")? Yep. I even made an "ADOPT-ME" package of it, because I didn't want to be responsible for maintaining it. But nobody adopted it. I still have it around, somewhere... -- Chuck
netpbm?
Hi, There is a netpbm binary distributed on Pierre Humblet's ftp area at <ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/porters/Humblet_Pierre_A/V1.1/>. Any particular reason why it's not part of the Cygwin distribution (other than "nobody bothered to make it into a package")? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing." -- Dr. Jubal Harshaw
Re: ITP: netpbm
At 11:51 AM 4/29/2002, Earnie Boyd wrote: >"Larry Hall (RFK Partners, Inc)" wrote: > > > > At 07:44 AM 4/29/2002, Earnie Boyd wrote: >-8<- > > The point is, the extra path walks are > > >expensive. > > > > Quite true. But I would say that Corinna's suggestion, from a strict > > technical perspective, makes netpbm in a different bin directory usable > > 'out-of-the-box' under Cygwin. If netpbm were going to be put in it's > > own bin directory, I would say that adding files like the ones Corinna > > suggests is an absolute requirement. > > > >Yes, but you missed the point. > >Go ahead, add something to the end of your PATH and execute it with >strace. Then see how many times the pathing routines are called to >search for a symlink. It's once for each directory listed in PATH and I >mean each directory listed in the path name of the path list (E.G.: a >PATH of /usr/local/bin:/bin:/usr/bin has six directories in it). And if >someone has a symlink in PATH, it's called again to see if the file >pointed to by the symlink is a symlink. Note, the coding is necessary >for symlink simulation, but it's slows down time it takes to find the >binary file to exec. Keep the binaries to the front of the PATH and put >them in /bin. Thanks for this explanation. It's good to have this information for the email archives. Also, I wasn't disagreeing with the point you were making. Personally, I think it is yet another reason not to split binaries out into separate directories without good reason. But this is a technical issue. My point was that *if* someone were planning to put binaries of netpbm or any other package in it's own bin directory, something like Corinna's suggestion is needed to make it usable in Cygwin by anyone right after installation. Without something like that, the installation is broken and this list gets flooded with questions about why the package doesn't work. So Corinna's suggestion addresses this issue but not yours. They are two separate issues, both of which have been discussed in this thread. From a sanity perspective, I'm more concerned about making sure any new approach to packaging doesn't confuse users and overwhelm the Cygwin list. Performance only falls into that category for me if the affect is so drastic that a good subset of users complain. Since it wasn't obvious to me that Corinna's suggestion automatically creates that situation, I'm not as concerned about it, though I do acknowledge it. But I think there's some consensus that extra bin directories is "bad" for any of a number of reasons, including the issue of performance, so I don't think anyone will be pushing the idea at this point. Though maybe I'm wrong... ;-) Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX
Re: ITP: netpbm
Corinna Vinschen wrote: > On Sat, Apr 27, 2002 at 06:04:55PM -0400, Larry Hall (RFK Partners, Inc) wrote: > >>But everyone will complain if they can't run the package after they install >>it. I think we should absolutely avoid the latter case. The former >>we can deal with as required. >> > > What's the problem in adding two files to the package: > > /etc/profile.d/netpbm.sh: > > PATH=$PATH:/usr/netpbm/bin export $PATH > > /etc/profile.d/netpbm.csh: > > set path = ( $path /usr/netpbm/bin ) Great idea -- but I believe a consenses has already been reached: put the binaries in /usr/bin. I don't really care; I'll fix things up the way I like 'em on my system... Also, Jan and I have been talking with Bryan Henderson(?) who maintains netpbm. He has said that version 10 will be coming out in about a month with some big changes, and Jan is inclined to wait until then to create the cygwin package...just so you know. --Chuck
Re: ITP: netpbm
"Larry Hall (RFK Partners, Inc)" wrote: > > At 07:44 AM 4/29/2002, Earnie Boyd wrote: -8<- > The point is, the extra path walks are > >expensive. > > Quite true. But I would say that Corinna's suggestion, from a strict > technical perspective, makes netpbm in a different bin directory usable > 'out-of-the-box' under Cygwin. If netpbm were going to be put in it's > own bin directory, I would say that adding files like the ones Corinna > suggests is an absolute requirement. > Yes, but you missed the point. Go ahead, add something to the end of your PATH and execute it with strace. Then see how many times the pathing routines are called to search for a symlink. It's once for each directory listed in PATH and I mean each directory listed in the path name of the path list (E.G.: a PATH of /usr/local/bin:/bin:/usr/bin has six directories in it). And if someone has a symlink in PATH, it's called again to see if the file pointed to by the symlink is a symlink. Note, the coding is necessary for symlink simulation, but it's slows down time it takes to find the binary file to exec. Keep the binaries to the front of the PATH and put them in /bin. Earnie.
Re: ITP: netpbm
At 07:44 AM 4/29/2002, Earnie Boyd wrote: >Corinna Vinschen wrote: > > > > On Sat, Apr 27, 2002 at 06:04:55PM -0400, Larry Hall (RFK Partners, Inc) wrote: > > > But everyone will complain if they can't run the package after they install > > > it. I think we should absolutely avoid the latter case. The former > > > we can deal with as required. > > > > What's the problem in adding two files to the package: > > > > /etc/profile.d/netpbm.sh: > > > > PATH=$PATH:/usr/netpbm/bin export $PATH > > > > /etc/profile.d/netpbm.csh: > > > > set path = ( $path /usr/netpbm/bin ) > > > >Because I would `mv /usr/netpbm/bin/* /usr/bin/ && rm -rf /usr/netpbm && >rm -f /etc/profile.d/netpbm*'. The point is, the extra path walks are >expensive. Quite true. But I would say that Corinna's suggestion, from a strict technical perspective, makes netpbm in a different bin directory usable 'out-of-the-box' under Cygwin. If netpbm were going to be put in it's own bin directory, I would say that adding files like the ones Corinna suggests is an absolute requirement. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX
Re: ITP: netpbm
Corinna Vinschen wrote: > > On Sat, Apr 27, 2002 at 06:04:55PM -0400, Larry Hall (RFK Partners, Inc) wrote: > > But everyone will complain if they can't run the package after they install > > it. I think we should absolutely avoid the latter case. The former > > we can deal with as required. > > What's the problem in adding two files to the package: > > /etc/profile.d/netpbm.sh: > > PATH=$PATH:/usr/netpbm/bin export $PATH > > /etc/profile.d/netpbm.csh: > > set path = ( $path /usr/netpbm/bin ) > Because I would `mv /usr/netpbm/bin/* /usr/bin/ && rm -rf /usr/netpbm && rm -f /etc/profile.d/netpbm*'. The point is, the extra path walks are expensive. Earnie.
Re: ITP: netpbm
On Sat, Apr 27, 2002 at 06:04:55PM -0400, Larry Hall (RFK Partners, Inc) wrote: > But everyone will complain if they can't run the package after they install > it. I think we should absolutely avoid the latter case. The former > we can deal with as required. What's the problem in adding two files to the package: /etc/profile.d/netpbm.sh: PATH=$PATH:/usr/netpbm/bin export $PATH /etc/profile.d/netpbm.csh: set path = ( $path /usr/netpbm/bin ) ? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: ITP: netpbm
Charles Wilson <[EMAIL PROTECTED]> writes: > Well, as I described in the other message, there are only three > patches. Ok, I must have looked over it. > One, which creates a Makefile.config, > Two, a cygwin-specific README file. > Three, GNU shtool, to create a shadow tree in which to build. Indeed, I've done something quite similar, of course, but it seems that you've put more work in it than I, already. > What *would* be appropriate is if someone totally autoconfiscated the > whole mess, Yes, but I guess we'll leave that up to the authors, or, at least, ask them first. It shouldn't be much work, there seem to be a few system profiles, and then some questions. > Big directories == slow. Much worse on FAT than on NTFS. There's no > hard limit on non-partition-root directories, however (unless somebody > does something REALLY silly, like 'mount C:\ /bin'. > > Putting all the netpbm binaries in /usr/bin(==/bin) won't cause any > problems, except for the standard PATH ordering issues(*), but those > will only affect a few people (like me, and I can deal). Ok. I think plainly in usr/bin would be best, because it's standard, but things can be changed/ moved around whenever this list decides something else. Also, I think that this > (*) there are widely used windows ports of netpbm tools. [..] So, > in normal windows, and cmd prompt, I use the native port of netpbm > [..] When in bash, I use the cygwin port of netpbm (this makes me > happy). while, a valid argument, can probably be said for tex itself (tex,latex etc), for gs (ghostscript), probably even the 'find' command. I think that if 'you' want some subset of bin in certain situations, you should probably arrange that yourself. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
RE: ITP: netpbm
At 01:40 PM 4/27/2002, Robert Collins wrote: > > -Original Message- > > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, April 28, 2002 2:46 AM > >... > > But cygwin is used on > > both NTFS and > > FAT... > >Which is the killer question: is adding a directory to the search path >more or less of a performance hog than adding x-100 .exes and/or .dll's >to the /usr/bin directory. And will the inevitable 'my dos script can't >find netpbm foobar tool' questions be worth it? No, not in my book. >Well my system32 directory here has 1971 files. Adding a coupla hundred >optional files doesn't seem all that bad to me. > >And hey, if FAT is too slow, folk can always install the windows ext2 >driver. Right, there are alternatives to this issue. I believe performance is an important concern but not to the exclusion of simple usability. Some people will complain if this package causes things to slow down for them. But everyone will complain if they can't run the package after they install it. I think we should absolutely avoid the latter case. The former we can deal with as required. Just my $.02. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX
Re: ITP: netpbm
Oh yeah -- one last thing: netpbm provides jbigtopnm and pnmtojbig. These duplicate the functionality of similar programs in cygwin's jbigkit package -- but fortunately they do not conflict: netpbm: jbigtopnm pnmtojbig jbigkit: jbgtopbm pbmtojbg So in case anyone was worried... :-) --Chuck
Re: ITP: netpbm
Charles Wilson wrote: > As promised, take a look: > http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ > The -src package contains --- a patch, which does the following three > things: If you go back to http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ you'll see I've updated "my" version to netpbm-9.25, and split the binary package into two different packages: netpbm-9.25-1 libnetpbm9-9.25-1 (contains the DLLs alone). There is no separate -devel package, because without further work, you can't have two versions coexist side-by-side: the static libs, import libs, and header files are not themselves versioned, and they live right in /lib & /include, and not in subdirectories. I also significantly enlarged patch so that on windows/cygwin, the DLLs are created with the major version number -- at least that way, later we CAN have multiple version of the DLLs coexist, if there is a major interface change. (This is more important than the implib/statlib/header issue mentioned above). /usr/local/bin/cygpbm-9.dll /usr/local/bin/cygpgm-9.dll /usr/local/bin/cygppm-9.dll /usr/local/bin/cygpnm-9.dll I've split that patch into two separate patches: netpbm-submit.patch (the versioning changes, which should have no effect on non-windows platforms. Also, takes into account the recent official libpng policy change for versions -- see png-implement mailing list) netpbm-9.25-1-cygwin.patch (the updated version of my 9.24 patch; contains shtool, the cygwin-specific readme, and the ready-made Makefile.config file) Both are available at the /testing/ location above. I'll be submitting the netpbm-submit patch upstream. --Chuck P.S. Jan, to use "my" stuff, you'll probably want to change the following things: Makefile.config : INSTALL_PREFIX = /usr (line 518) INSTALLBINARIES = $(INSTALL_PREFIX)/bin (line 523) /CYGWIN-PATCHES/netpbm.README you'll need to fixup the pathnames I specified in the "This package contains..." section. netpbm-9.25-1.sh: remove line 120 -- I explicitly move the dlls from /bin/netpbm into /bin. You won't need that. > 1) creates a ready-made Makefile.config to implement the "policy" I > described: > INSTALL_PREFIX = /usr/local (line 469) > - you'll want to change that to /usr > PNGHDR_DIR = /usr/include (line 466) > - you'll want to make that /usr/include/libpngXX if > you use libpng-1.0.13 or libpng-1.2.2 > LDSHLIB = -shared -Wl,--enable-auto-image-base (line 460) > - you'll wnat to change that to -shared -Wl,--export-all > since (1) auto-image-base is no longer recommended, and > (2) export-all so you can take advantage of binutils' auto-export > fucntionality > INSTALLBINARIES = $(INSTALL_PREFIX)/bin/netpbm (line 474) > - this is the big controversy > > 2) creates a CYGWIN-PATCHES/netpbm.README files which describes how to > build [merged|normal][shared|static], and some analysis I did about > which version is the most space efficient. > > 3) creates CYGWIN-PATCHES/shtool : netpbm is one of those packages that > won't build outside of its own source tree, which complicates the > script-driven build procedure. As mentioned here: > http://www.cygwin.com/setup.html, I used GNU shtool's 'mkshadow' > function to replicate the whole source tree inside the .build directory > via symlinks. > > -src also contains: the build script, and the "pristine" tarball. But, > this is all based on 9.24, not 9.25, so it would take some adaptation to > use it, and merge my stuff with yours -- if you want it. > > Hope it's helpful. > > --Chuck > > > Charles Wilson wrote: > >> Wonderful, please do. >> >> BTW, I have had a private version of netpbm, packaged in a >> 'setup-compatible' way, for some time now. When I get home, I'll put >> my version somewhere that you can access; you may want to expropriate >> some of my patches... >> >> Also, which png have you linked against? 1.0.12, or 1.0.13? (Also, I >> have libpng-1.2.2 ready for upload to sourceware, but I'm waiting for >> the ripples from the massive 1.0.13 packaging changes to settle out...) >> >> --Chuck >> > >
Re: ITP: netpbm
Robert Collins wrote: > > > -Original Message- > > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, April 28, 2002 2:46 AM > > ... > > But cygwin is used on > > both NTFS and > > FAT... > > Which is the killer question: is adding a directory to the search path > more or less of a performance hog than adding x-100 .exes and/or .dll's > to the /usr/bin directory. And will the inevitable 'my dos script can't > find netpbm foobar tool' questions be worth it? > It be the reason I would want the binaries in /bin. I even remove the /usr/bin from the PATH. Watch how many extra calls to the path methods are generated via an strace output. You really want to avoid extra path walks based on PATH. > Well my system32 directory here has 1971 files. Adding a coupla hundred > optional files doesn't seem all that bad to me. > Not in light of the path walk and path methods. > And hey, if FAT is too slow, folk can always install the windows ext2 > driver. > Or upgrade to XP4HOME, NTFS is the file system. Earnie.
Re: ITP: netpbm
Charles Wilson wrote: > LDSHLIB = -shared -Wl,--enable-auto-image-base (line 460) > - you'll wnat to change that to -shared -Wl,--export-all > since (1) auto-image-base is no longer recommended, and > (2) export-all so you can take advantage of binutils' auto-export > fucntionality Actually, you'll just want to change it to '-dhared'. We don't wan't --export-all, because then cygpbm.dll would export stuff from cygpbm.dll. The netpbm build scripts already work around this by using dlltool to autogenerate a .def file for JUST the stuff that cygpXm should export... -Chuck
RE: ITP: netpbm
> -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Sunday, April 28, 2002 2:46 AM ... > But cygwin is used on > both NTFS and > FAT... Which is the killer question: is adding a directory to the search path more or less of a performance hog than adding x-100 .exes and/or .dll's to the /usr/bin directory. And will the inevitable 'my dos script can't find netpbm foobar tool' questions be worth it? Well my system32 directory here has 1971 files. Adding a coupla hundred optional files doesn't seem all that bad to me. And hey, if FAT is too slow, folk can always install the windows ext2 driver. Rob
Re: ITP: netpbm
Jan Nieuwenhuizen wrote: >>BTW, I have had a private version of netpbm, packaged in a >>'setup-compatible' way, for some time now. When I get home, I'll put >>my version somewhere that you can access; you may want to expropriate >>some of my patches... >> > > Ok, I'd like to have a look. What do these patches do, ie, (why) > can't they flow upstream? Well, as I described in the other message, there are only three patches. One, which creates a Makefile.config, so you don't have to run netpbm's configure (which is NOT autoconf-generated, and requires manual intervention when you run it). That is, netpbm WITHOUT a prebuilt Makefile.config can't be built via an unattended script. Two, a cygwin-specific README file. Three, GNU shtool, to create a shadow tree in which to build. Without this, it's hard to automatically generate a patchset using an unattended build script. These changes are all specific to the script-based unattended build setup used by cygwin packages (method 2: http://www.cygwin.com/setup.html). They aren't appropriate for submission upstream. What *would* be appropriate is if someone totally autoconfiscated the whole mess, so that you could do a GNU-standard, unattended ./configure --my-favorite-options. Then you wouldn't need GNU shtool, or the prebuild Makefile.config. >>Also, which png have you linked against? 1.0.12, or 1.0.13? >> > > 1.0.13. > > I'll change dependencies to libpng10, and will split the package into > netpbm, libnetpbm9, libnetpbm9-dev[el], simply mimicking what Debian > is doing; that should be enough? Probably...now that I've looked closer, it seems that all four p*m libraries use "9" as their MAJor version and so-number, but they have different MINor revision numbers. Assuming that the so-number will change only when backwards incompatible changes are made, then we could probably assume that the putting all of the shared libs into "libnetpbm9" would be okay. However, currently the DLLs are named "cygp?m.dll" without a distinguising DLL/so number. I'll look into fixing that -- which IS an upstream-submittable patch... > I'll have to read up to the # binaries thing, the only thing I would > like to consider* is moving /usr/bin to /usr/bin/netpbm, but I'd > rather not. > * but only if there's a good reason because of broken filesystem and > lookup support, and some sort of consensus (summary, anyone? :-) Big directories == slow. Much worse on FAT than on NTFS. There's no hard limit on non-partition-root directories, however (unless somebody does something REALLY silly, like 'mount C:\ /bin'. Putting all the netpbm binaries in /usr/bin(==/bin) won't cause any problems, except for the standard PATH ordering issues(*), but those will only affect a few people (like me, and I can deal). --Chuck (*) there are widely used windows ports of netpbm tools. MikTeX even distributes one. I like to put cygwin's bin/ at the front of my PATH, but bin/netpbm is NOT in my windows path. When I start a bash shell, my .profile moves bin/netpbm toware the front of my PATH. So, in normal windows, and cmd prompt, I use the native port of netpbm (this makes miktex and friends happy; also I have direct access to the OTHER cygwin tools since cygwin/bin is at the front (and the cygwin-netpbm tools aren't in there). When in bash, I use the cygwin port of netpbm (this makes me happy). But it's tricky, and not possible unless the cygwin netpbm tools are segregated from the other cygwin binaries. However, this is a rare situation, and anybody who knows enough to want to do it, knows enough to implement it regardless of how you package cygwin-netpbm.
Re: ITP: netpbm
Gareth Pearce wrote: >> > As for the # of executables in the /bin directory, isn't >> > there a limit to the number of files and/or directory entries >> > in any one directory on win32? >> >> As has already been said, not past the root. However directory search >> time is O(N) on FAT, vs (IIRC) O(logN) on NTFS. So directories with many >> files leads to signficcantly longer lookup times - and thas when the >> filename is known!. > > > My experience - on ntfs ... [snip] > Except in one area. > cd'ing to the directory in the first place - can take a minute or more, NTFS uses a btree to store directory and file information, leading to O(logN) lookup times. If you were doing that on FAT, it would require FAR more time. That's what I meant by saying "directory size is limited by your patience" -- lots of files in a directory == long waits for ls, find, etc. It's not as bad on NTFS, but cygwin is used on both NTFS and FAT... --Chuck
Re: ITP: netpbm
Charles Wilson <[EMAIL PROTECTED]> writes: > Wonderful, please do. Ok. I've been away from email, as you noticed, and will be back tonight (CET). I'll have to consider if any big problems arise, because this mustn't turn into a time sink. > BTW, I have had a private version of netpbm, packaged in a > 'setup-compatible' way, for some time now. When I get home, I'll put > my version somewhere that you can access; you may want to expropriate > some of my patches... Ok, I'd like to have a look. What do these patches do, ie, (why) can't they flow upstream? > Also, which png have you linked against? 1.0.12, or 1.0.13? 1.0.13. I'll change dependencies to libpng10, and will split the package into netpbm, libnetpbm9, libnetpbm9-dev[el], simply mimicking what Debian is doing; that should be enough? I'll have to read up to the # binaries thing, the only thing I would like to consider* is moving /usr/bin to /usr/bin/netpbm, but I'd rather not. Greetings, Jan. * but only if there's a good reason because of broken filesystem and lookup support, and some sort of consensus (summary, anyone? :-) -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
RE: ITP: netpbm
> > > > > -Original Message- > > From: Earnie Boyd [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, April 27, 2002 6:03 AM > > > As for the # of executables in the /bin directory, isn't > > there a limit to the number of files and/or directory entries > > in any one directory on win32? > >As has already been said, not past the root. However directory search >time is O(N) on FAT, vs (IIRC) O(logN) on NTFS. So directories with many >files leads to signficcantly longer lookup times - and thas when the >filename is known!. My experience - on ntfs ... i have a directory of approx 10thousand 5 minute log files of me playing telnet based muds ... *snicker* i can grep them all (each about 10-20k) in a few minutes ... (9 grep commands because command line expansion limitations :P) - really preformance drop is not that noticible. Except in one area. cd'ing to the directory in the first place - can take a minute or more, subsequent cd's are fast, but it seems like its caching all the filenames in the directory for faster access. Anyway ... theres a 'pseudo-data-point' Regards, Gareth _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
Re: ITP: netpbm
As promised, take a look: http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ The -src package contains --- a patch, which does the following three things: 1) creates a ready-made Makefile.config to implement the "policy" I described: INSTALL_PREFIX = /usr/local (line 469) - you'll want to change that to /usr PNGHDR_DIR = /usr/include (line 466) - you'll want to make that /usr/include/libpngXX if you use libpng-1.0.13 or libpng-1.2.2 LDSHLIB = -shared -Wl,--enable-auto-image-base (line 460) - you'll wnat to change that to -shared -Wl,--export-all since (1) auto-image-base is no longer recommended, and (2) export-all so you can take advantage of binutils' auto-export fucntionality INSTALLBINARIES = $(INSTALL_PREFIX)/bin/netpbm (line 474) - this is the big controversy 2) creates a CYGWIN-PATCHES/netpbm.README files which describes how to build [merged|normal][shared|static], and some analysis I did about which version is the most space efficient. 3) creates CYGWIN-PATCHES/shtool : netpbm is one of those packages that won't build outside of its own source tree, which complicates the script-driven build procedure. As mentioned here: http://www.cygwin.com/setup.html, I used GNU shtool's 'mkshadow' function to replicate the whole source tree inside the .build directory via symlinks. -src also contains: the build script, and the "pristine" tarball. But, this is all based on 9.24, not 9.25, so it would take some adaptation to use it, and merge my stuff with yours -- if you want it. Hope it's helpful. --Chuck Charles Wilson wrote: > Wonderful, please do. > > BTW, I have had a private version of netpbm, packaged in a > 'setup-compatible' way, for some time now. When I get home, I'll put my > version somewhere that you can access; you may want to expropriate some > of my patches... > > Also, which png have you linked against? 1.0.12, or 1.0.13? (Also, I > have libpng-1.2.2 ready for upload to sourceware, but I'm waiting for > the ripples from the massive 1.0.13 packaging changes to settle out...) > > --Chuck >
RE: ITP: netpbm
> -Original Message- > From: Earnie Boyd [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 27, 2002 6:03 AM > As for the # of executables in the /bin directory, isn't > there a limit to the number of files and/or directory entries > in any one directory on win32? As has already been said, not past the root. However directory search time is O(N) on FAT, vs (IIRC) O(logN) on NTFS. So directories with many files leads to signficcantly longer lookup times - and thas when the filename is known!. Rob
Re: ITP: netpbm
Charles Wilson wrote: > > However, directories other than the root are unlimited in size (except > by your patience, and vision) > Given that, I think the usual /usr/bin directory should suffice. Earnie.
Re: ITP: netpbm
At 04:40 PM 4/26/2002, Charles Wilson wrote: >Larry Hall (RFK Partners, Inc) wrote: > >>At 04:03 PM 4/26/2002, Earnie Boyd wrote: >> >>>As for the # of executables in the /bin directory, isn't there a limit >>>to the number of files and/or directory entries in any one directory on >>>win32? >>I remember something vague about the number of entries in a directory on FAT (not >FAT32) partitions but I'm not sure whether it applies to files, >>directories, or both (probably both). Depending on what the restriction is, this >may be a good argument for being cautious of putting too much stuff in bin. Anybody >remember more about this FAT limitation? > > >You can only have 512 entries in the ROOT directory of a partition. However, long >file names take up more than one entry, so under VFAT this limitation is actually >worse than in FAT. > >However, directories other than the root are unlimited in size (except by your >patience, and vision) That's the ticket! OK, this is a non-issue then (good!). Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX
Re: ITP: netpbm
Larry Hall (RFK Partners, Inc) wrote: > At 04:03 PM 4/26/2002, Earnie Boyd wrote: > >>As for the # of executables in the /bin directory, isn't there a limit >>to the number of files and/or directory entries in any one directory on >>win32? >> > > I remember something vague about the number of entries in a directory on > FAT (not FAT32) partitions but I'm not sure whether it applies to files, > directories, or both (probably both). Depending on what the restriction > is, this may be a good argument for being cautious of putting too much > stuff in bin. Anybody remember more about this FAT limitation? You can only have 512 entries in the ROOT directory of a partition. However, long file names take up more than one entry, so under VFAT this limitation is actually worse than in FAT. However, directories other than the root are unlimited in size (except by your patience, and vision) --Chuck
Re: ITP: netpbm
At 04:23 PM 4/26/2002, you wrote: >Larry Hall (RFK Partners, Inc) wrote: > >>They can be accommodated by providing a script with the package that moves the files >elsewhere if this becomes a big issue, no? > > >upgrades? Run the script again. >Also, user customized installations belong in /usr/local; don't mess with /usr if you >want support from the list. OK, if you're suggesting this is an argument against the script I mentioned, fine by me. I don't think it's needed either. I was just trying to point out that there are alternatives for those individuals who preferred their installation of netpbm to go in other directories. I wasn't really proposing a specific solution. >I'd probably end up ignoring Jan's package and rebuilding my own version (which goes >into: > >/usr/local/bin/netpbm/* >/usr/local/lib/ >/usr/local/include/ >etc... > >Or maybe downloading Jan's -src package with each new release and rebuilding it after >changing the prefix...and the /bin/netpbm/ ... Right. That's an option too for those who want something different than setup would provide. I guess I can live with netpbm packaged with it's own bin directory if it handles adding the special directory to PATH and given that it is the exception to the rule like you mentioned. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX
Re: ITP: netpbm
At 04:03 PM 4/26/2002, Earnie Boyd wrote: >As for the # of executables in the /bin directory, isn't there a limit >to the number of files and/or directory entries in any one directory on >win32? I remember something vague about the number of entries in a directory on FAT (not FAT32) partitions but I'm not sure whether it applies to files, directories, or both (probably both). Depending on what the restriction is, this may be a good argument for being cautious of putting too much stuff in bin. Anybody remember more about this FAT limitation? Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX
Re: ITP: netpbm
Larry Hall (RFK Partners, Inc) wrote: > They can be accommodated by providing a > script with the package that moves the files elsewhere if this becomes a big > issue, no? upgrades? Also, user customized installations belong in /usr/local; don't mess with /usr if you want support from the list. I'd probably end up ignoring Jan's package and rebuilding my own version (which goes into: /usr/local/bin/netpbm/* /usr/local/lib/ /usr/local/include/ etc... Or maybe downloading Jan's -src package with each new release and rebuilding it after changing the prefix...and the /bin/netpbm/ ... --Chuck
Re: ITP: netpbm
Earnie Boyd wrote: > So, I would like to see /usr/netpbm/bin. But I don't want to go all-out on the "separate package tree" idea. NO: /usr/netpbm/bin /usr/netpbm/lib /usr/netpbm/include /usr/netpbm/man /usr/netpbm/info Blech! YES: /usr/bin/netpbm/ << the only special case /usr/lib/ /usr/include/ /usr/man/ /usr/info/ XFree86 has a long history of a fully separate tree, and autoconf macros and suchlike have dealt with it for a long time. OTOH, netpbm has no such history (e.g. where to look for pbm.h? where to look for libpgm.a?) so development files should go in the "normal" place. But everything in the "normal" place under /usr/[lib,include,man], except for binaries in /usr/netpbm/bin/ ? That just offends my sense of aesthetics... Besides, we already have a history of /usr/bin/*/ that predates any of the mandates on http://www.cygwin.com/setup.html : ncurses-test-dll/ etc. --Chuck
Re: ITP: netpbm
At 03:57 PM 4/26/2002, Charles Wilson wrote:
>Larry Hall (RFK Partners, Inc) wrote:
>
>
>>I'm not sure why this makes more sense for this package than it would for
>>any package. So, to me, this is not a requirement for generating this package or at
>least not at this time, unless somebody can point out how
>>this package would be considered "special" in this regard.
>>In general, I don't see the advantage to having many "bin" directories,
>>at least insofar as it moves toward separate bin directories for every
>>package. It would just lead to the proliferation of directories in PATH or many
>complaints on this list stating "I installed X but when I run it,
>>it says 'X: command not found'!!!" I'd rather avoid either of these alternatives.
>
>
>Funny you should use 'X' as your variable. Think /usr/X11R6/bin/...
Yep, I'm good at things like that! ;-)
>I agree, we shouldn't worry too much about keeping /bin "clean" -- although
>distributions are moving towards putting stuff into /opt/pkg/* and making symlinks
>these days.
>
>However, IMO netpbm, like XF86, is a special case -- how many other packages have 223
>executable files and scripts? ("KDE" doesn't count; the KDE environment consists of
>lots of different packages; netpbm is one integral unit (or at most 4). And besides,
>doesn't KDE install into its own tree?)
OK, if you want to use the yardstick of "What's the convention on UNIX" as
a guideline, I guess that makes sense, excluding the free-for-all idea of
putting all packages in /opt/ptg/* and symlinking. Is there any de-facto
standard directory tree for netpbm in the UNIX world? If so, then maybe
it's worth adopting. If not, then I say it's best to just lump it all in
/usr/bin with everything else. Since it's an optional package, the number
of users that might prefer it otherwise will be a percentage of a percentage
of those who choose to install it. They can be accommodated by providing a
script with the package that moves the files elsewhere if this becomes a big
issue, no?
Larry Hall [EMAIL PROTECTED]
RFK Partners, Inc. http://www.rfk.com
838 Washington Street (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX
Re: ITP: netpbm
Charles Wilson wrote:
>
> Funny you should use 'X' as your variable. Think /usr/X11R6/bin/...
>
So, I would like to see /usr/netpbm/bin.
> I agree, we shouldn't worry too much about keeping /bin "clean" --
> although distributions are moving towards putting stuff into /opt/pkg/*
> and making symlinks these days.
>
Symlinks are slow for Win32, avoid them.
> However, IMO netpbm, like XF86, is a special case -- how many other
> packages have 223 executable files and scripts? ("KDE" doesn't count;
> the KDE environment consists of lots of different packages; netpbm is
> one integral unit (or at most 4). And besides, doesn't KDE install into
> its own tree?)
>
As for the # of executables in the /bin directory, isn't there a limit
to the number of files and/or directory entries in any one directory on
win32?
Earnie.
Re: ITP: netpbm
Larry Hall (RFK Partners, Inc) wrote:
> I'm not sure why this makes more sense for this package than it would for
> any package. So, to me, this is not a requirement for generating this
> package or at least not at this time, unless somebody can point out how
> this package would be considered "special" in this regard.
>
> In general, I don't see the advantage to having many "bin" directories,
> at least insofar as it moves toward separate bin directories for every
> package. It would just lead to the proliferation of directories in PATH
> or many complaints on this list stating "I installed X but when I run it,
> it says 'X: command not found'!!!" I'd rather avoid either of these
> alternatives.
Funny you should use 'X' as your variable. Think /usr/X11R6/bin/...
I agree, we shouldn't worry too much about keeping /bin "clean" --
although distributions are moving towards putting stuff into /opt/pkg/*
and making symlinks these days.
However, IMO netpbm, like XF86, is a special case -- how many other
packages have 223 executable files and scripts? ("KDE" doesn't count;
the KDE environment consists of lots of different packages; netpbm is
one integral unit (or at most 4). And besides, doesn't KDE install into
its own tree?)
--Chuck
Re: ITP: netpbm
Gerrit P. Haase wrote: >>Okay, *two* more things: you may want to package this "the right way" >>from the beginning -- and avoid the pain I (and everyone else by proxy) >>went thru. Split out your DLLs from everything else and have two >>packages...'netpbm' and 'libpnmXX'. That way, when user bob builds >> > > Ohoh, that makes me nervous... > > If a new perl package gets released I probably should also release a > 'libperl-5.6.1' package which contains only the libperl-5.6.1.dll ? > Probably not - and here's why: (1) the DLLs are already versioned down to the micro level (2) anybody cluefull enough to actually build something against the perl DLL is cluefull enough to save the DLL version they need for their private package 'foo' before upgrading perl. Actually, given the interdependencies in /usr/lib/perl5/5.6.1/... I don't think the DLL is much use, without all the other stuff under /usr/lib/perl5/5.6.1/... So, in the case of perl, I don't think it makes much sense to split the DLL from the rest of the package. OTOH, allowing two perls to coexist might be a reasonable thing...perhaps the parrot should be released as 'perl6-6.x.y' and not 'perl-6.x.y'. --Chuck
Re: ITP: netpbm
Gerrit P. Haase wrote: > Thumbs up from me;) > > BUT: > Is it possible to put all the binaries into a separate directory > and not to flood /bin ? > > There are 223 .exe files (the scripts and .dll not counted)! > That's one of the things my setup-compatible private version did -- but since it was private, I could do whatever I wanted. In Jan's case...we need to discuss it. I vote for a special exception to the "all executables go in /usr/bin" rule specifically for netpbm. /usr/bin/netpbm/ for the exe's, but /usr/bin for the DLLs. --Chuck
Re: ITP: netpbm
At 02:38 PM 4/26/2002, Gerrit P. Haase wrote: >Jan schrieb: > > > Today I've taken a look at the netpbm package. Pierre Humblet, who's > > listed as Cygwin porter, is not considering to contribute it as Cygwin > > package, but was fine with me packaging it. > > > I've only done a few quick tests, from ps->pnm->png. URLs below. > > Cast your votes now. > >Thumbs up from me;) > >BUT: >Is it possible to put all the binaries into a separate directory >and not to flood /bin ? > >There are 223 .exe files (the scripts and .dll not counted)! I'm not sure why this makes more sense for this package than it would for any package. So, to me, this is not a requirement for generating this package or at least not at this time, unless somebody can point out how this package would be considered "special" in this regard. In general, I don't see the advantage to having many "bin" directories, at least insofar as it moves toward separate bin directories for every package. It would just lead to the proliferation of directories in PATH or many complaints on this list stating "I installed X but when I run it, it says 'X: command not found'!!!" I'd rather avoid either of these alternatives. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX
Re: ITP: netpbm
Charles schrieb: > Okay, *two* more things: you may want to package this "the right way" > from the beginning -- and avoid the pain I (and everyone else by proxy) > went thru. Split out your DLLs from everything else and have two > packages...'netpbm' and 'libpnmXX'. That way, when user bob builds Ohoh, that makes me nervous... If a new perl package gets released I probably should also release a 'libperl-5.6.1' package which contains only the libperl-5.6.1.dll ? Gerrit -- =^..^=
Re: ITP: netpbm
Jan schrieb: > Today I've taken a look at the netpbm package. Pierre Humblet, who's > listed as Cygwin porter, is not considering to contribute it as Cygwin > package, but was fine with me packaging it. > I've only done a few quick tests, from ps->pnm->png. URLs below. > Cast your votes now. Thumbs up from me;) BUT: Is it possible to put all the binaries into a separate directory and not to flood /bin ? There are 223 .exe files (the scripts and .dll not counted)! Gerrit > http://lilypond.org/cygwin/tar/netpbm/setup.hint > sdesc: "Graphics conversion tools" > category: Graphics > requires: cygwin jpeg libpng tiff zlib > # build-requires: cygwin jpeg libpng libpng-devel tiff zlib > ldesc: "Netpbm is a toolkit for manipulation of graphic images, including > conversion of images between a variety of different formats. There > are over 220 separate tools in the package including converters for > more than 80 graphics formats." > http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1-src.tar.bz2 > http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1.tar.bz2 -- =^..^=
Re: ITP: netpbm
Oh, yeah, one other thing: runtime requirement is probably either libpng2 or libpng10, not 'libpng'. Build requirement is either libpng or libpng10-devel. (the first of each pair if 1.0.12, the second of each pair if 1.0.13). Okay, *two* more things: you may want to package this "the right way" from the beginning -- and avoid the pain I (and everyone else by proxy) went thru. Split out your DLLs from everything else and have two packages...'netpbm' and 'libpnmXX'. That way, when user bob builds gnuplot against your 'libpnm1' DLLs, his gnuplot will still work even after he upgrades to your newer netpbm package and libpnm2 DLLs -- because libpnm2 will (a) contain DLLs with names that are different from those in libpnm1, (b) can coexist on the same machine. Naturally, you'd only bump the libpnmX package number (and DLL numbers) when there was a backwards-incompatible change; ordinarily you'd just release a new libpnm1 package and overwrite the old DLLs with new-and-improved, but compatible, DLLs. Now that I think about it, you might want to split ALL of the DLLs into separate libpbmX, libpgmX, libppmX, libpamX packages -- IIRC the netpbm maintainer(s) follow different sequences on backwards compatibility on the libraries. There's no need to bump the "so" number and force new downloads of cygpbmX.dll, cygpgmX.dll, and cygpamX.dll, if only cygppmX.dll had a backwards-incompatible change... --Chuck Charles Wilson wrote: > Wonderful, please do. > > BTW, I have had a private version of netpbm, packaged in a > 'setup-compatible' way, for some time now. When I get home, I'll put my > version somewhere that you can access; you may want to expropriate some > of my patches... > > Also, which png have you linked against? 1.0.12, or 1.0.13? (Also, I > have libpng-1.2.2 ready for upload to sourceware, but I'm waiting for > the ripples from the massive 1.0.13 packaging changes to settle out...)
Re: ITP: netpbm
Wonderful, please do. BTW, I have had a private version of netpbm, packaged in a 'setup-compatible' way, for some time now. When I get home, I'll put my version somewhere that you can access; you may want to expropriate some of my patches... Also, which png have you linked against? 1.0.12, or 1.0.13? (Also, I have libpng-1.2.2 ready for upload to sourceware, but I'm waiting for the ripples from the massive 1.0.13 packaging changes to settle out...) --Chuck Jan Nieuwenhuizen wrote: > Hi list, > > Today I've taken a look at the netpbm package. Pierre Humblet, who's > listed as Cygwin porter, is not considering to contribute it as Cygwin > package, but was fine with me packaging it. > > I've only done a few quick tests, from ps->pnm->png. URLs below. > Cast your votes now. > > Greetings, > Jan. > > > http://lilypond.org/cygwin/tar/netpbm/setup.hint > sdesc: "Graphics conversion tools" > category: Graphics > requires: cygwin jpeg libpng tiff zlib > # build-requires: cygwin jpeg libpng libpng-devel tiff zlib > ldesc: "Netpbm is a toolkit for manipulation of graphic images, including > conversion of images between a variety of different formats. There > are over 220 separate tools in the package including converters for > more than 80 graphics formats." > > http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1-src.tar.bz2 > http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1.tar.bz2 > > >
ITP: netpbm
Hi list, Today I've taken a look at the netpbm package. Pierre Humblet, who's listed as Cygwin porter, is not considering to contribute it as Cygwin package, but was fine with me packaging it. I've only done a few quick tests, from ps->pnm->png. URLs below. Cast your votes now. Greetings, Jan. http://lilypond.org/cygwin/tar/netpbm/setup.hint sdesc: "Graphics conversion tools" category: Graphics requires: cygwin jpeg libpng tiff zlib # build-requires: cygwin jpeg libpng libpng-devel tiff zlib ldesc: "Netpbm is a toolkit for manipulation of graphic images, including conversion of images between a variety of different formats. There are over 220 separate tools in the package including converters for more than 80 graphics formats." http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1-src.tar.bz2 http://lilypond.org/cygwin/tar/netpbm/netpbm-9.25-1.tar.bz2 -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
