IRC channel logs


back to list of logs

<nixd>Hey, has anyone ever had an error after defining a package returns "In procedure bytevector->base16-string: In procedure bytevector-length: Wrong type argument in position 1 (expecting bytevector): followed by the packages SHA256 (which I got from guix hash) when trying to build the package?
<rekado>nixd: do you use (sha256 (base32 …)) or just (sha256…)?
<mbakke>nixd: I've seen a similar error when I had a typo in the hash string.
<rekado>gtk+ 3.94 switched to meson, which makes the update more difficult than it should be :-/
<Thra11>I ran 'guix hash -f base32 /gnu/store/blahblahblah...' and copied the result into my package definition. However, I get this error: invalid-base32-character [character: #\\o string: "nbhy2l253okuogpfydgbjezt4pads3pjlewlvuvxw6gbkr677loa"] I don't understand why.
<rekado>(also new dependencies such as gstreamer-player, which seems to be unpackaged.)
<nixd>rekado, I used sha256. I also tried the same thing with sha256( base32 with the hash returned from guix hash -f base32, but I got the same error as Thra11. Also, mbakke this actually happened when trying to use an adaption of your custom kernel config.scm, trying to make it work with 4.17.3
<rekado>Thra11: the default is to use nix-base32, not base32.
<rekado>ACTION —> zzZ
<civodul>rekado: isn't gtk+ 3.94 a prerelease?
<civodul>the number looks like it
<civodul>good night!
<nixd>mbakke, I also copy pasted the strings directly from the output of guix hash, so I doubt its actually the wrong sha256 string
<mbakke>nixd: Make sure you use `guix hash -f nix-base32` (the default) as rekado mentioned.
<nixd>I did. I tried both using (sha256 "*") with the output of "guix hash *" and (sha256 (base32 "*")) with the output of "guix hash * -f base32", the former returns the error in my first message, the latter returns the error Thra11 gave
<Thra11>I'm just replacing my hashes with ones calculated by running 'guix hash /gnu/store/...' without the base32 format specifier...
<mbakke>nixd: You should use the output of `guix hash` inside (sha256 (base32 ...)).
<nixd>mbakke Seems to work. I don't know how I missed that. Thank You!
<Thra11>My problem is also fixed now. I think it's a little bit confusing that base32 in guix and the base32 format argument to guix hash are different formats, but I guess it's for a reason.
<civodul>Thra11: 'guix hash' defaults to the nix-base32 format, and that's also what's expected in package definitions
<lfam>Thra11: 'base32' is the wrong format to pass to `guix hash`. We use the 'nix-base32' format, which is the default for `guix hash` when the format argument is not specified
<apteryx`>does this use of phase seem legit?
<apteryx`>it gives me the following output when built:
<mange>Your assoc-ref for set-paths looks like its arguments are in the wrong order?
<apteryx`>haha, right
<sgsz>Hi, does anyone have any experience with running GuixSD on the VPSs at or other small business VPS providers?
<sgsz>I see that supports NixO so GuixSD could be ok too:
<sgsz>And by small business I mean not AWS, Digital Ocean or GCP.
<brendyn>sgsz: I don't but it'd be great if you could try testing it and report your findings
<sgsz>Yeah I'll be giving it a go soon, I'll make sure I write up how to do it (or how not to :P )
<ray__>I'm trying to package nethack, which has a custom license. Should I add the license to guix/licenses.scm, or just use fsf-free? Additional note: although the nethack general public license is not specifically approved as free by the FSF, it is a free software license.
<efraim>rust is killing me on aarch64, now have to fix the 1.26.2 build
<rekado_>Hi Guix!
<civodul>Hello rekado_ & all!
<rekado_>so … if the version of gtk+ that I’m working on is actually a prerelease then the GNOME updater isn’t doing the right thing.
<rekado_>I just blindly ran “guix refresh -t gnome -u” and started working on the results.
<civodul>it's supposed to do the right thing
<civodul>i remember adding provisions to filter out prereleases
<civodul>and things with odd minor version numbers
<civodul>maybe gtk is a bit different though
<civodul>so is the version you were looking at actually a prerelease?
<rekado_>I haven’t looked more closely at this, but I’ll do this today
<roptat>hi guix!
<kmicu>( ^_^)/
<civodul>hey hey!
<civodul>snape: i'm done reviewing the Cuirass patch set! \\o/
<civodul>really happy to see this moving forward
<snape>hey civodul, thanks! I'm writing a very long reply :op
<snape>it's a bit tricky
<civodul>it is!
<kmicu>ACTION [not seriously] wonders how many folks see (focus on) ‘ass’ in ‘Cuirass’.
<civodul>heh, a name change is in order...
<snape>I never noticed :p
<kmicu>We could go with Coq path and keep the name nevertheless.
<snape>haha, those French people...
<kmicu>At least the new build system is not ‘Uranus’.
<efraim>I noticed almost imediately
<civodul> is nice!
<snape>Cuirass is a French word too, so for us, French people, it's more difficult to notice
<snape>I guess
<kmicu>No js‽ I love it. ヽ(*^▽^)/
<civodul>yup, nice work
<kmicu>That UI is soo usable in w3m/Eww. I love it.
<kmicu>(Though green succeeded indicators are not visible yet.)
<civodul>i wonder if guix-hydra.el exploits all the HTTP API
<snape> now
<jonsger>how fast compared to hydra :)
<snape>it also does much less :p
<snape>it builds my manifest for x86_64, and guix-modular, whereas Hydra builds several branches, all packages, all architectures...
<alezost>civodul: I am currently working on separating "guix-hydra" stuff into a stand-alone package so that nix people could use it too; and I found that Hydra has a much reacher API than I thought
<alezost>for example, you can receive json data with projects using: curl -i -H 'Accept: application/json'
<alezost>cuirass does not support this (at least does not)
<alezost>I am going to add these missing features to the new package ("build-farm.el" is a working name for it), and it would be great if cuirass also has this "Accept" header feature
<efraim>Does anyone have cuirass working on not GuixSD?
<efraim>from a text browser it could use some spaces between [suceeded][failed][not-built-yet]
<oriansj1>The latest eslint breach and malicious package attack got me thinking. what can we do to prevent something similar from happening here.
<oriansj1>how can we ensure that a single compromised account can't inject something malicious to all of the guix users who do a guix pull?
<oriansj1>say add things such as requiring signed commits and two-factor auth for access to the sensitive infrastructure
<oriansj1>Things like adding cryptographic port knocking for pushing git commits and behaviorial access pattern restrictions (aka only have access during standard hours)
<snape>oriansj1: signing is required already
<snape>actually I'm not 100% sure it's enforced
<brendyn>"The majority of graphical applications use Fontconfig to locate and load fonts and perform X11-client-side rendering. The fontconfig package in Guix looks for fonts in $HOME/.guix-profile by default. Thus, to allow graphical applications installed with Guix to display fonts, you have to install fonts with Guix as well."
<brendyn>In a guix on foreign distro setting, how can I get guix installed applications to see parent-system installed fonts
<brendyn>I tried $(guix build fontconfig)/bin/fc-cache -r /usr/share/fonts, but that had no effect
<mbakke>The server side requires that commits are signed, although it performs no verification.
<civodul>sneek: later tell alezost re application/json, sure that'd be nice; i don't expect Cuirass to remain compatible with Hydra forever, longer-term we may want to be free to add anything we deem appropriate
<sneek>Will do.
<apteryx`>hello! Is there anyway I could use phases in such a manner?
<apteryx`>The set-paths procedure object is not usable from the builder side.
<apteryx`>I'm not even sure this can be a viable way (compared to manually setting the PATH myself as in other examples for the trivial-build-system), but I'm experimenting.
<efraim>I have a guix-keyring package, but nothing yet tying it in to guix pull
<mbakke>efraim: I cannot access that repo without logging in.
<efraim>Hmmm, I'll have to check on that
<efraim>Definately unintended
<efraim>mbakke: try it now
<mbakke>I'm in!
<mbakke>efraim: Savannah can generate a keyring from a project:
<civodul>people don't realize, but Savannah is really high-tech
<civodul>it's Web 3.0 disguised as Web 1.0
<kmicu>I’d just like to interject for a moment. What you're referring to as
<kmicu>Web 3.0, is in fact, GNU Web, or as I've recently taken to calling it,
<kmicu>(Sorry for multiple lines. My Emacs conf not always DWIM-it.)
<civodul>kmicu: true! i'd definitely like a GNU net (GNUnet?) to be the Next Thing, with GNS and all
<jlicht>hey guix!
<wigust->hello jlicht
<efraim>Heh, didn't realize that was an option
<rekado_>hmm, the new gtk+ depends on gstreamer-player-1.0, which is provided by gst-plugins-bad(!), which depends on gtk+… :-/
<rekado_>(it’s not a pre-release, so the updater did nothing wrong)
<efraim>You can probably drop gtk from gst-plugins-bad
<rekado_>yeah, I did that.
<rekado_>I created a gst-plugins-bad-minimal package with no inputs.
<rekado_>because I think it’s ugly to have gtk+ depend on all of the things that gst-plugins-bad depends on for plugins.
<rekado_>now most tests fail, but I see that we had disabled most tests previously anyway.
<mbakke>I thought gtk 3.90.x was prereleases for GTK4; at least that's how GNOME has operated in the past.
<rekado_>but they are listed as stable…?
<rekado_>previously they said that gtk 3.2x would be the last release of GTK+3 but then they changed their mind IIUC
<civodul> (linked from "stable releases") gives 3.20 as the latest
<civodul>(note "linux.php" :-))
<civodul> , which is linked from "unstable releases", has 3.94
<civodul>not super clear
<mbakke>rekado_: According to <> they aim to release GTK 2.24 in time for GNOME 3.30.
<civodul>3.23 is just as recent as 3.94 it seems
<civodul>according to 3.94 is a "milestone on our way towards GTK+ 4"
<efraim>Can confirm, 3.9x are pre-releases for 4
<brendyn>I have an issue with my btrfs drive in my os config. when I reconfigure, it mounts it on the fly, but when I reboot there is an error and i cant boot, something about btrfs progs. I just have the entry (file-system (device (file-system-label "1tb")) (mount-point "/mnt/1tb/") (type "btrfs"))
<brendyn>does the order of entries in file-systems matter?
<mbakke>brendyn: Any chance you can capture the error message?
<brendyn>im not sure where to find it if there are any logs, otherwise i can reboot and have a closer look
<brendyn>alright so shepherd says: failed to open /dev/btrfs-control, skipping device registration: No such file or directory
<brendyn>(thats just a warning)
<brendyn>then it says Rerror: therer are 1 errors while registering devices
<brendyn>File system check on /dev/sda1 failed; spawning Bourne-like REPL
<mbakke>brendyn: Thanks for checking! Can you file a bug report?
<brendyn>I can if you think it's a bug rather than some error I have made
<mbakke>It's almost definitely a bug, the snippet you posted should be sufficient.
<mbakke>And there is no fsck for btrfs AFAIK, so no wonder it fails to check it :P
<brendyn>alright, I'll make one
<mbakke>brendyn: Thank you! :-)
<brendyn>do i send to ?
<mbakke>brendyn: Yes.
<brendyn>i also have an issue with the mailing lists. a while a go i suspended my subscriptions, but now that i want to resubscribe to guix-devel/guix-patches, it just tells me im already a member
<brendyn>but i dont get any emails
<snape>brendyn: you may have disabled them
<brendyn>I checked the settings and it was enabled
<snape>or you may have required a digest?
<brendyn>I'm an idiot
<brendyn>I setup a filter in thunderbird to move every guix email into a guix folder
<brendyn>I just found 20,000 emails there xD
<snape>you're not an idiot, the world is hard
<snape>(I just read that somewhere :p)
<brendyn>Email is my one true hate in life
<snape>too bad, it's the only decentralized way of communicating that is still widely used
<brendyn>Indeed noone has ever made anything better yet
<ng0>do we already have the new youtube-dl on master?
<ng0>though it should be possible to do guix pull while I do guix system build…
<ng0>I'll check for myself
<snape>brendyn: it has to be popular too
<snape>otherwise nobody uses it
<snape>and it's useless
<brendyn>or compatible. many people use matrix now because it links in to irc
<snape>the handfull of people hanging out on IRC don't really count. And being compatible with things like Slack/Gmail/Facebook is impossible
<ng0>sometimes compatibility has to be removed.
<ng0>I would not like to stay up to date with the undocumented Discord API for example
<brendyn>I guess I don't mind email it's self it's just how using it is kind a scary. If I want to send 10 emails to the list in a thread I can't prepare that thread and see what it looks like, i just have to send off the emails one after another and hope all of them send correctly and i dont accidently start multiple threads etc
<snape>you want to send 10 related patches?
<brendyn>not at the moment
<ng0>brendyn: mailman3 has a good webinterface.
<snape>but it you need to, you just to send one email, wait for the email and reply to it
<snape>just *need
<brendyn>Yeah, but I use thunderbird, so I have to select each patch as an attachement, and then copypaste the patch name to be the title
<snape>it's way faster to use git send-email
<snape>to send patches
<ng0>I think you could create a rule for the patch list
<brendyn>I think I tried that and botched it also
<snape>to send the last ten commits, just: git send-email -10
<snape>that's all
<ng0>snape: not really. yo uneed to configure an smtp server
<brendyn>but you have to send the first one once to create the thread?
<snape>ng0: same for Thunderbird
<snape>brendyn: yes
<ng0>we could probably write something to ease this process if we use debbugs for a much longer time
<brendyn>I use Their interface is terrible slow
<brendyn>and sometimes google rejects my emails
<snape>that's another, well known, issue...
<ng0>I'd contact openmailbox and ask them to annoy gmail
<snape>well, they're probably insignificant compared to Google
<brendyn>I guess. I donated to them back when it was free, then they suddenly made it subscription out of knowwhere, so a paid for a year, but its still kind sucky
<snape>maintaining a mail server is hard
<snape>in part because every big player doesn't want of your email
<ng0>only some limitations on runbox subscriptions make me run my own server. otherwise I'd suggest them, very good support.
<ng0>not derailing, but I never ran into issues with big hosters
<snape>good to know
<brendyn>I ran my own for a while but then it broke and took me weeks to fix it, and it'd break with dovecot/postfix config updates
<snape>brendyn: well, that wouldn't happen with a GuixSD config :D
<brendyn>it would
<brendyn>i mean dovecot/postfix have changed their config format over time
<brendyn>so my config would become broken
<ng0>the resources required for GuixSD atm outrun those required by a typical small mailserver though
<snape>brendyn: well, right
<snape>ng0: what are those resources?
<brendyn>snape: guix it's self
<ng0>otoh, you can get decent dedicated servers already for fair prices.
<brendyn>requiring up to 1GiB of RAM to build sometimes
<snape>yep, but it's cheap nowadays
<ng0>snape: guix pull being able to succeed on a 512 MB VPS with 2 cores, but taking really long to complete
<ng0>it's been worse though
<snape>I use, it works pretty well
<snape>for years, actually
<ng0>well not everyone can get static IPs ;)
<efraim>brendyn: I have my root on btrfs,
<snape>hm, that's another issue isn't it?
<snape>brendyn: the goal with GuixSD is to do a Scheme layer that wouldn't break when upstream config changes
<snape>it's actually the case with some services, not all of them yet
<brendyn>oh right
<brendyn>currently tho I have no idea how to configure my system in most cases
<brendyn>since i cannot modify any files
<mbakke>Oh no. The builder for glib-schemas.drv consistently fails here with "no code for module (guix build utils)".
<mbakke>From a pre-inst-env.
<g_bor[m]>Hello guix!
<g_bor[m]>I've seen staging is merged.
<Thra11>I'm experimenting with some changes to a package. Making the changes in a git checkout and running guix pull spends a long time "Computing Guix derivation.." Should I be making a copy of the packages I'm changing in a different directory instead, possibly importing the original modules?
<g_bor[m]>Thra11: you can build you package from the checkout using ./pre-inst-env guix build package.
<g_bor[m]>Then you don't need to guix pull.
<g_bor[m]>What are you using guix pull for in this context?
<Thra11>g_bor[m]: pre-inst-env sounds good. I'm currently using guix pull to be able to build my changes because I don't know any better.
<mbakke>g_bor: Uh oh, you're not supposed to notice when it's merged! :P
<brendyn>Thra11: I didn't think guix pull could do that, I thought it just pulled the latest master
<rekado_>efraim, mbakke, civodul: thanks for confirming this. It’s easier for me to just drop this gtk+ update.
<Thra11>brendyn: You can set GUIX_PULL_URL and/or specify --branch=
<brendyn>oh ok I've never tried such madness :)
<brendyn>I use ./pre-env-inst as mentioned
<g_bor[m]>mbakke: :) I did not break anything for me, just was waiting for it, and watching commits list closely...
<roptat>faba-icon-theme is broken
<roptat>I think it was converted to meson-build-system recently, and the install phase tries to run gtk-update-icon-cache now
<roptat>should I try to disable running it, or should I add it to the native-inputs?
<mbakke>roptat: Ah yes, and the failure didn't cause an error until staging was merged (which fixed meson-build-system).
<mbakke>I think it's better to disable it, we do that in a profile hook I think?
<roptat>mbakke: there's no flag for that. I could substitute* meson/ to remove the call to gtk-update-icon-cache though
<janneke>rekado_: iwbn if you can find some time to weigh in to our bootstrapping integration strategies thread
<EuAndreh[m]>ACTION sent a long message: < >
<EuAndreh[m]>BTW, why is useradd ran with both -g and -G?
<pkill9>how do i go about compiling this kernel module? I have a vague idea of what to change in the Makefile:
<pkill9>actually that might not be the right one
<pkill9>it's for tlp
<lfam>Has anyone run `make check` recently and noticed the test suite trying (and failing) to compile a GCC?
<pkill9>anyone know how to fix this `make` error? "Compiler lacks asm-goto support"
<lfam>pkill9: Which compiler are you using?
<pkill9>i was using gcc-toolchain
<pkill9>and then i did `guix environment linux-libre` so i assume whatever that one uses
<lfam>Can you try again with --pure?
<lfam>You are building a kernel?
<pkill9>i'm building a kernel module
<lfam>The linux-libre environment should provide GCC 7.3
<pkill9>yeah it does
<pkill9>--pure didnt work for either gcc-toolchian or `guix environment linux-libre`
<lfam>From within the environment, what does `gcc --version` show?
<pkill9>it showed version 7.3
<lfam>Hm... not sure. I've built kernels but never standalone modules
<pkill9>7.3.0 to be exact
<pkill9>ah well, thanks anyways
<pkill9>maybe i need to specfy some environment variables
<pkill9>i found the issue, it's the Makefile in linux-kernel-path/arch/x86 so i think it's because 64bit gcc is in the PATH