<vagrantc>so, i conceptually knew about the existance of "guix system container" and "guix system vm" ... but i didn't try them till today... amazing! <atw>that code you just pasted is for Emacs. Are you using Emacs? <atw>ok cool. You can put it in your init.el <atw>and it's assumed in that snippet that your checkout of guix is located in ~/src/guix <vagrantc>with guix container i'm not able to login via ssh as it's trying to use /bin/bash instead of the user's shell from /etc/passwd ***jonsger1 is now known as jonsger
<apteryx>civodul: o/. About 'guix build -K' implicitly not offloading: is there a way from the command line to have it offload anyway? like, --no-offload=no ;-). I'm using an offloading machine to ease with debugging builds, but having to re-issue 'guix build /path/of/drv -K' on the offload target is a bit annoying :-) <bavier`>nckx: in 31afa65 you undid some "overzealous substitution"; would you care to fix the resulting build failure? ;) <akoppela>Everytime I'm running guix system reconfigure I got following error <akoppela>guix system: error: symlink: Permission denied: "/var/guix/profiles/system-2-link.new" <akoppela>Am I suppose to run the command with `sudo`? <akoppela>Or am I missing 14:24 <akoppela> Everytime I'm running guix system reconfigure I <vagrantc>non-administrator users shouldn't be able to rewrite your operating system :) <vagrantc>they can manage their own packages, of course :) <vagrantc>strictly speaking, -E may no longer be necessary, but it doesn't hurt. <str1ngs>divansantana do you have the same problem with icecat? <g_bor[m]>I now have a working postfix package, just got down to write a service. <g_bor[m]>I intend to include this in one series, as the package can't be used without the config file, as the path is embedded in the binary. ***apteryx is now known as Guest21047
***apteryx_ is now known as apteryx
<vagrantc>well, i managed to try to build guix by deleting all the patches in gnu/packages/patches, commenting out dist_patch_DATA in gnu/local.mk ... now i just need to patch search-patches to be a no-op ... and maybe my crazy idea of a patchless guix will work <g_bor[m]>vagrantc: interesting. May I ask what the motivation of doing that is? <vagrantc>g_bor[m]: gnu/packages/patches has ... unclear licensing ... it's pretty much the last hurdle to include in debian <vagrantc>g_bor[m]: my goal was to produce a guix that could at least run guix pull <vagrantc>and then i can ship it without the patches... <vagrantc>maybe i just need to purge gnu/packages* <g_bor[m]>I authored some of these patches, and would be willing to clarify licenses on those. What would that involve? <vagrantc>many of them are just grabbed from upstream... <g_bor[m]>I don't believe that would just work as is :-) But it would be really useful to identify a core set of packages, that are really needed. There is some invisible connection through implicit inputs... <vagrantc>the other approach is to do what civodul did with the bootstrap binaries <g_bor[m]>This reminds me that I have to be more careful when authoring self-standing patches. <vagrantc>e.g. download them at runtime if not present <vagrantc>but it seems we can even compile all the .go modules that reference the patches without them <vagrantc>but a guix built from git ... shouldn't need any of the guix packages no? it should just use guile and guile libraries that it was compiled with? <ng0>vagrantc / everyone else: what about a license disclaimer in the patches directory for the most common patch case (grabbed from upstrema) if we ever forget to refer to it? <vagrantc>maybe guix lint should check for licensing with included patches... <terpri>that's not precise enough for debian iirc, debian/copyright has per-file licensing info <vagrantc>per-file is preferred, but not required if there's clear documentation <vagrantc>alternately, if i could just build guix-daemon without the rest of guix ... that might also be a way to move forward <nckx>ng0: Fine by me, although I'm not sure how authoritative (if that's the word) such a catch-all file would be. And if it were: we do already have COPYING at the top level. *nckx off to see how Debian handles this for their own patches. <ng0>just claiming one license for a patch which wasn't taken from upstream will make it harder to upstream it if the intention to do so arises when the original author is dead or otherwise incapable. guix is young enough to not have this case yet, but this is one problem i see with per-file licenses <vagrantc>well, a catch-all for upstream licenses would be different for each random project pulled from, and *might* not be compatible with upstream if they're sloppy. <ng0>which is why i personally think it's not necessary <vagrantc>so the top-level copying file is certainly not accurate if you're pulling patches from arbitrary projects on the internet <ng0>vagrantc: but you can relicense <ng0>if the author is alive, etc. <vagrantc>it's mostly just a sheer numbers problem <vagrantc>guile can't seem to make use of more than 8 cores when building guix <ng0>ok, maybe a step back would be where does debian see the problem in the distributed source of guix? or are we talking about more than the distributed releases? <ng0>since the way icecat or bash etc pull patches is different from the directory <ng0>that's not arbitrary patches, it's clearly licensed upstream work <vagrantc>the patch files are certainly licensed under some unknown license which is *presumably* but not verifyably consistant with the license of the project ... additionally debian gets a bit pedantic not just about license, but actual copyright holder needs to be documented <vagrantc>ng0: clearly would be saying what license it is under and where it came from <vagrantc>but right now it's just a bunch of files in a directory, for the most part <vagrantc>all relevent to many arbitrary upstream projects... i'm assuming they're mostly upstream patches... the handful that are guix-specific i suspect we can easily get clarity on it <ng0>assuming that patches for software can be upstreamed in all cases is very utopian in my experience. <ng0>i think we can still put a license on them, but <ng0>how do they fit into the context of guix as a software? <ng0>they aren't part of guix <ng0>they are applied on software build later on with the installed guix <vagrantc>if they're shipped in git and/or tarball, and guix fails to build if you remove them, it's hard to see how they're not part of guix :) <ng0>for the build-system, i agree <ng0>but not for the programmatic part <ng0>and simply slapping all the licenses on them we can find for upstream feels odd? wrong? <vagrantc>authorship/copyright holder and licensing is what i need, which is a bit more pedantic than what guix has done <ng0>otoh the more pragmatic approach could be to 0BSD / Public-Domain them, then both sides get to be happy <ng0>used in places where people bought into uncertainties of public-domain statements, or by people who want to make sure they satisfy those people (like i did) <nckx>vagrantc: Is Debian really blocking Guix because of this or is this just you being thorough? <vagrantc>nckx: i am fairly sure it's reasonably likely this could be a blocker, though it might possibly slip by <nckx>You could say there's some top-level copyright file somewhere taking care of it but try finding it from that URL as a non-Debianist. <vagrantc>nckx: that's also simple enough that it's arguably not copyrightable <ng0>it just needs to be checked patch by patch <vagrantc>i should get some sleep and bring it up on the list <ng0>and this needs is a "could be" because it doesn't seem very likely unless done by multiple people and with a focus <civodul>vagrantc: so the licensing of patches is causing troubles? <civodul>i'd say that most are "not legally significant", and all implicitly fall under the license of the project they apply to <civodul>my impression is that Debian doesn't really do it differently, does it? <ng0>more projects than guix got away with the way of it being implicit for over 20 years.. but if it could be clearly stated that would be nice <vagrantc>i've gotten packages rejected over similar issues, and there are just so many files to review, someone will likely squit funny. or not. <vagrantc>each individual patch might, on it's own, be okayish ... but the sheer number of them all in one package <vagrantc> 1646 files changed, 24097 insertions(+), 26233 deletions(-), 7 modifications(!) <nckx>vagrantc: That's neat. How d'you generate that? <vagrantc>my fantasy would be to have ./configure --without-packages --with-guix-daemon --with-guix-minimal ... or some such <vagrantc>guix-minimal being a build of guix without any knowledge of packages, just guix pull... <civodul>to run "guix pull", you need the package definitions for the closure of Guile etc. <ng0>speaking of patches, are there people who (try to) upstream them sometimes? <civodul>ng0: it's always been the (unwritten?) policy, except for patches that are Guix-specific <civodul>vagrantc: so i guess there's currently no good answer to that :-/ <civodul>perhaps just see what fellow Debian hackers think? <ng0>still looks like it got stalled or at some point upstreams stopped accepting, the regular numbers like I have in pkgsrc <vagrantc>civodul: there's always upload and hope for the best :) <ng0>so far my acceptance of patches remains mixed but leaning towards acceptance <civodul>vagrantc: or if you think it's likely to be controversial, then let's discuss it upfront and see if there are practical steps we can take <civodul>based on the feedback of other Debian developers <vagrantc>guix as a whole does a great job of documenting licensing ... it's just this one class of files :) <civodul>maybe moving forward we could add SPDX identifiers to those files <ng0>asking because i've been thnking about setting up a guix development machine again and instead of finalizing lots of packages I made, I could upstream some patches <civodul>but that's more of a long-term solution <vagrantc>there's also a certain amount of "believe what upstream says about licensing unless proven otherwise" in debain <nckx>Agree. Meanwhile I've found some clear examples of non-trivial uncopyrighted patches in Debian but don't let's throw fellow packagers under the bus. <vagrantc>oh... the other issue is that tests fail too often :P <nckx>Foreign distro wizards, hit me with your cluestaff: error: failed to run download program '/home/fedora/guix/scripts/guix': Permission denied <efraim>we should check his other packages <Darth>I do development using IAR and Renesas Synergy framework. <Darth>I need to interface with guix but can not find any example showing how to do with LCD display using SPI <Darth>Only examples using parallel bus <Darth>Anyone know if such example exist ? <nckx>Darth: I think you have the wrong Guix. This is the channel for GNU Guix, a functional software package manager. <ng0>the curses based installer is good :) <efraim>nckx: I assume you mean about the ownership. You made sure you own the files and not root or something, right? <nckx>efraim: ‘we should check his other packages’ appeared here without context, I see there was a netsplit around that time though. <efraim>joeyh took the opportunity on palendrome day to release git-annex 7.20200202.7 <nckx>logs.guix seems to have lost some dialogue then. <nckx>efraim: -r-xr-xr-x 1 fedora fedora 1.9K Jan 14 19:00 /home/fedora/guix/scripts/guix <NieDzejkob>following commit a76a343082d61d5303b61a9e4cbde4ab8515a1e7 (currently on core-updates), the patches cmake-curl-certificates.patch and kodi-set-libcurl-ssl-parameters.patch shouldn't be necessary anymore. Could someone familiar with either cmake or kodi test that this is indeed the case? <g_bor[m]>in the context of a mixed-text-file how can I refer to an output different from "out"? <ng0>how much of an edgecase would be a bugreport on the installer where it doesn't clean up (Net)BSD disklabels and you end up with 2 disklabels at the end of Guix setup :D? <ng0>(i know how to fix this by hand btw) <nckx>ng0: A perfectly valid one 🙂 <nckx>If you don't include a patch, please do describe what exactly would need to be done. <jonsger>nckx: are the bootstrap tarballs working? *nckx has been staring at ‘guix build’ output for ~20 minutes now without any errors. This might be the run that works. <ng0>i think i can't come up with a patch yet, this is my way to setup guix again. every other laptop runs NetBSD, even the work laptop is kind of before-failure <ng0>I'll include a screenshot and a description <nckx>Guile works, thanks for your ‘hint patch’ to use 2.2. (I'm trying to get there without copying any code verbatim, for security raisins, but your work was a great help.) <nckx>ng0: That's already great. <ng0>i don't like it, one of the few times i have to literally sent a picture taken of the screen <jonsger>nckx: don't forget to make the commit messages verbose, so we know what we did today in a year :P <nckx>2.0 just dies at ‘Unhandled exception’ [freeze], debugging that would have been tedious and useless. <nckx>jonsger: Yeah, I'm keeping a log but there's already a magical step :-/ The ‘Permission denied’ error I got above just suddenly went away. I think. I certainly don't know what I could have had to do with that. <ng0>hm, i guess i should do the patch though.. i have a perfectly functional testcase i can reproduce <ng0>it will be harder to come up with an arbitrary one <nckx>ng0: Oh, interesting. Blocklists aren't something we should support at all IMO. I must admit I don't really understand what's happening, but that would probably become clear if you explain how you fix it up by hand. <ng0>this is a Lenovo T60 which ran NetBSD 8.1 before that. NetBSD like I think every other *BSD has its own bootloader. <ng0>i think removal succeeded <ng0>but the label stayed <ng0>I had this happening in the past before <nckx>ng0: Is this something that wipefs could take care of? (Sorry if I'm way off 🙂 ) <ng0>i have to look into wipefs <ng0>i'm not sure if i'm reading the output right, but it might identify our FFS partitions as type atari o.o <ng0>i'll give wiping a try <efraim>it turns out on debian I can run terminology or even enlightenment in the frame buffer <efraim>rather suprising when I thought it'd be launching enlightenment in wayland <jonsger>nckx: thats at least the same error I see :P <jonsger>efraim: who is we? and what working on? <ng0>I'll see what I can come up with an send a bugreport <efraim>jonsger: there was a suggestion to freeze core-updates around fosdem and then work on merging it but I didn't see a freeze email <efraim>civodul: I'm building the packages in my profile on core-updates, making sure they're good <divansantana>str1ngs: icecat does the same (after disabling all the extensions), incorrect timezone. <NieDzejkob>divansantana: for IceCat, try setting about:config -> privacy.resistFingerprinting to false, check if persists <NieDzejkob>make sure to restart the browser afterwards to make the changes apply fully ***wingo_ is now known as wingo
<civodul>janneke: just sent a patch for commencement.scm, let me know what you think! <PurpleSym>Has someone written a tool to mass-import packages using `guix import` yet? I’m mainly looking to automate `git commit`, which should produce one commit per package, right? <leoprikler>PurpleSym: I'm pretty sure you want to perform checks on the imported package before commiting. <leoprikler>There are commit snippets though, that might help you, specifically "Add package". <divansantana>str1ngs:time is correct then with icecat. So what does this mean? <str1ngs>divansantana: I'm not sure, it's not a QT issues directly. it's something related to qtwebengine or javascript. but since I can't replicate it... <civodul>divansantana: our IceCat has a privacy option enabled by default, which has it not disclose its timezone to web servers <str1ngs>divansantana: also you are using UTC and not localtime right? <civodul>(that's led me to have problems with meetings at work since the agenda is in a web service :-)) <jonsger>seems to be something we want to test properly :P <mjw>civodul, cool. And sorry I didn't give any more feedback on it. Really just got home. <str1ngs>divansantana: I think date is working right but double check with. date +"%Z %z"; cat /etc/timezone <civodul>mjw: np! the pressure was high enough that several of us started looking into it :-) <mjw>civodul, I was able to pitch GNU Guix to a RH lawyer. He seemed to like what you are doing (including the make sure all sources are always at the software heritage part) for compliance reasons. <civodul>i actually got in touch with someone from a company interested in this in the context of containers <mjw>I doubt RH will adopt guix wholesale soon :) <civodul>they saw Guix as a tool that could help them have better provenance tracking than with Dockerfiles <mjw>But for the lawyer the guix concepts are really nice. They are thinking about what it means to make sure to ship corresponding source code for everything we release (which RH does, it is a good company). <civodul>right, the functional model gives a faithful implementation of the "Corresponding Source" <mjw>NieDzejkob, yeah, that is the company I work for. *jonsger never showed guix the SUSE lawyers... <mjw>I don't work on guix for the company though. I just happened to run into one of our lawyers the other day who was indeed pondering containers and products and making sure corresponding source code is always shipped. <civodul>mjw: sure, no need for a disclaimer ;-) <civodul>"i do not speak for my past, present, or future employers" <pkill9>you could have an option to automatically download the source with all the substitutes, so the source code is always provided with the binaries <mjw>I better, because I do think we (RH) have the best lawyers. People might otherwise think I am nuts :) <jonsger>civodul: interestingly the guy who wrote this guix files seems to work vor VMware <civodul>there's been a couple of nice LWN articles about their work <kahiru>hey, I'm trying to import a package from nix and it i salready running for like 10 minutes, is that normal? <civodul>so the main shortcoming in Guix here is the image size, as often <civodul>kahiru: unfortunately the Nix importer seems to not work for recent versions of Nix/Nixpkgs <civodul>if you're familiar with Nix, it'd be great if you could take a look :-) <janneke>civodul: maybe "someone" could write "somewhere" "something" about changing that <kahiru>I'm familiar with it as a user, but the language is driving me away <civodul>janneke: it's popped up several times in Brussels (embedded, containers, etc.), so i'm sure this will happen <civodul>and there can be regressions at any time *civodul laughes behind his screen <civodul>hmm looks like Guile 3 needs a lot of time to build gnu/services/mail.scm <kahiru>civodul: btw how do you define "recent"? <civodul>kahiru: hmm "less than 5 years old" maybe? :-) <civodul>that's about the time where i stopped paying attention <zimoun>mjw, civoldul: zack from SWH told me at FOSDEM that some people use the archive to claim copyright when some projects re-license the ugly way. It is unexpected, I guess, but could interest the good lawyers. :-) <civodul>zimoun: yes, that's one of the use cases apparently <zimoun>nckx: have you fixed your permission error? <nckx>zimoun: Not consciously, it ‘fixed itself’ which I don't like. Why? <zimoun>just to know because I never encountered such issue on foreign distro. So curious. :-) <zimoun>civodul: really interesting, isn't it? :-) Speaking about SWH, have you meet lewo at FOSDEM? <nckx>zimoun: It's a common error on Fedora, but it's always been SELinux-related and disabling SELinux (or applying our incomplete policy) has always fixed it. So this is different, and weird. <civodul>zimoun: yes, lewo and i briefly discussed before my talk, which was nice! <civodul>lewo has been going great work on SWH <zimoun>civodul: cool! Yes, really nice work... it will be a killer feature for scientific people. ;-) <lewo>zimoun: nice to see you are interested in;) <jonsger>ggaaattyp stands for "GNU Guix as an alternative to the Yocto project". Verbose naming as it's best :P <zimoun>lewo: cool you are here. Did not know. :-) <zimoun>lewo: I have tried to read the SWH bug tracker entry, but not able to follow. <lewo>zimoun: ahah... that's really hard for me as well :/ <lewo>zimoun: but I should meet the SWH team next week. So, i think this will move faster on it soon. <zimoun>lewo: cool! if you are in Paris and you want to drink a beer, feel free to contact me. ;-) <lewo>To sumarize, i think all of their comments are addressed. So, it almost ready to be merged. On the NixOS side, since 1 week (WIP), we are exposing a sources.json file (which will be consumed by the SWH lister) <lewo>zimoun: ah, that would be cool! But I'll not have enough time during my next visit <zimoun>using the proposed format in the thread, right? ***ng0_ is now known as ng0
<mbakke>woah, TIL you can comment a sexp with #; <janneke>mbakke: yeah, i cheered about that until i reopened the file in paredit mode :-/ <civodul>zimoun: we have packages-json-builder in the web site that we should update/fork for the new format <nckx>How does paredit break sexp comments? <civodul>nckx: when you visit a file that has such comments, it fails to load *nckx got the usual amount of paredit proselytism at FOSDEM but hasn't tri—oh wow. <mbakke>civodul: the ssh tunnels to dmitri and sergei appears to be down (or the machines themselves) <nckx>The EmacsWiki answer to this class of problems is ‘no no don't ever not use paredit’. 😒 <nckx>civodul, mbakke: I can SSH into both. Must be the tunnel. <civodul>mbakke, nckx: oh that's because the tunnels goes through "my" OverDrive, and there's a network outage at home since ~2PM <civodul>i could have them go through some other machine in the meantime <civodul>hmm not sure what machine i could bounce on <lispmacs[work]>hi, I want to know what commands/capabilities are available in early boot guile shell, but am having trouble finding the documentation for it in the Guix manual <mbakke>I wonder if we should remove GCC 4.7 and 4.8, as they haven't been building for some time <zimoun>civodul: yes, I have looked at that but not enough time yet to update the "exporter" to the new format. Let see if I am able to make this week. :-) <civodul>mbakke, nckx: seems to be back on-line! <civodul>mbakke: we need a tunnel because of the firewall at the MDC that wouldn't let it through <civodul>rekado_ registered some of the IPs we need but it takes time to get IT to do that <civodul>atw: ah yes, someone reported it during the Guix Days, marusich and i discussed it briefly and came to the conclusion that... something's wrong <civodul>may have to do with %file-port-name-canonicalization <azymohliad[m]>Hi all. New guix user here. Everytime I run guix it complains about locale (guile: warning: failed to install locale). Could anybody please help me to fix it? I'm on ArchLinux, I have `LANG=en_US.UTF-8` in my /etc/locale.conf. <civodul>atw: could you report it to bug-guix so we keep track of it? <nckx>What's the default GCC on c-u? <nckx>lispmacs[work]: There are two ‘languages’, regular Guile (the default) and ‘bournish’ which gives you a very basic ‘shell’. However, PATH isn't set and even if it were our initrd doesn't have (need) the coreutils/busybox that other distributions traditionally use to script the boot process. So IMO bournish is currently a neat PoC, not a useful tool. The Guile REPL can do anything the initrd needs to do. I sometimes use (mount …) & frie <nckx>nds to rescue a wonky RAID system. There is no documentation for those procedures besides the docstrings in the code. <nckx>Conclusion: both suck. Enjoy. <divansantana>str1ngs: date +"%Z %z"; cat /etc/timezone SAST +0200 Africa/Johannesburg <divansantana>str1ngs: Another thing, I see I can't print to PDF for some reason in qutebrowser. I had qutebrowser before via nix on guix and print to pdf worked. Does it work for you? <valignatev>efraim: Just watched your FOSDEM talk, really makes you think that rust devs didn't think much about how distros would package rust programs ***jonsger1 is now known as jonsger
<jonsger>does someone has rustfmt laying around? <mbakke>nckx: core-updates is at GCC 7.5.0 <mbakke>I'd like to move to 9 by the next cycle <mbakke>would it make sense to move gzip and friends over to a 'compression-core' module to avoid some of the cyclic module references? <jonsger>efraim: do we have a rust importer who adjust the variable names automatically (e.g. rust-serde-0.4 and so on) <str1ngs>divansantana: qtwebengine has pepper plugins disabled. which also removes PDF support. mostly to avoid DRM issues <janneke>sneek: later tell civodul: commencement patch looks like a nice cleanup; i have locally rebpased wip-bootstrap onto that and am seeing if that works; more later <str1ngs>divansantana: though now there is code to remove widevine which is the DRM component. it might be okay to enable pepper plugins to allow for PDF support. <valignatev>jonsger: There was a patch to implement a full blown semver importer for crates. I'm not sure it got applied though <lispmacs[work]>nckx: for inspecting the source of the boot guile, what package should I look at? <lispmacs[work]>nckx: also, would guix developers want there to be something like a (help) command in the boot guile, if somebody took the trouble, our are they wanting to keep that out for size concerns? <efraim>sneek: later tell jonsger there's patches from today to the mailing list for the recursive rust importer which should take care of all the rust import issues <NieDzejkob>huh. when I do `guix package -m my-manifest.scm', it tries (and fails) to build sane-backends, but when I do `guix build sane-backends', it downloads a substitute <drakonis>hmm, what's the easy way to build a specific package version without needing to provide a source tarball? <bavier>drakonis: if the package uses a git checkout, you can set the commit or tag to build from <drakonis>no option to just 'guix build <package>@<version>'? <bavier>drakonis: depends on if that version is packaged <bavier>'guix show <package>' would list available versions <drakonis>hm, right, as it stands, i have to install an older hplip release <drakonis>oh and what's the best way to include a channel that pulls from a local repository? <bavier>drakonis: same as usual, but use a "file://" uri <drakonis>and i have to push all changes to the git repository for them to be picked up? <bavier>drakonis: well, not necessarily *push*, but at least commit <drakonis>oh and hm, i have a problem now, using git commit tries to open up vi but i dont have it nor i have an editor flag set <nly>janneke: mes is awesome! saw the fosdem slides :) <nly>so this was the 'exciting progress', super cool! <nly>also congrats to Jeremiah and everyone else involved, gash too! <nckx>Yeah, Mes & the Hex friends are awesome. You think, no, wait, I misunderstand, that can't be right, they can't be doing $this — they are doing exactly $this. And it is glorious. *nckx fanbois unashamedly. <nly>i love your description nckx *bavier goes down for reboot <drakonis>hrm, dependencies on other channels must be explicitly declared in the channel, right? 
