IRC channel logs


back to list of logs

<daviid>rekado_: no rush of course, if the debian paste i posted earlier today expires when you want to deal with the tiny correction i did ask for, the 3 paragrahs i recommend to use for the guix gule-cv synopsis/description 'fields' are on the front page of the guile-cv site ...
<olivuser>if I were to try to implement lxqt as desktop service, would I find help in the guix/guile manuals? Or do I need other resources
<olivuser>Also, which commands do I have to pass regularly to maintain guixsd as a user? I mean, is guix system reconfigure a component of user maintenance, or could a user change, p.x., the desktop service in an easier fashion?
<efraim>The first part for lxqt would be to upgrade the components and make sure all the parts are packaged
<olivuser>But I guess I would find the necessary components-"barebone" in guix/guile and the definitions of gnome-desktop-service and others, right?
<olivuser>That is, an overview of what is required for a desktop service to be properly defined.
<apteryx>efraim: I just answered to your comment about the openntpd-service-type
<apteryx>I will try to test openntpd more to get it to sync at least; I wonder if one of the oddities I spotted in the generated config may be at cause
<apteryx>efraim: ah, the sync problem stemmed from the use of constraints
<efraim>apteryx: I don't actually use the constraints with my setup, thanks for taking a look at it
<janneke_>do we have a --target option for guix environment yet?
***janneke_ is now known as janneke
***abbiya_ is now known as abbiya
*janneke digging in my old mingw cross patches for how to setup a cross environment with a mingw xgcc package
<janneke>okay, this builds a cross compiler: guix build -e '(begin (use-modules (gnu packages cross-base) (gnu packages mingw)) (let ((triplet "x86_64-w64-mingw32")) (cross-gcc triplet #:xbinutils (cross-binutils triplet) #:libc mingw-w64-x86_64)))'
<janneke>'t would be nice if we could attach a friendly package name to this curse, though
<apteryx>efraim: do you think it's OK to use the cert.pem CA from libressl for the openntpd package?
<civodul>Hello Guix!
<raghavgururajan>civodul o/
<janneke>hello civodul! do you know a of a way to add --target=... to guix environment?
*janneke is now ^C'ing the build and work in /tmp/guix-build* ...
<civodul>janneke: we'd have to think about the semantics
<civodul>because normally, --target would give you binaries that you cannot run on your machine
<janneke>civodul: ah, right -- what I really mean is --cross, I think
<janneke>"guix, just gimme an environment with the packages resulting from guix build --target=XX and the cross-compiler XX" -- hmm...
<civodul>ah yes
<civodul>so without --ad-hoc, typically
<civodul>i guess that should be doable
<janneke>i'm scripting it in sh now, but hmm
<civodul>it should be possible to do better :-)
<janneke>building up some understanding, i guess
<janneke>yes, that would be very nice; how do the hurd people do it?
<civodul>not with 'guix environment' i guess
<civodul>there's one package->bag call in (guix scripts environment), you could try passing #:target there to see what happens
<civodul>it might be enough to get "guix environment foo" give you the cross-compilation environment
<civodul>now that i think about it, i think this was discussed with dongcarl before
<janneke>ah -- i tried (parameterize ((%current-target-system "x86_64-w64-mingw32")) foo), but that does not work
<efraim>apteryx: probably?
<olivuser>hello everyone. I just installed guixsd afresh from usb stick. guided installation went fine, it is only when I was asked to remove the usb stick and restart that the installation froze and I had to restart.
<olivuser>now that I am booting to the system for the first time, I cant guix pull. it says that building guix-symste.drv has failed, and guix pull is aborted
<olivuser>also, the build of profile.drv has failed. this "comes to light" only when I run guix pull with the --fallback option.
<olivuser>does anyone have an idea what might have gone wrong and how to fix it?
<rekado_>olivuser: it should also report the location of the log file corresponding to the failed build.
<rekado_>olivuser: could you paste this somewhere please so that we can see what’s wrong?
<rekado_>“--fallback” causes Guix to build things locally in case of network problems.
<rekado_>olivuser: to answer your earlier question about maintaining a Guix System: you just need “guix pull” to get a more recent Guix (that has access to updates and security fixes), and then reconfigure your system with “sudo guix system reconfigure /etc/config.scm”.
<rekado_>“guix system reconfigure” will build a new system as specified in the configuration file, and make it the default when booting.
<rekado_>on its own “guix system reconfigure” won’t give you anything new, though. Building with the same version of Guix will always give you the same system. You need “guix pull” before that to get access to changes, fixes, updates, etc.
<olivuser>rekado_, thanks for the replies, will reply in the next minutes/hours!
<olivuser>rekado_, also, it seems like the problem has mysteriously solved itself. Is it possible that this is related to the desktop environment that I chose? because it has not worked under mate but now works under gnome
<olivuser>and there is one difference I seem unable to understand: when I want to reproduce the same system (especially programs) in different computing environments, do I have to write that in the same configuration file that I instantiate using guix system reconfigure? and if I do, do all users have access to it?
<efraim>It was with the master branch, it was broken for about a half hour
*civodul founds that CI was not really happening for ARM on 'core-updates'
<civodul>ant-bootstrap fails to build on core-updates (x86_64):
<civodul>any ideas?
<civodul>g_bor[m] maybe? :-)
<civodul>IIUC, the actual issue is "Could not load the version information"
<apteryx>efraim: OK, thanks
<olivuser>efraim, thx, good to know!
<dongcarl>janneke: What I currently do as a workaround for my Bitcoin Core builds is just to set the CROSS_*_PATH variables manually.
<quiliro>Saluton Giksujo!
<Marlin1113>hi guix
<Marlin1113>any idea why installing guix on a foreign distro changes neofetch to guix?
<roptat>do you mean, guix installed a guix version of neofetch without your consent, or neofetch detects guix and thinks you're using the guix system?
<rekado_>civodul: the problem with ant-bootstrap is worse than it sounds
<rekado_>a few months ago I came up with a fix, but it’s ugly.
<rekado_>the fix is: let the bootstrap JDK’s classpath library leak memory.
<rekado_>I asked for comments, because I feel uncomfortable with a workaround like that.
<rekado_>but nobody came up with a better suggestion.
<rekado_>if it was up to me I’d just push that fix and worry about it later
<rekado_>the bootstrap JDK isn’t used anywhere else, so there should be no impact on other Java things.
<quiliro>Marlin1113: Check roptat's question above.
<rekado_>re ant-bootstrap: comments would be very welcome here:
<Marlin1113>i'm on fedora
<Marlin1113>i run fedora's neofetch
<Marlin1113>and it shows up as guix
<rekado_>what’s neofetch?
<rekado_>what means “shows up as guix”?
<civodul>rekado_: re ant-bootstrap, thanks for the pointer!
<roptat>Marlin1113, that's an issue with neofetch, not guix
<roptat>iirc, it wrongly detects your OS as the guix system, instead of fedora, probably because of the presence of /gnu
<roptat>or some other hint that you have guix installed
<roptat>so it's fixed upstream
<civodul>rekado_: re ant-bootstrap, so you had to downgrade both gcc and glibc, right? it's not enough to just downgrade glibc?
<civodul>does gcc@5:lib or glibc@2.28 shows up as a reference of the final icedtea/openjdk?
<civodul>if not, i'd say it's ok
<rekado_>civodul: it’s possible that none of the downgrades are necessary (or fewer of them).
<rekado_>civodul: what really fixes the problem is the removal of a call to “free” in the native parts of Classpath.
<rekado_>the problem manifests itself as an inability to reliably detect if a file exists.
<rekado_>that’s why ant-bootstrap fails to find version information (which is provided in a separate file)
<rekado_>the “native/jni/java-io/java_io_VMFile.c” file includes a call to “free”
<rekado_>commenting that leaks memory but it also fixes the procedure.
<rekado_>it’s possible that this is all that’s needed to fix the problem.
<rekado_>(+ another patch later to fix bitrot)
<rekado_>g_bor[m] wanted to confirm that the openjdk can be built with a smaller patch
<rekado_>i.e. without all the gcc and glibc downgrades.
<Marlin1113>oh ok
<Minall>Hello guix!
<Minall>I'm trying to install some packages with emacs-guix, but I'm getting an error
<Minall>What should I do?
<Minall>Maybe the error is because the package is from emacs?
<joshuaBPMan>morning guix. I'm running nginx from /srv/http/, which is a symlink to my ~/prog/ (programming) directory. Trying visit the site at localhost:8080 and nignx is telling me "403 Forbidden". I'm not certain what I am doing wrong...
<joshuaBPMan>I suppose I could try to sudo chown nginx -R /srv
<Minall>When trying to install a package on emacs-guix, I got the messages: The process begins ... Then 'The following package will be installed: then the package... and then this message: guix/profiles.scm:292:22: Throw to key `srfi-34' with args `(#<condition &profile-collision-error [entry: #<<manifest-entry> name: "emacs-dash" version: "2.16.0" output: "out" item: "/gnu/store/qwm0zza4h8jfw15nqvla86z9yg6fw3yl-emacs-dash-2.16.0" dependencies:
<Minall>() search-paths: () parent: #<promise #<procedure 22bd320 at guix/profiles.scm:309:61 ()>> properties: ()> conflict: #<<manifest-entry> name: "emacs-dash" version: "2.16.0" output: "out" item: "/gnu/store/wd7pmrgb54skkkv2f3yiz9vwhsr5svpf-emacs-dash-2.16.0" dependencies: () search-paths: () parent: #<promise #<procedure 237ad60 at guix/profiles.scm:428:58 ()>> properties: ()>] 22a2420>)'. And no installation, the last message I get is
<Minall>'Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue
<joshuaBPMan>Minall: what are you trying to install?
<rekado_>Minall: it says that there’s a conflict.
<rekado_>Minall: there would be two different variants of emacs-dash in your profile.
<Minall>I'm trying to install emacs-all-the-icons
<Minall>It happends when I'm trying to install any emacs packages
<rekado_>Minall: upgrade the other emacs* packages in your profile first
<Minall>Maybe is because I'm inside emacs?
<Minall>Ok!, on it
<Minall>I'll upgrade them
<null_radix[m]>does anyone know where the source for guix documentation live?
<rekado_>null_radix[m]: it’s in the git repository with the rest of Guix.
<rekado_>see doc/guix.texi
<null_radix[m]>oh nine
<civodul>rekado_: what about committing the remove-free patch and the fix-bitrot patch first?
<civodul>then we'll see if something else is needed :-)
<null_radix[m]>umm rekado_ would you happen to know how to build the documention?
<null_radix[m]>i don't see an documention on build the documention
<olivuser>which packages do I need to install for html5 video playback to be possible?
<Minall>I make that question too ^
<roptat>Minall, probably nothing special, but you need to check or uncheck a box in the newtab page I think
<joshuaBPMan>does someone have an example of a file-like object for a hosts-file?
<rekado_>civodul: sure, I’ll try to do this tonight.
<rekado_>(+ rebuild of openjdk)
<rekado_>null_radix[m]: the documentation is provided as an Info document.
<rekado_>the source file is doc/guix.texi
<rekado_>null_radix[m]: what documentation format are you interested in generating?
<rekado_>texinfo sources can be used to generate to HTML
<nckx>efraim: Thanks for fixing that very strange duplicate ‘/bin/sh’ line. It's not clear to me how that could happen.
<efraim>nckx: it happens
*nckx looks up what's emacs for ‘duplicate current line’ and if it's fat-fingerable, I guess.
<rekado_>roptat: I’m reviving the attempts to provide a guix-cookbook document. I’m getting this error upon running ./bootstrap:
<rekado_> error: 'version.texi', included in 'doc/guix-cookbook.texi', also included in 'doc/guix.texi'
<rekado_>is it a problem for version.texi to be included from two different documents?
<rekado_>maybe you know this
<roptat>I have no idea
<rekado_>I’ll see if I can figure it out; if not I’ll just generate a differently named texi snippet for use in guix-cookbook.texi.
<roptat>for translations, we have a different version.*.texi, but they all have the same content...
<rekado_>that’s good to know
<roptat>they're generated by the makefile, so it's not really an issue
<rekado_>maybe I’ll just do that
<roptat>their filename needs to start with "version" iirc
<Minall>Thanks guix, I updated guix and now I'm able to install packages
<rekado_>one more thing: to add guix-cookbook to the translation project, do I need to write email or is this something we can do by ourselves?
<katco>are there any cmake/llvm/cpp experts available to help me package something? i haven't been able to make any progress on this:
<roptat>rekado_, if we want l10n, we'll have to send a new tarball to the TP I think
<roptat>you'll just have to make sure "make dist" generates a pot file that we can send to the TP admins
<roptat>or we could have both in the same file as the manual, I don't know
<dongcarl>looking at the log... `master` was just merged into `core-updates`?
<dongcarl>Does that mean a release is coming soon?
<dongcarl>just = a week ago
<vagrantc>it keeps re-merging from master to keep it in "sync"
<vagrantc>though i heard mumblings on the list that it would be merged "soon"
*dongcarl needs to look at list
<vagrantc>rekado commented on #36685 making it sond likely soon :)
<dongcarl>mbakke: So I've been reading your gcc bump commits, mostly trying to understand implications around cross-compilation...
<dongcarl>From what I understand... We will no longer use `CROSS_*_PATH`, but rather `CROSS_CPATH`?
<vagrantc>so, diffoscope has a huge number of optional features that are enabled when additional packages are installed, and also runs the test suites ... should i add all the optional packages to native-inputs so all the functionality is tested?
<janneke>hey dongcarl, did anything come out of a discussion about something like guix environment --target/--cross?
<janneke>civodul had a vague recollection of something like that
<dongcarl>janneke: No I don't think so... I believe we agreed it should be done, but nothing came of it
<janneke>dongcarl: ah, okay :)
<dongcarl>I do hacky things for my Bitcoin Core builds just to make it work...
<dongcarl>Building my own cross-toolchain packages and setting env var gets me thru most of it
<janneke>yeah, i started hacking sh stuff too and ^C'ing a build also works...
<dongcarl>janneke: Lollll what a hack
<dongcarl>janneke: Are you doing this for something mingw-related?
<janneke>dongcarl: later i learned to add #f at the end of configure stage or something like that ;)
<dongcarl>I'm pretty sure the latest mingw 6 bump broke something...
<janneke>dongcarl: yes, i'm looking at mingw-64 atm
<janneke>oh? i just started after not looking at it for years, and it seems to work...
<dongcarl>Here's something that doesn't build with our latest mingw 6.0:
<dongcarl>The problem is `_tcscat_s`
<dongcarl>but I can't figure out the cause
<dongcarl>Let me know if you can reproduce
<dongcarl>(this compiles fine on Ubuntu)
*dongcarl goes to have lunch, will be back
<janneke>dongcarl: enjoy
<janneke>dongcarl: not sure how to reproduce; i need `-D MINGW_HAS_SECURE_API=1' also before the mingw-6.0.0 transition
<janneke>(note that i don't really know what i'm doing or what the secure api is...)
<janneke>dongcarl: iow: this works for me before and after mingw-6.0.0
<janneke>wget -O
<janneke>[..enter mingw environment]
<dongcarl>janneke: Back... Oh but it doesn't work without the `-DMINGW_HAS_SECURE_API=1`?
<dongcarl>janneke: How are you constructing the mingw environment?
<janneke>dongcarl: right, not without that define
<janneke>dongcarl: i use `mingw.scm': and do guix environment -l mingw.scm
<dongcarl>janneke: Ah yes that fixed things for me... Thank you! BTW, I hacked up a version of mingw toolchain with posix threading... I'm not sure how to upstream it though
<janneke>dongcarl: i just read tchar.h and saw that define
<janneke>dongcarl: that's pretty nice!
<dongcarl>should we just adhoc define a triple like `x86_64-w64-mingw32-posix`?
<janneke>you may have noticed that i didn't upstream my mingw patch either -- i could not figure out where/how the mingw(64?) community is organized
<dongcarl>Oh no I mean for guix!
<janneke>ah :)
<dongcarl>so for ubuntu, they do this: `x86_64-w64-mingw32-gcc-posix`
<janneke>does it harm to enable threads by default/for everyone?
<dongcarl>as a suffix
<dongcarl>janneke: well, some people might want win32 threads
<janneke>ah, and that needs a whole different toolchain, or gcc, or mingw package?
<janneke>dongcarl: best to ask/discuss this question on guix-devel
<dongcarl>janneke: Okay, I'll gather up some links and facts and post it on the list
<janneke>dongcarl: great, i'm hoping davexunit will also weigh in
<janneke>have you looked at darwin at all yet?
<janneke>for a cross build, i mean
<dongcarl>janneke: Not yet... But we've got a lot of work done already in our Bitcoin Core repo... It's just about porting it to Guix
<dongcarl>janneke: This is the key:
<janneke>hanwen created a cross build environment for darwing ~15 years ago but i'm not sure if that could be resurrected
<janneke>nice, and that's all free software, more or less ready to be packaged for Guix?
<dongcarl>janneke: The MacOS SDK is not free software unfortunately
<dongcarl>and we need the sdk for compilations to work
<dongcarl>I'll dig more into it, but if it turns out it can't be in Guix proper I'll start a guix-nonfree or something
<janneke>oh, then we'll need to look at other options; possibly hanwen's work
*janneke needs to go afk, bbl
<dongcarl>cya, lemme know if you have a link for his work
<vagrantc>is it possible to pass extra native-inputs to a build from guix build ?
<vagrantc>i want to iterate through adding various inputs for tests and editing the file each time is a bit cumbersome
<janneke>dongcarl: it's part of lilypond's GUB; I think the canonical source now lives here
<janneke>vagrantc: you could maybe modify the package something like (define-public pkg ... (native-inputs `(... ,@extra-inputs)))
<vagrantc>where does extra-inputs come from?
<janneke>vagrantc: and then call something like guix build -e '(begin (set! extra-inputs ...) pkg)
<janneke>not sure if that works, you may have to use module-define! instead of set! ... i'm thinking out loud...
<vagrantc>also building diffoscope explodes whenever adding #:use-module (gnu packages android) ... complaining with tons of "variable X not found, did you forget to add Y?"
<janneke>ah, ugh ...
<janneke>you don't really like small challenges eh? ;)
<vagrantc>to add all the possible tests, i'm wondering if diffoscope still belongs in package-management.scm or if somewhere else might be a better home ... still don't understand the implications of all the use-modules entries
<vagrantc>janneke: well, as i've been finding and adding additional optional packages for diffoscope, i realized that it was probably skipping most of the tests ... and that's not good
<vagrantc>since it only runs the tests if the tools are present
<janneke>ah, so you're finding-out new things each iteration...
<vagrantc>trying just to get the number of skipped tests down by adding additional tools to the native-inputs ... hope that's a reasonable way to approach it
<vagrantc>though it will make diffoscope builds have a lot of dependent packages
<vagrantc>also wondering if it would make sense to add a diffoscope-with-all-the-features-enabled package
<vagrantc>a metapackage or something
<janneke>if a tool is not present at build time, but installed by the user, does diffoscope still pick that up and use it at runtime?
<vagrantc>from PATH
<janneke>hmm, yeah, so your diffoscope-with-all-the-features-enabled package could depend on diffoscope and a selection of tools and then only run tests in its build
<vagrantc>"diffoscope --list-missing-tools guix" will show you tools it wants that you don't have installed, and even suggest what guix packages to install that it knows about
<vagrantc>janneke: that's one idea
<janneke>or maybe add that as a guix system test even?
<vagrantc>it's a user-installable package, so not sure what a system test would be ...
<janneke>a meta-package could be handy to install all tools at once
<vagrantc>i've been doing things like: guix environment --ad-hoc diffoscope .... diffoscope --list-missing-tools guix ... cut-and-paste ... guix environment --ad-hoc diffoscope all-the-other-packages
<vagrantc>which is a bit cumbersome
<vagrantc>been teaching diffoscope a few new guix packages and packaging a few more
<janneke>yeah, if your metapackage could depend on an already-built diffoscope, then the round-trip test time could be acceptable?
<janneke>...if you can get that to work, running the tests that way
<vagrantc>should work, as long as inputs are installed ... but at the moment, i'll just try to work with diffoscope and adding more things to native-inputs to enable more thorough testing
<vagrantc>native-inputs is only installed at build-time, right?
<vagrantc>also been working on packaging a few of the missing tools
<dongcarl>janneke: Thanks for pointing out `-DMINGW_HAS_SECURE_API=1`, I was stuck on that for a few days. Just unblocked me :-)
<janneke>dongcarl: good :)
<civodul>oh, /usr/bin/env
<sebboh>Hm. I just created a new user and copied /etc/skel to make their home directory. But when I do `guix install foo` for them, I get some old version of foo. Now, I should just run `guix pull` first, I get that. But, how'd that even happen?
<sebboh>Actually I get an error when I guix pull with this new user. *deep breath* Ok, I'll create the user the guix way.
<civodul>sebboh: yes, you should create it the guix way :-)
<reepca>if you're on Guix System, the user's path most likely only includes /run/current-system/profile/... so they're basically running the "system" guix - the one that was used to create the current system generation. Which, does tend to be more out-of-date than the user ones.
<sebboh>ok, thank you
<reepca>or more accurately, the system profile would be the only part of the path with anything in it. If you just copied /etc/skel, then there's no ~/.config/guix/current or ~/.guix-profile
<vagrantc>how do you add an input for giflib:bin instead of giflib?
<vagrantc>found an example...
<vagrantc>("giflib:bin" ,giflib "bin")
<vagrantc>hrm. worked for giflib:bin but not openjdk:jdk
<vagrantc>do i need to specify a specific version of openjdk:jdk?
<reepca>vagrantc: you did ("openjdk:jdk" ,openjdk "jdk")?
<reepca>hmm, looking through (gnu packages java) it looks like although we have packages named openjdk, we don't have any of them bound to a symbol named openjdk. So yeah, ,opnjdk10 or whatever version will be necessary.
<vagrantc>+ #:use-module (gnu packages java) ... + ("openjdk:jdk" ,openjdk "jdk")
<vagrantc>how to pick the version?
*vagrantc just goes with openjdk12 since it's what guix environment --ad-hoc openjdk:jdk pulls in
<janneke>,openjdk (or ,openjdk10) are identifiers (define-package <identifier>
<janneke>you probably knew that :)
<vagrantc>janneke: given i'm not exactly sure what you mean, i'm not sure :)
<vagrantc>327 passed, 99 skipped, 1 warnings in 58.55 seconds
<vagrantc>that's down from ~140 skipped :)
<Minall>Hello guix!
<Minall>unable to mount, unknown filesystem 'exfat'
<rekado_>Minall: you’ll need exfat-utils and fuse-exfat.
<Minall>rekado_: I have them installed
<Minall>But I'm still unable to mount
<rekado_>what command do you use?
<Minall>Trying to mount it on a file manager and I get that error
<Minall>If I do a mount /dev/sdb /mnt I have the same error too
<rekado_>and if you use mount.exfat?
<rekado_>(if that exists)
<Minall>Let me try
<Minall>It should exist, since I'm
<Minall>since I have installed exfat-utils and fuse-exfat
<vagrantc>what inputs are installed in all build environments?
<Minall>rekado_: I got this error:
<Minall>FUSE exfat 1.3.0
<Minall>ERROR: unsupported FAT count: 2.
<vagrantc>i'm seeing a lot of tools that diffoscope uses and the tests seem to pass regardless weather i add them to native-inputs or not...
<Minall>What should I do?
<civodul>Minall: could it be something with the device you're trying to access?
<civodul>i've used mount.exfat successfully on Guix System
<Minall>I'm not sure... How can I check?
<Minall>I can mount the device in another systems
<vagrantc>so are there significant considerations about how many use-modules entries to use in each file?