<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?
<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
<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
<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>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
<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?
<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>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.
<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.
<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
<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>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
<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"
<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>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.
<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>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.
<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.
<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.
<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.
<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>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>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.
<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?
<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.
<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.
<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
<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>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>('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>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-220.127.116.11) (for weeks I think, though possibly with a different derivation) -> TLS error in procedure 'read_from_session_record_port'