IRC channel logs


back to list of logs

<fogbugz>What web browser are you using (in case you use GuixSD routinely as a desktop)? IceCat?
<OriansJ>fogbugz: I prefer emacs myself
<brendyn>Anyone have a system76 desktop? does it work well with a libre distro?
<fogbugz>brendyn: I dont have a system76 desktop, but a NUC works surprisingly well with linux-libre
<brendyn>I've never owned a desktop computer before. I'd like to get a good one but I don't want to make a big mistake in terms of compatability
<clacke[m]>> Especially in Debian/Ubuntu it can cause severe problems where the upgrade process blocks and the user needs to resolve the 3-way merge.
<clacke[m]>What does this even mean?
<clacke[m]>(from ArneBab's link)
<clacke[m]>It sounds like there is a mode where Guix handles state and can upgrade or downgrade configuration files. But that doesn't exist, right?
<str1ngs>I think it talking about the store and conflicts
<clacke[m]>conflicts in the profile? When two packages provide the same file? Maybe, but it doesn't say that very clearly, and I don't get where Debian comes in. :-)
<str1ngs>example you can install gcc@4.6.0 and gcc@7.2.0 and there will be file conflicts
<str1ngs>I'm reading into what he's trying to say there though. in order to make sense of it
<str1ngs>it's possible English is not the users first language.
<str1ngs>and maybe even better to say the whole comment, does not make much sense.
<str1ngs>distro should not have relevance at all. either guix works or it does. if it does work. then it will work the same across distro's
<str1ngs>short of guixsd. which is the only special case
<efraim>looks like we forgot to update cmake in core-updates
<efraim>on my system it looks like /run/current-system/profile/var is /gnu/store/...cups/var , which could explain some of the printing problems
<civodul>Hello Guix!
<efraim>I think we should add -DCMAKE_INSTALL_LIB=lib to the default cmake flags
<wigust>civodul: Hello
<kmicu>( ^_^)/
<civodul>efraim: yes!
<civodul>this was discussed again recently
<civodul>i think this can still go to core-updates if you hurry ;-)
<wigust>civodul: me CCed to 28832 and, but it seems the new bug report will not be produced, sorry for that
<efraim>i'll add it now, I notice that we already have -DCMAKE_INSTALL_RPATH= out /lib, so /lib64 could be a problem anyway
<efraim>-DCMAKE_INSTALL_LIBDIR should probably be (or (assoc-ref %outputs "lib") "lib") but I'm not sure our cmake build system supports separate lib outputs
<efraim>interesting, cmake defaults to parallel-tests? #f
<efraim>i take it back, it's later redefined as #t
<efraim>guix/build-system/cmake.scm:102 has parallel-tests? #f and gnu/build/cmake-build-system.scm:77 has #t
<rekado_>The “Free Java” devroom schedule is up. Looks like they decided against my bootstrapping talk, although it’s still listed as “undecided” in penta.
<rekado_>that’s changed now :) Just got the rejection email. Oh well.
<efraim>rekado_: your pcsc-lite commit is interesting :)
<rekado_>I did this yesterday night and only just rebased.
<rekado_>sorry about this :-l
<civodul>rekado_: bah :-(
<civodul>too bad, it's also tells a lot about how much they care about the issue
<mb[m]1>I love how `git pull --rebase` will just silently drop hunks that are already present on the remote, or the commit altogether if there are no more changes.
<civodul>yes, that's fun
<rekado_>do you think I should revert my version of the pcsc-lite commit, which after rebasing only adds a copyright line…?
<civodul>i think it's ok
<efraim>aarch64 mesa with llvm still fails a test, leaving it disabled
<bavier>this might be useful for our hpc packges:
<emsyr>Hello Guix!
<pkill9>hi emsyr
<emsyr>This is my first post here. I'v been trying GuixSD for about three months. I have a Mullins AMD graphic card that uses microcode from linux-firmware. I have searched a lot but I haven't found any legitimate way to by-pass this problem and have a good resolution on desktop services. Can someone help me with this? Thanks in adavnce.
<emsyr>This is my first post here. I'v been trying GuixSD for about three months. I have a Mullins AMD graphic card that uses microcode from linux-firmware. I have searched a lot but I haven't found any legitimate way to by-pass this problem and have a good resolution on desktop services. Can someone help me with this? Thanks in advance.
<pkill9>I'm getting an error while compiling Guix, It says 'In procedure memoize-variable-access!: gzip: unbound variable'. Full output here:
<pkill9>anyone know what this means?
<civodul>Hello emsyr!
<civodul>i'm afraid nobody here had a good answer
<civodul>pkill9: this was reported a couple of times before and i think it's been fixed (?)
<pkill9>oh interesting
<civodul>can you paste to another site BTW, like, which allows Tor users to access it
<pkill9>I downloaded the source from the Guix downlaod page
<pkill9>civodul: has the fix been added to the source downloadable from the download page?
<pkill9>as in on this page
<pkill9>under 'GNU Guix 0.14.0 Source'
<pkill9>in the tarball
<pkill9>or is it very new and not yet been added to that?
<bavier>pkill9: iirc it was a more recent fix
<civodul>yes, it's in master i think
<civodul>though i still can't remember what that was, which is kinda annoying
<emsyr>civodul: Thanks for answering.
<pkill9>hmm, `git clone` fails with "fatal: repository '' not found"
<pkill9>am i cloning the wrong url?
<lfam>pkill9: Yes, that's the wrong URL. Valid URLs are listed on the bottom of this page:
<lfam>So, most likely you should use <>
<pkill9>ah, thanks
<lfam>Kind of annoying that it doesn't "just work"
<lfam>I wonder how GitHub decides whether to serve a web page or a Git repo when you connect over port 443.
<pkill9>does '' direct to the master branch?
<pkill9>i'm getting a compilation error that's apparently been fixed in the master branch, but I'm still getting it with that git reposity
<lfam>pkill9: By default, Git always chooses the master branch
<lfam>You can check with `git branch`
<pkill9>oh yeah >.<
<pkill9>lfam: don't suppose you know the cause of this compilation error (line 172):
<lfam>I'm building from a fresh Git clone to see if it happens
<lfam>pkill9: From commit 9a56cf2b5b4970843c215091ea9823a67e077310, the error is not reproduced.
<brendyn>Can Guix run on IBM's POWER CPUs?
<pkill9>hmm i tried compiling with that commit (downloaded the tar.gz from and i still get that error
<lfam>pkill9: What is `guix --version`?
<pkill9>i don't have it installed, that's why i'm compiling it
<lfam>How are you providing the dependencies?
<pkill9>oh, slackware
<rekado_>brendyn: it would need to be ported.
<lfam>Okay, and what is the CPU architecture, how much RAM is there, what filesystem are you compiling on, any other details that might be relevant?
<brendyn>I guess windows doesn't run on it either?
<lfam>Also the kernel version
<rekado_>brendyn: the hardest part is to get access to a POWER system…
<efraim>Guix hasn't yet been ported to POWER, Mac power or POWER8/9
<pkill9>x86_64, about 4GB ram, EXT4 filesystem, kernel 4.4.88
<efraim>iirc there's somewhere online you can get a vps on power
<lfam>pkill9: Okay, that all sounds good. What version of Guile are you using?
<lfam>Okay, sounds like this should all work. If you don't get any other answer here, please compile all this information into a bug report and send it to <>, first searching for previous reports of this issue
<efraim>I actually have 2 PPC Mac laptops in my computer stash
<brendyn>I'm looking at the Talos II which might not exist yet
<pkill9>if guix is configured to share the store with nix, does it end up reusing things huilt by nix and vice versa, or does it typically rebuild/download it's own cache but store it in the nix store?
<fogbugz>what's a quick way to convert base16 strings output from sha256 to base32 as used by guix package definitions?
<lfam>fogbugz: I'm not sure, but you can use `guix hash` to get the hashes in the base32 format used by Guix
<fogbugz>lfoham:h, ok
<fogbugz>lfam: oh, ok
<fogbugz>what is the standard way to pass an argument or set an environment variable for configure in a gnu-build-system? I'm trying to package a QT application *LyX) and I need to either set QTDIR or pass --with-qt-dir from the QT input I'm using.
<fogbugz>I've seen how it's been done in QUCS, but I wonder if there's no simpler way.
<mb[m]1>Today I learned Btrfs lets you delete in-use subvolumes, without question.
<mb[m]1>Don't ask how.. :/
<bavier>fogbugz: #:configure-flags is the typical way
<OriansJ>mb[m]1: well it could be worse, you could have "accidentally" recursively defined your subvolume such that it believes itself to have infinite space but any write to it completely nukes your drive
<mb[m]1>OriansJ: That sounds a little more involved than a fat-finger `btrfs subvol delete ...` :P
<OriansJ>mb[m]1: actually it involves a single unicode character in what you thought was a comment
<mb[m]1>I'm going to have to read the code and see if it's possible to check open file count and at least warn about it. Surprised the kernel allowed it!
<mb[m]1>OriansJ: heh
<efraim>perl-moosex-getopt fails on aarch64
<OriansJ>mb[m]1: appearently # and # are two entirely different things. The first is the ascii char used by bash for line comments and the second is the utf-8 char that results in rather strange system behavior.
<efraim>because of course it is
<mb[m]1>OriansJ: Yeah I've had fun with "invisible" unicode chars before.
<OriansJ>efraim: that simple frustration made me take the time to write this: a program that has just one job. Identify ALL chars that DON'T belong in a source file under any conditions.
<bavier>efraim: I'm guessing perl-moosex-getopt would fail on x86-64 too
<efraim>looks like it
<bavier>efraim: probably 68998abd4fcaf7a1e19de21b311a9e4610cdaf45
<bavier>the perl-getopt-long-descriptive update might have changed output formatting that the moosex-getopt test is looking for
<mb[m]1>Note sure what to make of the new core-updates failures:
<pkill9>good song >
<pkill9>oops wrong chat