<nckx>Also don't think that matters, but who can say. Unlikely though.
<KE0VVT>What info should I post to the list? Not sure how to post it from my phone
<nckx>Good question. I think a ‘me too’ *is* valuable here because it could eventually expose a pattern in those affected. See if you can find one skimming that bug report (I don't have time right now, sorry). Adding details about your hardware is certainly a good idea. From what I did skim, HDDs/slower storage (maybe machines in general?) do seem to be suspiciously common in the reports.
*nckx …maybe I could dig up an old HDD from somewhere, but where…
<the_tubular>I login, screen flashes and i'm back to the login screen
<mroh>could be https://issues.guix.gnu.org/52051 than. maybe try to boot an older generation and look in /var/log/debug, is there is something with "elogind is already running" than welcome to the club ;(
<the_tubular>I've found a workaround: restarting elogind via SSH resolved the issue.
<podiki[m]>sorry the_tubular, don't remember any conclusions if there were any, but you can search the logs
<lfam>As for the kernel, I don't know if it's the same. Like, what kernel did you have installed, and which one are you using now? There is also the question of what firmware the installer provides. Maybe it is different from your config.scm. And then like I suggested, if your UEFI bootloader is not working right, your hardware might not work either
<the_tubular>Sorry was in my server room testing stuff, still no progress
<bdju>my swaylock takes several seconds to disappear after a successful password entry since my recent updates. did anyone else run into that? maybe it would be better after a reboot or sway session restart or something.
<the_tubular>I finally got an IP adress, but it's still not working ...!
<jpoiret>i'd run cfdisk /dev/sdX (or whatever your block device is) to see if the partition table is okay, if so, you can reformat a partition using mkfs.TYPE /dev/sdXN, where TYPE is the filesystem type, and N is the partition number
<jpoiret>be careful, double check everything as that will erase the contents of the partition
<jpoiret>you can also do `mkfs.TYPE --help` first as each fs has its own options
<the_tubular>I had trouble with my network for a few hours, so I tested both installer
<the_tubular>Is there something wrong with my usb stick be on the available lists to format jpoiret ?
<jpoiret>yes, the installer shouldn't list it here. It doesn't think it's the installation device, so it will wait on it to be available later on. That might be an installer bug, let me try to reproduce it in qemu.
<jgart>civodul, > design an implement the missing pieces
<jgart>civodul, > design <and> implement the missing pieces
<PotentialUser-12>Hello everyone. I am new to Guix and am currently trying it from the QEMU virtual machine file provided on guix.gnu.org. First of all, I would like to thank everyone who contributed to this amazing piece of software!
<PotentialUser-12>In order to try Guix, I tried to reconfigure my (virtual) system by changing its hostname. I therefore copied /run/current-system/configuration.scm to another location (let's say ~), modified the hostname field in the file, then run sudo guix system reconfigure ~/configuration.scm. Everything seems to run normally. Then I reboot my system, and
<PotentialUser-12>instead of booting up to the connection screen then to XFCE, a "Bourne-like REPL" starts and I don't know what to do from there.
<PotentialUser-12>Anyone knows what is going on? Sorry if this is a stupid question, but I'm very new to Guix and I really wanna learn more about it!
<PotentialUser-12>jpoiret: yes, I use the qcow2 image downloaded from the website. And I don't know if qemu is using EFI or Legacy boot, sorry
<jpoiret>are you running qemu from the command line? If so, unless you're using the -bios option with a firmware, it's running in legacy boot
<abrenon>I don't think it should, but that's something I haven't tried myself, and since I see no obvious reason why what you have tried shouldn't have worked on a "regular" system, I can't help wanting it to be linked to the issue : )
<jpoiret>is the shell you're presented with the GRUB rescue shell?
<jpoiret>it should be pretty visible if that's the case, you won't miss it
<abrenon>you didn't get any message about GRUB during the reconfigure ? so I take it that you passed -drive with format=qcow2, otherwise QEMU would've complained about not being able to write to the first sectors
<jpoiret>abrenon: the manual doesn't include running it with format=qcow2, maybe that's the issue
<jpoiret>although I don't think it should matter, as the older GRUB should work just as well if it wasn't able to update the MBR-installed one
<abrenon>running, it, no, but if you want to reconfigure it, GRUB's got to be able to write to the first sectors, and I know that's a frequent issue I've had when I booted VMs without specifying the format of the drive
<PotentialUser-12>Well, when the system starts, I can choose between my newly configured system or the previous generation. Then I boot the new generation, I get the REPL, but the old generation still works properly. So I don't think it's an issue with GRUB, but I might be wrong
<abrenon>but there should've been messages from GRUB during the install, in that case, I think
<jpoiret>PotentialUser-12: can you see any error messages above the REPL?
<PotentialUser-12>I don't remember seeing any message from GRUB during the reconfigure, but I might have missed them
<abrenon>when does the REPL appears ? how long after selecting the new generation ? do you get the regular boot steps that you get with the old generation ?
<PotentialUser-12>jpoiret: yes I do, sorry, I might have started from this! Let me try to send a screenshot
<PotentialUser-12>I tried to look it up on issues.guix.gnu.org but couldn't find anything that matched. And I tried to do that twice from a fresh download of the image and obtained the same result twice. Also I ran guix pull before guix reconfigure, I don't know if it matters
<jpoiret>can you try again by adding format=qcow2 to the -drive parameter as abrenon suggested?
<phf-1>jpoiret: Well, let's hope it will get fixed. Thank in advance to whoever manage to do it.
<jpoiret>phf-1: it looks like a Debian packaging issue to me but I might be wrong
<abrenon>PotentialUser-12: the whole syntax looks like: -drive file=/path/to/the/guix/image.qcow2,format=gcow2
<PotentialUser-12>Alright, I will try adding format=qcow2. Thank you very much jpoiret and abrenon for your answers!
<PotentialUser-12>jpoiret: thank you very much for the suggestion. Now when I run guix system reconfigure, I get error: device '/dev/vda1' not found: no such file or directory. I think I might have to edit something in configuration.scm
<abrenon>well probably the (device …) fields in the file-systems
<jpoiret>you should definitely use partition UUIDs instead of /dev/vda1 though
<abrenon>what are your actual devices called when you boot from the old generation ? sudo blkid ?
<PotentialUser-12>I get /dev/sda1 and /dev/sda2. I'll try switching to partition UUIDs as suggested by jpoiret
<jpoiret>the fun part is that when doing `qemu system image -t qcow2 xyz.scm`, the root device definition is not used for the installation, but rather a fixed partition UUID that the installer is able to generate
<abrenon>adding a subcommand raises the perceived complexity of the tool
<abrenon>having emacs 'installed' isn't really a problem on a system like guix where you can simply get an environment with it "for free" when you need it
<abrenon>I say this as an absolute ignorant of the ways of emacs, I never use it, don't know a single shortcut, and I simply see it as a development dependence for guix, including emacs or coreutils when I work on the repos doesn't make a big difference for me
<jgart>It just feels cleaner for users to run `guix fmt ...` than having to open emacs when they don't use emacs. Imagine telling a rust user that the standard way to format rust code is with an emacs lisp script instead of just using cargo's built in `cargo fmt`.
<abrenon>but not sure exactly what you mean by "open emacs", it's simply the "interpreter" for the ident-code.el script
<cybersyn>jgart: +1 for "guix fmt" being nice. I'm an emacs user but its something I also thought about. The issue being I think (but haven't looked) there is some inheritance from emacs to do the magic.
<jgart>I currently use `indent-code.el` and have it vendored into my bin/ scripts in my dotfiles
<jgart>They don't have to worry about learning how to run an elisp script :)
<cybersyn>while guix is an emacs-centric distro, I know some very involved contributors are not emacs users, and I think plenty of vim users who would be drawn to Guix because they see the benefits of scheme will be turned off by having to download emacs, because that crowd tends to prize minimalism quite strictly
<jgart>They just have to learn how to use one tool: guix
<jpoiret>but the installer doesn't use .config/guix/current/
<the_tubular>Yeah, might just go take a nap, been on this for a while and redownload the iso tomorrow
<civodul>jpoiret: yes; "guix pull" uses (guix self), which doesn't rely on local.mk to find patches
<vldn[m]>possibly related, what paths are needed to added to bashrc? i tend to overwrite it with my custom definition on my systems and recognized that somethings like progs installed with nixs are stop working because of fontconfig and something..
<NicholasvonKlitz>I submitted a patch to add gtk-rs for gtk4 on Wednesday but haven't heard any feedback so far. What's the usual timeline for reviewing patches and is there anything I can do to support the process?
<rekado_>NicholasvonKlitz: could you tell us the issue number here?
<rekado_>I can’t review this now, but maybe someone here has time now
<singpolyma>NicholasvonKlitz: I've been sold not to consider a patch stale until at least two weeks. Sometimes longer
*rekado_ successfully built icedtea 2 without first building icedtea 1.
<mothacehe>we may also want to extend the static network interface system tests as this is a somehow critical service
<jonsger>%build-inputs got dropped with the c-u-f merge and needed to be replaced with those "Gothic" sexp/gexp thingy?
<attila_lendvai>oh, re serialize and define-configuration: this is basically just a way to emit it as a string, not a serialize/deserialize infrastructure.
<jackhill>civodul: btw (not sure if you say my message a few days ago), but my static networking problem was that a copy-pasted a space after the address/netmask, which I guess got passwd happily to the kernel
<lfam>apteryx: If you want, I can do some testing of a gnupg upgrade for version-1.4.0
<lfam>I want to make a backup of the datefudge source code, which has been deleted upstream. In Guix, we apply a patch to this source code, so I can't log on to berlin and do `guix build -S datefudge` to access to the tarball named by the hash
<lfam>What is the best way to find the file for preservation?
<lfam>Hm, I guess I could try building without the patch :)
<nckx>lfam: I just search for the tarball and check the hash.
<apteryx>lfam: yes, please (I'm fine with testing an upgrade)
<singpolyma>nckx: sure, doesn't have to be git, just can't be tarball-over-http
<zimoun>singpolyma: the issue is intrinsic content-address (as Git) vs extrinsic as tarball+URL.
<nckx>zimoun: Some NIH invented ‘permanent’ URL scheme 😉 because I don't think the suggestion to ‘not include non-archived URLs’ indentifies or solves the real problem. It's confusing URLs with content-addressability, which we *already have*.
<zimoun>nckx: NIH = National Institutes of Health?
<nckx>raghavgururajan: I'm not sure myself, yet. I ran into the same problem (sanity-check dying because a module ‘wasn't found’ that wasn't an input) but the actual code is written in Python, which I can't read.
<nckx>lfam: Right, my only caveat was going to be ‘but it might be computationally expensive on their side’ so I agree!
<lfam>I mean, ideally our code wouldn't exercise it very often
<tex_milan>Hi Guix. After latest update I got interesting issue with i3 and its bar. After start it shows really big font there. After <Shift-Win-R> (reload configuration) it gets the correct size. Any idea what to look for?
<PurpleSym>raghavgururajan: Wrt gajim: Can you post the full message of the 'sanity-check phase? Usually it’s better to patch setup.py, but on rare occasions it’s acceptable to disable that phase. (Author of the 'sanity-check phase here)
<jgart>lfam, I also had the wrong thing in my gpg-agent.conf
<apteryx>I'm going to smoke test the branch 'manually', then if all looks OK I'll have it crunched by cuirass
<lfam>I'm building all the first-level dependents of gnupg apteryx, comparing to current master, and then I'll try upgrading my profile based on the update. I use gnupg for encryption and signing, so I can test it decently
<roptat>what does that mean: "guix shell: error: integer expected from stream" is that a network issue?
<jgart>I was pointing to a pinentry in the store with a dynamic hash instead of the one in .guix-profile/bin/
<nckx>apteryx: Do you have pinentry-program in your gpg-agent.conf? I have it set to current-system/…/pinentry-tty so it works from non-emacs.
<jgart>not sure why i thought that was a good idea at the time
<nckx>I don't know, but removing /gnu/store /var/guix /var/log/guix ~/.cache/guix ~/.config/guix should be all of it, unless I forget.
<apteryx>found it: "apteryx breatheoutbreath: for what it's worth, it's supposed to work OOTB without specifying pinentry-program since commit c7af9d0b5ebaa1fdb08ff5d8a56004998bcd8103 (Mar 26 2020)."
<lfam>I would recommend these things: 1) Stop the guix-daemon 2) unregister the guix-daemon from your service manager 3) delete /gnu/store 4) delete /var/guix and /var/log/guix 5) delete /etc/guix 6) delete ~/.guix-profile 7) delete ~/.config/guix
<lfam>There may be some other caches remaining but they are just caches
<apteryx>lfam: so that's what this gnupg-default-pinentry.patch is about
<singpolyma>lfam: installer same as now, but no version or related terminology, just "run this and it installs, yo, then always run pull after"
<iyefrat>well, lfam is right that versions are good for morale
<iyefrat>also from the perspective of potential users that are unfamilliar with guix
<singpolyma>iyefrat: yes, I know. It's confusing to outsiders but I agree with the internal morale thing
<unmatched-paren>we could just update the installer whenever we feel like enough time has passed, this seems like something that wouldn't really benefit from versioning formalities
<lfam>singpolyma: I guess there are two approaches. We do "waterfall" with the release, and then you get onto the rolling release afterwards. If our QA process improves we could maybe be able to keep an installer working constantly
<lfam>As it stands now, installing Guix System from a random commit is going to be more painful than we prefer
<lfam>Installing is way harder than updating the installed system
<lfam>It touches the one thing that can't be rolled back: the bootloader
<lfam>And remember, the project is young and small. We need publicity
<singpolyma>Yeah, it's just hard to communicate that "guix release" or "guix version number" is borderline meaningless to an existing user. So you get people (like me) looking at the manual for "the release version" which no one is running, stuff like that
<singpolyma>But I'm not saying I have a great idea how to be better and keep the benefits
<lfam>singpolyma: Yeah it's tough. The truth is that the original core of Guix developers expected people to use the info manual that is kept up to date locally. The web manual was not expected to be so popular
<lfam>Just a difference of experience and preference
<podiki[m]>dissent: that was supposed to be fixed....but i haven't tried, let me get the bugnumber
<iyefrat>yes but given the fact that no one is actually using guix 1.3.0, having the manual there is more confusing than anything
<iyefrat>i would suggest having only the latest manual, and in the install section explain the thing about guix constantly running on head
<podiki[m]>we've discussed the confusion over the manual here before, would be good to get sorted. a manual snapshot matching the installer version is useful though (as that will be what's in the iso and matches the system at that time)
<lfam>Maybe the two manuals could be named 'current' and 'version-1.3.0' or something?
<podiki[m]>then maybe for the manual issue we can just have one version linked (the "devel" one) and in the installation section it could have a note to refer to the manual snapshot that corresponds to the installer release
<nckx>It's just a snapshot that presumably a few people tested.
<zimoun>It is written «These images are development snapshots, you might prefer to use stable images» but indeed “stable” is confusing since it is “latest released”
<podiki[m]>maybe just "release version"? so it doesn't imply much?
<nckx>Veering off topic a bit, I don't see the need for a Web-hosted arbitrary snapshot manual anyway. Just host ‘devel’ (master), and note that ‘the manual installed with your version of Guix should always apply to that version, if different’ or something.
<nckx>People differ, so I can only assume there must be a human out there that for reasons unfathomable to me wants to connect to a Web server in Berlin to read the documentation they have waiting on tty2.
<podiki[m]>but the web version can be handy to have, esp if you have another computer/phone
<nckx>Maybe it involves telephones. I'm still not convinced but who knows. Does it justify hosting it? Dunno.
<zimoun>rekado_: which browser? Because the image could be huge, no?
<podiki[m]>having a full graphical environment for the installer could be nice, though I'm sure introduces all sorts of complexity
<nckx>It would have to have a Firefox-style UI or the same arguments apply though.
<iyefrat>zimoun: the only issue is that people that are using guix but are unclear about the fact that the installer version is just the initial guix version, and they may end up using the wrong web manual
<rekado_>I’ve rarely used info because Arch removed all info manuals… When I learned that GNU software came with real manuals and not just short man pages I was delighted.
<florhizome[m]>unmatched_paren I may correct: wf shell doesn’t have much priority since devs built wayfire to be used by DEs. It’s more of a proof of work. There are some interesting MRs though that would probably make it much better.
<florhizome[m]>they need some protocols to make interaction about workspaces and client/server transactions easier to get to stable release (or 0.8, first), wf shell will probably get attention when wayfire is production ready for DEs
<mroh>It's frustrating, we couldn't reproduce it with several qemu images with several throttling options, but on the real (HDD) box's it happens every try. Rebooting work/desktop machines all day is no fun ;(
<tex_milan>Hello, how to install neovim with python-pynvim? I just installed those two, but in neovim it tells me it python can't do import neovim. When I run python3 it also can't import neovim. Where the python-pynvim was installed to?
<unmatched-paren>i only found it painful because i had to figure out how to create an empty branch
<unmatched-paren>florhizome[m]: you'll need to create a keypair in gpg, if you don't have one, and then dump the ascii-armoured public key into florhizome.key in the keyring branch
<slimjim>hi Guix, I'm trying to define a gdb-multi package that inherits from the main gdb package, but adds some configure flags. I'm experimenting with different flags - but after installing the package once (via a gdb.scm in a path I set with GUIX_EXTENSIONS_PATH and then guix package -i gdb-multi), I can't get the package to rebuild after changing the
<slimjim>configure flags in my package definition - it just says 'nothing to do' because I've already installed the 'gdb-multi' package.
<slimjim>I tried "guix package -r gdb-multi" which removed it, but it didn't flush it from the store, so a subsequent "guix package -i" just re-used the same store path without rebuilding using the new flags
<nckx>Hm. If guix isn't rebuilding it it's just not seeing your gdb-multi. Neither uninstalling nor gc'ing will change that.
<nckx>There is no ‘flush from the store’, builds are input addressed. Guix won't install new binaries to /gnu/store/old-hash-gdb-multi/.
<jpoiret>shouldn't it be GUIX_PACKAGE_PATH instead of GUIX_EXTENSIONS_PATH?
<slimjim>well it's seeing the definition, because gdb-multi isn't a name defined in core guix, and I can "package -r" and "package -i" to uninstall and reinstall - but it doesn't look like changing the configure flags is triggering a rebuild
<nckx>Then you're not changing the configure flags as far as Guix can tell.
<jpoiret>yes. Although this isn't the root of the issue, as you would've gotten an error
<nckx>(#:configure-flags flags) `(append ,flags (list "--en…"))) ; I think.
<jackhill>Can someone test to see if you're able to reproduce this issue: https://issues.guix.gnu.org/52375 Vivien couldn't, but I just tried again and it persists for me (across multiple computers!), so I find it really odd.
<nckx>Otherwise you're throwing away the old flags.
<jackhill>what's wierd is that I was just able to play an embeded yt video, so clearly some AV stuff is working…
<slimjim>nckx: quasiquote seems to have gotten me farther, now `guix package -i gdb-multi` says The following package will be upgraded: gdb-multi (dependencies or package changed): gdb-multi ... but then says "nothing to be done"
<lfam>jackhill: Is there a browser cache that you can delete?
<florhizome[m]>how does the packaging meetup proceed, does it have a pad or do we communicate live via mail :D
<nckx>slimjim: OK, now I admit to be a bit stumped at first glance ☺
<lfam>slimjim: My advice in general is to avoid using `guix package` while testing builds. I recommend using `guix shell $package` to avoid getting about the state of one's profile
<lfam>I would also look at the derivation (`guix build $package -d`) to be sure it includes the configure flags that you expect
<nckx>slimjim: Do ‘realpath $(which gdb-multi [or whatever unique binary it provides])’ and ‘guix build gdb-multi’ print the same store path?
<jackhill>lfam: still getting it after rm .rf ~/.cache/epiphany
<nckx>lfam: I think they'd be in the -builder, but neat idea.
<slimjim>can i delete that specific package out of the store to try again? I am mistrustful of `guix gc` because it often removes a lot more than I want (e.g. I have to download a lot more stuff again the next time I run `guix pack`)
<nckx>florhizome[m]: By the way, I was full of poop, there *is* an --all argument to ‘pull’, it just does the equivalent of ‘git fetch --all && git rebase origin/master’, it still won't check out ‘all’ branches. I don't think git works that way. I use a worktree for the keyring to avoid the multiple checkout dance.
<nckx>Because checking out different branches each time screws up Guile .go caching.
<lfam>slimjim: Also, you shouldn't use package/inherit here. Instead, you should use (inherit gdb)
<nckx>slimjim: I don't use G_P_P myself so can't help debug why, but it's clear that at least ‘guix install’ isn't picking your (syntactically invalid) package. I don't understand what it *is* loading.
<lfam>package/inherit is intended for a special case, which relates to grafting
<lfam>slimjim: The crucial difference between what you shared is the empty list in the #:configure-flags part
<lfam>Don't ask me why it matters, I copied it from the guix-daemon package
<lfam>And I confirm that it doesn't work without it
<Kolev>I need to bookmark the page on the elogind bug...
<slimjim>lfam: is there potentially a module I need to include? The build derivation error starts with ice-9/psyntax.scm:2794:12: In procedure syntax-violation: Syntax error: unknown location: unexpected syntax in form ()
<slimjim>So using the original def I pasted in here, when args where just '--enable-targets=all', it did build, but then looking at the build log, there was a "starting phase configure"
<slimjim>and then configure flags: ("CONFIG_SHELL=/gnu/store/5pdmm36mvq8cb994z90blyk02jz7zvfv-bash-5.1.8/bin/bash" "SHELL=/gnu/store/5pdmm36mvq8cb994z90blyk02jz7zvfv-bash-5.1.8/bin/bash" "--prefix=/gnu/store/a5m2rsv3yfaa9w87n4p96xkpzz3rymcb-gdb-multi-11.1" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu")
<slimjim>so, there *are* some configure flags, but none of the ones I specified
<lfam>Yes, but is there a #:configure-flags key? I'm not a Schemer, but I would focus my investigation here
<nckx>Those are the defaults (not the ,flags you'd be inheriting — even lower level implicit defaults).
<slimjim>so it makes sense that the system isn't picking up the changes I've made to the flags, if they are all getting dropped somehow, because the original definition didn't have a configure-flags section
<nckx>lfam: I wasn't following but that's what e.g. (#:configure-flags '()) is for — it falls back to '() if gdb lacks that keyword.
<slimjim>ah, yes and original gdb definition does lack that keyword