<civodul>i think it's be reasonable to postpone a little bit and have RCs <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 <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 <mdevos>maar het is nu toch al laat (of vroeg?) aan het worden <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? <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? <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]>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, once you made the patch, you can check it's building with ./pre-inst-env guix build foo <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! ***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 <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>I thought we had a string freeze for all domains D: <apteryx>sneek: later tell civodul, thanks that helped :-) <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>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 <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 <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 <roptat>also, guix-packages is ~2500 stings, the manual is ~10000 strings <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>so what did you have in mind when talking about turing completeness' <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 <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 <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 <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]>I think this package is in crates-io.scm <Telc[m]>I have the import right I think """ #:use-module (gnu packages crates-io)" <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? <leoprikler>It does help if you are familiar with the tools themselves. <leoprikler>Particularly when stuff goes wrong and you already know the error. <nij>Do you recommend that I at least package it on archlinux, for example? <nij>cool, i will proceed and have fun :-D <leoprikler>no Debian, Arch or Gentoo-related knowledge needed ;) <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>(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. <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 <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 :) <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. <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' <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 <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>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 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. *raghavgururajan wakes up and rubs his eyes <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 <mdevos>jlicht: dat is nogal een pleonasme. In een restaurant: server == degene die je eten opdient <mdevos>bedieningsserver == bedieningsopdiener <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? *raghavgururajan wants to learn Martian xD <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 :) <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_>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. <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. <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>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>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 :) <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? <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? <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" <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>(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? <leoprikler>mavi: I'm currently building emacs-next on wip-emacs, I'll let you know once I'm finished <mavi>but some guy told me yesterday emacs-next has the same issue. <mavi>so i said that i'm using emacs-next so you guys can see it from official repos. <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" <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. ;-) *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>"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 <leoprikler>mavi: Okay, I think the problem is, that tramp does not find uname <mavi>leoprikler: what should i do then? <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, 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? <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. <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>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. <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 <nckx>another-nick: Do you promise to behave this time, and abide by basic social norms like not circumventing ignores? ***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 :) <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. <leoprikler>mavi: okay, new result, adding coreutils to PATH *does* fix it <roptat>at least the good thing is I know the new u-boot can boot the machine <leoprikler>installing it to your profile won't help you with pure environments ***brown is now known as Guest53609
<raghavgururajan>leoprikler: Oh. I should see certs in /etc/letsencrypt right? after reconfigure? <nckx>Maybe not immediately, see ‘herd schedule mcron’ to see when it's expected to run. But disclaimer & all I don't use certbot. <leoprikler>look in /var/lib/certbot, perhaps stuff is there <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>Do you want to contribute in an atypical manner? <leoprikler>There is a grey area with sending patches as attachments. Humans understand those, but machines don't. <nckx>raghavgururajan: You might get lucky with ‘sudo -i <the command that ‘sudo herd schedule mcron’ says it would run>’. Haven't tried. <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. <nckx>No . but that was probably a typo. <nckx>Otherwise, sure, looks good, try. <nckx>Is that really what the certbot job calls? <nckx>It'll work if you're in /, not otherwise, but just... why. <nckx>> Is that really what the certbot job calls? <nij>sneek, tell nij and it's really "later tell", not "tell" <nckx>sneek is dead and we killed him. <nij>Ok, I finally am starting to package. <nckx>OK, no leading . , good. <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? <nckx>You've made it a dependency of your system configuration, keep them together. <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. *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... <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. <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 <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 <nij>CMake Error at CMakeLists.txt:40 (MESSAGE): ManageEnvironmentCommon.cmake is not found in CMAKE_MODULE_PATH. <nij>This is the only "CMAKE_MODULE_PATH" in the whole log. I didn't set it explicitly either. <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>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) <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. <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>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?!?!?!?! <gr0n>nij: that is my experience with other package systems. maybe guix is better :D <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? <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. <nckx>Build-time download magic ♪ <nckx>Oops, sorry, clipboard still busted. <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>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>is there a way to disable generations/cache and just keep the latest updated version of the package? <nckx>Run ‘guix gc -d 1s’ everytiem. <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>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. <BlackMug>nckx there is another command which delete all generations <nckx>I think this is truly my first time using recursive? #t (!) so I'm not sure what that means. <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>But what format is that patch file? How can I get the code from it? <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. <Aurora_v_kosmose>Guix has chosen the up-to-date model, while Debian (Stable) has chosen the latter option. <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 :) <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 <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.) <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>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 <nckx>nij: Does the build continue? I'd ignore it if so, until you run into actual breakage. <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>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? <nij>Yes! By changing the version of ibus-chewing to the latest. <BlackMug>mdevos yes as they cant know what the hell is the bug unless there is detailed explanation what 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 <nckx>Don't ‘refresh’ for the hell of it or you'll find yourself without certs sooner than most expect. <mdevos>BlackMug: What is this ‘authentic way’? <nckx>I'm not aware of any more locations, that's all I can say raghavgururajan. <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. <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 <BlackMug>the maintainers will ask you to please work on adding it to CVE <lfam>How is pre-release testing going? :) <lfam>Did we find any bugs yet? <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. <BlackMug>lfam great!, cant wait for testing hope there are worth features added to guix <nckx>But perhaps it was just idle chit-chat. 🐈 <lfam>We have fixed some bugs in the installer script but it's largely the same <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. <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’. <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'? <nckx>nij: It is, but it wasn't the solution. <nckx>gob2 (‘gob’) is an actual thing that will need to be packaged. <nckx>nij: I was probably mistaken. <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. <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. <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 <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. <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>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 <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 <BlackMug>waste of time my friend to something i know the answer to <mdevos>on irc.debian.org (alias for irc.oftc.net) *Aurora_v_kosmose was not sure they still had a functional TorOftc config <nij>I'm not sure which fetch method I should use though. It's not hosted on github. <nckx>That sentence saddens me. <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*. <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>It looks like we still have some serious bugs <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. <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 <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 <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 <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. <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 <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. <avalenn>how can I select with guix install between two packages which have same name and version on two different channels ? <nckx>This calls for actual Unicode. <BlackMug>nckx you should always believe first its guix issue until you can prove its not ;) <nij>It's a noob-level package. But I don't care. <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. <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. <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. <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 <apteryx>then we can cherry pick just the fixes to the blocking bugs <nckx>mdevos: Don't feel obliged. It's not *that* off-topic. <lfam>I think that, in the past, we've tagged RCs <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 <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 <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. :) <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 my machine is spinning :) can feel the heat <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 :))) <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. <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 <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>All these grafts really kill performance of package operations, especially on spinning disks <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 <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 <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? <lfam>No, I don't use Emacs at all <apteryx>OK! Hm, that may make the usertags less useful. <nij>lfam how do you type? <lfam>I push the keyboard with my nose <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 <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 <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>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 <nij>BlackMug: that's just a joke. But yeah, sorry folks. <lfam>I see, apteryx. That list looks stale to me <apteryx>some are already closed in that list though <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 <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 <lfam>Problems with the binary installer <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>On Debian, /root is not part of /home, but maybe it's different on Fedora <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>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 <roptat>is there another way to obtain these tarballs? <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>I don't know how to do that <apteryx>roptat: I'll give it a try with 'make release' <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 <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? <apteryx>I just feel 1.2.1 sends a too conservative message about the changes in that release <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 <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>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>It lacks to permission to start the daemon? <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 <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 <lfam>I'm going to try using the tarball in the ISO now <mdevos>I think (when cross-compiling) PATH only has stuff from native-inputs ***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>How to go from 'hm this ball game sure needs working sound' to 'welp my initrd can't mount / now' in 27s. <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. <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>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 <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>How can you type on this layou mdevos. :) <mdevos>xkcn: is that belgian-alternative? <xkcn>I'm not sure, it's belgian-borrowed. What's alternative about it? <mdevos>belgian-alternative == azerty + ??? + fancy Unicode <mdevos>Alt-gr + shif + die 1 toets bovenaan = ≥ <xkcn>Apparently this isn't Belgian but Frans (AZERTY). I'll have words with the owner that this is unacceptable. <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 <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. <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>Noisytoot: Worse, I ran 'reboot'. <xkcn>Now I know while all GNU/Linux users boast such uptimes. <mdevos>xkcn: I never edit my bootloader configuration if I can help it <mdevos>when I got this laptop, it had $PROPIETARY installed <mdevos>I was locked out of the BIOS configuration (laptop was second-hand) <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 <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>it was a flaw in ‘Windows Vista’ IIRC *xkcn just barely succeeded in installing an EXE but can now at least type at human speeds. <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. <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>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>Otherwise, honestly, diplomas are overvalued anyway. <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. <mdevos>not paying close attention to the ‘partition configuration’ menu <mdevos>xkcn: sorry, I can't find the exploit anymore <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 <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>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>the login screen will spontanuously dissappear <xkcn>Noisytoot: Yes, things like that. I've made myself very popular with the poor receptionist :) <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>ISO 77% downloaded, 31 minutes remaining. <xkcn>mdevos: Any ideas for 'hackable'? <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>('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? <xkcn>nij: Where did you get stuck? Keeping in mind that I can't run any code. <mdevos>klopt, bedoel ik. versleutelbaar = encryptable <xkcn>And verstelbaar is like... you can tweak a setting. <mdevos>"hacker" is ondertussen wel ingeburgerd <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' <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 <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