<milkey>this may be a stupid question, but: does mesa need to be a propagated-input on things that need mesa to run? cause in existing packages, sometimes it's in propagated-inputs, and sometimes just inputs <leoprikler>for libraries it may make sense (e.g. if required by pkg-config) <leoprikler>for applications, it may be that paths are not patched correctly (in which case they should be!) <milkey>the library in question doesn't even link to mesa, but it's useless without mesa installed at runtime <milkey>it's libplacebo, which uses vulkan, but the only package that is likely to use it is mpv, which already has mesa as an input <milkey>I'm just a little confused, and want to be *not* confused before I actually submit a patch <leoprikler>hmm, the question in that case is not "how would mpv handle this?", but "how would any library linked against libplacebo handle this" <leoprikler>if you can link it without needing mesa at build, it seems somewhat meaningless to propagate it <nothingmuch>i'm trying to import a pypi package that only ships .whl files (using Pipfile{,.lock}) and which lacks a setup.py but adding an appropriate patch to the package definition i'm encountering a weird error: <nothingmuch>package -s finds it, trying to start an environment with it fails because the package isn't found, after which package -s also fails <nothingmuch>In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f <nothingmuch>if i touch the .scm file where the package is defined then package -s starts working again (it's a module imported from my manifest.scm, so i suspect there's some interaction with the cached compilation of the manifest?) <nothingmuch>this appears to be the result of just trying to specify the path, if i evaluate (string-append (dirname (current-filename)) "/patches/bitcoin-coin-selection-setuppy.patch") anywhere in the package definition (e.g. as a `description` instead of an argument to `patches`) that seems to be enough to trigger this error <nothingmuch>oops, i misleadingly copied only a part of the error, it's preceded by "Exception thrown while printing backtrace:" <nothingmuch>pebcak as usual... (passed string instead of list to patches, still confused about how using current-filename in the descr made it break) <marusich>"make check" succeeds on powerpc64le-linux <marusich>This is using commit 66ab7c740268fa58dabeb2ab9ce476ca60166248 which is now the head of the wip-ppc64le branch in savannah <xelxebar>Anyone using udev-rules-service, does the filename you provide to udev-rule show up under the directory spit out by `herd rules udev`? <xelxebar>For some reason, I'm not finding my udev-rule in there. <shcv>is there a package for emacs native-comp? <Allan[m]>Hi guix. Anyone know how to disable laptop suspend on lid close? I have been searching the manual and cookbook to no avail <shcv>It has a parameter for handle-lid-switch that defaults to suspend <shcv>changing it to 'ignore' might do what you want <nothingmuch>i imported python-pyscaffold, which needs python-pytest-shutil, which depends on path.py which is currently broken (i think setup.py is missing metadata, not sure yet) <Allan[m]>Wow, thanks. I knew I would feel silly about this. I was searching and not finding matches on logind. Anyway, thank you very much for saving me from going down some dark rabbit holes! <nothingmuch>i then created my own definitions of python-pytest-shutil and python-path (new name for python-pathpy), and guix build works for this, but guix build for python-pyscaffold still refers to the python-pytest-shutil in gnu/packages/python-check.scm <nothingmuch>my understanding was that ,python-pytest-shutil would evaluate to my definition (i've even tried renaming it), is that incorrect? <shcv>nothingmuch: I'm not very familiar with these things myself, but if you're importing python-pyscaffold without changing it, it's probably referring to everything from its own module (which would include the old python-pytest-shutil) <nothingmuch>i've defined all of these in my own module, the two invocations of guix build use --load-path <nothingmuch>FWIW, i'm having a few other potentially confounding issues, the goal of this is to get the last package in an environment for a jupyter notebook <nothingmuch>i was seeing the same behaviour before adding '-fixed' suffix to python-pytest-shutil's definition and invocation, and with --load-path, building python-pytest-shutil uses my version but building python-pyscaffold uses the one in python-check.scm in the derivation <nothingmuch>ah it's building *both* versions, so i guess it's some other dependency <shcv>the joys of statically linked dependencies <shcv>I think I read something about some package transformer utilities that might help though <nothingmuch>i suppose in this case the real solution is to figure out what to do with python-pathpy and submit a patch <shcv>those functions apply to the whole graph, so you wouldn't have to write new package definitions <shcv>I agree a real fix would be better, but you might need to figure out what that is first <nothingmuch>for now i think i'll keep trying to get it working first, the package variant stuff should help clean up my definition, but once i actually have an environment with the one dep i need i can take a break from that and try to get the older path.py building <nothingmuch>actually that's not correct - it builds, but the resulting package installation only has metadata, no loadable python package (c.f. `guix environment --ad-hoc python-pathpy --pure -- python -c 'import path'`) <wumpus>Aurora_v_kosmose: it looks like the shutdown events are reaching the kernel, i built acpid from source and ran it in debug mode to test: 'acpid: received input layer event "button/power PBTN 00000080 00000000"' 'acpid: received netlink event "button/power LNXPWRBN:00 00000080 00000003"'-apparently they arrive in two ways, as a input subsystem event and as a netlink event <wumpus>time to learn how to define a guix service for acpid i guess <Aurora_v_kosmose>wumpus: I see. Thanks for pinging me regarding this, I was wondering what you'd find. <wumpus>yes, i was also curious how it worked internally, never really thought about it explicitly before :) <marusich>dftxbs3e, I'm trying to build guix using guix now, and we'll see what happens... Perhaps you've already tried this. Fingers crossed! ***iyzsong-- is now known as iyzsong-w
<vagrantc>and of course, time to head out! happy guixing everyone! ***apteryx is now known as Guest22097
***apteryx_ is now known as apteryx
<aidalgol>When running guix atop a "foreign distro", is it possible to install it for just one user, rather than system wide? <janneke>possibly, if the 'foreign distro' supports per-user package installation, such as nixos <wumpus>aidalgol: no, that's not currently possible, the install has minimal impact on the existing system but it does need to create /gnu as well as needs some linux namespace things that require root permissions IIRC <janneke>yes, and the guix daemon will be available for all, anyway <wumpus>last time i tried it was also not possible to use GUIX from an unprivileged LXC container, due to needing access to "mount" <wumpus>(there might be ways around that though, i just didn't investigate further) <iyzsong-w>may run guix-daemon as the normal user with '--disable-chroot', and make /gnu own by that user (should be same as nix single user mode) <aidalgol>I'll just install and run it normally, then, instead of trying hacks to run guix-daemon unprivileged. <aidalgol>Good to know it has minimal impact on the host system. It was hard to be certain from the docs. <aidalgol>Ah, I may need to come back to this when I'm not sleepy. >_< <narispo>marusich: hello! this is dftxbs3e on mobile btw <sneek>narispo, you have 1 message! <sneek>narispo, marusich says: neat, it's good to see things being reported in the Guix Data Service. Who's building this? Is somebody running Cuirass on a powerpc64-linux system, or is the build farm using the transparent qemu binfmt trick to emulate the builds for the arch? <narispo>marusich: yes I am running a VM on my Talos II with guix-build-coordinator-agent! <balance>Hello! Please help with the next question. How can i do detached header with luks (no lvm) on guixsd? When i do "guix system init /mnt/etc/config.scm /mnt" a error occurs "/mnt/etc/config.scm:22:22: error: no LUKS partition with UUID '11111111-aaaa-2222-bbbb-333333333333'" (here using fake UUID). Read manuals but did not find an example with detached header. <civodul>balance: hi! what's a detached LUKS header? <civodul>Guix expects the LUKS header to be at the start of a partition <xelxebar>civodul: Not OP, but you can actually store a LUKS header separately from the data, like in a separate file on a USB drive or something. This is a "detached header". <civodul>so the answer is: it's not supported yet! <xelxebar>Yeah, this is something I used to do in a different distro and have on my TODO list of Guix contributions <xelxebar>Detached headers are cool, because then your drive just looks like random noise. Gives plausible deniability that the drive is anything else. <xelxebar>balance: The quick and dirty way to get this working now is to use a manual that invokes cryptsetup with the parameters you need. <jonsger>I could get simple-cuirass running, thats good news <jonsger>the bad news: not like I want it. I want it to evaluate guix-channel + thirdparty-channel, but only building all packages from thirdparty-channel. Is that already supported? <jonsger>later I tried the manifest thing out, but it didn't really worked... <mothacehe>jonsger: the only way to do that for now is to pass a manifest containing all the packages of the thirdparty-channel. <mothacehe>jonsger: what's failing with the manifest approach? <jonsger>mothacehe: the evaluations have a yellow cross, but I couldn't find any errors in the evaluation log... <balance>xelxebar: Thank you for answer. You mean to compile cryptsetup with needed parameters? <raghavgururajan>Does Nix on Guix System via nix-service-type works correctly for anyone? <xelxebar>balance: No, no. Nothing that extreme. You can use stock packages but just create a custom initrd (see `info guix "Initial RAM Disk"`). <balance>xelxebar: ok will read about "Initial RAM Disk", thanks <brendyyn>i cant change language settings in icecat. it says it cant connect to the internet <wingo>when using guix time-machine with a channels.scm <wingo>is there a way to avoid having it update the git repo from the internet, if guix has already updated the repo in the past? <abcdw>wingo: you can specify exact commit in your channels.scm to avoid updates after first pull. <wingo>i did specify an exact commit <abcdw>Now it will pull it only on first invocation and after that it should not download anything. <janneke>hmm, something changed here? guix deploy: error: failed to deploy kluit: failed to start Guile on remote host 'kluit.dezyne.org' <civodul>wingo: the time-machine cache used to mistakenly update the repo, even on cache hits <civodul>that is, if you use a recent 'guix time-machine', it won't try to update the repo if the thing is cached ***stikonas_ is now known as stikonas
<leoprikler>raghavgururajan: ice-9/boot-9.scm:1669:16: In procedure raise-exception: <leoprikler>In procedure stat: No such file or directory: "application.h" <apteryx>wingo: this was improved recently, make sure to use a fresh guix to test <apteryx>janneke: that's a rare but reported issue <apteryx>I think civodul had said it had to do with the .go cache on the remote IIRC. *apteryx tries qemu-binfmt with the "F" flag <leoprikler>building my own nextcloud rn, we can compare diffs once I'm done <leoprikler>building qt stuff after hacking on oshu seems such a waste of computation time <wingo>my guix on this machine for some reason doesn't do substitutes. i suspect some shenanigans related to a custom build of guix that i had <wingo>anyway i want to reinstall it. what do i have to keep in mind? <wingo>can i just get the tarball and then obliterate my /gnu and /var ? is there a way to keep the set of packages i have installed in my user profile? <wingo>at least to record the set of packages <wingo>i don't care about the profile history <viljami[m]>noticed that default exwm install of guix does not seem to set up xorg keyboard layout. <civodul>wingo: with recent guix, you can do "guix package --export-manifest" <janneke>civodul: ah right, a compile race -- seen that before <apteryx>sneek later tell vagrant so yes, dynamically linked binaries are not completly pre-loaded even with the F flag, and breaks in containers. See: https://lwn.net/Articles/679536/. There was also a comment about it not working in (gnu services virtualization) :-). <civodul>apteryx: are you trying to avoid the --chroot-directory trick? <apteryx>more like trying to enable our qemu-binfmt config to work with other containers than those of guix-daemon OOTB :-) <apteryx>civodul: but yes, as a side effect it'd make the --chroot-directory trick unnecessary <civodul>apteryx: perhaps we can make that an option? <civodul>shared libs are nice from a resource consumption viewpoint <civodul>OTOH few people are going to change the default... <apteryx>civodul: It doesn't look as wasteful as one would think; it uses a bit disk space to stor ethe 174 MiB of all the user-emulation static QEMU binaries (in the static output), but that's about it <wingo>but in that tarball there is no current-guix in /var/guix/profiles/per-user/root <apteryx>our QEMU package is already gigantic at around 750 MiB anyway. <apteryx>memory consumption to hold the binary in memory would be negligeable for machines intended to do transparent emulation (about 7 MiB per enabled target). <leoprikler>raghavgururajan: see 36824 for oshu patch in the MLs <apteryx>How can I use file-append with a specific package output? *apteryx checks package->bag <leoprikler>raghavgururajan: void Application::slotParseMessage(const QString &msg, QObject *) <- strip the QObject* <viljami[m]><viljami[m] "noticed that default exwm instal"> I wonder where in savannah git repo is the installer, to put an issue <raghavgururajan>leoprikler: The bundled QtLockedFile and QtSingleApplication were not git sub-modules. So we might as well can keep it as is right? <leoprikler>bundled sources are bundled sources and bundled sources are evil <mothacehe>is there a way to know which channel is providing a given package? <leoprikler>`guix show` should give you the file name, which should be a good enough hint <leoprikler>e.g. `guix show <non-free stuff>` delivers the naughty channel it came from <raghavgururajan>leoprikler: Cool! Btw, are you working on the error you mentioned above? <mothacehe>leoprikler: thanks, I need to find a programmatical way. <mothacehe>yup, I'll look this way. The goal is to make the CI able to build packages on a per-channel basis <leoprikler>raghavgururajan: (("slotParseMessage\\(const QString &(msg)?.*\\)" all) "slotParseMessage(const QString &msg)") <efraim>Can you iterate over all the packages to just grab the ones from a certain location? Like is possible for all the ones with a specific build system <lf94>What should I name my package file as? <lf94>For example, I'm packaging nodejs 12 <leoprikler>There is already a node module, just put it there? <leoprikler>as for the variable name node-12 is probably a good idea <leoprikler>if there is already a package for 12, then node-12.20 and so on <lf94>Hm, I'm not sure where "the node module" is on my system <lf94>I used apt to install guix <mothacehe>efraim: (fold-packages (lambda (p k) (if (eq? 'python (build-system-name (package-build-system p))) (cons p k) k)) '()) <mothacehe>but the location is sadly not enough to determine to identify the channel <leoprikler>but remember, that you should actually *package* qtsolutions <pricly_yellow>Hello, how i can convert usual sha256 checksum to checksum that used in package definitions? <leoprikler>the easiest way of obtaining a hash in Guix format would be to use `guix hash` <leoprikler>but there are some internal conversion functions IIRc <wingo>guix.texi:16599: @item outside of table or list <wingo>guix pull currently fails due to not being able to build the manual <raghavgururajan>> leoprikler: but remember, that you should actually *package* qtsolutions <raghavgururajan>You mean by copying .cpp and .h files using copy-build-system right? ***to-hu1 is now known as to-hu
<rekado_>wingo: that’s probably b309a28678664c295e97a70607def02b0c9b4296 <wingo>rekado_: yeah. just pointing it out so someone who's a more regular committer can quick-fix it :) *wingo doesn't know how to guix any more :P <raghavgururajan>leoprikler: Btw, in the patch-set, could you push the appstream though? <rekado_>wingo: oh, I didn’t mean that as “here, go fix it” :) I only meant to assist whomever was trying to fix it. <apteryx>answering my earlier question about 'how to use the specific output of a package with file-append': You use package-file instead, with the #:output keyword argument. <boombim>Hello. How can I change shell to zsh which installed with guix on debian? <wingo>ah great, i am back in business with working substitutes, finally. dunno what was wrong before <dftxbs3e>mothacehe, hey :-D I see you made simple-cuirass-service, that's awesome!! Looking forward to use it on PowerPC 64-bits :-D <dftxbs3e>marusich, re guix tests passing: awesome!! :-D <leoprikler>do you include stuff from version-control by chance? <dftxbs3e>marusich, right syscalls.. I would think GNU Guix uses glibc to abstract over that! <leoprikler>currently hacking on oshu, compiles much faster than rust <dftxbs3e>leoprikler, I just found a semver issue with rust-comrak 0.7.1 (crate was yanked upstream, re-released as 0.8.0), GNU Guix packages 0.7.1, so I am trying to change it back to 0.7.0 since fractal-gtk requires that version specially. <leoprikler>oh, btw. updating rust-anyhow would cause a large number of rebuilds, so can we make do with 1.0.37? <lf94>so I've added my derivative to gnu/packages/node.scm <lf94>But it says source is newer than compiled? <lf94>And it can't find my package... <lf94>gnu/packages/node.scm is like one big "meta package" <lf94>This is not very clear to me in the manual <lf94>nckx: did I maybe miss a section to read? <amadeus->Does anyone know how well guix run on old laptop ? <civodul>amadeus-: hi! some people use it on old Thinkpads <civodul>some 'guix' operations are CPU- and I/O-intensive <lf94>amadeus-: you need at least 128GB of storage. <lf94>(if you use substitutes) <lf94>without substitutes you need even more <lf94>you also need about 1GB of ram <rekado_>128GB? I use it on a laptop with a disk that is smaller than 100GB. <rekado_>50G is fine, but you’d have to run “guix gc” more often. <lf94>I was told if you're using graphical programs, 128GB is much more preferrable <lf94>> In procedure delete-file: No such file or directory <lf94>Does guix not tell you which it couldn't delete? :( <lf94>> (delete-file "test/sequential/test-performance.js") <lf94>So since I have a build error with this one line, but I'm inheriting build instructions... do I have now copy them all over to my inherited package and make it into a regular package? <amadeus->oh ok thank for the answer I've been toying with this distro in a vm and the io/cpu were kinda meh but that's prbbly due to qemu i think <amadeus->and I only have access to old laptop for now <amadeus->host machine has about 4gb of ram,old hdd of 1tb and i3 <hulten>It is an old computer, but does this not mean there's something wrong? <civodul>hulten: that includes build time, right? <hulten>«building profile with 144 packages...» takes a while. <hulten>I talk about the wall time of 'guix package --install-from-file=my-hello.scm'. <civodul>sure, though this example involves building things, so it's not necessarily representative <civodul>building icecat would take even more time ;-) <amadeus->At the end of the guix pull my machine just froze :( <civodul>and yes, the "building profile" phase is i/o-intensive and slow on spinning disks <amadeus->I guess it's not a good idea to try to run in a vm + having emacs exwm on the side <hulten>Then it's clear, thanks civodul. <heloaoban>hey guix! question: is there a way to specifiy multiple downloads as part of guix package origin definition? I'd like to package a bunch of minified js files (one url per file) for use as a dependency for another package. <dftxbs3e>leoprikler, yes anyhow version is fine as flatpak-gtk upstream requires what GNU Guix currently packages and that's anyway semver compatible <hulten>I am trying to install a newer version of unison, following the cook book. I am using (inherit unison), which requires a module. <heloaoban>I'd liek to have a single package that provides these instead of package definition per file. <hulten>What is the name of this module (and how can I find this out myself)? <dftxbs3e>civodul, hello there! :-D Is there a way you think to optimize GNU Guile usage within GNU Guix so that it doesnt try to check for compiled versions of all packages when you're just trying to rebuild a single one? <civodul>dftxbs3e: hi! Guile has nothing to do with that :-), but yes, we could do better <civodul>it's tricky (i pull my hair on it, but i'm a prank), but definitely the way to go <dftxbs3e>civodul, do you think it would be possible to remove the need of compiling packages definitions for GNU Guix altogether (but still compile GNU Guix core code)? <civodul>traversing packages would be very slow <civodul>you can try something like: "rm gnu/packages/*.go ; ./pre-inst-env guix build hello -n" <dftxbs3e>civodul, no way to build a cheap index of some sort? <civodul>'guix pull' produces a cheap index already <dftxbs3e>I really like performance optimization in general, can't wait to know more about Scheme to work on that in GNU Guix <lf94>How do I force guix to rebuild a package? <lf94>guix build --help doesn't give me anything which looks relevant <lf94>--check doesn't seem to do the build process <dftxbs3e>lf94, it does for me here, what does it do for you exactly? <lf94>could you try guix build --check node? <cbaines>you probably need --no-grafts too, otherwise you're checking the grafting derivation <lf94>it says "successfully built /gnu/store/ly941niqchff3552mznv0lhphr8nd0h0-node-10.22.0.drv" <lf94>I'm trying to figure out, despite being nearly an exact copy, why "http-parser" cant be found <lf94>(So I can build node 12) <leoprikler>raghavgururajan: again, the only user of sync should be version-control. Check your inputs. <amadeus->raghavgururajan: ty for the report , is the build,install cycle smooth ? Are you building everything from that machine ? Or offloading to a better pc? <raghavgururajan>amadeus-, I have enabled substitutes. So no explicit building. I usually do --dry-run to see if substitutes are available. Overall functioning is smooth, though you see won't install cycle as fast as in binary-only distros. <apteryx>civodul: I was wondering whether mergefs or other file system level hacks could be employed to hasten 'building' profiles <iis>Hello. How can I kill LibreOffice 6.4 ? is taking more than 20min to open a 15.8 mb .pptx file. Ctrl+q libreoffice procedure doesn't work. [superkey]+Shift+q doesn't work. I cannot see the libreoffice name using top con cli, so I could get the PID to kill it. Some ideas? <apteryx>from what I understand currently at least a stat + symlink operation occurs for every file of the profile union, which means it doesn't scale well (O(n)) ? <dftxbs3e>iis, pid is there on one of the left columns, then, kill <pid> or kill -9 <pid> in case it's reluctant to quitting <civodul>file system hacks are tempting but... <civodul>i see potential (1) portability problems, and (2) reliability problems <apteryx>yes, mergefs would require adding metadata to a profile to 'mount' the overlay in case it isn't already, not great <civodul>yeah, it might be doable on Guix System, but not on foreign distros <apteryx>It could add up to the list of benefits of Guix System ;-) <civodul>(interestingly, there was a mythical GNU package manager project for the Hurd that would use unionfs, a couple of decades before Linux got unionfs :-)) <apteryx>wow! Do you recall the name of such project, by chance? <iis>dftxbs3e, it worked! excellent. Thanks. I take note of this command ps waux, because in other linux distros I used pidof libreoffice and would bring me the PID. Here on Guix pidof doesn't work in that way <apteryx>It'd make for an interesting read, it seems. <civodul>it's a thing that people would discuss at length on the mailing list ca. 2000 <ryanprior>Portability concerns don't seem too important as long as there's a well tested fallback for systems that don't support the optimization. Call it progressive enhancement. <apteryx>hmm, I'm a bit blocked: I want a file-append gexp-input to be expanded with a specific output <apteryx>ah, I had missed that from the manual: (ungexp OBJ OUTPUT) or #$OBJ:OUTPUT (info '(guix)G-Expressions') <apteryx>file-append can take any gexp as its first argument <apteryx>ah, sadly it says: invalid G-expression input <hulten>I used in a package.scm '(use modules (guix licenses))', and in guix/licenses.scm there is 'gpl3+' defined, but why do I still get the error "error: license:gpl3+: unbound variable"? <roptat>apteryx, maybe (gexp-input foo "otherout")? <nckx>hulten: Add #:prefix licence. <nckx>hulten: #:use-module ((guix licenses) #:prefix license:) to be precise. <NieDzejkob>here's, essentially, my notes from the last time I had to deal with this <hulten>nckx, thanks, I think this solves this issue. <apteryx>roptat: that also throws invalid G-expression input <roptat>#~(string-append #$foo:otherout "/bin/foo") :p <apteryx>right, the workaround found by NieDzejkob <cbaines>does anyone know how to list filesystems on the hurd? <cbaines>I would try using fdisk, but I can't build that with Guix (dependencies fail to build) <apteryx>and now, 'docker run --rm -it arm32v7/debian' works as expected on my x86_64 machine <cbaines>I'm seeing test failures with Guix, particularly fold-available-packages with/without cache <cbaines>but I also see the failure when running : ./pre-inst-env guix build -e "((@ (gnu packages package-management) current-guix))" <marusich>I have recently run make check on wip-ppc64le, and it all passed. <marusich>master was recently merged into there, but perhaps it is missing something triggering the issue for you? <apteryx>is chroot-directories useful outside sharing QEMU with the guix-daemon container? <Aurora_v_kosmose>I've got the cl-irc package building, but for some reason the tests won't run correctly. <Aurora_v_kosmose>If I tell it to only use cl-irc.asd it builds without errors. But when it tries to build cl-irc-test.asd, it starts trying to compile a "c" system. <cbaines>maybe the Guix Data Service could compute/store a derivation that builds the guix package with the source for that commit... that way it could be built for every commit, and then it would at least be easier to spot when things break... <cbaines>if that happened, it could be tested for patches as well, which might stop things breaking <cbaines>unfortunately, (current-guix) can't be used from a channel (just a Git repository) so it requires a bit of thinking <apteryx>weird; I 'sudo -E ./pre-inst-env guix system reconfigure'd my guix, then 'sudo herd restart guix-daemon', but the args found in ps for it do not match the guix-daemon.scm service definition referenced by /run/current-system <apteryx>ah, I removed its qemu-binfmt-guix-chroot service extension; perhaps those are not cleared from shepherd's memory or something <lfam>IME, it's always worth rebooting after reconfiguring <NieDzejkob>apteryx: did you configure your repo with the right options? <pkill9>i thought guix had created a broken nginx configuration, turns out i accidentally deleted index.html and nginx reported '500 internal error' <Aurora_v_kosmose>nginx defaults to low-detail error messages for safety reasons. There was some way to enable debugging output... <apteryx>NieDzejkob: do you mean the configure --localstatevar=/var and --sysconfdir=etc options? <apteryx>lfam: sadly I've had experiences like that too <apteryx>mbakke: For now we can raise the timeout values. I'll send a patch stripping that soon using the linux-libre tarballs directly soon (TM). <pkill9>does anyone have an example of how to redirect all http to https in nginx? <jonsger>pkill9: I think (listen '("443 ssl")) works <pkill9>doesn't work for me, http gives 500 internal error, https works though <pkill9>oh actually https doesn't work now weird <pkill9>well it seems to be already doing it anyway so idk <lfam>pkill9: You need to create a server block that listens on port 80 and returns a 301 redirection to the same URL but with https <lfam>That's a permanent redirection so it's appropriate if you never want to serve anything on port 80 again <pkill9>looking at the generated nginx.conf it looks like guix puts that in <pkill9>ok it acutally does seem to hav ea server block for redirecting all http to https <pkill9>but the other server block is also listening on port 80 <pkill9>so the change should work, i'll test again <lfam>Make sure the running nginx is using the configuration file you think it is using. You can check the output of `ps aux` to see exactly which configuration file is effective <pkill9>it's using the new config yet it's not working, all it's done is remove 'listen 80;' from the server block <lfam>You should share your configuration file. It's too hard to help this way <pkill9>I'm sorry, the problem wasn't the listen block, I had it set to the wrong root directory :/ <pkill9>by setting (listen '("443 ssl")) which removes the default (listen '("80" "443 ssl")) <lfam>Right, in another server block? <lfam>Oh, you are using the Guix configuration <pkill9>guix configuration automatically adds a server block just for redirecting http to https <pkill9>but the server block for the domain itself by default was listening on port 80, so it was not redirecting <pkill9>so it captured the traffic before the redirect block <civodul>thing is, the MIT published several licenses, that's why "*the* MIT license" isn't accurate <civodul>pkill9: it's the name of a library, see "guix show expat <lfam>sss2: Try again without the nonguix channel <lfam>Or, any of the extra channels <lfam>It's almost certainly an incompatibility in one of them <civodul>(or report the issue to these projects) <Aurora_v_kosmose>It's confusing, because their site says MIT-style, I pasted what's in the repo because CVS is dead, and it does look more like what you posted. <Aurora_v_kosmose>I'll write it down as BSD-2, because that's definitely closer, and it seems compatible at a glance. <lfam>It's definitely not MIT or expat <sss2>stupid question. how to properly remove channel ?, just remove it from channels.scm does not work ... <lfam>Don't worry, there's no stupid questions here :) <lfam>Now, does anyone know the answer? I'm still not using channels... <Aurora_v_kosmose>Perhaps pulling? There doesn't seem to be anything in the manual about removing channels. <civodul>sss2: remove from ~/.config/guix/channels.scm and pull <sss2>civodul, does not work ) <civodul>sss2: 'guix pull' pulls exactly the channels listed in that file, or in /etc/guix/channels.scm as noted in the manual <Aurora_v_kosmose>Huh. Do you use the ~/.config/guix/channels.scm file or only /etc/guix/channels.scm? <sss2>but if i remove channels.scm, only guix channel is pulling, probabluy it is somehow related to default-channels variable <sss2>can you provide exact command ? <Aurora_v_kosmose>"guix repl" -> "(use-modules (guix channels))" "%default-channels"; From your terminal, writing what's within the quotes. <apteryx>it's funny to think that the ability for every project to peg each of their dependency to an exact commit such as can be done in go is essentially equivalent to bundling sources (you now have a zillon of copies to maintain)' <lfam>It could be considered bundling, or something else <lfam>I think it's a new paradigm <apteryx>lfam: it can't be good from a security perspective <lfam>I read the Gentoo blog article. I don't think it's necessarily good or bad from that perspective <Aurora_v_kosmose>Pinning to major versions in semvar would be a step forward, but that leaves the whole "signaling major version deprecration" problem unaddressed. <sss2>ah, dependency, most probably so <lfam>Generally, the "ecosystems" of software that represent this new approach are immature. It took a long time for the old world to invent and perfect distros, and it will take time for the new world to achieve that, too <alextee[m]>is it possible to setup guix to use pipewire only instead of alsa/jack/pulse? *rekado_ twitches, but is happy about the quotes around “ecosystems” <lfam>I know, but what word would you use, rekado? :) <apteryx>lfam: I made that comment before reading the article :-). I was trying to update Docker and noticed about the *load of vendored deps. <lfam>I think it's undeniable that the worlds of Go and Rust are not part of the "thing" that is represented by Debian and Gentoo <rekado_>lfam: I don’t know. It’s much easier to express discomfort than it is to come up with a word that would be more comfortable. <lfam>I have a lot of thoughts on this subject :) <sss2>yes, they all depends on nonguix channel <lfam>I think that these older distros and the software they package... they grew up together, and depend on each other in many ways. <Aurora_v_kosmose>Hm, it shouldn't be too hard to recursively walk a depedency tree and see obsolete packages for which higher major versions exist. But that assumes devs even bother to use semvar properly. <rekado_>I had an idle thought about static linking. If you squint, what Guix does looks like static linking by constraining dynamic linking. <heloaoban>any reason while guile wouldn't be able to resolve gnu/packages/python-build on my machine? <Aurora_v_kosmose>And it's dubious whether disabling support for obsolete packages would help. <heloaoban>(use-modules (gnu packages python-xyz)) works fine but (gnu packages python-build) throws a 'no code for module' <rekado_>heloaoban:does your repository have any changes? <lfam>I think that what Guix does is actually the same thing as what Go and Rust do. But we do it in different places, we have a different name for it, and we think of ourselves as part of that old world, rather than the new world <heloaoban>rekado_: lol I hope I'm not that dumb, let me check... <lfam>You might also double-check for typos :) <rekado_>heloaoban: also, if there is any more output (even if it appears unrelated) — that could be useful <lfam>I mean, the Go compiler implements of memoized cache of software dependencies in a graph... <Aurora_v_kosmose>rekado_: On one hand yeah, on the other Guix also transparently upgrades to newer versions of packages. It just gives an easy way to find what went wrong. <heloaoban>it's present in my personal checkout of guix (which is a couple days stale) so I assumed it must be in my machine's checkout, but maybe that file was added just recently? <rekado_>it’s funny how much harder it is to cooperate for any two projects the closer they are, conceptually speaking <rekado_>heloaoban: it was addid on Thu Jan 14 16:27:39 2021 -0500 <rekado_>(wow, that sentence I wrote reads like Yoda had a stroke.) <rekado_>I wonder if bundling dependencies is an example of the tragedy of the commons in that the local avoidance of complexity leads to greater global complexity, which leads to a systemic reduction in software reliability. <rekado_>Or perhaps it’s just an example of entropy where local order always comes at the cost of increased disorder elsewhere.