<civodul>maybe we'll do better eventually, who knows <civodul>(i've reached the point where i combined printfs + rr...) <maximed>but publishing the result, and telling people ‘run these and those commands to get Linux-with-ZFS-patched-for-Linux<,))’ <maximed>And 5(c): the _entire work_ as a whole must be licensed under the GPL <dstolfa>yeah, this is the source of incompatibility, but it's only really applicable when you distribute the binary, no? <maximed>The section is titled ‘Converying Modifies Source Versions’ (ok this only applies to modified source) <maximed>And being allowed to ‘convey verbatim copies’ isn't suffcient, because 4 freedoms? <dstolfa>i don't think there's any real issue in guix specifically as long as: (1) guix doesn't offer a substitute for zfs.ko; (2) guix doesn't modify any source; (3) guix only fetches a tarball and runs make. something that may make sense to do (as per your original suggestion) is warn users that they are in a legal grey area when it comes to redistributing zfs.ko, link to the article and maybe remind them of the 4 <maximed>(oops, I'm reading the GPLv3, Linux uses the GPLv2) <geex3>openvpn-client service, to use openvpn.conf file, need to split out cert,ca,key into /etc/openvpn/client.key ? or can use /etc/openvpn/mything.conf <dstolfa>there might be an issue in OpenZFS itself (e.g. they might have to explain how they build a linux kernel module without violating anything), but in guix we'd just kind of fetch a tarball and run make <dstolfa>it's no different from having a GPLv3+ install recipe that fetches something like steam <maximed>About (2): possibly guix itself is _legally_ in the clear, but I think we try to guarantee that all software in guix (not counting channels), respects the third freedom? <maximed>‘(3) to distribute modified versions’ <dstolfa>maximed: agreed, which is why it might make sense to have a big bold warning on it <dstolfa>it is still technically free software, but in a legal grey area <maximed>As it stands, it seems that I don't have the freedom to distribute modified versions of OpenZFS <dstolfa>canonical would not only argue it's fine, but they actively do it <the_tubular>Can i disallow a user from accessing a binary that has been installed only by a specific user ? <dstolfa>maximed: would it make sense to have a command line flag such as: "--really-i-understand-the-risks" or something? <maximed>the_tubular: Nope, all users on a system share the same store <dstolfa>maximed: i know :( it's a hard and polarizing topic <dstolfa>FWIW i think your original proposal of a warning is 100% valid <dstolfa>especially given the context of guix as a whole <maximed>dtolfa: would you mind if, in murky, not-yet-settled, situations, "guix install MURKY" and "guix environment --ad-hoc MURKY" raise an error by default? <dstolfa>maximed: i personally wouldn't, but i feel people might get upset if their scripts stop working <maximed>with an option "--accept-murkiness=MU,R,KY" <dstolfa>maybe there could be a pedanic guix mode that raises the error, and otherwise just warns, which could be phased in over time? <dstolfa>e.g. starts off with default off + educating users about it and eventually becomes the default? <maximed>it could be saved like transformation options, such that it doesn't need to be re-added every time <dstolfa>yeah, i mean i'd be fine with that personally <maximed>dstolfa: I don't think the phasing in will be necessary, but it seems reasonable <dstolfa>might be worth moving the discussion to the mailing list? <dstolfa>ZFS is just one example of this, i suspect there are more? <dstolfa>it would certainly help users make a decision <maximed>dstolfa: ok, I'll post a link there linking what we've discussed on IRC <geex3>is there channel for help with configuring a service (in my operating-system config.scm) ? <muradm>i tried yours also, but it is not enough to trick gcc <maximed>the proposed linter detects two other kernel modules <dstolfa>are they maybe dual licensed? i find it hard to believe that someone would just slap GPLv3 on a linux module <muradm>my de-optimization is a bit more aggresive <steggy[m]>is geiser + exwm expected to perform pretty terribly or am I possibly doing something _real_ wrong? I have a file that's just ```(use-modules <steggy[m]> )``` because I was gonna mess with trying to change the version and get it working, but after C-x C-e to eval that, typing pretty much anything locks me up unless I C-g out <muradm>civodul, i could not figure out relation to the issue from your valgrind output <steggy[m]>To answer my own question - guessing there's something single threaded going on(that causes exwm to choke up), but after a startup period, it appears fine :) <muradm>roptat: ReleaseStringUTFChars drills down to simple free(addr) call <mjw>muradm, civodul's valgrind trace is probably not related. It is somewhat embarassing code though. If now cwd is given then a null string is used for chdir, which fails, but the failure isn't checked... the code has a /* FIXME: Handle the return value */ <mjw>but NULL simply meant we didn't need to chdir <mjw>what a frustrating bug. there is clearly some bad code, but none of it explains the issue <roptat>muradm, well, your patch works for me, but maybe as you said, we should try with an older gcc? <roptat>but it's weird we get a different result with my patch, shouldn't it be reproducible? <muradm>roptat: i'm looking at jikes, jamvm and classpath-bootstrap, trying to build with some older gcc like from 2016 could be an option to try <roptat>"Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz" <roptat>but our gcc is not supposed to do any cpu-related optimizations <lfam>Sometimes a package sneaks them in <muradm>roptat: as far as i saw, if not specified all above compiles with -O2 <muradm>trying to compile all of them with -O0 cause segfault :) ***LispyLights is now known as Aurora_v_kosmose
<apteryx>shouldn't rustfmt be included along rustc (same default output) for our rust package? <iskarian>apteryx, that would make sense, assuming it's not some stripped version just for building packages... <apteryx>OK. No, it's the leaf packaged to be consumed by Guix users <apteryx>ugh. why is mozjs stuck on a rust 1.41? *apteryx remembers fighting with this monster before <iskarian>Maybe it had to do with the vendoring? (vague recollection) <apteryx>yes, I think it vendors a massive amount of rust things <apteryx>my new rust bootstrap only builds intermediates rusts at stage 1, which means they aren't usable. That's doesn't seem to be an issue for most software (can be built with latest rust happily) but not mozjs <muradm>does ci.guix.gnu.org keeps how long it took to build package? <muradm>meh.. it allows to search only public packages? <iskarian>muradm, what do you mean public packages? It should build all packages in the default channel <iskarian>And yes, if you navigate to a build page, the sixth item down is "Duration" <iskarian>oh, I don't think it shows hidden packages, if that's what you mean <muradm>iskarian: yes hidden packages are not shown <efraim>iskarian: I've built go-1.4-bootstrap for aarch64 on core-updates-frozen (which is actually for armhf) <abrenon>just to make sure: is there a way to pass build output path as among #:make-flags ? <abrenon>reading the manual I'd say no, but I thought maybe there was a clever way to do it <flatwhatson>abrenon: yes, eg. (#:make-flags (list (assoc-ref %outputs "out"))) <abrenon>that's this %outputs assoc I've been missing <abrenon>or rather, how come it enters the scope when #:make-flags is evaluated ? <flatwhatson>the arguments to package aren't evaluated immediately <flatwhatson>%outuputs is defined in the scope they're evaluated in <abrenon>so you mean it'd be possible in theory to access it to define a field like propagated-inputs or description ? <abrenon>(I know it wouldn't make sense, just wondering what is technically possible) <flatwhatson>it's buried in there, you get %outputs and %build-inputs and that's it <abrenon>yeah… I skip too fast over such blocks, thinking I'll always be able to come back to them when I need to know the actual values <flatwhatson>oh i don't think it's easy to find, i only found it "backwards" :P <flatwhatson>personally i learn such tricks by grepping the existing package definitions <abrenon>I thought there wasn't too much work left but I wasn't ready to assume it was that little <abrenon>hmmm now I get Fatal error just trying to invoke my program with --help ^^' <abrenon>thank you so much for your kind help ! <attila_lendvai>how do i get my trezor gpg agent working? i have installed for my user: trezord, trezor-agent, trezord-udev-rules (no restart). and i get: "Failed to enumerate WebUsbTransport. USBErrorAccess: LIBUSB_ERROR_ACCESS [-3]" any hints? <attila_lendvai>ok, i've installed trezord-udev-rules system-wide, but looking into the rules, they reference the plugdev group, which is not created. is this a bug to be reported? <attila_lendvai>i see this in other packages... is this missing from trezord-udev-rules? (substitute* (find-files "contrib" "\\.rules$") (("plugdev") "dialout")) <vivien>Hello, commit 5dac09e263d566ccf99776df97c47eed0d30c172 broke my cgit server. When pulling, I get: (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (guile-syntax-highlight)) (value #f)) <vivien>I don’t, because I don’t use that variable and it seems to be included wherever it is needed ^^ <vivien>((gnu packages guile-xyz) seems to be included in (gnu packages version-control), where cgit and the new package are defined) <civodul>it's a minor issue in the commit you mentioned, i'll push a fix shortly <vivien>I’m really curious, the commit seems fine to me <civodul>the guile-syntax-highlight inheritance is what causes problems: it inherits from a package defined in another module <civodul>we cannot do that due to circular module dependencies <vivien>Ooh, I get it, (gnu packages version-control) depends on (gnu packages guile-xyz) and (gnu packages guile-xyz) depends on (gnu packages version-control) <vivien>In this situation, is it possible to use the (@ module package) form to break the circular dependency? <mbakke>did anyone look into why the initrd Guile is failing on core-updates-frozen? <civodul>mbakke: nope, i'm still deep into Java <civodul>the initrd Guile is failing in what way? <mbakke>it fails looking up users with getpwnam (at least) <mbakke>In procedure getpw: entry not found <mbakke>it can be reproduced with: $(./pre-inst-env guix build -e '(@@ (gnu packages make-bootstrap) %guile-static-stripped)')/bin/guile -c '(pk (getpw "root"))' <mbakke>the unstripped version works, so something is wrong with embedding the static libc <civodul>mbakke: that getpw fails suggests the "file" NSS backend is not getting embedded <civodul>i think there were changes in this area in glibc *civodul builds icedtea 1.13 on core-updates-frozen \o/ <attila_lendvai>how do i tell guix to use my local guix.git checkout when running e.g. guix system reconfigure? after scanning the docs, i still don't know how to test my changes on my live system. i have set up my own channel, but that only helps with testing added packages. i want to test changes some to a service (tlp). <cbaines>attila_lendvai, that's what the ./pre-inst-env script is for, you would run ./pre-inst-env guix system reconfigure ... for example <attila_lendvai>what would be the easiest way to get a vanilla golang compiler on Guix (i.e. don't do any of the /gnu/store magic on the resulting binary)? use a debootstrap chroot? <cbaines>attila_lendvai, go is packaged for guix, so it's pretty simple <cbaines>just install/use it like any other package <attila_lendvai>cbaines, i'm trying to reproducible build the go-ethereum official binary release. i need a vanilla golang compiler for that. <cbaines>attila_lendvai, I wasn't aware that go packaged for guix wasn't "vanilla" in some way? <attila_lendvai>cbaines, re pre-inst-env: thanks for clarifying that! i can't make it work though, because i don't know how to specify my channels (that normally get loaded from /etc/channels.scm) <attila_lendvai>cbaines, on guix e.g. the resulting binary gets a different ld loader, etc... the patchelf stuff <cbaines>the guix docs seem to say that channels are looked for in ~/.config/guix/channels.scm <attila_lendvai>oh, i think i forgot to specify --sysconfdir=/etc to ./configure... lemme retry <attila_lendvai>civodul, when i try: sudo ./pre-inst-env guix system reconfigure /etc/guix/config.scm => no code for module (gcrypt hash) *attila_lendvai does a guix pull and a git pull <cbaines>attila_lendvai, with sudo, you're using the root users environment. If you're got dependencies in your users environment that you want to use, you should use sudo -E <qzdlns[m]>struggling to grok =extension= for =postgresql-role-service= to add a role -> does <nckx>I'm failing to SEO-keyword something so I'll ask here: does anyone happen to know if/how I tell NetworkManager to add an entry to /etc/hosts only when I'm connected to one specific Wi-Fi network? All I find is people complaining that NM modifies /etc/hosts. I want that, I just don't know how to harness it. <nckx>It doesn't have to be /etc/hosts, it can be something fancier in dnsmasq. I just want the (public) foo.bar.baz name to resolve to a LAN IP on one specific network. *nckx didn't recognise you under that expensive donor cloak. <roptat>I have a few workarounds for icedtea1, but it still doesn't build <civodul>roptat: ah, good! we'll get there :-) <civodul>perhaps it's a matter of passing -std=cxxNN, for some value of NN? <civodul>nckx: can NetworkManager handle such sophisticated settings at all? <dstolfa>i've seen it do it before, i just have no idea how <nckx>It runs dnsmasq, so it's frustratingly close to being able to do so trivial, but no I don't know if it can. <dstolfa>nckx: does the gui not have anything helpful? *nckx pretends to know what the GUI is called. <nckx>Does nmtui expose the same settings? *dstolfa pretends to know nmtui <roptat>civodul, ah maybe that could work <nckx>Because I don't see anything close to what I need. <dstolfa>nckx: i usually use the gnome one :/ <nckx>This is turning into a question for #networkmanager (which probably doesn't exist). I was just hoping for a ‘oh that's trivial here's my .scm’ here ☺ <attila_lendvai>cbaines, i'm not sure what i want. something like this: do a `guix system reconfigure /etc/guix/config.scm`, but using the modified service definitions from my local guix.git checkout. *nckx curses ISP for replacing modem with 'identical' one that isn't and can't NAT gud. <dstolfa>nckx: network setups have gotten way too complicated <roptat>attila_lendvai, you can do something like ./pre-inst-env guix system reconfigure /etc/guix/config.scm <nckx>Maybe? I don't know :-) I'm going to sidestep any subjective discussion by stating that NAT sucks and needs to die yesterday, which is merely an objective fact. <nckx>My ISP is still struggling with IPv5. <roptat>you didn't tell them they can skip it? <attila_lendvai>roptat, if i run it as-is, then it's missing my other channel that is required for my config. if i prefix it with sudo, i get: no code for module (gcrypt hash) <roptat>can you pull with your local checkout? <roptat>or, you could create a channels.scm and use that with time-machine, that way you can stay on the official guix channel except when you really want your checkout <roptat>you might need to disable authentication *attila_lendvai faild, and looks into time-machine <cbaines>./pre-inst-env guix system reconfigure ... would probably work if you used sudo -E <cbaines>I don't know a lot about channels, but you'll probably be able to use the channel as a Guile module <roptat>attila_lendvai, even with time-machine, the channels.scm needs to specify your additional channels <roptat>what happened on core-updates-frozen? I'm building llvm :( <civodul>roptat: ah, it could be the jemalloc patch i applied <cbaines>I'm not quite sure what the "frozen" thing is meant to mean <cbaines>but currently it doesn't seem to mean "no changes" <roptat>it was supposed to mean only fixes to packages that fail to build <roptat>but that includes changes to dependencies that might have lots of dependents if that's needed <attila_lendvai>roptat, cbaines yay, success! the magic incantation was this: guix time-machine --url=/path/to/guix --branch=battery --disable-authentication -- system reconfigure /etc/guix/config.scm *attila_lendvai is making notes and will open PR's for the documentation <civodul>roptat: to me, it's for "package fixes", and that one seemed important <civodul>ah, got it: "guix graph --path llvm jemalloc -t bag" says jemalloc is a dependency via cmake <civodul>i guess i went a bit overboard, though OTOH the build farm has been sitting idle for a while <roptat>it's ok, I have a fast computer, though llvm might still take a while :) <dstolfa>llvm takes a while even on fast computers! :P <roptat>mh, searching for "jemalloc cmake" to learn about what the dependency is used for, I see some projects to use cmake to build jemalloc <roptat>I think I remember a similar discussion, but could we get rid of curl in cmake-minimal? <roptat>since we'll never download anything anyway? <civodul>maybe; we need to double-check what the impact would be <roptat>looks like not, if we don't provide curl, it builds its own embedded version <apteryx>updating mozjs to 78.13.0 resolved the problem with rust 1.54 :-) <roptat>oh, now building some rust packages <apteryx>OK. I have 2 things to test and then I can send my patch series (which includes Rust) for review. allows to build it in 4 instead of 8 hours <apteryx>roptat: bootstrap using mrustc from rust 1.39 and disables stage 2 compilation mostly <apteryx>(except for the final rust package, which is the only one exposed) <apteryx>yes! The per-profile font thing now works: ./pre-inst-env guix environment --pure --ad-hoc abiword font-linuxlibertine fontconfig -- abiword --> linux libertine in there <apteryx>via XDG_DATA_DIRS (new in latest fontconfig) <apteryx>the last check is verifying that the sitecustomize.py fix actually works <roptat>"guix build: error: gnu/packages/ocaml.scm:1452:2: ocaml-zarith@1.12: build system `ocaml' does not support cross builds" <roptat>what does that mean? I'm not trying to cross-build anything <podiki[m]>that update in fontconfig will be nice, can remove the little work around now I have to add a profile directory in a fontconfig file <apteryx>ah, my test case is removing a build phase from glade <roptat>I think I managed to build the OCaml bindings of z3 without needing to rebuild z3, in a separate package :) ***dongcarl7 is now known as dongcarl
<apteryx>we could sync core-updates before, or cherry pick things from it since it's a world rebuilding change <civodul>oh, because of the "Fix repacking" patch? <apteryx>but the other things touched are rather core too <qboltz>anyone familiar with how to get javac up and running? I already got openjdk16 installed, and I saw it came with openjdk-16-jdk, so I was under the impression javac would be available <ssouth>qboltz: You need to have the "jdk" output installed, i.e. "guix install openjdk:jdk". <qboltz>amazing, thanks! is there a command to see various outputs for packages available? <ssouth>qboltz: Yes, "guix show" shows that information, i.e.: "guix show openjdk" or "guix show openjdk | recutils -p outputs". <ssouth>"recsel" I meant, not "recutils". <yoctocell>finally sent my patch for the `generic-git' updater; `guix refresh -L' now reports "94.5% of the packages are covered by these updaters.", 100%, when? ;-) <qboltz>hello again! I just recently installed gcc-objc++ and gcc-toolchain, <qboltz> and I am able to see g++ in my .guix_profile/bin, but it's throwing <qboltz> error messages on compiling a basic loop right after the <qboltz> install. Anyone know if there's extra steps besides just installing <qboltz>fatal error: linux/errno.h: No such file or directory <roptat>looks like you're missing linux-libre-headers <qboltz>awesome, thanks! Is there anywhere in the guix docs or elsewhere that would have prevented me from coming here to ask? <roptat>it's "common knowledge", not really specific to guix <ssouth>Incidentally qboltz, are you working on a program of your own or trying to compile something you've downloaded? <ssouth>"guix environment" is great for managing dependencies for you if there's already a package in Guix. <ssouth>(or even if there isn't, really) <qboltz>my own I just copied from a textbook, just wanted something small to see it compile. Also, is there a reason the headers wouldn't be a dependency? <ssouth>Not every program requires the Linux headers. <ekaitz>hi guix! anyone has an explanation of why do we use an initrd instead of initramfs? I've been reading on this things and it looks like initrd is a little bit outdated, am I right? <ekaitz>initrd is a disk, and initramfs uses the kernel cache system <ekaitz>initramfs is linked in the kernel and the initrd is a separate thing <nckx>We don't use an initrd. It's beyond obsolete. <ekaitz>the documentation says we use initrd <nckx>The naming 'initrd' is still used a lot, including in e.g. GRUB. <ekaitz>so what's what are we using? we use an initramfs but we call it initrd? <roptat>that might be why I was confused ^^ <abrenon>I always though it was the same too : ) <nckx>abrenon: Initrd is a block device in RAM. Initramfs does not emulate a disc or even file system at all. <nckx>‘File system’ in the real sense that is; it hooks directly into the page cache. <ekaitz>i just read the link and I was like: wtf? are we using this outdated thing in guix? <ekaitz>they are, but they are treated differently <abrenon>that were more or less uncompressed or something when the kernel started <nckx>ekaitz: If you care enough about the name you could submit a patch to update the manual (I agree that it's misleading if you're not used to ignoring actual initrds as obsolete), but I don't think the name initrd should be changed in the code. <nckx>abrenon: ‘At rest’, sure, but they are extracted very differently <ekaitz>nckx: Honestly, i don't really care, but I was confused by it. <nckx>abrenon: Initrd was an actual file system init (as in mke2fs img; mount -o loop img /mnt; cp stuff/ /mnt) that is 'loop mounted' in RAM, initramfs is a cpio archive (an older & simpler tar if you will) that is extracted & thrown away. <abrenon>I think it'd be a good idea to fix the naming in the documentation, if only because I and roptat were confusing both types of objects <nckx>I see that I'm almost repeating ekaitz's link word by word, it is a good link, these people seem to know Linux! <abrenon>it could be useful just for the additional information of clarifying this <nckx>I'm just suprised anyone cares ☺ <abrenon>well I do ! those kind of things are important <ekaitz>(I also thought they were the same thing, and I'm preparing a course about linux and I was preparing the contents when I found this) <abrenon>(also, I've spent way too much time in init recovery shells not to care…) <nckx>At the level 99% of people operate they really are TBH. <lfam>Is there a system test to exercise guile-ssh within Guix itself? <lfam>I'm testing an update of libssh <lfam>Or even a way to enumerate the system tests ***janneke_ is now known as janneke
<zacchae[m]>One of my primary interests in Guix is the reproducibility of an entire system, especially for research purposes. Assuming I produce some result, how would I go about archiving my build? <zacchae[m]>Ideally, I would be able to generate a config that specifies code versions AND their hashes <maximed>zacchae: something with time machines (let me look ...) <zacchae[m]>maximed: So we can only do marginally better than distributing a docker? <lfam>To put it simply, Guix is totally based on Git. So, you only need to preserve the Git repo and record the Git revision that your system is based on, and then you can reproduce it completely <lfam>Whether that reproduction is bit-identical is another story <roptat>with the configuration you used, obviously <maximed>I'm not sure what you're trying to achive exactly, but that blog post should be a good starting point <lfam>Agreed, you have to clarify your goals <lfam>Guix is categorically better than Docker in this regard, since Docker uses many things from the host system, whereas Guix *is* the host system <zacchae[m]>ok, so I can specify a commit stirng for guix pull <roptat>if it's to provide an artifact for a conference for instance, I usually have two instructions, one with virtualbox (not really reproducible) and one with guix: "guix time-machine <some-hash> -- guix build whatever" <roptat>yes, you can find your current revision with "guix describe" <zacchae[m]>maximed: That blog post is the right answer: i.e. any work I do should be wrapped up in a guix package <zacchae[m]>but as a matter of practice, not everyone doing research is going to want to do that, so many might find it easier to make something work, then distribute a system config that they ran on <muradm>roptat: did you push that commit regarding ant-boostrap/classpath-bootstrap thing? :) <roptat>muradm, civodul pushed something different <roptat>but because of a patch to jemalloc, I'm stuck building the rust bootstrap chain right now... <maximed>note that the guix package doesn't have to in the guix repo <maximed>if using "guix time-machine .... guix build -f some-file.scm" <zacchae[m]>Why would I need to guix time-machine to build from a local package definition? <maximed>so the build process will use some specific versions of software <roptat>if you don't use the same version of guix, you get different dependencies <roptat>it's like running "apt update" in your dockerfile <zacchae[m]>I assumed that the local package def would specify dependency versions, but then again, that sounds really tedious <abrenon>bye all, thanks for all the interesting things I learnt again here today <roptat>unless your local package redefines all packages up to the bootstrap seeds, it will rely on packages from guix that can change <roptat>and even if you specify a version, that version might not exist anymore in future guix revisions <roptat>or depend on different packages itself <roptat>so, relying on version numbers is not enough for reproducibility <iskarian>sneek, later tell atilla_lenvdai: regarding "the resulting binary gets a different ld loader, etc...": this is necessary because of how Guix works; without this, the binary would not use the libraries packaged by Guix, which defeats the purpose of Guix :p <iskarian>apteryx, aha! Everything is on recent rust now? <roptat>civodul, muradm ah, actually the first failure (a friend declaration) is after on a g++ command that already has -std=gnu++98, so specifying a -std won't help :) <lfam>I wonder how there is a substitute for the 'guix' package, considering that tests/publish.scm fails consistently on berlin <lfam>I want to push this libssh update but it will be very annoying if every user has to build Guix themselves afterwards <apteryx>iskarian: on 1.54 yes, if I didn't forget anything <apteryx>roptat: you really should apply that rust bootstrap patch; it starts at 1.39 and you're building 1.33 ;-) <roptat>apteryx, in the end I simply went one commit back, so I don't have to build rust <muradm>roptat: i'm still in process of rebuilding the world :) <roptat>the issue now seems to be in openjdk/hotspot/src/share/vm/memory/dump.cpp <roptat>it computes a hash of a list of files and doesn't agree with the same code written in Java <roptat>the java side computes ...167e8087, the C side computes ...00000031 <roptat>I want to say the C side is buggy <roptat>what the java side computes matches what we have on master, at least <roptat>that function is called for each file in the list <roptat>I added some printfs to check it's really called <roptat>maybe gcc is trying to be smart again? <apteryx>roptat: hmm, why are there two versions of that code? <roptat>the java side generates the hash, the C side checks it <roptat>that's why I suspect gcc being crazy <apteryx>I think GCC used to default to C99, perhaps tht changed with GCC 10.3? <apteryx>you may want to force its compilation to C99, or whatever it was on master <roptat>it looks like all the files are compiled with -std=gnu98 <apteryx>-std=gnu98 both on master and core-updates-frozen? <roptat>I suppose, there's no specific flags set, it's the default <roptat>I mean, but default icedtea adds gnu++98 to the g++ command line <apteryx>what if you build it with gcc@7.5 on core-updates? <apteryx>if so, you could regress from which GCC it broke, and then check with GCC folks if they have an idea <muradm>roptat: it computes for same string different value? <roptat>yeah, the java side computes ...167e8087, the C++ side computes ...00000031, on master they both computed ...167e8087 <roptat>another reason I suspect gcc optimized out some of the inner loop <roptat>I mean, it's suspicious that a hash has so many 0s <muradm>31 would mean it is looped only once <roptat>and it's supposed to start with 0xcafebabebabecafe <roptat>(I can only print the last 8 hex digits) <iskarian>I haven't been following, what's the actual error you're getting? <muradm>roptat: can you trace definition of jlong? <muradm>but if it would be wrongly typedefed most likely nothing would work <roptat>not entirely sure, I think it's "long" <muradm>can you try substituting "jlong h = start;" to "unsigned long h = start;" <roptat>sure a single long can contain something as big as 0xcafebabebabecafe? <roptat>also, it fails after a long time, so I can't test too many times <muradm>this is not big, exactly 8 bytes :) 64 bits <apteryx>lol, 12 GiB per ld process to link LLVM <muradm>roptat: you could continue broken build instead of rebuilding everything from /tmp/guix-build-<pkg>...drv-<N> <roptat>yeah, but I'm not sure how to rebuild the parts I need to rebuild <roptat>the process is also very complex <iskarian>the same "friend declaration" error, that is <muradm>roptat: that seems to be make which is called, why not trusting it? :) yes it will pass from top to bottom, but won't hopefully rebuild everything, and continue on broken piece <iskarian>Ah, was just going off of the last ML message :) <roptat>muradm, mh, I tried to surgically remove two files that are needed to run the code, but then make fails :/ <roptat>mh, now it wants to reapply patches, I don't think I can test it that way <roptat>iskarian, there's no toolchain.m4 in the sources, so I doubt that's it <iskarian>In that case, it's very likely there are compiler flags needed for newer GCCs <iskarian>since it looks like this version doesn't even detect compiler version and adjust <podiki[m]>is there something different about how guix sets up sys? I can't (as sudo) write to something in /sys/class/drm/... (trying to force display detection and enable/disabling) <podiki[m]>oh, it is set as read only, is that typical? <nckx>/sys should not be mounted ro, but Guix doesn't do that. <sneek>milkey, nckx says: <it needs gl.pc at build time> tells you only that mesa should be an input, which you already knew, not which flavour. Whether its dependents require mesa, for example because mesa's in Requires.private of (say) libbplacebo.pc, is the question. If yes, propagating mesa might be an appropriate hack. <milkey>It is old. I was considering rewriting it <milkey>It works fine and is packaged in all the other distros I've used though <nckx>So I don't get whence Repology is getting the ‘slurm-monitor’ name, but I'd use that. <milkey>I thought calling the network monitor "slurm-monitor" would be kind of confusing since technically, "slurm" the job scheduling program also monitors something <civodul>surely we understood something that nobody else did <milkey>but "slurm-network-monitor" is a handful <nckx>Yeah. IMO the little specificity that ‘network-’ adds isn't worth the added length, but I've no strong opinion. <nckx>This from the person who introduced $foo-linux-module so... packager chooses. <podiki[m]>from what I've read you can write directly to that (text file) with something like "detect". having some issue with some displays being detected (not specific to guix, had before on arch too) <nckx>podiki[m]: That's writable here. <nckx>It says ‘disconnected’, when I try to write ‘connected’ (just a guess 😛) it returns ‘Invalid argument’. <nckx>I.e. ‘what is this nonsense, human’, not ‘permission denied’. <podiki[m]>I see permissions as only +r, even a chmod with +w still get permission issue <nckx>I don't think /sys supports permissions like that (unlike /dev), it's fully virtual. <nckx>There's nothing wired up to that. <podiki[m]>yeah, not getting a "nonsense" just a "zsh: permission denied: /sys/class/drm/card0-DP-2/status" <nckx>Here all 6 card0s have -rw-r--r-- for status <podiki[m]>yeah, seeing that now too, maybe I looked at it wrong <podiki[m]>okay, think it works via tee, which is what I usually use for this sort of thing (echo was not) <nckx>Yeah, that's totally different. <podiki[m]>some of the other files in there are just r permissions, but I'm guessing those don't do anything <podiki[m]>right. okay good. too much copying from internet not enough thinking :-) <nckx>Yes, they are truly read only, as in the driver gave the kernel a read function but didn't implement a write function, there's no changing that which chmod. <nckx>To be fair, ‘sudo echo haha > nope’ is a common mistake ☺ <podiki[m]>must have been too long since I've made that mistake, and forgot