IRC channel logs

2021-04-17.log

back to list of logs

<civodul>i think it's be reasonable to postpone a little bit and have RCs
<civodul>*it'd
<lle-bout>civodul: has F2FS support been added to the installer?
<jlicht>mdevos: ik vind hospita wel iets hebben (en heb dat woord ook eerder gehoord al, als voornaamste reden dat het mijn voorkeur draagt)
<mdevos>serve -> opdienen, als in ‘serve store items’ -> ‘dien depotobjecten op’
<lle-bout>civodul: It's missing some f2fs packages added in some lists and then some commands to format block devices
<lle-bout>I could read multiple users asking for that
<nckx>mdevos: Poort? Aansluiting? Not quite equivalent but the most clear.
<mdevos>jlicht: hospita is meer gebruikelijk dan hospes. Ik heb nog nooit eerder van hospes gehoord
<mdevos>zal dat in het vervolg doen
<nckx>In the same vein, fun hacks like ‘hospes’ are, well, fun, but they don't actually help anyone understand & use the software.
<mdevos>nckx: maar er bestaat ook zoiets als WiFi en Bluetooth
<mdevos>WiFi-aansluiting? Bluetoothaansluiting?
<mdevos>er zijn geen kabels om aan te sluiten
<jlicht>interface is een ingeburgerd leenwoord
<mdevos>We zijn op 62%! Goed gewerkt denk ik
<nckx>Formidabel.
<mdevos>maar het is nu toch al laat (of vroeg?) aan het worden
*mdevos leaves
<nckx>Night-night.
<mavi>hello. i am trying to use sudo in emacs but it fails. emacs says "Wrong method specification for 'sudo'". i can use sudoedit, but it is very slow. how can i solve this?
<jlicht>mavi: I only know that error as a tramp issue; what are you trying to do?
<lle-bout>mavi: for me it works with 'emacs' package but not any other
<rekado>mavi: do you mean sudo as a TRAMP method?
<mavi>yes, with tramp.
<lle-bout>emacs-next, emacs-pgtk, or other emacs packages from third party channels, tramp sudo doesnt work for me. Only with the 'emacs' package.
<lle-bout>It says in logs it's unable to find the 'ls' command, also some times other errors
<mavi>lle-bout: yes, i am using native-comp emacs.
<mavi>so isn't there any way to solve this?
<civodul>lle-bout: re f2f, i have no idea; but it's not necessarily a blocker, is it?
<leoprikler>perhaps you want to substitute* some commands, e.g. "ls" with coreutils/bin/ls
<leoprikler>the wip-emacs branch already has some patches, perhaps they work for you (but maybe they're also too small, because they target standard emacs)
***mihi_ is now known as mihi
<gr0n>how often are packages upgraded in guix? i see that texlive is the 2019 version, but there's a 2020 and the 2021 version available upstream
<Telc[m]>i think its based on someone being interested enough to update it
<Telc[m]>are there install statistics collected for guix?
<Telc[m]>ie like debian popularity contest?
<gr0n>Telc[m]: how would one submit a patch to guix to bump a package, and are there any tests that i could run?
<Telc[m]>gr0n: I'm just getting started myself
<Telc[m]>sec
<Telc[m]> https://www.youtube.com/watch?v=R8DtPnP4eL8
<gr0n>cheers!
<Telc[m]>tldr; basically yeah you just send a patch to mailing list with updated version in a diff
<Telc[m]>someone with commit on the git repo will apply patch and it goes to build servers
<nij>Hello! I'm installing guix system from scratch. Before `guix system init /mnt/etc/config.scm /mnt`, I'd like to getch config.scm from my github repo. So I ran `guix package -i git`. But when I `git clone ...` as usual, there's an error "git: 'remote-https' is not a git command .See 'git --help'".
<nij>What's going on? Why does `git clone` fails when I'm installing guix system?
<roptat>gr0n, just send a patch to guix-patches@gnu.og, the manual explains how to set up the guix repo: https://guix.gnu.org/manual/devel/en/html_node/Building-from-Git.html
<gr0n>roptat: cheers
<roptat>gr0n, once you made the patch, you can check it's building with ./pre-inst-env guix build foo
<gr0n>awesome
<roptat>and check which dependents are affected with ./pre-inst-env guix refresh -l foo
<roptat>it will tell you how many packages are affected, depending on that number it would go to master, staging or core-updates
<roptat>also, it tells you which leaf packages to build to check everything is fine
<roptat>then, you fix every new build failure (it's fine not to fix a package that's already failing on master)
<gr0n>alright, i'll have to play with it a bit when i get some time. sounds like a reasonably straightforward system actually
<roptat>I mean it's not good, but it shouldn't block you updating another package
<gr0n>roptat: oh i'm used to a much worse system than this. one based on makefiles of all things.
<dongcarl>re: RCs I'd be happy to test starting next Monady!
<dongcarl>Monday*
***dmt is now known as abogado
<brendyyn>gr0n: you can tackle texlive, but i suspect it may be a big undertaking as a first contribution. You can look in the git repo for when TexLive was updated to 2019.3 by Marius. It required a lot of changes and fixes.
<brendyyn>gr0n: Also its a core-updates change. because 2000+ package depend on it so there will be lots of rebuilds, it will need to go there
<gr0n>brendyyn: oof, that does sound quite a bit bigger than expected. i'll give it a shot to see if it's maybe not as painless, but if this version bump is similar to the previous, it might be a bit painful
<gr0n>erm, painful, not painless
<gr0n>:)
<brendyyn>gr0n: It would recommending first updating a leaf node package as a contribution. That means a package that is not a dependency of anything else.
<gr0n>yeah that is something that i'll look into doing if this doesn't go according to plan. thanks!
<leoprikler>Of course adding leaf nodes is also always fine outside of string freezes.
<avalenn>I just tumbled on nss-cert problem with git
<roptat>leoprikler, I thought that was clear, but string freeze does not affect packages themselves (synopsis and descriptions are translated in another domain)
<roptat>so you can still feel free to change anything you want from gnu/packages
<leoprikler>nani?
<leoprikler>I thought we had a string freeze for all domains D:
<roptat>that's just not possible
<apteryx>sneek: later tell civodul, thanks that helped :-)
<sneek>Okay.
<roptat>obviously we'll continue to update packages, add and remove them
<roptat>and the packages domain is not very well translated anyway, and requires a lot of work, so that doesn't make a lot of sense to freeze it
<roptat>the best you'll find is the 19% French: https://translate.fedoraproject.org/projects/guix/packages/
<roptat>which I'm surprised I went so far already ^^'
<leoprikler>updating can be done without touching strings (maybe offsets change, but not the strings themselves), and removals do change the strings, but they're only taking stuff away
<roptat>(and the domain covers only a subset of gnu/packages)
<leoprikler>so the only thing that'd really matter is package additions or synopsis/description changes
<roptat>well, we can think about it for next release, it's too late now :)
<roptat>I just feel like it doesn't make sense considering the state of that domain
<leoprikler>Well, a string freeze if it was well coordinated, could help bump those numbers though
<roptat>how so?
<leoprikler>No one changes synopses and a bunch of people write purple prose for their favourite packages in their native tongue, of course :)
<leoprikler>same with the manual, though the manual appears much more manageable
<leoprikler>And quite importantly does not consist of thousands of pointless Rust packages :)
<leoprikler>hmm, now that I'm tired enough to get philosophical, could we bump package management into turing completeness?
<roptat>yeah, the only reason I managed to go so far is because I found games.scm to be somewhate meaningful
<roptat>I was thinking of something like that for OCaml
<roptat>you'd generate package definitions on the fly from the opam repository (similar to the importer), and build them immediately, except you'd not use existing packages, so you'd always get something similar to what opam would get you
<roptat>instead of having some weird packaging issues, and old versions or conflicts because we try to keep only one version around
<roptat>but of course this means you don't get the same level of QA as other guix packages
<roptat>it could be very useful for building node stuff too
<leoprikler>I think that's called curl | guix build
<roptat>makes you loose some of the provenance tracking though, except you could maybe do like *2nix do, and write the recipes to a file
<roptat>yeah, there would be more intelligence than that, because it would convert .opam recipes to actual package objects
<roptat>maybe that's not what you had in mind
<leoprikler>you can actually call the importer from a manifest
<leoprikler>I did that once
<roptat>oh, interesting
<roptat>also, guix-packages is ~2500 stings, the manual is ~10000 strings
<leoprikler>stings describes it perfectly, though
<roptat>(but in reality that's only because it's a small subset of packages)
<leoprikler>(eval (elpa->guix-package "vala-mode" 'melpa) (current-module))
<roptat>we have 17000 packages, so that should be ~34000 strings
<leoprikler>👆️ that's the snippet that I used to get vala-mode from melpa into my development environment
<roptat>oh, nice
<roptat>so what did you have in mind when talking about turing completeness'
<leoprikler>something entirely different
<roptat>ok, need to sleep, see you soon :)
<brendyyn>I feel like packaging needs more automation. for example is there a way to download and update the entire crates.io metadata so that an importer could work of that static data rather than connecting to the web each time?
<leoprikler>You could write a spider that feeds an importer-esque program?
<brendyyn>Can we change the whole process of packaging to be more of an Assisted process. So that guix refresh/import are actually the main ways in which things are update and automatically generated and then tweaked by a human
<brendyyn>All the rust packages embed versions numbers and dependencies that was all originally imported but then embedded in to guix's repo
<leoprikler>sneek, later tell roptat The Turing package manager would be able to do everything a Turing machine could do in terms of package installation. E.g. if you ask it to install 1 + 1, it installs package 2, if you ask it to install "1" + "1", it installs package 11, if you ask it to install + "1" + + "1", it installs "Syntax error: this is not Javascript" and if you ask it to install halt, it halts if the Turing package manager when
<sneek>Okay.
<leoprikler>asked to install halt doesn't halt.
<leoprikler>brendyyn: As much as I'd like to say "just remove that stuff and use guix import", the sad story is, that Guix packagers still know better than Rust in enough cases.
<leoprikler>That being said, all you'd need for refresh to work in the way you're describing is for it to also download the new source and produce a hash. A script could then take that input and edit the package definitions in place.
<leoprikler>There are also some people, who already use a CI process for updating their packages. I for instance do so outside of Guix, but I like to put effort into quality control in the main repo.
<brendyyn>Thinking in the long term, If Guix is always behind then why would rust programmers want to bother using it. Suppose our goal was to package all the Rust packages in existance and have then up to date somehow, we would need the importing process to be seamless and efficient, and based on some static data we could inspect and update manually, not connecting to the internet
<brendyyn>Then we could add features ontop that make Guix actually attractive to developers. For example automatically detecting if non-Rust packages are needed and adding them as inputs
<brendyyn>like how many of them need clang as and input and a variable set
<leoprikler>Garbage in, garbage out.
<brendyyn>The symbol names of rust packages have part of the version number embeded in them, so that can be generated and enforced rather than just sitting in source code
<brendyyn>I mean, the imported would be honed so that the final packages are essentially identical to what we already have manually. the actual code we would define would be a set of modifications to the importer, and something like (define-public (rust-package ...)) that would usually just be 1 single line
<leoprikler>There's a limit to how much you can abbreviate.
<brendyyn>It's just interesting to think about. If in theory our goal was to package a million billion programs, we'd necessarily have to develop some industrial production line level of efficiency and abstraction.
<leoprikler>If you move that metadata outside of the package description, you don't make the problem easier.
<brendyyn>Currently the metadata is often originally outside to start with, but we are then pulling it in to source code where it then needs to be manually updated
<brendyyn>its not like this means /putting/ the data outside
<Telc[m]>I'm having trouble building a rust package
*Telc[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/sYHnnJEWinPwHsZjVNECwCZx/message.txt >
<Telc[m]>I think this package is in crates-io.scm
<Telc[m]>I have the import right I think """ #:use-module (gnu packages crates-io)"
<Telc[m]>anything obvious to check?
<nij>Hello! I'm about to enter the phase of learning how to package (by actually packaging!)! Are there any general advice that I can take before? For example, should I be familiar with the toolchain that I'm going to use? I'm going to use cmake-build-system for the specific package of interest. Should I at least need to have some experience of packaging things by cmake on traditional systems?
<nij>It'd also be helpful if someone can tell me how approximately how hard is this to be packaged by a newbie: https://github.com/definite/ibus-chewing
<nij>Thanks :-)
<leoprikler>It does help if you are familiar with the tools themselves.
<leoprikler>Particularly when stuff goes wrong and you already know the error.
<leoprikler>ibus-chewing looks mostly sane.
<nij>Do you recommend that I at least package it on archlinux, for example?
<leoprikler>No no, "building it from source" is enough.
<nij>cool, i will proceed and have fun :-D
<leoprikler>no Debian, Arch or Gentoo-related knowledge needed ;)
<bone-baboon>I am having trouble connecting to Freenode.
<bone-baboon>I was using rcirc (IRC client built into Emacs) but recently I started getting SASL authentication errors.
<bone-baboon>In #freenode it was suggested that I use a client with SASL support.
<bone-baboon>Searching the rcirc info document for sasl returns no results.
<bone-baboon>Circe (Emacs IRC client) list SASL authentication support.
<bone-baboon>When I try to connect to Freenode using Circe I get this error:
<bone-baboon>-Server Notice- *** Notice -- You need to identify via SASL to use this server
<bone-baboon>*** Error: Closing Link: <gateway-information>
<bone-baboon>    (SASL access only)
<bone-baboon>My Circe configuration is:
<bone-baboon>(setq circe-network-options '(("testing" :host "chat.freenode.net" :port 6697 :use-tls t :nick "bone-baboon" :sasl-username "bone-baboon" :sasl-password "<password>"))))
<bone-baboon>Can a Circe user point out what needs to be fixed with this configuration?
<bone-baboon>What other Emacs IRC clients that support SASL authentication have people had success with?
<brendyyn>nij: i use chewing to type mandarin. so its great that you want to add that. i use fcitx-chewing though
<nij>Is (use-modules (a b c d)) a standard way of how Scheme (and its dialects) handles its namespaces? So that when that is evaluated, each directory in the load-paths will be examined.. until some-dir/a/b/c/d.scm is found?
<brendyyn>ive always wanted to get this stuff in guix
<nij>brendyyn: beware i'm a newbie - i might never succeed in that
<nij>but please gimme a few days before you do that, cuz i'm highly motivated by the same reason xD
<brendyyn>nij: best thing you can do is search the git repo for examples that are similar
<nij>brendyyn: yeah.. actually ibus-rime is quite good as i tested today.. but i couldn't get it working in emacs.
<brendyyn>nij: its been like 4 years since i thought of doing it and still havent done it xD
<nij>I got it working in icecat after adding some enviroment variables.. but emacs is stubborn
<nij>brendyyn: how do you type in CJK then in guix?!
<brendyyn>nij: I actually havent typed much mandarin at all in a while.
<brendyyn>for japanese id run ibus-daemon and use ibus-anthy
<brendyyn>but mostly im just typing it on my phone so i havent got around to setting it up right. before i used guix i was on parabola and used fcitx
<brendyyn>so its on my todo list to package more fcitx stuff. i tried once and got stuck
<nij>huh! lemme see if I can get ibus-chewing packaged
<nij>brendyyn: have you tried ibus-rime?
<nij>I actually found the experience better than chewing.. if it hadn't failed on emacs..
<nij>Their documentations are better written as well.. and it appears to be more customizable.
<brendyyn>years ago.
<nij>I want to do chewing cuz 1. I haven't figured out a way for rime to work for emacs.. and 2. just as a fun exercise
<brendyyn>i got angry at the whole problem because of how hard it is to configure when i use the colemak layout and make it work consistently
<nij>bummer
<brendyyn>maybe ibus is better these days but fctix used to be the way to go for chinese
<Telc[m]>sweet! my 1100 line rust package is building!
<nij>I'm actually not sure. Was wanting to use ibus-chewing because it happened to work for me on arch :)
<nij>Telc[m]: yay
<Telc[m]>first package
<Telc[m]>so yay :D
<brendyyn>nij: its a good contribution so i hope you get it in
<nij>Telc[m]: YAY! I hope I'd have my first done soon.
<nij>Seriously, I think someone should shoot some youtube videos that package for guix on live! That'd be fun and make the barrier much less scary.
<Aurora_v_kosmose>Substitutes are signed and verified after download, correct?
<Telc[m]>nij: https://www.youtube.com/watch?v=R8DtPnP4eL8 thats what got me started
<nij>I remember at some point he copied the "solution", which is supposed to be the crux and should be performed on live. Or maybe I remember wrongly xD..
<nij>That moment made me think.. hmmm maybe packaging is intrinsically hard, and that's why it appears to be hard.
<nij>But this work is invaluable, especially when there's not many resources out there. So thumbs up to A. Tropin!
<drakonis>i'm highly tempted to do guix again now that i'm much better at lisp-y langs
<nij>drakonis: do it :) I feel the same way so I came back too
<emacsen>Hey guix folks, when a build happens, everything is captured (build files, architecture, etc.) where is that stored?
<guest97>Hi! Installing guix, ran 'guix system init ...' and it says cannot build derivation '/gnu/store/...-libx11-1.6.A'
<guest97>What do i do now?
<nij>Hello! I'm trying to package a thing.. I will obtain the source by method `git-fetch`. What should I put in the slot `(sha256 (base32 ...?))`? How do I get the hash?
<nij>Should I git clone the whole repo, and compute its sha256 some against the whole directory?
<Telc[m]> nij: I think you can make sometimes ng up and then correct it with what it complains about not matching
<nij>oh! nice tip. thanks :)
<brendyyn>nij: put in a fake hash and try build it. itll tell you what it actually is
<brendyyn>bit of a silly trick
<nij>doing :) --- I'm stuck with something else while trying. I need "gob" to build. I think it stands for gtk object builder.. does guix have that already?
<nij>Hello! I'm packaging something that asks me to run `cmake . -DCMAKE_INSTALL_PREFIX='/usr' -DLIBEXEC_DIR='/usr/libexec'
<nij>` on a traditional linux machine. I feel like I should probably alter this right? As guix doesn't really use `/usr`..?
<brendyyn>nij: Look at guix/build/cmake-build-system.scm
<brendyyn>the first variables is already handled in there
<brendyyn>i suspect LIBEXEC_DIR can remain unset and it will use the correct path
<mange>Hey! Random question, does LIBRARY_PATH during a build include both inputs and native inputs? If yes (which I think is the case), is there a way to strip out the native inputs, but leave the regular inputs? I'm not cross compiling.
<mange>I'm looking into https://issues.guix.gnu.org/31719 and while I could hard-code some library names to exclude from the patching, the problem is really that native inputs are being considered for rewriting runtime references.
<apteryx>mange: mmh, tricky
<apteryx>I don't know; perhaps something needs fixing at the low level
<apteryx>is anyone still able to use this trick to SSH into a VM created with 'guix system vm' ? /gnu/store/...-run-vm.sh -nic user,model=virtio-net-pci,hostfwd=tcp::11111-:22, then 'ssh root@localhost -p 11111' (OS needs to have the ssh service with (openssh-configuration (permit-root-login 'without-password))
<apteryx>here it hangs after: debug1: Local version string SSH-2.0-OpenSSH_8.5
<mange>apteryx: I'm seeing the same thing here. Trying to use a non-root user didn't work, either.
<apteryx>OK :-/
***apteryx is now known as Guest86193
***apteryx_ is now known as apteryx
<Akawama>I'm trying to create my first config.scm. I want to use hikari, wayland window manager which requires elogind. It has been installed as a dependency. When I run 'sudo herd enable elogind' i get 'herd: service 'elogind' could not be found.
<Akawama>Do I need to create this service?
*raghavgururajan wakes up and rubs his eyes
<raghavgururajan>Hello Guix!
<mange>Akawama: Hmm. Do you have %desktop-services in your operating-system definition? If not, I think you'll need to add (elogind-service) to your services.
<mdevos>nckx, jlicht: (guix publish) server -> dienaar, bediende, ambtenaar, functionaris?
<mdevos>ik zou voor ‘bediende (‘server’)’ gaan
<jlicht>mdevos bedieningsserver?
<mdevos>jlicht: dat is nogal een pleonasme. In een restaurant: server == degene die je eten opdient
<mdevos>bedieningsserver == bedieningsopdiener
<mdevos>toch?
<jlicht>bediende is inderdaad beter dan
<mdevos>aangezien ‘server’ de gangbare term is, zal ik dan wel tussen ‘aanhalingstekens’ ‘server’ zetten
<janneke>serveerder misschien? een bediende hoeft niet te serveren
<mdevos>janneke: dat lijkt inderdaad wat beter
*janneke almost got a hartverzakking seeing all that dutch here ;)
<mdevos>are there any people here who _don't_ speak Dutch?
<janneke>there certainly are people who speak dutch that aren't here
<mdevos>but is it something like 10%, or more like 90%?
<janneke>i'd say 10%, but i can't guess what people have been studying this past corona year
<mdevos>10% don't speak Dutch, or 10% do speak dutch (-:? I'd assume 10% do speak Dutch?
<janneke>yes, that would be my guess
*raghavgururajan wants to learn Martian xD
<terpri>good morning #guix
<roptat>hi guix!
<sneek>Welcome back roptat, you have 1 message!
<sneek>roptat, leoprikler says: The Turing package manager would be able to do everything a Turing machine could do in terms of package installation. E.g. if you ask it to install 1 + 1, it installs package 2, if you ask it to install "1" + "1", it installs package 11, if you ask it to install + "1" + + "1", it installs "Syntax error: this is not Javascript" and if you ask it to install halt, it halts if the Turing package manager when
<leoprikler>Well, that got cut off, but you get the point :)
<roptat>right, I read the logs :)
<nckx>Morning Guix.
<nckx>mdevos: I saw ‘hospes’ actually made it into git. Do avoid Denglish whenever possible, but we must also prioritise usability over purity/creativity. ‘Het bouwsel uitbesteden aan de hospes is mislukt want je had de verkeerde sleutels vast!’ is a text adventure gone weird.
<zzappie>strange, during guix upgrade I got 40% [######$*&%^$&%^&$^*SEVERAL_PAGES_OF_BINARYGOBLEDIGOOK_and_make_ouput*######]
<rekado_>zzappie: sometimes output escapes our way of redirecting it to a separate port
<rekado_>not sure why
<rekado_>sneek: later tell brendyyn For CRAN / Bioconductor packages what you describe is already reality. I can’t remember the last time I wrote an R package definition by hand.
<sneek>Okay.
<rekado_>sneek: botsnack
<sneek>:)
<zzappie>rekado_: I see :)
<attila_lendvai>hi! i'm looking for any bird's eye view readings or opinions on how guix and nix compare to each other, especially in terms of current status. i'm not intending to troll, or start a flame. i moved to nixos from debian a few months ago, and i'm really loving it, but i'm a lisper, and i have also learned, to my horror, that nix is bash all the way down...
<attila_lendvai>i don't want to invest into learning something new that is inferior to something else... i'm already hacking on/in nix, and i'm wondering whether i should stop right now, and move on to guix...
<leoprikler>Guix is probably friendlier to Lispers, being written in Scheme, but you should also be interested in free software.
<leoprikler>No advantages for proprietary lispers.
<gr0n>attila_lendvai: so i tried use nix, and i just found it clunky for my usecases, which is managing many versions of the same thing with an easy way to switch between them
<gr0n>also i couldn't for the life of me get over their language
<gr0n>opted for guix instead, and was pleasantly surprised that it's also all free software guaranteed
<attila_lendvai>i prefer free software, and i mostly only use and write free software, but i'm not a fundamentalist. and i also have some issues with nix, the language.
<roptat>how can I test installing guix on a foreign distro, for the upcoming release?
<roptat>I think I found what I needed: I create VMs with foreign distros (systemd and openrc), download the latest installation script, and modify it to download the latest tarball
<emacsen>Hey guix folks, when a build happens, everything is captured (build files, architecture, etc.) where is that stored?
<leoprikler>The store.
<emacsen>leoprikler, can I see them?
<leoprikler>Though log files go elsewhere, to /var/log to be exact.
<emacsen>leoprikler, but when I do a guix challenge and something isn't the same, will it just fail or will it say "Hey of course this doesn't work, because things (versions of software, architecture, etc.) aren't the same?
<leoprikler>And the temporary build directories are discarded unless you specify -K and it fails.
<leoprikler>guix challenge only compares store items, that should be equal
<leoprikler>i.e. same system, same compile commands, same everything.
<emacsen>but not the route in getting there... got it
<leoprikler>so if your build system e.g. embeds time stamps or the name of the machine it built on
<leoprikler>you will see that in the output diff
<emacsen>leoprikler, *nod*
<leoprikler>which you can get by running diffoscope on the file you have and the file the substituter has
<leoprikler>(or any other diff tool, but Guix seems to advocate diffoscope because it's useful)
<emacsen>leoprikler, yeah my goal here is not quite the same as I think what you're thinking, but thank you :)
<roptat>uh oh, that failed :/
<nij>Can I leave an offline message to someone on #guix?
<dekenevs>hey awesome guix ppl. I ran a guix pull recently, but it fails for binutils-mesboot0-2.14. i checked the logs and apparently it fails because there's no `flex`. is this normal?
<gr0n>correct me if i'm wrong, but isn't flex non-free?
<raghavgururajan>> nij‎: Can I leave an offline message to someone on #guix?
<raghavgururajan>sneek is your friend for this.
<raghavgururajan>sneek, later tell nij: Tada!
<sneek>Will do.
<dekenevs>gr0n: hmm, I see it in commencement.scm as a (gnu packages flex) module
<dekenevs>gr0n: but wait even weirder, "checking for flex... lex" [... 3 lines below] "lex: command not found"
<gr0n>hum, ok i guess i'm wrong then and it sounds like a potential bug?
<nij>@@ how do i let sneek tell someone an offline message?
<dekenevs>hmm it's a fresh install and I didn't install it with the official script (it was an AUR package). but that shouldn't matter right? should I try with the official script?
<dekenevs>i'll give it a shot
<cage_>hi! there is a release version of a library in guix that is outdated, it is advisable to update its definition package from a new commits (even if it is not an official release, i mean no got tagged commit)?
<mavi>hello. i use emacs-next on my guix system. but i cannot use tramp with sudo, it fails. how can i solve this issue? could you guys please help me?
<roptat>nij, normally that would be "sneek, later tell <someone> <your message>"
<roptat>although it didn't seem to work when raghavgururajan left you a message ^^'
<leoprikler>sneek, tell nij and it's really "later tell", not "tell"
<raghavgururajan>sneek, botsnack
<leoprikler>yeah, sneek is ded
<raghavgururajan>Can you investigate the death of sneek, officer nckx? 👮️
<bone-baboon>When I try to connect to Freenode using Circe I get this error:
<bone-baboon>-Server Notice- *** Notice -- You need to identify via SASL to use this server
<bone-baboon>*** Error: Closing Link: <gateway-information>
<bone-baboon>    (SASL access only)
<bone-baboon>My Circe configuration is:
<bone-baboon>(setq circe-network-options '(("testing" :host "chat.freenode.net" :port 6697 :use-tls t :nick "bone-baboon" :sasl-username "bone-baboon" :sasl-password "<password>"))))
<bone-baboon>Is there a Circe user here that can point out what needs to be fixed with this configuration?
<bone-baboon>What other Emacs IRC clients that support SASL authentication have people had success with?
<dekenevs>try #emacs?
<leoprikler>mavi: I'm currently building emacs-next on wip-emacs, I'll let you know once I'm finished
<bone-baboon>dekenevs: okay thanks
<mavi>leoprikler: oh, thank you. i'm actually using emacs from this channel: https://github.com/flatwhatson/guix-channel
<mavi>but some guy told me yesterday emacs-next has the same issue.
<leoprikler>you mean the native-comp right?
<mavi>so i said that i'm using emacs-next so you guys can see it from official repos.
<mavi>leoprikler: yes
<leoprikler>yeah, I've been doing some emacs UX changes recently which haven't been upstreamed yet, so if those by chance fix emacs-next, it's likely going to be the same for pgtk and native-comp
<flatwhatson>my packages inherit from emacs-next so if it's a patch or a new phase it should "just work"
<raghavgururajan>Do anyone use certbot-service-type with CSR?
<leoprikler>Hmm, it seems that some stuff in Elisp changed
<leoprikler>`getconf PATH' not successful, using default value "/bin:/usr/bin" sounds pretty bad
<nckx>raghavgururajan: I've bothered sneek's owner, that's all I can do. We don't have any control over our own channel bot. I wouldn't say it's a sore point but it's not ideal.
<raghavgururajan>nckx: No worries! I just funnily mentioned you as our cop friend. ;-)
<raghavgururajan>Hmm. I get "In execvp of /etc/desec/hook.sh: Permission denied" for https://paste.debian.net/plain/1194085
<raghavgururajan>Any ideas, anyone?
*nckx IS‌ NOT A COP please relax everyone
<civodul>raghavgururajan: that probably means hook.sh lacks executable permissions
<civodul>so you need to chmod +x /etc/desec/hook.sh
<raghavgururajan>Ah, thanks civodul. Lemme try
<raghavgururajan>"It appears that you are not running this script through certbot ($CERTBOT_DOMAIN is unset). Please call with: certbot --manual-auth-hook=/etc/desec/hook.sh"
<raghavgururajan>May I should put "/etc/desec/hook.sh" directly in (authentication-hook
<raghavgururajan>Damn! Same error.
<leoprikler>mavi: Okay, I think the problem is, that tramp does not find uname
<mavi>leoprikler: what should i do then?
<leoprikler>Patch it so it does ._.
<leoprikler>or no, wait, uname -sr still works
<leoprikler>ehhhhhhhhh
<leoprikler>I hate the Emacs debugger
<another-nick>Could someone unban me (Noisytoot) on #guix?
<civodul>another-nick: we've asked you to wait for one week before coming back
<leoprikler>mavi okay, at the very least tramp from emacs 27 works for emacs 28
<civodul>another-nick: please stop gaming IRC
<another-nick>civodul, https://logs.guix.gnu.org/guix/2021-04-16.log#232608
<another-nick>civodul, You actually said the ban was temporary, and did not say to wait 1 week specifically
<mavi>leoprikler: i will try using old tramp then. thank you very much for your time.
<Aurora_v_kosmose>The issues with the CVE system make me wonder if one fixes more issues than they introduce by keeping things to the latest releases.
<Aurora_v_kosmose>This coming from someone who is mainly a Debian user, and thinking that if only CVEs get backported, and CVEs don't get published as half often as they should, then isn't that a major problem?
<Aurora_v_kosmose>Posting this in this channel mostly for the "is most up-to-date introducing more fixes than bugs" question. The rest is just background.
<leoprikler>Well, that's a philosophical question for the most part.
<leoprikler>With new software you can't be sure what bugs they'll introduce but you have to defend against those you know.
<Akawama>Like global /etc/config.scm. Is it possible to have config.scm for local user, so it would override the global config.scm?
<leoprikler>Okay, it really seems to be uname
<leoprikler>sh: uname: command not found
<mavi>leoprikler: isn't adding uname to the path variable supposed to fix that? or am i missing something?
<leoprikler>We have a snippet for tramp-default-remote-path, that *should* take care of that.
<leoprikler>Emphasis on *should*.
<mavi>maybe installing coreutils package as user can solve this. just a prediction.
<roptat>mh... guix system: bootloader successfully installed on '/dev/mmcblk0' but it's still booting to the previous distro
<leoprikler>no
<leoprikler>uname is already part of "/run/current-system/profile/bin", which lies in tramp-remote-path
<nckx>Hi Akawama. User-level configuration (~/.config, etc.) is explicitly out of Guix's scope for now, so there's nothing to configure there. Conversely, allowing regular users to override the main system configuration sounds like a direct security risk. I'm not sure what else remains. Users can ‘override’ system packages with a manifest, that's about it.
<another-nick>You can use guix package -i to install packages
<nckx>A correct fact.
<roptat>it seems to be installed, I see the string "U-Boot SPL 2021.04 (Jan 01 1970 - 00:00:01 +0000)" in /dev/mmcblk0
<roptat>whereas my foreign distro used u-boot 2017.01
<mavi>leoprikler: symlinks might be problematic. check this out: https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=feature/native-comp&id=9aa5203b542f0c9ea7d074c6cfde2a28b466f5d1
<leoprikler>Argh!
<nckx>another-nick: Do you promise to behave this time, and abide by basic social norms like not circumventing ignores?
<another-nick>nckx, yes
***ChanServ sets mode: -b *!*@fsf/member/Noisytoot
<nckx>I'm genuinely happy to have you ‘back’.
<nckx>Hence I'm going to pretend that another-nick was your dog typing next to you and not ban circumvention :)
*nckx pets another-nick.
<roptat>mh... why is the new uboot not booting the guix system then...
<nckx>That cuts both ways though: since I'm sick of drama, there will be no warnings or strikes.
*nckx → foodz.
<leoprikler>mavi: okay, new result, adding coreutils to PATH *does* fix it
<mavi>leoprikler: :)
<roptat>at least the good thing is I know the new u-boot can boot the machine
<leoprikler>but to PATH
<leoprikler>installing it to your profile won't help you with pure environments
<raghavgururajan>Am I configuring certbot-service-type correctly? https://paste.debian.net/plain/1194091
<raghavgururajan>After system reconfigure, `herd status` doesn't show certbot
<lighthouse>hello
<leoprikler>raghavgururajan: it's an mcron service
***brown is now known as Guest53609
<nckx>Hullo lighthouse.
<raghavgururajan>leoprikler: Oh. I should see certs in /etc/letsencrypt right? after reconfigure?
<raghavgururajan>I don't.
<nckx>Maybe not immediately, see ‘herd schedule mcron’ to see when it's expected to run. But disclaimer & all I don't use certbot.
<raghavgururajan>Does that mean, mcron hasn't ran yet?
<nckx>*sudo
<leoprikler>look in /var/lib/certbot, perhaps stuff is there
<raghavgururajan>In the paste, I have declared auth-hook correctly right?
<raghavgururajan>Not sure if its single quotes or double
<lighthouse>Hi. How can I submit new pakages to guix. I have read the man, I didnt get it right. Do I have to make a patch?
<leoprikler>if it's supposed to be a filename, then yes
<leoprikler>lighthouse: That's the typical way, yes
<leoprikler>Do you want to contribute in an atypical manner?
<raghavgururajan>Jeez, how do I unbundle nginx service. I don't need it.
<lighthouse>leoprikler, Whats the prefered way ?
<leoprikler>Sending a patch [set] via git send-email
<Noisytoot>leoprikler, What is the atypical way?
<raghavgururajan>Sun Apr 18 00:45:00 2021 -0400
<raghavgururajan>/gnu/store/sgyskhi0aa8iawrmwwb1am5wp5yg4f9l-certbot-command
<leoprikler>Sending something, that is not a patch.
<raghavgururajan>nckx: Got the schedule. Can I make it to run now though?
<leoprikler>There is a grey area with sending patches as attachments. Humans understand those, but machines don't.
<Noisytoot>How does issues.guix.gnu.org show those?
<raghavgururajan>lighthouse: I found this to be useful. https://git-send-email.io/
<nckx>raghavgururajan: You might get lucky with ‘sudo -i <the command that ‘sudo herd schedule mcron’ says it would run>’. Haven't tried.
<leoprikler>Noisytoot: "those = ?"
<Noisytoot>leoprikler, patches as attachments
<nckx>I think it handles attachments well.
<nckx>Maybe not in-line/highlighted but you can at least download them.
<leoprikler>Yep, you don't have any issues with looking at them.
<raghavgururajan>nckx: I am logged-in as root. So I just do `./gnu/store/sgyskhi0aa8iawrmwwb1am5wp5yg4f9l-certbot-command` ??
<leoprikler>But it does screw up some folks' automated setup.
<leoprikler>./gnu/store looks like a recipy for trouble
<nckx>No . but that was probably a typo.
<nckx>Otherwise, sure, looks good, try.
<leoprikler>you want to make that an absolute path
<raghavgururajan>I didn't do any typo xD
<nckx>‘./gnu/store’? Why?
<nckx>Is that really what the certbot job calls?
<raghavgururajan>No dot at the beginning?
<nckx>It's just weird.
<nckx>It'll work if you're in /, not otherwise, but just... why.
<raghavgururajan>Without dot worked. Thanks!
<nckx>> Is that really what the certbot job calls?
<nckx>Still wondering.
<raghavgururajan>Well, had errors, but the command was executed.
<nckx>Great.
<nij>sneek, tell nij and it's really "later tell", not "tell"
<nij>sneek, you alive?
<nckx>sneek is dead and we killed him.
<nckx>All of us.
<nij>Ok, I finally am starting to package.
<nckx>RIP.
<nij>RIP
<raghavgururajan>nckx: https://paste.debian.net/1194092/
<nckx>OK, no leading . , good.
<raghavgururajan>hook.sh has curl commands, which is not in profile.
<raghavgururajan>Hmm. Should I install in root profile or system profile?
<nckx>Best system.
<nij>Hello! I'm using cmake-build-system to build a package. In the source repo, it instructed me to run `cmake . -DCMAKE_INSTALL_PREFIX='/usr' -DLIBEXEC_DIR='/usr/libexec'. I think the first var is set.. but how about -DLIBEXEC_DIR? What should I set it to?
<nij>`
<nckx>You've made it a dependency of your system configuration, keep them together.
<lighthouse>To which repo should I send the patch ?
<nckx>raghavgururajan: This is why my hook script is in-line bash code in a Scheme string in my system.scm. It gives you cancer to look at it, *but* I can use gexps to pull in dependencies automatically.
<nckx>lighthouse: It should apply on top of <https://git.savannah.gnu.org/cgit/guix.git>, and you should send-email it --to guix-patches at gnu.org.
*raghavgururajan 's head spins ... looks at nckx for holy water
*nckx has only holy water blessed by Satan himself
<nckx>And I say ‘water’, but, well...
*nckx AFK.
<Noisytoot>sneek: botsnack
<Noisytoot>What happened to sneek?
<raghavgururajan>certs generated. Yay!
<nij>Help ! :) Why does guix complain that I do not have a string here:
<nij>(arguments '(#:configure-flags '("." (format #f "-DLIBEXEC_DIR='~a/libexec'" out))))
<nij>In particular, it complains that (format #f "..." out) is expected to be a string, but it's not.
<nckx>nij: Too much quoting. You're passing (format ...) itself, as *code*, as the second list element. You're not evaluating it.
<nckx>Use (list "." (format ...)) or `("." ,(format ...)).
<nckx>I strongly recommend list as I find it much more readable.
<nij>I see.
<nckx>raghavgururajan: Huzzah!
<nij>Progress! Thanks ncks :)
<nij>-- Configuring incomplete, errors occurred!
<nij> command "cmake" "../source" "-DCMAKE_BUILD_TYPE=RelWithDebInfo" "-DCMAKE_INSTALL_PREFIX=/gnu/store/gcfd446mzgqj0bzmvj95xm6rwpaaw389-ibus-chewing-1.5.1" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE" "-DCMAKE_INSTALL_RPATH=/gnu/store/gcfd446mzgqj0bzmvj95xm6rwpaaw389-ibus-chewing-1.5.1/lib" "-DCMAKE_VERBOSE_MAKEFILE=ON" "." "-DLIBEXEC_DIR='/usr/libexec'" failed with status 1
<nij>
<nckx>I expect the cause to be listed above that line.
<nij>This is from the build log.. it only says it fails.. but didn't say why :O
<nckx>Hm.
<nij>CMake Error at CMakeLists.txt:40 (MESSAGE): ManageEnvironmentCommon.cmake is not found in CMAKE_MODULE_PATH.
<nij>
<nij>This one?
<nckx>I guess so...
<nij>This is the only "CMAKE_MODULE_PATH" in the whole log. I didn't set it explicitly either.
<raghavgururajan>nij: You might extra-cmake-modules
<raghavgururajan>*might need
<nckx>Try adding extra-cmake-modules, which is a total guess, because what I'm seeing elsewhere isn't promising.
<nckx>‘cmake-fedora: Set of cmake modules for fedora developers’
<nckx>Oh, what raghavgururajan said.
<nckx>If that really is the source, it needs to be packaged.
<nij>extra-cmake-modules is given here : https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/kde-frameworks.scm#n87
<nij>do i include it by (use-module (gnu packages kde-frameworks extra-cmake-modules))?
<nij>Oooop - no code for module (gnu packages kde-frameworks extra-cmake-modules)
<nij>
<nckx>No no.
<nckx>Add (gnu packages kde-frameworks) to the module imports at the top of the file if it's not there yet, then add extra-cmake-modules to the native-inputs of the package.
<nckx>By the way, guix show and guix search also print the location.
<nckx>But it's fine if you prefer other means.
<nij>Make sense. I did that again with extra-cmake-modules, but still ---- CMake Error at CMakeLists.txt:40 (MESSAGE):
<nij> ManageEnvironmentCommon.cmake is not found in CMAKE_MODULE_PATH.
<nij>
<nckx>Then I fear you must first package cmake-fedora.
<nij>Oh by the way, I'm using cmake-minimal. Maybe I should use a full-fledged cmake.
<nckx>Welcome to the rabbit hole ♪
<nckx>Oh, yes, try that first.
<nij>Hmm.. still CMake Error at CMakeLists.txt:40 (MESSAGE):
<nij> ManageEnvironmentCommon.cmake is not found in CMAKE_MODULE_PATH.
<nckx>Which package is this? Is it plausible that it would use Fedora-specific modules?
<gr0n>i'm always amazed at how complicated packaging some software is... in theory you'd think that it's just a matter of writing: "ah yes download from here, build like this, and these are deps". in reality, a year later and you're still struggling :)
<nckx>Before I send you down the *wrong* rabbit hole.
<nij>nckx: I'm packaging ibus-chewing: https://github.com/definite/ibus-chewing/blob/e221ddd14dcfc922900db92fd6d9cca0e358a0f8/INSTALL
<nij>It's my first package.. so it could be a bit rough.
<nckx>Ah, that's exactly the package mentioned in all these search results.
<nij>gr0n - you mean even with 1-year long packaging experience, it could still be hard?!?!?!?!
<nij>Sounds like QFT..
<gr0n>nij: that is my experience with other package systems. maybe guix is better :D
<Noisytoot>Is cmake-fedora applicable to Guix?
<nij>nckx: what do you mean @_@?
<nij>Noisytoot: didn't find any "fedora" in the output of `guix search cmake`
<nij>gr0n: :-( I hope guix is better. Well.. it should be even harder than other traditional ones, no?
<nckx>nij: That I think it does depend on cmake-fedora: <https://www.freshports.org/chinese/ibus-chewing/>
<gr0n>well the traditional package managers are hard to reason with when it comes to breakages and reproducibility. guix most certainly makes this better...
<nckx>Noisytoot: If the bundled CMake files require that non-standard module, then yes.
<nckx>nij: See ‘build dependencies’ on that page, it even mentions ManageEnvironmentCommon.cmake explicitly.
<nckx>It's one of the few non-contextless-random-build-log search results I found.
<nij>nckx.. hmm on its official repo it doesn't mention fedora - https://github.com/definite/ibus-chewing/blob/e221ddd14dcfc922900db92fd6d9cca0e358a0f8/INSTALL
<nckx>It does though: https://github.com/definite/ibus-chewing/blob/e221ddd14dcfc922900db92fd6d9cca0e358a0f8/INSTALL
<nckx>Build-time download magic ♪
<nij>nckx: it does?
<nckx>See my link.
<nckx>Oops, sorry, clipboard still busted.
<nckx> https://github.com/definite/ibus-chewing/blob/e221ddd14dcfc922900db92fd6d9cca0e358a0f8/CMakeLists.txt#L16
<nckx>That one.
<nckx>If it is a git submodule you might be able to use (git-download … (recursive #t)).
<nckx>It's a bit icky but less work than packaging cmake-fedora for now.
<nij>Oh indeed. It appears to be a submodule here: https://github.com/definite/ibus-chewing
<nij>So I should no longer use (native-inputs `("cmake" ,cmake))?
<nckx>Since it's a build script, I think it's OK to ‘bundle’ it.
<nckx>nij: Probably not. If you use the cmake-build-system I don't think it was ever needed anyway.
<BlackMug>Hi There
<nckx>Hi BlackMug.
<BlackMug>is there a way to disable generations/cache and just keep the latest updated version of the package?
<nij>Here's the full hint! https://bpa.st/I3RQ
<nckx>Run ‘guix gc -d 1s’ everytiem.
<nckx>BlackMug: ☝
<BlackMug>nckx yes by this is not practical
<nckx>Then no.
<nckx>That's the answer: make new gen, switch to it, delete old.
***leoprikler_ is now known as leoprikler
<nckx>nij: Eh, did you get this from the start? That would have been handy to have...
<BlackMug>example package version 1 , new version of package lets call 2 -> upgrading the package to version 2 and either replacing 1 or removing it after finish
<nij>Hmm.. I'm sorry I'm not pretty sure.. this is my first time.
<nij>The whole log is huge.
<nckx>It would've saved me 5 minutes of work but it's OK.
<nckx>So (recursive #t) didn't help? Could you share your complete package definition so far?
<nckx>(Pasty bin, of course.)
<nij>I'm sorry.. Yes!
<nij> https://bpa.st/76PQ
<nckx>BlackMug: The current generation points at 1, then you build or substitute 2 into the store, then a new generation is created that points to all other packages + 2, then that generation is made the current one. Deleting the previous generation and any store items that aren't referenced by the new generation (or others) is excatly what ‘guix gc -d 1s’ does.
<nckx>nij: Thanks.
<BlackMug>nckx there is another command which delete all generations
<BlackMug>one sec let me find it
<nckx> https://paste.debian.net/plain/1194095
<nckx>I think this is truly my first time using recursive? #t (!) so I'm not sure what that means.
<BlackMug>sudo guix system delete-generations
<nckx>Do we not trust redirections?
<nij>But that seems we are making progress, nckx.. lemme see what log I get. Thanks :)
<nij>Hmmm.. I'm getting a similar (if not the same log). By the way, the command I ran was `guix package -L ~/pkgs -i ibus-chewing`
<nckx>BlackMug: My mistake for interpreting your mention of ‘packages’ to mean ‘user-installed packages’. ‘guix system delete-generations’ deletes system generations only. guix gc -d deletes user generations only. Different things.
<mdevos>nckx: Is "hospita (‘host’)" goed?
<nckx>nij: I ran guix build -f FILE after adding ibus-chewing as last line. Both methods are fine and both produce the exact same output.
<nckx>In this case, error output :(
<BlackMug>nckx yeah i meant both needed if someone want to just have the latest version of the packages (user or system) without having any caches to it
<nckx>mdevos: My opinion is the same as y'day: just use ‘computer’ or ‘machine’.
<nij>nckx: But in my method I didn't see it mentioning that it's pulling the submodule.. even after I add recisve? #t
<mdevos>nckx: ok, moet nu wel even wat oude tekenreeksen weer aanpassen
<nij>So I suppose `guix build -f the-file.scm` tells you more. I will now switch to that method.
<nckx>BlackMug: Guix is built around the concept of a cache (the store), it will always follow an ADD → SWITCH → DELETE pattern.
<nckx>ADD → SWITCH [→ DELETE] since it's optional.
<BlackMug>nckx ADD → SWITCH -> Cache [→(manual) DELETE]
<nij>nckx.. ok suppose it did fetch the cmake-fedora submodule.. how on earth would it be smart enough to know that it's what it should use?
<nckx>Could you expand the many ‘it’s? :)
<darth-cheney>Hey all, I have a question about something on the mailing list
<nij>ok suppose guix did fetch the cmake-fedora submodules.. how on earth would guix be smart enough to know that cmake-fedora is what guix should use?
<darth-cheney>I'm interested in picking up on some work that was going on here: https://lists.gnu.org/archive/html/guix-patches/2019-05/msg00685.html
<darth-cheney>But what format is that patch file? How can I get the code from it?
<darth-cheney>(and what is it patching exactly)
<nckx>nij: Guix won't and doesn't need to understand anything. ibus-wotsit's CMakeLists.txt will see that the directory exists and use it, barring bugs/assumptions.
<nckx>BlackMug: No, there isn't a manual ‘cache things’ step.
<nckx>s/manual/explicit/, not even automated.
<nckx>Maybe cache is the wrong word. The store is a garbage-collected heap.
<nij>nckx I see... wow packaging is definitely the hardest thing I've attempted during my learning of computer-ish stuff...
<nckx>If nothing points to an item, that item is dead, and will be removed during GC.
*nij wonders if there's anyone that can start packaging without any guide by real people.
*nckx points at self, (many) others, but it's good that it's no longer the only way.
*nckx has to go AFK again, probably for a while now.
<Aurora_v_kosmose>leoprikler: My client failed to alert me to the answer, sorry back there.
<leoprikler>Hm?
<Aurora_v_kosmose>@ up-to-date vs backporting only CVE patches, what's safest?
<Aurora_v_kosmose>Guix has chosen the up-to-date model, while Debian (Stable) has chosen the latter option.
<Aurora_v_kosmose>And I'm not sure which effectively is the best security-wise.
<leoprikler>Some people in Guix push for the always up to date model.
<Aurora_v_kosmose>Stability-wise Debian's position works better, dev-experience wise, Guix does much better.
<leoprikler>In general, Guix tries to compromise for rebuilds :)
<Aurora_v_kosmose>Yeah, that's what grafts are for.
<leoprikler>Yeah, but grafts like Debian patches often require a backport.
<leoprikler>So Guix' security story is not too different here.
<Aurora_v_kosmose>Mhm. But given CVE publishing is at best a lackluster approximation of the actual security story, one has to presume plain version updating also fixes a number of undisclosed issues
<Aurora_v_kosmose>But at the same time, new versions may introduce new bugs.
<leoprikler>Indeed, that's why I said you're heading into philosophical territory.
<leoprikler>(Also security issues are not the only reason to try to stay up to date, but meh.)
<Aurora_v_kosmose>New features and dev experience, yeah.
<leoprikler>mavi, flatwhatson: I sent the revised wip-emacs patch to the mailing list, you can fetch it from there
*lfam will never tire of the SSH warning "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!"
<lfam>I reinstalled my Guix System computer, so the SSH host keys changed
<BlackMug>Aurora_v_kosmose up to date is safest
<BlackMug>debian is not safer, its just more stable
<nij>Hello! I'm trying to build some package the first time. In the build log, it first complains "[Error] Package ibus is not installed", which seems like a big deal. However, it later says "-- Checking for module 'ibus-1.0>=1.3' -- Found ibus-1.0, version 1.5.22 ".. does that mean the error is resolved? Or I still have to take care of the error?
<Aurora_v_kosmose>BlackMug: Can you expand upon that which allows you to assert so? I do not have a pre-conceived opinion on this, although some irritation that there's very few actual studies on the matter.
<BlackMug>Aurora_v_kosmose debian rely on CVE to fix bugs, does all the bugs gets CVE? No
<BlackMug>i will give you example
<BlackMug>one second
*nckx ret.
<nckx>nij: Does the build continue? I'd ignore it if so, until you run into actual breakage.
<BlackMug> https://forums.whonix.org/t/chromium-browser-for-kicksecure-discussions-not-whonix/10388
<mdevos>BlackMug: is there a policy in Debian for _only_ fixing bugs with a CVE? I would think ‘they’ would fix other bugs as well, no?
<nij>It continues, yes.
<nij>I see, nckx.
<nij>I changed it to version "1.6.1", and it progressed.. with another error ^^
<BlackMug>Aurora_v_kosmose this is long discussion on having chromium from debian
<leoprikler>I don't think that's the case. It's rather that others are even likelier to not get noticed in the first place.
<Aurora_v_kosmose>mdevos: Notification would require individual attention from a particularly attentive maintainer. And I do not know if there is a policy to not backport things which aren't CVE'd.
<nckx>nij: Did you make any progress in my absence?
<raghavgururajan>nckx: Do you know how to nuke the generated certs, privkeys etc. In other words, do certbot fresh?
<BlackMug> https://forums.whonix.org/t/chromium-browser-for-kicksecure-discussions-not-whonix/10388/81 here we see chromium exploited in wide without fixes from debian
<nij>Yes! By changing the version of ibus-chewing to the latest.
<nij>Current def I'm working on : https://bpa.st/RPMA
<BlackMug>mdevos yes as they cant know what the hell is the bug unless there is detailed explanation what it
<BlackMug>what is it*
<nckx>raghavgururajan: I don't, but you can't stop me from randomly guessing. Would this not do the job? rm -rf /etc/letsencrypt/ /var/*/letsencrypt/
<mdevos>BlackMug: detailed explanations don't require CVE's. Though CVE's are of course one possible location of explanations
<raghavgururajan>nckx: I was planning on doing that, was wondering if certbot stored some configs/cache elsewhere.
<nckx>raghavgururajan: But remember that the Let's Encrypt service is quite strictly rate limited with absolutely no exceptions.
<BlackMug>mdevos thats only the authentic way of doing it
<raghavgururajan>Yeah.
<nckx>Don't ‘refresh’ for the hell of it or you'll find yourself without certs sooner than most expect.
<nckx>OK‌ :)
<mdevos>BlackMug: What is this ‘authentic way’?
<nckx>I'm not aware of any more locations, that's all I can say raghavgururajan.
<BlackMug>mdevos having CVE for the bug
<raghavgururajan>No worries!
<nij>nckx.. currently the log file gets to ~800 lines instead of ~300. There are many errors, and it wasn't clear to me what was the actual failing point. I decided to fix them one by one.
<nij>Log file with Error (huge!) - https://bpa.st/KWJQ
<mdevos>Myself, I would never bother with allocating CVEs. When I'm a maintainer of Z, I would rather just send a mail to the maintainer of the package in ‘all’ the distributions that package Z.
<mdevos>here, ‘all’ = Debian, Guix, Fedora, $LOOK_AT_LWN_FOR_MORE, $LOOK_AT_WIKIPEDIA_FOR_MORE, $LOOK_AT_SEARCH_MACHINE_FOR_Z
<mdevos>maybe I should bother though
<BlackMug>yeah nothing will be done
<BlackMug>the maintainers will ask you to please work on adding it to CVE
<lfam>Howdy
<lfam>How is pre-release testing going? :)
<lfam>Did we find any bugs yet?
<BlackMug>lfam there is pre-release?
<Aurora_v_kosmose>New Guix release incoming?
<BlackMug>and when is the stable release gonna be out?
<lfam>Yes, tomorrow we are planning to release 1.2.1
<nckx>nij: I do not think the build is parallel-safe. By which I mean: it aborts for both of us because ‘gob2’ doesn't exist, but ‘gob2’ appears to be something that should be built by the package itself. Adding #:parallel-build? #f to arguments causes a different error (missing xgettext) which could confirm that hypothesis.
<nckx>Maybe later, some say.
<lfam>You can test the installer images, downloadable here (select the "iso9660-image" for your system): https://ci.guix.gnu.org/eval/22915
<nckx>☝ 1.2.1
<BlackMug>lfam great!, cant wait for testing hope there are worth features added to guix
<nckx>But perhaps it was just idle chit-chat. 🐈
<Aurora_v_kosmose>Is installation on foreign systems going to change much?
<lfam>No Aurora_v_kosmose
<lfam>We have fixed some bugs in the installer script but it's largely the same
<BlackMug>only?
<nckx>Aurora_v_kosmose: No, and if you guix pulled this week, version 1.2.1 won't be ‘new’ at all. It's more a better-tested snapshot of a rolling release.
<lfam>You can test the binary installer process using these: https://ci.guix.gnu.org/eval/22918
<nij>nckx: On my current file, that xgettext is missing was already complained. SO I think adding #-parallen-build? #f is making a progress. Lemme do that.
<mdevos>BlackMug: that sounds ... broken. I'm not on that list of ‘the maintainers’.
<lfam>And, for installing Guix on other distros or Guix System itself, follow the instructions in the "devel" manual: https://guix.gnu.org/manual/devel/en/html_node/
<BlackMug>mdevos debian has their own trusted "sorta" package maintainers, not anyone can be a package maintainer within debian
<nckx>nij: It's also possible that it just postpones the gob2 error until later. Still, one error at a time is nice too.
*nckx add gettext-minimal to native-inputs to squish this one.
<nckx>Yep, back to gob2 we go. What the flip.
<nij>:-( so parallel-build=#f not workin'?
<BlackMug>lfam nice thanks for the links
<nckx>nij: It is, but it wasn't the solution.
<Aurora_v_kosmose>lfam: Has the script's actions changed much?
<nckx>gob2 (‘gob’) is an actual thing that will need to be packaged.
<nij>How did you know that gob should be self-built? GOB is included as a dependency in the official INSTALL guide. https://github.com/definite/ibus-chewing/blob/master/INSTALL
<nckx> https://www.jirka.org/gob.html
<nckx>nij: I was probably mistaken.
<nckx>Yep, I was.
<nckx>I read grep output without context. Tickle me.
<Aurora_v_kosmose>In other news, I just realized my efforts to add deployment of new Guix foreign systems on my LAN to my configuration management system have been completely useless because it contains an "expect" module that could just use the Guix script directly.
<mdevos>BlackMug: what are you trying to say? That debian maintainers only fix issues that have a CVE, or that I used incorrect terminology (‘Debian developer’ or something), or ...
<nckx>nij: You'll have to write a ‘gob’ package first. That's how things go, I'm afraid.
<BlackMug>mdevos yes only with CVE
<mdevos>if you have questions (/ complaints?) on how Debian fixes security issues, ask them on #debian <https://wiki.debian.org/IRC>
<nij>nckx oops
<lfam>Aurora_v_kosmose: You can look at the changes here: https://git.savannah.gnu.org/cgit/guix.git/log/etc/guix-install.sh
<nij>so i can take paralle-build? #f away, right?
<nckx>I've heard that claim before (‘Debian won't fix your V without a CVE’) but apart from sounding bullshit it's been denied by people who, whilst not DDs themselves, ought to know.
<nij>(And by the way, is this the right way to add gettext-minimal? ::
<nij> ("gettext" ,gettext-minimal)
<nckx>nij: Yeah, if you don't mind more chaotic build output.
<nckx>Yep.
<Aurora_v_kosmose>lfam: I was thinking I'd have to update my setup to follow the changes, and finally just got that I never really needed to do it that way.
<mdevos>in any case, we're getting off-topic here, so let's stop the discussion here
<nij>nckx: we do have gobject-introspection.. that seems pretty close to gob
<Aurora_v_kosmose>ooh, it now autodetects KVM
<BlackMug>mdevos i know debian more than any other distro, im contributor to one of debian derivatives distros so i know these things im not guessing them.
<Aurora_v_kosmose>BlackMug: That would leave a worrying amount of vulnerabilities just lying around then.
<BlackMug>Aurora_v_kosmose dah exactly
<mdevos>BlackMug: I'm on irc.debian.org#debian now
<BlackMug>mdevos better ask in security , apt room because debian alone is general room
<lfam>Hm, we need to fix this: <https://bugs.gnu.org/47841>
<lfam>That's a release blocker
<mdevos>BlackMug: can we continue this in #debian-security?
<BlackMug>no, i have stored conversation between me and devs in debian security, if you like i can share it with you but no time going there and do anything
<Aurora_v_kosmose>BlackMug: mdevos: I'm also interested.
<mdevos>BlackMug: sure, post a link
<mdevos>BlackMug: but you do seem to have plenty of time to discuss this, so I don't why we couldn't go to #debian-security
<Aurora_v_kosmose>On freenode, yes?
<mdevos>No
<BlackMug>waste of time my friend to something i know the answer to
<mdevos> <https://wiki.debian.org/IRC>
<mdevos>on irc.debian.org (alias for irc.oftc.net)
*Aurora_v_kosmose was not sure they still had a functional TorOftc config
<nij>nckx: I agree. I need to build gob2 first for guix.. It doesn't seem too complicated (at least for archlinux: https://github.com/archlinux/svntogit-packages/blob/packages/gob2/trunk/PKGBUILD)
<nij>I'm not sure which fetch method I should use though. It's not hosted on github.
<nckx>That sentence saddens me.
<nckx>nij: url-fetch, url "http://ftp.5z.com/pub/gob/gob2-2.0.20.tar.gz" :)
<nij>Which sentence?
<apteryx>is there a way to force re-running a system test without having to introduce a change in the test gexp?
<nckx>Honestly? Most sentences matching the regex *github*.
<nckx>+.
<nckx>Shit.
<nij>nckx: sorry again xD
<BlackMug>Aurora_v_kosmose mdevos check your pms i sent to you the conversation
*nckx hands back nij's sorry for when it's really needed, like when they mention Go.
<lfam>Hm, based on the status of <https://bugs.gnu.org/47297>, I wonder if it wise to make a release tomorrow
<lfam>It looks like we still have some serious bugs
<lfam>nckx, apteryx: WDYT?
<BlackMug>lfam just pretend that you never said there will be any release coming soon...
<pkill9>does guix still prefer tarball resleases over git
<raghavgururajan>nckx: In past, your website use to only show a owl logo at the center. Do still have that html file?
<nij>nckx how about java script?
<mdevos>BlackMug: where/when did that discussion happen? I can't find in on the web.
<pkill9>because git references let you use branches
<lfam>It's up to the person writing the package, pkill9.
<pkill9>and pull latest comit
<raghavgururajan>I would like to put some other logo for my website.
<lfam>pkill9: Our guidelines are that we package things that upstream aims to "release". So, in most cases we won't accept packages that just use the latest commit
<Aurora_v_kosmose>mdevos: BlackMug: Thanks. And it probably happened in private.
<lfam>Some upstreams don't make releases, and that's a different story
<pkill9>lfam: i don't mean using the latest commit, i just mean using the git source
<pkill9>with the release tag
<lfam>Sure
<lfam>Use your judgement
<BlackMug>mdevos 29/06/2020 , on room #debian-security on OFTC , check if you can view the archive on that date
<pkill9>because then you can use --with-branch=master to get the latest commit
<mdevos>BlackMug: thanks
<nckx>BlackMug: I've been unable to connect to OFTC for several weeks. I gather you can?
<nckx>Damn, that means it's my problem now.
<BlackMug>nckx yes i can
<BlackMug>why you cant?
<Aurora_v_kosmose>nckx: May I recommend trying to connect to it over Tor? It works for me.
<BlackMug>nckx im using it over tor , it works for me
<nckx>BlackMug: https://paste.debian.net/plain/1194099 - so yeah, it's probably a problem on my (Guix System) ZNC box, but I kept hoping it was OFTC. Only happens there, as is obvious by my presence.
<nij>nckx!
<nij>nckx!
<apteryx>lfam: would you mind if we I tagged the blocking bugs via debbugs user tags with v1.3.0 to mark the blocking bugs? It'd allow us to get a clear listing (in one buffer) of what's remaining. Unless you know how to do that currently?
<nij>I just built my first package in muh life :D
<nckx>nij: <how about java script?> Oh, you'll need more than a sorry for that, friend.
<nckx>nij: \o/
<avalenn>how can I select with guix install between two packages which have same name and version on two different channels ?
<nckx>🚀
<nckx>This calls for actual Unicode.
<BlackMug>nckx you should always believe first its guix issue until you can prove its not ;)
<nij>gob2 - freshly baked - https://bpa.st/4ZAQ
<nij>It's a noob-level package. But I don't care.
<Aurora_v_kosmose>🚀
<lfam>apteryx: The blocking bugs are listed in this ticket, whose purpose is to collect them: <https://bugs.gnu.org/47297>. I don't know how to use user tags
<nij>Now I can build ibus-chewing.............. but how? Should I put gob2 to the guix official channel first?
<nckx>Aurora_v_kosmose: Thanks for the suggestion. The same box actually already runs a Tor node, so it might not be that hard.
<Aurora_v_kosmose>They don't, afaik, have a different URL, they just autodetect the exit-node connection.
<Aurora_v_kosmose>And then they cloak it.
<nckx>nij: For now, paste a copy of (define-public gob2 ...) above (define-public ibus-chewing ...) and use it that way.
<apteryx>lfam: OK, let me try something, if it works I'll share the command to get the buffer view I have on mind.
<lfam>Cool
<nckx>raghavgururajan: May I ask why?
<lfam>What do you think about my concerns, apteryx?
<lfam>I wonder if we've really done enough testing, if people are experiencing bugs like those
<nckx>The logo itself isn't mine, but selfishly I still don't want others to use it.
<avalenn>answering myself : guix package -e '(@ (gnu packages finance) beancount)'
<lfam>Maybe we should issue a release candidate and give ourselves another week
<mdevos>it seems there aren' any public logs for debian-security. In any case, in the quoted discussion, it was never said CVE's are required. The problem was that the vulnerabilities weren't documented (and hence the debian developer/maintainer didn't know about it, and couldn't fix it). Documentating vulnerabilities can be done without CVEs. CVEs are ‘merely’ a somewhat standard way to do so.
<nckx>lfam: https://logs.guix.gnu.org/guix/2021-04-17.log
<nckx>No anchor needed :)
<apteryx>lfam: I think it may be wiser to delay it a bit. Perhaps freeze what we have in a separate branch to avoid keeping master in a undefinite string freeze?
*mdevos won't post more on this off-topic
<lfam>Alright
<apteryx>then we can cherry pick just the fixes to the blocking bugs
<lfam>Yeah
<nckx>mdevos: Don't feel obliged. It's not *that* off-topic.
<lfam>I think that, in the past, we've tagged RCs
<lfam>We can branch and tag
<nckx>Yes.
<nckx>IMO, please do.
<nij>making lots of progress! this time the log file is twice as long
<nij>cd /tmp/guix-build-ibus-chewing-1.6.1.drv-0/build/bin && G_MESSAGES_DEBUG=all glib-compile-schemas /tmp/guix-build-ibus-chewing-1.6.1.drv-0/build/bin
<nij>/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/sh: glib-compile-schemas: command not found
<nij>make[2]: *** [bin/CMakeFiles/schemas_gsettings.dir/build.make:62: bin/CMakeFiles/schemas_gsettings] Error 127
<nij>
<nckx>This is not release-ready.
<lfam>Is there a special type of tag we are supposed to use?
<nij>Oopps.. longer than i thought.. sorry i will use paste bin next time
<mdevos>nckx: it's not just the off-topic, it's also that I want to something else now
<lfam>I know that Git tags are more complicated than they seem
<Aurora_v_kosmose>It's somewhat off-topic, but logs of Guix's security model advantages over others are worth it.
<nckx>nij: Add ("glib-bin" ,glib "bin") to native-inputs.
<apteryx>lfam: they should just be signed; that'll take care to make them annotated as well
<lfam>Okay
<apteryx>I'll create the branch from master now
<raghavgururajan>nckx: I would like to do the same on my website. I don't need your logo. Just the html code. :)
<lfam>Okay apteryx
<nckx>nij: This is currently ‘you need to know, and you will, eventually’ stuff. Some day we'll have a package file search but that is not this day.
<nij>nckx: what do you mean?
<apteryx>I'll call it 'version-1.3.0', unless there was a good reason to go with 'version-1.2.1'.
<nckx>nij: Knowing that glib-compile-schemas missing means you have to add glib:bin.
<nij>The hint you provided just now is beyond my comprehension for now?
<lfam>As you see fit, apteryx :)
<nij>oh..
<nij>Oh my machine is spinning :) can feel the heat
<nij>and ... crash
<nckx>nij: I meant you're not expected to know that without asking someone or running ‘find’ on /gnu/store.
***ae is now known as Guest87989
<nij>40% tests passed, 3 tests failed out of 5
<nij>At least I passed 40% of it :)))
<nckx>My thoughts exactly.
<Noisytoot>nckx, I couldn't get certfp to work with OFTC
<nckx>nij: I'll let you handle it but pastepost the output if you're really stuck.
<nij>The part that starts from the test - https://bpa.st/DQYA
<nij>sure
<lfam>What should we do about the nascent ungrafting branch, apteryx?
<apteryx>lfam: OK, the branch version-1.3.0 has been created. I'll message guix-devel to let them know we can lift the string freeze on master
<nij>lemme figure it out
<nckx>Noisytoot: That might be it! My ZNC config is positively ancient, I don't remember what it says at all.
<lfam>civodul suggested we try ungrafting the simple grafts pre-release
<apteryx>lfam: I'd roll them in that version-1.3.0 branch, if you are confident they don't cause breakage
<Noisytoot>nckx, So I use *perform to connect using a different nick, use NickServ identify, then change my nick
<lfam>Even though these are the simpler grafts (just a patch or two, or an update of well-behaved packages like openssl)
<lfam>I'm still somewhat wary of throwing in such big changes at the last minutes, but civodul thought it was important
<lfam> https://ci.guix.gnu.org/jobset/ungrafting
<lfam>All these grafts really kill performance of package operations, especially on spinning disks
<lfam>I don't know
<nckx>Noisytoot: Thanks!
<apteryx>lfam: I agree!
<raghavgururajan>nckx: Never mind! I managed to set it up. :)
<apteryx>lfam: I'd say it's OK to try them in version-1.3.0, if something goes wrong we can revert.
*nckx puts on gas mask & opens znc.conf.
<apteryx>the only thing I wasn't sure about a branch like this is how to hook up the CI so that it builds it
<Noisytoot>What's the point of making releases if Guix just uses the latest commit?
<lfam>apteryx: civodul added the 'ungrafting' job in just a few minutes the other night, so I don't think it will take too long to add the new RC job
<apteryx>Noisytoot: for the installation images, mostly
<apteryx>OK
<lfam>I looked in maintenance.git on Berlin but I don't see how the ungrafting job was added. Maybe it was done directly via the psql client
<lfam>And that is something I don't know how to do
<nckx>Noisytoot: Ideally, releases are known-good commits tested by actual humans on real and varied hardware, that we can then leave on the Web site until the next release. Apart from that: publicity.
<nckx>It's mainly about the installer working well. Nobody's expected to keep running 1.3.0 *after* installation.
<nckx>In fact it's not recommended.
<nij>How to settle this error while building? -- GLib-GIO-ERROR **: 18:05:16.576: Settings schema 'org.freedesktop.IBus.Chewing' is not installed
<nij>
<nckx>Hm, OFTC is the only network *without* a TrustedServerFingerprint.
<nckx>nij: Try adding gsettings-desktop-schemas to inputs?
<nckx>Is this during the build or check phase?
<nckx>I assume check.
<nij>test face
<nckx>Face tested.
<nckx>I failed :(
<nij>lol
<apteryx>lfam: do you use Debbugs in Emacs?
<lfam>No, I don't use Emacs at all
<lfam>I just never learned
<nij>gasp
<apteryx>OK! Hm, that may make the usertags less useful.
<nij>lfam how do you type?
<lfam>I push the keyboard with my nose
<apteryx>until MUMI can make use of them
<nij>lfam: that makes sense. emacs is bloated.
<lfam>That's never something that's bothered me
<nckx>I read that as ‘with my mouse’. 🤭
<nckx>Dunno why that made it even funnier.
<lfam>apteryx: If the usertags help you, then set them up. For me, using the debbugs blocking mechanism, as we've been doing with #47297, works well enough
*nckx has kicked nij from #guix (lies)
<nij>I added in inputs - ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
<nij>but the same error persists
<roptat>YES! FINALLY! my armhf server booted on Guix
<BlackMug>nij bloated but its features exceed any known text editor
*nij wonders why nckx and other hackers know what to try
<nckx>nij: Bleh, you might need to do stuff that's neither fun nor easy to explain over the phone. Worse, I have to go AFK again. TTYL.
<apteryx>lfam: so what I'm doing in debbugs is I visit the blocking bugs with M-x debbugs-gnu-bugs RET 47841 RET, then while reading the bug I press C usertag -> user: guix RET -> tag: v1.3.0 RET
<nij>BlackMug: how about VSCode?
<lfam>apteryx: I see. I just use the website
<nij>nckx: ttyl~
<lfam>And the email commands
<BlackMug>nij cant match emacs
<apteryx>later I can consult the list of tagged items for v1.3.0 by doing M-x debbugs-gnu-usertags and choosing 'guix v1.3.0'
<lfam>I'd prefer if, for this release, you stuck to the method we've been using so far
<lfam>Assuming it's "one or the other"...
<nij>BlackMug: I'm not sure if there's anyone that knows both emacs and VSCode so deeply to judge.
<nij>But my intuition chooses emacs :D just becuase it's lisp
<apteryx>usertags can be added independently of the blocking mechanism used so far
<BlackMug>nij good
<nij>Hello! I'm almost done packaging this baby - however, I'm stuck at testing phase. 40% has passed. Now in the official INSTALL instruction, it says we need to `make install_schemas`. However, there's no makefile in the repo.. how would I know what `make install_schemas` does? https://github.com/definite/ibus-chewing/blob/master/INSTALL
<nij>BlackMug: https://www.youtube.com/watch?v=8kCd4w4kc68
<nij>Title - 10 years of love for Emacs undone by a week of VSCode
<apteryx>lfam: ah, I just found a much easier way that works with the current scheme (blocking bugs); in Debbugs, you press 'b' on the 47841 report; it shows a listing of all currently opened issues blocking it
<BlackMug>i would have discuss this further but this is not the right room nij
<apteryx>this is what I wanted to see
<nij>BlackMug: that's just a joke. But yeah, sorry folks.
<apteryx>lfam: it looks like this: https://paste.debian.net/1194103/
<lfam>I see, apteryx. That list looks stale to me
<apteryx>some are already closed in that list though
<lfam>Right
<lfam>The blocking mechanism lets us check things off the list
<lfam>Anyways, if the usertags are useful for you, please use them. But it would be great to also use the blocking, so that non-Emacs users can participate
<apteryx>ah, only the top ones are unresolved: https://paste.debian.net/1194104/
<apteryx>lfam: yep
<lfam>I wonder what's happened to the binary tarballs (#47841)
<lfam>What changed to cause them to break
<lfam>I even tested this the other day and it worked fine
<lfam>I think that roptat reported this previously
<roptat>reported what?
<lfam>Problems with the binary installer
<lfam>Right, I found #47734
<lfam>I guess that my tests were bogus
<roptat>ah, #47734 is with the tarball for 1.2.0
<roptat>#47841 is with the latest tarball built from the ci
<roptat>in both cases with the latest script
<lfam>But, you had trouble with 1.2.0, and I could not reproduce it
<lfam>So, somebody's tests are wrong
<lfam>It would be great to clear that up
<roptat>yeah, my system might have been in a weird shape, not sure
<lfam>I added 47734 to the release blockers.
<lfam>I guess we have quite a bit more testing to do
<roptat>it was a brand new fedora system, whose /home (and maybe /root, but I'm not sure) was copied from another machine that had guix installed
<lfam>Oh
<lfam>On Debian, /root is not part of /home, but maybe it's different on Fedora
<lfam>Usually it's part of /
<roptat>#47841 is a release blocker, #47734 is about the previous release, so not a blocker
<roptat>I can try to install guix again on a new Fedora VM
<lfam>I know that it's about the previous release, but it was with the current install script
<lfam>It could be a bug in the script, and that's a blocker
<roptat>/root is separate, it's not part of /home
<roptat>let me try again, we'll see if I can still reproduce the issue ^^
<lfam>Okay, thanks
<lfam>I'll reproduce #47841 while you do that
<lfam>I'll do it in a Debian ISO
<roptat>sure, I reproduced on fedora and xubuntu (VM)
<lfam>Maybe there is something different about how CI is created these tarballs, idk
<lfam>s/created/creating
<roptat>yeah, maybe
<roptat>is there another way to obtain these tarballs?
<roptat>could we make a RC available?
<lfam>Well, I already downloaded the tarball to check, and it is missing the current-guix stuff
<lfam>Yeah, it would be good issue RCs
<lfam>Good to issue RCs
<lfam>I don't know how to do that
<apteryx>roptat: I'll give it a try with 'make release'
<lfam>Thanks
<roptat>I think someone needs to run make release and publish the result on alpha.gnu.org or something
<roptat>you'll need a .tarball-version (or .version, not sure I have both ^^')
<apteryx>yep, civodul gave me access to it so if 'make release' goes though I should be able to do so
<roptat>it would contain 1.2.1-rc1
<roptat>great!
<lfam>How to make the tarball "by hand": https://git.savannah.gnu.org/cgit/guix.git/tree/Makefile.am#n739
<lfam>roptat, apteryx: You should make sure you are on the same page regarding the version number
<lfam>apteryx was thinking of doing 1.3.0. roptat, is that a problem for translation?
<roptat>not at all
<roptat>I thought we were doing 1.2.1
<apteryx>I just feel 1.2.1 sends a too conservative message about the changes in that release
<roptat>ok, whichever is fine with me
<lfam>Then it's settled
<roptat>oh, when we update the website, make sure to update the pot file too!
<roptat>although, I don't think we have 1.2.0 as part of the strins, so that might be fine
<roptat>strings*
<nij>Does anyone know any hint to resolve this error I got from building (test phase)? :)
<nij>GLib-GIO-ERROR **: 18:29:16.961: Settings schema 'org.freedesktop.IBus.Chewing' is not installed
<apteryx>lfam: I've sent the email advertising the lift of string freeze for the master branch to guix-devel
<lfam>Thanks apteryx
<lfam>I kept a list of pending patches for after string freeze
<lfam>I'll reply with the list
<mdevos>in a build environment, PATH only contains inputs from 'native-inputs' (& implicit), and no inputs from 'inputs', right?
<roptat>lfam, I managed to install guix on the fedora VM, so that might just have been the system that was in a weird state
<roptat>however, I get: systemd[29912]: guix-daemon.service: Failed to execute command: Permission denied
<lfam>Huh
<lfam>It lacks to permission to start the daemon?
<lfam>No mdevos
<roptat>oh! selinux maybe
<lfam>mdevos: All the inputs will be available. Everything with a 'bin/' or 'sbin/' directory will be on PATH
<mdevos>lfam: I'm considering a cross-compilation scenario here
<roptat>that was it
<lfam>I don't have experience with cross-compilation. Hopefully someone else can answer your question mdevos
<lfam>Good news regarding #47841, roptat. When I build the tarball in the same way as `make release`, it includes the correct directories. So, it's a problem with the CI job, IIUC
<roptat>lfam, great!
<lfam>I'm going to try using the tarball in the ISO now
<roptat>thanks
<mdevos>I think (when cross-compiling) PATH only has stuff from native-inputs
<roptat>mdevos, I think so too
<mdevos>This seems to confirm: <https://issues.guix.gnu.org/18895>
***abogado is now known as dmt
<lfam>Editing guix-install.sh for testing is so annoying
<lfam>I'm not sure I have the patience for that
<xkcn>Sigh.
<xkcn>How to go from 'hm this ball game sure needs working sound' to 'welp my initrd can't mount / now' in 27s.
<xkcn>Let me whisper you how.
<dmt>how
<xkcn>In other news Debian live images are 3 GiB now, which is as large as a Guix installer + GNOME, so that's acceptable now and something we should consider.
<lfam>Some of them are <1 GB, like the "standard" image
<xkcn>But they don't have gnomes.
<lfam>No, it's "headless"
<xkcn>I just mean I added GNOME to an installer last year, saw thath the result was 3G, thought 'well that's clearly ridiculous and due to Guix's wayz' but no, it's nomral.
<lfam>I give up on altering guix-install.sh to use a different tarball
*xkcn typing on a Belgan keyboard ejoy
<lfam>roptat: I sent an email asking for the same, but you can share your diff on guix-install.sh? I can't make it work to use a different URL for the tarball
<xkcn>dmt: type 'reboot', apparently.
<nij>Hello! I'm trying to build with cmake. On archlinux, the command was `cmake -B build -S . -DCMAKE_INSTALL_PREFIX=/usr -DLIBEXEC_DIR=/usr/lib/ibus`. I wonder what's the right equivalents for guix.
***ae is now known as Guest81282
<Noisytoot>Debian live images being 3 GiB doesn't mean that's acceptable
<Noisytoot>It's far too large
<Noisytoot>I don't think GNOME is necessary in an installer
<Noisytoot>If you want a desktop environment, use a more lightweight one (for an installer image)
<xkcn>Noisytoot: Acceptable *for a GNOME image* that is. Are there significantly smaller ones? I couldn't care less about other desktops. Last I informally polled GNOME was the most used & installed DE amongst Guix System users.
<xkcn>Those concerned about size can always use the non-GNOME one. It won't go anywhere.
<gr0n>i mean there's also a guix minimal image so...
<gr0n>you don't really need to install the gnome one
<xkcn>Exactly.
<roptat>lfam, http://paste.debian.net/1194115/
<mdevos>I've a bug to report, and a patch to fix it.
<mdevos>Logically, they should go to bug-guix@ and guix-patches@
<xkcn>No.
<mdevos>xkcn: is that a response to me?
<xkcn>Just guix-pathces
<xkcn>Yes.
<xkcn>How can you type on this layou mdevos. :)
<lfam>Thanks roptat
<mdevos>xkcn: is that belgian-alternative?
<lfam>I'll try again
<mdevos>is nckx=xkcn?
<xkcn>I'm not sure, it's belgian-borrowed. What's alternative about it?
<xkcn>Yes it is.
<mdevos>belgian-alternative == azerty + ??? + fancy Unicode
<mdevos>fancy Unicode: alt-gr + F = ‘
<mdevos>Alt-gr + shif + die 1 toets bovenaan = ≥
<mdevos>and more things like that
<xkcn>Apparently this isn't Belgian but Frans (AZERTY). I'll have words with the owner that this is unacceptable.
<Noisytoot>The owner of what?
<xkcn>Thislaptop.
<mdevos>there are some subtle differences between Belgian and French keyboards. THe letters are at the same places, but alt-gr behaves differently or something
<mdevos>xkcn: is this your own laptop
<Noisytoot>Are you going to have words with yourself?
<xkcn>No, $partner's, which I'm using to run Putty to SSH into a headless GNU/Linux box to build a Guix installer image because mine won't boot. A very normal thing to do.
<Noisytoot>xkcn, You can change the keyboard layout
<xkcn>I'm doing just that!
<Noisytoot>What happened to yours?
<Noisytoot>How did you get it to not boot?
<Noisytoot>Did you run rm -rf --no-preserve-root /
<Noisytoot>?
<xkcn>I am, how must I put this, severely unfamiliar with this OS.
<xkcn>Installing my keyboard layout means downloading executbales from the Web etc.
<xkcn>Great fun.
<xkcn>Noisytoot: Worse, I ran 'reboot'.
<xkcn>Now I know while all GNU/Linux users boast such uptimes.
<xkcn>It is fear.
<mdevos>xkcn: I never edit my bootloader configuration if I can help it
<xkcn>I didn't :'''(
<mdevos>when I got this laptop, it had $PROPIETARY installed
<mdevos>I was locked out of the BIOS configuration (laptop was second-hand)
<mdevos>or UEFI, whatever
<mdevos>and the BIOS / UEFI / whatever was not configured to boot from floppy / USB / CD
<mdevos>so I got to boot into $PROPIETARY, exploit a security flaw to get the equivalent to 'root'
<mdevos>(The laptop didn't receive updates in a looong time)
<mdevos>and run some program that installs bootable images onto hard disks
<Noisytoot>I installed libreboot
<mdevos>The installation had to go right in one try, otherwise I would end up with a bricked laptop. Luckily, things went well.
<xkcn>mdevos: Holy Gatesballs that's 1337.
<xkcn>I'm supremely interested in which flaw that was for, ehm, liberational reasons.
<mdevos>lemme see if I can find it
<mdevos>it was a flaw in ‘Windows Vista’ IIRC
<pkill9>nice
*xkcn just barely succeeded in installing an EXE but can now at least type at human speeds.
<Noisytoot>Why are you using Windows?
<xkcn>Because I once insulted a gnome and was cursed.
<xkcn>But also because $partner hard-needs this +&{@ 'OS' to receive her diploma.
<xkcn>Don't bother questioning this, I've tried, it's how it is.
<Noisytoot>Did you insult GNOME?
<bdju>how does system logging on guix work? does shepherd handle it? a friend is used to journalctl and I don't know an equivalent.
<xkcn>Noisytoot: Probably, the last time I tried to use it, yes.
*xkcn just shrunk the system partition by 50% and is going to do something very enjoyable to the remaining 50
<Noisytoot>xkcn, Is that on the Windows computer?
<xkcn>Yes.
<Noisytoot>Are you going to install Guix on the other 50%?
<xkcn>I hope it can dual boot? I didn't technically ask permission. Forgiveness is Free.
<xkcn>Ding ding ding.
<xkcn>(That's a yes.)
<xkcn>Otherwise, honestly, diplomas are overvalued anyway.
<civodul>leoprikler: hi! do you think https://issues.guix.gnu.org/47539 is ready for inclusion?
<mdevos>xkcn: I managed to accidentally delete the ‘Windows’ partition on each of my laptops
<xkcn>Curious how that happens.
<mdevos>it really was an accident (but nice)
<xkcn>I have the same problem.
<xkcn>Oh :)
<Noisytoot>Can't she use wine?
<mdevos>not paying close attention to the ‘partition configuration’ menu
<mdevos>xkcn: sorry, I can't find the exploit anymore
<mdevos>It basically went like this:
<mdevos>boot into some kind of ‘safe’ mode, using F8 or something
<mdevos>at some point Windows explorer is launched (IIRC)
<mdevos>(the rescuer has a ‘save’ button or something for log files)
<mdevos>replace Magnify.exe with cmd.exe
<mdevos>now, reboot
<xkcn>Noisytoot: So her school basically mandates running spyware during on-line exams ('due to COVID'). I don't want to discuss that fact (of course it's unacceptable, of course I've embarrased her by 'talking' to people, ...), it just does. I am 100% certain that spyware won't run under Wine.
<xkcn>mdevos: Thanks!
<xkcn>Noisytoot: It's nasty stuff.
<mdevos>when in the login screen, start the magnifier. There's a button on the bottom-right somewhere, or a keyboard combination
<mdevos>--> now you have a shell
<Noisytoot> https://my.fsf.org/give-students-userfreedom
<mdevos>Warning:
<mdevos>the login screen will spontanuously dissappear
<xkcn>Noisytoot: Yes, things like that. I've made myself very popular with the poor receptionist :)
<bandali>speaking of education and (resisting) nonfree software, new article by a polish student: https://www.gnu.org/education/how-i-fought-to-graduate-without-using-non-free-software.html
<xkcn>I say 'basically mandates' because of course she's also free to suspend her education for 2 (so far) years until she can take regular exams again. It's a choice! They're not *monsters*.
*xkcn scrighs.
<Noisytoot>scrighs?
*xkcn scrugs.
<xkcn>ISO 77% downloaded, 31 minutes remaining.
<xkcn>mdevos: Any ideas for 'hackable'?
<mdevos>sleutelbaar?
<mdevos>dat heb ik eens gebruikt
<efraim>civodul: there's a hurd-target? in gnu/packages/hurd that would also work for #:tests in util-linux
<xkcn>That's better than my 'maakbaar' or 'aanpasbaar'.
<xkcn>Ta.
<xkcn>('Maakbaar' is OK, but I can't hear it without adding 'samenleving'.)
<nij>Hello #guix! I'm trying to package but failed on my second one. Is there anything that I should read at this point? For example, I still don't know how to modify phases. Maybe I should read and learn that before I do?
<xkcn>mdevos: Sorry for backtracking but I'm reluctantly going for maakbaar. Sleutelbaar is too unique (bedoelde je: sleutelbaard) and doesn't feel grammatical.
<nij>Or maybe I should start with the tools I'm more familiar with (emacs and common-lisp), instead of c, gnu, cmake.. etc?
<mdevos>versleutelbaar?
<xkcn>nij: Where did you get stuck? Keeping in mind that I can't run any code.
<xkcn>No, that's encryptable.
<mdevos>xckn: waar
<mdevos>klopt, bedoel ik. versleutelbaar = encryptable
<xkcn>And verstelbaar is like... you can tweak a setting.
<mdevos>"hacker" is ondertussen wel ingeburgerd
<xkcn>Yeah
<xkcn>so
<xkcn>we are not putting 'het hackbare besturingssysteem' on our home page.
<mdevos>xkcn: waarom niet (-:. 't Zou voor misverstanden kunnen leiden weliswaar
<xkcn>It's risky enough in English. It hasn't been reclaimed at all in Dutch.
<xkcn>I got kicked out of a promising job interview for having 'I hack things' come up when you searched my name.
<mdevos>the substitute for libreoffice is broken (/gnu/store/6sc2cm5azsr4sdp117rnfxfki569r9s5-libreoffice-6.4.7.2) (for weeks I think, though possibly with a different derivation) -> TLS error in procedure 'read_from_session_record_port'
<mdevos>is this a known issue
<xkcn>Can you download it with cURL/wget?
<mdevos>how can I determine the substitute url
<lfam>Try running your command again, but with -v9
<lfam>It should print the URL
<xkcn>Is it https://ci.guix.gnu.org/nar/lzip/6sc2cm5azsr4sdp117rnfxfki569r9s5-libreoffice-6.4.7.2?
<xkcn>Seem so.
<mdevos>xkcn: yes
<xkcn>It looks intact.
<xkcn>Not 'broken', I mean.
<xkcn>Not saying that Guix isn't throwing that error. *That's* totally plausible.
<xkcn>OTOH, there are other schemes than lzip and I didn't try them.
<mdevos>btw the download gets much slower when at 40% or so
<xkcn>Not here.
*xkcn reboots.
*mdevos leaves