<g_bor>bavier: I've also noticed that. We also had some discussion about having that phase modified. It would be desirable, if we could finally have the same permissions we started with, but modify them here if we need to write a file.
<g_bor>bavier: I also think that maybe it does not worth the complexity, and a simple one-line patch that adds make-file-writeable is also good. When installed into the store the permission is revoked automatically.
<OriansJ>sneek: later tell rain1 that I really appreciate their help with finding bugs in M2-Planet and writing tests
<buenouanq>unless I'm misunderstanding something, it would be clearer if they were both the same (either sda1 or sda2)
<marusich>buenouanq, I think you're right; I think that for clarity that section should say sda1
<marusich>The section is not incorrect. If the FAT32 file system is in the second partition, which usually shows up as /dev/sda2, then /dev/sda2 is correct. However, it's strange to say this here because the paragraph right above it, as you point out, talks about making the FIRST partition the EFI system partition.
<marusich>I think probably we forgot to update the preceding paragraph when we added the text that said sda2.
<ng0>I think there are hints and notes somewhere.. but that's it. on the public side
<catonano>amz3: I remember reading the NetBSD docs about how many platfforms thheir thing could run on. I even used their scripts to use a pc to compile an installation image for an Apple laptop. This was several yearrs ago. Because they used the autotools ffor everything, I was wondering why this isn't more common
<catonano>I reiterate that I don't know so much about this though
<str1ngs>autotools though good a cross compiling relies on the project to configure it properly. many things break when testing host system vs target system
<buenouanq>ok, Installation finished. No error reported.
<buenouanq>looks like I maybe did the efi stuff correctly
<str1ngs>so you end up having to have a bunch of small patches just to get things to cross compile.
<ng0>not everyone will read the Manuals of all GNU tools. We can day dream all day about this, but it won't happen. So we have to describe good usage, like "use an lowercase name for user-name" or catch it via input validation of the file
<t0167641>what is the command for build a package from scheme file
<ng0>you could check out the pitivi branch in my repo to experience the bugs live
<t0167641>because when i do a guix build -f file.scm
<ng0>that is, the main dev repo, not the package repos
<t0167641>they just say uix build: error: #<unspecified>: not something we can build
<adfeno>t0167641: Unless I'm mistaken, the file passed to -f mustn't use "#:use-module", but "(use-modules ...)", perhaps this is a start.
<ng0>adfeno: in theory I'm getting paid for the work on pitivi, so collab on it wouldn't be fair. but it amounts to so little (when you consider workhours divided by payment) that in theory collab would be okay.
<ng0>ACTION wondering with all the lag if anything is getting send through
<ng0>someone else wants Docker and Flowblade, so there's two more applications lined up after/in parallel to pitivi. For Flowblade we have almost everything. For Docker I'd just mentor the packaging process.
<ng0>of course if you want to work on Flowblade, go ahead. it would work now :)
<amz3>adfeno: when you use guix, you can freeze the dependencies in binary form, just like people do with docker, mind the fact that guix can generate docker images but except if your hosting service is using docker images there is no point in doing that
<rekado_>this segfaults when you call “salmon quant” without any further arguments, because argv2 doesn’t have a 1st element.
<daviid>bavier: rekado_ the gule-cv latex dependency is because I use latex to create images for both gray and colored histograms... whe find some time, i'll use cairo (guile-cairo) but it was a lot easier(fatser) for me to do it in latex ...
<daviid>it does not depend on texlive itself, any modern latex distro will do. however, I use iwona fonts (which admittedly could be perceived as a bit too much, but I love that font and the 'look' of the results matters ... oh well
<ng0>this is more of a guile question, but I'm asking it in a Guix context: where can I find the reason for guile modules always having a maximum length of 3 words in their path / name? I've tried 4 before and this is not recognized. The guile documentation doesn#t give much insight either.
<daviid>bavier: rekado_ ping me anytme if you need help ...
<bavier>I think the packaging of those latex modules would need to be done eventually anyhow
<daviid>bavier: guile-cv configure.ac lists the packages it depends upon ...
<amz3>ng0: what do you mean by "maxium length of 3 words" like you can't nest more that 3 level deep modules?
<ng0>for example (define-module (templates foo 0 bar-baz))
<amz3>ng0: that's the module 0 that might not work, that not an issue with how deep the module is
<ng0>so (define-module (templates foo zerok bar-baz)) would be possible. just '0' in the middle would not work
<bavier>still links to 0.1.7 as the latest release
<daviid>rekado_: though, to present it to the bioinformatic friends, we really need guile maintainers to patch guile's default repl and raised exception 'systems' ... I hope they will find some time soon to proccess my bug reports (request for improvments actually) ...
<rekado_>isn’t that only important when using it with a REPL?
<daviid>for the very brave, the way to localy patch is very well (I hope) described in the manual 2.1 Configuring Guile for Guile-CV
<rekado_>imagej people don’t use their software interactively, do they?
<daviid>bavier: if you happen to try it before to publish the guix package, do read and configure your guile before any attempt to even load a small image ...
<rekado_>(it’s puzzling to me, but not everyone likes to use Emacs+Geiser)
<daviid>rekado_: it could, but not me :), emacs+geiser is a lot better (and faster)
<daviid>octave image, mathlab, opencv ... do not have 'on the fly' ide either
<adfeno>I really hope my little experiment works... can't seem to get ng0's `./pre-inst-env guix-daemon ...' to work with the guix environment he told me to use, so I decided to go on and do `./pre-inst-env guix build pitivi' directly instead of trying to start daemon.
<adfeno>.... and I just hope I don't endup rebuilding the world. ;D
<daviid>rekado_: but I know, it is difficult to convince people to use emacs+geiser (and in the ip/cv world, almost none know scheme ... so it will take some time, if I ever succeed, to get 'real users' ... but then you will help me :) and talk to your collegue ... once guile is patched, or if you patch guile for them ...
<daviid>rekado_: civodul I never took the time to answer to guix 'guile-libification' now a bit 'old' thread, but I 'm interested and thought you might talk a bit about that at fosdem (I won't be there) and select, say, one functionality that would be a good fit to land in guile-lib, they I would do it as a test ... wdyt?
<daviid>there are tons of things that are in guix but could benefit guile based projects ... (not depending o guix)
<civodul>daviid: yes we should do something about it
<civodul>first candidate is guile-gcrypt, which may well be almost ready; dustyweb? :-)
<dustyweb>wingo at one point suggested that maybe 3.0 could get Guile to the point where it's a more interesting backend target for Racket than Chez... that would be one interesting way to combine scheme powers :)
<dustyweb>(Matthew Flatt is currently working on moving Racket's VM away from its C engine to a Scheme one with Chez)
<amz3>dustyweb: did you read the new book about racket web dev?