<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! <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>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>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>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”. <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>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>guix system build bare-bones.tmpl worked for me <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 <samplet>Well, I guess you could try adding “shpchp” to the “bare bones” config and seeing if it breaks. <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>I’m trying to reproduce the failure now on 4.18.4. <samplet>Currently, <berlin.guixsd.org> is crawling. So it might take some time. <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 <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 <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. <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. <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. <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. <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. <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
<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 <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 <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>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. <civodul>novaskell: several people have GuixSD running on an x220 (rekado maybe?) <novaskell>Wondering, are there any extra steps to getting it to boot? Currently I can only boot from the install media <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 <janneke>civodul: if i want to port build gcc-2.95.3 to a new architecture (say: mes), configure and Makefile.in will break <janneke>civodul: i would need to change configure.(ac,in) and Makefile.am <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? <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>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 <civodul>janneke: the reason i'd recommend patching, say, "configure" instead of "configure.ac" 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 *incites kernel war* <mbakke>glibc 2.28 is now live on core-updates :) <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>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? <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>did remove the iso (usb key or compact disc) before rebooting? <amz3>do that, then select hard disk from 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 <civodul>mbakke: we should focus our efforts on berlin IMO <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 cytu.be. <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 <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>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. <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")