IRC channel logs


back to list of logs

<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>lfam: True!
*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
<vagrantc>bdju: you could check the git logs
<bdju>I don't keep a copy of the repo around, or if I do it's not kept updated at least
<vagrantc>bdju: but guix does :)
<vagrantc>i think it's in .cache/guix/ somewhere
<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
<hurricos>oh hey!
<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
<hurricos>OK, the replacement firmare for the SOIC should be buildable with
<hurricos>(for the veyron / veyron-jerry rk3288)
<guix-vits>sneek: bambam?
*raghavgururajan responded to the cosmetic commits issue
<raghavgururajan>sneek: botsnack ?
<raghavgururajan>sneek, later tell dannym: Sorry Danny! for putting you in the awkward position regarding the cosmetic issue. :-(
<xelxebar>bdju: I don't see that error on my end.
<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>kozo[m]: idk. maybe that's kernel changed?
<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]
<kozo[m]>Oh.. kernel... ya
<kozo[m]>thanks guix-vits
***db48x` is now known as db48x
<rekado_>Debbugs is frustrating
<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>Hey !
<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>what's the matter?
<olivuser>hello guix o/
<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
<olivuser>whats the matter?
<jeko>Hey olivuser!
<jeko>what about running `guile` in a terminal?
<olivuser>works fine
<olivuser>you think I need to alter $PATH in my init.el?
<jeko>I am not sure.
<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 ?
<olivuser>Guix System
<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>jeko, yes
<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
<olivuser>(when in exwm that is)
<civodul>Hello Guix!
<jeko>civodul: Hey!
<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
<emys>also glibc-locales
<jeko>emys: you don't need glibc-utf8-locales
<civodul>emys: hi! is this with Guix 1.2.0?
<emys>civodul, guix (GNU Guix) 36a7af816186eca1927b232dd25c8bd804ba38f9 according to guix --version
<civodul>ok, that's from Sept.
<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
<civodul>and type "hash guix"
<civodul>didn't it?
<civodul>(see <>)
<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
<civodul>great :-)
<jeko>mbakke: Does that mean certbot will do its labor at 12:00? Or does it mean it won't ? 😅️
<jeko># herd schedule mcron
<jeko>Fri Dec 4 12:00:00 2020 +0100
<emys>civodul, do I need to install guix via guix for that to work?
<emys>because the source statement just changes the path
<civodul>emys: no no, just run "guix pull"
<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
<emys>ah I see now
<emys>never mind
<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
<civodul>but dunno, we'll have to try :-)
<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
<leoprikler>perhaps you can try to extend guix-service-type
<emys>what is still unclear to me after reading is whether I need to make one or two definitions for GUIX_PROFILE
<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`?
<civodul>emys: exactly
<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
<elais>Er, seeing
<ArneBab>is scanelf packaged in Guix?
<emys>civodul, I'll send in a patch fixing a typo on the Getting-Started page , I have also already submitted my patch. Will probably show up in a bit
<emys>I did submit this patch a few days ago fixing and adding Gnu Smalltalk builds: anything that would be still missing from my side?
<civodul>emys: maybe not, but it can take time before volunteers catch up :-)
<civodul>a couple of suggestions...
<civodul>i'd just keep the VCS variant of smalltalk-next, the one that uses 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>np ;-)
<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>i'll be on stable kernel from now
<bog_dan_ro>Hi, I'm trying to download Guix on Hurd from but the link is dead. Is there another way to download it ?
<vits-hobo>bog_dan_ro: on .../latest, see 'Build details: link'
<vits-hobo>follow link. there will be line 'Build outputs'
<vits-hobo>ah, 502.
***chrislck_ is now known as chrislck
<mothacehe> bog_dan_ro: do you have a Guix checkout somewhere?
<bog_dan_ro>not yet
<bog_dan_ro>shall I use to make one ?
<mothacehe>yes first you can follow:
<mothacehe>to download Guix sources
<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 :(
<bog_dan_ro>mothacehe: NP, many thanks for the tips ;-)
<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
<jlicht>hey guix!
<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?
<jeko_>no clue
<rekado_>sneek: later tell davidl
<rekado_>sneek: botsnack
<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
<mroh>mbakke: ty!
<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
<PurpleSym>Reconfigured a system and now `guix package -u` crashes when substituting:
<civodul>mothacehe: looks like a bug! ↑ :-)
<civodul>PurpleSym: i suspect you can work around it by creating said directory
<mothacehe>civodul: yes it should be fixed by 79fd9f
<mothacehe>but maybe I need to update guix package
<civodul>so i guess PurpleSym should pull & reconfigure?
<civodul>but wait
<civodul>why /var/guix/discover?
<civodul>should be /var/cache/guix/discover, no?
<civodul>so replacing %state-directory by a call to xdg-cache-home or so
<civodul>WDYT, mothacehe?
<PurpleSym>/var/guix/discover/ exists, but it’s empty.
<civodul>PurpleSym: "sudo touch /var/guix/discover/publish" i suppose
<PurpleSym>Yep, that did the trick.
<mothacehe>civodul: there's /var/guix/offload that exposes kinda the same information
<mothacehe>so I chose /var/guix/offload
<mothacehe>but no strong preference
<civodul>i feel /var/cache may be more appropriate here because it's really just a cache
<mothacehe>sure, I'll change it and update guix then
<civodul>(and i think we used /var/guix too much in the past)
***sneek_ is now known as sneek
<mothacehe>civodul: this does the trick:, wdyt?
<civodul>mothacehe: you can use the xdg-cache-home procedure, no?
<civodul>mothacehe: ah no, it's called cache-directory, in (guix utils)
<mothacehe>hehe just found it :p
<civodul>i miss Helm's git-grepping facilities
<civodul>tried to get the same in Ivy but it doesn't quite work
<mothacehe>I'm using emacs-ag which works pretty well
<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.
<civodul>bavier[m]: heh sure :-)
<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)
<bavier[m]>oh no!
<civodul>still an improvement, no?
<bavier[m]>well, the hand-crafted Makefile's do suck.
<civodul>yeah, big deal even
<bavier[m]>well, autotools would be better ;)
<civodul>i agree but it's not in fashion
<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!
<civodul>mroh: like this:
<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
<mothacehe>looks like we have an issue with the "crate" tests:
<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>(Especially when dealing with GNOME stuff.)
<leoprikler>The problem is working with tools they haven't considered yet is a bit of a pain.
<leoprikler>(Tools such as guild.)
<civodul>ah ha! "guild compile"?
<civodul>tell us more about your feelings :-)
<leoprikler>I handcrafted my own for a project of mine.
<civodul>oh got it
<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 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
<leoprikler>when is "then"?
<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?
<mothacehe>restarting with -K, it may take a while :)
<civodul>mothacehe: wasn't the log dumped at the end?
<mothacehe>yes but my terminal history is too short
<mothacehe>ok so tests do pass with:
<civodul>mothacehe: yay!
<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
<mothacehe>s/You/We sorry
<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 then? Good to know :-)
<jlicht>s/they/the scm files/
*jlicht hurt it self in its confusion, ignore the previous statement
<civodul>mothacehe: pushed!
<civodul>jlicht: dependencies are not listed in :-)
<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
<janneke>bandali: thanks for the headsup
<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>zimoun: you mean with --commit=XYZ?
<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>yes, try another older commit.
<civodul>it also 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.
<zimoun>Do I miss something?
<civodul>zimoun: does it work if you pass the full SHA1?
<zimoun>ah yes, it works.
<civodul>yes it fails :-)
<civodul>with the short ID
<bandali>looks like we're coming back up :-)
<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
*civodul tries
<civodul>yes, that does the trick
<civodul>thanks zimoun :-)
<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.
<bavier[m]>how does the mingw stuff in guix work?
<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, you have 1 message!
<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 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>I used novena-eeprom to set up sata according to
<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>No, then it doesn't initialize sata by default, probably because of this patch
<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: sata init
<dannym>* Type: part list sata 0 -bootable devplist
<dannym>* Type: run sata_boot
<dannym>Then it indeed boots Guix from sata starting from the u-boot from microsd
<davidl>rekado_ thx for the link
<sneek>Welcome back davidl, you have 1 message!
<sneek>davidl, rekado_ says:
<dannym>But this is supposed to be a server--I don't want to keep it like that
<dannym>(better than nothing, though)
<vagrantc>dannym: i probably hooked up a boot script or something to initialize the sata
<dannym>I see
<janneke>hey danny, i have some great arm tcc progress
<dannym>janneke: Awesome! Tell me :)
<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
<vagrantc>segfault can be a form of progress :)
<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'd booby-trap longjmp
<dannym>If it's still ours used
<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
<dannym>Oh good
<janneke>we'll might need a better version once we start with the guix bootstrap, dunno
<janneke>*we might
<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: (no asm yet); looking into that
<janneke>dannym: asm =>
<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>Did this warning come? ;)
<dannym>Ah, it has been disabled by us
<dannym>Yeah, so now it's trying to use hardware floating point
<dannym>And an unsupposed version of it
<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?
<dannym>(and thuse FPA disabled)
<euandreh>is using '(wrap-program ...)' a solution to what lfam raised here?
<euandreh>I mean, using wrap-program over a propagated input
<lfam>Yes, it's better
<euandreh>hey there
<euandreh>ty for the patch reviews, BTW
<nckx>euandreh: Probably.
<nckx>Morning Guix.
<euandreh>I'll send another patch in a few minutes, then
<lfam>You're welcome! Thanks for following up with an improvement
<janneke>dannym: oh, interesting...
<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>oh, haha
<janneke>but no, we're not using TCC_ARM_VFP
<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)
<dannym>(or any newer ARM CPU)
<euandreh>lfam: here you go
<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
<lispmacs[work]>do u need iptables installed?
<civodul>elais: nice! it'd be worth sharing your findings on guix-devel
<civodul>perhaps we can improve on that
<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?
<jeko_>or to clear old ones
<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
<civodul>let's hope they switch to CMake
<civodul>(don't quote me out of context :-))
<bavier[m]>heh, np :)
<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>elais: thank you!
<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?
<mdevos1>I'll prepare a patch
<civodul>mdevos1: hi! it's been fixed just earlier today
<civodul>you may have to pull & reconfigure
<mdevos1>civodul: nice
<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, :D
<civodul>mdevos1: yes
<roptat>zimoun, I suspect this is because it checks all commits from the introduction point
<roptat>since it's your first install
<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.
<zimoun>«greffe» for ‘graft’, neat! :-)
<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 :-)
*civodul -> zZz
<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 <>"
<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 :-)
<zimoun>*never 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>--discover=yes --> --discover=no
<mdevos1>restarting guix-daemon is fine for me, but I wouldn't know how
<lfam>Are you on Guix System?
<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
<mdevos1>lfam: I'll reboot
<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
<mdevos1>lfam: better safe than sorry
<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
<sneek>Got it.