<jeko>lfam: I am trying to deploy a new system conf on a VPS <hurricos>Bootstrap into something that can give me a serial console on the servo header or put the RK3288 into Maskrom mode. <lfam>"only every other 128KB can be used" How strange *hurricos points at Rockchip with a finger of blame <jeko>lfam: and I guess nginx doesn't like the resulting conf but I don't <jeko>know where to get more detailed info *raghavgururajan just noticed the cosmetic changes email <lfam>It's tricky to know the best course of action in cases like that raghavgururajan *raghavgururajan will compose a response in some time :-) <hurricos>one correction for those who reach here via seo, the Asus C201 is not a veyron despite having the same soc <hurricos>or is it. Huh. The motherboard doesn't look the same. What do I know. <jeko>Time to sleep for me. Take care ! <lispmacs[work]>is gnome-maps working fine for everybody else? I'm getting an Internet connection error that prevents it from displaying any maps, even though my internet connection is working fine in other applications <lfam>lispmacs[work]: It's probably not just you. I've always had trouble of some sort with it <bdju>is doing a guix pull the only way to get up-to-date results from `guix search`? <roptat>technically, you could use the time-machine <vagrantc>which is sort of a wrapper around guix pull :) <sneek>vagrantc, you have 1 message! <sneek>vagrantc, hurricos says: Hi there, you talked about linux-libre on your Asus C201 / veyron around September last year, did you replace u-boot on flash to attempt to boot it, and did it ever boot? <vagrantc>hurricos: i never got a working u-boot on it, have only used coreboot/libreboot successfull <bdju>I guess I'm fine sticking with guix pull, I just wonder if there's a faster way to find out if a package has been updated or not <bdju>like if I basically just wanna see if the version number changed <leoprikler>lispmacs[work]: the only problem I have with gnome maps is that I have to launch it from the command line like a caveperson when dinosaurs still existed when I already sent a patch fixing that bug ages ago <bdju>I don't keep a copy of the repo around, or if I do it's not kept updated at least <vagrantc>so you could git fetch from there, and do a git log ..origin/master probably <vagrantc>or git log --grep=SOMEPACKAGE ..origin/master <bdju>ah jeez. I barely know my way around git. I don't think I've even used fetch before <vagrantc>git fetch updates the remote without updating your working copy <vagrantc>and next time you guix pull, it'll have less to pull <bdju>I started getting this message when launching mpv recently: cplayer: Cannot find main.* for any supported scripting backend in: /home/user/.config/mpv/scripts/lib <bdju>anyone else experiencing that? <bdju>might just be that I have to update one of my scripts now *raghavgururajan responded to the cosmetic commits issue <raghavgururajan>sneek, later tell dannym: Sorry Danny! for putting you in the awkward position regarding the cosmetic issue. :-( <bdju>I did find out that I had to update the mpv-gallery-view script I was using. there was a commit where they moved gallery.lua from lib to lib.disable so it doesn't try to get loaded by mpv as a lib <kozo[m]>Hey all, what changed with guix environment? What do I have to add to my config.scm to fix this? <kozo[m]>guix environment: error: cannot create container: unprivileged user cannot create user namespaces <kozo[m]>guix environment: error: please set /proc/sys/kernel/unprivileged_userns_clone to "1" <guix-vits>aside. i'd just a wifi error, and guix environment (older commit) get "no route to host". so this laptop decided to build python :) i wish there was some guard against such minor inconveniences. like --network-try-twice[=y] ***db48x` is now known as db48x
<rekado_>the problem with 22952 appearing as “open” is that it’s not entirely clear from the Debbugs data whether the issue is archived or not. <rekado_>Debbugs has two file trees: for archived issues and for active issues. <rekado_>in this case only the archived file contains the information that the issue has been closed, but there is *also* a newer file indicating that it is an active issue — and that file does *not* mention that the issue was closed <rekado_>so I guess mumi needs to gain even more heuristics and look at both files… <rekado_>archiving issues has to be one of the more annoying features of Debbugs. <rekado_>it also prevents emails from being processed unless the first email it receives is an unarchive command <rekado_>oh, looks like this issue *actually* has been reopened, so the only problem here is that mumi sees the archive and displays those message instead of the new messages that have been received since unarchiving. <jeko>I have configured a `certbot-service-type` but `herd status certbot` say certbot service is not found. Is it OK ? <jetomit>jeko: certbot service uses mcron to schedule renewals, there isn’t a separate daemon <jetomit>you can check the jobs scheduled by mcron by looking at its arguments in ps … and probably in some other, less stupid way :) <mbakke>jeko: try 'sudo herd schedule mcron' <jeko>jetomit: alright! thank you ! <jeko>mbakke: I only see about rottlog <olivuser>hello guix. I'm on a mostly freshly installed machine. When I try to launch programs (like geiser in emacs), I am prompted with the error message "could not find guile" even though I have installed it. I have already added $HOME/.guix-profile/bin to my $PATH <olivuser>I'm on a mostly freshly installed machine. When I try to launch programs (like geiser in emacs), I am prompted with the error message "could not find guile" even though I have installed it. I have already added $HOME/.guix-profile/bin to my $PATH <jeko>what about running `guile` in a terminal? <olivuser>you think I need to alter $PATH in my init.el? <jeko>Are you running Guix as a package manager or as an Operating System ? <olivuser>jeko, so what you are implying is that the problem is related not to the shell but to emacs? <olivuser>I've just tried altering the exec-path to include $HOME/.guix-profile/bin, but this doesnt solve the issue <jeko>olivuser: your freshly installed machine is a Guix System or another GNU/Linux distro with Guix as a package manager ? <jeko>I think you should not have to do anything to make it to work <jeko>oh I found the solution in the manual I think ! <jeko>oh no, I read too fast it's not about Guile path haha sorry… <jeko>olivuser: I guess you've already done `guix package -i emacs guile emacs-geiser` ? <olivuser>to be a bit more precise: I have said packages installed. Also, my problem is not only related to geiser, but also to git. Whenever I try to open a file, I get prompted with the error message that git was not found (the file is opened regardless). <olivuser>also, dmenu does not find any program inside emacs, even though SUPER-& finds them <emys>I have for weeks now gotten the warning messages `guile: warning: failed to install locale' on my guix installation (on top of a debian system) <emys>GUIX_LOCPATH is set and exported <emys>glibc-utf8-locales is installed <jeko>olivuser: I suggest you to ask for help on the mailing list <jeko>emys: you don't need glibc-utf8-locales <emys>civodul, guix (GNU Guix) 36a7af816186eca1927b232dd25c8bd804ba38f9 according to guix --version <civodul>emys: i believe you'll no longer see the warning if you upgrade, with "guix pull" <civodul>it's something that was fixed at the end of September <emys>civodul, I just did that this morning <civodul>ok but the one above is not the new guix <civodul>what does "type guix" say in your terminal? <emys>guix is /usr/local/bin/guix <civodul>yeah, that's the initial Guix, the "old one" <civodul>probably "guix pull" printed a hint that you should source ~/.config/guix/current/etc/profile <mbakke>olivuser: it sounds like you may need to source /etc/profile before starting Exwm, to get the required environment variables <emys>civodul, ok, thanks for pointing that out. It seems my profile and zsh config file situation is a bit messed up and so the sourcing didn't work yet but I am sure I'll be able to figure it out <jeko>mbakke: Does that mean certbot will do its labor at 12:00? Or does it mean it won't ? 😅️ <jeko>Fri Dec 4 12:00:00 2020 +0100 <jeko>/gnu/store/8q2i735qhdivn5pn87b6ay7z16xnf6py-rottlog-0.72.2/sbin/rottlog <emys>civodul, do I need to install guix via guix for that to work? <emys>because the source statement just changes the path <civodul>(do not try "guix install guix", if that's what you meant) <emys>civodul, thats what I meant <emys>but I don't understand then <emys>because this is the content of that profile file export PATH="${GUIX_PROFILE:-/gnu/store/sa10snc5hqssxhxqaf1qgxlw9nm54j99-profile}/bin${PATH:+:}$PATH" <emys>and sourcing that adds /home/holger/.guix-profile/bin to my path <emys>which has been part of my path all along <emys>and this directory has no guix executable <emys>running guix pull doesn't change that <jeko>mbakke: I answer my question with a test in a VM. I should see something like /gnu/store/***********hash**********-certbot-command <jeko>So why isn't it working on my VPS… <olivuser>mbakke, considering that I use exwm via a system installation, is it sufficient to source it via bashrc or do I need to do something else <olivuser>(I have chosen exwm while installing guix system is what I mean) <jeko>To myself: restart mcron service haha <civodul>emys: it's ~/.config/guix/current/etc/profile that you should source <civodul>this is the one that 'guix pull' creates <civodul>whereas ~/.guix-profile/etc/profile is created by 'guix install' etc. <emys>so th problem was that I got GUIX_PROFILE wrong, which meant the wrong profil was sourced ***apteryx is now known as Guest25677
***apteryx_ is now known as apteryx
<olivuser>will come back to that later, thanks so far :) <elais>Is there any downside to using a simple etc-service-type to store a channel as part of the os config? <elais>Just realized I could use a scheme file gexp to do this inline with the config and it saves me some manual steps <civodul>elais: that's a good idea, but there might be complications because you have to create the /etc/guix sub-directory <elais>I haven't thrown it on a system but using the `file-union` procedure allows me to collect files into a directory, then I feed that gexp to the service and it looks like it does what I want when checking three system build output <elais>ie create `/etc/guix/channels` <civodul>yes, but i think guix-service-type is also trying to create /etc/guix <elais>This is what I was afraid of. Does file-union create the `guix` directory or doea it create a symlink to that directory in its store <elais>Do all gexps go into the store? <leoprikler>it creates a directory, but the result in /etc will be a symlink <emys>civodul, It seems that now I got two places where excutables are stored /home/holger/.config/guix/current/bin/ (e.g. guix) and /home/holger/.guix-profile/bin (e.g. tig/emacs other installed packages) <elais><leoprikler "it creates a directory, but the "> Modify guix-service-type instead of using `simple-service 'blah etc-service-type`? <elais>So if the guix directory is created in etv then no harm no foul, right? Both services should be able to add symlinks <civodul>and i'm not just repeating what leoprikler writes :-) <elais>* So if the guix directory is created in etc then no harm no foul, right? Both services should be able to add symlinks <emys>so define GUIX_PROFILE for the paths, source it, then overwrite GUIX_PROFIL setting, sourc again? Feels unintuitiv, but I guess ok <civodul>elais: yup, though guix-service-type actually tries to write to /etc/guix (via activation), so that's where things might fail <elais>It would be no different than if I added the channels.scm file there manually is what I'm hearing <civodul>emys: maybe not, but it can take time before volunteers catch up :-) <civodul>i'd just keep the VCS variant of smalltalk-next, the one that uses alpha.gnu.org is not very useful IMO <civodul>i'd arrange to not duplicate the 'fix-libc' phase if possible <civodul>also it'd be great to avoid #:tests? #f <civodul>at worst, you can skip just the faulty test with a link to the bug report/issue <emys>ah yeah, about the test skipping, I tried to patch it out but failed to do so for some reason (I guess guix-related or my usage of guix' patching system). <civodul>the first thing would be to check why it fails/what it does so we have an idea of how serious that is <emys>phas duplication could be factored into a modul-variable I guess <civodul>you could just not override 'arguments', or use 'substitute-keyword-arguments' <emys>I guess I overrid arguments to enable tests again in the VCS build <emys>the situation was IIRC last release and alpha release showed failing tests, on master they were fixed. <civodul>ok, so maybe the explanation shows up in their VCS log <emys>no it doesn't (at least not for me) <emys>let me rebuild the alpha build with tests enabled again, just to make sure I didn't mess this up <emys>another option I guess would be to not bundle smalltalk release and alpha and just provide the smalltalk-next from git as a functional package (until someone feels compelled to engage in software archeology for Gnu Smalltalk). <emys>for my use cases the VCS version would definitely suffice <civodul>yes, but Guix is for additional people too ;-) <emys>civodul, I am sorry I didn't mean it in that way <civodul>i mean we should probably keep the latest upstream release, because that's what upstream released <civodul>then look at the test failure, decide if it's serious, and skip this one test if it's not <vits-hobo>bog_dan_ro: on .../latest, see 'Build details: link' <vits-hobo>follow link. there will be line 'Build outputs' ***chrislck_ is now known as chrislck
<mothacehe> bog_dan_ro: do you have a Guix checkout somewhere? <mothacehe>and then run ./pre-inst-env guix system disk-image -t hurd-raw gnu/system/examples/bare-hurd.tmpl <mothacehe>sorry about the link gone missing, we are having some troubles with the CI :( <vits-hobo>indeed, troubles. the 5.4 isn't available as a substitute. i'm out of luck today. <emys>civodul, I think I hav found the issue with the failing tests and its worth patching the implementation I think <civodul>bavier[m]: hi! any idea why our Scotch package is provides .a files only? <civodul>BTW, feel free to join #guix-hpc :-) <mbakke>ooh, 'guix git log', cool stuff :-) <mbakke>perhaps a good incentive to encourage uppercasing of variables in the commit log, so that it is easier to filter out uninteresting changes such as input additions/removals <jeko>How can I trigger certbot for renewing certificates right now ? <davidl>I vaguely remember that there was a screencast made of the installation process written in guile somewhere? Does anyone remember where the code for it is? <mroh>core-updates has been merged recently, no? *vits-hobo "almighty mac-beast, we, pirates, pledge ourselves to ur mercy, no merges this week.. may i repair in peace." <mbakke>mroh: core-updates has not been merged since many months, but work to merge it will start soonish <rekado_>I have a guix.scm file for my project. This works fine with “guix environment -l” and “guix build -f”, but I’d really like to also use it with “guix pack” to deploy it. <rekado_>I see that “guix pack” can take a manifest, but it won’t take a file evaluating to a package. <rekado_>any ideas how to get around this easily? <vits-hobo>rekado_: maybe a manifest with 'add-to-load-path on top? <vits-hobo>if someone implement "fat manifests", that work either with -f or -m, we can sold it to apple and try to poison them with gpl :) <rekado_>I guess guix pack -e '(load "guix.scm")' would work <civodul>PurpleSym: i suspect you can work around it by creating said directory <civodul>so i guess PurpleSym should pull & reconfigure? <civodul>should be /var/cache/guix/discover, no? <civodul>so replacing %state-directory by a call to xdg-cache-home or so <civodul>PurpleSym: "sudo touch /var/guix/discover/publish" i suppose <mothacehe>civodul: there's /var/guix/offload that exposes kinda the same information <civodul>i feel /var/cache may be more appropriate here because it's really just a cache <civodul>(and i think we used /var/guix too much in the past) ***sneek_ is now known as sneek
<civodul>mothacehe: you can use the xdg-cache-home procedure, no? <civodul>mothacehe: ah no, it's called cache-directory, in (guix utils) <civodul>i miss Helm's git-grepping facilities <civodul>tried to get the same in Ivy but it doesn't quite work <zimoun>apteryx: I hit the bug#42371 about «guix build: error: all build users are currently in use;…» using a manifest file with 200+ packages. Well, because of that, massive rebuild from the command line is annoying. Have you investigated more since you have reported it? <sneek>Welcome back zimoun, you have 1 message! <sneek>zimoun, nikita` says: I also do not intend to react to bugtickets that old (see icecat localizations one) because I have no means to reproduce it and don't really have the spoons to deal with more than one project this year <civodul>it's the interface that i blame, not the underlying tool ("git grep") <bavier[m]>hi civodul, um, I think it's just a little harder to make .so libraries in scotch :) <bavier[m]>I was going to upgrade that package soon, so I can take a look. <vits-hobo>any hints, guixen: "guix system: error: creating directory `/var/log/guix/drvs/3x': Bad message" ? <mroh>civodul: counsel-git-grep isn't good (enough)? <civodul>bavier[m]: a colleague of mine of pushing for a switch to CMake instead of those hand-crafted makefile (it's already in a branch AIUI) <civodul>mroh: not quite: in helm-find-file, i could M-g g to git grep in the cwd, and C-u M-g g to git grep in the whole project <civodul>i wrote Ivy "actions" that call counsel-git-grep <civodul>but that doesn't behave as expected, not sure why <bavier[m]>too often people end up replacing a working autotools setup with a cmake setup that has mostly the same plus a few more problems <leoprikler>Let's stop that by using an equivalently broken meson setup! <vits-hobo>leoprikler: ye, i remember that "update ur meson" stuff. <leoprikler>I really wish meson was made better suited towards Guile tho <civodul>leoprikler: i have an uninformed yet better impression of Meson than CMake <civodul>(Friday's a good time to share uninformed impressions) <civodul>mothacehe: did you add guile-semver to the guix package? <leoprikler>Oh, sure, I prefer Meson over CMake all times of the day and even Autotools sometimes. <leoprikler>The problem is working with tools they haven't considered yet is a bit of a pain. <civodul>tell us more about your feelings :-) <leoprikler>I handcrafted my own meson.build for a project of mine. <mothacehe>civodul: well it doesn't appear in (gnu packages package-management), trying to see if it helps <leoprikler>The thing is, I don't like how meson wants to enforce a meson.build per directory, so I do everything at top level. <leoprikler>so I chain up my compile command for foo/bar/baz.scm <leoprikler>and meson puts baz.go into build/ instead of build/foo/bar <leoprikler>and there's no way of telling it "yes, I would like build/foo/bar, though, tyvm" <leoprikler>Installing is no problem, but you can't use the build directory for GUILE_LOAD_COMPILED_PATH, which sucks for debugging obviously <zimoun>bavier[m]: to have seen the transition of Gmsh from configure&co. to CMake, it was then much easier to add/remove contributions for newcomers. :-) <civodul>mothacehe: "make check TESTS=tests/crate.scm" succeeds once you've installed guile-semver <mothacehe>civodul: ok, but I fear that "guix build guix" doesn't. <vits-hobo>seem trouble was fs size of /var/log. so ist es. <civodul>mothacehe: even with guile-semver as an input? <civodul>can you paste the test-suite.log output in that case? <civodul>mothacehe: wasn't the log dumped at the end? <zimoun>civodul: about Ivy, it seems your problem is that default-directory is not the thing you expect. I guess. <mothacehe>does this mean guile-semver is a new dependency? You should add it to configure script + documentation in that case <civodul>mothacehe: yes i've updated the manual + tests locally <civodul>it's apparently meant as a "soft" dependency <civodul>so i changed tests/crate.scm to skip those that really need it <jlicht>how would one add a "soft" dependency to guix? <civodul>just autoload the thing (at run time) <civodul>we do that for guile-charting for instance <mothacehe>civodul: awesome, I'll update Guix package right after then! <jlicht>so they don't have to be listed in Makefile.am then? Good to know :-) *jlicht hurt it self in its confusion, ignore the previous statement <civodul>jlicht: dependencies are not listed in Makefile.am :-) <civodul>the scm files still need to be there <civodul>in practice "guix pull" grabs guile-semver unconditionally <ngz>Hmm it seems like I cannot push anymore to the repo… <bandali>fsf/gnu is experiencing partial network outage <zimoun>civodul: this network outage leads to “guix time-machine” error and it should not be the case, since the commits are already in my ~/.cache. Well, is it a feature or a bug? <civodul>if you're specifying a commit and it fails, then it's a bug <civodul>works for me: if i do "guix time-machine --commit=C", where C is the commit shown by 'guix describe', it works <zimoun>civodul: guix describe says 17d9a91, then git -C ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/ show 26e92a3025 works, then guix time-machine --commit=26e92a3025 -- help fails. <civodul>zimoun: does it work if you pass the full SHA1? <zimoun>civodul: maybe this piece (not (reference-available? repository ref)) in update-cached-checkout. Or so reference-available? in guix/git.scm and so commit-lookup. As you said, interesting. :-) <civodul>zimoun: i think we should be using object-lookup-prefix <zimoun>thanks civodul for the quick fix. And thanks Savannah to be off just right now otherwise, it would be really hard to hit it. ;-) <zimoun>civodul: it appears that with-ivy-window seems buggy becayse if you add right after (message default-directory), it display the Git root and not the right directory. <dannym>Setting up the novena went a lot further now. I am more-or-less booted over SATA (except for u-boot itself) <sneek>dannym, raghavgururajan says: Sorry Danny! for putting you in the awkward position regarding the cosmetic issue. :-( <dannym>vagrantc: Did you also try to boot the novena via SATA, or just SD card ? <dannym>Seems that they expect all kinda of funny stuff (according to novena-image.sh)--for example they explicitly set a special disk id <vagrantc>dannym: i honestly don't quite recall :) <vagrantc>dannym: using upstream u-boot it just follows normalish distro_bootcmd stuff <dannym>then u-boot never appears if I take the sd card out :( <vagrantc>yeah, i've only ever used u-boot from microsd <vagrantc>but u-boot should be able to load from sata <dannym>In order to make it work to use u-boot from microsd to boot guix from sata I have to do: <dannym>* First copy the hard drive's /boot/extlinux/extlinux.conf to the microsd's /boot/extlinux/extlinux.conf, overwriting the latter <dannym>* Reboot into U-boot-from-the-sd-card <dannym>* Stop autoboot (otherwise it fails and eventually falls back to sd card boot because there's still an old guix generation for it (because I used cp -a to get everything from the sd card to the sata drive)) <dannym>* Type: part list sata 0 -bootable devplist <dannym>Then it indeed boots Guix from sata starting from the u-boot from microsd <sneek>Welcome back davidl, you have 1 message! <dannym>But this is supposed to be a server--I don't want to keep it like that <vagrantc>dannym: i probably hooked up a boot script or something to initialize the sata <janneke>hey danny, i have some great arm tcc progress <janneke>dannym: i started a terrible bisect, simplifying c constructs, and now have a pretty ugly "arm-bisect" branch that builds boot2-tcc <janneke>so that's mescc => mes-tcc => boo0-tcc => boot1-tcc => boot2-tcc <janneke>but then boot2-tcc segfaults building tccgen.c <janneke>more (probably good news) is that boot2-tcc also segfaults when we start with arm-unknown-linux-gnueabihf-gcc! <janneke>so...the problem now isn't mes, but probably the way we incrementally add HAVE_LONG_LONG and HAVE_FLOAT, in some interesting combiniation with arm <janneke>the bad news is that i haven't been able to find a construct yet that mescc compiles wrongly, i.e., no failing test yet <janneke>also, i tried a few attempts at cleaning up the mess that "arm-bisect" is in, and until now they all fail to produce the same result, which puzzles me <dannym>I'm pretty sure bad things (tm) happen if our longjmp is being used for a tcc with float support, because I don't store or restore any floating point registers <dannym>But that tcc probably has its own longjmp implementation ? <janneke>no, tcc has not; but we're not using it <janneke>we'll might need a better version once we start with the guix bootstrap, dunno <dannym>Maybe, maybe not. If it's replaced soon enough in the bootstrap chain it's fine <dannym>But now that I added gcc support to longjmp (in addition to mescc), I just want to point out that doesn't mean tcc should be using it :) <dannym>But ok, it's something else then <dannym>What kind of segfault is it? Can I see some arm assembly around there? <jonsger>is there a way to abort builds of cuirass? <janneke>dannym: initially, when creating the tcc bootstrap, i added the HAVE_FLOAT_STUB stage prior to enabling HAVE_FLOAT <janneke>that proved to be unnecessary for x86, maybe we need it for arm (parsing floats, otherwise ignoring them) -- dunno <jonsger>hm, guix seems to ignore the --cores= option for the daemon. Now even for gcc, formerly it was only during rust builds ***rekado_ is now known as rekado
<dannym>janneke: Uhhh... who emits those stfd and ldfd instructions? <dannym>Those are for FPA, an old ARM floating point accelerator, and are not supported in any of the newer models <dannym>(supported in neither VFP nor in Neon) <dannym>I've searched through mes-tinycc but not found mention of any ldfd nor stfd instruction emitters <dannym>./arm-gen.c: tcc_warning("Support for FPA is deprecated and will be removed in next" <dannym>Yeah, so now it's trying to use hardware floating point <dannym>I was hoping that tcc would implement softfloats <dannym>(Note: has been disabled by grischka, not us) <dannym>In order to progress, our best bet is to enable flag TCC_ARM_VFP <dannym>But my config.mak has CONFIG_arm_vfp, so why isn't it enabled? <euandreh>I mean, using wrap-program over a propagated input <euandreh>I'll send another patch in a few minutes, then <lfam>You're welcome! Thanks for following up with an improvement <janneke>dannym: ah, i saw that in the gcc build <janneke>we are not using any of the standard configure stuff; our bootstrap build is fully scripted <janneke>the weird thing is that the gcc-built tcc does not fall into this trap -- weird <janneke>i didn't keep the logs, i'm doing a rebuild to look <dannym>'./arm-gen.c: tcc_warning("Support for FPA is deprecated and will be removed in next"' seems to be in a #if 0 block, beware! <dannym>Would still be interesting to know <janneke>i can try that with the gcc-built tcc... <janneke>in order to get that to work with the mes-tcc bootstrap, i could try simplifying the TCC_ARM_VFP branches...but i'd rather pause here then and finish the bisecting; corner and fix the bug that is avoided by this bisecting and simplification work <dannym>(But whoever emits those FPA instructions is wrong; those won't work on Banana) <elais>civodul: I did run into trouble doing the etc-service-type but using the `extra-special-file` procedure I was able to place the channel file <bdju>does anyone here have a pinephone or other device running postmarketOS? I'm trying to get USB Internet working on it, but the instructions only cover other distros, and so far I haven't been able to figure it out. <bdju>I just need to do this temporarily due to some wifi issues, so nothing needs to be saved to configs really <bdju>I did the sysctl command, but I haven't got iptables or firewall-cmd. my attempt at the first nmcli command in the RHEL section tells me my interface is invalid even though it's exactly what's listed in both `ip a` and `nmcli` outputs <civodul>elais: nice! it'd be worth sharing your findings on guix-devel <bdju>lispmacs[work]: possibly. sounds like some sort of firewall is required for the routing. for now I gave up on that and plugged in a usb to ethernet adapter <bavier[m]>civodul: debian has a big patch to their scotch package to have it make shared libs <jeko_>is there a command to see which conf nginx is using? <elais>civodul: improve on it how so? Maybe adding a operating-system field for declaring system wide channels but I think its handled pretty elegantly by defining a scheme file-like object and symlinking it into place with that extra-special-file procedure. I think this is the ideal use case for that, though it is pretty hidden in the docs. <civodul>elais: yes you're right; it would just be nicer if we could do that via etc-service-type maybe, dunno <civodul>bavier[m]: big patch is not great, maybe better wait until they DTRT upstream <janneke>dannym: okay, and the hope is that using TCC_ARM_VFP will not emit those instructions? *janneke runs yet another bisect <bavier[m]>civodul: agrred. Can you work with .a in the meantime? <civodul>bavier[m]: yes; i was just wondering if you had tried and failed before <dannym>I think it should be possible on enable TCC_ARM_VFP even without enabling EABI (the latter would require us to do syscalls differently than we currently do) <elais>civodul: well I sent it to the mailing list. This is my first time be gentle. <civodul>don't be afraid, the list is full of nice folks :-) <zimoun>Hum? We are couple of days after v1.2 and fresh install on foreign distro says at the first “guix pull“: 9edb3f6 à c235233 (9 323 nouveaux commits). Why? Have I missed a merged? <zimoun>roptat: awesome! it is the first I am seeing the FR locales. :-) <mdevos1>local substitute server discovery doesn't work for me when there aren't any substitutes servers on the local network <mdevos1>error message when performing ‘guix build hello’: substitute: In procedure open-file: No such file or directory: "/var/guix/discover/publish" <mdevos1>Maybe read-substitute-urls from (guix scripts discovery) should return an empty list if /var/guix/discover/publish doesn't exist? <civodul>mdevos1: hi! it's been fixed just earlier today <civodul>zimoun: this is the number of commits since the "introductory commit" <mdevos1>I pulled recently, so I assume (guix scripts discover) is a guix daemon thing? <roptat>zimoun, I suspect this is because it checks all commits from the introduction point <zimoun>roptat, civodul: ah, make more sense. Indeed. :-) So the install part will be longer and longer, right? +10,000 commits between each release. <roptat>not if we change the introduction, and every subsequent guix pull will only check the new commits <zimoun>yeah I have been allowed to play with a new machine at work \o/ <zimoun>roptat: for now, the authentication is fast enough to be neglectible, so it is not a real issue. Well, that’s my understanding. <civodul>zimoun: we should start from the commit in use: start authenticating from v1.3.0 when you install v1.3.0 <civodul>otherwise the first 'guix pull' on v10.0 will be rather expensive :-) <zimoun>civodul, ah too late. But yeah that’s my point. :-) <mdevos1>apparently, guix system switch-generation doesn't restart the guix daemon, even if a flag changed (discover? #t/#f in my case). <mdevos1>if I'm disconnected, it's due to my system crashing while restarting guix-daemon <lfam>I wonder about patches that come with author email addresses set to "Foo via Guix-patches via <guix-patches@gnu.org>" <lfam>Should we try to find a better address? <lfam>Is there anything we can do to improve the submission process here? <roptat>zimoun, I think it's the standard translation, it comes from biology, right? <mdevos1>Is it possible to change the parameters to guix-daemon at runtime? I don't feel like building dozens of rusts locally jut to upgrade guix to a version with fixed substitute discovery. <lfam>Or, how do these patches get such an email address in the first place? <zimoun>roptat, yeah but I have done the link :-) <lfam>mdevos1: Which parameter do you want to change? In general, you have to restart the guix-daemon to change it's arguments <mdevos1>restarting guix-daemon is fine for me, but I wouldn't know how <lfam>Hm, I think you'd have to edit config.scm, reconfigure, and reboot <lfam>If you need to rollback without having to build anything, you could reboot and pick an older system generation from the GRUB menu <lfam>It would be nice if there was something that didn't require a reboot... maybe it's not necessary to reboot after reconfiguring in this case. <mdevos1>lfam: I was trying to avoid edit + configure, as I'm on a Guix with somewhat broken substitute server discovery <lfam>You can also do things "the hard way", kill the daemon and run it "manually" with the arguments you want <lfam>But that's just a short-term solution <lfam>It would avoid having to reboot right now just to do --discover=no <mdevos1>lfam: I'll just reboot before I accidently break my system <lfam>I don't think you can break it this way but I understand :) <lfam>The daemon is not really that important to running the system <lfam>sneek: later tell mdevos1: It would just be a matter of copying the command-line from `ps aux | grep guix-daemon` and changing the arguments