IRC channel logs


back to list of logs

<database>is there any tool to detect error of graphic card
<civodul>lfam: i added some pk's and it seems that it's deduplucation that's killing us
<civodul>because it involves retraversing each store item and reading each file
<lfam>It does it for each file?
<lfam>Or, you could just point me to the relevant code so I can learn it :)
<civodul>yeah, it has to read them to be able to determine if there are duplicates
<civodul>(guix store database) calls the deduplication code
<civodul>which is in (guix store deduplication)
<civodul>(reepca's code from last year's GSoC)
<civodul>maybe c45477d2a1a651485feede20fe0f3d15aec48b39 or something close inadvertently turned on deduplication
<civodul>so in (gnu system vm), we could pass #:deduplicate? #f to 'root-partition-initializer'
<apteryx>rekado: I got what I wanted with a mix of --ProfileManager --new-inst (configured new profile), and now I can start it using icecat -P mynewprofile (even if the original profile is running). Nifty!
<apteryx>thanks for the tip.
<ecbrown>i have a nasty "stacktrace" on guix system reconfigure:
<ecbrown>it was generated with config.scm:
<ecbrown>sorry that it involves a non-free kernel
<ecbrown>i can't really decipher the error and follow it back to anything i recognize in the config
<samplet>ecbrown: Looks like one of your kernel modules cannot be found.
<ecbrown>hmmm ok
<ecbrown>interesting that i was able to install the system with basically this config. the reason for reconfigure is that i'm trying to update global packages
<ecbrown>even with (firmware %base-firmware) i am seeing same problem
<samplet>Try “(initrd-modules %base-initrd-modules)”.
<ecbrown>samplet: i can't as i need to append ahci and shpchp
<ecbrown>i get reconfigure error if i don't append them to %base-initrd-modules)
<samplet>exbrown: I wonder if some module from “%base-initrd-modules” is missing then.
<samplet>It’s too bad Guix doesn’t print which module is missing.
<ecbrown>hah yeah
<ecbrown>i seem to be grepping the guix source tree a lot
<samplet>If you can find the store file for your particular Linux, you could check the modules in “%base-initrd-modules” against “lib/modules”.
<ecbrown>my linux is guixsd
<ecbrown>but if i can't fix this soon its gonna be neon + guix
<samplet>I mean your particular, custom kernel package.
*ecbrown wonders if guixsd is currently an OS best suited for big hardware rather than dual core laptop
<ecbrown>or maybe i'm just pissed cuz of apple hardware
<samplet>exbrown: You could try restoring the stock Guix kernel “(kernel linux-libre)” and running “guix system build config.scm”.
<samplet>Just to see if it works.
<ecbrown>ok, here goes nothing
<ecbrown>same error
<samplet>That’s pretty strange.
<samplet>Let me look a bit more closely.
<ecbrown>i feel my system is in a strange state rather than e.g. syntax error
<samplet>ecbrown: I can’t find anything. If I were you, I would try building the “bare bones” config from the manual as a sanity check.
<ecbrown>wow i was just thinking that.
<ecbrown>does guix system build differ from guix system reconfigure
<ecbrown>i.e. i'm worried about losing my desktop session while i do this
<ecbrown>maybe i should do it in a console window
<samplet>Using “build” just builds the kernel, initrd, and bootloader (and maybe some other things, too).
<samplet>It doesn’t install or change anything (except the store in a very safe way).
<ecbrown>just read the --help. doh
<ecbrown>guix system build bare-bones.tmpl worked for me
<ecbrown>i wonder if guix gc will help
<samplet>ebrown: It shouldn’t.
<samplet>Are you sure it doesn’t work if you modify your normal config to be “linux-libre” and just “%base-initrd-modules”?
<ecbrown>i did linux-libre and added only shpchp to base-initrd-modules
<ecbrown>it downloaded and everything
<ecbrown>linux-libre that is
<samplet>Well, I guess you could try adding “shpchp” to the “bare bones” config and seeing if it breaks.
<ecbrown>thats a great idea, let me try that
<samplet>(The module seems to be available, but that looks like the only relevant difference.)
<ecbrown>samplet: any what do you know, adding the shpchp to the barebones and building leads to that very same error in my original scrupt
*ecbrown wonders if samplet is really gandlaf
<ecbrown>so my situation is, if i omit those ahci and/or shpchp i get an error in reconfigure that says i need them. if i have them, i get that horrible stack trace
<samplet>ecbrown: OK. That’s rough. What version of Linux-Libre do you have currently? What’s the most recent version listed from “guix package --show=linux-libre”?
<ecbrown>wonder if i should try an earlier kernel?
<samplet>I am already on an earlier kernel; let me try.
<samplet>It works on 4.17.13.
<samplet>I’m trying to reproduce the failure now on 4.18.4.
<samplet>Currently, <> is crawling. So it might take some time.
<ecbrown>ok, no problem, and thank you
<samplet>You’re welcome!
<samplet>ecbrown: I get the same issue. It is a bug. You should submit it if you are up for it. Be sure to include the bare bones config with the extra module in the report.
<ecbrown>ok, that sounds like a plan. thanks for your efforts
<samplet>I have to go now. If you don’t submit it, I can do it later.
<ecbrown>interesting there is a --skip-checks option that lets me get past not having the modules declared
<ecbrown>kernel compile is about the length of a Pawn Stars
<tune>gmail webmail's new layout is really laggy for me. anyone have recommendations for an email client I can run on guixsd?
<tune>my specs are fine, the modern web just sucks
<ecbrown>i'd expect emacs-based email to be disproportionately represented
<ecbrown>for example i use Gnus as my primary email and web browser
<ecbrown>i mean emacs web browser
<emacsomancer>tune: mu4e is nice
<tune>I was thinking of getting into emacs, but I don't know if I'm ready just yet, so I'll check out claws. Thanks for all the recs.
<buenouanq>I too am not yet cool enough to do email through emacs - Claws-mail is great.
<janneke>sneek: later tell civodul: i am making some progress with wip-bootstrap; i found the bug that caused the weirdness i saw: a depedency on non-bootstrapped linux-kernel-headers. now added a linux-libre-headers-bootstrap tarball too
<janneke>sneek: botsnack
<ngz>Hello. I'm having trouble with Guix environment variables in a foreign distribution (Debian Buster) using Gnome (Wayland). Logging through GDM doesn't let me enter Gnome session. I have to rename .profile to .profile_bak or some such so I can log in. But then, ~/.guix-profile/etc/profile is not sourced.
***rekado_ is now known as rekado
<rekado>ngz: this is probably a problem with the XDG_* environment variables.
<rekado>GNOME looks up binaries in directories on XDG_*, but they might be incompatible.
<rekado>this is a difficult problem to solve.
<rekado>you can unset them in .profile after sourcing the profile.
<ngz>How can I know which ones are set? I don't set any XDG_* in ".profile", so they all come from sourcing .guix-profile/etc/profile.
<rekado>you could grep that file for XDG
<ngz>At the moment, there is only XDG_DATA_DIRS, but could there be more?
<rekado>there are other XDG variables, but I think that’s the one that gives you problems.
<rekado>others are for caches and so on
<ngz>so I put "unset XDG_DATA_DIRS" at the end of ".profile"?
<ngz>I'm going to try that.
<ngz>While I'm at it, there is another issue. I re-installed my system, and thus Guix binary, but guix pull && guix package -u only gives me outdated package definitions.
<ngz>For example, I get asymptote 2.44 although the one in the repository is 2.47
<rekado>make sure you’re actually using the pulled guix.
<rekado>“guix pull” now installs the new version in ~/.config/guix/current/bin
<rekado>it also asks you to put this directory first on PATH.
<rekado>you may have overlooked that.
<ngz>It somehow rings a bell as I had tested it in my previous installation. I'm using the "guix" link (in /usr/local/bin/guix) which comes from root.
<rekado>the behaviour of “guix pull” has changed a few months ago
<ngz>Yes, I remember something about it.
<rekado>it no longer just installs some Guile modules and looks for them no matter what “guix” executable you use.
<rekado>you now actually need to run that new “guix” executable.
*rekado has to leave
<rekado>hope this helps!
<ngz>Yes, it does. Thank you.
<ngz>rekado: unsetting XDG_DATA_DIR doesn't work.
<wigust>sneek: later tell ngz Try instead of unsetting - set them to what they were before sourcing ‘~/.guix-profile/etc/profile’ [1]. For me setting XDG_CONFIG_DIRS and XDG_DATA_DIRS after sourcing [1] works.
<sneek>Got it.
<jlicht>hey guix
<ng0>what's the special move to reference the package "file"? (assoc-ref %build-inputs "file") when file is in the native-inputs doesn't work
<ng0>basically I want to patch "file -i" to "$out/bin/file -i" where $out is out of file, not the current build dir.
<civodul>hi there!
<sneek>civodul, you have 1 message.
<sneek>civodul, janneke says: i am making some progress with wip-bootstrap; i found the bug that caused the weirdness i saw: a depedency on non-bootstrapped linux-kernel-headers. now added a linux-libre-headers-bootstrap tarball too
<ng0>no package does that, so either I'm the first, or file is part of the base and I forgot it
<ng0>ok, got it, was an error
<janneke>civodul: still have the "duplicate/shadow" package tree and silly 00/01 names -- we can remove that later
<janneke>civodul: i expect to remove the make and diffutils bootstrap tarballs later
<janneke>the thing is that diffutils and make depend on DIR and opendir, which mes c lib does not support yet
***slyfox_ is now known as slyfox
<jlicht>great news janneke :)
<jlicht>or at least, progress
<janneke>jlicht: :-) tnx
<novaskell>Hello, I was wondering if it's possible to direct the grub-efi installer to use x86_64-efi correctly as i386-pc seems to be missing (I may also lack an understanding within this area) on my install media generated using the default gnu/system/install.scm.
<novaskell>I have tried legacy boot but it sadly doesn't seem to work at all for my x220
<janneke>the auto* implementation of the gnu build system really sucks, at least for developers
<janneke>it's beyond me how we created such an atrocity
<rain1>we can fix this!
<rain1>we can build a better one
<janneke>rain1: no we can't
<janneke>i'm trying to build gcc-2.95.3
<janneke>oh, yes, we can release gcc-2.95.4, 15 years later :-)
<rain1>now that would make headlines
<janneke>rain1: i really like this/your attitude: we can fix this!
<rain1>I have written a build script for bash that doesn't use auto* or make
<rain1>it was pretty hard! it took me 2 days
<rain1>i think gcc would be much harder to do as well, maybe like 2 weeks
<rain1>but it's a possible route
<janneke>it just occured to me a couple of weeks ago, that the auto* implementation of the gnu build system is NOT FREE SOFTWARE
<rain1>that's true!
<rain1>it's not source files, it's a derived product
<janneke>i'm still brewing on that, and not sure how to bring the message across
<janneke>but building ancient software is *terribly annoying"
<janneke>you cannot change the sources, because you cannot re-create the magical mix of auto* tools to regenerate them
<janneke>i think GNU should not tolerate this madness any longer
<rain1>i am seeing projects start to use meson/ninja a lot. i'm not totally convinced that it's the change we need
<rain1>but i totally agree about improving our build tools - that said, it is a complex space
<rain1>the flexibility that autotools provides will be hard to reimplement
<janneke>yeah -- and i *really* like the gnu build system -- just not the perl+auto* implementation of it that many use
<rain1>I think we could definitely keep the UI with te same flags and stuff
<rain1>and implement it better so that we have things like parallelism for the ./configure checks
*janneke needs to go -- see you late tonight or tomorrow
<OriansJ>well autotools was ultimately a quest to solve a problem that probably shouldn't have been solved.
<rain1>what do you mean?
<civodul>novaskell: several people have GuixSD running on an x220 (rekado maybe?)
<civodul>i think it's not UEFI
<civodul>rekado: ↑
<novaskell>Wondering, are there any extra steps to getting it to boot? Currently I can only boot from the install media
<novaskell>Works on the T410 though
<OriansJ>rain1: Think about what autotools does and how it is used to not have a well defined set of dependencies
<OriansJ>I mean it literally has config.guess
<OriansJ>That entire complexity is worthless in a well defined world like guix
<civodul>janneke: i understand the bad feelings about the autotools, but it is free software
<civodul>it was designed to address portability to Unices without requiring users to install anything special beforehand
<OriansJ>The results of its generation are entirely deterministic and with a little logical planning be expressed cleanly in a simple make file
<OriansJ>civodul: very true
<janneke>civodul: if i want to port build gcc-2.95.3 to a new architecture (say: mes), configure and will break
<janneke>civodul: i would need to change configure.(ac,in) and
<janneke>civodul: however, if i change any of those, i need to have installed the exact autoconf+automake+libtool triplet that was used to create gcc-2.95.3
<janneke>if that's not possible, it would be non-free software
<janneke>in theory it's possible to install those -- in practice it's not
<janneke>so, theoretically, auto* is free software, in practice it's not
<janneke>or, i'm just too frustrated -- and also i *really* need to run :-)
<rain1>which version of gcc introduced 64 bit?
<rain1>ttyl janneke!
<rain1> this seems to be it
<civodul>janneke: it's not that it's non-free software, it's just that you need the right version; same if you try to run Guile 2.2 code on Guile 1.4 :-)
<civodul>re portability, the problem is config.{guess,sub}, as was discussed on g-p-d
<civodul>but yeah, i agree that it's a real problem in practice, no argument!
<janneke>hmm, what you're saying is that 'not free-sofware' is a hyperbole and thus not helpful
<OriansJ>janneke: I guess that what is what makes guix so important, we actually have to do the work required to make the source something that actually is usable.
<janneke>there's really something terribly wrong with the auto* implementation and we need to fix that
<rain1>I think the idea of entropy that OriansJ raised is the key
<OriansJ>janneke: I think civodul is expressing, although the source code is available under a free license, the net desired freedom isn't obtainable because the build information required still needs to be collected and stored
<rain1>the inputs should be sealed off in such a way that it is clear what will be conditioned upon
<rain1>and the compiliation procedure would ideally be a function of these inputs (like a reproducible build)
<OriansJ>Aka source code without the required build information is effectively useless, like Haskell source code without a Haskell compiler
<ng0>I'm currently packaging one of the oldest OTP releases and the perl + other dependencies which where out back then.. having to reconstruct environments is not fun.
<janneke>most of us know that you should never patch .ac or .am, but always patch configure or .in
<janneke>because "you can never expect to regeerate
<janneke>that's just terrible...and we keep on doing this
<janneke>in theory, guix could solve this by providing auto* packages for all possible configurations
<OriansJ>janneke: that is because the pain of history hasn't been experienced by those who most benefited by their toxic choices.
<janneke>i haven't seen any effort towards that direction
<rain1>i hope we don't make janneke late... we can always pick this up another time :P
<OriansJ>Much like how companies used to dump toxic waste in streams, todays build processes need a green revolution
<janneke>yeah, rain1 i'm running now!!!
<janneke>civodul: please let me know whenever you have any (preliminary) wip-bootstrap patches somewhere
<rain1>i can't actually build any of these old gcc's (before it went C++) using my modern gcc
<rain1>a different error every time
<amz3>autotools ftw
*amz3 hides
<civodul>janneke: the reason i'd recommend patching, say, "configure" instead of "" in Guix packages it because it avoids adding a dependency on Autoconf & co.
<civodul>but usually regenerating works well nowadays, in part because Autoconf & co. move very slowly now
<civodul>mind you, my point is not that autotools is great ;-)
<OriansJ>amz3: Your a Hurd user aren't you!
*OriansJ *incites kernel war*
*OriansJ *_^
<mbakke>glibc 2.28 is now live on core-updates :)
<civodul>mbakke: \o/
<mbakke>Woah, what's with the queue on Hydra.
<novaskell>yep, seems to not detect it at all. Looks like I'll just have to use Guix on another distro
<amz3>novaskell: what is the platform / device that you are trying to boot?
<amz3>novaskell: if it's coreboot / libreboot bios, did you try to upgrade?
<amz3>I am not saying you should upgrade right away
<novaskell>currently the original as currently not able to flash core/libre
<amz3>ok, so the problem is that you can not boot the guixsd iso? is that correct?
<novaskell>can boot the guixsd iso but after install it doesn't detect a system installed
<amz3>then it might be a problem with config.scm you used to init the guix system
<amz3>pasting config.scm somewhere like will be helpful
<amz3>novaskell: if the guixsd iso boots, it's very unlikely you can not boot from the hard disk
<novaskell>It's the default bare-bones.scm with (target "/dev/sda")
<amz3>did you check that /dev/sda exists?
<novaskell>It does
<amz3>is there any error message when you try to boot from the hard disk?
<amz3>kernel panic or something?
<novaskell>None, currently it only shows the device selection menu after attempting to boot
<amz3>what is the "device selection menu" ?
<amz3>isn't that a bios menu?
<amz3>did remove the iso (usb key or compact disc) before rebooting?
<amz3>do that, then select hard disk from the bios menu
<novaskell>have done, returns to the bios menu
<amz3>I think something is wrong with your bios setup, i never see the device selection from the bios without pushing a particular keyboard button
<amz3>reboot again
<novaskell>trying install again
<civodul>mbakke: we should focus our efforts on berlin IMO
<novaskell>amz3: got it working. Thank you
<mbakke>Wait, why doesn't Hydra have substitutes for 'libinput' on master?
<ison111>I have a rather trivial package for SpaceFM that I'm thinking about contributing. I understand that I would send it to the mailing list but who maintains it after that (just updating the version number and hash I assume)? If it were accepted should I then keep an eye out for new versions and submit a new copy to the mailing list, or is it maintained in some other way?
<amz3>ison111: no one is assigned maintenance duty
<amz3>ison111: there is no maitainer per package if that's what you meant
<amz3>ison111: how did you solve you issue regarding playing videos in google doc?
<ison111>amz3: Oh, I still haven't resolved that. I suspect it's just a special case involving the custom script required to play videos from google docs on
<ison111>amz3: But thanks for the info on submitting packages. I didn' have anything specific in mind, was just looking for info. I wasn't sure if there could be some automated way they check for updates and automatically grab the new hash or anything like that.
<amz3>ison111: iirc there is sub command of guix that can check for updates
<amz3>ison111: but it still requires to commit the change and submit the patch
<amz3>not sure
<ison111>amz3: Well like I said the package is fairly trivial. I just want to do things in the standard way. So when there's a new version do people typically just resend the package to the mailing list then?
<jlicht>ison111: usually, yes. After some time, if you feel like it, you might be offered (or simply ask for) commit-permissions to the repo, after which you can directly commit the more-or-less trivial package updates to the relevant git branch.
<roptat>amz3: ison111: guix refresh is helpful to find new versions
<roptat>but it works only on a subset of our packages
<ison111>jlicht: Is there any special formatting I should use for the email subject or body? Sorry for the simple questions, I've never submitted a package before.
<jlicht>ison111: don't worry, everyone had to sent their first patch at one point :)
<jlicht>The easiest (imho) way is to use git directly:
<jlicht>but you can also simply send the patch as an attachment in a normal email to the mailing list. The commit message format used by the guix project is similar to ChangeLog, and a bit verbose, but you should be able to check the git log for other examples.
<jlicht>ison111: You can check the archives for how other's send the patches:
<civodul>ison111: see also
<ison111>civodul: Ah, perfect. That answers a few other questions I had. Don't know how I didn't find that before.
<civodul>also don't worry too much about the details of the conventions, it's already quite some work to get started ;-)
<civodul>(i say this because every time i look at this page i'm like "woow, this is really long")