<Veltas>During install I'm getting a lot of "Downloading ....\\n guix substitute: error: download from '...' failed: 410, "Gone"" ***cehteh_ is now known as cehteh
***Digitteknohippie is now known as Digit
***Digitteknohippie is now known as Digit
<lfam>lm-sensors is an suprisingly heavy package <sneek>Welcome back lfam, you have 2 messages. <sneek>lfam, ng0 says: do you know what the state of gparted is roel was working on, end of may? Otherwise I'll bump the thread. <sneek>lfam, ng0 says: for reference, this is the threadname: May 28 [6/6] Roel Janssen, ... [PATCH] gnu: Add gparted. <lfam>sneek: later tell ng0: Regarding gparted: I think the package is ready for roelj to push, if he wants to. There are a couple of very minor problems but they should not block packaging. <lfam>sneek: Sorry, I gave all the botsnacks to the cat <lfam>sneek is so deprived that they don't even understand the plural of 'botsnack'. Sad. <lfam>nee`: You are the 'nee' that submitted the supertux package? <cmhobbs>anyone know how to silence this warning? warning: failed to install locale: Invalid argument <catonano>many beginners, me included, run into this <cmhobbs>yeah, i just realized i had it in my profile but not my bashrc <lfam>cmhobbs: If it's in your ~/.bash_profile, it will get sourced when you log in <lfam>I've also noticed some people putting it in the environment where the guix-daemon runs <mark_weaver>since switching to core-updates (now merged) on my i686 GuixSD box, I've been getting locale warnings where I didn't before. not yet sure what's up with that. <cmhobbs>now that i've managed to reinstall guix, i'm debating whether or not i'm going to uninstall emacs from apt and install it with guix :D <cmhobbs>i'm currently removing guile from apt and installing it with guix <lfam>I had to do that on my GuixSD machine <lfam>I don't really understand why, but it did make the locale problems go away <cmhobbs>i really want to install GuixSD on my netbook but i fear it won't be functional at all <lfam>You could try booting from a USB image to see how it goes <lfam>mark_weaver: Do you understand why packages are still referring to the old glibc even after I (thought) that I rebuilt them after the core-updates merge? <lfam>Most likely, the reason is that I forgot to update my user's packages :) <sapientech>hi all, ideas on the best way to manage external guile libraries? create my own package definitions for them? <cmhobbs>is there a list of guix packages somewhere? <cmhobbs>byte-code: Couldn't start Geiser: (file-error Searching for program no such file or directory guile) <lfam>cmhobbs: You can also do `guix package -A` <cmhobbs>emacs was installed with apt, i guess i should install it with guile? <cmhobbs>bah, it looks like geiser can't load guile at all <lfam>I'm not sure, I don't use Emacs very much <mark_weaver>sapientech: yes, for Guix users I would recommend creating Guix packages whenever reasonable. <mark_weaver>cmhobbs: did you follow the instructions in section 4.1 (Emacs Initial Setup) in the Guix manual? <cmhobbs>mark_weaver: i just did those steps and i have the same problem <cmhobbs>OH, i bet it's because i haven't logged out <cmhobbs>emacs seems to find geiser if i launch it from a terminal <mark_weaver>most likely it has to do with environment variables set incorrectly <cmhobbs>geiser can find guile if i run emacs from a terminal <cmhobbs>at some point, i may install emacs from guix itself <sapientech>okay thanks mark_weaver. really liking guix so far, yall have done a great job <lfam>Hm, I'm having locale problems too <sapientech>haven't given it much thought, i should fix it now :) <lfam>I'm used to warnings from the guix-daemon. I don't really care about those. But since the core-updates merge today, my GuixSD system is having actual problems with the locales <mark_weaver>lfam: you wrote earlier: <lfam> I don't really understand why, but it did make the locale problems go away <lfam>I know, but other problems cropped up <lfam>For example, I can't use `mosh` to connect to the GuixSD system. The remote end complains about not being able to find a UTF-8 locale <lfam>This started after I did `guix package -u .` on the GuixSD system, updating my packages to use glibc-2.23 <lfam>Well, that included many other changes besides glibc. But that seems like a likely source of the problems <sapientech>i fortunately haven't had any actual issues, but not sure why im getting the "failed to install locale" error since i set GUIX_LOCPATH correctly <lfam>I rolled back my packages to the profile before the core-updates merge, and I can connect with mosh. <rekado>sapientech: is GUIX_LOCPATH also set in the environment in which the daemon runs? <rekado>ACTION is getting very close to building elixir with more tests enabled and with the usual approach to patching <vlegoll>Hello, is it me or is there a problem with git.savannah.gnu.org ? I cannot guix pull: error: failed to download up-to-date source, exiting <rekado>vlegoll: I also cannot seem to do “git fetch origin”. It just sits there. <Sleep_Walker>10 packets transmitted, 1 packets received, 90% packet loss <civodul>ACTION upgrades their 230-package profile <ng0>anyone got an opinion where musl should go to other than musl.scm which I found to be okay for the moment? base.scm is the second idea I had for the review. <vlegoll>Personally I prefer as-standalone-as-possible, so musl.scm, but I understand the will for package grouping <ng0>and then we have to discuss about how multiple libc should be treated in our system. My very basic idea was inherits like the idea i have for libressl, do $name-musl or $name-libressl ... don't know. <ng0>we can do better than this i think <civodul>vlegoll: sorry for the delay on these packages, BTW <civodul>i'm currently focusing on the Guix release <ng0>plus musl, at least on gentoo, required usually many patches for packages, or some trivial ones. i found one for torsocks. usually fixed upstream <vlegoll>what about libc-needing packages having a :#libc which would default to system-default-one and that can be overridden as-needed for specific packages ? <ng0>vlegoll: i'm reviewing this musl.scm alone now <vlegoll>no problem with the delays, I see there's a lot of activity going, no urgency... <ng0>maybe.. but as I wrote, musl can cause many bugs <ng0>uclibc-ng not so much <vlegoll>system should default to glibc, and select packages that have been tested working with another one and that benefit from could be switched on a case-by-case basis <vlegoll>and that would let people willing to experiment an easy way to test <wingo>after the release we can update guile :) <ng0>i don't know. i still prefer to offer it all, maybe in different outputs <ng0>:musl :uclibc-ng etc <ng0>powwow now redirects to https download server, making the download fail <ng0>i'll fix the powwow package by making it https directly <civodul>wingo: yes that's also what i thought :-) <ng0>how do I skip one package? <civodul>profile minus 5 packages updated \\o/ <ng0>oh. vlegoll would've been good if the .scm file was a complete one, i'll do the exporting importing here now, no problem. but for testing it's easier <ng0>then why did it fial <ng0>fun.. my notmuch breaks special symbols like © when i save appended files.. at the moment. <ng0>4 parralel reviews,builds etc are too slow for this.. build offloading is easy? <ng0>*are making this too slow <ng0>who's working on the login manager (elogind?) ? <ng0>having this in the system.scm in (services): (console-keymap-service "neo2") does not affect the login manager language. <ng0>what do i need to set to get another input layout there <civodul>the login manager is slim, and it's not internationalized (which sucks) <ng0>i did not know we use slim <ng0>but shouldn't the console key layout be changed when i set this, reconfigure and reboot? in tty it's still whater i had before (de-latin1) <ng0>but it didn't change <ng0>so maybe this is limited in some way? <rekado>I don't know how to switch the keymapping in slim. <rekado>It's a bit confusing to have to input the password with Qwerty. <ng0>when I change (console-keymap-service) from "de-latin1" to "neo2", I expect the change to be that tty is now neo2 layout. this failed. <rekado>synfig is broken because of the isnan change <rekado>error: ‘::isnan’ has not been declared <rekado>I’ll fix r-genomationdata today. <ng0>must the user on the machine i offload builds to be "root"? the average daily user i have on GuixSD on the other machine seems not to be enough <ng0>no. it's just not setup for building/development yet ***nully_ is now known as nully
<ng0>configuring offloading is hard to get right it seems <ng0>libreoffice is still starting to build here <ng0>and not on the build machine <Sleep_Walker>is anyone here using dual boot with GuixSD, and has grub configuration stored as a part of system configuration? <ng0>could it be that current master is damaged? i get an error in kde-frameworks <ng0>master.tar.gz i mean <ng0>related to 8f9d70fcb9b55aea56515e2f4f55351ff544022a maybe <rekado>ng0: I don't see anything wrong with the commit you referenced. <ng0>a later commit may have problems because of this earlier one <civodul>Sleep_Walker: i've just fixed this one :-) <ng0>offloading seems to depent on one guix checkout.. offloading the build of for example the update of libressl does not work <ng0>oh, it did not change the folder back <ng0>it seems that "neo2" is a wrong input for console-keymap <ng0>maybe it's named differently for console <rekado>ng0: there must be a file with a matching name. <rekado>you can try this by running "loadkeys" <ng0>i know, i'm looking into this right now <ng0>neo and neo2 was wrong <ng0>where does guix throw the keymaps again? in openrc / gentoo i know where they are. <ng0>i'm not sure. it's a layout which can be used in X11, but i never checked for outside of x11. <civodul>ng0: try "find $(guix build kbd)/share/keymaps" <ng0>apparently it's not existing for console ***contrapumpkin is now known as copumpkin
<ng0>offloading is not documented well enough. I have read some threads, I have followed lsh + our documentation, and I still can't make guix build offload due to authentitcation errors. <ng0>what user? root? unprivileged user? I tried both.. I'm trying root now again <ng0>with root defined in the machines.scm I could get at least past the path failures <ng0>there's another build process running, but that shouldn't throw me this error: <ng0>number of parallel builds is set to 4 <efraim>I would just manually create that dir on the remote end <efraim>Andreas(?) had a blog post about setting it up with a novena board <ng0>how do i do this manually? sorry if it's obvious, but i'm not well today <ng0>filling out paperwork where the "optional" part requires me to either hand over access to personal intimate files to state or loose my source of current income. very optional indeed. <ng0>i should photograph it and kick their behinds if they can't delete it int 3 years, because that's also stated in the optional part. however this state near agency is known for having the worst data protection. <ng0>lfam: yeah, i tried to compile a new patch addressing the 3rd email. but offloading did not work. so I'll do without offloading now <lfam>ng0: Which 3rd email? ;) There are many emails <lfam>I didn't see the email about ircii that mentioned offloading <ng0>no.. that'S a local problem. i mean what izy wrote <ng0>i'm just building so much that I need to come up with ways to have more builds in parallel <lfam>I think that removing the hard-coded paths is a Guix-specific modification. It's very normal for chmod, chown, rm, etc to be found under '/bin' <lfam>So, I think they should go in a build phase like your latest patch <lfam>I don't know, I trust iyzsong on that <ng0>gentoo does that because they have musl, uclibc, uclibc-ng <ng0>I could also not include libiconv, do as iyzsong says and add back later if problems occur for other libcs <lfam>Huh, does anybody else use mosh to log in to a GuixSD system? <lfam>bavier`: Have you tried it since we merged core-updates yesterday? <lfam>It's always worked for me, until then. Now, mosh can't find the UTF-8 locales on the remote system <lfam>I'm also having issues with my terminal emulator (urxvt) since then <lfam>I tried setting TERMINFO_DIRS and GUIX_LOCPATH in the remote ~/.bash_profile, but that didn't help, and I figured those variables were already being taken care of <civodul>lfam: did you use the configuration trick that i gave to have both 2.22 and 2.23 locale data on this system? <lfam>It helped with some other locale issues I had after updating <lfam>When I set TERMINFO_DIRS and GUIX_LOCPATH in my .bashrc (bad, I know!), then I can log in with mosh and my terminal works as expected <lfam>I suppose that mosh is not sourcing my login shell init files <civodul>should be in .bash_profile, which is for login shells <lfam>Yes, that's where it was before <cmhobbs>i've got that information in .bashrc, .bash_profile, and .profile and some things still don't get loaded for me <lfam>I seem to remember somebody calling environment variables one of the hard problems of computer science ;) <lfam>cmhobbs: What doesn't get loaded? <cmhobbs>emacs can't seem to find things i've installed with guix (emacs was installed via apt) <cmhobbs>except my problem is just scoped to emacs only <lfam>On your local system? Did you log out and back in (or test with `bash -l`)? <lfam>.profile and .bash_profile are only sourced on login or when simulating the login with `$SHELL -l`? <lfam>Whereas .bashrc is sourced every time you run the shell <cmhobbs>i put it in all three because i was mad <civodul>lfam: indeed, environment variables are hard :-) <civodul>they're probably not "science", though ;-) <lfam>No, more like a magic show. "Where did the variable definition go?!" <lfam>ng0: My suggestion to propagate libiconv was probably not correct. It was basically just a guess. I'd rather use your previous patch. <ng0>i have send a new one <ng0>don't know if that's what you wanted , id id not follow the channel. <ng0>also, i don't even know what --with-emacs-meta-keys does. if it happened in the early 90s, i could one of the original contributors. <ng0>i guess it does not require emacs <ng0>if it would, it would be documented <lfam>ng0: Should we remove it from the configure flags? <civodul>our libc no longer honors /run/current-system/locale/ <ng0>lfam: i tried to do all configure options, even socks but for socks we have no small enough socks lib. i don't want to pull in haskell. <lfam>civodul: Okay, so I'm not losing my mind. Anything I can do to help debug? <civodul>lfam: well, you can see why that happens <civodul>we have to rebuild the whole thing, or use a replcaement <civodul>or we can set GUIX_LOCPATH=/run/current-system/locale on GuixSD <ng0>lfam: there's also --with-paranoid , but i was not sure about that either. if people notice missing features they will complain… paranoid config is highly optional <ng0>i find it useful, others probably don't <ng0>privacy related stuff <ng0>also i believe it might or might not be fixed through config overwrites, post setup <lfam>civodul: That was fast! Reconfiguring... <ng0>i'll think about a documentation fix this week <ng0>or next.. i have lots of things coming up <ng0>already mixed up one appointment <lfam>I made a wrapper script for mosh that exports GUIX_LOCPATH before invoking the server, and that works. Annoying <myglc2>I did what Ludo recommended but my locales are broken. <lfam>myglc2: Yes, there was a locale related change in glibc-2.23. Ludo pushed commit ab3a64507a a few minutes ago as a mitigation <lfam>I'm still having some trouble, but I'm not sure yet if they are related to this or to changes in other packages <myglc2>Thanks... will guix pull get the fix or should I do git pull & make?? <efraim>Guix pull gets the current head and uses that <lfam>glibc commit 90fe682d30 made a change that I believe broke our glibc package's locale handling. Title: Rename localedir to complocaledir (bug 14259). <efraim>Git pull && make is faster bug both will get the job done <myglc2>efraim: Is that on master branch? <lfam>myglc2: Yes, on the master branch <ng0>I don't understand offloading.. in checkouts it works, but with the system guix it doesn't <ng0>or maybe it is picking up remains <myglc2>ouch. my locales are still out of whack. <ng0>where are the temporary files from aborted build located again? <myglc2>Is: (use-modules (gnu system locale)) <myglc2> (locale-libcs (cons glibc-2.22 %default-locale-libcs)) <myglc2>all I should need in my system.scm? <lfam>ng0: You have to pass --keep-failed to `guix build` if you want to keep them <ng0>i don't want to keep them <ng0>i aborted a libreoffice build <ng0>and now i can't offload it <lfam>I don't know. I've never used offloading <lfam>Now I try building a modified glibc on a laptop :p <ng0>what i mean is, a build aborted before it finished and i need to clean what recorded <lfam>ng0: The build directory (by default found in /tmp) should be deleted automatically <ng0>in this case there's nothing in tmp but it still builts locally <ng0>but guix gc.. should run it more often <ng0>the listing goes on and on and on <ng0>wee. segmentation fault in notmuch <ng0>Wrong type argument: number-or-marker-p, "Segmentation fault" <ng0>ntomuch emacs i mean <ng0>i need to send a mail :/ any idea how to solve this? build notmuch again against current glibc? <ng0>gc solved the libreoffice problem i think <lfam>The elixir commit begins with U+FEFF (ZERO WIDTH NO-BREAK SPACE) <lfam>I guess it's fine if nothing breaks <ng0>cool, you commited libressl. i was working on that too today <ng0>no, it did not fix it. well i gues i'll build libreoffice here. <ng0>or just remove it for now <civodul>that was a ZERO WIDTH NO-BREAK SPACE <civodul>ACTION wonders about the purpose of a zero-width space <rekado>bah, I really liked that password… <ng0>the language/locale problems we have now are caused by glibc probelms? <mark_weaver>U+FEFF is also a BOM, when found at the beginning of a UTF-16/32 stream <mark_weaver>BOMs are also allowed at the beginning of UTF-8 streams, although they are seldom added there <ng0>can i fix it somehow? i can not send emails (emacs) because of this <ng0>or work on fixing it <ng0>well i can load an older version of the system <mark_weaver>ng0: civodul pushed a commit a couple of hours ago to work around the problem <myglc2>ng0: FWIW, git pull && make and removing Ludo's recommended '(locale-libcs (cons glibc-2.22 ...' works for me <mark_weaver>"system: Define 'GUIX_LOCPATH' to work around 'glibc' package defect." <mark_weaver>or, in the meantime, set GUIX_LOCPATH=/run/current-system/locale in some environments, and in those environments locales should work better <rekado>I use the zero-width space to circumvent an annoying chat bot at work that automatically responds with snarky comments whenever I mention Emacs. So I write “E<space>macs” or a variant thereof. <mark_weaver>rekado: wow, whoever set up that bot is obnoxious :-( <rekado>the bot isn’t as annoying as the comment that “Atom is the Emacs of the 21st century” <taylan>sounds like a fun workplace... (half sarcasm :P) <rekado>taylan: it’s all in good humour… I think :) <civodul>rekado: you're having a good time at work :-) <myglc2>Hi lfam. guix edit started producing 'Couldn't find package location.' with latest git pull && make. Am I missing something? <lfam>myglc2: Well, I don't use it, so I can't say if it's a regression, but `./pre-inst-env guix edit certbot` gives me Emacs with a dialog telling me that the local variables list in my source tree may not be safe, and then a question about what to do. <myglc2>lfam: duh, I have to leave emacs to try that, scary! <civodul>myglc2: do you have an example? it works for me here <myglc2>lfam: Yup that opens emacs on the source. <myglc2>Sorry I wasn't clear before, 'M-x guix-edit' is the problem. <alezost>myglc2: what's the value of 'guix-directory' variable? <myglc2>... which points to the guix source tree <alezost>try "M-: (guix-package-location "emacs")" <ng0>weechat (ncurses) is fixed. emacs (-f notmuch) is still segfaulting. <ng0>afk, fixing bricked phone. if there's anything i can be more speficic about it will be in 2 hours <myglc2>'guix edit certbot` gives me errors, maybe I forgot --localstatedir-/var <alezost>myglc2: where do you see that "[No Match]"? Do you mean nil? <myglc2>"M-: (guix-package-location "emacs")" shows "[No Match]" on mode line <alezost>it shouldn't return "[No Match]", but never mind. Could you switch to *Guix REPL* buffer and evaluate (packages-by-name "emacs") there? <myglc2>(#<package emacs@24.5 gnu/packages/emacs.scm:79 2a389c0>) <alezost>ok, what about (package-location-string "emacs") <alezost>then evaluating (guix-package-location "emacs") in Emacs should return the same string <myglc2>yup: "gnu/packages/emacs.scm:79:2" ***Digitteknohippie is now known as Digit
<alezost>myglc2: ???? earlier you said it returns "[No Match]" <myglc2>alezost: did you note my comment that w/o './pre-inst-env' 'guix edit' fails. <alezost>myglc2: sorry, I don't understand what your problem then. I thought you "M-x guix-edit" doesn't work for you, but as I see it does, right? <myglc2>"M-x guix-edit" does not work, 'guix edit' does not work, './pre-inst-env guix edit' does work. <alezost>myglc2: once again: (guix-package-location "emacs") returns the right string, try to evaluate (guix-edit "emacs") <alezost>myglc2: what error do you have when you invoke 'guix edit'? <alezost>myglc2: evaluate (guix-edit "emacs") in the same way you evaluated (guix-package-location "emacs") <alezost>myglc2: "efine-public"! you have an error in (gnu packages screen) <myglc2>Ooooh, how embarrassing ... slinking off into a corner <alezost>myglc2: after fixing that typo, "make" the git checkout to make sure you don't have such errors <roptat>hi, I just installed guix sd, but it fails to boot with message "waiting for partition 'system' to appear..." "ERROR: failed to resolve partition "system"" <roptat>when installing, I created a partition called system, and from the live usb I can list it in /dev/disk/by-lable/system <roptat>I used only two partitions : a swap partition and the system partition (ext4) <bavier`>roptat: you used the 'label' title for the file-system declaration? <roptat>something like (file-system (device "system") (title 'label) (mount-point "/") (type "ext4")) ***tschwing_ is now known as tschwinge
<civodul>roptat: does the partition show up in /proc/partitions? <civodul>you should check from the rescue shell that appears when your system fails to boot <roptat>that's a scheme interpreter, I don't know how to use that :/ <roptat>(I mean the partition is not listed) <lfam>Wow, the Go packaging system is very _interesting_ <civodul>roptat: maybe you need a particular kernel module to access it? <roptat>does the live usb include kernel drivers that are not installed on the system? <civodul>yes, it includes the kernel and all its drivers <civodul>lfam: interesting in what sense? :-) <lfam>civodul: For example, there is no concept of releases. Everyone bundles a seemingly arbitrary version control revision. The mechanism for fetching these revisions requires webmasters to include a special <meta> tag on their sites. <lfam>A filesystem path like '$GOPATH/src/github.com/user/project' is derived from the remote URL, and this path is supposed to uniquely identify the code. But, from my admittedly limited investigation, there is no way to actually uniquely identify the code. No hash or version string or anything like that <lfam>I need to find a way to know that path without having network access, since it seems that you can't build the software if it's not in that directory <lfam>I wonder if we will need to create some "union" directory of a Go package and its dependencies in order to build it, or if there is some other way <lfam>I hope there is some other way :) <lfam>I need the help of an experienced Go programmer <lfam>davexunit: Perhaps, but there is some good software written with it :) <davexunit>the philosophy of the entire language is bad. <bavier`>I had my first encounter with go yesterday, thankfully it had no other go dependencies <lfam>There must be a way to make the tools find the source locally rather than over the network... <lfam>I'm going to keep learning for a little bit before I take my questions to #golang <lfam>I might actually ask for help on #syncthing instead. They are friendly <davexunit>would be cool to have things like Gogs available <lfam>Me too. It would also be cool to have Boulder, the Let's Encrypt CA server <ng0>yay. my gnunet-gtk.desktop got added to gnunet-gtk <ng0>i'm not the only one with the emacs segfaulting problem i assume? <ng0>ah.. it is torsocks which is the problem