<jpoiret>well, since packages in other distros are often installed globally, you can't make 2 versions of 1 package co-exist <jpoiret>that gets worse when you want to downgrade package A, that depends on package D, but package B also depends on package B <jpoiret>if a downgraded package A expects an older package D, then you won't be able to make the new and old D co-exist <jpoiret>nij-: well, it'll only do so in a very controlled manner. Packages in guix don't try to look up other binaries in the PATH (exceptions apply), but rather use their full store name <jpoiret>that way, even if you install hello 0.1, if package A was made to depend on hello 0.4, it will use /gnu/store/xxxxx-hello-0.4/bin/hello <nij->!! This is the true merit. Got it! <jpoiret>i'll be going to sleep though now, but the manual should really tell you most of what you're seeking <jpoiret>note though that the above implies that these kinds of invocations should be patched by the packager, which is why packaging for Guix is often a bit harder <nij->Usuaully a package is not written with guix in mind. <jpoiret>although, for some packages, the package definitions are incredibly trivial <nij->In the software they could have just called `hello`. <nij->ANd guix packager need to take care of that kind of issue. <nij->If it's a closed source software, there'd be no way out of it. <nij->And that's a legit limitation of guix for people who want to use them, right? <ekaitz>nij-: exactly, that's why we don't like closed source stuff <ekaitz>nij-: but there are other ways -> creating containers <ekaitz>nij-: if you generate a guix shell with appropriate variables set, you can make the software running on it see the /bin or the /lib folder (or anything) as part of your current setup <ekaitz>that way, even if they call /bin/program_name they would be pointing to the correct entry in the store (that you set up properly) <AhmedNabil[m]>I'm sorry for saying that an error on latest download page I know now it's building system was creating new iso build <iska>Hii! I'm just wondering, can Guix System run on ARM? <iska>There's no ISO for it, but the distro is source based. <KiranShila[m]>The `rust-clap-3` package isn't actually v3, it's a beta from 2 years ago and won't match any rust `clap = "3"` dependency ***the_tubular49 is now known as the_tubular
<KiranShila[m]><KiranShila[m]> "The `rust-clap-3` package isn'..." <- I just submitted a patch for this <char[m]>Hello guix. What is the way to modify the phases of an inherited package? <char[m]>oouu I found: substitute-keyword-arguments ***haugh[m] is now known as haugh
<vhallac>Hello. Is it possible to get "guix shell" to work with eshell? <andrzejku>is it something like guix daemon is too new? <andrzejku>while the manifest which it analyze and download have obsolete syntax <jpoiret>andrzejku: ouch. are they on guix system? <jpoiret>if so, can they run `/run/current-system/profile/bin/guix describe`? <andrzejku>jpoiret, yeah he installed guix yesterday like me <jpoiret>i think it's a known bug, but it'll be a bit annoying to fix <unmatched-paren>i wonder what it is with guix that causes these bugs all the time. not trying to downplay the hard work people put in to guix, but sometimes it still feels like experimental technology even though 1.0 was ages ago <unmatched-paren>and the compilation time doesn't help there. we need better dependency resolution, as has been pointed out here a few times :) <jpoiret>yes, the manifest upgrade bug was kind of a disaster <jpoiret>but it'd need a big concerted effort to rework how guix is built <jpoiret>one thing i'd love is to be able to compartimentalize guix bootstrap with guix proper <jpoiret>for now, we're just relying on the fact that a subset of modules used by guix at an early stage don't try to use external dependencies <jpoiret>i think a big blocker for now is that we use autotools at an early stage <civodul>it'd be interesting to see how we could have avoided the manifest upgrade bug <civodul>everyone could tell an older Guix would be unable to read a newer manifest, but it's much harder to foresee all the implications (it never occurred to me things could go wrong like this) <unmatched-paren>probably bad proposal: kill the autotools setup and use a hand-coded external tool <jpoiret>i think using an improved (current-guix) unconditionally would be bettern <jpoiret>autotools is really needed for the daemon unfortunately <jpoiret>as much as i hate autotools, it's the #1 thing for portability <civodul>not like we really need portability though :-) <jpoiret>right, for now we don't, but i don't think we should close the doors so soon <jpoiret>we shouldn't make it harder for future hackers to add support for other oses <jpoiret>and, say you're building on another distro with an older libc, and guile without threads and whatnot <jpoiret>maybe my mail was a little dry about the whole issue, and maybe it's too big of an undertaking <jpoiret>but right now i'm feeling a bit stuck with C extension. It works locally on my dev setup, inferiors use it, but i don't want to test in production <efraim>we already require guile-3.0.5 IIRC <jpoiret>right, but guile could be built without threads <unmatched-paren>personally i don't care about _backwards_ compatibility too much but I do care about _sideways_ compatibilitf <unmatched-paren>if some silly company is still using gcc 4 on a really old RHEL contract, that's their problem <unmatched-paren>but if a user of netbsd tells me that my program crashes on it, that's my problem <jpoiret>uhm, guix really won't work on netbsd right now though <jpoiret>but yeah, we shouldn't close the door to guix possibly running on BSDs in the future <jpoiret>unmatched-paren: well, we need it to generate the configure, and also for the Makefile.am -> makefile <civodul>cbaines: i wonder if we should just add a link to that from mumi, and/or have the Data Service email the issue with a status report like: "successfully applied, and successfully built" <civodul>jpoiret: Guix targets systems with glibc, which concretely means one of two "kernels" at this stage <cbaines>civodul, a suggestion I got from Arun was to use SVG badges, so have a badge or several badges that contain the information and have issues.guix.gnu.org show them on the page <cbaines>which sounds like a good place to start, hopefully that might be achievable in the next couple of months <civodul>the only downside is that we won't see it in debbugs.el :-) <unmatched-paren>mumi could look for the 'working' tag and if the issue has it slap on a badge <cbaines>yeah, I think there are potentially some issues. I'm not sure if SVG's are great for accessibility (like will a screenreader make sense of it) <cbaines>but hopefully once there's something working, it will be easier to iterate and yeah, send an email with the test information once it's available, or other things like that <jpoiret>cbaines: i think you can use svgs in an accessible manner with proper html <cbaines>jpoiret, I think I did see some things about using the svg tag, but this would be using an img tag with no alt text <cbaines>I'm not saying we shouldn't do it though, just that iterating might be good <jpoiret>civodul: yup, i think it's the culprit <reyman>i will try some guile to curl something today, hope i will success :) <jpoiret>looking at the installer code, i think it'd be okay to warn the user and abort the step there. That means that the user would lose the partitions they set up on that step, but alas <jpoiret>unmatched-paren: right, we could definitely replace that <jpoiret>but we'd need a build system written all in guile ***wielaard is now known as mjw
<mrvdb->I am trying out guix on powerpc64le (Talos II machine), 'guix install python-numpy' fails and the log says it can't find '/bin/true'. That file is obviously there (in many '/bin/' locations) What is my next step here? Not familiar enough with the system yet. <efraim>can using debbugs control messages be made to work well enough? <jpoiret>mrvdb-: what log? the build log? can you send your full error at paste.debian.net <efraim>mrvdb-: what stage does it happen in? While its building the package? <cbaines>it looks like there might be architecture specific tests <efraim>that's what I'm guessing based on it literally calling /bin/true <reyman>i'm trying to load a module installed by manifest : guile-curl and guile-json <jpoiret>otherwise the search paths won't be set <efraim>if I can set GUIX_DAEMON_SOCKET for our ppc64le machine I can try doing more than just substituting out '/bin/true' <mrvdb->efraim: during check phase by the looks of it <reyman>hum, "no code for module (curl web json)" <jpoiret>reyman: you shouldn't try to load (curl web json) but rather (curl) (web) and (json) <jpoiret>ie (use-modules (curl) (web) (json)) <jpoiret>with (define-module ...) it's (define-module #:use-module (curl) #:use-module (web) #:use-module (json)) <reyman>yeah you're right, i try to write a script that curl some files, called from another script that embark my R analysis to reproduce <efraim>it looks like that's the only instance of /bin/true in the code base. I've substituted it and I'll try building it on ppc64le <reyman>if my download.scm is only a script to curl and unzip some file is it better to encapsule into one module, or leaving like that <efraim>actually I wonder if instead of patching out /bin/true if we should be enforcing specific cpu features for ppc64le <mrvdb->anything i can do locally other than using --without-tests? <efraim>with /bin/true substituted it built fine, let me commit and push that and I'll go back to looking at possible optimizations <efraim>mrvdb-: if you run 'guix pull' python-numpy is now fixed <jpoiret>(I don't really know of any other image host) <jpoiret>xmszkn: this is a known issue. let me check if we have a quick and dirty workaround <jpoiret>can you try `mkdir -p ~/.config/guix/current && guix pull -p ~/.config/guix/current`? <jpoiret>if that pull succeeds, you'll have to reconfigure your system asap, so that the broken system-wide guix gets updated <xmszkn>I can;t the same error unsuported manifest format <xmszkn>which .iso file is good, not broken? <xmszkn>btw standard version have bug in installator <xmszkn>in stard version is imposible to use manual partition tool in graphics instalator <jpoiret>no, that bug is still present possibly <jpoiret>did you ask for a partition not to be formatted? <civodul>jpoiret: i can't access imgur.com: it wants JS, rejects Tor connections, bah <civodul>i don't know of other image hosts though <jpoiret>fun fact: i thought that my local patch successfully added an error message for when the installer can't read the UUID <jpoiret>but actually there was already such a warning with the exact same wording <jpoiret>see check-user-partitions in installer/parted.scm, which is used at the end of run-disk-page in installer/newt/partition.scm <civodul>jpoiret: so you managed to reproduce the bug? <jpoiret>no, but actually Mathieu added such a check before in f5d9d6ec68f78f5651bd5a698f489ab57bf77d5d <jpoiret>well, rather i can't reproduce the bug with current master because the check is now here <xmszkn>in latest version I didn't any problems wiht partiotioning and format <jpoiret>well, in any case the 1.3 installer is missing quite a lot of fixes <civodul>yes, we need to get that release out! <jpoiret>we still have that elusive guile-parted segfault though <jpoiret>some people have been experiencing an outright crash of the latest installer <jpoiret>it's just a hunch, since we haven't got any debug info ***GNUtoo_ is now known as GNUtoo
<muradm>fail2ban would go to (gnu packages admin) or (gnu packages networking)? <apteryx>I'd put it in (gnu packages admin) I think <apteryx>are you packaging it? that's a welcome addition! <muradm>what about fail2ban-service-type? <dlowe>I'd put it in the same place as firewalls and iptables <mrvdb->Is there a way to limit guix's use of cpu cores? Like 'all but 4' so I can keep doing stuff while guix is compiling the world <muradm>apterix: yes, packaging was painful but seems done, thinking about fail2ban-service-type now <apteryx>there's a (gnu services admin) module already, but lemme check what's in it to see if it's a good fit <muradm>dlowe: iptables in (gnu packages linux).. i don't feel like fail2ban should be there <apteryx>perhaps you can create a new (gnu services security) module <mrvdb->efraim: the python-numpy change worked perfectly, thanks for your time! <robin>mrvdb-, check out (info "(guix)Common Build Options"), --cores (-c) or --max-jobs (-M) might be what you're looking for <muradm>apteryx: (gnu services admin) too tidy for fail2ban for me :) <apteryx>you migth want to use define-configuration & friends for it to produce self-validated records <muradm>i would put to (gnu services networking) since it is kinda networking security, but then (gnu services security) sounds good <mrvdb->robin: found those indeed, but i was wondering to set a global upper limit for every user on the machine <apteryx>reyman: hi! please juse the paste.debian.net as in the topic for those of us using no-js scripts (e.g., icecat + librejs) <apteryx>regular 'let' doesn't allow using previous bindings <robin>mrvdb-, for that i think you'd have to change the extra-options field of guix-configuration (node "Base Services"), which allows at least --cores and --max-jobs <apteryx>reyman: you're welcome! as another welcome tip to IRC, you don't need to refer to people with @, most IRC clients simply highlight any nickname mentioned <apteryx>how can I invoke Guile's ',trace' programatically? <apteryx>I want to debug something weird in a phase <robin>mrvdb-, something like (modify-services %desktop-services (guix-service-type config => (guix-configuration (inherit config) (extra-options ...)))) on desktop configs i think <robin>(replacing the original %desktop-services reference, or %base-services or whatever) <robin>apteryx, i think you'd want to use add-trace-at-procedure-call! from (system vm trap-state) <robin>(i haven't tried non-interactive tracing before tho, and it might require some other fiddling with the VM that ,trace does for you, dunno) <robin>np, you might also want to read guile's VM Hooks (might need set-vm-engine! or call-with-vm or something depending on how guix sets things up) <apteryx>ah, add-trace-at-procedure-call! is apparently a breakpoint, from info '(guile) High-Level Traps' <robin>that's add-trap-at-procedure-call! unless i'm misreading <reyman>hum, in my alist i have something like that, what's this type with # ? => #((("links" <reyman>thanks @apteryx, i found that using goops i could get the type with class-of :) <robin>apteryx, np :) hopefully it DTRT outside a repl environment <reyman>(i continue to add @ by default ahah sorry) <apteryx>reyman: yes, class-of from (oop goops) is useful indeed <reyman>"learning guile the hardway" ahah :) <reyman>two hour to make one function lol <apteryx>robin: odd, it caused the build to abort without any error <apteryx>I'll try trace-calls-in-procedure proc <robin>apteryx, i bet it's not using the debug vm, but how to use it is poorly documented :/ (set-vm-engine! 'debug) ...somewhere might help <robin>(call-with-vm seems not to do anything??) <robin>#guile might be more helpful if your next attempt doesn't work <jorge[m]>Hi, I am presenting this error at boot for the installation of i Guix sistem " error: no such device : 1970-01-01-19-49-46-83. " ***rgherdt_ is now known as rgherdt
<apteryx>call-with-vm is defined in libguile/vm.c -> "Apply @var{proc} to @var{args} in a dynamic extent in which @var{vm} is the current VM." <apteryx>but yes, that's getting a bit Guile deep for #guix :-) <apteryx>I'll try (set-vm-engine! 1), given in libguile/vm.h it has #define SCM_VM_DEBUG_ENGINE 1 <the_tubular>Umm, I just guix pulled and guix upgraded and got a lot of weird output i've never seen before <apteryx>the_tubular: you are saying that 'guix pull' is broken? <apteryx>the error seems to be missing from your paste <lispmacs[work]>should we report challenge fails where there is a difference between the ci and the bordeaux builds? Or is that automatically checked by something? <apteryx>but that appears to be a test failure in glib 2.70.2 <the_tubular>Guix pulled just pushed trough, next line after the paste is : building /gnu/store/wp6wmy6kghmjbbz16gf5kf6k7h4zdbaj-ibus-1.5.24.drv.. <the_tubular>I've just never seen such a traceback after running guix pull, I might be in guix upgrade though, I ran both in the same command <vagrantc>lispmacs[work]: i did a summary of all the reproducibility issues i could find last month <andrzejku>jpoiret, guix describe: error: unsupported manifest format <andrzejku>jpoiret, every guix command finishes like that <vagrantc>lispmacs[work]: curious which packages and what sort of issues you found ... <lispmacs[work]>questions regarding grafts: so, if you want to challenge a package to compare a local build to a ci/bordeaux substitue, is this even possible when grafts are involved? <lispmacs[work]>If I do "guix build --no-substitutes --no-grafts -v 1 lagrange" I get different package hash than the one installed from the substitute, so presumably I'm not actually building the same package <lispmacs[work]>but "guix build --no-substitute -v 1 lagrange" will not rebuild the package from source, even if I throw --check in there <cbaines>generally, substitutes don't overlap with grafts, so when you're comparing local builds against substiutes, you're going to comparing ungrafted outputs <lispmacs[work]>so... reading the docs... I think I think where I've gone wrong here is that grafts are not actually modifications of the package, loosely speaking, as just modifications of the package's dependencies <lispmacs[work]>so it really makes more sense to compare builds of the original ungrafted package <cbaines>my understanding of grafts is: you have a derivation for a package, you build that derivation and you get some /gnu/store/... output <podiki[m]>regarding the fhs-container patch, is there an easy way to try out this modified guix shell/environment script version without doing so from a guix check out environment? I'd like to do some more testing but being in a pure shell for guix building adds complications <podiki[m]>can I just do some sort of guild load-path...? <cbaines>say that output references guile, because it's a program written in Guile. Let's also say that the guile package has a replacement to fix some security issue. Applying a graft to the package output would mean taking references to the vulnerable guile, and replacing them with the replacement guile <apteryx>podiki[m]: once your tree is built, you can exit the guix pure shell <apteryx>and you can source the pre-inst-env script then use guix as usual <apteryx>with the --fhs-container new faature <podiki[m]>great, that would be handy for testing some actual graphical programs without going too crazy through 2 layers :) <podiki[m]>(a certain non-free package I worked on had something like 3 or 4 layers of containers in the end which was maddening to debug) <podiki[m]>apteryx: and thanks for your detailed comments, I think between yours and lilyp I can produce a patch to submit for proper review <podiki[m]>I think I'll do that this weekend along with more testing <minima>i used 'guix import texlive' to create some latex package definitions; all my work was just very minor changes to the 'guix import' output; would it still make sense to contribute these defs back to guix? <minima>the defs i came up with work (and i was able to replace texlive with texlive-base plus a series of texlive packages, yay!); but as i said it's just minor changes <podiki[m]>patches don't have to be complicated to be worthwhile <podiki[m]>and as you said, having more texlive- packages so people can use the smaller texlive is great <podiki[m]>it is a testament to the importers when you don't have to change much <minima>great, i've started reading the how-to-contribute section on the guix site, so i'll follow that and send something over over the weekend <podiki[m]>mostly you'll just want to make sure you have one new package per commit, the changelog commit message will be easy for new packages (see the yasnippet if you use emacs or see what others have done) <minima>podiki[m]: totally, it was really astonishing to run this command, change a line in the output, install the package, iterate and... boom! a working replacement for my texlive installation! very rewarding indeed <podiki[m]>and don't sweat the details for your first contribution, people will help <podiki[m]>I've had guix import get like a hundred packages and do very minimal changes to have it work, great when that happens <muradm>sentences in description should be followed by two spaces; possible infractions at 111, 244, 581 <muradm>i don't understan above warning from lint ^^^ <lilyp>muradm: these positions are relative to the start of the string <lilyp>In any case search for (literal) ". " and check that a second space is after your match <lilyp>you might also try "\\. [A-Z]" if you're looking for a regexp <muradm>lilyp: it wants two spaces after "."? <lilyp>two[m]: I think the [m] suffix is really only visible to us IRC folk, thus Matrix thinks you're "two" without [m] <muradm>guix lint: label 'bind' does not match package name 'bind:utils' ? <muradm>it points to (inputs (list ...)) which includes `(,isc-bind "utils") <muradm>guix lint: scheduled Software Heritage archival ?? <unmatched-paren>muradm: software heritage ("swh") is kind of like archive.org for free software <singpolyma>They archive nonfree software if they can get access to it <singpolyma>Since at the scale of their mission all source code becomes free software <singpolyma>So far it seems like the next extension is not coming. But it's not over until it's over of course ***Dynom_ is now known as Guest8025
<muradm>unmatched-paren: i can assume what it says about heritage, i don't understand why lint says so, and what should i do (if i have to do anything) to clean this? <roptat>mh, I'm having an issue trying to cross-compile llvm-9 <roptat>it looks like it's related to LLVM_TABLEGEN, which is defined in llvm-12 as #+(file-append this-package "/bin/llvmtblgen") <roptat>it's part of the configure flags, in arguments <roptat>llvm-11 inherits from it and so does llvm-10 <roptat>llvm-9 has something like this: (arguments (if riscv ... (package-arguments llvm-10))) <roptat>and looking at the builder, I see that LLVM_TABLEGEN is `llvm-10`/bin/llvmtblgen <roptat>so this-package is correctly expanded in llvm-12 to llvm-10, but then, it's no longer working as expected in llvm-9 and it causes a build failure <roptat>is there anything I can do to make this-package evaluate in the context of llvm-9? <apteryx>what does 'link' in Guile do? is it equivalent to a hard link? <unmatched-paren>muradm: it's just letting you know that the source code isn't in swh's database yet so it's being sent over <muradm>unmatched-paren: it says that everytime i write guix lint :) <roptat>I figured something out and it doesn't change the derivation for the native build :) <roptat>mh, and now cross-compiling libcxx, it uses the native libc instead of the cross libc :/ <muradm>bug#56579: Acknowledgement ([PATCH] gnu: admin: Add fail2ban 0.11.2.) <lilyp>muradm: try to use functions as abstractions, also g-expressions exist <ardon>Is anyone using OCaml with guix? How can I use findlib to manage my packages instead of having to install opam and install them through there? I currenly have a "#use topfind" expression in my ~/.ocamlinit but the REPL spits out "Cannot find file topfind" <muradm>lilyp: i see what you are saying about search-input-file, but "functions as abstractions"? <lilyp>you have quite a number of commands that you want to search-input-file, for example <muradm>lilyp: yes i got that, will change now, i don't think i clearly understand first part of your comment <lilyp>better, but you can still simplify the overall expression <muradm>lilyp: i'm travelling now, and can't reach issues.guix.gnu.org :) <apteryx>how can I swap (guix build utils) for (guix build utils2) in a build system? <lilyp>if it's just for one package, I'd say try creating a (guix build-system your-build-system2), which has #:modules and #:imported-modules set up correctly <apteryx>worked fine for the glib-or-gtk{,-build-system}2, but (guix build utils2) won't be found even I've adjusted the references <lilyp>if that doesn't do it, also rewrite (guix build your-build-system) <lilyp>so that the #:use-module inside refers to utils2 <apteryx>[ 1/10] Loading './guix/build/glib-or-gtk-build-system2.scm'... -> no code for module (guix build utils2) <lilyp>hum, I take it that the module you wrote *is* correctly patched up, right? <apteryx>glib-or-gtk2 has (guix build utils2) in its %default-modules <apteryx>ah, perhaps I forgot to add it to %glib-or-gtk-build-system-modules2 <roptat>ardon, I only use OCaml packages, I don't use OCaml interactively <roptat>and I think you're not the first person to report this issue <roptat>I don't know OCaml enough to know how to fix it <f1refly>excuse me, is gdm currently broken? I've been using slim for the last months but I want to go back to gdm because I want to use sway due to my highdpi display. I removed the slim service and don't remove gdm anymore, but when I start the machine I boot to a login prompt without cursor.. <roptat>f1refly, gdm works fine for me, you might have made a mistake in your config somewhere <roptat>if you share it, we could have a look, maybe more eyeballs could figure out if something's wrong :) <f1refly>I'm currently in the process of throwing everything out and testing when it'll work again <ardon>drakonis roptat: Thanks, I think it's just a matter of specifying a "#directory <dir>" directive in your OCaml initialization file to the OCaml libraries path in your user profile <roptat>f1refly, you can always boot the previous generation if you need a graphical display, at least <ardon>drakonis: You answered to me, I take that as help :) <roptat>ardon, ok, if that works that's great <roptat>maybe we could keep a note about it somewhere <Guest99>Is anyone else unable to change the display resolution of the official Guix VM image? I can select a new resolution, and it works for a split second, then goes back to the default 1280x800. My host is mac os. <roptat>oh, I was copying CPLUS_INCLUDE_PATH into CROS_CPLUS_INCLUDE_PATH, so of cours it couldn't work <muradm>lilyp: i updated 56579 with search-input-file, altough i don't see how it can be reduced more. if you are pointing to generalizing this part https://paste.rs/UQu, it would be hard, as these patterns are crafted not to break tons of places <muradm>on my side, i would note that i don't need to fix stuff from coreutils, just allow to resolve it from path may be <lilyp>still, I think it'd make more sense if you inlined a few of those <muradm>lilyp: ah, you are saying, don't let-bind, just use (search-input-file ...) in substitute* <f1refly>roptat: I know, it's great to freely modify everything about my system and know I can just go back from grub :) <lilyp>e.g. (("(echo|head|grep) " all cmd) (string-append (search-input-file inputs (string-append "/bin/cmd")) " ")) <muradm>lilyp: i tried that, while possible, there are so many of them, after 3-5 reductions patterns become unmanagable <apteryx>haha, did something change with canonicalize-path in guile? <muradm>lilyp: just look at etc/failban/action.d/*.conf files <lilyp>likewise, you can group ip6?tables, ip -[46] addr, and so on <apteryx>(canonicalize-path wrapped-file), where wrapped-file is "/gnu/store/s1zycvd81nxycagxcgkdywskg34z77zi-vala-0.54.2/bin/.vala-real", yields "/gnu/store/s1zycvd81nxycagxcgkdywskg34z77zi-vala-0.54.2/bin/valac-0.54". <apteryx>the .vala-real file is a hard link (made with Guile's 'link' procedure) to "/gnu/store/s1zycvd81nxycagxcgkdywskg34z77zi-vala-0.54.2/bin/vala" <lilyp>oh, I think I know what's wrong <lilyp>vala points to valac-version initially <apteryx>so we resolve the source of our real program link target <f1refly>alright, I have no idea why gdm is still not showing up. Would someone be kind enough to take a look at my system? http://ix.io/44so <lilyp>apteryx: interesting spider web to disentangle <lilyp>f1refly: I assume you have a weird graphics card that wants to use some blobby kernel driver? <apteryx>the giveaway though is that there's nothing else but valac <f1refly>lilyp: intel uhd integrated graphics, should be widely supported <apteryx>whether it's 'vala', 'vala-0.54' or valac, it all resolves to 'valac-0.54' <lilyp>hmm, in that case shouldn't linux-libre suffice? <lilyp>your wifi shouldn't mess with gdm <lilyp>source: am using linux-libre at the cost of wifi ***mark_ is now known as mjw
<f1refly>Do you suggest using linux-libre for testing purposes for gdm? <lilyp>my suggestion is always to use the smallest system first and then walk towards the bigger parts <lilyp>usually this means starting from bare-bones, but if linux-libre+gdm works for you that's also a good starting point <f1refly>I guess I'll throw out more stuff from my confi <Guest99>Is anyone else unable to change the display resolution of the official Guix VM image? I can select a new resolution, and it works for a split second, then goes back to the default 1280x800. My host is mac os. <lilyp>muradm: instead of si, try something meaningful like "lookup-command" which adds the "/bin", otherwise already much better <lilyp>for the file deletions you might want to use some directory excursions <f1refly>this configuration, which is basically just my filesystems and a bit of fluff so I don't boot into a tty, also doesn't seems to make gdm happy http://ix.io/44sr <lilyp>any hint as to what's wrong, like gdm output? <f1refly>I might try just using sddm and never find out why gdm isn't working <lilyp>note that you should use at least one generation that gives you tty access <f1refly>I don't see anything in /var/logs/debug regarding gdm <f1refly>(EE) Cannot open log file "/var/lib/gdm/.local/share/xorg/Xorg.pid-599.log" <unmatched-paren>Guest99: sorry nobody acknowledged your message, usually that just means nobody knows the answer, you're not being ignored :) <f1refly>I might just delete gdms data dir and see what happens out of curiosity <lilyp>yeah, stale files in gdm are ouch <morganw>I'm 95% sure I broken by GDM in the same way, by removing it and then putting it back. There was a ticket open for it because the issue was down to how the ID used on the permissions wasn't updated but the ID had changed when it re-installed. <f1refly>They wherent recognized user/group anyways <apteryx>uh, our vala package uses bootstrap binaries <f1refly>gdm won't display sway with wayland, looks like I have to use sddm. <morganw>You need to enable Wayland support in the GDM config, but it worked fine for me. <jackhill>muradm: is it bundled? I'm not seeing them in the inputs <f1refly>maybe i got confused and booted a system without <f1refly>no wait, what field do I have to set? <unmatched-paren>the recommended and only officially blessed way to launch sway is via TTY, though apparently "gdm is known to work fairly well" <f1refly>Is it in the config? It doesn't say anything about a wayland option in the manual <f1refly>how do I set my layout for wayland? Do I just put it in the xorg-configuration and it'll work? <f1refly>This is my first dabbling with wayland :) <unmatched-paren>it's just a compositor <-> windows protocol, no 'wayland-server' or anything *f1refly proceeds to shamelessly steal that config to build upon <unmatched-paren>f1refly: i haven't yet pushed the commit that adds license notices, so consider it GPL-3.0-or-latur <apteryx>was having a 'cc' symlink pointing to 'gcc' ever discussed and rejected in guix-devel? <f1refly>that's fine, I'll add it to the header of my config so I don't forget :) <unmatched-paren>apteryx: how about adding CC=(cc-for-target) to the default make-flags <nckx>My replacement laptop arrived from Señor eBay, along with a hand-written cover letter, which I will reproduce here in part: ‘I believe you will love this little beast. As agreed, I installed nothing; Guix is for tough boys and they like to do things on their own.’ <apteryx>unmatched-paren: It's not for configuring at build time, rather, the tool is a compiler (vala) that looks for 'cc' in PATH <nckx>Not epic value/$ at this point but I need my weird retro tablet form factor. <muradm>in two weeks i will battle with system76 ) <nckx>That doesn't sound… good? <nckx>This new )-for-:) trend is new and scary to me. <muradm>yeah, the day was packing for travel, realized that battery is expanded, and body is deformed <nckx>But whence from there??? Then all that remains is ‘’. <muradm>had to switch urgently to carbon x1 on the road.. thanks guix :) <nckx>There could be a 0-length smiley lurking ANYWHERE at that point. <nckx>muradm: as in swap drives, or re-init? <nckx>unmatched-paren: I feel like your nick is mocking me. <unmatched-paren>"" might become #f, NULL, or equivalent, depends on the language the IRC client is written in :P <muradm>and i don't have to fix this guix lint. right? fail2ban@0.11.2: scheduled Software Heritage archival <nckx>It's a false positive for lack of a better term, although semantically it's an upstream bug. <nckx>muradm: Also no. That is informative, although it could be more clear. <muradm>nckx: i still don't understand what it says :D <nckx>It's a public (free) software archival service, and ‘guix lint’ sends it a ‘please archive this git URL’ API request. <muradm>redirect is clear, although don't see reason, just to validate if url is ok should be enough (i.e. 2xx/3xx) <nckx>If the upstream git URL would vanish at some point, Guix will check SWH servers for the source hash. This helps make time-machine more robust. <muradm>nckx: does it every time i do guix lint? <nckx>It checks every time, but it sends that request only if it's missing. <nckx>Requests take a while to process, so you might see it a few times whilst developing the same package, but eventually it should disappear. <muradm>any way, and there is last one: fail2ban@0.11.2: label 'bind' does not match package name 'bind:utils' <nckx>muradm: Permanent HTTP redirects are *supposed* to signal ‘hey, we moved, update your bookmarks’ to clients. Using it like fail2ban does is just wrong. Whether Guix should be more lenient about bad practices in the real world is of course a different matter. <muradm>i suppose it does not like this part of inputs "`(,isc-bind "utils")" <nckx>muradm: Can you not use the new (label-free) input style for some reason? <nckx>The opposite. Never mind. <nckx>Then that can also be ignored, although that lint rule guarantees false positives and should be rewritten if possible. <nckx>Your code is correct. Indeed the matching should be a bit more clever when it sees PACKAGE for PACKAGE:OUTPUT as long as that's what the new style produces by default. <nckx>It's not ideal that one part of Guix produces something another part warns about that you can do nothing about :) <unmatched-paren>nckx: why did you write :)?! NULL is the latest treSegmentation faultnd <unmatched-paren>Actually, :-) -> :) -> ) -> NULL seems like the storyline of some kind of fable. <nckx>unmatched-paren: Time to write an esolang with smiley-terminated strings. <nckx>No, smiley-terminated everything. <nckx>efraim, apteryx: As I read the code, I needn't update the Guix keyring when I extend my otherwise unchanged key's validity. Could someone confirm? <unmatched-paren>just fork gcc and make the lexer recognise (: as an open paren and :) as a close paren <unmatched-paren>proposal for the Deity Consortium™: terminate lives with smileys instead of NULL <unmatched-paren>*The Deity Consortium™ is a wholly owned subsidiary of The Open Group®. <unmatched-paren>We know that mysterious deities aren't exactly open, but it's not like "The Open Group" is normally a fitting name anyway. <muradm>guix and/or guile scheme has validation/type for time presentation? like 1h (1 hour), 10m (1 minutes) etc. <nckx>The Deity Consortium™ sounds dystopic as hell. <nckx>muradm: Certainly not in Guix. I'm not aware of any such module in Guile. <nckx>I have a trivial set of (minutes->seconds 5) -style helpers to make my system configuration a bit more self-documenting. <nckx>Nothing magic, just does * 60 :) <nckx>But it's better than having to comment each field so I remember the unit in 2y's time. <unmatched-paren>nckx: it's an organization where normally competitive religions can come together to develop standards for belief systems, why else would Judaism, Islam, and Christianity have so much in common :P <nckx>But which text editor do they use. <nckx>(Presumably one with good RTL support.) <nckx>Translated into 25 languages, so we can fight over which one is true. <unmatched-paren>Its users generally don't like Arabic, they say it's too prone to memory bugs. <nckx>Honestly, as long as they don't propose their own package manager, I'm OK with all of that. <lilyp>Our package manager lucifer™ solves all supply chain issues using a novel resolution method: a file with a bunch of md5 hashes. <unmatched-paren>lilyp: are you implying something about language package managers with that 'lucifer™' name? :D <lilyp>This package manager is fictional. Any similarities to actual technologies are purely coincidental. <unmatched-paren>To be fair, if it's using md5 hashes for security it probably is demonic. <apteryx>nckx: I think so, you simply need to update it in your Savannah account <nckx>Thanks for the confirmation, apteryx. One wouldn't want to break guix pull. <KarlJoad>I am trying to get man pages for libc into a guix-shell environment and am failing. Does anyone have any pointers? <nckx>Do you have them elsewhere? <emturner>Hi, sorry if it's already been talked about! Just noticed that `guix pull` is now failing as of 44bb5507d63b89c9d5f0c2c77af94caeec96e5e6 - which added `chicken-args`, which depends on `chicken-srfi-37`, which is in a patch from https://issues.guix.gnu.org/56295#8-lineno4, but isn't in the guix master branch? <nckx>KarlJoad: I'm afraid I can't parse the ‘should’. <nckx>What I meant was: do you have glibc manpages outside of a pure environment? <KarlJoad>Oh. I have man, and some of the man pages, but none for libc functions. <KarlJoad>That goes for both when I am outside and inside the pure shell environment <nckx>KarlJoad: Does glibc ship man pages? I'd be a bit surprised. <KarlJoad>I know there should be man-pages for libc, i.e. `man strlen` usually works on other systems. The glibc package does not have an info/man output though. <nckx>But strlen isn't from (g)libc. <nckx>It's from the unaffiliated man-pages package. <nckx>If you want that, try guix shell --pure man-{db,pages}. <nckx>I really think glibc only provides a manual, not ‘man pages’. <KarlJoad>Ahhh... That'd do it. I did not find that info in the manual when looking. I'm just trying to isolate packages, but it may make more sense to leave man-db and man-pages in a more global profile. <nckx>rekado: Yay, more wrapper languages. <rekado>it’s sad that bash doesn’t allow me to do ‘exec’ with an offset into a file. We could build so many disgusting polyglot script-binaries <singpolyma>rekado: cosmopolitan not disgusting enough yet? ;) <nckx>I am… very happy and grateful that it doesn't. <rekado>put that memfd_create stuff in a bash extension and use it in a shell wrapper 