IRC channel logs
2017-12-19.log
back to list of logs
<fogbugz>What web browser are you using (in case you use GuixSD routinely as a desktop)? IceCat? <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]>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 <efraim>I think we should add -DCMAKE_INSTALL_LIB=lib to the default cmake flags <civodul>i think this can still go to core-updates if you hurry ;-) <wigust>civodul: me CCed to 28832 and bug-guix@gnu.org, 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. <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. <rekado_>do you think I should revert my version of the pcsc-lite commit, which after rebasing only adds a copyright line…? <efraim>aarch64 mesa with llvm still fails a test, leaving it disabled <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. <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 (?) <civodul>can you paste to another site BTW, like paste.debian.net, 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>or is it very new and not yet been added to that? <bavier>pkill9: iirc it was a more recent fix <civodul>though i still can't remember what that was, which is kinda annoying <emsyr>civodul: Thanks for answering. <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>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` <lfam>I'm building from a fresh Git clone to see if it happens <lfam>pkill9: From commit 9a56cf2b5b4970843c215091ea9823a67e077310, the error is not reproduced. <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? <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? <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 <bug-guix@gnu.org>, 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>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. <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! <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. <mb[m]1>OriansJ: Yeah I've had fun with "invisible" unicode chars before. <bavier>efraim: I'm guessing perl-moosex-getopt would fail on x86-64 too <bavier>efraim: probably 68998abd4fcaf7a1e19de21b311a9e4610cdaf45 <bavier>the perl-getopt-long-descriptive update might have changed output formatting that the moosex-getopt test is looking for