IRC channel logs

2020-07-02.log

back to list of logs

<NieDzejkob>you need some other plumbing
<pkill9>hmm, it says it's not a record type
<mwelt>pkill9: could you provide some code?
<pkill9>ok
<NieDzejkob>for some reason 'guix system build' is taking more time than I expected, so I can't test this easily, but you could do something like `(("/lib64" ,(directory-union "rustup-libs" (list (file-append glibc "/lib") (file-append #~#$gcc:lib "/lib")))))
<mwelt>NieDzejkob: uuh nice :) I'll try, thanks a lot for your time and effort
<pkill9>mwelt: run this: guile -c "(use-modules (gnu services base)) (record-type-fields (agetty-configuration (tty #f)))"
<mwelt>pkill9: without trying I would guess you just have to use (record-type-fields agetty-configuration)
<mwelt>without constructing the actual record?
<mwelt>maybe there's something like agetty-configuration-type
<pkill9>it doesn't work without parenthesis either
<pkill9>oh well
<NieDzejkob>pkill9: (record-type-fields (record-type-descriptor (agetty-configuration (tty #f))))
<rekado>civodul, pkill9: forking srfi-37 is an option; what do you think about using Guile Config? Or would it be too much to depend on it?
<rekado>(or too inflexible for our needs?)
<mwelt>NieDzejkob: directory-union fails on the gexpression (is that how you call this?) #~#$gcc:lib
<mwelt>I am totally not able to understand how these expressions work, albeit reading the documentation several times :)
<civodul>rekado: Guile Config is for config files, right?
<civodul>mwelt: #~#$ looks fishy :-)
<civodul>ah that's to get the "lib" output
<civodul>alright, makes sense
*civodul hides
*NieDzejkob is still patiently waiting for the guix package to build
<mwelt>NieDzejkob: I think it is actually an extra package / derivation called gcc-x.x.x-lib
<NieDzejkob>mwelt: it's the "lib" output of the gcc package
<zimoun>rekado, pkill9, civodul: in addition, CLI issue http://issues.guix.gnu.org/issue/40549#7 for example -I [REGEXP] is wrong, it is not an option. But it is for --list-installed[=REGEXP]. So I am using all the time long option with = when needed, it avoids surprise
<pkill9>thanks NieDzejkob
<pkill9>i don't know rekado
<zimoun>all the short-name option with optional argument are doomed in Guix.
<zimoun>what is the use-case of "guix graph -b cypher"?
*civodul -> zZz
<mwelt>is there a way, that I can specify the version of a derivation I depend on in config.scm. (gnu packages gcc) utilizes gcc7.5 o.O
<NieDzejkob>mwelt: derivations are a lower-level concept, there's no such thing as the version of a derivation ;)
<NieDzejkob>you're looking for the gcc-10 variable
<mwelt>NieDzejkob: I come from the land of nix - everything is a derivation there ;)
<NieDzejkob>in guix, packages get lowered into bags, which then get lowered into derivations :)
<mwelt>ice-9/boot-9.scm:1515:18: object is not an exception of the right type #<&gexp-input-error input: #<gexp #<gexp-input #<package gcc@10.1.0 gnu/packages/gcc.scm:568 7f27921b2500>:lib> 7f278f3506c0>> #<record-type &package-input-error>
<NieDzejkob>yeah, I'm getting this error too, now
<mwelt>that's actually what #~#$gcc-10:lib produces
<mwelt>but man this is one hell of an error message for rookies like me ;)
<NieDzejkob>it stumps me too
<NieDzejkob>I don't see why (file-append #~#$gcc:lib "/lib") doesn't work
<mwelt>well maybe I just use hardwired path there for now?
<mwelt>all the /gnu/store/<hash-code>gcc.x.x.x-lib/lib string
<NieDzejkob>it could work...
<NieDzejkob>damn it, I swear this has worked before, but when I'm searching the irc logs, it only shows messages with either file-append or gcc, but not both
<redick>hello!
<NieDzejkob>Hi!
<redick>I just started using guix on my debian laptop today and I'm stuck on problem.
<redick>There are a few packages floating around that have optional compile time configurations and features. In my case, deutex's configure sniffs the system looking for libpng (installed both via debian as well as in guix profile). I can't figure out how to tell guix to build/rebuild deutex with png support
<NieDzejkob>redick: builds in guix are isolated, nothing you have installed on your system in any way will affect them. You'll want to edit the package definition and add something like (inputs `(("libpng" ,libpng))
<NieDzejkob>)
<NieDzejkob>in general, packages in guix should have all their features enabled
<NieDzejkob>redick: I'm not familiar with the software, what invokation could I use to test libpng support?
<redick>deutex -h | grep -qw PNG
<redick>basically run the help and see it PNG is listed in the supported image types.
<butterypancake>is the ath10k wireless firmware avaliable on guix? And if not, does it have a free license that would allow it to be packaged? This stuff confuses me greatly because it's kernel something I think
<Kozo>Greetings
<redick>NieDzejkob: sudo guix edit deutex and then adding the line... trying that now
<NieDzejkob>redick: I pushed a commit that fixes the package, it should work after you guix pull
<NieDzejkob>butterypancake: unfortunately it's non-free, thus it cannot be packaged for Guix.
<Kozo>Hey all, building a package: https://paste.debian.net/1154691/ but when I run guix build -f yuzu.scm, I get "qt unbound variable" and I have the use-module for gnu packages qt
<butterypancake>Thanks NieDzejkob!
<NieDzejkob>redick: I also had to add pkg-config to the native-inputs to help configure detect the library
<redick>NieDzejkob: thank you.
<NieDzejkob>Kozo: that's because the package isn't called that. Qt version 4 is available as qt-4, Qt version 5 is split into qtbase, qttools, and some others
<Kozo>NieDzejkob: I see, thank you. When I am doing this, I do guix search my package and use the name of what shows up. How else could I go about this to get more specific names?
<Kozo>How would I know those specifics about Qt4 and Qt5?
<NieDzejkob>Kozo: The thing is, packages in Guix kinda have two names
<NieDzejkob>there's the name field of the package record, and there's the variable they're bound to
<NieDzejkob>in most cases, they are the same, but the variables should be unique, while the name field is allowed to repeat, it is preferred than adding version numbers to the name
<NieDzejkob>you can find the variable for a package with 'guix edit qt', for example
<NieDzejkob>it takes a specification, which means you could also specify the version with `guix edit qt@4.8`
<NieDzejkob>also, to search for packages, you sometimes want to exclude hits from the description and such, and search through only the names, you can do this with `guix package -A`. It takes a regex
<Kozo>NieDzejkob: That is beautiful
<Kozo>guix package -A
*NieDzejkob will now attempt sleeping :P
<Kozo>NieDzejkob: Thank you very much for the information. Sleep well
***jonsger1 is now known as jonsger
<nckx>raghav_gururajan: Erm. I won't question why you need such an ancient ffmpeg; I'll simply make it more questionable (by disabling tests) and build it atop 64a2483e. https://paste.debian.net/plain/1154699 is available.
<dissoc>what's the way to install software that goes with a service? how is that supposed to be done? like psql for postgresql. is the expectation to create another package for the user to install to interact with the service?
<nckx>dissoc: The expectation is that the administrator adds e.g. postgresql to your operating-system's packages field.
<dissoc>i get that
<nckx>'Installing' it in a user profile works, but can easily go out of sync with the package version used by the service.
<dissoc>so is there a way to install like the client tools system wide then?
<nckx>Like I said, (packages ...).
<dissoc>oooh okay. i see now. thanks
<nckx>I should be honest and note that services can 'extend' the system profile and force random commands into it, but I'm obviously not a fan 🙂 The separation is a feature to me.
<dissoc>interesting. do you know of an example of that? just so I can see how it's done
<nckx>It's certainly not 'expected' that they do so though.
<nckx>I don't.
<nckx>Oh, interesting. It's (a) a bit more common that I thought (bah) and (b) obviously more of a 'desktop culture' thing. Few of the services I care about dare do it.
<nckx>dissoc: Look for (gnu services) that extend profile-service-type.
<dissoc>okay cool. i might play around with it a bit. im still learning. and this service isnt ready to be added yet
<nckx>dissoc: Whatcha writin'?
<dissoc>apache cassandra
<dissoc>there's a lot of stuff to it. and my intention was just to run it for development
<nckx>(Don't confuse my playful late-night grumpiness with a strong opinion. If your service makes 'cassandra' pop up in my shell I won't bite, or even notice.)
<dissoc>i dont understand but it wont show in shell
<dissoc>the service will only start cassandra but the user may use cqlsh (kinda like psql) to connect
<dissoc>so i was wondering how to give user access to cqlsh (and other tools). is the best way to make a package like cassandra-tools that the client would install?
<dissoc>it seems like that makes sense to me. but im also pretty new guix
<nckx>I'm familiar with Cassandra, I maintained it on Nix long ago. I wouldn't bother. We don't artificially split packages like that ('Debian style'?), the tools will simpy be in /gnu/store/...cassandra.../bin. If some part of the package is disproportionally huge you can use different outputs, but only then.
<nckx>Outputs are parts of a package, e.g. cassandra:lib or cassandra:doc.
<dissoc>makes sense
<nckx>You could make cassandra:cqlsh its own output if you really care about client-only size, *and* it doesn't depend on the rest of cassandra.
<dissoc>im pretty sure it's independent. it's a separate python script. but there's all the other client tools as well
<nckx>First get a monolithic working package, split it up at the very end if size is really an issue.
<dissoc>it has been the most difficult package i've made so far, which is a good thing for learning
<nckx>Java things in general can be challenging to package, and I tend to avoid them TBH. 'Maintaining' Cassandra for Nix was easy since they don't care about bootstrapping, just workin blobs. What was most difficult about it?
*nckx wonders if Scylla would be more fun to package.
<dissoc>well at first i didnt know about wrap-program. i ended up making my own which was was not good at all. it's more about every step of the way was challenging since all the prior packages i made were really simple
<dissoc>being new to guile as well
<lfam>I can relate to that. I found wrap-program hard to understand when I didn't know Guile well
<lfam>"PATH" ":" prefix
<lfam>It's just a bit tricky
<nckx>I still need to look up the definition if I haven't used it for a few weeks.
<lfam>Yeah
<lfam>It's no (version "1"), that's for sure
<nckx>(wrap-program "yes")
<lfam>I'll file the change request
<nckx>And I'll try to sleep. Good night.
<gnutec>Ok! Now I did. Register myself in freenode. rsrsrsrssrs
<gnutec>Is any app like CORE (Common Open Research Emulator) that I can install in my guix system?
<gnutec>I'll back tomorrow.
<GNUtoo>hi, I've several questions on guix:
<GNUtoo>(1) I've looked rapidely at the following: https://guix.gnu.org/manual/devel/en/html_node/Contributing.html but it doesn't really tell about the development model,
<GNUtoo>if I submit packages, who is expected to maintain them?
<GNUtoo>For instance in Linux people submiting patches are not necessarily the same people that end up maintaining it (but the quality of the patch is super high to enable that)
<bavier>GNUtoo: typically packages are maintained collectively, but also often by the original submitter
<GNUtoo>ok, my fear is to not have the time to maintain potential patches that I would send
<GNUtoo>(2) is it possible to somehow mix a host system (Parabola) and Guix together, and use some of the GuiX advanced features like GNU Shepherd and the system.scm / guix reconfigure, or do you need to install GuiX-SD for that?
<bavier>The Guix System can be installed alongside another distro in a dual-boot setup (guix requires control over the grub configuration)
<bavier>and guix as a package manager can be used on top of another distribution
*GNUtoo wondered if there was a middleground between the two
<GNUtoo>I can't manage to install GuiX-SD anyway and I would probably have to workaround many things for that: I use LVM2 almost everywere
<GNUtoo>and I can't manage to install it in a chroot either: guix system --verbosity=99 --debug=99 --no-bootloader init system.scm /srv/distros/guix/ returns something like 'In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f'
<GNUtoo>This is probably because I'm abusing many things trying to do that, and I've been having that issue for a long time, but I learned more guile now,
<GNUtoo>and I don't think it's my code
<bavier>GNUtoo: is this running from a local git clone build?
<GNUtoo>(file-systems %base-file-systems)
<GNUtoo>Here's what could potentially cause the issue ^^^ but I don't see anything wrong with it
<GNUtoo>% is like _ in C according to the cookbook
<GNUtoo>As for the git clone, I'm not, I run guix pull though
<GNUtoo>And what's more problematic here is not that it fails, it's rather that I've no backtrace, no line to look for
<bavier>hmm...
<bavier>bug report maybe?
<GNUtoo>/srv/distros/guix/ is just an empty directory that is easily accessible by root, which I run the command under, and nothing is mounted in it, so I'm most probably doing something wrong
<GNUtoo>but there should be a better backtrace
<GNUtoo>ok, I'll try to do that, thanks a lot
<bavier>thanks for trying things and sticking with it
<GNUtoo>Well, given how well designed GuiX is, I'm just looking for any excuse to use it
<GNUtoo>I've been upstreaming some GRUB patches to be able to use it on the FSF infrastructure for instance
<GNUtoo>For instance in Parabola we have automatic builds for 1 package only, which makes it super hard to add support for new architectures
<GNUtoo>Though adding packages is ultra easy, so that's the good side, so you can package stuff instead of using ./configure && make && make install
<GNUtoo>And the configuration management looks really nice in GuiX, and here I've a real use case for it
<GNUtoo>I want to accept and review patches for the Replicant infrastructure
<GNUtoo>so using GuiX there would be great
<GNUtoo>but in any case if I start using it, I'll most probably lack some packages, so I need to be able to package stuff
<bavier>cool, I think that's how many start packaging :)
<GNUtoo>my fear is the maintenance, as I've been doing a sloppy job in Parabola due to the lack of time
<GNUtoo>I've sent the bugreport. The address was hard to find (I had to use /topic on IRC for that as I didn't find it on the website), but that system looks really nice.
*GNUtoo likes system that bridge multiple users interfaces (mail + web here)
<raghavgururajan>leoprikler: You around?
<raghavgururajan>I was building a package that depends on ffmpeg.
<raghavgururajan> I got these errors for the respective line in source code. https://bin.disroot.org/?5c82512bd3e3bd88#83vWtaVqRsDhNZffikBwMdfXwmKXWUm4E8DpHFggRWFP
<raghavgururajan>How to fix those lines to overcome the errors?
<bricewge>Hello Guixers!
<mothacehe>hey bricewge!
<leoprikler>Hmm, so they want to encode raw data with avcodec?
<lrssi>Where can I find configuration examples for Guix System to build nginx + php environment?
<leoprikler>raghavgururajan: It appears they are using a rather weird signature here
<leoprikler>outbuf and outbuf_size should be fields of the AVPacket struct
<leoprikler>picture should be an AVFrame
<leoprikler>and they're missing the int* output parameter
<leoprikler>you'll have to manually patch that source
<raghavgururajan>leoprikler: I see. I am not sure what I should ptach the source with. Could you help?
<raghavgururajan>leoprikler: I was able to fix most of the build errors by patching source files via new phase. https://bin.disroot.org/?d26d253ddf012e1c#4X3z7L8913WGHQo21deYeQDoeD7GiQpertMLLimABndr
<raghavgururajan>Those two are the last ones.
<leoprikler>oof, that's going to be a biggie
<leoprikler>I'm not sure whether substitute* is enough for that
<raghavgururajan>leoprikler: I can git clone the project, edit the source and generate patch. But I don't know what to edit in source with.
<leoprikler>okay, so in ffmpeg_writer they manually allocate the audio buffer
<leoprikler> audio_outbuf = (uint8_t*)av_malloc(audio_outbuf_size);
<ArneBab>Is there a simple way to get the manifest of my current guix profile?
<ArneBab>something like guix package --save-manifest guix.manifest && guix package -m guix.manifest ?
<raghavgururajan> https://github.com/farindk/libvideogfx/blob/master/libvideogfx/graphics/fileio/ffmpeg_writer.cc
<raghavgururajan>Which line no you are referring to?
<leoprikler>266 is one of them, don't know if there's more
<raghavgururajan>Okay, 266.
<leoprikler>it seems they're using the right allocators everywhere, so that's okay
<raghavgururajan>okay
<leoprikler>Okay, I have it!
<raghavgururajan>\o/
<leoprikler>Compile FFMPEG with FF_API_OLD_ENCODE_VIDEO and FF_API_OLD_ENCODE_AUDIO :)
<raghavgururajan>Wow! That is it? No changes required in libvideogfx?
<leoprikler>well, you have to patch your 2s out again
<murmr>Hello, trying to install GuixSD, but when I get to Partitioning and select "Guided" it loops to the beginning of the installer.
<murmr>If I select Manual, none of the NVME drives are shown in the list
<raghavgururajan>Ah, so I just need to remove two lines from 'fix-build-errors phase, correct?
<leoprikler>yep
<raghavgururajan>Awesome! Thanks so much leoprikler
<mothacehe>murmr: hey! That's sadly a known issue of the 1.0.1. You can download a devel ISO here: https://ci.guix.gnu.org/download/10.
<efraim>ArneBab: I don't know of an automatic way to do it, but to create a list I'd use 'guix package -I | cut -f1,3 --output-delimiter=:' and then change any that come out like 'git:out' to git"
<mothacehe>*1.10
<mothacehe>*1.1.0
<efraim>s/git"/'git'/
<efraim>and then wrap it in the packages->manifest code
<civodul>hey ho, hello Guix!
<murmr>thank you @mothacehe
<raghavgururajan>civodul o/
<mothacehe>murmr: yw, tell us how it goes :)
<mothacehe>hey civodul!
<raghavgururajan>leoprikler: The flag is not available. https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/configure
<leoprikler>well, it's a make define IIRC, but you still need quite an old version
<leoprikler>Let's check which one
<raghavgururajan>oh! Then my other changes in 'fix-build-errors phase gonna get affected right?
<leoprikler>build against version 2.1.3 with this define
<leoprikler>yes, they might
<raghavgururajan>Make define you mean make-flags? I never did make define before.
<leoprikler>you want something make "CFLAGS=-DFF_API_..."
<leoprikler>*something like
<leoprikler>be warned, it seems ffmpeg does not actually use autotools
<raghavgururajan>I see.
<raghavgururajan>leoperikler: How did you find out that 2.1.3 supports that define?
<leoprikler>I stumbled over the define itself by using github search, then checked the same file in this version
<civodul>intriguing stuff with content-addressed derivations: https://github.com/NixOS/nix/pull/3776
<raghavgururajan>So you saw FF_API_OLD_ENCODE_VIDEO in Makefile of 2.1.3?
<raghavgururajan>Oh avcodec.h gotcha
<pkill9>civodul: what's a content-addressed derivation and what is beneficial about it?
<raghavgururajan>leoprikler, 2.8.16 also supports that define. Alteast this version is still maintained,
<raghavgururajan>leoprikler: Is this correct? https://paste.debian.net/1154732/
<civodul>pkill9: sometimes we rebuild things and obtain the exact same result modulo store file names
<civodul>a content-addressed derivation has store file names based on content, and thus doesn't have this problem
<alextee[m]>what's the proper way to use jalv.gtk3? i get lilv_lib_open(): error: Failed to open library /home/alex/.guix-profile/lib/lv2/Dexed.lv2/Dexed.so (libasound.so.2: cannot open shared object file: No such file or directory)
<alextee[m]>you basically pass a .so and jalv opens it dynamically, but it seems like it can't find the dependencies
<alextee[m]>actually nvm
<alextee[m]>that specific plugin was not built on guix
<alextee[m]>is there a way to make a package that copies binaries and "fixes" the dependent .so's to the ones guix has?
<raghavgururajan>leoprikler: https://paste.debian.net/1154734/
<murmr>Is there a ufw equivalent in Guix?
<leoprikler>oof, so first of all, that's too many flags that you're setting
<leoprikler>just CFLAGS should be fine
<leoprikler>second, you need to concatenate them into one
<civodul>murmr: what's "ufw"?
<mothacehe>murmr: don't think so, there's an iptables service however: https://guix.gnu.org/manual/devel/en/html_node/Networking-Services.html
<civodul>alextee[m]: in general don't count on being able to open a .so file not built with the same guix
<civodul>i know that's not very satisfactory, but hey!
<mothacehe>civodul: its a frontend to iptables afaik
<alextee[m]>ah ok then. well, i'll try to build this from source again when i can. last time it didnt work for some reason
<civodul>mothacehe: oh
<civodul>alextee[m]: the root "problem" is that you cannot load several libcs in the same process
<civodul>and that's what you may end up doing here
<civodul>well there's libc and all the other dependencies
<civodul>efraim: https://gitlab.inria.fr/guix-hpc/guix-past can now be authenticated!
<efraim>yay!
<civodul>i managed to mess up with the .guix-authorizations syntax
<civodul>which is kinda ironic
<alextee[m]>it can only work if it's built completely statically as a huge .so file then i guess
<civodul>maybe, yes
<alextee[m]>i have problems with fonts too anyway, that's probably more complicated
<civodul>we're used to dealing with font problems, and usually it has a happy ending :-)
<civodul>did you try "fc-cache -fv" already?
<raghavgururajan>leoprikler: "CFLAGS=-DFF_API_OLD_ENCODE_VIDEO,-DFF_API_OLD_ENCODE_AUDIO" ??
<leoprikler>space is a valid separator
<raghavgururajan>"CFLAGS=-DFF_API_OLD_ENCODE_VIDEO -DFF_API_OLD_ENCODE_AUDIO"
<leoprikler>yup
<raghavgururajan>Cool! let me try now.
<alextee[m]>civodul: yep, and i get this:
*alextee[m] uploaded an image: Screenshot from 2020-07-02 10-03-09.png (111KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/PaSOcJweraxexYFRLoJdQyiv >
<alextee[m]>here's the strace output, not sure what's wrong, it seems to find dejavu: https://www.zrythm.org/downloads/stlog.gz
<raghavgururajan>leoprikler: Building... Btw, since cc compiler is used, shouldn't we use CPPFLAGS instead of CFLAGS?
<leoprikler>CFLAGS get fed into all else in their build system
<raghavgururajan>Ah I see.
<raghavgururajan>leoprikler, works, tanks so much
<raghavgururajan>leoprikler: Now while building libvideogfx, I get:
<raghavgururajan>ld: /gnu/store/803r7cy05d473sj0cp15m8glczf8fsmi-ffmpeg-2.8.16/lib/libswscale.a(swscale.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
<raghavgururajan>So, should I do "CFLAGS=-DFF_API_OLD_ENCODE_VIDEO -DFF_API_OLD_ENCODE_AUDIO -fPIC" for ffmpeg?
<leoprikler>yep
<raghavgururajan>Cool!
<zimoun>civodul: based on your code from #42162, I am asking myself how packages are already in SWH, but I hit 'swh-error'. They limit the number of query, for saving and for looking up. Right? How can we have a view of what is archived and what is not?
<civodul>zimoun: right, we cannot do that
<civodul>:-/
<civodul>i approached them several times in the past to get a higher threshold or something
<civodul>but that hasn't happened yet
<zimoun>:(
<zimoun>because charts show the coverage and the archive like that could be nice https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/package-reproducibility
<zimoun>what is already archived and what fetching method
<raghavgururajan>leoprikler, I am still getting https://paste.debian.net/1154743/
<raghavgururajan>But number of ld error lines has been reduced now.
<raghavgururajan>rebuilding ffmpeg with --disable-static
<leoprikler>hmm, try configuring with --extra-cflags=... instead
<raghavgururajan>leoprikler, You can as configure-flags?
<leoprikler>yep
<civodul>zimoun: yeah
<raghavgururajan>Just the fpic or video/audio as well?
<leoprikler>just the defines
<leoprikler>and no make-flags
<zimoun>civodul: I will try to reapproach them about the rate. :-)
<allana>Hi Guix. I feel a little silly asking this question. Partly because I have been a guix user for around 2 years now. Also because it's probably answered somewhere in the manual or the cookbook, but I haven't come across it. How does someone list all of the packages installed in their current profile?
<lewo>zimoun: I have a script (wip) to maintain a cache to know the archived/submitted ratio
<raghavgururajan>"--extra-cflags=-DFF_API_OLD_ENCODE_VIDEO -DFF_API_OLD_ENCODE_AUDIO -fPIC"
<raghavgururajan>correct?
<leoprikler>i think you can drop -fPIC
<zimoun>lewo: cool! in scheme? :-)
<raghavgururajan>Okay
<lewo>civodul: I provided a static ip to SWH and they remove the rate limiting on this ip
<lewo>zimoun: if you can interpret the python dsl in scheme, yes!
<zimoun>lewo: my python is better than my scheme, but chut, we cannot say that here. ;-)
<civodul>lewo: heh, good for you! ;-)
<civodul>i guess we can ask again
<zimoun>lewo, civodul: so if we provide to SWH the IP of the machine behind data.guix.gnu.org, they could remove the rate.
<civodul>zimoun: i asked a few times in the past, suggested it in https://guix.gnu.org/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive/ and it yet that hasn't happened
<civodul>but yeah, we can try again
<civodul>i admit i'm a bit frustrated :-)
<lewo>civodul: i don't know how much requests you are planning to send, but iirc, they were ok for 4req/s for a batch of 20000 requests
<civodul>mothacehe: guix-minimal was meant to check whether we can still build without guile-ssh
<mothacehe> oh I see, as it was not referred anywhere and failing since a year or so I removed it. I try to restore it then.
<civodul>lewo: ok
<civodul>lewo, zimoun: for the record: https://sympa.inria.fr/sympa/arc/swh-devel/2018-11/msg00021.html
<murmr>Thanks again mothacehe. What option should I be looking up for having all packages build from source?
<mothacehe>murmr: did the installation worked? You would need to pass "--no-substitutes" to the daemon this way: https://guix.gnu.org/manual/en/html_node/Invoking-guix_002ddaemon.html.
<mothacehe>note that you can also pass it to "guix build" & friends if it's a ponctual need
<raghavgururajan>leoprikler, --disable-static worked \o/
<zimoun>civodul: thank you for the pointer. I will try to reapproach the issue. And if it could be an option "guix weather", showing if the package is archived or not.
<murmr>mothacehe: Yes it is working & GNOME is running smoothly now :)
<murmr>Is it possible to add the no-substitutes flag to my configuration file?
<mothacehe>murmr: good to hear :) Yes you can do something like: https://paste.debian.net/1154750/.
<civodul>zimoun: i think the rate limit is relatively low priority compared to tarball archival
<civodul>let's not overwhelm with too many messages :-)
<civodul>*overwhelm them
<NieDzejkob>civodul: any idea why we couldn't get (file-append #~#$gcc:lib "/lib") to work yesterday?
<zimoun>civodul: yeah for sure. :-)
<civodul>NieDzejkob: no, could you show me the context?
<civodul>i just saw part of the discussion
<NieDzejkob> (service special-files-service-type
<NieDzejkob> `(("/lib64" ,(file-append #~#$gcc-10:lib "/lib"))))
<NieDzejkob>and the error complains about an error: object is not an exception of the right type #<&gexp-input-error input: #<gexp #<gexp-input #<package gcc@10.1.0 gnu/packages/gcc.scm:568 7f854eb70aa0>:lib> 7f854b98a9c0>> #<record-type &package-input-error>
<zimoun>civodul: about raw tarball, lookup-content works, right. It falls back even for url-fetch and it fails if SWH changes permission or datetime or etc. So the hash is not corresponding anymore, right?
<murmr>mothacehe: Is there a difference in calling modify-services on %base-services VS my current config file's services value of (append ... %desktop-services)?
<NieDzejkob>murmr: you can call it at any point during the construction of your list.
<NieDzejkob>it doesn't quite make sense to make it process the services you have created, though
<NieDzejkob>so I'd call it on %desktop-services
<NieDzejkob>the nesting is more managable that way, too
<civodul>NieDzejkob: how about `(("/lib64" ,#~(string-append #$gcc-10:lib "/lib"))) ?
<civodul>does that work?
<NieDzejkob>civodul: works in isolation, but breaks in a directory-union if there is more than one entry in the list
<NieDzejkob> `(("/lib64" ,(directory-union "rustup-libs" (list #~(string-append #$gcc:lib "/lib") (file-append glibc "/lib"))))))
<NieDzejkob>various variations also break
<civodul>hmm
<civodul>NieDzejkob: could you open a bug with variants that you tried?
<civodul>that's annoying
<civodul>zimoun: SWH does archive tarballs in some cases, that's why it sometimes works
<civodul>those tarballs won't go away
<zimoun>civodul: sometimes based on what?
<civodul>zimoun: i don't know exactly
<murmr>Thanks @NieDzejkob. Noticing that after using --no-substitutes with reconfigure, it is still relying on the binary versions I currently have installed. How would I trigger a complete rebuild?
<civodul>zimoun: they take ftp.gnu.org as is, for instance
<zimoun>civodul: there are 14 packages on gforge.inria.fr and all are tarballs. lookup-content finds 9, and 5 are "missing". But it does not mean the data is not in SWH, it means we are not able to reach it, right?
<civodul>yes
<civodul>but it's practically equivalent
<zimoun>I agree. Equivalent from our point of view, not totally their. :-)
<civodul>i see two possible outcomes if they won't archive tarballs: Tarball Heritage :-), and Reproducible Tarballs
<civodul>the latter would be interesting
<zimoun>if they do not expose raw tarballs reachable which classical checksum, their Archive will be hard nor impossible to use in practise.
<zimoun>s/which/with
<zimoun>civodul: and a service providing checksum->SWHID means we trust SWH. Well, IMHO, it is ok because it is an Archive for abandonwares, not another full mirror.
<rekado>I’d be happy if someone could comment on this commit: https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-haskell-updates&id=a2107cb970aaa881fe82f6770a13a041e752f8df
<rekado>yes, it looks terrible
<rekado>but it allows us to cut out gigabytes from package closures involving Pandoc.
<rekado>I should also note that I often wonder if we couldn’t get rid of these labelled lists of inputs and use the inputs directly (not necessarily via gexps). In most cases we don’t actually need labels for all inputs.
<rekado>civodul: thank you for not only implementing the bulk of the “guix pull” commit authentication mechanism, but also for writing this very detailed blog post
<rekado>I always enjoy reading your blog posts.
<mothacehe>bricewge: Thanks for your gsoc update mail. Stefan is also trying to add NFS support for rootfs here: https://issues.guix.info/41820. I need to dive into the network boot topic, but is there any chance Stefan patch can work without having nfs-utils in the initrd?
<civodul>rekado: thanks! i think it's useful to give Guix folks a clearer picture of all this, but i was also hoping we could get feedback from outsiders and security folks
<civodul>but it seems the post went largely unnoticed
<rekado>“guix pull” appears to be broken. I just ran it as root on berlin and it failed to build /gnu/store/6w2ym8n1lz08jz32a3s8q0bg9nazg7zb-guix-1.1.0-15.03deb1e-checkout.drv
*jonsger enjoyed reading it
<civodul>rekado: that's from "guix build guix" or similar, no?
<civodul>ah no, -checkout
<civodul>mothacehe: you updated the 'guix' package today, right?
<Lurkki[m]> https://chat.privacytools.io/_matrix/media/r0/thumbnail/privacytools.io/rscgTjBJagVJOJQUcoVHSyJO?width=800&height=600
<rekado>this is what it looks like:
<rekado> https://paste.debian.net/plain/1154765
<civodul>if mothacehe isn't around we can revert of fix the hash
<Lurkki[m]>getting this error when trying to install guix on ubuntu
<civodul>yeah, wrong commit
<mothacehe>civodul: yep, i'm on it!
<rekado>Lurkki[m]: did you run “gpg --import” as root?
<rekado>Lurkki[m]: you’re running the script as root, so “gpg” also needs to run as root.
<Lurkki[m]><rekado "Lurkki: did you run “gpg --impor"> no, since it doesn't tell that
<Lurkki[m]>i'll try it
<mothacehe>should be fixed, sorry.
<Lurkki[m]>that worked
<rekado>well, it’s not entirely clear; this has been reported recently, so there’s a good chance the hint will be modified to include ‘sudo’ or a reference to root.
<rekado>mothacehe: thanks, I’m trying again
*rekado wants to reconfigure berlin and the build farm to deploy the childhurds
<civodul>rekado: cool!
<civodul>i can give a hand if needed
<mothacehe>rekado: nice :) I also sent a small patch to guix-sysadmin!
<mothacehe>(not about childhurds)
<civodul>mothacehe: FWIW i always do "guix build --check -S guix" after "make update-guix-package"
<civodul>to make sure i didn't inadvertently use the wrong commit/hash
<mothacehe>civodul: oh, thanks, I'll save this for next time :)
<civodul>rekado: re pandoc, all its dependencies now have a "static" output?
<rekado>civodul: yes
<civodul>i'm a bit concerned about the calls to package-closure
<civodul>it could make it quite expensive to compute the derivation of that package
<rekado>the haskell-build-system has a new ‘static’ output and places the .a files there.
<civodul>neat
<civodul>perhaps we should instead use package-input-rewriting to define a 'static-ghc-package' procedure or similar?
<rekado>good idea, I’ll try that
<civodul>also, static linking means no grafts
<civodul>maybe that's acceptable in this case
<rekado>there are two kinds of static linking here: static linking of the Haskell bits and static linking of the binary
<NieDzejkob>civodul: Sorry for taking the time, I figured out how to do it, but I've sent a bug about the confusing errors (#42164)
<NieDzejkob>I still don't understand why this is the way it must be written to work
<civodul>NieDzejkob: thanks, i'll take a look, it seems needlessly confusing
<civodul>rekado: the binary still uses shared libs for its C dependencies, like libc, no?
<janneke>rekado: yay, that's great
<NieDzejkob>rekado: the processing code for inputs and native-inputs is duplicated, maybe it should be a function? It could be useful for other packages, too, after all
*janneke hasn't found a sulution for the the sqlite locking weirdness yet...
<smithras>hello all!
<jonsger>why is mercurial so slow ^^
<civodul>on patch review by email: https://nhaehnle.blogspot.com/2020/06/they-want-to-be-small-they-want-to-be.html
<mothacehe>I agree with the author or gerrit being usable, compared to Github/Gitlab that make reviewing a nightmare.
<mothacehe>janneke: rekado: there's maybe an issue with childhurd: https://ci.guix.gnu.org/eval/14787/log/raw.
<civodul>the author says Gerrit is doing a better job than Git{Hub,Lab} tho
<janneke>mothacehe: oops? i added that to (sysadmin build-machines)
<rekado>mothacehe: I just updated /root/maintenance
<rekado>the /etc/guix/machines.scm file doesn’t have access to (sysadmin build-machines)
<rekado>I suppose we could add the module location to the load path near the top of that file
<rekado>build-machine-name isn’t exported
<civodul>rekado: it's clearer for /etc/guix/machines.scm to not have such dependencies
<rekado>yes, but currently it does have a dependency on (sysadmin build-machines)
<rekado>I also had to replace build-machine-name with (@@ (guix scripts offload) build-machine-name)
<rekado>‘guix offload test’ shows me again that at least one of SSH tunnels doesn’t work
<rekado>disabling dmitri
<katco>i'm attempting to use the proprietary nvidia drivers with guix system and Xorg is failing to start. the kernel modules are loaded, the Xorg module is loaded, but i get `(EE) NVIDIA: Failed to initialize the NVIDIA kernel module [...]`. there is no indication of any error in `dmesg`, but in the Xorg log there is `xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)`.
<katco>does anyone have any ideas? research shows fixes for other distros as `chomd u+s /usr/bin/xinit`
<rekado>mothacehe: /gnu/store/4i1b7dxfpxi72dq2vk7igdajnfx2bsvm-guile3.0-guix-1.1.0-16.d3eee3c.drv cannot be built due to test failures
<rekado>katco: sorry, we cannot help you with proprietary drivers.
<katco>rekado: well, some may choose not to :) "can't" is an overstatement i think
<rekado>we don’t use the official Guix communication channels to support proprietary software.
<katco>is that imposed on all people using Guix communication channels, or a choice made by some?
<civodul>hey katco!
<civodul> it's the project's policy
<katco>heya civodul
<mothacehe>rekado: oh it's the timestamp issue again. There's a machine causing clock issues but I can't find which one is this.
<katco>civodul: yeah, i'm aware of GNU's stance on this, but it's unclear to me whether this is an imposition or a choice people can make
<mothacehe>I was discussing this with civodul this morning here: https://lists.gnu.org/archive/html/bug-guix/2020-07/msg00024.html
<rekado>mothacehe: I ran guix system -L modules reconfigure berlin.scm --no-offload on berlin
<rekado>so … shouldn’t this mean that berlin has weird date/time settings?
<mothacehe>oh then the guilty machine would be berlin, at least it reduces the search :)
<mothacehe>I tried to run a "make check" by hand on berlin yesterday without triggering the problem
<katco>rekado: civodul well, thanks for responding anyhow. sorry to make waves, i'm just trying to use what hardware i have.
<civodul>katco: np!
<civodul>like i said it's really been project policy from day 1, though i don't know if it's written as is somewhere
<civodul>but of course, everyone's very welcome for general Guix questions here :-)
<jonsger>katco: does nouveau not work?
<katco>jonsger: nouveau works beautifully for some basic tasks, but not for other things
<rekado>more failures since the maintenance.git upgrade: guix offload: error: /root/maintenance/hydra/modules/sysadmin/build-machines.scm:216:35: extraneous field initializers (net-options)
*rekado tries to fix it
<rekado>mothacehe: I’m offloading the build now
<rekado>so far no test failures
<raingloom>haskell peeps, how do i fix missing base dependency? do i need to wait for wip-haskell-updates to be merged? (base >=4.9 && <=4.12)
<rekado>raingloom: wip-haskell-updates does not include upgrades to a more recent LTS release of the haskell platform
<rekado>raingloom: I know of nobody who is working on an upgrade like that.
<raingloom>rekado: heck. so i do need a newer LTS version?
<rekado>…maybe
<rekado>I don’t know what base version we are currently providind
<rekado>*providing
<rekado>but it seems that your package doesn’t like our version
<rekado>and I think we don’t have anything beyond version 4.12
<rekado>so I’d say: yes, we™ should upgrade all Haskell packages
<rekado>raingloom: would you like to be part of this mythical ‘we’?
<raingloom>rekado: idk if i have the know-how. i know basic Haskell but not how the ecosystem works.
<raingloom>but i could try.
<mothacehe>rekado: Ok! How do you force a build offload?
<raingloom>rekado: although i have other bugs i wanna fix first. (like that damn GVFS thing)
<mothacehe>I'm monitoring "dmesg" output of berlin to see if there's some funny things with the clock. Nothing so far.
***afk11` is now known as afk11
<rekado>mothacehe: simply by not passing ‘--no-offload’
<rekado>raingloom: well, I *also* don’t know about how the ‘ecosystem’ works (despite studies in ecology) or what that even means for Haskell, but for package upgrades you don’t need to know much
<mothacehe>oh ok, and then it does not complain about the locally cached failure I guess?
<rekado>mothacehe: I cleared the failure
<mothacehe>Ha! I tried that without success the other day? How did you do it :)?
<rekado>raingloom: the primary rule is just to upgrade everything to the same level. We don’t want to have some packages at an old LTS, others at a newer LTS, and yet others at whatever the most recent version is on Hackage.
<zimoun>civodul: cooking for downloading using the Web interface of SWH is sooo long...
<rekado>guix gc --clear-failures /gnu/store/…-guile3.0-guix…
<rekado>mothacehe: the build succeeded
<mothacehe>thanks rekado!
<raghavgururajan>substitute* is case-sensitive right?
<rekado>raghavgururajan: yes
<civodul>zimoun: cooking is an asynchronous operation, which sounds reasonable to me
<raghavgururajan>rekado: Cool!
<raingloom>rekado: i see. i'll take a look. do we have plans to just import Hackage like how Nix (AFAIK) does it? or would that kill the build farm?
<zimoun>civodul: I know, but the oven seems long to heat :-)
<NieDzejkob>sneek: later tell mwelt: I figured it out, see http:// issues.guix.gnu.org/42164
<sneek>Okay.
<raingloom>rekado: it looks like we have base-4.12.0.0 in the latest ghc, so i'm not sure what the issue is. -_-
<janneke>rekado: oops, net-options was added later; a pull should help if that's at all feasible
*janneke feels pretty bad about all this -- thanks so much for covering for me here
<zimoun>raingloom: do you mean "guix import hackage" or stackage?
<rekado>janneke: don’t worry about it
<rekado>janneke: the problem was with the pull and that just triggered the problems due to the machines.scm
<rekado>it’s easy to work around this
<rekado>if anything I should have first pulled before updating maintenance.git
<rekado>raingloom: do you mean a wholesale import of all packages? That would be fine.
<rekado>but we don’t want the sort of automatic importing that they use for CRAN packages
<rekado>(which I’m certain makes many packages unusable)
<raingloom>zimoun, rekado: wholesale import. in the long term, i don't think anyone wants to update everything by hand.
<rekado>that’s confusing to me
<rekado>you’d *still* have to update everything
<rekado>once in a while
<rekado>and someone’s got to check that updates don’t sneak in proprietary software
<rekado>and that everything still builds
<rekado>you can’t quite get around the maintenance burden
<rekado>unlike Nixpkgs we care about good descriptions as well, so we also can’t fully automate that
<zimoun>raingloom: magic does not exist :-) It cannot be fully automatic.
<raingloom>hmm. makes sense. although it could just be made automatic with human supervision after every step.
<rekado>that’s pretty much what we™ do for CRAN and Bioconductor
<raingloom>so we(tm) "just" need to implement the same thing for Haskell?
<rekado>but importing all those packages is tricky, because both repositories also host proprietary software, packages that have incorrect licensing info, or that include pre-built stuff that we need to figure out how to build
<rekado>the same thing exists for Haskell (stackage and hackage)
<rekado>we have the importers
<rekado>(do we have recursive importing for these two?)
<rekado>the CRAN and Bioconductor importers will also tell us what inputs have changed; that’s probably missing from the Haskell importers
<raingloom>rekado: doesn't the importer only work for importing new packages? i know there's `guix refresh` but i haven't looked at that deeply yet.
<rekado>raingloom: no, the importers are also updaters
<rekado>when I feel bored I run ‘guix refresh -t cran,bioconductor -u’ and work on the recommended changes it tells me about.
<civodul>:-)
<rekado>the CRAN/Bioconductor updaters also import the packages once more to compare inputs
<civodul>Someone (sometimes referred to as "we") should review maven-build-system: https://issues.guix.gnu.org/42100
<civodul>it looks like serious business
<janneke>oh my
*civodul is unable to get anything done today
<roptat>it is serious business :)
<janneke>roptat: looks like you did something impossible!
<roptat>yep ^^
<roptat>it was hard, but also a lot of fun to figure everything out
*mothacehe discovered offloading issues on Berlin, it might explain why we have so much idle time on the build farm.
<roptat>the only negative is that I already had everything working three months ago: https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00072.html
<roptat>but it took me all that time to create patches on top of master, because I'm working on my free time
<janneke>oh wow...yeah that's terrible
<NieDzejkob>damn, too bad I don't know anything about java build tools
<janneke>"the maven-build-system only has the very basic plugins by default" <= i'm afraid that if you use such language in your blog post, the fact that this is actually sheer amazing may escape some people ;-)
<jonsger>hm, clicking on mailto: links does not work anymore but `xdg-open mailto:` is still opening a new message window of icedove...
<NieDzejkob>jonsger: I'd try logging out and back in
<NieDzejkob>(alternatively, restarting your terminal and the program you're clicking the links in. Try starting the latter from the terminal, too)
<NieDzejkob>I suspect env vars :P
<jonsger>NieDzejkob: will try that later, thx
<civodul>rekado, mothacehe: on berlin, "sudo guix offload status" now fails with a weird error (perhaps reference to 'this-record' or similar?)
<rekado>it still does?
<civodul>yeah
<rekado>I just ran ‘guix offload test’ as root and it worked fine
<civodul>i really thing we shouldn't include (sysadmin modules) in there
<civodul>*think, even
<civodul>perhaps that an environment issue with sudo
<rekado>‘guix offload status’ also worked fine
<rekado>FWIW ‘guix deploy’ still complains about net-options
<civodul>uh
<civodul>rekado: besides, can i "herd restart guix-daemon"?
<civodul>that would give us the perf improvements reepca & i worked on recently
<rekado>sure
<NieDzejkob>huh, why is there no substitute for openjdk-13? The most recent build on CI is successful, but the derivation hash is different...
<janneke>"that's impossible!"
*janneke is running a near-identicial childhurd setup on their laptop
<janneke>*identical
<roptat>\o/ guix gc just removed 100GiB from my hard disk ^^'
***nckx sets mode: -r
<NieDzejkob>depending on your gc root hygiene, that might be 100GiB of caches you'll need to rebuild ;)
<roptat>I have some huge sources and packages as gc roots, so hopefully I don't have to rebuild them
<nckx>sneek: Later tell gnutec: I've disabled the registration requirement, was due to recent spam. But it's good to register in any case.
<sneek>Will do.
<roptat>I saw a few texlive-* stuff so I'm a bit worried
<roptat>the rest is mostly variants of java packages I've been rebuilding
<nckx>raghavgururajan: Did the downloaded ffmpeg fulfil all your wishes?
<roptat>the weird thing is that I only have 50GiB of space left on my disk now...
<roptat>but guix gc said 100000MiB
<jonsger>NieDzejkob: still does not work, even after login in to MATE
<NieDzejkob>jonsger: okay, what program are you clicking the link in?
<jonsger>in icecat
*alextee[m] found another cool app written in C# https://github.com/BleuBleu/FamiStudio
<alextee[m]>we need "MonoDevelop" apparently to build it
<jonsger>it does not work from other programs either, still xdg-open is fine
<NieDzejkob>jonsger: have you tried starting the programs from your terminal? is anything printed when you click the link?
***affinespaces_ is now known as affinespaces
***stefanc_diff_ is now known as stefanc_diff
***CcxWrk_ is now known as CcxWrk
<jonsger>NieDzejkob: it's strange. running programms from terminal starts them, but don't print their log into the terminal. I get a newline and can use the terminal normal. That's also strange
<NieDzejkob>all of them?!
<jonsger>yeah
***sneek_ is now known as sneek
<jonsger>hm, libreoffice is working as excepted and the mailto: stuff works
*jonsger is even more confused
***__shymega__ is now known as shymega
<gnutec>Is there a solution to replace Common Open Research Emulator?
<sneek>Welcome back gnutec, you have 1 message!
<sneek>gnutec, nckx says: I've disabled the registration requirement, was due to recent spam. But it's good to register in any case.
<bavier>gnutec: is a replacement necessary? or would creating a package work?
<civodul>what's this?
<gnutec>sneek: I did! Because I think I was register, but I'm not.
<civodul>hmm "pdfTeX error: /home/ludo/.guix-profile/bin/pdflatex (file fir_junpg2.enc): cannot open encoding file for reading"
<raghavgururajan>nckx: Yes! Thanks so much.
<gnutec>bavier: There is no CORE in guix package base. https://www.nrl.navy.mil/itd/ncs/products/core
<zimoun>I am not a Category Theorist guy but reading the The Store Monad section, I am confused. The monad, is it a State Monad? (I guess yes it is) But then Store Monad is badly choosen because store refers to a CoMonad, which can be seen as the dual of state.
<bavier>gnutec: right, I see. My suggested solution was to create a package for it.
<civodul>zimoun: then you're more of a category theorist than i am :-)
<civodul>%store-monad = %state-monad
<civodul>i was unaware of another "store monad"
<zimoun>civodul: I have seen the alias. :-) Well, the concepts are not enough clear to me, but The Store Comonad is something different to The State Monad.
<gnutec>bavier: https://github.com/coreemu/core/blob/master/LICENSE
<zimoun>civodul: Anyway about my thoughts about Category Theory. :-) My initial question I have was about the hash in /gnu/store/<hash>-*, that's why I open derivations, monads and so on. :-) It is sha256, right? Base16? Where is it computed?
<bavier>gnutec: bsd-2 license
<terpri_>base32 encoding of sha256 hash, iirc?
<civodul>yes
<civodul>nix-base32
<civodul>zimoun: ↑
<civodul>it's computed in various ways and in various places :-)
<civodul>see (guix store) and (guix derivations)
<civodul>or nix/libstore/*.cc for a C++ version
<civodul>short story is that outputs of fixed-output derivations as well as "sources" are content-addressed
<civodul>the rest is "input-addressed"
<zimoun>thanks. But they appears shorter, 32 chars and where the package is defined, it is 51 characters (more or less my error when counting)
<zimoun>civodul: thanks for explaining. I was not sure for (guix store) and (guix derivations).
<zimoun>in (guix derivations) derivation-hash, bytevector->base16-string is used, that's why I thought it has base16.
<nckx>gnutec: sneek is a bot and only speaks botsnack ;-)
<civodul>zimoun: BTW, i was rereading past discussions and stumbled upon this: https://sympa.inria.fr/sympa/arc/swh-devel/2016-07/msg00021.html
<civodul>we're back to this: should we store git-tree hashes instead of/in addition to nar hashes, that is the question
<civodul>until we do, SWH "directories" are inaccessible to us
<zimoun>civodul: except if SWH provides a bridge. Which means we have to trust this bridge.
<civodul>not an option
<civodul>well
<civodul>i mean that would work, but the discussion above suggests they're unlikely to store anything other than git-tree hashes
<civodul>(which is understandable)
<zimoun>well, the pristine-tar idea could be an option
<lispmacs[work]>sneek: botsnack
<sneek>:)
<zimoun>but it is difficult to know what SWH wants, I mean this point is on the table since 2016.
<civodul>one way to look at it is that they've defined a model and as users we have to adapt
<civodul>but yeah, it's tricky
<civodul>zimoun: is everything on track for tomorrow? :-)
<zimoun> civodul: we have checksum noted C, they have SWHID noted S, but somehow we need 2 hash functions such that f(C)=h(S), and everybody will be happy. :-)
*Lurkki[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/jCanslrEMMKfARmhZzluupou >
<zimoun>for tomorrow, yes I guess. :-)
<Lurkki[m]>what does this mean
<zimoun>for the curious reader about Monad vs Comonad https://bartoszmilewski.com/2017/01/02/comonads/ but be prepared... :-)
<zimoun>civodul: the hash appears shorter in /gnu/store/hash than (sha256 (base32 of packages, 32 chars vs 51 (more or less my error when counting). And in (guix derivations), derivation-hash uses bytevector->base16-string. Well, I am confused.
<gnutec>nckx: Ok! But I will forget again in any moment. HAHAHAHAHA
<civodul>zimoun: see compressed-hash in (guix store)
<zimoun>civodul: ah moment! :-) Thank you
<gnutec>bavier: https://www.gnu.org/licenses/quick-guide-gplv3-compatibility.png
<lispmacs[work]>if I want to run a "guix search" command in the latest commit of guix, without upgrading my current profile, do I need to create another profile, or is there some other trick that is less bother?
<zimoun>lispmacs[work]: guix pull -p /tmp/next and then /tmp/next/bin/guix search
<zimoun>or guix time-machine --commit=<lastest> -- search
<ryanprior>lispmacs[work]: time-machine works both backwards and forwards, so you can "guix time-machine --branch=master -- search <query>"
<lispmacs[work]>ryanprior: will --branch=master pull the latest commit?
<ryanprior>I'm not a hundred on that, but I think it does (the docs say it "uses the tip of the specified branch")
<ryanprior>Possible it could use the tip that's already locally available but that would be boring if so :\
<zimoun>lispmacs[work]: yes it does.
<lispmacs[work]>zimoun: okay, thanks. both solutions looks simple, am trying zimoun's suggestion first
<zimoun>lispmacs[work]: it depends how many search you plan to do. :-)
<ryanprior>Is the /tmp/next solution a lot faster or something?
<lispmacs[work]>well, actually what I do is I read through the commit email digest report, and then do a "guix show" to find out info on packages that were just added
<zimoun>ryanprior: no, it is roughly the same. But it avoids to go to ~/.cache/guix/checkout/hash and does some check for the second search
<bavier>gnutec: guix has many bsd-2 packages already. packages themselves do not need to be compatible with guix's license as long as they are free licenses.
<zimoun>however, be careful with the new authentication machinery because with the /tmp/next then it will raise an error suggesting --allow-downgrades at your next regular pull.
<zimoun>time-machine avoids this annoyance, well it should. :-)
<ryanprior>Yeah, time-machine definitely seems like the right solution, if there's any advantages to the /tmp/next method then maybe we can figure out a way to bring those to time-machine too?
<lispmacs[work]>just curious, anybody ever try like a "thin client" setup, where the store is located on a separate computer, and the client computer mounts just one profile?
<zimoun>Hey! Have a good evening (or day) and see you all tomorrow on #guix-hpc for a great Reproducible Science Hackathon day! :-)
***familia_ is now known as familia
<gnutec>bavier: Ok! I'll try to use "guix pack" in this case. I think I need to create a file.scm to do this.
<raingloom>new and fun bug (?): file manager shows that greg.lan is available but ssh and ping don't see it.
<raingloom>but in a sudo shell it finds it. :|
<raingloom>god i hate computers
<raingloom>ugh. i really should work on making offloading easier to set up. every time i try to use it i remember how painful it is.
<raingloom>...well, now it works but i don't know why. ...computers.
<raingloom>ok. i have idris2 built on machine B and my channel checkouts are in sync on both machines. if offloading is working as advertised, it should just copy the existing binaries.
<rekado_>hmm, ‘unknown error while sending files over SSH’
<raingloom>fun fact: if both machines are set up to offload to eachother, you get a cycle
<roptat>oh, offloading is recursive?
<raingloom>roptat: seems to be. at least that's what my logs indicate. the `guix build` on bingobongo.lan got offloaded to greg.lan, which then said it was waiting for build slots on bingobongo. so it all locked up.
<roptat>I see
<raingloom>it's also not just copying the idris2 package, which is weird. i'm pretty sure i have it in greg.lan's store.
<raingloom>....oh, right. the guix commits must be different.
<walter[m]1>hi guix, I'm not able to mount my external hdd using udisks without authenticating as root, anyone know why?
<raingloom>walter[m]1: could you describe your setup? i'm working on a possible related bug and could use more data.
<ngz>Hello. I get an error when I try to use the latex importer. For example, the command "guix import texlive newunicodechar" fails. Can anyone reproduce it?
<bavier>ngz: same here
<ngz>OK, thanks.
<ngz>Oddly, when I run the reported svn command manually, I get no error.
<walter[m]1>raingloom: thanks for the help, here's my system file: https://paste.debian.net/1154851/
<raingloom>by the by, re: offloading, yggdrasil could be useful for offloading things across moving hosts.
<raingloom>walter[m]1: thanks! taking a look in a bit.
<walter[m]1>raingloom I switched from using %desktop-services to a more hand built setup on top of %base-services, so it's very possible I did something wrong
<raingloom>walter[m]1: ah, also an sddm setup.
<raingloom>you don't even have to switch completely from %desktop-services to get this bug
<raingloom>it seems to me that not using gdb breaks a bunch of things, including GVFS based mounting.
<raingloom>s/gdb/GDM/
<raingloom>walter[m]1: here is my bug report https://issues.guix.gnu.org/41927
<raingloom>42076 might also be of interest
<raingloom>walter[m]1: could you describe what you did as a reply to 41927? it might just get some people's attention and it would be good to have a more permanent record of this bug.
***gavlee_ is now known as gavlee
<walter[m]1>raingloom I read your report and I'm not sure they're related? my issue is just that udisks can only mount as root
<walter[m]1>I mean it could be related I don't know much about udisks and polkit and such
<raingloom>walter[m]1: it's possible they aren't. i don't use udisks directly, but i also had issues with external devices (which isn't in the bug report (yet)) and that seems rather closer.
<raingloom>(nevermind, it is now on the tracker. https://issues.guix.gnu.org/41927)
<walter[m]1>later I'll give it a spin with a default gdm %desktop-services to see if that fixes it
<walter[m]1>if it's sddm specific than I'd be happy to add a report
<NieDzejkob>raingloom: re gvfs: do you use elogin?
<walter[m]1>now I'm getting the lovely problem where switching desktop configurations leaves me in a broken state
<NieDzejkob>yeah, elogin does that
<NieDzejkob>specifically, either adding or removing it
<walter[m]1>is there a workaround? I can't even shut down cleanly
<gnutec>tcl is not a great enemy of free software foundation? And CORE (Common Open Research Emulator) was made with this program language. https://www.gnu.org/software/guile/manual/html_node/Early-Days.html
<raingloom>NieDzejkob: i think so.
<raingloom>walter[m]1: it's not so much SDDM specific and it is GDM specific. as in, GDM work, everything else I tried doesn't.
<raingloom>oh, that's another fun bug. also you can't `herd stop xorg-server` because it breaks local login across all virtual TTYs.
<walter[m]1>raingloom yeah exactly, logins are broken and can't even power off...
<raingloom>walter[m]1: i wonder if there's an existing issue for that.
<walter[m]1>I suppose I should start one if not
<walter[m]1>I swear that issue corrupted my grub once, but I don't know enough to be sure that was why
<GNULinuz>Hi. I'm selling GNU/Linux licenses. $99 for single computer, $49 for each computer if you purchase 25 or more licenses. Bitcoin payment only!
<NieDzejkob>GNULinuz: Cool, I've always wanted a GNU/Linux license! Now that I ddg'd some, though, most people seem to be giving them away for free. What gives?
<murmr>GNULinuz: How much are your Hurd licenses?
<GNULinuz>murmr: same, as Hurd is GNU software
<NieDzejkob>GNULinuz: but then shouldn't we get a discount if we don't use the Linux part?
<nckx>GNULinuz: So also free?
<GNULinuz>You have a right to use GNU and Linux kernel software with this license.
<GNULinuz>Unfortunately, we don't sell them separately.
<nckx>GNULinuz: You have that right without the licences, too. What does your licence add to software that is already free?
<GNULinuz>Certificate of Authenticity with product key, at least
<nckx>I assume this includes full patent indemnification too, right?
<nckx>
<leoprikler>inb4 people start selling linux license selling licenses
<ngz>Let's sell Guix channel introductions.
<nckx>GNULinuz in #devuan: 'Without license you're not allowed to run Devuan.'
<murmr>M-x register-product-key
<nckx>So that's another advantage of not buying one.
<nckx>No such restriction on Guix.
<Blukunfando>You do have that restriction, too; only, in both cases, you already have the licence, unless you got the software from someone who broke it.
<nckx>Blukunfando: That strictly applies to copying, not running, but IANAL and this is not a serious discussion.
<mbakke>the last 5% of Ganeti packaging took me like three weeks, but now DRBD mirroring, live migration and master failover has been tested and verified
<civodul>mbakke: neat, congrats!
<civodul>it's always the last bits that take the most time
<mbakke>indeed :-)
*mbakke begins a long commit squashing journey, prepares blog post
<nckx>mbakke: Wow.
<mbakke>I rely on something of a hack for master-failover though, and the hack is outright dangerous until https://issues.guix.gnu.org/issue/42167 is fixed
<mbakke>will look into it once I have my branch "under control" :P
<civodul>heh
<civodul>janneke: pretty cool to have provenance tracking for Hurd images!
<janneke>civodul: yeah...i was suprised it didn't already work; some thinko/typos
<janneke>but figured it would be nice, esp. when we get childhurds up :)