Re: [9fans] Software preservation in the post-hg era
It's worth highlighting the fact that Bitbucket will be deleting *all* hg repositories on May 30, 2020. Thankfully, the Software Heritage ( https://www.softwareheritage.org/) seems to be doing a great job of archiving all open source work. For example: https://archive.softwareheritage.org/browse/origin/https://bitbucket.org/inferno-os/inferno-os/directory/ I don't know how much they have archived or how up-to-date it is. It's worth converting repos to git anyway, especially if we want to continue maintaining them. On Mon, Mar 30, 2020 at 9:11 PM Sean Hinchee wrote: > In the wake of Bitbucket removing hg (Mercurial) support [1], I feel > it's topical to bring up software preservation for the plan9 > community. > > A lot of community contributed software has been put up on Bitbucket > or other hg hosts over time (RIP Google Code), but no consolidated > effort, to my knowledge, seems to have been made to index, let alone > mirror, this software. > > For now, as a stop-gap, I've made a GitHub organization in which I've > consolidated most of what I had indexed from Bitbucket and a few other > places. > > Thanks to people like Ori Bernstein, we have a native git client for > plan9 [3]; without a native client, this kind of transition wouldn't > be nearly as simple, thank you. > > I'm more than happy to add anyone interested in the curation of this > archive to the GitHub organization. It would be nice to have spare > hands around to add README's, mkfiles, and attributions where they > have been missed or never existed. > > In the long term, it would be nice to have a federated or otherwise > decentralized solution to pooling community contributed software, > especially keeping in mind ease of mirroring and picking up old > projects as contributors come and go. > > The contrib/ directory on sources and 9front are fine and good, but > they are centralized. I don't have a proposed solution to this > problem, but it would be nice to have ideas or insight posted ☺. > > I recognize that GitHub is also centralized and doesn't solve the > centralization problem, but at least git is really straightforward to > mirror with multiple remotes, etc. and having an index/archive is > valuable at least to me. > > If anyone has further thoughts, anything they want added, or any lists > or indices of works they want archived/mirrored, I would love to see > these posted. > > If anyone wants to mirror the archive, that would be wonderful. I was > considering mirroring everything to a remote in sr.ht in the future, > but haven't gotten around to it. > > As a footnote, there's a decent git client written in Go that works > alright on plan9 [4], but it's slow and memory intensive at the > moment. > > Cheers, > Sean > > [1] https://twitter.com/traverser/status/1244398479591563265 > [2] https://github.com/Plan9-Archive > [3] https://github.com/oridb/git9 > [4] https://github.com/driusan/dgit -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T303744e1ec6d2108-M3889534780ac09733b7bf1cd Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] macOS drawterm audio
All, Wanted to reach out before I started doing any work on this, but does anyone have existing code for a devaudio-macos.c for drawterm? I see win32 and unix have working audio. If anyone has something out there they have started that I can use, would be greatly appreciated. I am willing to take a stab at it, but just wanted to check before I went down this rabbit hole. If not... I think I can bang it out. Doesn't seem too difficult. I need audio! Tony -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tfe03295f479d4dad-M6ff0f0be4cf446bf5cd301fb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Software preservation in the post-hg era
On Tue, Mar 31, 2020 at 8:38 PM Dave MacFarlane wrote: > > On Tue, Mar 31, 2020 at 10:46 AM wrote: > > > If anyone has further thoughts, anything they want added, or any lists > > > or indices of works they want archived/mirrored, I would love to see > > > these posted. > > > > I think the lede got buried here, and people went of discussing git > > clients. > > > > Given that the aptly-named bitbucket is deleting mercurial repositories, > > is there anything of interest that should be retrieved before they empty > > the bitbucket onto the curb? > > > > Is Inferno already mirrored? If https://github.com/Plan9-Archive/inferno-os is the one then yes. There are multiple other forks of Inferno there. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T303744e1ec6d2108-Mb217461f21ece2f1e8125545 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Software preservation in the post-hg era
Thanks for doing this. Please add me (jxy) to the GitHub org. I plan to maintain drawterm-metal so long as I'm using it. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T303744e1ec6d2108-Mb35e89ba494b39cee28abc84 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Software preservation in the post-hg era
On Tue, Mar 31, 2020 at 10:46 AM wrote: > > If anyone has further thoughts, anything they want added, or any lists > > or indices of works they want archived/mirrored, I would love to see > > these posted. > > I think the lede got buried here, and people went of discussing git > clients. > > Given that the aptly-named bitbucket is deleting mercurial repositories, > is there anything of interest that should be retrieved before they empty > the bitbucket onto the curb? > Is Inferno already mirrored? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T303744e1ec6d2108-M8ffeabfca5531d4d9caffcb1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Software preservation in the post-hg era
On 3/31/20, o...@eigenstate.org wrote: > > I think the lede got buried here, and people went of discussing git > clients. > Entirely your fault: that's the thanks you get for doing such a good job. Lucio. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T303744e1ec6d2108-M76529bf4c6408c5c3b474d4f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Software preservation in the post-hg era
> If anyone has further thoughts, anything they want added, or any lists > or indices of works they want archived/mirrored, I would love to see > these posted. I think the lede got buried here, and people went of discussing git clients. Given that the aptly-named bitbucket is deleting mercurial repositories, is there anything of interest that should be retrieved before they empty the bitbucket onto the curb? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T303744e1ec6d2108-M43dd6e182ede2169dd8b55b7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] iOS drawterm
On Tue, Mar 31, 2020, at 9:52 AM, yy wrote: > > In case there is any interest, I would be glad of helping to port > devwsys: https://bitbucket.org/yiyus/devwsys-prev/src/default/ > > Even if the goal is to have drawterm, this may be an easier middle > step, since it would allow you to get something working first, and > later you could use the same devices from drawterm. indeed. it could be bound to drawterm -G if android or ios lets them talk to each other. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T69dec3540d033863-Ma2f61c291706a0ac44c1c18c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] iOS drawterm
On Wed, 25 Mar 2020 at 07:40, Anthony Sorace wrote: > > With iOS getting first-class mouse pointer support, I’m looking at the iOS > drawterm port again. Has anyone touched this since the old GSoC project bit > rotted out? > In case there is any interest, I would be glad of helping to port devwsys: https://bitbucket.org/yiyus/devwsys-prev/src/default/ Even if the goal is to have drawterm, this may be an easier middle step, since it would allow you to get something working first, and later you could use the same devices from drawterm. -- - yiyus || JGL . -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T69dec3540d033863-M46cb79d3280452323f2ab0d7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Git and heritage (Was: Software preservation in the post-hg era)
On 3/31/20, Sean Hinchee wrote:
> [ ... ]
> For now, as a stop-gap, I've made a GitHub organization in which I've
> consolidated most of what I had indexed from Bitbucket and a few other
> places.
>
> Thanks to people like Ori Bernstein, we have a native git client for
> plan9 [3]; without a native client, this kind of transition wouldn't
> be nearly as simple, thank you.
>
Ori's git9 is working better than adequately, although I tend to get
tangled up in its interface a lot. Which brings me to submit my
"enhancements" to 9front's "cmd/ssh.c"; these allow the Git URLs (a
subspecies, if my Git Bible is to go by) to be handled a little more
familiarly.
Quite correctly, Cinap, no doubt others, pointed out that Plan 9 has a
different representation for network addresses, one that seems better
designed. The change I applied to ssh.c does nothing to limit use of
the Plan 9 addressing style, it merely adds features that *do* belong
in the SSH context. The price is minimal: conflicting address
components may be supplied and something may break as a result, but
the expectation is that such breakage would be under interactive
supervision.
What I think swings the balance entirely in favour of adding the
enhancements is that Git likes to write URLs to the .git/config file
and as a result using Plan 9 addresses does make the config file
incompatible between Git as she is spoke and Plan 9's alternative. I
don't know about anyone else, but I live in a hybrid environment and I
fear this will bite me or someone I care about unnecessarily.
With the ssh.c enhancements and very minor tweaks to git9/proto.c (so
minor I'm having trouble finding them), one at least is able to avoid
incompatibilities (well, I'm hoping so).
I've attached the two patch sets, I make no claim to being a great
coder, the focus was to make the changes (a) as clear as possible, (b)
as unintrusive as possible.
The copy of 9front "ssh.c" I based my changes on may not be the most recent.
There's more to be said about converging the various Plan 9 flavours,
I continually find cause to regret the paths that have been chosen;
even though I am a faithful follower of the legacy system, I
appreciate divergence when it causes Plan 9 on my desktop to
interoperate better with the Posix and Posix-like systems I have
reason to use. But I think the convergence tool chest lies with Ori's
git9 and I would really like to assist making it not just robust, but
irresistible.
For that, my aim is to make it portable across all 9-flavours, very
much including p9p. I see no reason not to migrate to git9 everywhere
from the lesser Git ;-)
Lucio.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T0cc6edbc13d3e92c-M9d35345d18bae23e2a9d30e2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
% ape/diff -p ssh.c /n/dump/2020/0202/9front/sys/src/cmd/ssh.c
*** ssh.c Sun Feb 2 08:34:12 2020
--- /n/dump/2020/0202/9front/sys/src/cmd/ssh.c Sat Oct 28 18:57:42 2017
*** uchar sid[256];
*** 81,87
char thumb[2*SHA2_256dlen+1], *thumbfile;
int fd, intr, raw, debug;
! char *user, *service, *status, *host, *port, *cmd;
Oneway recv, send;
void dispatch(void);
--- 81,87
char thumb[2*SHA2_256dlen+1], *thumbfile;
int fd, intr, raw, debug;
! char *user, *service, *status, *host, *cmd;
Oneway recv, send;
void dispatch(void);
*** kfmt(Fmt *f)
*** 1133,1139
void
usage(void)
{
! fprint(2, "usage: %s [-dR] [-t thumbfile] [-T tries] [-u user] [-h] [-p port] [user@]host[:port] [cmd args...]\n", argv0);
exits("usage");
}
--- 1133,1139
void
usage(void)
{
! fprint(2, "usage: %s [-dR] [-t thumbfile] [-T tries] [-u user] [-h] [user@]host [cmd args...]\n", argv0);
exits("usage");
}
*** main(int argc, char *argv[])
*** 1157,1171
case 'd':
debug++;
break;
- case 'h':
- host = EARGF(usage());
- break;
- case 'p':
- port = EARGF(usage());
- break;
case 'R':
raw = 0;
break;
case 't':
thumbfile = EARGF(usage());
break;
--- 1157,1171
case 'd':
debug++;
break;
case 'R':
raw = 0;
break;
+ case 'u':
+ user = EARGF(usage());
+ break;
+ case 'h':
+ host = EARGF(usage());
+ break;
case 't':
thumbfile = EARGF(usage());
break;
*** main(int argc, char *argv[])
*** 1173,1181
MaxPwTries = strtol(EARGF(usage()), , 0);
if(*s != 0) usage();
break;
- case 'u':
- user = EARGF(usage());
- break;
} ARGEND;
if(host == nil){
--- 1173,1178
*** main(int argc, char *argv[])
*** 1192,1205
host = s;
}
}
- if(port == nil){
- port = "ssh";
- s = strchr(host, ':');
- if(s != nil){
- *s = '\0';
- port = s+1;
- }
- }
for(cmd = nil; *argv != nil; argv++){
if(cmd == nil){
--- 1189,1194
*** main(int argc, char *argv[])
*** 1212,1218
