IRC channel logs


back to list of logs

<vagrantc_>rlb: well... one issue down, but now i get some presumably non-deterministic segfaults in various test suites: ... so far only ppc64el, s390x, riscv64 and ppc64 ... but they're segfaulting in different tests
*vagrantc_ wonders if running tests in parallel could be an issue
<vagrantc_>oh, apparently i run the tests in serial already...
<rlb>vagrantc_: note that there's a current known issue exposed by gnutls.
<rlb>not sure if it's related, hang on...
<rlb>"if it could be"
<vagrantc_>yeah ...
<vagrantc_>maybe the gmp thing ludo mentioned?
<rlb> and also noticed very old
<rlb>Might have nothing to do with the current issue, though.
<vagrantc_>i can try to schedule a giveback, but that seems poor form :/
<rlb>I suppose if you have the time, might try to reproduce it in a loop on one of the porterboxes or similar...
<fnstudio>i followed this guide ( to create a GNU Build System / Autotools package
<fnstudio>it seems to work, as it configures/builds/install with no errors
<fnstudio>however, there might be something fundamental that i'm missing
<rlb>vagrantc_: since s390x is a segfault, if we can reproduce it, suppose gdb might be able to tell us something more interesting, if we're lucky...
<vagrantc_>rlb: all of the failed builds are segfaults
<fnstudio>at the end of the installation i see a hello.go file is save in and made available from a lib folder in my home; should i expect a `hello` binary to be also saved anywhere?
<fnstudio>*is saved
<vagrantc_>wonder why they're not getting this issue on guix's guile ...
<vagrantc_>oh, i guess if it's actually architecture-specific... they test on fewer architectures ... but i suspect it is more non-deterministic than architecture related ... maybe specific architectures might trigger the issue
<vagrantc_>more easily
<vagrantc_>i'm going to try in a loop on x86_64 and see if i can trigger it ...
<rlb>fnstudio: I don't know anything about those project setup recommendations, but no, I wouldn't think you'd end up with a binary. You'll generally run your program via a #!/.../guile script.
<rlb>vagrantc_: suppose x86 does have some substantially different memory/cache/etc. behaviors from say arm64, so it may be notably different on some fronts.
<fnstudio>rlb: oh i see, excellent, thanks - i'll have a look at some other project to see how this is handled when things are packaged
<rlb>fnstudio: see also
<rlb>fnstudio: or actually perhaps start at
<fnstudio>thanks rlb very good pointers
<daviid>rlb: back to trying vagrant, I try to follow the steps you kindely pasted, quite blindingly I must say, didn't have time to look at any doc yet, here is what happens
<daviid>rlb: after vagrant init debian/testing64, i edit the file but can't find any entry for vm.memory, nor vm.cpus (which were optional, but can't find them ...)
<daviid>rlb: then vagrant ssh fails ==> default: Domain is not created. Please run `vagrant up` first.
<daviid>i try vagrant up, it also fails, here -
<daviid>i 'have' ssh the .ssh/id_rsa file exist, and the ssh daemon is running, fwiw
<daviid>rlb: (or any vagrant user who would know ...) i'll read/search (not exactly now, but will do) to solve this (small) problem of course, just reporting that i prob miss some (libvirt ?) set-up here ... but in case you'd be 'here' and know the missing step(s) let me know ...
<rlb>daviid: sorry, right, I forgot the vagrant up command, and it's vb.memory and vb.cpus (not vm) -- you should see a section commented out near the bottom of the Vagrantfile that includes vb.memory, and you can just add vb.cpus there too if you want to.
<rlb>daviid: oh, and sorry, another assumption, I'm using virtualbox (the default vagrant provider here), i.e. "apt install vagrant virtualbox", though that might require (in debian) testing or sid -- iirc one of them might not be in stable... So I suppose it could be this is more hassle than it's worth for you, depending on your situation.
<rlb>I don't know that I've ever used vagrant with libvirt/kvm/qemu -- I do use kvm/qemu/libvirt for less throwaway servers (mostly just use vagrant for testing), but in those cases, I use kvm/virsh/etc. more directly.
<rlb>And if you don't have virtualbox available to vagrant, I guess that might be why you didn't see the section in the config file (didn't realize that's how it works).
<fnstudio>briefly following up on my question re packaging a guile executable with the GNU Build System / Autotools, i understand i need to add a script that wraps my guile program, as it's done here for instance
<fnstudio>(the project comes with a lot of useful docs and comments, by the way, very useful to understand what's going on with the different files)
<fnstudio>i still need to understand how it can make it away without importing the guile.m4 file that seems to be used in all other packaging-guile-with-the-GNU-Build-System projects i've looked at
<fnstudio>ah... this might explain the lack of guile.m4:
<fnstudio>where it explains that, in certain circumstances, the file guile.m4 is automatically copied over from the system by aclocal
<fnstudio>although that doesn't seem to apply to guile-daemon... as it doesn't make use of GUILE_FLAGS...
<fnstudio>i'm looking at and i wonder if there's a simpler way for me to wrap a shell script around my guile module
<fnstudio>if i understand it correctly, the script above has to figure out the paths where the guile module has been installed
<fnstudio>if i simply use (use-modules (my-mod)), then the script doesn't seem to be able to find the library
<fnstudio>i'll go and see if i can find another simple guile program (not a library) that i can get some insight from
<mwette>fnstudio: my distribution is all scheme, I did away w/ guile.m4 and ginned up a the works for me. I ran into too many issues with the other stuff. Look here, it may give some ideas:
<mwette>you'll want to look in etc/ directory
<fnstudio>mwette: this is priceless, thanks so much!!
<tohoyn>I have had problems with guile.m4. It does not detect the guile version correctly when both guile 2.2 and 3.0 are installed.
<tohoyn>This was with G-Golf.
<ATuin>Hi, I have a weird problem when creating a binding for libzip, seems to be GC related. Basicaly i create a source from a bytevector to be added later into the resulting zip. When the script is compiled first time, it works properly but when i run it a second time the output produced by that source is messed up (a mix between txt from other files and random characters)
<ATuin>is there anyway to debug the GC
<ATuin>if i register those bv in a hasmap before creating the source seems to work fine when running it several times so it looks for me like a GC tihng
<ATuin>any idea?
<ATuin>tht's the code
***leoprikler_ is now known as leoprikler
<ATuin>yeah, seems to be the GC, when using a guardian on the data before adding it to the source record it works.
<ATuin>why is guile not knowing that i have a reference for that bv as a field in the record <source>?
<tohoyn>ATuin: are you using g-wrap for the library bindings?
<ATuin>nope, just ffi
<ATuin>i pass a bv, i get the pointer for it and i pass it to a ffi function
<ATuin>then i save the pointer returned by that function (and the bv to keep a reference to the original guile data) into record (kind of wrapper basically)
<ATuin>but for some reason guile is not aware of that data and it collects the bytevector
<ATuin>see there the function bytevector->source
<ATuin>lzip/source-buffer-create is a call to the c library
<tohoyn>ATuin: g-wrap has type qualifier "aggregated" for this kind of situations
<ATuin>mmmm what's g-wrap?
<ATuin>maybe i can take a look at it
<ATuin>but still why guile is not aware of the bv field in the record?
<ATuin>or is just that the whole source is GC
<tohoyn>ATuin: warning: I'm not sure if g-wrap is actively maintained anymore
<tohoyn>ATuin: guile-gnome uses g-wrap
<mwette>guile allocates space for bytevectors using scm_gc_malloc_pointerless
<ATuin>interesting, adding the guardian to the whole source record (the one that wraps the bytevector and the low level pointer) makes it work as well
<mwette>so if the bytevector is not referenced the contents will be freed, I believe
<ATuin>so i guess the whole source record is GC (and whatever is inside)
<ATuin>mwette: yeah, that makes sense but i save it as a field inside the wrapper
<mwette>"space for" => "space for payload"
<ATuin>seems that it's the wrapper the one that is collectec then
<mwette>the bytevector itself or the pointer?
<ATuin>i store the bytevector itself
<ATuin>and the pointer returned by the c call
<ATuin>see the code above
<ATuin>first function
<ATuin>I guess the problem is that the function that adds the source to the resulting zip does not keep a reference to the source, so when the zip is closed (it's then when the sources are saved) then some data has been collected. Interesting :D
<ATuin>finally I added a reference to each source added into the archive record (everytime archive-add-source! is called), seems to work as well
<mwette>and you are saving the returned "source" record I guess?
<ATuin>mwette: yes, the archive record keeps track now of the sources added to it
<ATuin>that was the main problem, since i was doing everything in one rec funcion i was not saving the sources and they are used when the zip is closed
<ATuin>once i implement replace and delete I will made the code to remove them or replace them from the hash-map
<wingo>my reader seems to work?? weird
<wingo>haha i was testing the wrong thing, n/m :)
<wingo>interesting production in guix/scripts/lint.scm: (cons* #\\ #\"result)
<wingo>ok now (ice-9 read) has the same results as C read for all scm files in my ~/src/
<wingo>soon will make sure errors are same. source locations would be a bit gnarly to get exactly the same tho