Timo Myyrä wrote:
> Seems the changing the chicken binary is pretty trivial so let's go
> with it. New binary names also line up nicely with other binaries.
Since csi has been a CHICKEN command since 2000, and a command with the
same name was (as far as I can tell) only added to Mono this year,
wo
Jason Valencia wrote:
> Tiny system info for Unix-like operating systems written in POSIX
> shell, along the lines of screenfetch and neofetch.
Can someone test this port and let me know if it works alright for you?
--
Jason
ufetch.tar.gz
Description: application/tar-gz
> Tiny system info for Unix-like operating systems written in POSIX
> shell, along the lines of screenfetch and neofetch.
Jason Valencia wrote:
> Brian Callahan wrote:
> > Still not sure why you have an aversion to hosting your own tarball,
> > seeing as two developers (at
Brian Callahan wrote:
> Still not sure why you have an aversion to hosting your own tarball,
> seeing as two developers (at least on the mailing lists) have asked
> you to do so.
I've thrown up a tarball. Here's an updated version of the port. Let me
know if there are any issues.
--
Jason
ufetc
Brian Callahan wrote:
> > OK?
>
> Still not sure why you have an aversion to hosting your own tarball,
> seeing as two developers (at least on the mailing lists) have asked
> you to do so.
For the same reasons I didn't want to maintain it. Maintaining a mirror
takes time and upkeep I don't want to
Attached is a newer version addressing some of your comments.
> 2018.07.21-git is not a valid version number.
I've changed the version from 2018.07.21-git to 2018.07.18, dropping
-git and moving the date to the latest change made to any of the files
used in this port.
I contacted upstream about t
francisc.si...@evalgo.org wrote:
> What are the next steps, what should I do to bring it into the ports
> tree?
The normal way it to make a gzipped tarball of the port and send it to
this list (ports@). To do that, go to the directory containing the port
and run some variation of:
$ tar -czf nng.t
Alessandro DE LAURENZIS wrote:
> just noticed that I'm no more able to fetch tarballs for ports
> relying on github's on-the-fly archive creation...
I have the same issue for all the ports that I tried, so this appears
to be on GitHub's end.
Stuart Henderson wrote:
> Gitlab still builds tars on the fly doesn't it, even with tags? (So
> they may change later and fail distinfo checks). Self hosting, or
> adding upstream to upload a tar somewhere, would be better.
I think so. But since we really only need two text files, we can
download d
Tiny system info for Unix-like operating systems written in POSIX
shell, along the lines of screenfetch and neofetch.
Tested on i386, though that should not make any difference as it is
architecture-independent.
ufetch.tar.gz
Description: application/tar-gz
10 matches
Mail list logo
