This will go in but not immediately, I've a couple of pending things in my
sandbox to sort out first.
Rob
- Original Message -
From: "Marcel Telka" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 10, 2002 5:01 PM
Subject: Re: [PATCH] setup.exe - problem with FTP
>
> Na
Napísané dňa 08.07.2002 15:27:30 +0200, (autor: Marcel Telka):
> Hi.
>
> I've found little problem in the cygwin setup program:
>
> There is no possibility to download files from some FTP servers (like
> djb's publicfile ftpd http://cr.yp.to/publicfile/ftpd.html) because
> the setup scans for '
- Original Message -
From: "Charles Wilson" <[EMAIL PROTECTED]>
To: "Charles Wilson" <[EMAIL PROTECTED]>
Sent: Wednesday, July 10, 2002 1:54 PM
> > unpack -src, giving:
> > foo-1.2-3.mknetrel
> > foo-1.2-3.patch
> > foo-1.2.tar.gz
>
>
> Yes, this looks an awful lot like 'method 2' -- and
- Original Message -
From: "Charles Wilson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 10, 2002 1:49 PM
> This is counter to the RPM (and mebbe deb?) concept of "shipping
> pristine sources". Is there some way to do this?
deb ships pristine sources.
> unpack -sr
[had to take a little while to settle down before answering this one]
On Tue, Jul 09, 2002 at 06:31:20PM +0200, Jan Nieuwenhuizen wrote:
>Christopher Faylor <[EMAIL PROTECTED]> writes:
>
>> On Tue, Jul 09, 2002 at 02:14:16AM +0200, Jan Nieuwenhuizen wrote:
>>>
>>> - fixes and preparations for b
Charles Wilson wrote:
> Now, stop me if I get too 'method 2ish', but:
[snip]
> unpack -src, giving:
> foo-1.2-3.mknetrel
> foo-1.2-3.patch
> foo-1.2.tar.gz
Yes, this looks an awful lot like 'method 2' -- and we've got perfectly
good example shell scripts for doing things the 'method 2'
Christopher Faylor wrote:
> Hmm. It's sort of sad when I make the effort to read the entire thread
> but still miss the point anyway.
>
> Why not just have mknetrel use a "mknetrel" file in the source directory
> if it finds one? I've been thinking about doing this for a while.
>
> Then the
Hmm. It's sort of sad when I make the effort to read the entire thread
but still miss the point anyway.
Why not just have mknetrel use a "mknetrel" file in the source directory
if it finds one? I've been thinking about doing this for a while.
Then there is no need to decide on a location for t
On Tue, Jul 09, 2002 at 06:05:51PM +0200, Jan Nieuwenhuizen wrote:
>Christopher Faylor <[EMAIL PROTECTED]> writes:
>
>> On Tue, Jul 09, 2002 at 02:14:37AM +0200, Jan Nieuwenhuizen wrote:
>>>
>>> - autogenerate cygwin build script: $package.sh
>>
>> This looks like a prepackage function to me. N
On Tue, Jul 09, 2002 at 10:00:00PM -0500, Gary R. Van Sickle wrote:
>Here it is.
>
>Page:
>http://home.att.net/~g.r.vansickle/cygwin_packages/mutt-1.4-1/
>
>Direct Links:
>http://home.att.net/~g.r.vansickle/cygwin_packages/mutt-1.4-1/mutt-1.4-1-src.tar
>.bz2
>http://home.att.net/~g.r.vansickle/cyg
Here it is.
Page:
http://home.att.net/~g.r.vansickle/cygwin_packages/mutt-1.4-1/
Direct Links:
http://home.att.net/~g.r.vansickle/cygwin_packages/mutt-1.4-1/mutt-1.4-1-src.tar
.bz2
http://home.att.net/~g.r.vansickle/cygwin_packages/mutt-1.4-1/mutt-1.4-1.tar.bz2
http://home.att.net/~g.r.vansickle
On Tue, Jul 09, 2002 at 12:43:48PM +0200, Jan Nieuwenhuizen wrote:
>> Oh, one part wasn't. The layout is supposed to be like this:
>>
>> /netrel
>> bin
>> extra
>> src
>> inst
>> uploads
>> log
>>
>> So, the location of extra was not erroneous.
>
>I don't think so; it depends on your defaul
On Tue, Jul 09, 2002 at 06:02:11PM +0200, Jan Nieuwenhuizen wrote:
>Christopher Faylor <[EMAIL PROTECTED]> writes:
>
>> On Tue, Jul 09, 2002 at 02:14:54AM +0200, Jan Nieuwenhuizen wrote:
>>>
>>> - add funtionality to split into and build sub packages
>>
>> I suspect that this functionality could
On Tue, Jul 09, 2002 at 02:45:46PM +0200, Jan Nieuwenhuizen wrote:
>2002-07-09 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
>
> * bin/mknetrel: Invoke atexit () before exiting.
> (atexit): New function.
> (drop): New funtion.
> (usage): Return (previously: exit unsuccessfully).
> > > Also, libintl2 requires libiconv2, so he should only need to depend on
> > > libintl2. Similarly, libncurses6 requires terminfo, so he should only
> > > need to depend on libncurses6.
> > >
> >
> > http://cygwin.com/setup.html#setup.hint recommends this:
> >
> > "Hierarchical dependencies s
> On Tue, Jul 09, 2002 at 05:13:00AM -0500, Gary R. Van Sickle wrote:
> > setup.hint if you're interested:
> > @ mutt
> > sdesc: "A text mode mail user agent"
> > category: Mail
> > requires: cygwin libncurses6 terminfo libintl1 libiconv2 openssl ssmtp
>
> The setup.hint contains a dependency to a
- Original Message -
From: "Gary R. Van Sickle" <[EMAIL PROTECTED]>
To: "Cygwin-Apps" <[EMAIL PROTECTED]>
Sent: Wednesday, July 10, 2002 11:59 AM
Subject: RE: [FINALLY]: Mutt-1.4-1 package ready
> > Also, libintl2 requires libiconv2, so he should only need to depend on
> > libintl2. Si
> Also, libintl2 requires libiconv2, so he should only need to depend on
> libintl2. Similarly, libncurses6 requires terminfo, so he should only
> need to depend on libncurses6.
>
http://cygwin.com/setup.html#setup.hint recommends this:
"Hierarchical dependencies should work correctly, however,
Uploaded.
Dario Alcocer wrote:
> On Mon, Jul 08, 2002 at 04:17:41PM -0400, Charles Wilson wrote:
>
>>Erm, you realize that the setup.hints are supposed to be *separate*
>>files, right?
>>
>
> Oops, no I didn't realize this. I've split the setup.hint into three
> separate ones: gs-setup.hint,
Robert Collins wrote:
> mmm, time for arch/subversion/another one of the recent pack of opensource /
> free software revision control systems?
Mebbe -- but cygwin still needs a cvs port, because cvs is still the
standard. The main attractions to cvsnt are
1) it's still basically cvs. same c
- Original Message -
From: "Lapo Luchini" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>;
Sent: Tuesday, July 09, 2002 5:34 PM
Subject: setup.ini format [Was: setup.exe and replacing of in-use files]
> >[vV]"ersion:" return PACKAGEVERSION;
> >
> Do you accidentally know where is
mmm, time for arch/subversion/another one of the recent pack of opensource /
free software revision control systems?
Rob
- Original Message -
From: "Charles Wilson" <[EMAIL PROTECTED]>
To: "Jan Nieuwenhuizen" <[EMAIL PROTECTED]>
Cc: "Earnie Boyd" <[EMAIL PROTECTED]>
Sent: Wednesday, July
- Original Message -
From: "Jan Nieuwenhuizen" <[EMAIL PROTECTED]>
To: "Nicholas Wourms" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, July 10, 2002 5:43 AM
>
> But what I would like is
>
>apt-get task-cygwin-devel
Have I mentioned already that setup.exe HEAD has full
- Original Message -
From: "Nicholas Wourms" <[EMAIL PROTECTED]>
To: "Jan Nieuwenhuizen" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, July 10, 2002 5:01 AM
> Jan et al.,
>
> Let keep the conversation about building a cross-compiler automatically
> going. I think CGF is b
Matt Rice wrote:
> here is what it took to get through 'make' on Corinna's port of sunrpc
> back from B20 to 1.3
> I haven't really checked out the secure_rpc directory...
> I dont have all the neccesary librarys...
>
> on a side note, 'make clean' doesnt remove .exe files...
>
> I got the orig
Charles Wilson <[EMAIL PROTECTED]> writes:
> It's a short term problem. [..] Once those are fixed, I'll release
> another test release -- with cygltdl-3.dll split out into, oh, I
> dunno, a 'libltdl3' package.
Ok. Then it's fine.
> However, in the short term, early adopters of guile are goin
On Tue, Jul 09, 2002 at 11:32:24PM +0200, Hack Kampbj?rn wrote:
>Hi all,
>
>keychain-1.9-1 is now ready for upload.
>
>http://hackdata.com/cygwin/keychain/keychain-1.9-1.tar.bz2
>http://hackdata.com/cygwin/keychain/keychain-1.9-1-src.tar.bz2
>
>http://hackdata.com/cygwin/keychain/setup.hint (remov
here is what it took to get through 'make' on Corinna's port of sunrpc
back from B20 to 1.3
I haven't really checked out the secure_rpc directory...
I dont have all the neccesary librarys...
on a side note, 'make clean' doesnt remove .exe files...
I got the original sources from
http://www.ge
Hi all,
keychain-1.9-1 is now ready for upload.
http://hackdata.com/cygwin/keychain/keychain-1.9-1.tar.bz2
http://hackdata.com/cygwin/keychain/keychain-1.9-1-src.tar.bz2
http://hackdata.com/cygwin/keychain/setup.hint (removed test tag)
sdesc: "An OpenSSH key manager"
ldesc: "Keychain is an Open
On Tue, Jul 09, 2002 at 04:16:03PM -0400, Charles Wilson wrote:
>>Let keep the conversation about building a cross-compiler automatically
>>going. I think CGF is being rather stubborn about it and doesn't see
>>the potential benefits for the end user.
>
>No need to be confrontational, Nichola
Jan Nieuwenhuizen wrote:
>>Mebbe I ought split out the dll...but right now, libtool-devel IS
>>required by libguile14, or cygguile-14.dll will break.
>>
>
> Yes, I wondered about this (a lilypond user flagged this problem just
> a minute ago). But I guess there's no way around this, for guile?
Charles Wilson <[EMAIL PROTECTED]> writes:
> Uploaded. I made some corrections to the setup.hints, I hope that was okay.
Ok? You're fixing my bugs, don't do that again.
;-) Thanks a lot!
I think they're all ok, so I'll fix the hint files for -4.
> WHY: cygguile-14.dll depends on cygltdl-3.dl
Jan Nieuwenhuizen wrote:
> There just one small bugreport on -2, from Chuck, which has been
> fixed, so I think this is it.
>
> There was some delay because I had hoped, after spending the weekend
> and yesterday night hacking on mknetrel, to junk my cygwin-cross tools
> and use mknetrel for p
Jan Nieuwenhuizen wrote:
>
> But what I would like is
>
>apt-get task-cygwin-devel
Exactly. Use the packaging tools native to the platform on which the
binaries will be installed. So, for a debian-hosted, cygwin-target
cross compiler environment: use dpkg/apt-get/whatever. For a Red
Nicholas Wourms wrote:
>> What about picking a directory for extra right now, let's say:
>>
>> /usr/share/mknetrel/extra
>>
>> and have individual packages all unpack their extra script there
>> (maybe even junk most extra's from mknetrel-cvs itself)?
Not yet. Since all of the scripts curren
Nicholas Wourms wrote:
>
> Let keep the conversation about building a cross-compiler automatically
> going. I think CGF is being rather stubborn about it and doesn't see
> the potential benefits for the end user.
No need to be confrontational, Nicholas...
> What probably should happen
Nicholas Wourms <[EMAIL PROTECTED]> writes:
> Let keep the conversation about building a cross-compiler
> automatically going.
Uhm, ok.
> What probably should happen is the build cross environment script
> should be in a separate cvs tree and maintained apart from mknetrel.
It should be not to
Jan Nieuwenhuizen wrote:
>Charles Wilson <[EMAIL PROTECTED]> writes:
>
>
>>If we want to add a "method 3" which is:
>>
>>donwload current mknetrel
>>copy the included script 'pkgname' into mknetrel/extra (*)
>>run mknetrel -b
>>
>>(*) where 'pkgname' is the override script.
>>
>>That would be fin
Jan Nieuwenhuizen wrote:
>Charles Wilson <[EMAIL PROTECTED]> writes:
>
>
>>I think you made the right decision to go ahead with guile for now.
>>You can always release the next version/update of guile using mknetrel
>>if/when it will do what you need.
>>
>
>Ok. It was just that I really wanted t
Jan Nieuwenhuizen wrote:
> Ah, now that would be smart thing to do, why didn't I think of that?
>
> What about picking a directory for extra right now, let's say:
>
>/usr/share/mknetrel/extra
>
> and have individual packages all unpack their extra script there
> (maybe even junk most ext
Hi!
> there is a new GnuPG beta release, GnuPG 1.1.90.
>
> (Here thould be the pointer to that mail in the GnuPG mailing list
> archiv, but since yesterday the website is dead. I will post the link
> when it is up again.)
http://lists.gnupg.org/pipermail/gnupg-devel/2002-July/007372.html
Bye
Charles Wilson <[EMAIL PROTECTED]> writes:
> I think you made the right decision to go ahead with guile for now.
> You can always release the next version/update of guile using mknetrel
> if/when it will do what you need.
Ok. It was just that I really wanted to strive to unite efforts,
esp. aft
Charles Wilson <[EMAIL PROTECTED]> writes:
> If we want to add a "method 3" which is:
>
> donwload current mknetrel
> copy the included script 'pkgname' into mknetrel/extra (*)
> run mknetrel -b
>
> (*) where 'pkgname' is the override script.
>
> That would be fine, too, IMO.
Ah, now that would
And, here, ladies and gentlemen, is the somewhat rarer form of the
cygwin/cygwin-apps confusion where a thread, started in cygwin@cygwin,
is moved to cygwin-apps rather than the other way around.
Are we having fun yet?
cgf
On Tue, Jul 09, 2002 at 10:12:18AM +0200, Lapo Luchini wrote:
>>And roll
Corinna Vinschen wrote:
>On Tue, Jul 09, 2002 at 05:13:00AM -0500, Gary R. Van Sickle wrote:
>
>>setup.hint if you're interested:
>>@ mutt
>>sdesc: "A text mode mail user agent"
>>category: Mail
>>requires: cygwin libncurses6 terminfo libintl1 libiconv2 openssl ssmtp
>>
>
>The setup.hint contains
Jan Nieuwenhuizen wrote:
> Christopher Faylor <[EMAIL PROTECTED]> writes:
>
>
>>On Tue, Jul 09, 2002 at 02:14:16AM +0200, Jan Nieuwenhuizen wrote:
>>
>>> - fixes and preparations for building with libtool
>>>
>>>
>>Sorry, but I don't like this one. Does libtool *really* need to run
>>ld dir
Christopher Faylor <[EMAIL PROTECTED]> writes:
> On Tue, Jul 09, 2002 at 02:14:16AM +0200, Jan Nieuwenhuizen wrote:
>>
>> - fixes and preparations for building with libtool
>>
>
> Sorry, but I don't like this one. Does libtool *really* need to run
> ld directly? That seems ill advised to me.
Hi,
There just one small bugreport on -2, from Chuck, which has been
fixed, so I think this is it.
There was some delay because I had hoped, after spending the weekend
and yesterday night hacking on mknetrel, to junk my cygwin-cross tools
and use mknetrel for packaging Guile, but alas, it appear
Jan Nieuwenhuizen wrote:
> The script is a requirement for Method2, and I'd like to slowly move
> towards that packaging method.
http://www.cygwin.com/setup.html isn't written in stone. If we want to add a "method
3" which is:
donwload current mknetrel
copy the included script 'pkgname'
Christopher Faylor <[EMAIL PROTECTED]> writes:
> On Tue, Jul 09, 2002 at 02:14:37AM +0200, Jan Nieuwenhuizen wrote:
>>
>> - autogenerate cygwin build script: $package.sh
>
> This looks like a prepackage function to me. No need to modify mknetrel.
I think that you do not understand. This will
Christopher Faylor <[EMAIL PROTECTED]> writes:
> On Tue, Jul 09, 2002 at 02:14:54AM +0200, Jan Nieuwenhuizen wrote:
>>
>> - add funtionality to split into and build sub packages
>
> I suspect that this functionality could also be handled with judicious
> use of extra/whatever files.
Sure. All
Jan Nieuwenhuizen wrote:
>
>>That's why I am investigating transitioning us to a cygwin port of
>>cvsnt (no, it's not just for native windows anymore...)
>>
>
> And it does work with emacs' pcvs.el, right?
Dunno. It's based on the cvs code; most of the changes are (a) bugfixes
-- what a con
Charles Wilson <[EMAIL PROTECTED]> writes:
> That's why I am investigating transitioning us to a cygwin port of
> cvsnt (no, it's not just for native windows anymore...)
And it does work with emacs' pcvs.el, right?
> The thing about the ChangeLog stuff, is that it really isn't that
> non-standa
Earnie Boyd <[EMAIL PROTECTED]> writes:
>> >> Btw: A very silly question, but I can't seem to get `cvs diff' to
>> >> respect your (Cygwin's?) wishes of excluding the ChangeLog from
>> >> the diff. It doesn't grok -X,--exclude options, most annoying.
>> >> How do you manage?
>> >>
Jan Nieuwenhuizen wrote:
>
> Hrmm. If you're going to have nonstandard requests, it would be handy
> if these somehow would be handled automagically. How dead is CVS
> development, maybe they would take a patch?
Deader than roadkill, IMO. I think they are in permanennt bugfix only
mode
On Tue, Jul 09, 2002 at 05:13:00AM -0500, Gary R. Van Sickle wrote:
> setup.hint if you're interested:
> @ mutt
> sdesc: "A text mode mail user agent"
> category: Mail
> requires: cygwin libncurses6 terminfo libintl1 libiconv2 openssl ssmtp
The setup.hint contains a dependency to ash so far. Is
Jan Nieuwenhuizen wrote:
>
> Earnie Boyd <[EMAIL PROTECTED]> writes:
>
> >> Btw: A very silly question, but I can't seem to get `cvs diff' to
> >> respect your (Cygwin's?) wishes of excluding the ChangeLog from
> >> the diff. It doesn't grok -X,--exclude options, most annoying.
> >>
Earnie Boyd <[EMAIL PROTECTED]> writes:
>> Btw: A very silly question, but I can't seem to get `cvs diff' to
>> respect your (Cygwin's?) wishes of excluding the ChangeLog from
>> the diff. It doesn't grok -X,--exclude options, most annoying.
>> How do you manage?
>>
>
> Remove th
Jan Nieuwenhuizen wrote:
>
>
> Btw: A very silly question, but I can't seem to get `cvs diff' to
> respect your (Cygwin's?) wishes of excluding the ChangeLog from
> the diff. It doesn't grok -X,--exclude options, most annoying.
> How do you manage?
>
Remove the ChangeLog diff f
On Fri, Jul 05, 2002 at 09:25:29PM +0200, [EMAIL PROTECTED] wrote:
> http://ptsekov.gamersrevolt.it/cygwin/release/mc/mc-4.5.55-1-src.tar.bz2
> http://ptsekov.gamersrevolt.it/cygwin/release/mc/mc-4.5.55-1.tar.bz2
> http://ptsekov.gamersrevolt.it/cygwin/release/mc/setup.hint
Uploaded. Please prep
Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes:
Aarg, copied the original patch, including ChangeLog. Sorry
2002-07-09 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
* bin/mknetrel: Invoke atexit () before exiting.
(atexit): New function.
(drop): New funtion.
(usage): R
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Nicholas Wourms
> Sent: Tuesday, 9 July 2002 8:45 PM
> To: Robert Collins
> Cc: [EMAIL PROTECTED]
> Subject: Re: custom container code now obsolete for setup sources
>
>
> Robert Collins wrote:
>
Christopher Faylor <[EMAIL PROTECTED]> writes:
>> - add debugging feature: drop to shell upon failure
>
> I normally run mknetrel in the background. In fact, I just added a
> couple of options to accommodate this. They would conflict with this
> patch.
Ok.
> If you want to add this function
Robert Collins wrote:
>I've removed all references to the custom container list.h in HEAD. It's now
>STL all the way. There are some minor design regressions for the moment,
>until I find a new balance with some of the differences the STL brings, but
>nothing that affects users (AFAICT).
>
I assu
Christopher Faylor <[EMAIL PROTECTED]> writes:
> I've checked in a modified version of this patch.
Thanks!
> I eliminated some of the wording in the README. Especially the parts
> that say that mknetrel is a cross build tool. Can we lay that one to
> rest now?
Sure. But it's *also* a cross
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Gary R. Van Sickle
> > Sent: Tuesday, 9 July 2002 8:13 PM
>
> > Whew! Now back to my cave for another hundred years ;-).
>
> Heh, well now we have you emailing again... And mutt off your plat
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Gary R. Van Sickle
> Sent: Tuesday, 9 July 2002 8:13 PM
> Whew! Now back to my cave for another hundred years ;-).
Heh, well now we have you emailing again... And mutt off your plate
Howabout
Charles Wilson wrote:
>
>
> Christopher Faylor wrote:
>
>> On Tue, Jul 09, 2002 at 02:14:54AM +0200, Jan Nieuwenhuizen wrote:
>>
>>> - add funtionality to split into and build sub packages
>>>
>>
>> I suspect that this functionality could also be handled with judicious
>> use of extra/whatever f
After much too long, I've finally got a build of the latest Mutt patched and
packaged up:
Page:
http://home.att.net/~g.r.vansickle/cygwin_packages/mutt-1.4-1/
Direct Links:
http://home.att.net/~g.r.vansickle/cygwin_packages/mutt-1.4-1/mutt-1.4-1-src.tar
.bz2
http://home.att.net/~g.r.vansickle/cy
> And roll your own "IvoWin". (Remember, tho, cygwin is GPL; therefore
> IvoWin will be GPL and you must make the source code available to
> whomever you give the binary. Ditto for your app - but that's already
> true for your app, since it currently links to cygwin itself)
The app can in f
>
>
>>I don't know yacc format enough to extract that information myself from
>>iniparse.y.
>>But... steange inilex.l doesn't contain a token for "version:"... I
>>guess I must study it a bit more.
>>
>>
>[vV]"ersion:" return PACKAGEVERSION;
>
Do you accidentally know where is the ne
Hi,
there is a new GnuPG beta release, GnuPG 1.1.90.
(Here thould be the pointer to that mail in the GnuPG mailing list
archiv, but since yesterday the website is dead. I will post the link
when it is up again.)
I used the new sources and also changed the loadable module / library
generation of
72 matches
Mail list logo