IRC channel logs
2018-07-13.log
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. <civodul>rekado: isn't gtk+ 3.94 a prerelease? <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 <mange>Your assoc-ref for set-paths looks like its arguments are in the wrong order? <sgsz>Hi, does anyone have any experience with running GuixSD on the VPSs at prgmr.com or other small business VPS providers? <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_>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>i remember adding provisions to filter out prereleases <civodul>and things with odd minor version numbers <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 <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 <kmicu>ACTION [not seriously] wonders how many folks see (focus on) ‘ass’ in ‘Cuirass’. <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’. <snape>Cuirass is a French word too, so for us, French people, it's more difficult to notice <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>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>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 <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. <mbakke>efraim: I cannot access that repo without logging in. <efraim>Hmmm, I'll have to check on that <civodul>people don't realize, but Savannah is really high-tech <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 <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_>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_>previously they said that gtk 3.2x would be the last release of GTK+3 but then they changed their mind IIUC <civodul>3.23 is just as recent as 3.94 it seems <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>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>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 <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 setup a filter in thunderbird to move every guix email into a guix folder <snape>you're not an idiot, the world is hard <snape>(I just read that somewhere :p) <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 <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? <ng0>brendyn: mailman3 has a good webinterface. <snape>but it you need to, you just to send one email, wait for the nnnn@debbugs.gnu.org email and reply to it <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 <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 --to=nnnnn@debbugs.gnu.org -10 <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? <ng0>we could probably write something to ease this process if we use debbugs for a much longer time <brendyn>I use openmailbox.org. 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 <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>i mean dovecot/postfix have changed their config format over time <ng0>the resources required for GuixSD atm outrun those required by a typical small mailserver though <snape>ng0: what are those resources? <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 <ng0>well not everyone can get static IPs ;) <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>currently tho I have no idea how to configure my system in most cases <mbakke>Oh no. The builder for glib-schemas.drv consistently fails here with "no code for module (guix build utils)". <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]>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 :) <g_bor[m]>mbakke: :) I did not break anything for me, just was waiting for it, and watching commits list closely... <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/post_install.py 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 <pkill9>actually that might not be the right one <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>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? <lfam>The linux-libre environment should provide GCC 7.3 <pkill9>--pure didnt work for either gcc-toolchian or `guix environment linux-libre` <lfam>From within the environment, what does `gcc --version` show? <lfam>Hm... not sure. I've built kernels but never standalone modules <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