<Jookia>Also is coreutils supposed to be reproducible yet
<lfam>Anyone familiar with cmake? I'm trying to package something but the build fails right away with "CMake Error: The source directory "..." does not appear to contain CMakeLists.txt." https://github.com/nemtrif/utfcpp
<lfam>Working repos usually don't match distribution tarballs. Ideally, upstream does some things to prepare the tarball for distribution (such as `make dist`)
<lfam>Sometimes on github that is not the case, because apparently github rolls a tarball of HEAD anytime you make a release tag. But not in this case. Just wondering if this is something I can work around or if it's a bug. I'm not familiar with cmake.
<Jookia>If it differs and there's no CMakeLists.txt, there's no way to build it- it's like the 'bootstrap' and 'configure' scripts
<Jookia>Well, assuming they shuffle the UUID around - Say it's just #ifndef UTF8_FOR_CPP_CHECKED_H, there's two possibilities when conflicting: That it's a library conflict, or that someone's used the same #define . Adding a UUID means there's a chance you might be able to include two utf8cpp libraries that don't conflict in #define but do in code
<lfam>Things like this make me thing twice about packaging stuff
<NiAsterisk>i have not much insight yet, but I run ./pre-inst-env in the environment as iirc it does not affect the local store/state, the later run not in an env would build it with affecting the local store?
<NiAsterisk>maybe I just rollback completely and redo what I worked on. I am not entirely new to git, but branching workflow is something I am not so good at (yet). I did guix pull, guix package -u, git pull (in master) and then git pull on my local-lispf4 branch which tracks origin/master to rebase it, but I removed the *.po files with git rm --cached -r *.po before I merged.
<mark_weaver>civodul: In addition to cURL, the OpenSSL folks have announced that there's a "high" severity vulnerability in OpenSSL 1.0.2, which is the one we're using, but they're keeping the details secret until tomorrow.
<mark_weaver>I guess we better build both of those out in the same branch.
<mark_weaver>civodul: actually, I would prefer to wait until GC finishes, because after it's merged, hydra will be heavily loaded generating nars as people download new substitutes, and it's probably bad if that all happens while GC is running.
<davexunit>kristofer: the reason why dual booting is currently hard is because we don't detect other OSes and add GRUB menu entries like other distros do. if we were to do that, dual booting would be fine.
<davexunit>but since you aren't necessarily introduced in dual boot, maybe it's not an issue. :)
<kristofer>like I said, I'm not really interested in dual booting, but booting from usb is difficult for me.. I'm a little concerned about bricking my system if I replace the bootloader with 32bit grub-efi
<mark_weaver>davexunit: I haven't tried it, but we have a way to add one kind of grub menu entry.... for booting linux.
<calher|Nibbler>The system should detect non-free operating systems and write over them with /dev/urandom.
<kristofer>so if I could use a CD to boot and install guix this would be a lot easier/safer for me :)