IRC channel logs

<nckx>Guest28: There's ecryptfs. Guix has both the ecrypts-utils user-space tools and kernel support. I don't know if it's still considered secure. Probably depends on your threat model, as always.

<frog>RavenJoad: looking at my system, nginx, smtpd, and nscd all have their config files in the store passed as an argument.

<nckx>RavenJoad: The latter.

<RavenJoad>Guest28: I use cryptsetup for that kind of stuff.

<RavenJoad>Ok. I will see if some wrapping is required to make that possible. No using etc-service-type then!

<nckx>If you're willing to encrypt & mount a block device (rather than ‘a directory’) it's miles better than anything like ecryptfs and probably more secure. Definitely more audited.

<nckx>It = dm-crypt.

<Guest28>Thanks for the help

<Guest28>nckx: Why would block encryption be so much more secure?

<oriansj>a block volume can't expose any data about the size of its contents and no pointers to the inside of the encrypted block to indicate where a file is

<oriansj>or its type

<Guest28>ah, I understand. Thanks

<nckx>I'm not going to make any pronouncements on theory (because I'm a non-cryptographer and we have a poor track record of saying stupid shit about cryptography), but in practice things like encfs, ecrypts, etc. see significantly fewer qualified eyeballs and maintenance. And are harder to get right. And tend to leak more metadata even when working as intended.

<nckx>Since you're doing this for peace of mind, why compromise.

<Guest28>Yep, makes sense

<Guest28>My system builds Git 1.41.0 although the commit is 6 days old... Can't I configure Guix in a way that it won't proceed if it needs to build?

<nckx>The commit is less than a day old. My timestamps are lies.

<nckx>I'd expect there to be substitutes by now, though. It's been hours.

<nckx>Cuirass doesn't seem to be evaluating: https://ci.guix.gnu.org/jobset/master

<nckx>(db803cc predates the git update)

<RavenJoad>My favorite part about Guix is understandable system tests with marionettes. It is making my life sooo much easier.

<nckx>I'm afraid I don't have time to look into CI tonight.

<Guest28>nckx: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=55476119dd2aeb8fc6427098d928a1c9db451ff7 isn't it 6? How can you get less than a day

<nckx>Lies!

<nckx> https://packages.guix.gnu.org/packages/libfaketime/0.9.10/

<Guest28>nckx: Sure, no problem. I just wondered because this could be a indication for a problem or something and I just wanted to make sure everything works as expected

<Guest28>thankfully it is Git and not something like llvm

<nckx>ACTION away. o/

<nckx>(I made that commit, to be clear.)

<Guest28>Ah, so you may committed it on 02 July but pushed it upstream yesterday? Therefore it says 6?

<RavenJoad>What is the "minimal" program to use for a service/daemon that wants to use a mail command?

<nckx>Guest28: It's true that git commit dates can differ greatly from when they were actually pushed, but no, I mean I literally fake the time on all my commits to ‘last Sunday’ regardless of when they are authored, signed, or pushed: https://paste.debian.net/plainh/1c7ce3f3 . That's just me. Other committers are not so silly.

<nckx>I've restarted Cuirass on berlin and it is now evaluating.

<nckx> https://ci.guix.gnu.org/eval/582848

<nckx>Not sure what happened.

<nckx>ACTION → 😴💤

<Guest28>Ah, well with that background information it makes sense. Do you mind sharing why you created that kind of workflow?

<Guest28>Workflow isn't the right work choice but I don't know the correct word for it

<Guest28>s/work/word

<singpolyma>RavenJoad: ssh to mailserver, when that's an option

<RavenJoad>singpolyma: In this case, mail is called by scripts which are run when a UPS event happens. The daemon fails on trying to mail something right now.

<DigitalKiwi>plot twist: script works fine but the router isn't on the UPS

<RavenJoad>As funny as that would be, that is also not the case. apcupsd runs on a standalone computer and monitors messages from the UPS. So the mail comes from the computer. But I just need a package that provides a reasonable mail command without blowing up the closure size.

<DigitalKiwi>[nixos@MSI-16Q4:~]$ nix-shell -p nullmailer

<DigitalKiwi>this path will be fetched (0.08 MiB download, 0.42 MiB unpacked):

<RavenJoad>That works for me.

<Guest28>If I create a system image with guix system image, is the Guix commit version the same as the one from the system running the command?

<RavenJoad>Guest28: I believe so? That is an easy one to double-check.

<nckx>ACTION woke.

<nckx>Guest28, assuming you're still the same Guest28: https://paste.debian.net/plainh/e7ac8131

<nckx>Guest28: It should be the version shown by ‘guix show guix’ on the creating system. So, older.

<Guest28>nckx: Yes, I am the same one (rebooted system, since I updated it)

<Guest28>Okay older, yea because I wondered. It didn't find the variable because it was some commits behind the version I created it with

<Guest28>Created it with 87c3fab8543396d09be5513aff91c1245aca4229 but the system itself was on 8e2f32cee982d42a79e53fc1e9aa7b8ff0514714

<nckx>We have to update the guix package twice (in two separate commits) for certain changes for this reason.

<nckx>I don't know which kind of image we're talking about, but it's generally a good idea to ‘guix pull’ on a newly-installed system.

<nckx>s/on/even on/

<mirai>is there a primer on how to build java apps? (best if guix specific)

<Guest28>My system on the rpi takes some time to synchronize time with ntp. How can I have correct date at boot time?

<nckx>Heh. My X230T has an drifty RTC that openntpd was too weak to handle. I just switched to (ISC) ntp but haven't tested it yet. Which NTP daemon are you using?

<Guest28>(service ntp-service-type)

<nckx>Meh.

<nckx>I guess allow-large-adjustment? isn't magic.

<nckx>In what way does it take some time? Slow slewing (small adjustments) towards the correct time? Or one big jump that happens later than expected/desired?

<Guest28>well, the pi boots with 1970 as date and after like 1 or 2 minutes ntp syncs it back to 2023.

<nckx>Does ‘ntpdate -b’ adjust it faster? If so, you could invoke it at boot time (in a loop or waiting until your network's up). It's been deprecated since forever, but hey.

<Guest28>and I don't understand why, the timezone is set correctly. isn't ntp used to have exact time? so the system should itself at least be aware that it is not 1970

<Guest28>well (timezone "Europe/Berlin") is basically useless on pi and I wonder why

<nckx>I'm not (yet!) familiar with ntp since I haven't booted with it yet. Maybe it waits a while by default? Maybe it tries, fails because your network isn't yet up, and only retries after 2 minutes?

<Guest28>hmm

<nckx>I'm not sure how timezone is related.

<Guest28>yea nvm. timezone is something else

<nckx>(Even if there wasn't a single Europe/Berlin time zone, say, pre-1989, I don't think the system is *that* clever… :)

<Guest28> https://paste.debian.net/1285277/ this is the log of ntpd

<Guest28>i wonder if my hwclock is out of sync since kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

<nckx>So ‘yey we haz networking, waking up resolver’ waits almost an exact minute to do… stuff.

<Guest28>ah, i think the pi simply has no hardware clock and therefore it behaves differently than my desktop machine

<nckx>That ‘error’ just means that the clock hasn't been marked as synchronised. And of course, at boot, your hwclock *is* extremely out of sync.

<nckx>Yes.

<nckx>It might not even have one, only a ‘system clock’, or certainly not a battery-backed one.

<Guest28>root@raspberrypi-guix /var/log# hwclock --verbose

<Guest28>hwclock from util-linux 2.37.2

<Guest28>System Time: 1688780150.000304

<Guest28>Trying to open: /dev/rtc0

<Guest28>Trying to open: /dev/rtc

<Guest28>Trying to open: /dev/misc/rtc

<Guest28>No usable clock interface found.

<nckx>Heh. None: https://learn.adafruit.com/adding-a-real-time-clock-to-raspberry-pi/overview

<Guest28>board"

<nckx>Guest28: Use paste.debian.net for messages over ~3 lines. You were quieted by a bot for flooding.

<Guest28>Ah okay, well I thought no one is online anyways and open new tab copy/paste copy link was to much for me

<Guest28> https://github.com/wingo/fibers/issues/89 so this issue is probably the cause for my shepherd hanging since my pi has always the wrong time in the beginning

<nckx>Ooh. Nicely thickening plot you found there.

<Guest28>It all makes sense now. What a great feeling to understand why a computer behaves not like it should behave

<nckx>Guest28: Try booting with the iburst option to your server(s).

<nckx>(grep the manual for how.)

<nckx>It'll still be too late for shepherd but might solve the minute-long ‘delay’ (which is really just ntp waiting ‘minpoll’ seconds).

<nckx>(If my hypothesis is correct.)

<Guest28>well, now that I know why it behaves like that, I am okay with it. It just bothered me that it was not consistent with other Guix machines.

<Guest28>dark theme version for the web docs would be nice. Maybe I should just learn how to probably use Emacs and the builtin info

<Guest28>nckx: I am going offline. Appreciate all the help from you. Good night.

<nckx>In the mean time, there are Firefox extensions that do this.

<nckx>So am I. See you!

<oriansj>nckx: that a nondeterministic computer will behave: nondeterministicly. Well yes, otherwise we couldn't use that to do random number generation (The basis of all crypto deployed these days).

<ulfvonbelow>so a strange thing happened just now. I gave a huge list of things to build to 'guix build' with --keep-going, and it built a ton of stuff up to and including ungoogled-chromium, but one build failed, and I just now gave it the same list of things to build again (haven't run guix pull or anything like that) and now it's building bootstrap binaries. I haven't told it to run 'guix gc' at any point, and 'guix graph --type=derivation' tells

<ulfvonbelow>me that the things it successfully build just a little while ago definitely depended on the exact same derivations as are now being built.

<ulfvonbelow>I wonder if this has anything to do with this being done on a system that has itself as a substitute server

<PotentialUser-78>@frog Thanks for the heads up. That's a great catch. But I don't want `guix build...` to run the 'test or 'check phase to begin with.

<jpoiret>janneke: did you report the hurd gnulib test problems upstream?

<jpoiret>also, i'm considering adding a job on CI for hurd

<jpoiret>i'd need to add a new manifest though that would be like release-manifest.scm but with only cross-builds to hurd

<jpoiret>uh, actually since we shouldn't change the derivations of the other archs I can just keep the release manifest 🤔

<janneke>jpoiret: no, i haven't reported those yet

<frog>PotentialUser-78: adding #:tests? #f to the arguments of a package only disables tests for that one package. you disabled tests for python-dirsearch, but that doesn't affect python-pyspnego. if you want to try build python-pyspnego without tests, you can either (option 1) define a package inheriting from python-pyspnego that has tests? as #false and use that as a dependency of python-requests-ntlm, or, (option 2) add

<frog>--without-test=python-pyspnego to your "guix build" command. alternatively, you can update the python-pyspnego package to the latest version and that will fix the tests iirc.

<yarl>Hello guix

<yarl>Can someone point me to the code where guix-daemon is upgraded by a guix pull please?

<jpoiret>yarl: guix-daemon is *not* upgraded by a guix pull

<ulfvonbelow>it may be upgraded in certain circumstances

<jpoiret>well, there's no specific code in `guix pull` to upgrade your running guix-deamon

<jpoiret>sure, the newer guix profile might contain a newer daemon binary, but that's it. In most cases, it's not the one being used

<ulfvonbelow>IIRC on foreign systems that start guix-daemon via the foreign system's init system, root's guix profile is used to launch the daemon

<jpoiret>I don't think it's done by default, even though it's a better setup

<jpoiret>since when installing root doesn't have a profile either

<yarl>I am reading : 2.7 Upgrading guix.

<jpoiret>are you on a foreign distro yarl?

<yarl>Yes

<ulfvonbelow>ExecStart=@localstatedir@/guix/profiles/per-user/root/current-guix/bin/guix-daemon ...

<jpoiret>which one? it might depend on your packaging

<ulfvonbelow>(from etc/guix-daemon.service.in)

<yarl>arch

<yarl>I'll be more precise.

<jpoiret>ulfvonbelow: see eg. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=guix#n127

<jpoiret>root's profile doesn't exist when installing the initial guix, so most distributions rewrite this unit file to point to the /usr/bin/guix-daemon

<yarl>How is constructed the channel file?

<ulfvonbelow>ah, didn't know guix was in other package repos now

<yarl>I guess it includes everything under gnu/packages, what else?

<yarl>Actually, I installed guix using the script.

<jpoiret>yarl: wdym the channels file?

<yarl>jpoiret: Well, sorry if I am unclear.

<ulfvonbelow>like ~/.config/guix/channels.scm?

<yarl>I am trying to understand.

<yarl>When I guix pull, that gathers package definitions, right?

<yarl>When I guix upgrade, that builds or substitutes those packages.

<nckx>oriansj: What were you responding to?

<jpoiret>aha, the install script does the right thing™, ie. it sets up root's first profile

<yarl>But when modifications are done to the daemon on the guix repository. How does one eventually get these modifications?

<jpoiret>`guix pull` doesn't just gather package definitions, it builds guix as a whole

<ulfvonbelow>'guix pull' updates the guix in your user's guix profile (~/.config/guix/current), which also updates the package definitions included with it.

<jpoiret>(I'm simplifying here, since it doesn't really try to build the guix daemon from where you pulled, but rather from the guix package definition that's contained in it)

<jpoiret>so, whenever someone updates the guix package in (gnu packages package-management), everyone's subsequent pulls will build the new daemon that corresponds to that new package definition

<yarl>jpoiret: Thank you. I cannot see "guix" when I run guix package -I. why?

<jpoiret>that's because the `guix` package is not installed

<ulfvonbelow>note that 'guix package ...' by default operates on the profile at ~/.guix-profile

<jpoiret>there's a guix installed in the profile `.config/guix/current`

<jpoiret>but it's not the guix package that's defined in (gnu packages package-management) either

<jpoiret>it's something that's computed on `guix pull` by `build-aux/build-self.scm` then `guix/self.scm`

<ulfvonbelow>the build system details are one of the more confusing parts of guix IMO

<yarl>jpoiret: ok. I will look at that. Thank you!

<jpoiret>the code that triggers this from the current guix is `guix/scripts/pull.scm` which then defers most of the interesting stuff to `guix/channels.scm`

<yarl>Hmm. `guix package -p .config/guix/current -I` : guix

<nckx>You've found the magic.

<jpoiret>janneke: I'm thinking of pushing all of 1) the libc stuff 2) rumpdisk 3) netdde at the same time

<jpoiret>is that a good idea?

<jpoiret>seems manageable to me

<janneke>jpoiret: i think that would work

<janneke>be sure to also squash the top commit

<janneke>8bdaadbe25 * hurd-team origin/hurd-team gitlab/hurd-team squash! gnu: Add rumpkernel.

<jpoiret>Yep, I was thinking of that as well

<jpoiret>there's still the second boot stuff that we need to sort out

<jpoiret>none of the solutions seemed super clean to me

<jpoiret>but that's for later

<janneke>great

<janneke>yes, indeed

<jpoiret>by the way (I'll send some corrections for this), (or native-inputs inputs) is the idiomatic method

<janneke>those patches haven't really been looked at

<jpoiret>instead of or'ing around both (assoc-ref input "...")

<janneke>ah, sure

<janneke>ACTION likes cleanups!

<janneke>esp. if they (still) work ;)

<jpoiret>where can I find your public key, by the way?

<janneke>jpoiret: https://savannah.gnu.org/people/viewgpg.php?user_id=4348

<jpoiret>thanks!

<jpoiret>wrt. the tests that you disabled for 32-bit systems, do they not work currently?

<janneke>jpoiret: they failed on my x60

<janneke>i've no idea how they pass, possibly they work on 64bit hardware?

<jpoiret>i'll squash 3e648d4f77b502f2698ac8b4ca08ab7fb713cb0d (gnu: netdde: Support native build on the Hurd.) onto the first netdde commit. Also, it's missing some idiomatic changes

<janneke>jpoiret: sure, great

<jpoiret>also, as a general rule you shouldn't use (system-hurd?) if you're not in a thunked context, otherwise you'll probably run into trouble if you do `guix build --system=...`

<janneke>that yields another result with --system than with a native build, i suspect?

<jpoiret>yes

<jpoiret>notably %default-locale-libcs's value would be different whether you're using --system or are actually on the native system

<jpoiret>doesn't mesh well with offload

<janneke>jpoiret: right, so %default-locale-libcs needs to be thunked

<nutcase[m]>jpoiret: I don't know, if you remember my question yesterday / care / mind: I got screen sharing working in chromium (single tab/window/screen) but not in firefox.

<janneke>ACTION didn't dare to make such a change :)

<yarl>Another dumb question : what is ^L in source files? I use emacs.

<yarl>(If that matters)

<janneke>jpoiret: please also (feel free to) reset the hurd-team branch, even with an intermediate result

<ChocolettePalett>yari: it's "page break" special character

<ChocolettePalett>To divide source file in "pages", and in GNU/Emacs you can, as far as I remember, navigate using these characters somehow

<ChocolettePalett>Here is some more accurate information:

<ChocolettePalett> https://www.emacswiki.org/emacs/PageBreaks

<janneke>yarl: see also <https://www.gnu.org/prep/standards/html_node/Formatting.html>, bottom of page

<yarl>Thanks.

<jpoiret>nutcase[m]: ah right, I saw your message before going to sleep

<jpoiret>let me have a look

<jpoiret>nutcase[m]: I have this in my config https://paste.debian.net/1285310/

<jpoiret>(that's an org-mode block that gets tangled to ~/.config/xdg-desktop-portal-wlr/sway, so you want the contents of the #+begin_src #+end_src block)

<jpoiret>if you haven't used the xdp system before then you might need to ensure that XDG_CURRENT_DESKTOP is correctly set

<jpoiret>(thats what xdp uses to determine what portal implementation to start)

<jpoiret>janneke: should i squash the revision of rumpkernel to 1?

<janneke>jpoiret: yeah, or 0 even :)

<jpoiret>is 0-indexed the usual?

<janneke>(jpoiret: unless maybe would be the *only* change that would trigger a rebuild)

<janneke>but i guess you made other changes that trigger a hurd rebuild anyway

<janneke>jpoiret: i'm not positive that 0 is usual, but that's what i normally do ;)

<nckx>Why waste a good entire non-negative integer.

<janneke>my thoughts exactly, athough

<janneke>ACTION has unsuccessfully tried to convince a mathematician of that ;)

<janneke>more than one, actually...

<nckx>Someone recently tried to convince me that ‘counting words’ don't include 0, because 0 isn't an amount. Like, have you never had 5 apples and then proceded to eat 5 apples, friend.

<nckx>This person was American though, so that probably played a role.

<nckx>ACTION wanders back off into the woods.

<janneke>'t would be an interesting world where you could never have less than 1 of anything

<jpoiret>I think it's mostly the connotation that 0 represents nothing that makes it annoying when numbering stuff

<jpoiret>you say first, not zeroth

<janneke>sure, 0 is the first number :)

<jpoiret>it is, but then having something numbered zero when you have one of them might prove less intuitive

<jpoiret>ah, I guess there's been arguments for either sides for a long time now

<jpoiret>in other news, yes i've modified the patches that we apply to glibc so that'll be a world rebuild

<janneke>hehe, good

<jpoiret>mostly changing the associated messages and indicating upstream location

<janneke>ACTION votes for CI on that though

<jpoiret>also removing a linux-specific patch that I adapted for 2.37 for no reason 🙄

<jpoiret>i'll try to build an image locally first and boot it

<janneke>OK

<janneke>right, i guess we'll probabbly have a glibc/hurd for quite some time to come

<janneke>if we want to keep up with upstream

<jpoiret>yes, and I don't think that's a bad idea

<jpoiret>it also opens up the possibility of carrying other libcs

<jpoiret>(looking at the "why no BSD" people that pop in here all the time)

<janneke>indeed, one could just say: until now no-one cared to create a patch, see glibc/hurd

<jpoiret>do we need netdde.static?

<janneke>i don't know, let me check

<jpoiret>otherwise i'm in favor of removing it

<anemofilia>does anyone here uses zile-on-guile?

<anemofilia>I installed it and would like to give it a try, but couldn't find any documentation

<anemofilia>And also couldn't find any configuration from other users

<janneke>jpoiret: my childhurd boots just fine after (re)moving netdde.static

<anemofilia>So I am feeling kinda lost

<janneke>i believe .static is only needed for servers used in grub modules

<jpoiret>i'll try removing it then

<janneke>anemofilia: i've used zile once or twice on a minimal system

<anemofilia>But normal zile or zile-on-guile?

<janneke>i guess it's mostly emacs except for unsupported features

<anemofilia>I would like to configure a text editor in guile

<anemofilia>janneke: Yeah, I imagine so too

<janneke>anemofilia: guile-emacs ;) ?

<anemofilia>Maybe I'll just try to read the implementation and discover things that way

<anemofilia>I tried guile-emacs

<janneke>jpoiret: sure, that's fine

<anemofilia>But it's kinda abandoned

<anemofilia>I really would like more to use guile-emacs than any other thing

<anemofilia>But it's sad

<janneke>well, it needs some serious love, that's for sure

<pjals>How do I add something (specifically the directory containing Python 2's "Python.h") to the C include path of a package?

<anemofilia>janneke: Yes

<anemofilia>I would be nice if it could get some visibility in any future GSoC, for example

<anemofilia>But I seriously doubt it can help

<anemofilia>(I said GSoC just because it really helps some projects in terms of resources, even guix, with the thing of parameterized packages, though I really dislike google and proprietary software in general, just to clarify)

<anemofilia>Anything capable of make guile-emacs active again would be welcome, IMO

<jpoiret>that was discussed recently on #guile and people close to the project said that guile-emacs shouldn't be too hard to update up to where emacs is now

<pjals>btw, does this bridge still work?

<anemofilia>jpoiret: Is that so? I asked about the project in #emacs and no one seemed too hopeful with that

<janneke>anemofilia: yeah, i wouldn't ask #emacs that question (just yet)

<HiltonChain[m]>pjals (trans rights): It's working, you can check the message logs here: <https://logs.guix.gnu.org/>

<pjals>(continuing from my question about include paths): or atleast how can i append to environment values at the configure and build phase?

<pjals>*variables

<janneke>pjals: you can just add them to #:configure-flags and/or #:make-flags

<pjals>will that append?

<janneke>yes

<jpoiret>but I would assume that adding python to your input list should be enough

<janneke>jpoiret: netdde.static might be required for booting off nfs

<janneke>ACTION just thought to ask #hurd => https://logs.guix.gnu.org/hurd/2023-07-08.log#172059

<janneke>and i seem to remember rekado adding the netdde package just for that...

<janneke>although "we" never spent the effort to use netdde at that time

<Kolev>Just installed on a Lenovo computer. Stuck at GRUB.

<janneke>Kolev: what does that mean?

<Kolev>janneke: GRUB prompt.

<Guest7619>hello

<Kolev> https://share.csh.snikket.chat/upload/aqULFRoVpfYjT5CNJiA6KK0t/zb2rhWq94zzeQVVwKBiAZiTJwCL1Uvd5XAGTHXAB6pukLoShx.jpg

<Kolev>Error during installation.

<Guest28>Never had it at install time but sometimes upon upgrading. Just retry should be no problem

<Guest28> https://guix.gnu.org/manual/en/html_node/Version-Control-Services.html#index-repositories can someone show me how that list would look like? I don't really understand it

<Guest28>also I noticed that https://guix.gnu.org/manual/en/html_node/Web-Services.html doesn't have the option to pin anything like I did with the link above

<pjals>Is there any way to make Guix not delete the /tmp/guix-build-...drv-0/?

<pjals>+folder

<HiltonChain[m]>Guest28: Maybe looking through the source directly? <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/cgit.scm#n320>

<HiltonChain[m]>Default values are defined there, you can map them to this:

<HiltonChain[m]>(cgit-configuration (package cgit) (nginx (list %cgit-configuration-nginx)) ...)

<HiltonChain[m]>pjals (trans rights): guix build --keep-failed

<Guest28>pjals: -K flag as of guix build -K, though is only if failed

<pjals>ah, thanks

<pjals>should have looked at the docs more!

<Guest28>HiltonChain[m] I do, still hard for me to understand. Still a beginner in Scheme and this is more for advanced people

<pjals>i think its more that the way guix defines nginx/web stuff is a bit complicated

<pjals>though, good luck making it better without reinventing emacs!

<nckx>Kolev: That's ‘just’ a networking error and is (ugh) ‘solved’ by simply running the same ‘guix system init’ command again. I hope the ‘graphical’ installer supports doing so.

<Guest28> https://paste.debian.net/1285331/ that is my current syntax but it returns https://paste.debian.net/1285332/

<Guest28>(nice web design on handling long lines)

<HiltonChain[m]>How about (list (repository-cgit-configuration ...)) ?

<HiltonChain[m]>change the value of repository field to ^

<HiltonChain[m]>repositories*

<Guest28>Ah nice, it works. Thank you very much

<nckx>I can't even parse what ‘[a] list of “cgit-repo” records to use with config’ is trying to say.

<pjals>it is a (list) of (repository-cgit-configuration)s to use with the (cgit-configuration)

<pjals>By the way, has anyone packaged cwiid for Guix?

<pjals>I got it to configure and build but it seemingly fails at the linking phase, with ld: /gnu/store/qz5knhmckxyss8ybgqv7wagc4402qsn7-bluez-5.66/lib/libbluetooth.so.3: error adding symbols: DSO missing from command line, and I'm really not sure if this is a Guix quirk or not, it seems like a lack of use of pkg-config.

<nckx>pjals: That's what I think.

<nckx>Who knows.

<nckx>If it's wrong, bother me.

<lfam>Howdy

<nckx>🤠/

<pjals>I got cwiid to build and link and all that cool stuff! But it seems like it fails at vaildate-runpath: `/gnu/store/mc1ma0cgbv321v7ak1z5fyi23qgjfl0z-cwiid-fadf11e/bin/wminput: error: depends on 'libcwiid.so.1', which cannot be found in RUNPATH ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" "/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib" "/gnu/store/qz5knhmckxyss8ybgqv7wagc4402qsn7-bluez-5.66/lib"

<pjals>"/gnu/store/4hym7qzn43kiqszyvjy6z519s1jkdxi8-python2-2.7.18/lib" "/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../..")`. `libcwiid.so.1` indeed exists in the /lib directory of cwiid, so I'm not sure why it errors.

<pjals>Sorry for yte long message.

<pjals>*the, how did i typo that bad?!

<nckx>I don't see cwiid's /lib in that list.

<nckx>You'll probably need something like "LDFLAGS=-Wl,-rpath=" #$output "/lib".

<pjals>Well, why isn't it in th- oh, thanks! I'll try that then

<pjals>(though, where am i supposed to put that? configure flags? make flags? modify-phases?)

<nckx>Heh. "🤷". But often configure-flags on autotools packages, make-flags on Makefile-only build systems, and then things like CMake have their own options.

<nckx>Which can be CMAKE_anything.

<nckx>Often CMAKE_INSTALL_RPATH, I think.

<pjals>Ok, this is a autotools project so I'll try that

<pjals>Shouldn't I use LDFLAGS+=... instead of =?

<nckx>I doubt that'll work.

<lilyp>at least with autotools clever engineering is used to expand both, so += isn't needed

<nckx>I love clever engineering.

<nutcase[m]>jpoiret: thank you for that snippet. Although I'm not using dmenu / bemenu, it's nice to know that there is a way to configure xdp-wlr. What I have in my sway config is an `exec dbus-update-activation-environment --all` similarly to what is described in xdp-wlr's README.md

<jpoiret>right, but depending on your DE XDG_CURRENT_DESKTOP might not be set at all

<jpoiret>so you have to make sure that is also the case

<jpoiret>and even if you're not using dmenu / bemenu, I think you *need* a chooser

<nckx>Here it's set, but empty, so I guess that's an option too.

<janneke>jpoiret: you've seen my netdde.static remark, right?

<Guest28>On ARM architecture cat /proc/cpuinfo only returns mips, how would I get the current clock rate?

<vagrantc>lscpu, maybe?

<sneek>Welcome back vagrantc, you have 1 message!

<sneek>vagrantc, efraim says: I'm taking care of some of the 'missing derivation' derivations from the opensbi evaluation, they're building nicely finally

<vagrantc>efraim: thanks!

<vagrantc>heh. sneek's messages are kind of like a time machine ... i can guess approximately when that message was sent ... but onyl very approximately :)

<vagrantc>sneek: botsnack

<sneek>:)

<nckx>Guest28: cpupower like on x86?

<nckx>(Package.)

<nckx>lscpu just returns the nominal rate, not the actual, AFAIK.

<Guest28>nope, I don't know why it is not showing it.

<Guest28>Apparently it is this https://www.arm.com/products/silicon-ip-cpu/neoverse/neoverse-n1, some cloud server and I always wondered on what clock rate they run

<nckx>Does /sys/devices/system/cpu/cpufreq exist?

<nckx>Or /sys/devices/system/cpu/*/cpufreq

<Guest28>yes, empty dir

<Guest28>guess they have something to hide, if it requires that much effort

<nckx>Joy.

<nckx>Or our kernel is missing some setting :)

<Guest28>Ah, no it runs some complete different kind of Linux

<vagrantc>nckx: i've seen lscpu getting more fancy over time

<vagrantc>but sure, cpupower

<Guest28>okay got it with lshw. it is 2ghz

<nckx>vagrantc: So've I, but I haven't seen it report *current* frequency anywhere (yet).

<Guest28>4 cores at 2ghz, my pi has 4 as well at 1,5ghz. pi takes 5 hrs to compile kernel, that cloud machine 30 mins

<nckx>Min, max, on-the-tin sort of numbers.

<vagrantc>nckx: CPU(s) scaling MHz: 28% ?

<nckx>Nice. Which CPU?

<vagrantc>requires doing some ostensibly simple math

<vagrantc>so picky.

<nckx> https://paste.debian.net/plainh/a2fb075b is all it's ever done for me >:(

<nckx>Ah, lscpu -eMHZ.

<nckx>Sans the ., that is.

<nckx>TIL vagrantc.

<nckx>What's your bitcoin wallet password.

<vagrantc>"i use a very strong passphrase, nckx"

<nckx>Same as mine, cool.

<vagrantc>-eMHZ rolls right off the fingers

<Guest28>does it show the current clock rate for you?

<vagrantc>"lscpu -eMHZ" shows me some MHZ for each individual cpu

<nckx>Guest28: Yes. But this is all x86. I don't have easy access to an ARM. Does it not for you?

<Guest28>Nope, guess ARM isn't that much supported for those cmds

<Guest28>but I get min and max