IRC channel logs

2022-01-17.log

back to list of logs

<bauen1>seems like somebody is on the tinycc devel mailing list asking about musl support if anyone here wants to chime in there
<alMalsamo>Hi all, I was trying to find the source code to Gash and gash-utils and all I could find were tarballs a couple years old: http://download.savannah.nongnu.org/releases/gash/
<alMalsamo>Is there a VCS repo for these projects with more recent code?
<oriansj>alMalsamo: well I know janneke worked on it some: https://gitlab.com/janneke/gash/-/tree/gash-core-utils and https://gitlab.com/janneke/gash
<oriansj>but yeah, it looks like they stopped working on it for some reason
<oriansj>it is very possible they achieved the level of functionality they desired.
<alMalsamo>oriansj: Hmm on the first link when I click clone to find the URL to clone with git it only has the URL for the gash repo not gash-core-utils
<alMalsamo>I was able to clone gash fine though, but I would like to also clone gash-core-utils but I can't find the repo URL for that...?
<pabs3>alMalsamo: gash-core-utils seems to be a branch, not a repo. so clone gash then checkout the gash-core-utils branch
<alMalsamo>pabs3: Hmm I am a newb sorry, I cloned gash already so does that mean I have the gash-core-utils branch already downloaded? Or do I need to run a seperate git command for that branch?
<pabs3>alMalsamo: sorry for the delay. do this: git clone https://gitlab.com/janneke/gash.git ; cd gash ; git checkout gash-core-utils
<pabs3>then to go back to the main branch: git checkout master
<alMalsamo>pabs3: Hmm okay so both branches are stored locally on disk after the inital clone? Where are the files for gash-core-utils branch stored on the filesystm when I am in master branch? Are the stashed away in Git index files?
<alMalsamo>Is there no way to have both branches available to explore on my filesystem simultaneously?
<janneke>alMalsamo: gash and gash-utils from savannah are the latest versions
<janneke> https://git.savannah.nongnu.org/git/gash.git
<janneke>
<janneke> https://git.savannah.nongnu.org/git/gash/gash-utils.git
***ChanServ sets mode: -o janneke
<janneke>development will hopefully pick-up some steam again this year
<alMalsamo>janneke: Are these currently used to bootstrap Guix if I want to bootstrap from source with as little binaries as possible?
<alMalsamo>The last time I installed Guix was 2015 and Mes and Gash didn't exist yet...
<janneke>alMalsamo: for what's currently being used, see: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/commencement.scm#n141
<janneke>and https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/shells.scm#n870
<janneke>i.e., gash-0.2.0 and gash-utils-0.1.0
<janneke>note that these run on Guile
<alMalsamo>Hmm why are these git repos not available from the page: https://savannah.nongnu.org/projects/gash/
<pabs3>alMalsamo: they are, see https://savannah.nongnu.org/git/?group=gash
<pabs3>alMalsamo: re the branch question, you can either clone twice or use the git worktree command https://git-scm.com/docs/git-worktree
<doras>So regarding live-bootstrap, is the long-term plan to continue using the sysa build products as the base for sysc?
<doras>By that I mean that sysc is currently sysa + additional build products, if I understood things correctly. It's not its own sysroot which gets built from-scratch using sysa.
<doras>I created the following PR with (almost) all the changes I needed to bootstrap sysa using BuildStream: https://github.com/fosslinux/live-bootstrap/pull/144
<doras>I have some additional changes that aren't ready yet. Some related to sysc and some related to bootstrapping only sysa (and only sysc). However, I'm fairly confident about the changes above, so I'd rather merge them already if possible.
<stikonas[m]>doras: sysc only needs sysa products
<stikonas[m]>What else did you think was used?
<stikonas[m]>else we would need some additional seed from somewhere
<doras>stikonas: if I recall correctly, kaem is also part of sysc and most like other build products which are leftovers from sysa.
<doras>most likely*
<stikonas[m]>Yeah, they are leftovers from sysa
<stikonas[m]>Būt all bootsrapped there
<doras>Yes, all build products are bootstrapped from the seed, but sysc is technicall sysa + additional build products, and not a complete sysroot that stands on its own.
<stikonas[m]>Well build products of sysa
<stikonas[m]>I was calling that sysa...
<doras>And with that approach it's a bit hard to tell which patched/hacked around products were accidentally left there.
<stikonas[m]>Yes, that's true
<stikonas[m]>I guess the best way to consume sysc is to build a new toolchain that you need and that has no old cruft
<stikonas[m]>Or implement "binary packages" in live-boostrap
<stikonas[m]>Which would be useful for keeping things neat and tidy
<stikonas[m]>So that we can e.g. clearly separate outputs of each build step from rest of file system
<stikonas[m]>That's not possible in early sysa stages though...
<stikonas[m]>But by the time we reach sysc we have more than enough tools
<doras>Yes, this was my thought as well.
<clemens3>stikonas: hi, got more diskspace in the vm and back to base setup, trying rust 1.39.0, it installed bunch of packages and then complained that not the right llvm version was available.. is that normal? started with: emerge =dev-lang/rust-1.39.0
<stikonas>clemens3: hmm, maybe paste the whole error message. That doesn't sound normal
<stikonas>it should use vendored llvm
<clemens3>looked like it tries some old llvm
<clemens3>do i need to install standard llvm myself first?
<clemens3>it says "No LLVM slot satisfying the package's dependencies found installed!"
<clemens3>but does not say which version it expects
<clemens3>is just normal gentoo llvm like 13?
<clemens3>vendored means gentoo or your overlays?
<stikonas>clemens3: no, rust tarball contains llvm
<clemens3>hmm
<stikonas>it's much older llvm there
<clemens3>so vendor is overlay, ok
<clemens3>letme see if i find log with details
<stikonas>well, it's not even overlay, it's inside rust itself
<clemens3>i had just fresh gentoo install without desktop
<stikonas>but, it's not from the system
<clemens3>layman -L
<clemens3>layman -a and then emerge rust 1.39
<stikonas>well, maybe something did break in my ebuilds too, I haven't used them for a while
<stikonas>looks like end of april for rustc-1.39...
<clemens3>lemme look at log, found it
<clemens3>yeah, lots of updates i guess around
<clemens3>stikonas: i got the build log, but does not say more, only detail is: the specific snipet of code: die "No LLVM slot${1:+ <= ${1}} satisfying the package's dependencies found installed!"
<clemens3>seems something with brackets/substitution went wrong?
<stikonas>hmm, that is strange...
<stikonas>I don't do any substitution in that ebuild
<stikonas>and this is definitely coming from rustc-1.39?
<stikonas>DEPENDS only has cmake and time for that ebuild...
<stikonas>so I'm a bit confused where that error is coming from
<clemens3>yeah, build log was in /var/tmp/portage/dev-lang/rust-1.39.0/temp
<stikonas>well, this might be a hack but what happens if you run emerge --nodeps ...
<stikonas>make sure you have cmake and time installed first
<clemens3>immediately same error
<clemens3>i think cmake and time installed before as dependency already
<stikonas>hmm, hard to test here on non-empty system with rust dependencies :(
<clemens3>no problem, let it rest a bit, maybe later get some idea
<stikonas>no, I don't think I can reproduce it
<stikonas>seems fine here
<clemens3>hmm
<stikonas>if I do "sudo emerge -a1 =dev-lang/rust-1.39.0 --nodeps" it goes on and starts compiling mrustc
<clemens3>lemme see how big the cow immage is
<clemens3>i try same line
<clemens3>had emerge --nodeps -dev...
<clemens3>no, same...
<clemens3>i am using root user
<stikonas>well, root user doesn't matter
<stikonas>sudo would do the same thing
<stikonas>hmm, do you have any version of llvm installed?
<stikonas>in case something somewhere checks that
<clemens3>yeah.. my vm is 10 gb..
<clemens3>otherwise fresh setup
<stikonas>hmm...
<stikonas>no idea...
<clemens3>anyway, maybe not today.. but is an option i let you download my qemu
<clemens3>image
<clemens3>only root user with some dummy password
<stikonas>well, see first if you can figure it out...
<stikonas>if not then we can try that at some point
<clemens3>yeah.. day by day..
<stikonas>ok, I foudn at least where it comes from
<clemens3>cool
<stikonas> https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/llvm.eclass#n180
<stikonas>although not sure why I don't trigger that code-path
<clemens3>can't follow:).. let you think..
<stikonas>yeah, messy bash script...
<stikonas>maybe because I have /etc/portage/package.use/llvm file with
<stikonas>sys-devel/llvm LLVM_TARGETS: *
<stikonas>sys-devel/clang LLVM_TARGETS: *
<stikonas>dev-lang/rust LLVM_TARGETS: *