IRC channel logs

2022-08-11.log

back to list of logs

<acrow>vagrantc: you whippersnappers always have to use the shiny tools.
<acrow>vagrantc: k, I'll get that going...
<vagrantc>acrow: i used RCS ... 22 years ago. briefly.
<acrow>vagrantc: it's a package in both debian and guix!
<vagrantc>acrow: and numerous distros which no longer exist, except as artifacts of history!
<atka>what age range constitutes whippersnapperism? or is it just anyone younger than the accuser?
<atka>:)
<vagrantc>rekado, cbaines: what kernel are y'all using on the honeycomb lx2 boards you have set up for guix? is it in guix master?
<vagrantc>rekado, cbaines: and notably, can you get the on-board ethernet working?
*vagrantc suspects timezones may be interfering
<vagrantc>oh, i bet this is in some git repository exactly how these machines are configured...
<pkill9>is there a guix package transformation for just adding inputs rather than replacing them? I thought there was
<rekado>vagrantc: I use this kernel: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/honeycomb.scm#n136
<sneek>Welcome back rekado, you have 3 messages!
<sneek>rekado, antipode says: did you ever figure out what "configure: error: cannot run C compiled programs." meant
<sneek>rekado, antipode says: Nevermind, copied the wrong thing.
<sneek>rekado, antipode says: For git-version updating there's already a patch, see my response to ‘bug#39885: Bioconductor URI, fallback and time-machine’
<vagrantc>yay, debian's guix 1.3.0 package isn't borked on arm64/aarch64 after all... but the 1.2.0 version seems maybe ... but might be a pull to version X kind of problem
<vagrantc>rekado: thanks!
<vagrantc>rekado: i'm guessing those options were missing from the default linux-libre, then ... or did you need them as built-ins
<rekado>vagrantc: I copied some of these settings from the recommendations somewhere; at the time I had no other working kernel.
<rekado>there’s probably a simpler configuration now that works.
<rekado>back then I also had to use a more recent kernel than the ones we already had definitions for; since I had to build a new kernel anyway I decided to pick the recommended options.
<vagrantc>ok ... that's a useful list to have ... i might try building for the honeycomb now
<pkill9>why is guix building this giving me source expression failed to match any pattern? http://paste.debian.net/plain/1249963
<rekado>pkill9: you’re using “package” but it should be “original-package”
<rekado>in home-page, synopsis, description, and license
<pkill9>ahhhh thanks
<pkill9>i should probably not be coding while fatigued
<cbaines>vagrantc, it's tweaked a bit, the configuration is in git https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/hatysa.scm
<cbaines>vagrantc, but yeah, the on-board ethernet works
<Cairn>Anyone know of a Hydroxide (protonmail bridge) package from anyone's channels?
<vagrantc>cbaines: looks like a copy-pasted version of linux-libre-arm64-generic ?
<cbaines>vagrantc, yeah, there were some additional modules needed to get storage working
<cbaines>but this was quite a while ago, back when I set the machine up originally
<vagrantc>cbaines: any compelling reason to not just merge them into guix/master ?
<cbaines>not from me, I just haven't got around to it
<cbaines>next on my list of things to do is replace the SSD in hatysa, as I think it's worn out
<vagrantc>fair :)
<atka>vagrantc: you have your solar setup permanently installed?
<vagrantc>atka: nothing is permanent
<Spawns_Carpeting>hello
<atka>vagrantc: not speaking philosophically, just curious if you had panels just laying out or if you had them powering something on a continual basis
<atka>I checked out those slides from your talk, curious if it has changed much
<vagrantc>atka: ah, bolted them on sturdy gate-hinges under the eaves, so ... they're slightly less janky :)
<Spawns_Carpeting>does guix support building stuff from source with customized compile time feature flags like gentoo?
<Spawns_Carpeting>(in an automated way)
<yuu[m]>Spawns_Carpeting: no. basically same state as nix. https://lists.gnu.org/archive/html/help-guix/2019-02/msg00235.html
<yuu[m]>no eclipse IDE on Guix?
<vagrantc>is there not even loopback networking inside the build environment that guix-daemon creates?
<ulfvonbe`>loopback should exist
<Spawns_Carpeting>so it seems like neither guix nor nix can really fill the gentoo niche if USE flags are a little bit important to the user
<Spawns_Carpeting>i really like scheme and the ideas behind guix but I also really like being able to customize use flags!
<vagrantc>there was some relatively new feature ... tuning or something
<vagrantc>but packages need to have support for it, i think...
<vagrantc>Spawns_Carpeting: documented here: https://guix.gnu.org/en/manual/devel/en/guix.html#Package-Transformation-Options
<vagrantc>but that only covers cpu-specific features on individual packages that are marked tunable
<Spawns_Carpeting>thank you for the info!
<acrow>Shamelessly plugging for a commit of https://issues.guix.gnu.org/32947#29 it is an oldie but a goodie and on the path to get ditaa!
<jts>hey y'all. is there a standard way to deal with build-time tests that create files eg in the home directory besides skipping them?
<iyzsong>jts: you can call (setenv "HOME" (getcwd)) (or set to "/tmp/" or (getenv "TMPDIR"), i see both usages), to get a writable HOME.
<jts>awesome, thanks!
***daviid` is now known as daviid
***daviid is now known as Guest8421
***daviid` is now known as daviid
<klm>how can I produce file-like object with its content inline? I want to put the ssh key directly inside (authorized-keys ...) and not use a file.
<unmatched-paren>klm: (plain-file "...")
<iyzsong>iirc, it's text-file*
<unmatched-paren>text-file* also accepts gexps, plain-file doesn't
<unmatched-paren>(iirc)
<iyzsong>um, mixed-text-file, text-file* will return a monadic value.
<unmatched-paren>and text-file* seems to be equivalent to mixed-text-file
<unmatched-paren>i don't know why they both exist :)
<iyzsong>i just anwser that :)
<klm>but they all need a filename which doesn't really make sense: i just want to put the content inside authorized_keys
<unmatched-paren>klm: The filename is the filename *inside the store*
<klm>so I have to name it something?
<unmatched-paren>the text will be dropped into /gnu/store/<HASH>-<NAME>
<unmatched-paren>yes
<klm>i see. that feels a bit overkill for this, no? I wonder why it's designed that way.
<klm>so this is the case for everthing file-like, am I right? it all goes via /gnu/store/?
<unmatched-paren>yeah
<unmatched-paren>e.g. a computed-file creates a script in the store which itself creates another file in the store, iiuc
<unmatched-paren>an origin is another kind of file-like
<unmatched-paren>it fetches the file or directory from the internet
<unmatched-paren>and drops it in the store
<unmatched-paren>and you can ungexp a file-like inside a gexp to refer to its path
<klm>I see, thanks. This doesn't feel right for my use-case, I'll need to get more familiar with how guix works
<klm>unmatched-paren: I printed your "Code Staging in GNU Guix" but I haven't read it yet - looking forward to! All this will probably get clearer once I get around to that.
<unmatched-paren>klm: It's not mine :)
<unmatched-paren>It was written by ludo
<unmatched-paren>and others, i think
<klm>sorry, I meant your suggestion
<unmatched-paren>i see :)
<Lumine>Good morning!
<pkill9>why does the (wrap-program) function not produce a guile script instead of a bash script?
<unmatched-paren>pkill9: I suppose guile would be overkill. It only needs to set environment variables.
<unmatched-paren>Lumine: Hello.
<iyzsong>Lumine: Good morning! though i'm waiting my daily corp work to be finished in 20mins :o
<Lumine>Coffee is the word, not bird
<Lumine>:)
<sektor[m]>Morning.
<pkill9>it seems that (substitute*) butchers certain foreign characters
<unmatched-paren>pkill9: likely a bug in Guile's regex then
<pkill9>i don't think it's the regex, I think it's whatever it does to write the file
<pkill9>tghey're characters that don't match thepattern, like russian characters
<pkill9>adn they turn into qestion marks
<unmatched-paren>ah
<fnstudio>hola, building of texlive-font-maps seems to be failing - i suppose this is a known issue?
<abrenon>hello guix
<fnstudio>i get a 'ERROR: In procedure copy-file: In procedure copy-file: Permission denied' error
<unmatched-paren>abrenon: hello
<unmatched-paren>fnstudio: https://issues.guix.gnu.org/55280 <- apparently
<fnstudio>unmatched-paren: super, thanks, yes, it must be that!!
<pkill9>can anyone tell why wrap-program is failing to produce bash store path int his script, even though I've added bash as an input? http://paste.debian.net/plain/1250005
<unmatched-paren>pkill9: i don't know about your original question, but you can use (this-package-input #$name) instead of labels and assoc-ref build-inputs
<unmatched-paren>also, you probably shouldn't unquote "test"
<unmatched-paren>actually, you don't even need that this-package-input
<unmatched-paren>you can just do #$original-package
<unmatched-paren>you don't need the bash input for wrap-program
<pkill9>I can't use that because I'm makinga wrapper script that takes any package
<pkill9>well it produces #f as the store path for bash
<unmatched-paren>pkill9: Why can't you ungexp the parameter?
<pkill9>I meant to the first thign you said
<unmatched-paren>the this-package-input thing?
<unmatched-paren>you can replace that this-package-input with just #$original-package
<unmatched-paren>pkill9: why do you copy everything to the new path, instead of just writing scripts to $out/bin that call the original package's binaries?
<pkill9>yes, i just read that part of what you said *after* I posted that message
<unmatched-paren>i don't think you actually need wrap-program
<pkill9>so all the other stuff goes intot he profile
<pkill9>so what do i use instead?
<unmatched-paren>ah, i understand
<unmatched-paren>never mind then
<unmatched-paren>yeah, i just remembered that part of the conversation from yesterday :)
<unmatched-paren>could you show the error message you get when trying to build this package?
<unmatched-paren>I think it might actually be more straightforward for you to try containerization
<pkill9>it doesn't show an error
<pkill9>the wrapper shebang just has #f
<unmatched-paren>that is weird
<unciv>hi all :)
<unciv>I seem to have successfully built a .drv in /gnu/store , but it isn't available in my packages list
<unciv>is there anyway to output it to a package or a pack , rather than a .drv ?
<unciv>sorry, looks like I misunderstood, I used build instead of package
<abrenon>build simply gets the software ready in the store, yes, but without adding it to any environment
<abrenon>(hi unciv btw)
<klm>I'm getting the error `file name component is not a directory "/home/klm/.ssh"` because my ~/.ssh is a symlink to ~/.config/ssh. I think it's because of this line: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/activation.scm?id=5c131aff691fa1cb0fafe71b5f2795902ae056a7#n103anPerhaps
<klm>Sorry, premature "C-j". I'm getting the error `file name component is not a directory "/home/klm/.ssh"` because my ~/.ssh is a symlink to ~/.config/ssh. I think it's because of this line: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/activation.scm?id=5c131aff691fa1cb0fafe71b5f2795902ae056a7#n103 Why is there such a check, why isn't .ssh symlinks allowed?
<unciv>thanks abrenon
<unciv>so I used pacakge -f, and it worked, but I can't start a new shell with it
<unciv>how can I register the package so it gets picked up ?
<abrenon>unciv: there must be something weird with your profile, packages are supposed to be available as soon as they are installed
<abrenon>without even having to open a new shell
<abrenon>what about guix shell ?
<abrenon>is your program available in the new shell open by guix shell (same syntax as package, "-f myPkg.scm", but creates a transient environment where the package is installed)
<abrenon>guix shell also provides the --check option, that performs simple checks on the environment variables
<abrenon>are you using guix from the guix system or another distro ?
<pkill9>so looking at screenfetch package it just manually replaces #!#F with the correct shebang
<unciv>odoo 15 out /gnu/store/da5pqgllqyfzsq2vahi3ylsp53wzy6sr-odoo-15
<unciv>postgresql 14.4 out /gnu/store/ajywl056wwai0bybh3p7yxynnv9s73nx-postgresql-14.4
<unciv>
<unciv>so it seems to be in the listed packages
<unciv>$ guix shell odoo
<unciv>hint: Consider passing the `--check' option once to make sure your shell does not clobber environment variables.
<unciv>
<unciv>guix shell: error: odoo: unknown package
<unciv>
<unciv>$ guix shell postgresql
<unciv>hint: Consider passing the `--check' option once to make sure your shell does not clobber environment variables.
<unciv>
<unciv>The following derivation will be built:
<unciv> /gnu/store/yqmfz4qqp2a82m351sc3a1s1rqz56qmr-profile.drv
<unciv>
<unciv>but it doesn't seem to pick it up when I do that
<abrenon>ahhhhh that's so slow, please consider using a paste service : )
<unciv>oh, I'm sorry :)
<abrenon>lots of people do it the first time they share logs : )
<abrenon>I've just opened a shell with postgresql
<abrenon>and I do have psql in the environment at once
<unciv>yes, so it works for me with the actual guix packages, but not the one that I built
<unciv>but I can run it from my normal guix profile
<abrenon>oohhh so odoo is something you're developing ?
<unciv>well, it's something that I use, but there was no guix package for it
<abrenon>maybe there's something in your package definition preventing it from working properly
<abrenon>oh, so you're packaging it
<abrenon>great !
<unciv>so now I have built one and it does work, but I'm struggling to understand how I can use it
<abrenon>(then you'll be able to contribute it to guix core packages !)
<abrenon>what do you mean it "does work" ? have you inspected the resulting the gnu/store/…/ folder ?
<unciv>what I planned to do was use it in a guix shell, and then also pack it to a docker image
<abrenon>you can look at the $GUIX_ENVIRONMENT variable when you're inside a transient shell
<abrenon>yeah, that's a good idea
<unciv>so the binary is linked like this now : ~/.guix-profile/bin/odoo
<unciv>and if I run it from my normal terminal it runs as expected
<abrenon>which is properly in your $PATH ?
<unciv>but if I start a shell it doesn't get picked up
<abrenon>with --pure ?
<unciv>also if I start an empty shell it gets picked up
<unciv>oh interesting
<unciv>if I do a --pure it doesn't get picked up when I do a which
<abrenon>that's expected
<abrenon>so I don't really understand in what context it gets hidden ?
<abrenon>when you start a shell to add a different program, without --pure ?
<unciv>so, if I do a guix shell odoo - it says unknown package
<abrenon>yeah of course
<unciv>does it have to be registered somewhere ?
<abrenon>if you haven't added yet to a channel your guix program knows about
<abrenon>yes : )
<abrenon>if you want to be able to write that directly
<abrenon>but you really don't need to
<unciv>ohhh.
<unciv>thanks :
<abrenon>while you're working on it
<unciv>:)
<unciv>ok, I get it.
<abrenon>like I said, just like guix package, you can use the -f option
<abrenon>guix shell -f odoo.scm
<abrenon>if you put the definition for odoo in a file named odoo.scm in the current directory
<unciv>ok, so I can just start a guix shell with postgresql, and then add a packae inside with -f to my .scm ?
<abrenon>you can start a shell with both of them at once
<abrenon>guix shell postgresql -f myFile.scm
<abrenon>you can add as many local packages you want with as many -f options
<abrenon>I'm working on something with 3 local packages I mean to contribute one day
<unciv>I wonder why odoo isn't contributed yet, it's AGPL3 ...
<abrenon>I'm opening work shells like so: guix shell -f ../dep1/guix.scm -f ../dep2/guix.scm ../dep3/guix.scm python python-lxml
<abrenon>actually, at this level of complexity I'd be better off with a manifest, but it might be for the next lesson ; )
<abrenon>I dunno but I had never heard of it, I don't even know what it's supposed to do
<abrenon>sometimes the reason can be just "no one has done it yet and you'll be the first"
<unciv>There was a guy on a mailing list that tried with odoo 10 in 2016, but he failed because he didn't provide the right python packages as inputs
<unciv>So I modified his scm file and got it to work with odoo 15
<abrenon>good job
<abrenon>maybe he just needd a little push, maybe he lacked the time
<abrenon>in any case, good that his first attempt wasn't lost
<unciv>I hoped that we could use guix to deploy and build docker images and work locally with environments
<unciv>yeh, it was good... I wonder if he eventually figured it out
<unciv>the post was way before I heard of guix
<unciv>so, are you using guix as a distribution ?
<abrenon>yes !
<abrenon>this is my main system, installed on my work and personal laptops
<unciv>wow, that's pretty cool
<unciv>I've tried it in a VM
<unciv>but I'm using Pop OS
<unciv>but I still like the idea of guix, so I use it for a lot of packages
<unciv>I just found it a bit difficult to understand what was going on when I installed it in the VM, it didn't seem to obey my emacs config changes
<abrenon>oh, that's too bad
<abrenon>I think it's supposed to work rather well with emacs though because pretty much everyone in the community is using it
<abrenon>so I doubt a serious problem could remain very long
<unciv>I'm getting a new laptop soon and I'm going to try on it as well.
<unciv>so I installed exwm and got a pretty blank emacs config
<abrenon>alas, I am myself a vim sinner, so I cannot be of much help
<unciv>then I tride to drop into a terminal and install emacs-guix
<unciv>so it installed it, but it didn't show up in my installed packages, and with the built in packages commands it listed packages, but didn't install them with the guix packages
<unciv>so I just don't really understand if it was supposed to be using the guix packages or just loading emacs packages with package.el
<unciv>but it'd be cool to get it running
<unciv>lol :) vim is cool. I also use it and also use evil mode which emulates vim in emacs
<abrenon>I'm pretty sure you'll be able to get some help about that emacs issue if you hang around
<abrenon>I'm pretty sure there's a "right" way of assembling your emacs environment with everything properly configured
<abrenon>personally, I'd have tried to put emacs-guix and emacs in the same environment, instead of "in addition", in a shell spawned by the emacs executable itself
<unciv>well, thanks again for your advice ... it seems to work mostly the way you have said
<abrenon>sorry if there are still details to tweak
<unciv>I just can't pass -f into the shell command, but once I have a shell I can add the package with the path and -f
<abrenon>but I'm happy it works
<abrenon>in any case, I'll be AFK for a while, but good luck playing with guix
<unciv>thanks :)
<nckx>Hi Guix. I've reinstalled my system and now get ‘Unable to activate package ‘use-package’. | Required package ‘bind-key-2.4’ is unavailable’ (only context implies the two are related). What's up with that?
<pkill9>why does `guix --version` no longer show the git commit it is on?
<PotentialUser-26>Is there a way to see which config is used to produce a certain image on CI?
<pkill9>so ive created a package within home.scm but when I append it to my packages list and reconfigure home, it doesn't install, and when I display the output of the packages list, all the vanilla packages have "out" at the end but not my created package
<pkill9>what could be the issue here?
<pkill9>i can build it and install it with `guix package -f`
<nckx>pkill9: Because bug.
<nckx>(The 0 thing.)
<orneb>nckx: I tried what you and unmatched-paren suggested yesterday but didn't work. Libreoffice is still missing the menu bar. I added exec dbus-daemon--session --address=unix:path=$XDG_RUNTIME_DIR/bu\s in my sway config file and dbus-service in my desktop.scm but didn't work.
<nckx>Boo.
<nckx>The latter is Greek to me.
<nckx>Sorry, former.
<nckx>dbus-service, that I do have.
<unmatched-paren>i can't remember where i got that incantation from
<unmatched-paren>but i did it to fix sway crashing on startup because XDG_RUNTIME_DIR didn't exist, iirc
<unmatched-paren>no, wait
<unmatched-paren>hmm
<nckx>So what I wonder then is: does 'guix shell --pure libreoffice dbus -- soffice' show the menu bar for you?
<nckx>unmatched-paren: I don't have any such thing, but I'm sure you have your reasons. I recognise trauma-based snippets when I see them. We've all been there.
<unmatched-paren>Hmm, I do have XDG_CURRENT_DESKTOP set in my fish config
<unmatched-paren>i don't know what i was trying to fix with that though
<unmatched-paren>or whether i was even trying to fix anything :)
***sneek_ is now known as sneek
<nckx>orneb: That question above was for you. I have menu bars in that environment. If you don't, its purity is a lie.
<nckx>Which it is, but hush.
<nckx>I'd try a container but can't.
<orneb>nckx: I can only try later, sorry. I'll let you know.
<unmatched-paren>where's and=> from? I can't remember which SRFI provides it
<nckx>You sure it's a SRFI?
<unmatched-paren>uh, not entirely :) might be ice-9
<unmatched-paren>and-let* provides something better, so -.o.-
<nckx>Ice-9 sounds more plausible yes.
<nckx>orneb: Thanks!
<otfrom-lurking>morning
<unmatched-paren>otfrom-lurking: hello
<nckx>(You failed.)
<nckx>(Hi.)
<nckx>(We can talk like this and nobody will hear us.)
<abrenon>(wow it works I haven't heard a thing)
<nckx>I accidentally -j $(nproc) and now my laptop's been unresponsive for 15 minutes. I don't know how others with 4G of RAM do it.
<abrenon>(this trick is neat)
<nckx>(Who said that?)
<nckx>Yes, I have swap, and no, OOM would not be 'better'.
<abrenon>(laughs in evil — and anonymous — mode)
<nckx>'Is this the darknet'
<abrenon>🤣
<unmatched-paren>(communicating entirely in parentheses kinda makes sense for a community revolved around scheme)
<abrenon>you're one to talk…
<nckx>I don't think you're allowed to join in, sorry. You have a reputation for desyncing the protocol.
<nckx>Alice said it more succinctly.
<unmatched-paren>(aww....
<nckx>Grr.
<nckx>:) FTFY.
<abrenon>it's been so long since I haven't sent a patch, now I feel like I'll make a blunder
*nckx duckles 'sysrq oom' :-/
<nckx>abrenon: There really isn't much you can do wrong if you remember the bug number dance. And that's only for patch*es*.
<unmatched-paren>You can just send the `git format-patch --cover-letter` first, then you don't have to remember the bug number dance.
<abrenon>the cover-letter stuff is scary I have never done it
<abrenon>I usually send the mail myself
<abrenon>but I remembered the format-patch \o/
<unmatched-paren>I think all you have to do is `git format-patch --cover-letter <SPEC>`
<unmatched-paren>and use sendmail or whatever to send that
*abrenon is grepping through etc/teams.scm to find the appropriate person to target
<unmatched-paren>Uh, "target"?
<abrenon>: S
<abrenon>probably a bad choice of words
<abrenon>apologies
<unmatched-paren>:)
<abrenon>to send to ?
<unmatched-paren>Yeah.
<abrenon>in any case s/person/persons/
<unmatched-paren>"... people to send it to"
<nckx>s/target/'volunteer'/
<abrenon>thanks ! : D
<nckx>As in, you have been volunteered, resistance is futile.
<abrenon>I like the concept
<unmatched-paren>"target" sounds a little like you're aiming something at them. Which I guess is true :)
<abrenon>anyway, I haven't been much around when teams were formalised
<unmatched-paren>abrenon: English is weird, it's not your fault :)
<abrenon>are patches still supposed to be sent to the whole mailing list or to specific teams ?
<unmatched-paren>the entire mailing list
<abrenon>well I am aiming my mighty patch at them, so yeah
<abrenon>great, thanks
<nckx>I will probably regret this, but: 'target' wasn't wrong?
<abrenon>unmatched-paren: *I* am weird, it's not english's fault
<unmatched-paren>Eh, all of us in here probably qualify as "weird".
<abrenon>english' fault ?
<abrenon>the english language certainly isn't at fault here in any case
*nckx had to REISUB.
<unmatched-paren>nckx: What's "REISUB" an acronym for?
*abrenon had to duckduck it too
<abrenon>it sounds painful
<unmatched-paren>Oh, interesting.
<nckx>unmatched-paren: A series of 'magic sysrq' keys that will do stuff that you've probably already read by now.
<nckx>F didn't work, or at least my screen stayed blank.
<unmatched-paren>> Before the advent of journaled filesystems a common use of the magic SysRq key was to perform a safe reboot of a Linux computer which has otherwise locked up (abbr. REISUB), which avoided a risk of filesystem corruption. With modern filesystems, this practice is discouraged, offering no upsides over straight reBoot.
<nckx>Cunterpoint: bcachefs. I'm going to do all the precautionary stuff I can reasonably do.
<nckx>Ehhh. *Counterpoint :-/
*Lumine powers off by taking a sledgehammer on his computer
<unmatched-paren>REAL Linux users deliberately cause a kernel panic to stop their system.
<nckx>There's a sysrq app for that.
<nckx>But… I am actually going to reboot over cold because my backspace key is broken. WTF.
<Lumine>:C
<nckx>Phew, it's back. Having to listen to nckx without a backspace key is legally torture. But alas, working laptop means → work, byee.
<Lumine>Toodles, or something. o/
<abrenon>see ya !
<nckx>Thanks! Before I go, I'll just nudge this here: if anyone has any ideas about my original question (‘Unable to activate package ‘use-package’. | Required package ‘bind-key-2.4’ is unavailable’’), I'd be tickled pink by a ping. o/
<Lumine>This might be going out on a limb here since I'm a complete emacs noob but... M-x package-refresh-contents, nckx ?
<nckx>That prints things like ‘Contacting host: elpa.gnu.org:443’ so I'm not sure it's relevant to Guix-managed emacs, but thanks. I'm no emacs wizard myself, but I do miss ‘my’ emacs.
<nckx>I'm noticably less efficient.
<Lumine>Ah guix managed
<unmatched-paren>I don't use use-package :)
<unmatched-paren>I just (require) everything.
<nckx>I used to.
<nckx>I honestly don't know the one true way, if there is one.
<Lumine>I have yet to put emacs in my main PC's Guix, wondering what are the current best practises of doing things...
<nckx>I just put the cargo in the box and emacs comes out of the box and I use the emacs and all is good.
<nckx>*was
<nckx>:(
<unmatched-paren>Sounds like you've finally discovered a good use for Cargo.
<nckx>Lumine: Clearl, don't listen to me.
<nckx>unmatched-paren: Ding.
<nckx>*y
<Cairn>nckx: Are you using any :bind statements in any of your use-package expressions?
<nckx>What's weird is this .emacs, janky as it surely is, was just restored from a back-up that worked fine. Whatever's changed is due to guix packages being added or removed or moved around.
<nckx>Cairn: grep says no.
<Cairn>So I guess you could unrequire bind-key.
<unmatched-paren>is use of srfi-105 infix expressions allowed in the guix codebase?
<Lumine>Like, I want to have guix manage the emacs and exwm, but I found some hassles with the latter, but that might be because I can't for the life of me figure out how to make a .desktop file that is discoverable by guix
<unmatched-paren>because i think i'll use them next time i send a patch that needs an operator if they are
<nckx>unmatched-paren: Errr.
<nckx>‘Why.’
<nckx>Implicit ‘Dear god’ prefix etc. omitted.
<unmatched-paren>because {8 > 2} is infinitely better than (> 8 2) :)
<nckx>OK. Then the answer is no.
<unmatched-paren>sad, but okay
<nckx>Surprisingly to both of us, I'm not biting.
<Lumine>I know they reside in the store folder but as I understand, that is a no-no for manually adding things
<Lumine>So right now I just use xinitrc
<Lumine>What's odd is that when you add exwm to your main config, it shows up in GDM, but not when you add it via home
<Cairn>You're using xinitrc with GDM?
<Cairn>I had to switch to using .xsession when I started using GDM
<Lumine>I have xsession symlinked to xinitrc as a dumb solution, but yes
<Cairn>Fair enough
<Lumine>"There's gotta be a better way!" -Joey
<orneb>nckx: I reinstalled my system (Yesterday I messed it up with some kernel arguments and couldn't access the grub menu because I forgot to add (terminal-outputs '(console)) and with just dbus-service now libreoffice is showing the menu bar.
<orneb>Didn't know how chroot works with Guix.
<unmatched-paren>i've done a chroot recovery with guix before, it was a little involved though
<nckx> https://guix.gnu.org/en/manual/devel/en/html_node/Chrooting-into-an-existing-system.html#Chrooting-into-an-existing-system
<nckx>Missing? → bug reportz.
<phf-1>Hello! I've got Cuirass to work is a remote worker using these `operating-system` configurations : master: https://paste.debian.net/1250024/, worker: https://paste.debian.net/1250025/.
<phf-1>unfortunately, Cuirass seems unable to discover the remote worker with Avahi but the worker is taken into account by Cuirass when the parameter `(server "yyy.yyy.yyy.yyy:5555")` is added to `cuirass-remote-worker-service-type`.
<phf-1>So, given master: https://paste.debian.net/1250024/, worker: https://paste.debian.net/1250025/, what's wrong with Avahi's setup ?
<phf-1>I followed the best I could the documentations of Guix and Cuirass but, apparently, it's not enough.
<phf-1>I've got Cuirass to work *with a ...
<abcdw>nckx: Hi! Can you take a look at postmortem draft, please? https://cryptpad.fr/code/#/2/code/edit/-QpBZOTWCeVE4-NUOgAVbTtb/
<nckx>abcdw: ?
<abcdw>nckx: Wrote a summary on subkey authorization problem, which happened last weekends, want to publish it on guix-devel for future reference and also to discuss subkey authorization support. Would be glad if you take a brief look and let me know if I missed something.
<nckx>I thought I already did.
<nckx>Yes.
<faustx7>hi guix!
<nckx>I don't see a difference.
<nckx>My original comments are, of course, just that. You can take them or leave them.
<nckx>But it is unclear to me what more you want. Let me know, and I'll check back later.
<faustx7>i have custom service, i can check logs from this service?
<nckx>If you want me to rewrite it, I'll pass, just because I don't have a need to send another mail edited by me :)
<nckx>o/
<abcdw>nckx: Oh, probably it was cached and I missed your comment sorry, now I see them :)
<faustx7>may be any one knows how to check logs from custom service?
<nckx>abcdw: Ah :)
<nckx>Emphasis was on ‘by *me*’ in my last message by the way.
<nckx>faustx7: The Shepherd/Guix don't handle logging. Wherever your service logs, there it will be.
<nckx>If it doesn't log or logs to std{out,err}, you'll have to modify it to log to a file.
<abcdw>nckx: Addressed your and antipod's comments, published, thank you!)
<nckx>Thank you!
<faust45>nckx`i run kmonad as service and i want to handle it std... how i can do this?
<faust45>nckx: i run kmonad as service and i want to handle it std... how i can do this?
<podiki[m]>abcdw: remind me how the subkey issue was worked around after? was your subkey instead added to guix authorizations? (running into same problem in another channel)
<nckx>That's what I'm looking up faust45.
<nckx>faust45: https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n927 read the docstring.
<nckx>I just searched, I can't guarantee it will work. Good luck.
<nckx>podiki[m]: Yes.
<podiki[m]>nckx: hmm. so then the future problem is that typically(?) one will use subkeys that expire/get renewed more frequently than a primary key
<nckx>podiki[m]: Well, not actually! We haven't addressed it yet.
<nckx>That commit is gone :)
<podiki[m]>what does guix do for keys that expire in general? replace with renewed/new key before they expire and all is okay?
<nckx>podiki[m]: That is my point. https://issues.guix.gnu.org/57091#3
<nckx>I'm suprised that it's not universal, so please do chime in.
<faust45>nckx: thanks!
<podiki[m]>has guix not had to handle a commiter's key expiring?
<nckx>podiki[m]: Expiration isn't relevant or handled. Keys are valid forever.
<podiki[m]>yes, I've been watching that issue for this reason, I'll chime in there/guix-devel with what I do
<podiki[m]>ah
<nckx>Authorisations are added and ‘revoked’ (removed), instead.
<podiki[m]>I guess github/lab just do "standard" pgp since you always add your full public key, when my subkey expires I need to remove the pubkey and put it again (renewed)
<podiki[m]>gotcha
<nckx>podiki[m]: Subkey renewal isn't a problem (the key wouldn't change). It's indeed replacement and simply people who use different subkeys having to have each one added to the list, and not allowed to mint new ones without adding them later.
<podiki[m]>I just broke a certain other channel for the same reason, confusing of course since gitlab's handling of signing commits has nothing to do with guix pull's handling
<nckx>Yes.
<nckx>I'm glad to see someone echoing my points for a change :)
<podiki[m]>:)
<nckx>I find it dangerously different and currently do not understand the argument for that.
<nckx>Not saying there isn't one.
<nckx>But I don't see it.
<podiki[m]>apparently (having just looked into this) git signing will also tend to use the primary key over a subkey if both have signing ability
<podiki[m]>argument for always using primary key?
<abcdw>podiki[m]: Not addressed yet, will take a look at (guix athuorization) next week and hope will come up with a patch, which adds subkeys support.
<podiki[m]>I think the usage I saw and try to follow is only using subkeys (easier to revoke/renew) and the primary key is basically to just handle the subkey renew/revoke/etc
<podiki[m]>abcdw: thanks, will be watching and will add in my usage (and as one hoping to join the committers one day [soon?])
<nckx>podiki[m]: Both are valid.
<nckx>It doesn't really matter which is more likely to be chosen, the point is that it shouldn't matter.
<abcdw>podiki[m]: nice!)
<abcdw>Have a good evening everyone, see you in a bit!
<nckx>That was poorly edited. It shouldn't matter which one is chosen, so it's ‘irrelevant’ whichever is slightly more common.
<podiki[m]>yes, true
<nckx>I don't know why I'm having such trouble expressing a very simple thought :)
<podiki[m]>I understood
<nckx>That makes one of us.
<podiki[m]>while I'm at it, was anything else needed on other developers ends? meaning if they had just done a git pull with the offending commit, just a reset --hard back?
<apteryx>has anyone used 'vncviewer' from tigervnc-server successfullly on their tiling window manager?
<nckx>‘Just’ is a big word, but the only action we took so far was to hard-reset yes.
<nckx>The problem is that is is not something *anyone* on the Guix team can do.
<apteryx>it works in window mode, but doesn't for me in full screen, which is a pity because only fullscreen mode capture all keyboard keys.
<podiki[m]>nckx: okay, hence the "contact someone at savannah"
<nckx>podiki[m]: This can be framed as a extra security safeguard but I don't take that seriously either, since their are much less disruptive ways to compromise master. This wouldn't be a useful ‘attack’.
<nckx>podiki[m]: If you mentioned that I missed it.
<KarlJoad>Quick question for Cuirass admins here. How do you set up your email notifications? I'm looking at what is used for Guix's CI server and cannot figure out what the script is. https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/services.scm#n231
<nckx>apteryx: I use it very seldom on Sway.
<nckx>I open it, type my LUKS passphrase, then close it.
<podiki[m]>nckx: thanks for all the info. I was worried this was going to happen in the other channel and now I think I'm caught up on the useful details
<nckx>apteryx: It captures what needs to be captured in windowed mode, but of course it's quite the limited test case.
<nckx>WDYM by ‘all’?
<nckx>Fancy ones?
<nckx>I think I could switch VTs once…
<nckx>podiki[m]: Yep, you were right to be worried.
<podiki[m]>nckx: sometimes I hate being right 🙃
<podiki[m]>nckx: sorry, one more thing. the keyring publickey remained though right? just the master branch .guix-authorizations was the problem?
<nckx>Jebus. Can somebody who uses (use-package …) with Guix (and only Guix) emacs packages throw me their .emacs out of pity? I'm out of my depth.
<nckx>Unable to activate package `use-package'. Required package `bind-key-2.4' is unavailable — bind-key is *part* of bloody use-package.
<podiki[m]>i use use-package, but it just gets packages from elpa/melpa, not the guix packages if that's what you mean
<podiki[m]> https://github.com/podiki/dot.me/tree/master/emacs if it helps
<nckx>That is what I mean. I don't want to use {m,}elpa.
<nckx>But thanks!
<podiki[m]>you can force the load path to get the guix installed packages instead
<nckx>podiki[m]: Yes, the actual key data is fine, of course. There was never anything wrong with the GPG side, only with Guix.
<podiki[m]>in use-package declaration, e.g. :load-path "/path/to/share/emacs/site-lisp"
<podiki[m]>gotcha, keyring = gpg, authorizations = guix
<nckx>I think that's (sufficiently) accurate.
<gnucode>hello
<nckx>podiki[m]: <force the load path> True… but this can't be the right way…?
<ekaitz>hi all! how I'm supposed to add patches in my custom channels? I always end up with patch-not-found errors and I don't know how to do this properly
<podiki[m]>in conclusion guix != gpg
<nckx>I don't understand. This has to be a common use case.
<podiki[m]>I did the load-path since I mostly use (m)elpa currently, I did find some ways to handle this better, let me find it
*nckx → foodz.
<nckx>ekaitz: Root of the repo. gnu/packages/patches is special-cased for the guix channel. It's unexpected but how it is.
<podiki[m]>nckx: https://old.reddit.com/r/emacs/comments/jhb2i6/guix_the_right_way_to_manage_your_packages/g9y4cm5/ (and possibly the original post) for one (fancy) way, but basic idea is there
<ekaitz>nckx: thnks!
<podiki[m]>nckx: perhaps just making sure the guix emacs site-lisp is in the load path (I thought it should be automatically, but mine is not for some reason); then as long as ensure is nil for use-package (should be default) it should find the guix packages
<podiki[m]>nckx: perhaps also (guix-emacs-autoload-packages) ? maybe i'll tackle this later today as well :)
<apteryx>nckx: I mean like capturing Control, Alt, everything except its escape key (F8)
<apteryx>so that I could use ratpoison or emacs comfortably from it
<apteryx>if you put vncviewer fullscreen it does it, but this mode seems broken on ratpoison (doesn't display/refresh correctly -- seems to use the full monitor instead of the ratpoison frame)
<podiki[m]>perhaps a WM setting with what keys it handles? making an exception for fullscreen?
<raingloom>hey so jupyter notebook doesn't find mpmath, but jupyter-qtconsole does. any clue what's up with that?
<PotentialUser-6>Hey, I can't find my wifi device on guix.
<PotentialUser-6>I own a t400
<PotentialUser-6>I thought those would work without having to install a non-free package to detect the wifi
<raingloom>literally writing this from a T400, I can tell you wlan won't work without iwlwifi
<raingloom>you will need The Forbidden Channel, or use wired networking, or get a USB WiFi adapter that has libre firmware.
<gnucode>I also have a t400! we should have a fan club!
<raingloom>heck yeah, t400 party :)
<gnucode>raingloom or you can buy that one special wifi chip that is free software. But then you'd have to crack open the laptop and unscrew lots of stuff!
<PotentialUser-6>Whats the easiest and fastest option?
<gnucode>raingloom my battery is pretty much dead. My laptop has to be plugged in to run...I should probably buy another T400 for new battery. OR a reform....
<gnucode>PotentialUser-6: You want to buy a usb plug in for wifi. easiest and fastest.
<raingloom>PotentialUser-6: if you have a long ethernet cable, that's the fastest option. but if you go over to the #nonguix channel, I can walk you through setting up iwlwifi.
<gnucode>one moment, I will send you a link.
<PotentialUser-6>Haha yeah, I've seen multiple people that run guix on a t400. Must be because of the libreboot
<PotentialUser-6>I use an ethernet cable normally
<PotentialUser-6>But now I want to try using it while not at home
<gnucode>PotentialUser-6: https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-linux-tpe-n150usb
<PotentialUser-6>raingloom oh yes, that would be great. I'm also interested in the usb plug in, I guess that would make me avoid using non free stuff. But I need wifi fast though so for the moment the non free option is good
<PotentialUser-6>Sorry, can you repost it?
<PotentialUser-6>I left accidentally
<gnucode>Thinkpenguin is a really cool FOSS company. I believe they made are the reason that we have some open hardware wifi. it took them hand holding a company almost 4 years to open it.
<raingloom>yeah, if you need it right now, pop over to the #nonguix channel, i can help there
<gnucode>yeah just a moment.
<gnucode> https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-linux-tpe-n150usb
<PotentialUser-6>Thanks
<gnucode>sorry not open hardware...wifi hardware that runs entirely free software.
<PotentialUser-6>raingloom yes, im there
<PotentialUser-6>gnucode so the usb is not open, is that what youre saying?
<apteryx>gnucode: I use that one on a laptop, it's very reliable because the driver is in the kernel tree, but it's limited to 2.4 GHz.
<raingloom>solved the jupyter issue, it seems the first one i opened didn't exit, so when i restarted it in a new environment, it used a different port, but in my browser i just reloaded the tab, so it kept talking to the kernel i started first.
<raingloom>computers. :)
<faust45>one more question, how i can navigate guix code in emacs?
<faust45>eglot?
<unmatched-paren>faust45: There *is* a (very new) scheme-language-server
<unmatched-paren>though i think you might be able to navigate it with Geiser or something?
<faust45>unmatched-paren thanks, will check it out
<faust45>is it possible to setup custom xkb config in config.scm ?
<unmatched-paren>yes, probably
<unmatched-paren>The manual has a comprehensive list of system services :)
<faust45>unmatched-paren: can you point me please?
<faust45>i have checked it but coldnt find
<unmatched-paren>faust45: https://guix.gnu.org/manual/devel/en/html_node/Services.html#Services
***daviid`` is now known as daviid
<faust45>unmatched-paren: i just checked this docs, but still have no idea how to set custom xkb config )
<unmatched-paren>sorry, i'm not sure either
<apteryx>raingloom: please don't refer people to nonfree software in this space
*f1refly is sad that guix doesn't provide crystal but is also not good enough to attempt packaging it
<f1refly>:(
<unmatched-paren>f1refly: there is a crystal packaging effort
<unmatched-paren>it's going to take a long time, i think
<f1refly>i think the effort is on ice
<unmatched-paren> https://issues.guix.gnu.org/49158
<unmatched-paren>> There are 160 stages!
<f1refly>yeah I know and I couldn't even comprehend how to get the first one ^^'
<lilyp>only !
<f1refly>I think once the first one is done the others are more or less the same
<unmatched-paren>it's like the rust bootstrap but many times worse, i guess
<lilyp>Or it's like the scala bootstrap, but slightly better 🙃️
*unmatched-paren is scared to ask about the scala bootstrap
<f1refly>was the rust bootstrap that bad?
<vivien>Dear guix, I think I remember the time when there was an attempt at an NPM importer, but I can’t find anything related to it anymore. Did I invent it? Dit it exist at some point? Did it get removed?
<raingloom>apteryx: if someone needs network access *right now* i'm not gonna tell them to wait for a new usb wifi adapter. :)
<unmatched-paren>f1refly: i think it's been cut down a lot
<unmatched-paren>it's not insane, there's only a few packages now
<raingloom>i did redirect them to nonguix though, i was hoping that'd be good enough
<unmatched-paren>thanks to mutabah :)
<dthompson>vivien: it was attempted but never made it into guix officially
<vivien>Oh so that’s why
<dthompson>I was a google summer of code mentor for the person that did it.
<dthompson>this was years ago but the conclusion we came to was that nodejs is/was hopeless
<unmatched-paren>even for simply importing the packages?
<unmatched-paren>wow
<lilyp>Well, we already know nodejs is hopeless, but what's the broken part with importers?
<unmatched-paren>It's not even hopeless. Hopeless implies 0 hope. Node has negative hope.
<vivien>I think the python science packages use a lot of things on NPM, it is just bundled with the release tarball, no?
<dthompson>I don't remember all the details, the importer was a good start, but the packages themselves weren't anywhere near meeting the criteria for what guix could accept
<dthompson>if anyone wants to hunt down the old mailing list thread about it that would be much better than my very faded memory
<vivien>Like, jupyterlab-widgets
<unmatched-paren>i think rekado_ recently discovered bundled npm stuff in r-markdown, too
<dthompson>lots of wonderful discoveries to be found :)
<unmatched-paren>That's... one way to put it :)
<dthompson>if you don't look at it that way you might go insane
<dthompson>this is the kind of thing the upside down smiley face emoji was made for
<tissevert>glad to see I'm not the only one feeling that way about node : )
<vivien> https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00814.html :(
<tissevert>yeah, that is what happens when a "package manager" is reinvented for each language
<tissevert>instead of relying on some good stuff like guix
<yuu[m]>dthompson: don't guix has developed such a 2guix tools such as nix 2nix tools? lock files and fixed-output derivation sutff?
<unmatched-paren>yuu[m]: https://github.com/nix-community/dream2nix <- this?
<unmatched-paren>guix uses `guix import` for that
<dthompson>yuu[m]: I haveno clue. I don't know what 2nix is.
<unmatched-paren>but apparently nodejs is so hopeless it's even implausible to beat the packages into a slightly-sane form!
<dthompson>yeah we couldn't figure out how to untangle the dependency tree.
<unmatched-paren>ah
<yuu[m]>unmatched-paren: dthompson for node
<yuu[m]> https://github.com/tweag/npmlock2nix
<yuu[m]> https://github.com/svanderburg/node2nix
<dthompson>way back then I figured out how to get a ruby build system and ruby packages into guix
<dthompson>there were several issues of circular dependencies to work through there, too
<unmatched-paren> https://github.com/svanderburg/node2nix <- this doesn't look like an importer
<unmatched-paren>it looks like some tool for managing node projects^Wkludges with Nix
<dthompson>having solved them, I was feeling oh so confident that we could figure out whatever the node people wre doing
<dthompson>were*
<dthompson>but uhhhhh I guess you'd call that "hubris"
<unmatched-paren>node works in mysterious ways
<unmatched-paren> https://github.com/nix-community/npmlock2nix <- doesn't look like an importer either
<unmatched-paren>seems like it allows you to use package.jsons to spawn nix-shells
<vivien>If I were to badmouth the issue, I would say web application developers and all the devops crew call that "job security"
<dthompson>cwebber documented the state of things back in 2015 (I can't believe it's been that long already omg) https://dustycloud.org/blog/javascript-packaging-dystopia/
<unmatched-paren>it could only have gotten worse in 7 years
<vivien>There’s no way 2015 was 7 years ago
<vivien>Oh it is actually
<unmatched-paren>:)
<dthompson>when I looked into it, I also used jquery as a specimen since it was so prevalent at the time.
<unmatched-paren>ooh, this is possible in nix apparently! https://github.com/bennofs/nix-index
<unmatched-paren>we should have something like that in guix :)
*unmatched-paren adds to mental TODO list
<yuu[m]>unmatched-paren: it solves dependencies to create a nix package and such from a ndoe project. but all these from my experience create a fixed output derivation package-deps, then use that as input for building the project
<dthompson>and I found that the releases or the repo just had minified files. so problem #1 was: how do I build these from source? I needed grunt (or gulp, can't remember) and a minifier.
<unmatched-paren>i suppose you'd do <something something sqlite> (<- this is what it looks like when unmatched-paren thinks about a thing they know literally nothing about)
<dthompson>it wasn't long before circularity and massive dependency trees revealed themselves.
<unmatched-paren>sadly, I can't think of a stronger word than "dystopia" to describe this situation
<dthompson>circularity is always a problem with these language package managers for one reason: the notion of "development" dependencies.
<yuu[m]>unmatched-paren: yeah nix-index is pretty useful. then nix-locate to find which derivation has a specific file you need
<dthompson>it's a separate tree that no one ever deals with unless they are a developer on the project
<dthompson>but typicallyi you need that whole tree to build from source with guix.
<dthompson>which immediately puts guix on a path that no one else is going down
<vivien>dthompson, but now we have esbuild in guix, and that beast minifies anything
<dthompson>back when I was an active contributor I had more than one "why would you do that?" response when I tried asking questions to people outside guix
<efraim>there's also uglify-js and node-uglify-js
<dthompson>but the project chooses the minifier, so you need that one. :)
<unmatched-paren>how do you uglify JS any further? :P
<dthompson>and every other tool they use to produce a build
<yuu[m]>dthompson: how is that different from nix? you mean all the node dependencies need to be guixified as well? why just not FOD it like in nix?
<dthompson>hey ES6 is p nice
<dthompson>FOD?
<yuu[m]>fixed output derivation
<vivien>To quote dustycloud, back in the days: Unfortunately, Nix just downloads the prebuilt binary and installs that, which in the world of functional package management is kind of like saying "fuck it, I'm out."
<dthompson>^ yeah that
<efraim>wouldn't that be just downloading it and plopping it in the store?
<dthompson>it violates the standard guix has for packages
<vivien>I guess that’s the "binary importer" that jelle was talking about https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00814.html
<dthompson>yes
<ekaitz>hi, how do I clone only a subdirectory of a svn repository for a package?
<unmatched-paren>i guess "fixed output derivation" is Nix jargon for "gross hack to get around (nonfree|stupid) software"
<dthompson>it's also an issue for being a fully free distro
<cwebber>hi
<yuu[m]>vivien: depends. because as dthompson nixifying just everything for something like node and maven is such hardship
<cwebber>yes things have definitely gotten worse
<dthompson>if you just pull down whatever from npm and run it, you haven't built it from source.
<unmatched-paren>but wait, "nonfree" and "stupid" are synonymous anyway :P
<cwebber>one thing that happened in-between is we actually had a gsoc student do an npm importer
<cwebber>and they succeeded! I was a mentor on it even :P
<cwebber>however
<unmatched-paren>cwebber: yeah, we were talking about that a moment ago :)
<dthompson>I can't remember if I was comentor or just observing and offering a bit of help
<cwebber>the problem turned out to not be the importer, but the ecosystem
<cwebber>dthompson: I don't remember either
<unmatched-paren>however, the dependency trees were just too ridiculous and tangled?
<cwebber>I remember we co-mentored jakob's guix deploy, I was trying to remember if you helped on that one too, haha
<cwebber>unmatched-paren: yup.
<efraim>ekaitz: I'd check the svn-downloader, but depending on the size you could use a snippet to delete everything except for the subdirectory you need
<cwebber>bootstrapping problems everywhere
<cwebber>hundreds of packages where the guix definitions are larger than the code
<cwebber>loads of licensing problems
<yuu[m]>cwebber: what did this npm importer do? all node dependencies were actually built by Guix rather than just downloding them?
<unmatched-paren>yuu[m]: yes
<unmatched-paren>doomed to fail :P
<dthompson>we use a "modern" webpack-based js toolchain at $dayjob and the status quo is not good
<ekaitz>efraim: okay! thanks
<cwebber>it could be that there could be a guix channel that does what the nix folks do
<cwebber>which is just have a "giving up" channel
<dthompson>all sorts of ridiculous issues. javascript, the language, much improved over the years. javascript, the ecosystem, just getring worse and worse.
<cwebber>and you just package things in the nightmare state they're in
<unmatched-paren>"the depressed channel"
<cwebber>dthompson: yes exactly
<dthompson>that's the best option for people that need it
<dthompson>a third party channel
<cwebber>it's hard because I work with people who are legit, super smart PLT people who have done tons of work on JS
<cwebber>and have done great work! it's largely improved as a language
<cwebber>and yet I'm trashing JS all the time but it's not because I'm trashing the language really
<dthompson>I have a personal "no nodejs" policy for what I self host, because I do it all with guix and free software/reproducible only.
<ekaitz>efraim: lol it can be as simple as adding /subdir at the end of the url?
<cwebber>though there's lots of weird stuff in it
<cwebber>but
<cwebber>dthompson: samesies
<efraim>ekaitz: wait, that's it? that would make it pretty easy
<vivien>To be honest, I would definitely vote to have non-bootstrapped free software in guix, but I guess that sorting out which NPM packages are free software is not a lot easier than sorting out which one can be built from source
<unmatched-paren>cwebber: yeah, same with rust. the language has cool ideas, the ecosystem is both offputting and mandatory
<unmatched-paren>well, effectively mandatory
<dthompson>I'd be opposed to it. once guix goes down that road there's no putting the toothpaste back in the tube.
<unmatched-paren>i would be too
<ekaitz>efraim: I was in the sourceforge repo and clicked in the folder, watched the example `svn co URL` command change to +/subdir in the end and I'm giving it a try...lol
<dthompson>it would also remove a big part of what makes guix special
<ekaitz>efraim: LOL it actually works
<dthompson>guix being "stubborn" in this sense is a big part of why I like it
<vivien>What about the NPM stuff that sneaks in science packages?
<ekaitz>maybe SVN was the one an only SCM?
<vivien>We already have those.
*ekaitz hides after saying that heresy
<unmatched-paren>strictness about this sort of thing is good
<cwebber>I agree that strictness about these things are good. and we have a release valve
<cwebber>channels are the release valve
<dthompson>vivien: those are accidents, as far as I can understand, and every rule has its exceptions. guix should do its best to remedy the situation as much as possible.
<vivien>cwebber, channels are very frequently broken
<dthompson>I don't know what the current situation is, but in the before times many compilers were not bootstrappable.
<dthompson>and we lived with it.
<cwebber>vivien: but if we pulled in npm to our ecosystem
<cwebber>guix would often be broken :P
<vagrantc>dthompson: but we already have several non-bootstrapped things ... e.g. haskell/ghc and whatnot
<dthompson>right
<cwebber>it's a disaster. I've spent enough time in that hellscape
<efraim>there's fewer eyes on channels
<vivien>And vala
<cwebber>I think the main objection I have to guix's policy is not the policy itself, but the fact that there's a channel-which-must-not-be-named
<cwebber>I don't think that's helpful, that we can't name that channel :P
<dthompson>the cost of being tied to GNU
<unmatched-paren>dthompson: problem is, many of the remedies involve packaging mahoosive node trees :(
<unmatched-paren>e.g. r-markdown apparently bundles a `jquery-ui` js package
<unmatched-paren>and we all know what jquery is like :)
<cwebber>it makes sense to outsource the nonfree stuff, and not have this channel be the place where we talk aboub it
<dthompson>I think GNU should relax that but fat chance of that happening
<cwebber>but not letting people know about that
<efraim>We also have the python phase to try to search for cythonized files
<cwebber>well GNU's leadership also objected to the code of conduct, and also Emacs's manual talks about how to work with windows
<dthompson>unmatched-paren: right, so I say let the *goal* be to not do that, and make special exceptions where necessary.
<vivien>dthompson, being tied to GNU does not impact the bootstrap issue
<dthompson>I think that strikes the right balance between ideal/vision and pragmatism.
<dthompson>importing a ton of nodejs stuff: that's just opening the dang floodgates
<cwebber>dthompson: yes, so I think the ideal would be: have a npm channel that we can tell people about
<cwebber>"oh yeah, you want that stuff, hey go use this thing"
<dthompson>vivien: sorry, I was referring to the "don't speak of *that* channel" thing
<yuu[m]>dthompson: i'm somewhat opposed to that too. this is because i see the issue from the nix side of things, and it is not pretty. people just go that route and don't care anymore about actually building from source when things are hard to do so or not mature tooling around it.
<cwebber>"sorry it'll make our life hell if we put that in here and this is not the place to develop it but it's there for you"
<Noisytoot>cwebber: If it only contains free software, you can tell people about it here
<vivien>Yeah, but we could have an official channel with binary free NPM stuff
<unmatched-paren>vivien: it was in response to cwebber mentioning the fact that the forbidden channel is forbidden
<unmatched-paren>not to do with the bootstrap issue :)
<dthompson>Noisytoot: a nodejs channel would have proprietary stuff in it.
<unmatched-paren>Argh. Flaky internet sends messages too late.
<dthompson>unavoidably, because it's such a mess.
<cwebber>yeah that's part of the problem
<cwebber>a *huge* part of NPM is nonfree stuff, and probably not intentionally
<dthompson>yeah
<vivien>Well that solves the problem it seems
<cwebber>but because there's not much effort around making sure there are licensing notices, etc
<unmatched-paren>When I reply to something I'm not sure whether it's already been replied to :)
<yuu[m]>dthompson: but at the same time that route is the most feasible in the short-term
<vivien>Or rather, it closes the issue
<cwebber>so, an npm-hellscape channel, I'd support it
<dthompson>that's why I think a separate channel is the way to go
<cwebber>I might even use it, for some projects
<dthompson>yeah it could be useful
<gnucode>cwebber 143
<cwebber>on bare, isolated servers
<unmatched-paren>guix-here-be-dragons
<cwebber>before I knew about n*ng*ix I was thinking of making just such a thing and calling it guix-heresies
<vivien>cwebber, it is possible to run guix services in containers if you don’t trust the 4000 recursive dependencies
<dthompson>I personally won't use it because I only use guix in my personal life, not professionally (sadly), and I have to set some strict limits on what I have the capacity to maintain
<yuu[m]>cwebber: i mean as long it is not on guix official repo, then guess that's somewhat okayy. but there really need to be effort in doing things the correct way
<unmatched-paren> https://github.com/apognu/tuigreet <- this is a GPL rust package that links to a CDDL dependency somewhere down the line
<cwebber>if I put asterisks in it like a curse word can I escape the gnu GNFCC censors
<unmatched-paren>so rust does sometimes have that problem
<cwebber>GNFCC: GNFCC's Not FCC
<unmatched-paren>although i think they're usually better at licensing
<unmatched-paren>since crates.io enforces use of the `license` Cargo.toml field
<dthompson>it's a weird world where language design has vastly improved but the tools around those languages are faster and looser than ever
<unmatched-paren>note that i ended up giving up packaging tuigreet because it transitively depends on around 6 rust web frameworks
<dthompson>licenses? who cares I've got an app to ship!
<unmatched-paren>via rust-rust-embed, which is a dependent of rust-i18n-embed
<dthompson>unmatched-paren: oof I can relate.
<unmatched-paren>which is used by tuigreet for internationalization
<unmatched-paren>seems like rust-rust-embed has some integration with those frameworks
<dthompson>bootstrapping? who cares I've got an app to ship!
<unmatched-paren>so they're a required dependency :)
<dthompson>reproducibility? who cares I've got an app to ship! etc. etc. etc.
<yuu[m]>dthompson: nix search nixpkgs tuigreet legacyPackages.x86_64-linux.greetd.tuigreet (0.8.0) Graphical console greeter for greetd 😳😳
<vivien>Reproducibility? That’s handled by docker.
<unmatched-paren>shipping apps? who cares i've got an a... oh.
<dthompson>vivien: ha! love that one
<dthompson>"why are you building it? just use our docker container"
<dthompson>I've gotten that more than once
<unmatched-paren>i've seen one or two packages that run their tests in docker
<dthompson>or "just use <insert prebuilt binary thing here>"
<yuu[m]>dthompson: yeah nix tuigreet uses rustPlatform.buildRustPackage FOD stuff
<dthompson>there's a very prevalent attitude of "if you're not a core developer then you have no business learning how the software is built"
<yuu[m]>dthompson: so true.
<f1refly>what was the feature called where you can link two guix daemons so they can build each others stuff?
<yuu[m]>and they having so much bad documentation or not at all on the build process
<unmatched-paren>f1refly: i *think* that's an inferior?
<f1refly>isn't an inferior when you pin a package to a repo hash?
<dthompson>another thing I've gotten: "why aren't you using our install script?" you know, the one they asked me to curl | bash
<dthompson>'curl | sudo bash' even
<unmatched-paren>f1refly: i believe they *may* be the same thing
<unmatched-paren>i.e. you're creating a sub-guix and sub-guix-daemon that are pinned to some channels
<unmatched-paren>i'm not certain at all though
<f1refly>okay I'll see fi that's that
<f1refly>I vaguely recall reading about such a thing in the manual and now I'm transforming my desktop machine into guix as well
<unmatched-paren>oh, are you talking about over the network or something?
<f1refly>yes
<unmatched-paren>ah, that's not inferiors
<unmatched-paren>i thought you were talking about using a second guixd on the same machine
<yuu[m]>dthompson: there were some conflicts on nix vs upstream in regards to that.
<unmatched-paren>i'm not sure what offloading to another guixd would be called
<yuu[m]>nixpkgs*
<yuu[m]>debian even has a policy on that
<yuu[m]>like if upstream doesn't want debian to package it, then debian shouldn't package/distribute it
<dthompson>yuu[m]: I'm not surprised. nix is paddling upstream, too, maybe just with a bit of a weaker current than guix. ;)
<yuu[m]>in one situation for a home-manager dependency where maintainer and even home-manager team was pretty vocal against it, nixpkgs maintainer just packaged it anyway 💯
<unmatched-paren>why were they against it?
<vivien>Bootstrapping stuff on NPM is an un-googlable problem, therefore it is unfixable
<yuu[m]>not home-manager
<yuu[m]>i confused
<unmatched-paren>ah
<yuu[m]>it's home-something
<dthompson>I've gotta focus on some "real work" for a bit. it's been a fun discussion!
<yuu[m]>home-assistant*
<unmatched-paren>ahh
<unmatched-paren>isn't that some python thing?
<unmatched-paren>but why would they be against packaging in nixpkgs?
<unmatched-paren>that makes no sense whatsoveer
<unmatched-paren>s/veer/ever/
<yuu[m]>unmatched-paren: https://github.com/NixOS/nixpkgs/pull/126326
<vagrantc>packaging something against the will of upstream ... just sets people up for future conflict
<vagrantc>if you really need it, best to fork at that point
<unmatched-paren>lol, the author is being ridiculous
<vagrantc>that may be true, but that doesn't change reality
<yuu[m]>dthompson: seeya
<vagrantc>there are all sorts of ways upstream can make things go ugly, e.g. asserting "moral rights" and whatnot
<dthompson>okay last thing: it's weird that open source devs are more frequently trying to control how their software is built and distributed. been seeing that kind of behavior more and more.
<vagrantc>efraim: you fixed lcsync non-x86 builds! thank you!
<efraim>vagrantc: and it was my first time playing with simde!
<yuu[m]>unmatched-paren: idk what to thing about this tbh. guess people are exercising their free-speech. but well it is true that then if the dependency-author wanted could just relicense make it non-free non-redistributable or somethin.
<vagrantc>efraim: i need to import that into debian :)
<efraim>I still got a non-fatal test error on x86_64 but I couldn't find a different header to use that would fix it
<unmatched-paren>dthompson: I think that's what happens when people make (free|open) source software without actually believing in it... they get protective and have this idea in their head that the software is "theirs"
<efraim>vagrantc: go for it :)
<efraim>I actually checked there first to see if there was a fix
<unmatched-paren>it's not, it's everybody's, and that's the *entire point*
<vagrantc>efraim: does libsimde provide a cross-architecture implementation of #include <x86/ssse3.h> ?
<efraim>vagrantc: I'm not sure, but that's how I built it on my pinebook pro. with the x86/ssse3.h
*vagrantc blinks
<yuu[m]>dthompson: vagrantc unmatched-paren i think the problem was that dependency author did not want to deal with any related issue from nix people or any third-party. it is almost the same instance that rich hickey clojure author takes.
<yuu[m]>so forking would be the most reasonable way of doing things.
<unmatched-paren>i think nix users would be intelligent enough to know that if there are problems with the package, it's not necessarily the upstream maintainer's fault
<drakonis>home-assistant, eh?
<unmatched-paren>drakonis: One of its dependencies, specifically :)
<unmatched-paren> https://github.com/NixOS/nixpkgs/pull/126326
<yuu[m]>unmatched-paren: it is not that. imagine nix people or any third-party unofficial distributor creating issues in their bug tracker. sometimes it is kinda hard to trace if the problem is nix, the software, etc etc
<acrow> https://paste.debian.net/1250063/
<acrow>vagrantc: As discussed.
<drakonis>to be fair, nix does a lot of weird things
<unmatched-paren>well, then, be friendly and help them with that, don't lash out because you might get false issues on your tracker
<drakonis>this isnt the first time this happened either
<unmatched-paren>i bet it isn't
<vagrantc>people are free to decide what they want, even if it's unreasonable
<unmatched-paren>agree :)
<euandreh_>TIL: the code that copies passwords into VMs is called "secret-sevice" :p
<euandreh_>In gnu/build/secret-service.scm
<drakonis>there were other instances of home-assistant people going into nixpkgs to complain about it getting packaged
***euandreh_ is now known as euandreh
<yuu[m]>unmatched-paren: indeed. but some people just do not want to deal with that for free. sometimes licensing as free software in a kinda of free community for some people is just a means for their objective. i'm not sure about this particular case though.
<acrow>Enjoyed reading the last discussion. Is it free software if no one can build it? Guix requires 'build instructions' and that's a huge virtue. It is also secure which is another increasingly important word.
<yuu[m]>acrow: depends? why can't you build it?
<yuu[m]>license doesn't allow? then non-free
<unmatched-paren>yuu[m]: no, if there are no instructions, or it's incredibly tricky to the point of near-impossibility (see: android)
<acrow>Putting out another plea to a committer for
<acrow> https://issues.guix.gnu.org/32947#29 It's been carefully reviewed and leads eventually to ditaa and other more obscure but itch-scratching tools.
<yuu[m]>unmatched-paren: no what? i said depends because sometimes you need years old build toolchain that just disappeared from the earth
<acrow>yuu: I think it's free like in science, published experiments by multiple people must corroborate that it can be built.
<apteryx>how can I use the monitor port/socket of the marionette service to send QEMU commands such as screendump manually?
<acrow>Otherwise it reduces to pseudo-code.
<unmatched-paren>yuu[m]: "no" was referring to the "license doesn't allow?" part :0
<unmatched-paren>s/:0/:)
<acrow>When guix adheres to it's highest bootstrapability standards it is the best corroborator of software security and freedom I'm aware of.
<yuu[m]>unmatched-paren: btw do you have a link to that free vs impossible to build stuff? i think that makes sense but never saw a fsf/gnu piece on that
<davidl>unmatched-paren: reg. packaging tern (javascript tern-server) - I made some progress but got stuck on a package called node-parent-module that just doesn't give any error message, instead it eventually just throttles the cpu. I don't even know hot to debug it. Can u help? tern.scm is here: https://paste.debian.net/plain/1250066
<unmatched-paren>yuu[m]: nope
<unmatched-paren>davidl: I'll try :)
<davidl>thanks!
<unmatched-paren>why are the home-page and uri of node-parent-module completely different, btw?
<davidl>unmatched-paren: Im just trying to make the package build to begin with, cutting corners in the meantime when copy-pasting :-)
<unmatched-paren>davidl: which phase does it hang in?
<unmatched-paren>'build, 'check, ...?
<davidl>I don't know. It just eventually hang
<davidl>I guess actually, that would be the next, disabling phases.
<davidl>however, it takes a while before it hangs...
<unmatched-paren>try #:tests? #f maybe
<unmatched-paren>what's the last messages you get before it hangs?
<davidl>so not sure if there's a better way to investigate
<acrow>yuu: scala comes to mind. People have tried very hard to bootstrap it but no one has built it wo using a provided binary.
<davidl>guix build --verbose
<unmatched-paren>it'll have a "starting phase XXX" before it
<drakonis> https://github.com/flathub/flathub/pull/1978#issuecomment-743741387 yikes
<unmatched-paren>acrow: I've seen a scala bootstrap compiler, but it looks abandoned
<davidl>I get no message at all is the thing. I run guix build -f tern.scm and terminal is just silent.]
<lagash>euandreh: the U.S. Secret Service was created to solve mail crimes, and nowadays also investigates cybercrime, AFAIK
<unmatched-paren>drakonis: wow...
<lagash>What's the status of that guix pull authorization mishap? Following https://lists.gnu.org/archive/html/help-guix/2022-08/msg00073.html doesn't seem like it's permanently fixed yet?
<acrow>unmatched-paren: Maybe we need a new, non-legal, term -- shared software. I would not be able to say that scala is shared software.
<acrow>vagrantc: Do you see the features you most wished for there?
<vagrantc>lagash: the specific incident was "fixed" by reverting to an older commit on the git repository
<vagrantc>acrow: haven't gotten a chance to check yet, but it's in the queue
<acrow>vagrantc: :)
<vagrantc>lagash: but the fundemental problem is still there, it could happen again
<f1refly>unmatched-paren: https://guix.gnu.org/manual/devel/en/guix.html#Daemon-Offload-Setup
<vagrantc>acrow: i'm still excitedly reviewing efraim's work on lcsync :)
<unmatched-paren>f1refly: nice! glad to see you figured it out :)
<f1refly>Really excited to get that going :)
<lagash>vagrantc: I'm on ad878a2c5e5313c534ccf2546cb8c978e5295ae1, does that mean if I guix pull right now it won't complain?
*acrow looking up lcsync -- thinking it is like rsync
<vagrantc>lagash: easy way to find out is to try
<lagash>wasn't sure if it'll miss with the keyring branch or anything
<f1refly>Is there a way to convert a scheme object to a string so I can convert my offload build machine definitions to string and write them to a config file?
<davidl>unmacthed-paren: is it possible to do some kind of trace? like strace, gdb trace whatever, to see exactly what's being invoked in the guile process when the build hangs?
<f1refly>(if there is a better way that'd be great as well)
<vagrantc>acrow: still needs whitespace on when Files: contains multiple entries
<vagrantc>acrow: but otherwise looking very nice :)
<davidl>unmatched-paren: I found the error! I accidentally listed node-parent-module as an input to itself. Would be good if that threw an error preemptively though, instead of looping.
<acrow>vagrantc: ok, I'll get after that.
<unmatched-paren>davidl: Aha :) I've been caught out by that before
<vagrantc>acrow: e.g. it's coming out Files:\n a-file.scm\nother-file.scm ... rather than Files:\n a-file.scm\n other-file.scm
<vagrantc>acrow: seems to get that right for Copyright: entries
<vagrantc>acrow: what's the "any" license?
<acrow>vagrantc: ok, looking at it.
<acrow>vagrantc: the 'any license means we couldn't figure it out.
<acrow>vagrantc: nothing matched.
<acrow>vagrantc: when you look at any of those 6-7 files I think you will see why.
<vagrantc>acrow: maybe "UNKNOWN" would be clearer? as it's not really "any" license
<acrow>vagrantc: np
<vagrantc>acrow: ah, it'd be nice to trim the directory passed out of it ... e.g. -d /some/path currently results in Files: /some/path/file.scm rather than Files: file.scm
<vagrantc>since you already know exactly what it is, can remove it from the output
<nckx>sneek: later ask civodul: #$output:foo happily creates a :foo output even if it's not listed in the list of outputs. Is that a planned feature? I'm guessing it's not.
<sneek>Got it.
<nckx>sneek: botsnack!!!
<sneek>:)
<acrow>vagrantc: Hmmm... I thought I'd already beaten the directory prefix problem. But you don't get the same result... Hmmm.
<acrow>vagrantc: Oh, I see it.
<acrow>vagrant: I was using the -A option -- which is another thing.
<acrow>vagrantc: https://paste.debian.net/1250073/ All those things should be ok with this one.
<acrow>vagrantc: I thought you were joking about including a license but I still like the simplicity of RCS when not working on something that requires a tree of files to control.
<acrow>vagrantc: for that, yeah, git is king.
<vagrantc>acrow: i definitely was not joking about the license, how else would i demonstrate permission to use it? :)
<lagash>Wasn't there a shortcut to "jump" into the build environment if something failed? It's been awhile since I've created / updated package definitions...
<vagrantc>acrow: it's great! ... only small thing i see left is sorting the Copyrights entries ... if that's not too much to ask?
<acrow>vagrantc: :) well now it's in writing. I think; no lawyers have been consulted.
<acrow>vagrantc: well, they actually are sorted but I guess additional smarts are called for. I'll have to give that some thought.
<acrow>vagrantc: do you just want the existing order reversed?
<vagrantc>acrow: whole line sort, or sort by year?
<acrow>vagrantc: well right now it's whole line sort.
<vagrantc>acrow: https://paste.debian.net/1250074/ (i had to redact the email addresses, otherwise paste wouldn't go through)
<acrow>vagrantc: Here is where we miss that ability to discriminate surname.
<vagrantc>acrow: i just want sort by first listed year ... the rest by line?
<vagrantc>"just"
<vagrantc>acrow: there's no need to sort by surname.
<lagash>I know there's a kept flag, but is there a way to get into the build environment directly?
<acrow>vagrantc: waiting on icecat... but what you suggest seems easy enough.
<acrow>vagrantc: Yeah, I don't know what is up with those emdash characters. I'm sure I only insert #\-.
<acrow>vagrantc: UTF automagic I imagine. I'm not paying any attention to that.
<vagrantc>acrow: worst case i can search-and-replace :)
<nckx>lagash: No. ‘guix shell --pure -D PACKAGE’ and then sourcing environment-variables is the closest you get. Not that I've ever — ever — had to go that far.
<vagrantc>acrow: although maybe the whole "year" field makes sense ... e.g. "2016" "2016-2020" "2016, 2020" ... not sure how those should be
<nckx>I'd like to install something like this to avoid incidents like Sunday's: https://paste.debian.net/plainh/136a7cad (unproofread :)
<nckx>Make that https://paste.debian.net/plainh/ca6ee000, I guess.
<nckx>It's really bad, and I just realise it will still match primaries unless I add a "^" or something. We're just relying on style conventions. But I'm waiting for confirmation that we can use Guile here, and if so we're off to the races.
<gnucode>nckx I'm starting to wonder if you have God-like powers....
<gnucode>I don't know how you are so productive in helping guix. :)
<nckx>I'm really not.
<nckx>I'm struggling and way behind.
<nckx>But thanks.
<nckx>And then fun stuff like this jumps the queue and ruins everything.
*apteryx figured how to use the QEMU monitor via the GUI menu. The result of screendump is saved on the host
<apteryx>then you can run ocrad on that and see how poorly it did
<nckx>Those tests are whack.
<gnucode>nckx: I feel the struggle!
<nckx>sneek: later tell abcdw: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=dd7a29faf3eece4d1a672946d421e2bb72f245cf — but perhaps we should coordinate a time where a Savannah admin's on duty before we try again, if feasible, just in case.
<sneek>Will do.
<nckx>sneek: ONE MILLION BOTSNACKS
<nckx>Plurals are hard.
<amk>has anyone had luck with installing guix on the pinebook pro, to emmc?
<podiki[m]>nckx: not sure if it is the same, but in another channel having just tried switching from primary to subkey in authorizations did not solve a bad pull (still complains about not authorized); we did not first fix it though as was done here
<nckx>No, it won't fix it unless you roll back (a nice word for a hard reset) upstream.
<apteryx>nckx: I find the idea really neat :-)
<acrow>vagrantc: It isn't sorted bc some copyrights have no parsable years...
<nckx>It is! The OCR is of variable quality though.
<nckx>apteryx: ^
<apteryx>we could also try to use a more capable OCR, I think tesseract-ocr gave good results when I used it years back
<apteryx>Oh! there's also a new Ocrad release.
<apteryx>0.27 -> 0.28
*apteryx tries it
<apteryx>same output
<apteryx>supports PNG though, and QEMU too, so perhaps the lossless quality could help
<nckx>Using a font designed for OCR would help tremendously, but probably too much work, or a font that just OCRs better than the default we're probably using.
<nckx>Terminus 32 in ultra HD :)
<apteryx>hmm, tesseract-ocr needs 600+ gz'd trained data to boot
<vagrantc>acrow: can you put the exceptions somewhere special?
<vagrantc>acrow: or at the end? or beginning?
<vagrantc>acrow: e.g. sort what you can
<apteryx>oh wait, there's tessdata_fast, which is *only* 358 MiB
<apteryx>compressed
*vagrantc also doesn't understand why sorting by the whole line comes up in odd orders ...
<acrow>vagrantc: https://paste.debian.net/1250079/ It is hard bc there is no cleanup -- hence, eg... sort years-list will fail on an empty list. Similar.
<acrow>vagrantc: Notice that I use the set-record-type-printer!
<acrow>vagrantc: Those line strings don't exist before they are displayed.
<acrow>vagrantc: I'm sure rewrite three would make it better.
<vagrantc>acrow: that seems to work well enough!
<vagrantc>acrow: hmmm.. NEWS should be PERMISSIVE-VARIANT1
<vagrantc>acrow: this is totally good enough to be usable, though, thank you so much!
<ekaitz>hi I'm having an issue with a package I'm making: the makefile generates files in the source tree, but it says "Unable to create file", if I jump to the failed build directory, set the environment vars and run make it generates them with no problem
<nckx>$HOME, for example. Disallowed in the real build environment, happily writable when merely jumping in.
<nckx>Hard to say more.
<ekaitz>nckx: the created directories are inside the source dir
<ekaitz>I'm not sure about what's going on, honestly
<nckx>‘Unable to create file’ doesn't sound very unixy. Are error details logged anywhere?
<ekaitz>it wasn't literal, literally it does: ?ASxxxx-Error-<cannot create> : "../../../../build/small/asxxxx/gg/set_interrupts.lst"
<nckx>Still, I mean it's the build system noticing something and then printing that. It's not printing the actual (str)error it got from the OS. Would be nice to have that.
<ekaitz>hm yeah
<nckx>../../../../build always makes me wonder. Is it possible to share the package here?
<ekaitz>yes, but I need to change something first to make it free-software compatible, it doesn't use free software but it depends on a package that has some nonfree software and the patch that removes it is not set yet
<nckx>I see.
<ekaitz> http://git.elenq.tech/guix-packages/tree/gb.scm#n69 that's the package
<ekaitz>but it uses a nonpatched sdcc that contains non-free software
<ekaitz>I think you can replace it with the sdcc we have in guix and obtain the same error
<ekaitz>let me try so you don't have to
<davidl>nckx: any status update re bash-coding-utils?
<ekaitz>nckx: nah, the error is different, it needs that specific version but I didn't clean it yet so I won't ask about that
<ekaitz>if you can find any weird thing without installing sdcc-patched-for-gbdk that's cool
<davidl>unmatched-paren: I worked further on tern package but ran into recursion error, so don't know how to proceed: https://paste.debian.net/plain/1250081
<davidl>unmatched-paren: I mean a circular dependency problem, not "recursion error".
<unmatched-paren>davidl: Those are apparently common in Node-land.
<unmatched-paren>So common, we basically have no choice but to give up for many packages :P
<unmatched-paren>davidl: Try this, maybe:
<unmatched-paren>if P1 depends on P2 depends on P1, you can write an origin for P1 and put it in node-p1/bootstrap.
<unmatched-paren>then, use node-p1/bootstrap as an input for node-p2
<unmatched-paren>and try to copy the source for node-p1/bootstrap to a location where npm can find it
<singpolyma>Or make one package for both of them with two outputs, if it's a direct cycle
<unmatched-paren>then you can use node-p2 normally, and write a regular node-p1 with that node-p2
<singpolyma>A general solution to this would be 👌 but someone has to think it up first...
<unmatched-paren>well, cargo solves it with #:skip-build? iirc
<unmatched-paren>allows us not to include development-inputs
<unmatched-paren>which are the only kind that can have cycles
<singpolyma>Why? Something about rust makes other cycles not an option?
<unmatched-paren>that's what i've been told earlier
<singpolyma>Odd
<ekaitz>now I managed to remove the nonfree software so time to ask again :)
<ekaitz> https://paste.debian.net/1250085/ <-- this is what happens
<ekaitz>it's like that assembler thinks it's unable to write there when I'm in the package, but when I do it by hand it can
<ekaitz>what could it be?
<ekaitz>the path is in the build dir... so Idk...
<ekaitz>I straced it and it doesn't access anything outside
<ekaitz>hm