<nckx>Hullo raghavgururajan, and good night. <shrdlu68>Is /etc/profile and and bashrc customized in guix or is it from upstream? I ask because I've noticed different $PS1 across distros. <janneke>shrdlu68: /etc/profile is guix-specific and created by operating-system-etc-service <shrdlu68>I see a bunch of emacs packages on the guix list of packages, I'm curious: do they effectively deprecate melpa and others? <leoprikler>not quite -- you may need guix import elpa for the others ;) <leoprikler>but yes, installing emacs packages via guix is the preferred way <shrdlu68>leoprikler: Tangential: I haven't considered using `guix import` or `guix install` short of experimenting. I like `guix reconfigure` and having my entire OS on a repo somewhere. <leoprikler>if you like versioning, you can put that definition into you OS or manifest <leoprikler>btw. does anyone here have a shepherd config for the emacs daemon? <nataraj>on a Slackware non root user, getting "guix package: error: build failed: the Nix user should not be a member of `root'" <nataraj>was trying out "guix package --install mc" <leoprikler>That's a problem. Guix builds should be run by one of these builders <nataraj>Now it is "make-struct is deprecated. Use make-struct/no-tail instead." <porchetta>I am trying guix out, just the package manager <porchetta>is there a way to let is use system-wide installed gcc? and can the compilation be done on a ramdisk? <leoprikler>no, Guix uses its own packages, which are kept in a different place from Portage's <leoprikler>you can however speed the build up with substitutes <porchetta>can I specify a substitute only for specific packages? <roptat>substitute-urls specifies where you want to look for substitutes, but it won't download unless they are signed by an authorized key, or have the same content as a substitute signed by an authorized key <roptat>if you don't want substitutes by default, use --no-substitutes as an argument to the daemon, then --substitute-urls will tell it when you want to use substitutes, but that will substitute everything needed for a build, not for a specific package <roptat>I mean, it won't just substitute one thing, but also everything it needs <leoprikler>IIRC Guix on Gentoo does not automatically trust ci.guix.gnu.org <porchetta>I have other questions: why is it compiling a very old version of gcc? <roptat>it's going to build multiple versions of gcc <porchetta>what about use flags? Is there something where I could read for a method of having a similar strategy? <leoprikler>Guix has this configuration as part of the package specification <roptat>we don't have use flags, but we have build transformation options (a bit limited compared to use flags), or you can redefine packages (more powerful than use flags, but also more work on your side) <roptat>I would use a manifest to be sure I always apply the options I want and not miss one one day <porchetta>DO you have an example of manifest? The documentation lacks details <leoprikler>manifests can be arbitrarily detailed or detail-less <porchetta>the fact is that I have no idea on how to make a manifest file <leoprikler>but using packages->manifest as in the manual is a better idea than writing one yourself ;) <roptat>there's also specifications->manifest, but it will make it harder to change anything, I think <roptat>packages->manifest allows you to pass package objects, instead of mere strings, which gives you all the power and scheme and the Guix API to customize your packages <leoprikler>roptat: by the way, is there a way to create a manifest from the currently installed packages? <roptat>you could list packages and create a manifest from that, but it won't preserve build transformation options <porchetta>let's say that I want to install htop without the zserver configuration flag. How do I inherit the package recipe and modify it by adding the configuration flag? Is my modification gonna stick in case of htop upgrades or do I have to edit the recipe again in case of new htop versions? <porchetta>I am sorry if this a question already answered, I don't understand that from the documentation <leoprikler>(package (inherit htop) (arguments `(#:configure-flags ...))) <roptat>leoprikler, you can try "echo '(specifications->manifest'; for p in `guix package -I | cut -f1-3 | sed -e 's|\t|@|' -e 's|\t|:|'`; do echo '"' $p '"'; done; echo ')'" <leoprikler>and if I want to use packages->manifest instead? <leoprikler>porchetta: keep in mind, that configure flags are a Scheme list <roptat>porchetta, you may want to have a look at substitute-keyword-arguments too <roptat>leoprikler, it would be even more error-prone <roptat>leoprikler, but maybe a simple guix package -I | cut -f1 would work for you? <cornburglar>can I create a manifest for guix environments/containers that will have services started when the environment is launched? For example, say you don't want audio available regularly but you want to have alsa running in an environment used for audio production or listening <porchetta>/home/user/packages/htop.scm:5:0: error: htop: unbound variable <porchetta>I don't understand what to import to inherit htop <leoprikler>cornburglar: not in a simple manner, but it might work with an additional package <roptat>porchetta, that information could be found with "guix package --show=htop" for instance <leoprikler>roptat: is there a Scheme syntax to get a specific package output? <roptat>there's something, but I don't remember <porchetta>X.509 certificate of 'web.cvs.savannah.gnu.org' could not be verified <porchetta>is there a way to force it to trust the cert? <roptat>porchetta, check you system date, also I think you don't need guix refresh <roptat>it's for guix devs to know what package needs an update <roptat>it could also be that you don't have nss-certs in your environment, or your SSL_* variables don't point to it <porchetta>I think it is needed to initialize ACL isn't it? <roptat>no, if you want ACLs for substitutes, you need guix archive --authorize <roptat>then you pass it the public key of a substitute server <leoprikler>roptat: is "guix upgrade" compatible with "guix package -m"? <nckx>leoprikler: Yes. Compatible but not identical. And ‘-m’ will ‘uninstall’ any packages not in the specified manifest. <leoprikler>The scenario I had in mind was something like the following: <leoprikler>Guix upgrade comes along, Gimp gets pushed to 2.Y <leoprikler>I assume it would stay at 2.Y unless Guix version has changed in between yet again <nckx>Actually, I think you'll get a ‘package not found for version 2.X’ and the manifest will not be applied. <leoprikler>but only if I hardcode the version into the manifest, no? <nckx>Yes. I read ‘ the manifest specifies Gimp version 2.X’ as ‘hardcodes 2.X’. No? <nckx>Otherwise it just specifies gimp, and whatever Gimp is currently in Guix is installed. <nckx>I've never hard-coded versions in my manifest. <nckx>Let me try to read your question above with that new meaning. <nckx>leoprikler: deconstructed: : - D <nckx>I think I'm still misunderstanding. If the manifest just asks for ‘gimp’ (not ‘gimp@2.X’), then what do you mean by ‘manifest is edited’? <leoprikler>something that makes me run "guix package -m" again :) <nckx>leoprikler: Not much to read, your assumption that Gimp would never be downgraded in that scenario is correct. <porchetta>substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable <porchetta>I still get this, I don't understand how to get around it <civodul>(unless you don't want to get "substitutes", i.e. pre-built binaries) <civodul>i just realized that berlin must be building all of core-updates <fps>hm, interesting. i'm trying to use method git-fetch in a local package definition (a file on my hd) <fps>this works fine, but now i tried bumping the commit in the git-reference <fps>it seems guix doesn't notice that the commit is a different one from the one originally used <nckx>fps: Did you change the hash? <fps>nckx: no, since i don;t know what the hash will be <fps>i'm hoping for the package build to fail and tell me what the has should be <pinoaffe>when I try to run `guix system reconfigure` it complains about locales, this can be circumvented by changing LANG from en_GB.utf8 to en_US.utf8 <nckx>fps: Think of the URL as a mere hint, and origins as content-addressed by hash. Guix already has the thing, so it will never look at the URL to re-fetch the thing. Does that make sense? <nckx>fps: One of the easy ways/hacks to make Guix visit the URL is to change a character in the hash. <fps>nckx: that's an ok hack, i guess <fps>nckx: and yeah, the explanation made sense.. ty <pinoaffe>once I do that, `guix reconfigure` prints a warning about guile being unable to set the locale, but the reconfiguration proceeds without any further issues, and any resulting generation fails at starting X11 <nckx>The betterly correct way is to run ‘guix download’ (in your case ‘guix hash -rx’) by hand and replace the hash wholesale, but this does require a 100% clean repo. <pinoaffe>does anyone have a clue what might be happening? <nckx>pinoaffe: Is your entire system (system + user profiles) up to date? <nckx>I used en_GB for a long time on Guix System (and, before that, GuixSD) and never had problems. <porchetta>I don't understand how to install pythn suing a custo recipe <nckx>pinoaffe: And probably not, but do you have glibc-utf8-locales installed anywhere? If so, don't. <nckx>porchetta: The way that's written, the original python's ARGUMENTS field is completely replaced with the one you provide. Gone custom phases and and ‘#:tests? #f’ that were probably there. You need to use substitute-keyword-arguments. Plenty of examples in (gnu packages …). <truby>out of curiosity, are texlive version bumps usually done by hand? because that seems like a lot of packages to update by hand 😃 <nckx>porchetta: fftw-openmpi is my go-to example; you can probably get away with only modifying #:configure-flags and leaving #:phases as-are. <nckx>porchetta: gnu/packages is a subdirectory of the Guix sources, which you can see either by cloning the guix.git repository or with ‘guix build --source guix’. *nckx learnt what a porchetta is only last week. <porchetta>whatif I want to install something that depends on package? Does guix reuses the package-with-foo or it proceeds to build package? <nckx>porchetta: You'd use something called ‘input rewriting’ (in the manual) for that, but it's not something I've experience with. <porchetta>what is this syntax? ,@(package-inputs pkg-original))) <nckx>porchetta: Heh 🙂 Much Scheme. I forget what it's called. Until you learn more Scheme, think of it as unquoting a list while ‘removing’ the outer brackets. <nckx>‘unquote-splice’ apparently. <nckx>porchetta: Without it, you'd have a nested list of inputs: (libfoo (orig-input1 orig-input2 …)), instead of (libfoo orig-input1 orig-input2). *nckx much lag; such VPN; thanks pinoaffe. <olivuser>I had an old hdd plugged in order to backup copy some files to my fresh install of guix. now, I cant boot anymore. I get the "Reboot and Select proper Boot device or Insert Boot Media in selected Boot device and press a key" <olivuser>and the only "mistake" I think I committed was to not plug off current when I changed the cables from hdd to hdd <nckx>olivuser: Unless you messed with your boot loader, it sounds like your firmware is simply confused about what the current boot device is. <nckx>(That's not a GRUB message.) <nckx>(Firmware = ‘BIOS’ or UEFI.) <olivuser>nckx, no, I didnt mess with the boot loader. Unfortunately, the problem persists if I have only one drive plugged in <olivuser>hm. I have efi installed for both drives (one is guix, the other another linux distro; but separate drives!) <nckx>Can you ‘press X to enter Setup’ when booting? <nckx>Oh god, it depends completely on the implementation. But anything with ‘boot device’ or ‘boot order’ is a safe bet. <olivuser>there is a "boot mode select", which is currently set to (LEGACY+UEFI), another option being UEFI. would that be something like it? <nckx>olivuser: I'd leave that alone since it worked before. Nothing related to drive order or primary boot device…? <nckx>On my UEFI laptop, Guix even nicely shows up as ‘Guix’ in the list, but not all machines are so friendly. <nckx>olivuser: Have you tried booting without any external drives attached? <olivuser>nckx, funny thing is that there used to be an option "UEFI Hard Disk Drive BBS Priorities" which did show up three options (UEFI OS, Manjaro and Guix), but now only displays UEFI OS. I had problems with manjaro too, but that was a manjaro related issue which is fixed now <nckx>Yeah, all firmware is written by the dark lord to make us yearn for death. <olivuser>nckx, Boot Option #1 is "UEFI Hard Disk: UEFI OS", the other UEFI options being related to other storage medium formats <nckx>Except libreboot, of course. <olivuser>nckx, I dont use any external drives currently <olivuser>in the beginning, I was talking about an internal drive <nckx>olivuser: Hm. That's… vague, since UEFI allows multiple OSes on a single drive, it should give more information than just ‘drive X’. <olivuser>nckx, a curious thing I noticed: when I go to "choose boot device", the second SATA drive shows up; in BIOS; it doesnt. <nckx>Switching from UEFI to legacy (CSM, or ‘BIOS’ emulation) will definitely require a reinstallation of Guix first, so that's not really an option. But maybe LEGACY+UEFI means that it tries ‘BIOS’ first. Do you know in which mode you were booting? <olivuser>I will boot into the other os to check if it is recognised by gparted <nckx>Yay, more unknowns relying on whatever your firmware decided to do in the past 🙂 <nckx>Sorry, there's not much I can do (well, ‘too much I have to guess’) at this point. <olivuser>nckx, so in the os, the guix drive is detected - but apparently not in the bios. <olivuser>nckx, but do you have an idea where I could start digging on my own? <nckx>olivuser: I'm afraid not, apart from ‘make sure you haven't missed any submenus in the setup tool’. I'm also afraid I have to go AFK now. <nckx>A good rule of thumb is ‘don't trust the BIOS/EFI menu structure to reflect any part of reality’. <olivuser>so again I managed to get myself into trouble and I am about to reinstall. First off, two questions: I have two drives, both having a separate EFI partition. Is that likely to cause a problem? <olivuser>another question: having installed bootloader, system and data on separate partitions, is it possible to just reinstall the "system" and leave (in particular) the data alone? ***jonsger1 is now known as jonsger
<fps>btw: is there a way to refer to an earlier version of guix to build a package? <fps>i guess guix pull --commit=COMMIT? <civodul>fps: yes, that or /var/guix/profiles/per-user/$USER/current-guix-N-link/bin/guix build foo <fps>civodul: i'm just asking because i'm writing a small article about writing reproducible articles using guix ;) <fps>and in that context it's important to be able to be able for someone else to recreate the exact environment at some later time <civodul>then you'll probably want to mention "guix describe -f channels" <fps>i guess just recording the guix commit used to build the article enables a verifyer to reproduce the environment <roptat>there's a notion of "inferiors" too, although I never used them <civodul>still not as efficient as we'd like, but hey <fps>btw: what's the best way to cite the guix project? <civodul>there's a couple of peer-reviewed articles <civodul>so that could be one way if that's for a scientific article <civodul>but otherwise you can also just refer to the web site, the manual, or somethign <fps>civodul: yeah, those look good for a start :) <fps>we'll see if it gets published in an academic venue.. <civodul>no shortage of references actually :-) <rekado_>I just saw this while compiling Guix on master: gnu/services/kerberos.scm:230:0: warning: shadows previous definition of `%-location-procedure' at gnu/services/kerberos.scm:178:0 <rekado_>these two locations are instances of define-configuration <rekado_>can there only be one use of define-configuration in a module? <nckx>rekado_: IIRC purging ur caches ‘fixes’ that. <civodul>rekado_: it's just that Guile < 2.2.6 would not report that <civodul>this warning is for when you do (define foo x) (define foo y) in the same module <civodul>the 'define-configuration' macro uses the same name for the 'location' procedure, which is why it shows up <civodul>leoprikler: it's defined as a top-level binding <civodul>maybe we should just define it hiegienically as a function of the record type name <nckx>It happened to me in cups.scm, then went away when I recompiled… so it shouldn't have? <leoprikler>civodul: but do you actually need it at top-level? <nckx>Cool, a CVE fix for sudo. <civodul>leoprikler: well, it's actually unused at the moment, but in theory it could be used at the top level <civodul>at least the record type printer should use it <civodul>dunno, we need to take a closer loop <pinoaffe>I don't know whether this is a guix-specific thing, but on my old laptop (t420), backlight control using the keyboard used to work out of the box, regardless of whether X/Wayland/no display server was running, this does not work on my t470 <leoprikler>pinoaffe: it may very well be, that the t470 uses different backlight control <pinoaffe>leoprikler: it does, any clue how I could replicate the behaviour? <pinoaffe>I can controll the backlight using /sys/class/backlight, but don't know how to cause a value to be written to the brightness file when an acpi event is triggered <leoprikler>that sounds like you'd be writing your own backlight driver <leoprikler>pinoaffe: it seems like there are some signals on org.freedesktop.login1.Manager you can listen on <pinoaffe>leoprikler: huh, what does that have to do with the backlight? <bavier>ugh, I want to like rust-lang, but already turned off by trying to package one thing <apteryx>pinoaffe: on my T460 I use the 'light' utility to handle the specifics for me <leoprikler>pinoaffe: you can listen on DBus for the given signal, then write to /sys/class/backlight <bavier>I feel like there a giant rat's nest of rust libraries, and packaging any one of them requires packaging the other 500 <leoprikler>is there no rust stdlib at the base of everything? <pinoaffe>leoprikler: I'd be surprised if there was a dbus signal signalling that one of the special keys was pressed <leoprikler>ahh, I thought ACPI in the sense of sleep/hibernate <leoprikler>have you tried assigning them to shortcuts through settings? <nckx>Maybe ‘xev’ can answer leoprikler's question. Or maybe not. I tried capturing the Fn+F8/F9 (brightness up/down) events on my X230T with it, but it doesn't seem to generate anything of use. <nckx>It *does* capture the XRROutputPropertyChangeNotifyEvent… that is fed back to X after the backlight brightness has actually been adjusted. Heh. <bricewge>nckx: On t430 the keys are XF86MonBrightnessDown and XF86MonBrightnessUp. If you can't see them in `xev` you probably have a daemon that is capturing them (sxhkd on my case). <pinoaffe>leoprikler: I should be able to make my window manager react to them, but that'd not work in a TTY <nckx>bricewge: Right you are. ‘bindsym XF86MonBrightnessDown exec --no-startup-id sudo light -U 5’ *nckx from the past strikes again. <leoprikler>pinoaffe: what about shell aliases in the tty case? <bricewge>Speaking of backlight control, are there any example on how to package a kernel module? I'm missing `ddcci-driver-linux` to control external monitor backlight through ddcci. <nckx>bricewge: ‘;;; Linux kernel modules.’ in gnu/packages/linux.scm. <nckx>I think I also packaged some DDC UI, but no modules. <bricewge>Thanks, I'' try to package it during the week. <truby>I see there's a wip-texlive branch, is someone already working on texlive 2019? Otherwise I'm willing to take a look at it :-) *truby realises that wanting to package texlive-2019 for guix is really just procrastination from thesis writing... <thomassgn>how would I disable or remove a build-phase? <thomassgn>Woop! batctl, the userspace program for managing the batman-adv kernel module is now packaged. Let's see how patches work again... :) <bdju>is there any info about how to get adb/fastboot (android stuff) working on guix? I just used a separate machine to deal with it the other day, but would like to do it on my main machine <thomassgn>bdju: I've not used it myself, but I see there's both an adb package and a 'android-udev-rules' package. I see the last one is not meant to be installed, rather passed to your udev service in your configuration. theres also a fastboot package. :) <leoprikler>it also appears, that you need to add yourself to the plugdev group for permissions to work <bdju>there was something complicated it the config, probably the groups part <bdju>I remember messing with it several months ago and I couldn't build my config for a few days so I gave up and took it all out <bdju>looks like I have those two packages still <bdju>I think the plugdev group has to be created <leoprikler>grepping for "plugdev" in guix source, it seems to be replaced with "dialout" in some packages <leoprikler>bdju: try adding yourself to dialout and see whether that help <bdju>leoprikler: I added dialout to my supplementary-groups and it doesn't seem to have worked <bdju>I mean my groups didn't even change <leoprikler>you need to reconfigure and reboot for the change to take effect <bdju>why would I have to reboot? <bdju>I just need a new login shell, right? I did something like this on void yesterday without a reboot <leoprikler>okay, you might be able to do without the reboot <leoprikler>but you need to make sure your hack actually works and adds the dialout group <bdju>oh dear... I went to another tty to login and check groups there, and it neven asks my password. after typing anything and hitting return it just prints the welcome message again <bdju>opening a new terminal or a shell within my shell shows the same groups, though, so I have my doubts a reboot would work <leoprikler>spawning a shell in a shell does not apply the new groups <bdju>you're probably right about that <leoprikler>I'm not entirely sure how we've managed to lock you out of your TTYs though <bdju>well if I were to kill my session, login to a tty, and start a new one, that would probably do it <bdju>my system gives me various issues all the time, it's all quite complicated and tiresome <bdju>my new terminals now give locale errors and claim intel-vaapi-driver is an unknown package <bdju>so a new terminal can't reconfigure due to various errors including locale, but my tmux session is fine <bdju>so something broke and tmux is safe because it's all old shells/logins <bdju>I've removed dialout from groups, I also tried plugdev. neither did anything <bdju>I want to apply my manifest and reboot but weston has failed to build for days now <bdju>maybe I'll just uninstall it <bdju>it's needed for a command to tell you about your monitors and open windows in wayland, I don't use it as a compositor <thomassgn>bdju: sorry, didn't pay attention here. See the description of the android udev rules, it also says "an `adbusers' group must be defined and your user added to it." <bdju>yeah I actually still have some lines attempting to add an adbusers group commented out in my config, but I figured it would be fine to try other things first <bdju>I don't remember what I was doing or where I heard about it before ***MinceR_ is now known as MinceR
***benny is now known as Guest43477
***Guest43477 is now known as benny
<bdju>would it be possible to have the adbusers group created when adb is installed? that seems like it would simplify this for others <bdju>well I install adb as my user and groups are probably a system thing, so maybe it's not that simple <thomassgn>bdju: I'm guessing it would be possible. I see so many things people do with guix that I previously thought was sci-fi. I don't know how though :). <thomassgn>I see you are adding adbusers group, but your own user is not added to the adbusers group... <rekado_>bdju: it would only work with system services (which can install packages and create user accounts and all that) <bdju>I guess I wouldn't mind installing it as a system service if I knew it'd be easier <bdju>nckx: is your system.scm posted anywhere? I'm thinking I want to remove %desktop-services soon and have something more explicit so I don't have to do that modification thing <leoprikler>using services does not improve code over directly adding the group -- it's actually more work to write the boilerplate code for services <leoprikler>that said, if there is an actual service to be served, services do make sense again <bdju>what part of the manual covers creating a new group? <bdju>I just uncommented what I had before, fixed indentation, and tried to reconfigure <bdju>I'm not sure if groups is at the right part/depth of the file, and I'm not sure why I'm making a list <bdju>but otherwise it seems to match the manual <leoprikler>instead of (list (group ...)), do (cons* (group ...) %base-groups) <bdju>In procedure append: Wrong type argument in position 1 (expecting empty list): #<<user-group> name: "adbusers" password: #f id: #f system?: #t> <bdju>same error if I swap the order of name and system <bdju>I'll repaste the section in case I did it wrong <bdju>can't scheme very well so sorry if I'm missing something obvious <leoprikler>(i personally prefer (cons* ... x) over (append (list ...) x) ) <bdju>sweet! that worked without error <bdju>now I'll actually add myself to that group <bdju>okay so I did that, also created and added myself to plugdev <bdju>still says no permission to mess with an android device, and now it tells me to verify my udev rules <bdju>yes, was testing in a tty <bdju>and the error changed slightly as I joined more of the groups <bdju>I apparently have to pass android-udev-rules to the udev service <bdju>according to its package description