<vagrantc>it's actually one of the most invasive changes, added a whole word rather than a single character <nckx>vagrantc: Descriptions aren't part of The Hash, so if you're reasonably careful, there's nothing to worry about. *nckx was AFK for a while, reads backlog. Thanks rekado_. <vagrantc>ok, 33 packages, each in their own individual commit. on to the next typos... <krafter>How can I add programs to startup automatically when I log in? Does adding for example "exec redshift &" to "~/.profile" work? <sebboh>I all. I downloaded the 1.0.0 bootable image earlier this month. Now a newer one is available. Can I boot the old one and 'update' it? Or should I just go ahead and download the new one? <sebboh>krafter: if guix system is like other unix environments... and if you're logging into the console... then this line from the bash manual will be relevant: When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, <sebboh>~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior. <sebboh>There are specific criteria that define "interactive login shell". <vagrantc>sebboh: you might be able to install with 1.0.0, but 1.0.1 specifically fixed a number of installer issues <krafter>So, .profile wont run if I login non-interactively? <sebboh>krafter: more than that.. .profile is sourced in by bash. (and maybe other shells.) Does "log in" mean "start bash" on your system? I see now that "redshift" is a program that interacts with x11, so, maybe not? <krafter>sebboh: Do you have another suggestion? <sebboh>vagrantc: I didn't see my specific issue in the changelog. But I'll give it a shot. <sebboh>krafter: I have only questions. :) It's not safe for me to assume you are using some popular desktop environment, because here we are in #guix. <krafter>sebboh: "exec startx" is the line right below the one I posted above. :-D So its not strange that it doesn't work. <krafter>There is a service runner on guix called shepherd, but I have not yet figured out how it works. <sebboh>krafter: oh. so when you log in... your login shell starts X for you. Cool. I have to type startx every time. :) Well once your X is running you may have better luck running redshift. Do you know about .xinitrc? <sebboh>... .xinitrc is something else, or nothing. I'm not sure where I got those letters from. <krafter>sebboh: oh, the solution was always right in front of me! <sebboh>cool. Don't forget, you only want to `exec` your *last* line of .xsession. The other lines should just be plain invocations.. <sebboh>(Assuming that they are daemon-like and won't just hold the session forever... Does the & suffix work in .xsession? I don't even know..) <nckx>sebboh: Yes. .xsession is just a (ba)sh script. <nckx>Reading the above, this is exactly the kind of thing I would do in my .xsession. <nckx>In fact, there's a commented-out redshift still in there from before I switched to sct. <krafter>And sebboh I don't think you need to reinstall for version 1.0.1. From my understanding it mostly fixed bugs with the installer itself. ***hoangwetrust[m] is now known as hwt[m]
<nckx>sebboh: +1. Unless you're running into bugs that keep you from simply pulling and updating your system & profiles, there's little to be won by reinstalling. <nckx>The bugs in 1.0 were all pretty boring if spectacular: ‘oops, ls doesn't work’, not ‘we create subtly corrupted file systems that die after a year’. If you got this far, you're probably fine. <krafter>nckx: "not ‘we create subtly corrupted file systems that die after a year’.". From what we have discovered so far... <nckx>Nah you're thinking of btrfs. <sebboh>Well, I didn't finish the installation, so, installation bug fixes are what I want. I already downloaded 1.0.1. :) I'll try the install tomorrow. <nckx>krafter: Oh, no, not at all, I use it a lot. It was promoted a bit too early years ago and that's how you end up being the butt of bad IRC jokes a decade later. <nckx>We do create installer file systems that are hard to boot on Macs. That might be a feature or a bug. But it's not corruption. <devilishtype>isn't the bug in the installer for the "guided" install? <sebboh>Sorry, actually, I did finish the installation but the resultant OS didn't have whatever package the 'ip' command comes from, so I couldn't get online, so I couldn't install packages.. I gave up quickly and booted back into the installer and tried to make a better config. Maybe 1.0.1 will let me use the menu-based installer. <krafter>sebboh: I had issues with the 1.0.0 installer and had to use the "manual" one. <sebboh>my specific problem with the wizard was that it didn't let me set up a static ip. I don't have a DHCP server for my VMs. *str1ngs tosses some pixie dust in the air. poof! <krafter>sebboh: One critical bug with the installer was that the %base-packages didn't get installed, including 'ip'. <sebboh>Anyway, despite some bumps in the road, building a system from a single text file made me *very happy* and I thank you all. <krafter>But, really once you have your os-config file the installer isn't really necessary. <krafter>sebboh: Any special plan for the new OS? <kabo>I need node 10 in guix, someone said I might be able to take the node 8 definition and update it <kabo>so I found node.scm, and updated the download paths and hashes <kabo>but guix package -f new-node.scm does nothing <str1ngs>kabo: in order to use -f you need to have a tail in the file <kabo>that's another thing, node.scm defines two packages, node which is v9, and node-lts which is node 8 <kabo>I updated node to v11 and node-lts to v10 <kabo>how do I tell guix I want node-lts from that file? <str1ngs>if you want more then one package from that file. then it might be better to setup a channel. or use GUIX_PACKAGE_PATH <kabo>I want node-lts from that file <str1ngs>if you just want node-lts then add node-lts as the end of the file. then use guix package -f ./file.scm <str1ngs>when I say add I mean literally add . node-lts <kabo>ok, just the text "node-lts" at th end of the file <str1ngs>though probably you want to do this via the channel route. <str1ngs>but this will get you started atleast <jje>good day! does gdm on guix system attempt to use wayland for it's sessions? if so how would i force it to dfault to using xorg, because wayland won't work with nvidia gpus. <str1ngs>jje: I have a nvidia gpu and wayland works with nouveau atleast <jje>ok well i have got gdm starting and immediately stopping over and over many times in the console. i am stumped. <str1ngs>and you are using %desktop-services? <str1ngs>do you get a virtual console atleast? <str1ngs>and it's been modeset to a higher resolution? <jje>there is service spam but it scrolls by rapidly and i cant scoll back far enough to see it <jje>yes after 505 attempts mine gives up <jje>yes i checked greeter.log and it says "fatal server error cant open /var/log/gdm/.local/share/xorg/Xorg-server-pidXXX.log <kabo>the channels page describes how to add a git repo as a channel. but what should the git repo contain? <kabo>what should I put in my git repo to make it usable as a channel? <str1ngs>kabo: if you clone the guix repository. you can modify the node file directoy. the push your changes to your git repo <kabo>wouldn't that fork guix? <kabo>I just want to add my one file <str1ngs>we I was under the impression you were modifying node ... <kabo>ah, ok, I fork guix, update node to work as I want it, and make a PR, is that how it works? <kabo>I figured I could create my own channel with node, so that I can experiment with it while still being on standard guix channel as well <kabo>and when it's all working, I can patch node in guix <str1ngs>well not PR submit patches, but for time being if you use your channel it will expose your package to guix <str1ngs>so if you do package search package -i node. it will see your changes <krafter>Can I have guix system also control whatever happens in the /etc/modprobe.d/ directory? <kabo>lunch time, see you later, hopefully it's done building when I get back <str1ngs>kabo: I hope that made sense. basically yes it a fork. but it also expose your changes to guix. eventually if you want to contribute them back upstream. you can submit patches <nckx>kabo: A channel doesn't need any metadata files or anything, just guile modules: if you want to add (kabo packages gnome), just create ~/your-channel/kabo/packages/gnome.scm that starts with ‘(define-module (kabo packages gnome) …’ — that's it. <nckx>(You can even add file:// URLs to your channels.scm if you don't want to host it just yet. But do note that ‘guix pull’ will not see uncommitted changes to that directory!) <nckx>krafter: You can extend etc-service-type to add any file(s) to /etc: (define %my-service (simple-service 'store-my-configuration etc-service-type `(("modprobe.d/foo.bar" ,(local-file … <nckx>(Untested, and you can probably specify a string directly in place of ,(local-file) in simple cases like yours.) <nckx>krafter: Then don't forget to add your services to the services field. *str1ngs adds TODO to add pcspker to module blacklist <str1ngs>that thing is annoying. and I think it gets loaded in initrd. even when blacklist it in kernel arguements <nckx>str1ngs: Oh really? I don't remember that & I used to blacklist it before switching to a kustom kernel that has it ripped out at the root. <nckx>(Not just for that, but it would be a good enough reason.) <nckx> /* DEBLOBBED DESPKRD */ <nckx>Marlin[m]: Hm, nothing yet. <str1ngs>nckx: I used (kernel-arguments '("modprobe.blacklist=pcspkr")) and it still beeps. but now no longer listed with lsmod <nckx>str1ngs: Try blacklisting snd_pcsp as well. <jje>well it seems Xorg.0.log is reporting that it fails to load nouveau, fatal server error on my gtx 1050. <nckx>Hm. Some of my mothballed configuration files blacklist both, some only pcspkr. 🤷 <nckx>I'm as curious about the effect as you are. <str1ngs>I should just not build the module, I'm using a custom kernel <str1ngs>how do I get yasnippet to generate commit messages for guix again? ***ChanServ sets mode: -o nckx
<Marlin[m]>I just asked what i can help guix with being somebody that's just starting with lisp and guile <Marlin[m]>I'm still gonna take a look a in translating stuff <nckx>Marlin[m]: Sorry, I just restarted my ZNC bouncer because /MODE seemed broken here, but it didn't help. Did you say something? <str1ngs>Marlin[m]: I just asked what i can help guix with being somebody that's just starting with lisp and guile <nckx>Yikes. I had a >160(!)s ping… that would explain it. Now all my commands are taking effect. <str1ngs>I use circe which is great. but it's not so good with znc <str1ngs>if I kill a channel buffer it leaves the channel on the znc server. which is annoying <nckx>str1ngs: Just crusty ol' Hexchat with a ZNC script or two (but it's not great by any means, I have to manually clear MSG buffers &c.). <str1ngs>I tried the emacs znc package, but it uses erc. which I don't like much <nckx>Anybody who sent me a PM during the last few hours better send it again. Sorry about that. <str1ngs>probably explains why I spammed the channel earlier. I switched back to circe <nckx>str1ngs: M-hm. I've yet to discover the IRC equivalent of mu4e, which was a breath of fresh air. <krafter>I have found erc to be servicable with a bit of config. <str1ngs>also is there away to submit patches to guix with out using a mail workflow? *nckx had /MODE -R set, back from when #guix was registered-users-only… which I changed after 1.0. :-\ Wonder how many PMs I've missed. <nckx>str1ngs: I use that on shell boxes, it's… pretty good for a curses(?) client, but something just doesn't click. <nckx>krafter: True, that can be said for most emacs packages, maybe I should just force myself to use it & configure it. <nckx>str1ngs: [patches w/o mail]: No. <str1ngs>no!!!! I have to setup email and everything! <krafter>nckx: Servicable, I have never been content with the UX of any irc client. <str1ngs>krafter: that's why I use circe it's pretty much just emacs <nireno>Hi, I'm trying to install guixos on an older machine but I don't think it understands GPT. Is there an ISO that will give me a bootable usb with MBR instead of GPT <nckx>str1ngs: Use mu4e ;-) And OK, I'll try it; looks do actually matter. AFK for a while now. Thanks! <krafter>str1ngs: Yes and I am jealous. Is logging in easy with circe? <str1ngs>krafter: it can log, but I don't use it myself <nckx>sneek: later tell nireno: No, there's only one ISO(hybrid) installer image. You should ask on help-guix@gnu.org as well; the person whom I know has the most experience with partitioning the installer is hardly (ever?) on IRC. <str1ngs>oh logging in? yes. it use tls and sasl <nckx>…if they ever come back. <krafter>Oh, I meant authenticating to nickserv. <str1ngs>krafter: yes, just make sure you have gnutls installed <str1ngs>I have this weird error build guix from git. no code for module (json) though config.log finds (json). and I'm using guix environment guix --ad-hoc help2man git strace for my environment. <krafter>I have been thinking of how much of everything around guix is so old. <krafter>irc, email bugtracking, scheme, etc. <str1ngs>this is pretty typical GNU related project <nckx>krafter: Nothing old about Scheme and manuals 😒 *nckx prefers IRC and e-mail over anything newer but yeh, they are old standards. ☺ <krafter>Everything nowadays seem to happen in the browser. <nckx>I don't see a wiki competing with IRC or email. <nckx>krafter: Yeah. Horrible :-/ <str1ngs>yeah, and all the browsers are terrible <krafter>I consider the manual competing with an eventual wiki. <str1ngs>there is an html version of the manual :P <krafter>A wiki would be able to obsolete the manual. <nckx>krafter: I just said manuals aren't really an ageing concept; wikis are fine but tend to rot. <krafter>I do find the info interface a bit cumbersome. <str1ngs>no, because doc strings get snarfed into the manual <nckx>krafter: Oh. Manual-in-the-strict-Texinfo-manual sense is absolutely obsolete. No disagreement there. <str1ngs>info are exportable to many formats though <str1ngs>not to mention it handles localization <str1ngs>so as much as it's been dated. it only dated because GNU is old. but that doesnt mean it's not useful of has a purpose. *nckx was never convinced by the supposed arguments for wikis over manuals, but it's easy to prove them wrong. If wikis really do draw magical contributors that manuals can't, I do hope they start a wiki soon 😛 <str1ngs>I've personally got used to using GNU manuals. my whole guix setup etc. has come from the manual. <nckx>There's a lot of room for improvement with the manual: all the service overviews are maintained *in the manual*, not exported from the code. That's a huge duplication and the drift apart is real. <str1ngs>yeah, but that takes man power. only way to fix that is to contribute :P <krafter>The issue I have with both Emacs and Guix manuals is that they provide very little examples. <str1ngs>I guess the services could be snarfed into the manaul. like guile does it? <nckx>That's a lot easier to fix in a manual than a stateful wiki ‘app’, which will have an ‘API’, and… <Marlin[m]><krafter "And a manual instead of a wiki."> Manuals are great, i think they are nice for the basics, but wikis are better for really specific parts <str1ngs>still what's wrong with add a video drivers section. then adding a AMD sections. then contributing that go guix? <nckx>Some people here mean wiki in a stylistic sense (hopefully the ‘cook book’ being discussed on the ML will address that audience), others (including me) assume it's an actual wiki with pages and accounts and spam and vulnerabilities and… Not saying both aren't reasonable, but it's not the same discussion. <Marlin[m]>I think a manual would get kinda messy with too many specifics <Marlin[m]>Imagine the entire archwiki in a single manual <str1ngs>meh, the archwiki needs it cause, hardly anything works out of the box. not to mention archlinux is not declarative <Marlin[m]>I think a manual is great for the generic parts <nckx>‘Arch wiki as a manual’ sounds awesome TBH. No more needing a Web connection every time you need to look up something. <str1ngs>nckx: that's the whole down fall to the wiki. its not available offline, or as a source <Marlin[m]>But something like "IRC clients that work with guix" on a manual would be weird <str1ngs>I think how to setup a irc client is out of the context of guix all together <str1ngs>upstream packages have there own manual on how to setup said package. <krafter>Though a wiki could be considered a collection of articles. In such a case they can be provided independently. <Marlin[m]><krafter "Though a wiki could be considere"> yes <nckx>There's the ‘cultural’ definition of wiki again. A section like ‘choosing an IRC client’ would suit the cookbook just fine, but then that might be because it doesn't exist and can be whatever one dreams it to be ☺ Still, no need for a cumbersome Web-only CMS in any of that. <Marlin[m]>What parts does the manual lack translating and documenting atm? <Marlin[m]><nckx "There's the ‘cultural’ definitio"> You can usually download wiki articles <nckx>Like with git or something? <Marlin[m]>Well, you just save the page as a pdf really <nckx>Marlin[m]: I don't see the connection to the quote. By ‘cultural’ I meant people using ‘wiki’ as a shorthand for, well, something, not ‘MediaWiki software on a server’. <nckx>More a style of writing. <nckx>Marlin[m]: Er, how does that scale… <Marlin[m]>But i think downloading it just depends on providing a download option <nckx>Marlin[m]: Even so, assuming that can be automated, PDFs aren't editable source. <nckx>Having to send search queries to a remote server just to look for a HOWTO feels pretty… SaaSS to me? Anyway, bed time here too. Good night! You were all very enjoyable night-time company. o/ <Marlin[m]>You could also get a html file, markup etc i think ***rEnr3n0 is now known as rEnr3n
***slyfox__ is now known as slyfox
<notnotdan>Suppose I have a file A.scm which defines a package B and returns an expression that denotes the package A (in this case A depends on B). Usually I would install A by running `guix package -f A.scm`. But how can I install both A and B in this case? <degrees380>Hi Guix, today my "guix pull" (with no --verbose options) give me a very vebose output "@build-log"; it's the first time I see such behaviour: is it normal? <degrees380>I tryied using two different machines (and guix versions) with the very same result <degrees380>any of you "guix pull"ed today in the "normal" way? <g_bor[m]>does not seem more verbose than normal yet. <degrees380>g_bor[m]: here it starts after "Computing Guix derivation for 'x86_64-linux'..." <g_bor[m]>here it only states what will be built, and it started building those... <tune>I ran into the same thing <degrees380>tune: if you are subscribed to help-guix ML please reply to "Subject: guix pull extremely verbose" confirming you are getting the same thing <tune>I am not subscribed, but I think I have sent stuff to it before. <tune>nevermind, no idea what I'm doing with the mailing list thing <brendyyn>notnotdan: you cant do that without modifying the file. <brendyyn>either you turn it into a module and make your own guix channel or use GUIX_PACKAGE_PATH <roptat>degrees380, I think that's because your guix daemon is older than guix itself and doesn't understand properly what's going on, but I could be wrong <roptat>(that only affects display, not performing the actual build) <z0d>does anyone use Guix on Mac? I installed it on top of VirtualBox, but the guest additions binary doesn't work, as it expects rm at /bin/rm, also it needs ldconfig. I fixed the rm part <g_bor[m]>hello, I just did a fresh 1.0.1. install, and the first guix pull log is really verbose <mekare>mine too and from the backlog I can tell some others got that too <brendyyn>So im getting a build failure that just says Error 2. How can I figure out what that means? <g_bor[m]>brendyyn: That does not seem too informative... is there a hint pointing at the build log file? <brendyyn>ok i was able to get a clearer message when i disabled parallel builds <bgardner>On a foreign distro is there anything special I need to do to update guix itself or does 'guix pull' + 'guix package -u' handle that? <brendyyn>guix pull updates guix. guix package -u doesnt. <kdtsh>Hi all! I took a cursory glance at the chat logs to see if other people are having a similar issue to me when doing a 'guix pull' and it seems like there are other folks. I also can't connect to ci.guix.gnu.org (though I don't know if ping get eaten by a firewall). I get logging which indicates that curl has failed to build; there's also none of th <kdtsh>e usual messages saying that substitutes have been fetched from the official substitute server. Two issues here? - curl 7.65.0 failing to build, and can't connect to the official substitute server? <g_bor[m]>bgardner: On a foreign distro the following things should be done: guix pull to update guix for the user, for each user you would like to have the updated guix. guix package -u for each user, to update their packages to the version provided by the new guix. guix pull as root to update root's guix, simply sudo guix pull won't work here, you will have to be in an evironment that is a root login shell, or otherwise prepare the <g_bor[m]>env to pull for the root guix. (This is needed fr example to get the daemon to find the locales), then the service files starting up the guix daemon should be updated, to start up the version of the daemon from the freshly pulled root's guix, and the guix-daemon should be restarted. That's about it. <g_bor[m]>But doing guix pull and guix package -u for your user will give you all that is needed, except it won't update the daemon. <bgardner>g_bor[m]: Ah, thank you - updating the daemon was my question. <roptat>kdtsh, have ci.guix.gnu.org ever worked for you, or is it the first time you're trying guix? <roptat>(and, is it guix system or guix on a foreign distro?) <kdtsh>roptat yes it's worked for me up until today. I'm running guix system in a VM <degrees380>g_bor[m]: you said the first pull is verbose on 1.0.1, and the second? <brendyyn>g_bor[m]: fatal error: gst/audio/gstaudiofilter.h: No such file or directory <brendyyn>its because of that, but that file is in gst-plugins-base. im not sure why it doesnt find it <rekado>brendyyn: maybe because the include path doesn’t include the sub-directory containing the file. <bgardner>Calling 'crontab -e' yields '(copy-file "/tmp/crontab.951" "/var/cron/tabs/username")" followed by 'In prodedure copy-file: No such file or directory.' /tmp/crontab.951 exists, it's /var/cron/ that is missing. Do I need to do something to prepare user crontabs under mcron? <rekado>bgardner: I guess we might need an activation service extension for the mcron service that creates /var/cron. <efraim>As I understand it we don't have a crontab service <efraim>I should move that up my list, there's been more interest in it <rekado>efraim: does it matter? Won’t mcron handle this automatically if /var/cron/tabs/… exists? <efraim>I don't think so, but I haven't looked at it closely enough yet <Marlin1113>i'm trying to get the right configs on the xorg-configuration part <Marlin1113>it seems that i can use a driver other than vesa if i use the ati drivers for my gpu, instead of amdgpu <Marlin1113>so i should have something equivalent to the Identifier "AMD" Driver "ati" on the xorg-configuration section <Marlin1113>i got the driver right, how can i change the identifier? ***Server sets mode: +cnt
<rekado>On this one system Guile can’t run setlocale. <rekado>it works on other systems with the same Guile. <rekado>no, I don’t think it needs to be installed. <rekado>I’m just running what the builder does: setting LOCPATH and then issuing (setlocale LC_ALL "en_US.utf8") <rekado>only on this one CentOS 7.5 system <rekado>but it must be the lack of GUIX_LOCPATH. <rekado>it’s because I moved the declaration of GUIX_LOCPATH from that node to the default cluster profile — but this node is not part of the cluster. <donofrio__>kmicu, how do I hget the guix version and hash of inxi-minimal? <archetyp>@ unsupported-platform /gnu/store/q8gmnxhfiqbp9f1jj668k50b64fw7rh0-curl-7.65.0.drv armhf-linux while setting up the build environment: a `armhf-linux' is required to build `/gnu/store/q8gmnxhfiqbp9f1jj668k50b64fw7rh0-curl-7.65.0.drv', but I am a `x86_64-linux' <archetyp>EOMA68 Libre Tea Computer Card is coming soon! <espectalll[m]>Hey, what is the encryption label for when creating a partition in the ncurses installer? <vagrantc>i haven't had good luck generating cross-architecture bootable images, though, but building individual packages seems to work sometimes <espectalll[m]>May I suggest allowing an option to disable root login if no password is typed in? <vagrantc>still probably faster than native compilation on low-end arm hardware <str1ngs>cross compilation always has so many edge cases though. not just in the context of guix even <str1ngs>donofrio__: guix build inixi-minimal will return the hash and store path. is that the hash you need? <Marlin[m]>Tips on good monitors that don't have proprietary firmware? <vagrantc>i suppose i should actually test if the package works... <rvgn>kmicu No problems with rfkill on 1.0.0 installer, <mfg>is there a way to convert nix pkg templates to guix pkg templates? ie a script? <str1ngs>but I have not used that myself. I think that will import nix expressions <mfg>hm i need to check the manual ... <rekado>hmm, I still can’t get past this (setlocale 6 "en_US.utf8") error. <rekado>the daemon runs in an environment where glibc-locales is available and GUIX_LOCPATH is set. <rekado>it works fine when run outside of the daemon’s context (i.e. same guile as in the derivation, running the builder script) <espectalll[m]>Yeah, I know, there's IceCat, but it seems to be stuck in ESR and even then there's not really much maintenance <nckx>espectalll[m]: Not that I know of. *nckx finds one with the last commit message, from 2015, being ‘big crap’. So I'm guessing: no. <espectalll[m]>a shame considering that pretty much everything else is very fine, I can actually live with 100% FOSS but you know <espectalll[m]>The browser is the most important part of a computer nowadatsy <g_bor[m]>espectalll: There is actually nothing stopping you from packaging firefox, or even maintaining a channel for it, but please consider that firefox is not upstreamable. <g_bor[m]>rekado: oops? Is it? Maybe I missed some point... <mfg>Is there something like a base-devel or build-essential meta-package in guix? <nckx>mfg: There's gcc-toolchain, but ‘build essentials’ are so language-specific that it doesn't really make much sense IMO. <str1ngs>mfg: though, guix environment <package> is much better for dependencies etc <nckx>There's probably no overlap between C and Python projects, for example, not sure about hip things like Rust & Go. <mfg>so gcc-toolchain also contains make and such ? *nckx preferred Rust & Go's earlier albums. <g_bor[m]>should guix gc -d work without specifying a duration? <kmicu>rvgn: thank you for testing that. <str1ngs>nckx: speaking of browsers I sent my qtwebengine patches to guix-patches <rekado>on my laptop /gnu/store/mn3ymm3f2r4xjqf8m9fgmadh6b8p6fvr-glibc-utf8-locales-2.28/lib/locale/2.28/en_US.utf8/LC_IDENTIFICATION exists <kmicu>donofrio__: when you install a package e.g. ‘guix install inxi-minimal’ there is a hash printed in its output … /gnu/store/hash-inxi-minimal. With that hash we can check whether your version is available on build farm as a substitute. ‘guix describe’ should show guix version. <rekado>str1ngs: the hash of what? The store prefix is the same <nckx>str1ngs: I saw! I wondered if that was you. You don't like capital letters much. <str1ngs>nckx: oh no, habit form C programming :P <str1ngs>nckx: also mail patches, is not my normal work flow. but I'm trying to get upto speed with it. <nckx>str1ngs: Oh, in Scheme neither, but I was talking about your name. <str1ngs>nckx: oh I plan to fix this. I had to do a whole email workflow between emacs and git. so still polishing that. <kmicu>espectalll[m]: Guix’s IceCat is actively patched to follow Firefox ESR. ‘Modern’ web works on ESR. <g_bor[m]>rekado: can this missing file be a hardware/file system corruption issue? I am having a look at the definition to see if there is anything suspicious, but nothing so far... <rekado>g_bor[m]: this is always possible, of course. But it’s also really weird. <g_bor[m]>any idea how these build log entries leak through guix pull? <nckx>str1ngs: I quite like the e-mail workflow, but I can only compare it to GitHub; what are you used to? (Anything that allows one to keep their Web browser closed & hands on the keyboard? ☺) <rekado>This is on huge, redundant file servers. <str1ngs>nckx: I'm use to working with git directly, branches, rebase, merge, upstream remotes <g_bor[m]>rekado: Yes, it really is. How is this store item transferred to the node? <rekado>this is the one node that runs guix-daemon <str1ngs>rekado: I wonder if you gc that path. if its even possible . and then build it. if it replicates <str1ngs>it's glibc so may be impossible to gc <nckx>str1ngs: Aha. I've never done that, socially. <g_bor[m]>rekado: in this case does gc verify give any pointers? I guess not, because the prefix is ok... <str1ngs>nckx: other project I contribute too, have other codereview mechanics like Gerrit for example <str1ngs>nckx: Gerrit is nice, its a good mix of patch and codereview all rolled into one. <g_bor[m]>That could point out when the problem happened <mfg>so i want to write a new package definition ... what is the best setup for this? do i need a local channel for testing? <mfg>and how do i add local channels to guix? <str1ngs>mfg: you do not need a local channel. you can start with a file and use guix build -f ./file.scm ***ChanServ sets mode: +o nckx
***nckx sets mode: +srg
***ChanServ sets mode: -s
<str1ngs>mfg: gives an example for -f . channels are still nice though. but better suited when you are working with guix packages ***ChanServ sets mode: -o nckx
***ChanServ sets mode: +o nckx
***nckx sets mode: -rg
***ChanServ sets mode: -o nckx
<mfg>str1ngs: i will try channels if i have more experience ... <nckx>str1ngs: It's actually your fault, with your talk of fancy emacs IRC clients luring me out of my comfort zone! <str1ngs>mfg: -f ./file.scm is the lowest barrier to creating a package. <nckx>str1ngs: circe. Now back to HexChat; but I'll try/compare circe/erc some more tomorrow. <mfg>str1ngs, do you know any cmake based package which is not too big which i can look at for as an example ? <mfg>and at least for my IRC usage ERC does a really good job :P <mfg>Ah, i just found dolphin-emu <dekaidle>hello, I'm having some trouble configuring X. My (service slim-service-type (slim-configuration (xorg-configuration (keyboard-layout keyboard-layout)))) just gives me a "Wrong type to apply" (+ the keyboard-layout type) error. Any idea what I'm doing wrong? No other xorg options work either. <mfg>what uri do i need to give guix download if i'm fetching a git commit? <krafter>Is there a group that I can add a user to to make them able to shutdown or reboot the system? <str1ngs>mfg: you found a cmake package then? <dekaidle>(operating-system (keyboard-layout (keyboard-layout "no" "winkeys"))) <dekaidle>I get the same error if I just declare it directly in xorg-configuration, too <str1ngs>mfg: that's good it uses cmake-build-system <mfg>str1ngs: yes, but i don't understand how i should obtain the sha256 of a git tagged release ... <str1ngs>mfg: are you using commit for git source? <str1ngs>mfg: either way, guix will complain that the source hash is wrong. and tell you what the current hash is. which you can then use in place. I don't know how to receive just the source hash or do verification other then that. maybe there is a better way.. dunno <mfg>str1ngs: i think so .. (version (git-version "2.0" revision commit)) revision and commit are let defined <str1ngs>mfg: I mean in the git-reference for git-fetch <str1ngs>mfg: what ever you put in sha256 will be wront. but guix will tell you what it verifies to. in which case you can use that. <mfg>what packages does cmake-build-system include, so tha ti don't need to list them in the inputs ? <mfg>i read that ie gnu-build-system already includes a compiler and some things <rekado>I’m in trouble. More files are missing. Something’s definitely not right. <str1ngs>mfg: I'm not sure exactly. it would include common toolchain programs like gcc, binutils, cmake, make <donofrio__>kmicu, so substrate = arch specific binaries (saving space becasue it's not been compiled for the arch it's running on? thought ELF64 is linux wide ppc arch? <str1ngs>mfg: best to try, first satisfy inputs. and if a toolchain program is missing add it to native-inputs <str1ngs>mfg: sometimes inputs, and native-inputs takes some trial and error. <g_bor[m]>rekado: oops, that seems like a really serious problem. <g_bor[m]>Are these only missin from the locale related stuff, or also from other packages? <mfg>str1ngs: i guess you are right :D <mfg>How do I name specific versions of packages? ("llvm@6" ,llvm) ? <nckx>mfg: For now, use ("foo" ,foo). <Marlin[m]>dekaidle it means you used the wrong format on the option <mfg>nckx: the documentation of the program states that it needs llvm 6 <rekado>so, we have zfs snapshots here and I can confirm that a few days ago some of the corrupt store items still looked fine. <Marlin[m]>(keyboard-layout (keyboard-layout "us")) would work i think <nckx>mfg: The quoted string here is just a label, it won't do anything (("llvm" ,llvm) is equivalent to ("larry" ,llvm)). You want ("llvm" ,llvm-6), which changes the actual variable passed to the package. <mfg>nckx: ah okay i thought, the label has to say something special ... <rekado>the problem appears to be that I accidentally ran the daemon with the wrong GUIX_DATABASE_DIRECTORY <rekado>(localstatedir is /gnu/var, not /var) <dekaidle>Marlin[m]: I was thinking that at first too, but it works in the (bootloader) entry, plus I cannot use any other options like setting the resolution. I tried reading the manual on how these entries are built up but I'm clearly doing something fundamentally wrong, but I haven't been able to figure it out... <Marlin[m]>Hey guys, i'm gonna look into packaging the digimend kernel drivers on guix <rekado>(I used the daemon from “guix pull”, and it works only on /var) <dekaidle>they all fail with an error, usually of type <rekado>this message here doesn’t look good: guix pull: error: cannot unlink `/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/gconv': Directory not empty <nckx>Marlin[m]: Great! (Did my messages arrive? I still suspect something's wonky somewhere.) <rekado>yes: the daemon will remove stuff when it doesn’t appear in the database and the build is requested. <Marlin[m]>they are drivers for non wacom drawing tablets <rekado>so, the daemon ended up partially removing store items, while also failing to build new things. *nckx ‘great’ assuming they are Free software, of course. <rekado>I’m now repairing corrupted store items by rsyncing from the snapshots <mfg>is somewhere a list of supported license names? <kmicu>donofrio__: a substitute saves disk space because we don’t need to compile a program on our computer (that requires installing build tools). E.g. by using hello’s (binary) substitute I don’t need to compile hello and compiling hello requires installing hello’s build-time dependencies https://hydra.gnu.org/build/3199947#tabs-build-deps <g_bor[m]>rekado: I'm glad you could finally find out what went wrong. Do you have any idea how to prevent this in the future? <donofrio__>are there arch specific substrates - in that I mean can I take the apache substrate for the suse x64 linux and the apply it to aix power8 arch? <rekado>g_bor[m]: the daemon must be more careful. <rekado>when the client reports one kind of localstatedir and the daemon has another, it should abort. <dekaidle>if anyone has a working configuration file configuring X via slim I'd like to know how you got it working. Do I _have_ to use %desktop-services ? (I'm just using %base-services and picking other stuff I want to use manually) <dekaidle>I've got everything working but X configuration <kmicu>donofrio__: substitute binaries are not universal, hello has, currently, 3 system flavors gnu:master:hello-2.10.armhf-linux gnu:master:hello-2.10.i686-linux gnu:master:hello-2.10.x86_64-linux <kmicu>donofrio__: there are no substitutes for powerpc yet. That’s work in progress. <mfg>will try more tomorrow <nckx>Oh, I'm getting the spurious ’@ foo-… <nckx>’ spewing when guix pulling, now, too. <str1ngs>how do I add to an alist. can I only use acons? <str1ngs>I'd like to use cons or cons* but I don't think I can use that on an alist <str1ngs>yeah, alist keys are unique. I don't know why I'm even thinking cons is a good idea :( 
