[Libre-soc-dev] Getting an SSH access to the repositories

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Mon, Jul 12, 2021 at 10:44 PM Dmitry Selyutin
<dmitry.selyutin at 3mdeb.com> wrote:
>
> On 7/12/21 11:37 PM, Luke Kenneth Casson Leighton wrote:
> > see HDL_workflow: mailing list != editable document store :)
> >
> > for things that might need action: bugtracker
> >
> > for info that is repeated and important: wiki
> >
> > for automated stuff that makes stuff: git repos
> It's libreriscv.git repository, right?

yes.

> I've managed to clone this
> repository; if this is the right choice, I'll try updating the docs
> tomorrow.

go for it.  if you prefer you can use the ikiwiki web frontend.
as a test do create a user page (see lkcl.mdwn as a template).

btw do bear in mind we use ikiwiki "underlays" - some of the
pages are auto-generated.  so you will see they exist on the
main website but do *not* exist in the git repo: that's because
they're sourced automatically from a completely separate
location, during the static HTML build.

> OK, I installed it. Given that there are several dependencies which
> revealed as optional, perhaps it's worth listing those explicitly at HDL
> workflow page?

good idea.

> I'm neither Oracle's nor VirtualBox' lover. :-) This is simply the thing
> I sporadically used before, and therefore it was the most obvious
> choice, speaking of "least surprise principle".

yeah if you've got it, and it works, it saves time and saves learning
something else, go for it.

> That said, I've never
> been doing anything complex there, so perhaps this is the only reason
> I've not met problems. Actually I've been thinking of some kind of
> container instead, so that all dependencies are already installed.

which means someone has to build and maintain them, and make
them available for download, which in turn increases the resources
needed on the server by an order of magnitude, and i'm paying
for them.

> OTOH,
> it's really useful for a newcomer to understand the pieces the project
> consists of, so perhaps having a container would make the overall
> picture somewhat inaccurate and vague. On pros, this might help getting
> a reproducible build (but don't take that for granted, it's always a
> headache to make it working, I'm not signing under these words!).

if we were going any route it would likely be NIX (because it's a
project supported by NLnet).

> > try "pacman install debootstrap" (pacman -S debootstrap?)
> >
> > then use that (manually), then under *that* chroot run the devscripts.
> >
> > chroot in a chroot, i know.
> Perhaps it's worth a try; I'm only concerned that this pathetic virtual
> HDD I made (already containing sources and dependencies) would then
> become useless.

i usually fix that one by making the virtual HDD externally mountable,
(rather than "formatted with a proprietary tool" or in a "faster" format).

> Also, I'm afraid that this configuration is not
> "blessed", and that at some point Arch would make piss me off due to
> being non-Debian. I'm really thinking of containers again... but
> generally I consider the containers to be the ultimate resort, that is,
> only if the project is that complex that it cannot live without the
> "dockers" anymore. Anyway, could we go with VirtualBox setup for now?

yeah it's entirely your choice, there.

> At
> least most of guidelines has already been completed with that thing, and
> perhaps we can make it work (at least for a while).

yehyeh.

> > there's always dokkkaah. *shudder*.
> Kinda quintessence of the overall IT... It's always a trade-off between
> simplicity for newcomers and, well, container hell. :-)

dokkkkah is a particular kind of hell, having zero stability in the config
files.  one minute you have configs that worked, the next minute,
after an automatic update, you don't.  and tough f***** s*** if you
have something that *critically depended* on a specific version of
dokkkaa.

yeah, you can tell i'm not impressed, which is why we went with
schroot.  i have about 5, one of which i had to use to install
klayout: it wouldn't build on debian/testing (6 weeks ago).

l.