Re: Coreutils musings...
On Wed, 10 Mar 2004, Christopher Faylor wrote: > On Wed, Mar 10, 2004 at 12:01:12AM -0500, Mark Blackburn wrote: > >I tried compiling coreutils-5.2.0 and I didn't see many problems with > >that. Another problem I see is that coreutils will cause conflicts with > >other packages: textutils, sh-utils and fileutils. Obviously coreutils > >is intended to replace these packages so these packages would need to be > >withdrawn if coreutils was included with cygwin. > > I don't understand the point of this email. If you are volunteering to > support coreutils, then thanks. But if he's, let me add 2 things: 1- Last time I tried printf.exe linked against the static libintl (or libiconv), making a huge binary. 2- http://www.cygwin.com/ml/cygwin-apps/2003-08/msg00234.html -- http://www.pervalidus.net/contact.html
Re: libungif - Depends on obsolete X libraries - Rebuild for approval by maintainer
On Tue, 9 Mar 2004, Harold L Hunt II wrote: > Frédéric L. W. Meunier wrote: > > > These aren't really strong arguments. > > > > Lapo is assuming that only WindowMaker uses libungif because > > it's the only application linked to it in Cygwin. > > > > You're assuming libungif should depend on XFree86 because it > > worked fine with it for 2 years. > > > > linbugif compiled with --without-x will work fine too, and also > > enable other people who don't want to install XFree86 to use > > the library or any tools, except gif2x11. > > > Okay, I will make a stronger argument: I will be really p'odd > if a rebuild of libungif using --without-x busts my > WindowMaker package. In fact, I don't even want to have to > look into whether WindowMaker is busted or not; I want to > maintain the status quo because I am too busy to do > otherwise. If you rebuild libungif using --without-x, > rebuild WindowMaker against that version of libungif, install > both and test them to confirm that WindowMaker works, then I > *might* think it is okay to use --without-x for libungif. Sorry, but I'm not going to do that mainly because I don't use WindowMaker, am not familiar with it, and wouldn't know where to look for anything that could broke gif support. Maybe someone will. Anyway, it shouldn't break anything as some Linux distributions use --without-x and ship WindowMaker with gif support (yes, it has a --disable-gif). > > But, again, is it so hard to make 2 packages, one with > > --without-x ? > > Have you done it? Yes, it is really hard. Think about 16 > hours to work out all of the little kinks. What ? I thought you had fix all issues, so it's probably what took your time. Simply replicating it with --without-x shouldn't take so much, as it doesn't change anything. In fact, it just doesn't build gif2x11. You don't even need to relibtoolize and such. -- http://www.pervalidus.net/contact.html
Re: Coreutils musings...
Christopher Faylor wrote: I don't understand the point of this email. If you are volunteering to support coreutils, then thanks. If you aren't then I'm not going to enter into YA discussion about these issues. I'll do that when someone actually volunteers and actually starts doing work. cgf I'm going to poke around in the coreutils source for a bit to make sure I'm not biting off more than I can chew before I volunteer. I don't expect any further discussion until I post an ITP and I'm sure that I'm competent enough to discuss things. Mark Blackburn
Re: Coreutils musings...
On Wed, Mar 10, 2004 at 12:17:30AM -0500, Mark Blackburn wrote: >Mark Blackburn wrote: > >>I tried compiling coreutils-5.2.0 and I didn't see many problems with >>that. Another problem I see is that coreutils will cause conflicts >>with other packages: textutils, sh-utils and fileutils. Obviously >>coreutils is intended to replace these packages so these packages >>would need to be withdrawn if coreutils was included with cygwin. > >Feel free to ignore this posting. > >I didn't search the archives for coreutils before sending this message >(sorry). I was mainly looking for confirmation that coreutils was >intended to replace all three of the *utils packages and it's obvious >from the archives that this is the case. > >I'll research the archives more thoroughly before posting about >coreutils again. Not to be too pedantic or anything (but when did that ever stop me) but the only applicable message about coreutils in cygwin-apps is really an ITP. Anything else is off-topic since coreutils isn't currently a cygwin package. I'll gladly waive the moratorium for a new coreutils package. cgf
Re: Coreutils musings...
Mark Blackburn wrote: I tried compiling coreutils-5.2.0 and I didn't see many problems with that. Another problem I see is that coreutils will cause conflicts with other packages: textutils, sh-utils and fileutils. Obviously coreutils is intended to replace these packages so these packages would need to be withdrawn if coreutils was included with cygwin. Feel free to ignore this posting. I didn't search the archives for coreutils before sending this message (sorry). I was mainly looking for confirmation that coreutils was intended to replace all three of the *utils packages and it's obvious from the archives that this is the case. I'll research the archives more thoroughly before posting about coreutils again. Mark Blackburn
Re: Coreutils musings...
On Wed, Mar 10, 2004 at 12:01:12AM -0500, Mark Blackburn wrote: >I tried compiling coreutils-5.2.0 and I didn't see many problems with >that. Another problem I see is that coreutils will cause conflicts with >other packages: textutils, sh-utils and fileutils. Obviously coreutils >is intended to replace these packages so these packages would need to be >withdrawn if coreutils was included with cygwin. I don't understand the point of this email. If you are volunteering to support coreutils, then thanks. If you aren't then I'm not going to enter into YA discussion about these issues. I'll do that when someone actually volunteers and actually starts doing work. cgf >I've tried to correlate all the binaries in textutils, sh-utils and >fileutils with those in coreutils and here is what I found: > >/usr/bin/kill.exe from coreutils conflicts with cygwin-1.5.7-1. >New binaries in coreutils are: > /usr/bin/[.exe > /usr/bin/link.exe > /usr/bin/stat.exe > /usr/bin/unlink.exe > >I appear to be missing su.exe from coreutils but that's because it >didn't install for whatever reason. Other than that no binaries are >missing from coreutils that are in sh-utils, textutils and fileutils > >If coreutils were to be packaged I would assume that >1) kill would not be included with coreutils so cygwin's kill would not >get overwritten. >2) The binaries [.exe, link.exe, stat.exe and unlink.exe would be >included with coreutils. > >[EMAIL PROTECTED] ~/src/coreutils/tmp >$ tar jxf ../coreutils-5.2.0-1.tar.bz2 > >[EMAIL PROTECTED] ~/src/coreutils/tmp >$ tmp=`zcat /etc/setup/textutils.lst.gz | grep -e usr/bin/.*.exe`; for >i in $tmp ; do ls $i ; done >usr/bin/cat.exe* >usr/bin/cksum.exe* >usr/bin/comm.exe* >usr/bin/csplit.exe* >usr/bin/cut.exe* >usr/bin/expand.exe* >usr/bin/fmt.exe* >usr/bin/fold.exe* >usr/bin/head.exe* >usr/bin/join.exe* >usr/bin/md5sum.exe* >usr/bin/nl.exe* >usr/bin/od.exe* >usr/bin/paste.exe* >usr/bin/pr.exe* >usr/bin/ptx.exe* >usr/bin/sha1sum.exe* >usr/bin/sort.exe* >usr/bin/split.exe* >usr/bin/sum.exe* >usr/bin/tac.exe* >usr/bin/tail.exe* >usr/bin/tr.exe* >usr/bin/tsort.exe* >usr/bin/unexpand.exe* >usr/bin/uniq.exe* >usr/bin/wc.exe* > >[EMAIL PROTECTED] ~/src/coreutils/tmp >$ tmp=`zcat /etc/setup/fileutils.lst.gz | grep -e usr/bin/.*.exe`; for >i in $tmp ; do ls $i ; done >usr/bin/chgrp.exe* >usr/bin/chmod.exe* >usr/bin/chown.exe* >usr/bin/cp.exe* >usr/bin/dd.exe* >usr/bin/df.exe* >usr/bin/dir.exe* >usr/bin/dircolors.exe* >usr/bin/du.exe* >usr/bin/install.exe* >usr/bin/ln.exe* >usr/bin/ls.exe* >usr/bin/mkdir.exe* >usr/bin/mkfifo.exe* >usr/bin/mknod.exe* >usr/bin/mv.exe* >usr/bin/rm.exe* >usr/bin/rmdir.exe* >usr/bin/shred.exe* >usr/bin/sync.exe* >usr/bin/touch.exe* >usr/bin/vdir.exe* > >[EMAIL PROTECTED] ~/src/coreutils/tmp >$ tmp=`zcat /etc/setup/sh-utils.lst.gz | grep -e usr/bin/.*.exe`; for i >in $tmp ; do ls $i ; done >usr/bin/basename.exe* >usr/bin/chroot.exe* >usr/bin/date.exe* >usr/bin/dirname.exe* >usr/bin/echo.exe* >usr/bin/env.exe* >usr/bin/expr.exe* >usr/bin/factor.exe* >usr/bin/false.exe* >usr/bin/hostid.exe* >usr/bin/hostname.exe* >usr/bin/id.exe* >usr/bin/logname.exe* >usr/bin/nice.exe* >usr/bin/pathchk.exe* >usr/bin/pinky.exe* >usr/bin/printenv.exe* >usr/bin/printf.exe* >usr/bin/pwd.exe* >usr/bin/seq.exe* >usr/bin/sleep.exe* >usr/bin/stty.exe* >ls: usr/bin/su.exe: No such file or directory >usr/bin/tee.exe* >usr/bin/test.exe* >usr/bin/true.exe* >usr/bin/tty.exe* >usr/bin/uname.exe* >usr/bin/users.exe* >usr/bin/who.exe* >usr/bin/whoami.exe* >usr/bin/yes.exe* > >[EMAIL PROTECTED] ~/src/coreutils/tmp >$ cd usr/bin/ > >[EMAIL PROTECTED] ~/src/coreutils/tmp/usr/bin >$ for i in *.exe ; do echo -n $i" : ";tmp=`basename $i .exe`; echo >`cygcheck -f /usr/bin/$tmp` ; done >[.exe : >basename.exe : sh-utils-2.0.15-4 >cat.exe : textutils-2.0.21-1 >chgrp.exe : fileutils-4.1-2 >chmod.exe : fileutils-4.1-2 >chown.exe : fileutils-4.1-2 >chroot.exe : sh-utils-2.0.15-4 >cksum.exe : textutils-2.0.21-1 >comm.exe : textutils-2.0.21-1 >cp.exe : fileutils-4.1-2 >csplit.exe : textutils-2.0.21-1 >cut.exe : textutils-2.0.21-1 >date.exe : sh-utils-2.0.15-4 >dd.exe : fileutils-4.1-2 >df.exe : fileutils-4.1-2 >dir.exe : fileutils-4.1-2 >dircolors.exe : fileutils-4.1-2 >dirname.exe : sh-utils-2.0.15-4 >du.exe : fileutils-4.1-2 >echo.exe : sh-utils-2.0.15-4 >env.exe : sh-utils-2.0.15-4 >expand.exe : textutils-2.0.21-1 >expr.exe : sh-utils-2.0.15-4 >factor.exe : sh-utils-2.0.15-4 >false.exe : sh-utils-2.0.15-4 >fmt.exe : textutils-2.0.21-1 >fold.exe : textutils-2.0.21-1 >head.exe : textutils-2.0.21-1 >hostid.exe : sh-utils-2.0.15-4 >hostname.exe : sh-utils-2.0.15-4 >id.exe : sh-utils-2.0.15-4 >install.exe : fileutils-4.1-2 >join.exe : textutils-2.0.21-1 >kill.exe : cygwin-1.5.7-1 >link.exe : >ln.exe : fileutils-4.1-2 >logname.exe : sh-utils-2.0.15-4 >ls.exe : fileutils-4.1-2 >md5sum.exe : textutils-2.0.21-1 >mkdir.exe : fileutils-4.1-2 >mkfifo.exe : fileutils-4.1-2 >mknod.exe : fileutils-4.1-2 >mv.exe : fileut
Coreutils musings...
I tried compiling coreutils-5.2.0 and I didn't see many problems with that. Another problem I see is that coreutils will cause conflicts with other packages: textutils, sh-utils and fileutils. Obviously coreutils is intended to replace these packages so these packages would need to be withdrawn if coreutils was included with cygwin. I've tried to correlate all the binaries in textutils, sh-utils and fileutils with those in coreutils and here is what I found: /usr/bin/kill.exe from coreutils conflicts with cygwin-1.5.7-1. New binaries in coreutils are: /usr/bin/[.exe /usr/bin/link.exe /usr/bin/stat.exe /usr/bin/unlink.exe I appear to be missing su.exe from coreutils but that's because it didn't install for whatever reason. Other than that no binaries are missing from coreutils that are in sh-utils, textutils and fileutils If coreutils were to be packaged I would assume that 1) kill would not be included with coreutils so cygwin's kill would not get overwritten. 2) The binaries [.exe, link.exe, stat.exe and unlink.exe would be included with coreutils. [EMAIL PROTECTED] ~/src/coreutils/tmp $ tar jxf ../coreutils-5.2.0-1.tar.bz2 [EMAIL PROTECTED] ~/src/coreutils/tmp $ tmp=`zcat /etc/setup/textutils.lst.gz | grep -e usr/bin/.*.exe`; for i in $tmp ; do ls $i ; done usr/bin/cat.exe* usr/bin/cksum.exe* usr/bin/comm.exe* usr/bin/csplit.exe* usr/bin/cut.exe* usr/bin/expand.exe* usr/bin/fmt.exe* usr/bin/fold.exe* usr/bin/head.exe* usr/bin/join.exe* usr/bin/md5sum.exe* usr/bin/nl.exe* usr/bin/od.exe* usr/bin/paste.exe* usr/bin/pr.exe* usr/bin/ptx.exe* usr/bin/sha1sum.exe* usr/bin/sort.exe* usr/bin/split.exe* usr/bin/sum.exe* usr/bin/tac.exe* usr/bin/tail.exe* usr/bin/tr.exe* usr/bin/tsort.exe* usr/bin/unexpand.exe* usr/bin/uniq.exe* usr/bin/wc.exe* [EMAIL PROTECTED] ~/src/coreutils/tmp $ tmp=`zcat /etc/setup/fileutils.lst.gz | grep -e usr/bin/.*.exe`; for i in $tmp ; do ls $i ; done usr/bin/chgrp.exe* usr/bin/chmod.exe* usr/bin/chown.exe* usr/bin/cp.exe* usr/bin/dd.exe* usr/bin/df.exe* usr/bin/dir.exe* usr/bin/dircolors.exe* usr/bin/du.exe* usr/bin/install.exe* usr/bin/ln.exe* usr/bin/ls.exe* usr/bin/mkdir.exe* usr/bin/mkfifo.exe* usr/bin/mknod.exe* usr/bin/mv.exe* usr/bin/rm.exe* usr/bin/rmdir.exe* usr/bin/shred.exe* usr/bin/sync.exe* usr/bin/touch.exe* usr/bin/vdir.exe* [EMAIL PROTECTED] ~/src/coreutils/tmp $ tmp=`zcat /etc/setup/sh-utils.lst.gz | grep -e usr/bin/.*.exe`; for i in $tmp ; do ls $i ; done usr/bin/basename.exe* usr/bin/chroot.exe* usr/bin/date.exe* usr/bin/dirname.exe* usr/bin/echo.exe* usr/bin/env.exe* usr/bin/expr.exe* usr/bin/factor.exe* usr/bin/false.exe* usr/bin/hostid.exe* usr/bin/hostname.exe* usr/bin/id.exe* usr/bin/logname.exe* usr/bin/nice.exe* usr/bin/pathchk.exe* usr/bin/pinky.exe* usr/bin/printenv.exe* usr/bin/printf.exe* usr/bin/pwd.exe* usr/bin/seq.exe* usr/bin/sleep.exe* usr/bin/stty.exe* ls: usr/bin/su.exe: No such file or directory usr/bin/tee.exe* usr/bin/test.exe* usr/bin/true.exe* usr/bin/tty.exe* usr/bin/uname.exe* usr/bin/users.exe* usr/bin/who.exe* usr/bin/whoami.exe* usr/bin/yes.exe* [EMAIL PROTECTED] ~/src/coreutils/tmp $ cd usr/bin/ [EMAIL PROTECTED] ~/src/coreutils/tmp/usr/bin $ for i in *.exe ; do echo -n $i" : ";tmp=`basename $i .exe`; echo `cygcheck -f /usr/bin/$tmp` ; done [.exe : basename.exe : sh-utils-2.0.15-4 cat.exe : textutils-2.0.21-1 chgrp.exe : fileutils-4.1-2 chmod.exe : fileutils-4.1-2 chown.exe : fileutils-4.1-2 chroot.exe : sh-utils-2.0.15-4 cksum.exe : textutils-2.0.21-1 comm.exe : textutils-2.0.21-1 cp.exe : fileutils-4.1-2 csplit.exe : textutils-2.0.21-1 cut.exe : textutils-2.0.21-1 date.exe : sh-utils-2.0.15-4 dd.exe : fileutils-4.1-2 df.exe : fileutils-4.1-2 dir.exe : fileutils-4.1-2 dircolors.exe : fileutils-4.1-2 dirname.exe : sh-utils-2.0.15-4 du.exe : fileutils-4.1-2 echo.exe : sh-utils-2.0.15-4 env.exe : sh-utils-2.0.15-4 expand.exe : textutils-2.0.21-1 expr.exe : sh-utils-2.0.15-4 factor.exe : sh-utils-2.0.15-4 false.exe : sh-utils-2.0.15-4 fmt.exe : textutils-2.0.21-1 fold.exe : textutils-2.0.21-1 head.exe : textutils-2.0.21-1 hostid.exe : sh-utils-2.0.15-4 hostname.exe : sh-utils-2.0.15-4 id.exe : sh-utils-2.0.15-4 install.exe : fileutils-4.1-2 join.exe : textutils-2.0.21-1 kill.exe : cygwin-1.5.7-1 link.exe : ln.exe : fileutils-4.1-2 logname.exe : sh-utils-2.0.15-4 ls.exe : fileutils-4.1-2 md5sum.exe : textutils-2.0.21-1 mkdir.exe : fileutils-4.1-2 mkfifo.exe : fileutils-4.1-2 mknod.exe : fileutils-4.1-2 mv.exe : fileutils-4.1-2 nice.exe : sh-utils-2.0.15-4 nl.exe : textutils-2.0.21-1 nohup.exe : sh-utils-2.0.15-4 od.exe : textutils-2.0.21-1 paste.exe : textutils-2.0.21-1 pathchk.exe : sh-utils-2.0.15-4 pinky.exe : sh-utils-2.0.15-4 pr.exe : textutils-2.0.21-1 printenv.exe : sh-utils-2.0.15-4 printf.exe : sh-utils-2.0.15-4 ptx.exe : textutils-2.0.21-1 pwd.exe : sh-utils-2.0.15-4 readlink.exe : cygutils-1.2.4-1 rm.exe : fileutils-4.1-2 rmdir.exe : fileutils-4.1-2 seq.exe : sh-utils-2.0.15-4 sha1sum.exe : textutils-2.0.
Re: libungif - Depends on obsolete X libraries - Rebuild for approval by maintainer
Frédéric L. W. Meunier wrote: Sorry, sent it to cygwin-xfree. Time to sleep. On Tue, 9 Mar 2004, Harold L Hunt II wrote: Lapo Luchini wrote: Actually I was thinking about using --without-x in next release. But no other program seems to use it, except WMaker, that uses X11 anyway. There doesn't seem to be a reason to do --without-x since libungif has used it for two years without major problems. These aren't really strong arguments. Lapo is assuming that only WindowMaker uses libungif because it's the only application linked to it in Cygwin. You're assuming libungif should depend on XFree86 because it worked fine with it for 2 years. linbugif compiled with --without-x will work fine too, and also enable other people who don't want to install XFree86 to use the library or any tools, except gif2x11. Okay, I will make a stronger argument: I will be really p'odd if a rebuild of libungif using --without-x busts my WindowMaker package. In fact, I don't even want to have to look into whether WindowMaker is busted or not; I want to maintain the status quo because I am too busy to do otherwise. If you rebuild libungif using --without-x, rebuild WindowMaker against that version of libungif, install both and test them to confirm that WindowMaker works, then I *might* think it is okay to use --without-x for libungif. This is simply following the rule of "if it ain't broke, don't fix it". I often find out that lots of other people have plenty of arguments for leaving something alone when I cannot think of such an argument myself. Of course, I figure this out after the fact; in this case I am not interested in being unpleasantly surprised. But, again, is it so hard to make 2 packages, one with --without-x ? Have you done it? Yes, it is really hard. Think about 16 hours to work out all of the little kinks. Harold
Re: libungif - Depends on obsolete X libraries - Rebuild for approval by maintainer
Sorry, sent it to cygwin-xfree. Time to sleep. On Tue, 9 Mar 2004, Harold L Hunt II wrote: > Lapo Luchini wrote: > > > Actually I was thinking about using --without-x in next release. > > But no other program seems to use it, except WMaker, that uses X11 anyway. > > > There doesn't seem to be a reason to do --without-x since libungif has > used it for two years without major problems. These aren't really strong arguments. Lapo is assuming that only WindowMaker uses libungif because it's the only application linked to it in Cygwin. You're assuming libungif should depend on XFree86 because it worked fine with it for 2 years. linbugif compiled with --without-x will work fine too, and also enable other people who don't want to install XFree86 to use the library or any tools, except gif2x11. But, again, is it so hard to make 2 packages, one with --without-x ? I understand the same could be made for gd, after all only a few people are likely using the xpm support, which is what adds the XFree86-bin requirement. Anyway, it's just my opinion. I really don't use both on Cygwin (but do on a few Linux machines, where space matters). -- http://www.pervalidus.net/contact.html
Re: emacs / libICE.dll
Corinna Vinschen wrote: On Mar 9 14:03, Oodini wrote: Hello, I've just installed Cygwin on Windows 2000 to learn Unix stuff, and I don't succeed to run emacs. Windows looks for the missing dll libICE.dll. Please note that I don't know Unix, except some basic command. Thanks for help. Wrong mailing list. Try Well, sort of, but we need to discuss this here as well. I have been telling people that the lib*.dll libraries for Cygwin/X would be going away for a few months now and apparently the emacs maintainer has not had a chance to recompile their package in 8 months. emacs really needs to get rebuilt since I will be pulling thos lib*.dll libraries from the distribution within the next week or so. On a side note, emacs must have been missing XFree86-lib-compat as dependency in setup.hint for about 8 months now; this would explain why this user does not have those libraries. Harold
Re: libungif - Depends on obsolete X libraries - Rebuild for approval by maintainer
Lapo, Lapo Luchini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harold L Hunt II wrote: I am posting this for review by Lapo, the current maintainer of libungif. If Lapo approves, I will upload this ASAP. I'm packagin' 4.1.1, but in the meantime feel free to upload this one (that seems to have already most of the needed patches except "upgrade to latest version" ^_^). 2) Added dependency on XFree86-bin in setup.hint. (Harold L Hunt II) Actually I was thinking about using --without-x in next release. But no other program seems to use it, except WMaker, that uses X11 anyway. 4) Fixed build script to ignore files generated by relibtoolize, since this step will be performed on next rebuild. (Harold L Hunt II) I also knida changed my idea to ease the work on the user by including the giga-patch instead of dynamic relibtoolizing. But I doubt that "user" really exists, and relibtoolizing works just as good, with a much clearer patch. Actually, I did package 4.1.2 (released a few days ago) and posted it for your review also: http://cygwin.com/ml/cygwin-apps/2004-03/msg00044.html It is ready to upload and does the proper amount of re-autotooling before building and properly ignores those generated files. There doesn't seem to be a reason to do --without-x since libungif has used it for two years without major problems. Harold
Re: emacs / libICE.dll
Wrong mailing list. Try [EMAIL PROTECTED] OK, thank you !
Re: emacs / libICE.dll
On Mar 9 14:03, Oodini wrote: > Hello, > > I've just installed Cygwin on Windows 2000 to learn Unix stuff, and I > don't succeed to run emacs. > > Windows looks for the missing dll libICE.dll. > > Please note that I don't know Unix, except some basic command. > > Thanks for help. Wrong mailing list. Try [EMAIL PROTECTED] Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
emacs / libICE.dll
Hello, I've just installed Cygwin on Windows 2000 to learn Unix stuff, and I don't succeed to run emacs. Windows looks for the missing dll libICE.dll. Please note that I don't know Unix, except some basic command. Thanks for help.
Re: libungif - Depends on obsolete X libraries - Rebuild for approval by maintainer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harold L Hunt II wrote: > I am posting this for review by Lapo, the current maintainer of > libungif. If Lapo approves, I will upload this ASAP. I'm packagin' 4.1.1, but in the meantime feel free to upload this one (that seems to have already most of the needed patches except "upgrade to latest version" ^_^). > 2) Added dependency on XFree86-bin in setup.hint. (Harold L Hunt II) Actually I was thinking about using --without-x in next release. But no other program seems to use it, except WMaker, that uses X11 anyway. > 4) Fixed build script to ignore files generated by relibtoolize, since > this step will be performed on next rebuild. (Harold L Hunt II) I also knida changed my idea to ease the work on the user by including the giga-patch instead of dynamic relibtoolizing. But I doubt that "user" really exists, and relibtoolizing works just as good, with a much clearer patch. Lapo - -- L a p o L u c h i n i l a p o @ l a p o . i t w w w . l a p o . i t / http://www.megatokyo.it -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkBNndAACgkQaJiCLMjyUvuOWgCeOiNGQiURel8qrcJhnYi7UtAo 2QsAnA6XSnEo57+hFn/yMLKu7pMlHcM+ =Gyoo -END PGP SIGNATURE-
Re: xemacs-21.5.16 SHOULD BE MARKED AS experimental
On Mar 9 08:27, Dr. Volker Zell wrote: > cd xemacs > wget http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/xemacs/setup.hint > > cd xemacs-tags > wget > http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/xemacs/xemacs-tags/setup.hint > > cd ../xemacs-emacs-common > wget > http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/xemacs/xemacs-emacs-common/setup.hint Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: Please upload: xemacs-21.5.16-1/xemacs-tags-21.5.16-1/xemacs-emacs-common-21.5.16-1
On Mar 9 08:09, Dr. Volker Zell wrote: > > "Corinna" == Corinna Vinschen writes: > > Corinna> On Mar 3 10:17, Dr. Volker Zell wrote: > >> wget > http://cygwin.dev.wapme.net/packages/vzell/cygwin/release/xemacs/xemacs-tags/xemacs-tags-21.5.16-1.tar.bz2 > > Corinna> I just found that this one hasn't been uploaded: > > Corinna> $ wget [blah] > Corinna> HTTP request sent, awaiting response... 404 Not Found > Corinna> 17:25:00 ERROR 404: Not Found. > > My fault, should be there now. Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
