Orphaning fzf

Orphaning fzf

[Adam Dinwoodie]

The upstream fzf package moved from Ruby to Go some time ago.  I had
vague but noble intetions to try to maintain a fork on the basis of the
last version of the Ruby code, but never managed anything useful.  In
that context, I expect it's time that I officially throw in the towel,
and mark fzf as orphaned.

The existing build still works, and I don't think there's likely to be
any crass security problems or anything like that.  But there's no
longer any upstream support, and I clearly don't have the capacity to
properly maintain it solo.

I'm not quite sure what the process is here, but I suspect it's just a
case of someone with the appropriate access making an update to
https://cygwin.com/cygwin-pkg-maint

Adam

Re: Orphaning fzf

[Corinna Vinschen]

On Feb  1 21:22, Adam Dinwoodie wrote:
> The upstream fzf package moved from Ruby to Go some time ago.  I had
> vague but noble intetions to try to maintain a fork on the basis of the
> last version of the Ruby code, but never managed anything useful.  In
> that context, I expect it's time that I officially throw in the towel,
> and mark fzf as orphaned.
> 
> The existing build still works, and I don't think there's likely to be
> any crass security problems or anything like that.  But there's no
> longer any upstream support, and I clearly don't have the capacity to
> properly maintain it solo.
> 
> I'm not quite sure what the process is here, but I suspect it's just a
> case of someone with the appropriate access making an update to
> https://cygwin.com/cygwin-pkg-maint

Done.


Thanks,
Corinna

Go or Rust Packages?

[Brian Inglis]

On 2022-02-02 02:44, Corinna Vinschen wrote:
> On Feb  1 21:22, Adam Dinwoodie wrote:
>> The upstream fzf package moved from Ruby to Go some time ago.  I had
>> vague but noble intetions to try to maintain a fork on the basis of the
>> last version of the Ruby code, but never managed anything useful.  In
>> that context, I expect it's time that I officially throw in the towel,
>> and mark fzf as orphaned.
>>
>> The existing build still works, and I don't think there's likely to be
>> any crass security problems or anything like that.  But there's no
>> longer any upstream support, and I clearly don't have the capacity to
>> properly maintain it solo.
>>
>> I'm not quite sure what the process is here, but I suspect it's just a
>> case of someone with the appropriate access making an update to
>> https://cygwin.com/cygwin-pkg-maint

Anyone know of anyone trying to build Go or Rust on Cygwin?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: Go or Rust Packages?

[Marco Atzeri]

On 04.02.2022 06:27, Brian Inglis wrote:
> On 2022-02-02 02:44, Corinna Vinschen wrote:
>> On Feb  1 21:22, Adam Dinwoodie wrote:
>>> The upstream fzf package moved from Ruby to Go some time ago.  I had
>>> vague but noble intetions to try to maintain a fork on the basis of the
>>> last version of the Ruby code, but never managed anything useful.  In
>>> that context, I expect it's time that I officially throw in the towel,
>>> and mark fzf as orphaned.
>>>
>>> The existing build still works, and I don't think there's likely to be
>>> any crass security problems or anything like that.  But there's no
>>> longer any upstream support, and I clearly don't have the capacity to
>>> properly maintain it solo.
>>>
>>> I'm not quite sure what the process is here, but I suspect it's just a
>>> case of someone with the appropriate access making an update to
>>> https://cygwin.com/cygwin-pkg-maint
> 
> Anyone know of anyone trying to build Go or Rust on Cygwin?
> 

I looked some time ago on Go.

As it is written in go, you need to go back to the oldest version
written in C and from them forward to the current version.

But looking inside the code/build system I saw a lot of hack and 
conditional.
Nothing that looks like a test for functionality, just a lot of
assumption on the system.

It will require a lot of time IMHO, but I am not an expert in compilers

Regards
MArco

Re: Go or Rust Packages?

[Mark Geisert]

Brian Inglis wrote:
> On 2022-02-02 02:44, Corinna Vinschen wrote:
>> On Feb  1 21:22, Adam Dinwoodie wrote:
>>> The upstream fzf package moved from Ruby to Go some time ago.  I had
>>> vague but noble intetions to try to maintain a fork on the basis of the
>>> last version of the Ruby code, but never managed anything useful.  In
>>> that context, I expect it's time that I officially throw in the towel,
>>> and mark fzf as orphaned.
>>>
>>> The existing build still works, and I don't think there's likely to be
>>> any crass security problems or anything like that.  But there's no
>>> longer any upstream support, and I clearly don't have the capacity to
>>> properly maintain it solo.
>>>
>>> I'm not quite sure what the process is here, but I suspect it's just a
>>> case of someone with the appropriate access making an update to
>>> https://cygwin.com/cygwin-pkg-maint
> 
> Anyone know of anyone trying to build Go or Rust on Cygwin?
I made some progress with Go on Cygwin a couple years ago, but had to give up 
because it required more time than I could give it.  I got about 1/3 of the way 
through it.  The last straw was its need for syscall?() and Cygwin not having 
those functions (or a need for them).  It was a lot of looking for "#ifdef 
Windows" and usually adding "&& !defined(__CYGWIN__)".  The goal still tantalizes 
though...

I don't think anybody has mentioned a need for Rust on Cygwin before.  That might 
be easier because of a simpler runtime than Go, but still a major, major project.

..mark

Re: Go or Rust Packages?

[Corinna Vinschen]

On Feb  4 00:14, Mark Geisert wrote:
> Brian Inglis wrote:
> > On 2022-02-02 02:44, Corinna Vinschen wrote:
> > > On Feb  1 21:22, Adam Dinwoodie wrote:
> > > > The upstream fzf package moved from Ruby to Go some time ago.  I had
> > > > vague but noble intetions to try to maintain a fork on the basis of the
> > > > last version of the Ruby code, but never managed anything useful.  In
> > > > that context, I expect it's time that I officially throw in the towel,
> > > > and mark fzf as orphaned.
> > > > 
> > > > The existing build still works, and I don't think there's likely to be
> > > > any crass security problems or anything like that.  But there's no
> > > > longer any upstream support, and I clearly don't have the capacity to
> > > > properly maintain it solo.
> > > > 
> > > > I'm not quite sure what the process is here, but I suspect it's just a
> > > > case of someone with the appropriate access making an update to
> > > > https://cygwin.com/cygwin-pkg-maint
> > 
> > Anyone know of anyone trying to build Go or Rust on Cygwin?
> I made some progress with Go on Cygwin a couple years ago, but had to give
> up because it required more time than I could give it.  I got about 1/3 of
> the way through it.  The last straw was its need for syscall?() and Cygwin
> not having those functions (or a need for them).  It was a lot of looking
> for "#ifdef Windows" and usually adding "&& !defined(__CYGWIN__)".  The goal
> still tantalizes though...

You might be better off writing a syscall layer which translates the
expected syscalls into standard POSIX API calls.  Cygwin could even
provide that in the long run.

Ages ago we discussed converting cygwin1.dll to cygwin2.dll and only
export a syscall interface with any arbitrary libc on top (e. g. glibc),
but that would have been a near full re-implementation of Cygwin, so we
buried the idea.  However, providing a syscall layer on top might be a
nice extension.


Corinna

Re: Go or Rust Packages?

[Jan Nijtmans]

Op vr 4 feb. 2022 om 07:58 schreef Marco Atzeri:
> As it is written in go, you need to go back to the oldest version
> written in C and from them forward to the current version.

There's also a "golang" frontend for gcc.  Could that be used
to bootstrap go?

Regards,
       Jan Nijtmans

Re: Go or Rust Packages?

[Marco Atzeri]

On 04.02.2022 10:23, Jan Nijtmans wrote:
> Op vr 4 feb. 2022 om 07:58 schreef Marco Atzeri:
>> As it is written in go, you need to go back to the oldest version
>> written in C and from them forward to the current version.
> 
> There's also a "golang" frontend for gcc.  Could that be used
> to bootstrap go?
> 
> Regards,
>         Jan Nijtmans

no idea.

I leave the question to the GCC experts: Achim Gratz/Jonathan Yong

Re: Go or Rust Packages?

[ASSI]

Marco Atzeri writes:
> As it is written in go, you need to go back to the oldest version
> written in C and from them forward to the current version.

No you don't.  Upstream opines that they already support Windows and
Linux and thusly do not need Cygwin.  The details vary, but Rust climbed
up the same tree.

Go might be salvageable if the go frontend to go is usable, I haven't
had time to look at that.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Go or Rust Packages?

[Achim Gratz]

ASSI writes:
> Go might be salvageable if the go frontend to go is usable, I haven't
> had time to look at that.

I've went ahead and tried to activate go in gcc and it doesn't even get
past the very beginning of confdigure:

--8<---------------cut here---------------start------------->8---
configure: WARNING: go not supported for this target
configure: error: 
The following requested languages could not be built: go
--8<---------------cut here---------------end--------------->8---

Pulling out this and another stop successfully configures and actually
builds a gccgo executable sometime later.  If any of this actually works
remains to be seen.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: Go or Rust Packages?

[Achim Gratz]

Achim Gratz writes:
> Pulling out this and another stop successfully configures and actually
> builds a gccgo executable sometime later.  If any of this actually works
> remains to be seen.

The compiler itself seems to be working (for some definition of
working), but the compilation of libgo fails at some point:

--8<---------------cut here---------------start------------->8---
make[4]: Entering directory '/mnt/share/packages/gcc/gcc.x86_64/build/x86_64-pc-cygwin/libgo'
/usr/bin/mkdir -p os/signal/internal; files=`echo  | sed -e 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile /mnt/share/packages/gcc/gcc.x86_64/build/./gcc/gccgo -B/mnt/share/packages/gcc/gcc.x86_64/build/./gcc/ -B/usr/x86_64-pc-cygwin/bin/ -B/usr/x86_64-pc-cygwin/lib/ -isystem /usr/x86_64-pc-cygwin/include -isystem /usr/x86_64-pc-cygwin/sys-include   -fchecking=1  -minline-all-stringops  -O2 -g -I . -c -fgo-pkgpath=`echo os/signal/internal/pty.lo | sed -e 's/.lo$//'`  -o os/signal/internal/pty.lo $files
libtool: compile:  /mnt/share/packages/gcc/gcc.x86_64/build/./gcc/gccgo -B/mnt/share/packages/gcc/gcc.x86_64/build/./gcc/ -B/usr/x86_64-pc-cygwin/bin/ -B/usr/x86_64-pc-cygwin/lib/ -isystem /usr/x86_64-pc-cygwin/include -isystem /usr/x86_64-pc-cygwin/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=os/signal/internal/pty  -DDLL_EXPORT -o os/signal/internal/.libs/pty.o
gccgo: fatal error: no input files
compilation terminated.
make[4]: *** [Makefile:3001: os/signal/internal/pty.lo] Error 1
--8<---------------cut here---------------end--------------->8---

Since this is in the os subtree my guess is that this happens due to the
non-recognition of Cygwin somewhere else.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds