<guixy>I have stuff running so I'm not particularly willing to check... <leoprikler>you don't have to; I'll consider writing a bug report if it happens again <guixy>I am not familiar with how Debian's package manager works, but it looks like they configure w3m with "----enable-image=x11,fb+s" <guixy>I don't see that in the guix w3m <ryanprior>Debian defines packages using directories that have build scripts and config files. Those ought to be a rich source of ideas for how we might build our packages. <apteryx>there may already be a bug report for it, not sure <apteryx>raghavgururajan: well done for the mediastreamer2 test suite! <apteryx>do you remember what the (("O_BINARY") "L_INCR")))) substitution is for? <raghavgururajan>apteryx: There was a name-space mistatch while enabling portaudio ot pcap. <raghavgururajan>Regarding tester-->test, the latter represents both test-executable and test-data for the output. :) <raghavgururajan>Also will be consistent with other generic output names: doc debug test ... <apteryx>I like to think of the output name matching what it *is*; it's doc, it's debug (symbols), it's a tester <apteryx>if we had many packages installing test material of many kinds I would agree though. But this tester thing is very Belladone specific <apteryx>I think the quote in the manual are not single quotes <apteryx>I'm not sure, but copy pasting things have caused issues before, because the printed character differed to what I expected it was <apteryx>but in this case it seems to be fine <apteryx>the name is a symbol; what failed? do you still have the error and the original version? <apteryx>raghavgururajan: when we're done we'll have to update to 4.4.35 ;-) <apteryx>it's probably a painless bump, I'll try it before it's tested ready to merge <cdegroot_>The quote in the manual seems to be an actual quote. I couldn't get it to work - got scheme stack traces when I depended on nonguix as "(name 'nonguix)", tried various things, then "(name nonguix)" worked. Doesn't make sense. <cdegroot_>(I didn't copy from the manual but from my channels.scm) <jackhill>there may have been some problem building the devel version of the web manual, but I wasn't paying as much attention then :) <jackhill>for why it's different in the channel dependencies v. channels.scm the former is data and the later is executable scheme code as I understand it. <apteryx>jackhill: perhaps because of the guile-lib update that I made. *apteryx checks guix-devel <apteryx>doesn't seem to be anything about that <apteryx>raghavgururajan: was there a reason you added python to belle-sip? I seem to get away without. <apteryx>also, it builds fine without antlr and java; can we drop those? <brendyyn>pkill9: the removal of qt-4 broke your packages-free channel D: <brendyyn>I was wondering how do I specify a local git repo in as a channel url? ***sneek_ is now known as sneek
<rekado_>raghavgururajan: I don’t browse Gitlab. <rekado_>raghavgururajan: but I hear that switch the user agent string might be enough. <tissevert>wow the flow of mail on guix-devel and guix-patch is impressive Oo <brendyyn>tissevert: more more more! we should thank all reviewers <tissevert>but I'm amazed how interesting all of the mail is : unpiling what got in since I signed up yesterday evening and I've already learnt at least 3 helpful things if I'm to ever submit any package <tissevert>so yeah, thank you @reviewers for all the amazing work <nixo_>zimon: I'll have a look at your julia patches again soon, I got stuck building julia 1.6, which build fine and work fine but there are a few failing tests .-. and running the test suite requires something like 6 hours <nefix>Good morning! Is there a reason why Guix's Go package is at version 1.14 and not at 1.16? Is it just that no one has updated it yet? If so, how should I try to update it? Thanks! <nefix>Also, I have a local package that I'd like to contribute to the main repos, how should I do it? Thank you :) <brendyyn>nefix: i suspect it's just work to be done. 300 packages depend on go so it would involve testing all of them. <brendyyn>nefix: to contribute to guix you need to install it and then clone the guix repo to build locally and edit. have you done that? <brendyyn>nefix: do you need to make use of go 1.16, or do you want everything in guix to be using 1.16? <nefix>brendyyn: I need to make use of Go 1.16. It introduces a important package to stdlib and lots of libraries are starting using it <nefix>brendyyn: no, I haven't edited the repo, I didn't know where to start. I have my own little repo with some configs and packages, but the whole Guix repo it's a bit scary xD <nefix>Thanks for the link, I'll check it out <brendyyn>nef you could also do it in your own repo i guess <brendyyn>nefix: in gnu/packages/golang.scm there is the line define-public go-1.14. That's what you want to use as a basis for defining go-1.16. Most likely it will require changes to work <nefix>brendyyn: I could inherit it in a local package, couldn't I? <nefix>And then make the required changes <nefix>I'll see the changes in nixpkgs, it's really useful to see how they do things and then adapt it to Guix xD <nefix>And if it works out, I'll try to contribute it <brendyyn>i suspect things will break, so i'd then just copy paste the entire go-1.14 definition and start editing it <lle-bout>civodul: watching your talk related to guix-explorer *lle-bout needs to watch all other talks about GNU Guix in FOSDEM 2021 <cbaines>lle-bout, I think there was a backlog of package sources to build, but I think core-updates stuff is now at the top of the queue <lle-bout>ungoogled-chromium's Picture-in-Picture mode is really nice in that I can pin a video to a corner of my screen and it moves in all my XFCE workspaces when I switch so it's just always there, so nice! <lle-bout>valerii_leontiev: creating packages for nodejs is a time-consuming process and no one has done so yet, so it's possible but no one could put the energy for now. <lle-bout>valerii_leontiev: please try contributing if you need that! <lle-bout>testing work and feedback is also useful <lle-bout>civodul: I strongly welcome addition of guix-explorer to GNU Guix itself, I find it very very useful to understand what's going on! <nckx>Morning, people of Guix. <nckx>Oh, is that still supposed to work? <nckx>lle-bout: How did you run it, and how long did it take to start? <nckx>I vaguely remember #f featuring prominently in my stacktrace. <nckx>It also takes minutes to start. <nckx>Both are fine, I don't expect OOTB magic from cool quick hacks. <nckx>(It's still compiling things(?), so 5 mins so far.) <nefix>So, compiling Go 1.16 is throwing the following error: 'ld: cannot find crt1.o: No such file or directory'. It's failing a test that says 'Test that we can use the external linker with a host syso file that is embedded in a package, that is referenced by a Go assembly function.'. Does anybody have a clue? <nefix>It seems to compile 1.15.10 correctly though :think: <i1l>lle-bout: hi Guix. i remember Nix mirrors things from some repos, like ELPA or so (acc. to the manual). I mean, may Guix mirror the nodejs, in place of repro-builds, in a meantime? To make Node a tging in Fuix i mean. <i1l>heh, a virtual keyboard. <nckx>i1l: What's wrong with the current hosting? <i1l>nckx: i heard nodejs is not a thing in Guix yet. thought maybe "snapshotting" node can make it reasonably pseudoreproductive. <nckx>Yeah, it's a nightmare to build npm packages from source, since they're not intended to be. <nckx>Well, yes, that aside :) <pkill9>npm was created by some spiteful greek god <pkill9>maybe it's prometheus' revenge for humans getting the power of fire <i1l>pkill9: as someone said "evil is killer, for example. it is wrong word to describe a tech". <nefix>So, the only relevant changes that they've made is the test skip conditions: '[!exec:cc] skip' -> '[!cgo] skip' <nckx>Well, fire is one solution to npm. <i1l>buttfire grenadiers of regiment going to crusade the Node. (Breaking) <i1l>i think it is a thin red line thing. i am deserting from the regimen... <nckx>i1l: Nix mirrors things like ELPA because they like to change what a given URL returns over time (unversioned tarballs). That's not the issue with npm, so not a solution. <nckx>I mean, I wish it were that simple. <nefix>Soooo I think is that is beacause it's missing the '-r <gcc-lib>/lib' ldflag in the test... <nefix>How could I edit a file from the source using an inherit package? <nefix>I'm seeing a lot of (substitute*) functions, but I'm afraid of replacing the whole phase and not just "appending" to the already existing substitutions <nckx>nefix: Add a new phase before or after it if you don't yet want to touch the package you're inheriting from (which sounds sane). <nefix>nckx: thanks! Makes a lot of sense! <pkill9>i've been running the appimage currently <pkill9>it says right the in the package definition <lle-bout>nckx: I don't think npm packages werent made to be built from source, more so that semver compliance isnt the most strict there, that there's lots of micro-dependencies meaning multiplication of packages, also package-writing practices and maintenance quality of them are some times rather poor because lack of clear guidelines and good tools in the community. <lle-bout>It's a result of the individualist packaging philosophy <lle-bout>Without community and collective maintenance of packages <lle-bout>pkill9: the package definitions I posted in the issue just works so if you want to use it feel free <lle-bout>civodul: I have my channels defined in /etc/guix/channels.scm - but investigating <nckx>lle-bout: <I don't think npm packages werent made to be built from source> Then think again, or try to bootstrap any and despair. <rhou[m]>Do I have to run `pre-inst-env` inside the guix environment? <nckx>rhou[m]: It's recommended. <rhou[m]><nckx "rhou: It's recommended."> I always get `guix build: error: failed to connect to '/usr/local/var/guix/daemon-socket/socket': Connection refused` <nckx>I'm not much help debugging non-Guix Systems. <nckx>Did you omit --localstatedir=/var deliberately when building Guix? <nckx>It might be harmless, but only if all of your Guix installation follows suit. <davidl>I have a package from centos that I can install with guix with some hassle of first manually downloading the package and unpacking and repacking it and moving patches in place. I need some help to replace the unpack step of the gnu-build-system. How do you do that correctly? I did with a modify-phases thing and a lambda, but when running guix build -f mypackage.scm Im still getting an error from tar <davidl>xvf that it's not a tar archive. <nckx>davidl: Paste your package to Debian's bin. <rhou[m]><nckx "Did you omit --localstatedir=/va"> I just ran `./configure` and `make` did I need to set `--localstatedir=/var`? <davidl>nckx: the system command there should be removed, but the main point is that the unpack phase do not seem to actually be replaced. <i1l>davidl: try add (display "hello-Replaced unpack") to the new 'unpack to know for sure. <brendyyn>anyone know how to make nix installed applications use fonts installed via guix? (on guixsd) <nckx>rhou[m]: Guix should work it without it, but I don't know if it's well-tested. Does that socket file exist? <lle-bout>nckx: I already built npm packages and bootstrapped from source, I think there's bigger problems in other areas of software. The problem is not that they were designed to not build from source (as if it were intentional), but that there has not been an active community of people checking this property and actually bringing the issues to the upstreams. <lle-bout>What I disagree with is that they would somehow be designed to not build from source, which to me isnt true <nckx>I never said they were designed to not build from source, lle-bout. <nckx>davidl: OK, I see what's going on. <lle-bout>nckx: you said they werent intended to be, they are, otherwise the source wouldnt even be released, it's just often they are only half-way into that process because it's extra effort some developers can't afford vs making the thing work for users. <nckx>I had to comment out all your patches in order to build the package, because I don't have them. So I'm getting the error from the unpack phase, but you're getting it from patch-and-repack, since you're asking Guix to apply your patches to an .rpm file and it doesn't know how to (it tries to treat it like a tarball). <nckx>I wonder what the least ugly way forward is... :) <davidl>yeah, I couldn't find a good version of that package anywhere else. The patches come with the rpm so perhaps modify phases to just apply those, instead of storing them separately in Guix. <davidl>I managed to set it up with email-passwords and TLSv1.2 on Guix, so I thought it would be nice to add this version of the package to Guix master. <nckx>Something like that, but then you'll have to deal with the ugliness of getting them to the ‘build side’ yourself. It's not that hard, but it's something that (patches ...) magically does for you otherwise. <nckx>davidl: If it's all buildable from source, go ahead! <nckx>(Last day all shops are open, here...) <davidl>nckx: I will struggle doing it that way. The easiest way would be to upload a tarball git my own git repo and add the patches separately to Guix. <cdegroot_>Is there some secret magic around channels I am missing? I've setup a channel, added a dependency I need, added a package, popped my pgp key on the correct branch, etcetera. Adding it to channels.scm gets it pulled but then trying to build the derivation I get an error, the log just says "(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (channel)) (value #f))". I've verified my setup a bunch of times (https://paste.debian.net/ <cdegroot_>1191211/) but can't find anything obviously wrong. The single recipe in the channel works if I feed it to "guix build"... <soouul>i am back once more with more stupidity <soouul>whats the proper way to set up global environment variables? <lle-bout>soouul: hello! I don't see stupidity! Actually it's not clear to me how we can do this, that is, add global environment variables. Depending on where you want them to apply, you could export them in your .bash_profile or else, as this source is sourced at login. <soouul>and usually i would just add it to /etc/environment <lle-bout>soouul: so it's about your own usage after login? not for the whole system? <soouul>sure, i dont think i actually care if its system wide <lle-bout>If so, use $HOME/.bash_profile (or else depending on your shell) <soouul>i dont share my pc with anyone >:( <lle-bout>.profile may also work but for me with bash it does not <nckx>soouul: Use (simple-service 'my-global-env session-environment-service-type '(("HERP" . "blerp") ...)) <soouul>does that have to go inside another expression or alone? <nckx>In your (services ...) field. <soouul>you know, i was already making a ~/.profile file lmao <nckx>That's fine, but it's not global. <soouul>not used to this whole declarative thing, and also making a package seems easier than working around make install <nckx>lle-bout: It's normal you didn't know about it, it's not documented... :-/ <nckx>Not a hint, but feel free to take it that way 😉 <soouul>on the "..." you put, i can add more variables right? :O <lle-bout>nckx: I don't feel at ease with texinfo or knowledgeable enough about GNU Guix to write good GNU Guix docs <lle-bout>nckx: I would rather write notes in a collaborative draft anyone can search and edit without version control or approval process <lle-bout>This way, there's no way I can be wrong because no one expects it to be, and information is still readily available, in a less formal way, but still available <lle-bout>Things could be selectively picked in the official manual but that would make a good staging area <lle-bout>Maintaining commit history is tedious and often I am not ready to put that effort and I'd rather be able to do things without doing it else I wouldnt do them at all (happens a lot now) <nckx>You can use the w-word here. You won't be banned for saying wiki. Nor for creating your own if you like. <lle-bout>I would really like if we had a wiki.guix.gnu.org! <lle-bout>Libreplanet looks good but I don't feel like we can have the freedom we want there <lle-bout>Also the wiki would have to be publicized on the main GNU Guix page and being under wiki.guix.gnu.org makes more sense I think <lle-bout>Also there's the question of whether we make it an official resource or unofficial resource so that people can also talk about nonfree things when they remain needed <nckx>I don't think there's interest in an official wiki. Too much work; wikis attract nonsense (see: any distro wiki), and keeping them sane takes a lot of work *on top* of writing submissions, and until then the submissions just sit there under guix.gnu.org being wrong. <lle-bout>Many GNU Guix package definitions are wrong <lle-bout>Then we wont have a wiki and information will not flow through users, *shrugs* <nckx>lle-bout: Have you tried Guix's ikiwiki package at all, perchance? <nckx>It's... very old, especially for a Web Thing. <nckx>Although it's static so meh. <soouul>sorry to intrude again but this is not working :( <soouul>no like, it doesnt let me reconfigure <soouul>and shows the whole service expression <lle-bout>soouul: append it after openssh-service-type, not above <soouul>well imma reboot and report on how it went <rekado_>there’s really nothing wrong with using the Libreplanet wiki for WIP progress snapshots. It won’t ever be official documentation and if anyone asked me I’d vote against ever elevating a wiki to ‘official’ status. <rekado_>it really doesn’t need to have a home on the guix.gnu.org domain, which is where we take responsibility for content <lle-bout>rekado_: I have a feeling that if things are not official people don't use them though. <ennoausberlin>Hello. I try to create a package definition for python-asttokens but it fails with python-six unbound variable. What might be wrong? <lle-bout>ennoausberlin: did you bring (gnu packages python-xyz) into scope? <lle-bout>ennoausberlin: also share your package definition <lle-bout>rekado_: I think the secret to good community resource is that knowledge about it must be very widespread (link on official GNU Guix website) and that there must be next to zero gate-keeping before edits are live. <nckx>lle-bout: Well, yes, but that's because of what ‘official’ connotes to them: reliable, approved, curated. The former without the latter is (IMO!) meaningless bait-and-switch. <guixy>From gparted, navigate to broken device. device-> Attempt Data Rescue... "This feature uses gpart. Please install gpart and try again." <guixy>Is gpart included in any package? <lle-bout>nckx: I think it's more because it's not as widely know if it's not official, minority of people know about the resource. <nckx>guixy: I don't think so... <nefix>I've successfully compiled Go 1.16 :D <nckx>guixy: Not packaged yet. <lle-bout>guixy: there's also ddrescue package if that's interesting to you <nefix>For the contribution, should I change the default to 1.16 or leave it at 1.14? ***jonsger1 is now known as jonsger
<ennoausberlin>le-bout: Now I get one line further and it fails for unbound variable python-pytest <lle-bout>nefix: two steps separate, first submit, then discuss to change default, also changing default means lots of rebuilds so.. I already upgraded go on master for security reeasons with lots of rebuilds and it went fine though, as long as it doesnt break stuff I think it's OK to change the default <brendyyn>nefix: to start with you should leave it. to change the default you need to test all the packages that it might break <lle-bout>ennoausberlin: you can use 'guix search python-pytest' and look at the location field to figure out what module to bring into scope <ennoausberlin>le-bout: Great advice! It now fails while building but at least the scheme package definition is fine. <guixy>I just ran ddrescue. It didn't tell me anything about the targeted device other than that it seems healthy... <guixy>I'm looking for what information it has. strings has revealed it has many long strings (over 100 characters long) that look like source code, (some guile scheme and some C) but I can't conclude anything about the structure... <rekado_>I use testdisk for recovering deleted files. <cdegroot_>TIL that a channe repo gets scanned recursively for scheme source code and "non-channel" .scm in there result in seriously dense build errors. <cmack>good morning, I'm trying to boot the guix image from usb on an older non-EFI machine but without success. Is the image built with legacy bios support or do I need to build my own image for this? <lle-bout>cmack: it is built with legacy bios support <cdegroot_>leoprikler: I've been digging for hours before I realized that the errors pertained to some other scheme files. Moved the channel stuff into a subdir, safer :) <cmack>although fdisk is showing "Empty" for Type <bone-baboon>I am working on overcoming two hurdles that are in my way of using Guix. Which after considering several other\ <bone-baboon> options is the operating system I want to use. Runners up were Gentoo, OpenBSD and Devuan. However Guix has \ <bone-baboon>The first hurdle is getting X server to work. I have asked for help on the mailing list about starting X with \ <bone-baboon>The second hurdle is installing a previous version of a package. <bone-baboon>Help with either of these would be appreciated. Thank you <i1l>bone-baboon: sway wm? closest to xinit. just `sway` from TTY. needs elogind (if not suid). <i1l>bone-baboon: 2-nd is called inferiors in the manual. <lle-bout`>bone-baboon: older versions of packages can be installed with the 'guix time-machine' command, e.g. guix time-machine --commit=<hash> -- install <pkg> <nefix>so, in theory, the patch is sent. I'm not sure if I've followed the right steps or if I configured git-send-email correctly... <bone-baboon>sneek later tell i1l I will try Sway and Wayland. I read the Inferiors section of the manual and tried modifying the example given but I get an error that I posted to the mailing list. <lle-bout`>bone-baboon: time-machine does not work for all previous revisions of GNU Guix, it's still a recent feature I think too far back it doesnt work <bone-baboon>lle-bout`: Thanks. I was running into an error when I tried to use Inferiors see the mailing list link I posted above. I will try time-machine. <lle-bout`>bone-baboon: my advice is that you attempt other revisions that still contain a version of the package you want <bone-baboon>So in this case commit hash: c5a2b70135c9830e9c3051ddf4a096f9a80eb952 <lle-bout`>bone-baboon: until right before the update to 2.4.10 openvpn is still available at version 2.4.9 <lle-bout`>raghavgururajan: hey so what's next for GNOME you think? <lle-bout`>civodul: so many things come to meaning with guix-explorer, can't thank you enough, still can't use it on my config but using examples <lle-bout`>civodul: I realize the shepherd service things are actually really simple <Rovanion>I'm working on the sendmail package and think I managed to do something right. Two questions though: 1. what is a helpfile and 2. where should sendmail stats go? <civodul>lle-bout`: aaah! assuming you're not saying this just to please me ;-), that makes me happy! <lle-bout`>civodul: I really do not, I've been exploring things since around an hour now <lle-bout`>civodul: the graph is too big some times it doesnt fit on the screen but there's workarounds <lle-bout`>civodul: you should make a blog post about it! <lle-bout`>civodul: or when it's within GNU Guix proper <civodul>i'm sure with some more d3.js hacking we could improve graph rendering, when there are many nodes <Whyvn>I am wanting to make a package that I need some clarifcation on to clear some confusion. The steps are: git clone, cd into cloned dir, mkdir build, cd build, cmake .. -DBUILD_STATIC_DEPS=ON -DBUILD_SHARED_LIBS=OFF -DSTATIC_LINK=ON, make -j$(nproc). Now i know there is a mkdir-p and also a chdir function, but i am confuesed by the cmake .., would I override the install phase and chdir back to root and then run cmake with the <Whyvn>confgiure-flags and then chdir back into the build dir and run make with the configure-flags -j$(nproc)? <lle-bout`>civodul: maybe also pretty rendering of generated executable Scheme files <lle-bout`>civodul: also in your talk, parameters, very elegant solution I like it a lot <civodul>yeah it can be pretty nice but has to be used with care, due to combinatory explosion <civodul>cbaines: ah yes, i did see that message and i think my immediate reaction was to look away :-) <lle-bout`>Whyvn: I can't take arbitrary package requests and commit to doing them because there's lots to do in GNU Guix and I want to feel free to set my own priorities but this looks like an easy one to package <cbaines>Before separating out the connection caching from the substitute related code in Guix, I was putting some of the errors in the Guix Build Coordinator down to shared cached connections, but now that's not an issue, it's clear that something's up with concurrent HTTPS connections in Guile <cbaines>yeah, I'm really hoping this isn't an issue in GnuTLS, especially as there's a statement that things should be fine with threads (although under particular conditions) <Whyvn>lle-bout`: I had more of a question on the step sequence. with the moving back and forth through the directories. would i just override the install phase or is there other phases i need to condsider? <civodul>d'oh, "guix weather" tells me we're at 95.2% for x86_64! <civodul>i think it's never been this good, even for x86_64 <lle-bout`>Whyvn: sorry didnt link with my previous question <lle-bout`>Whyvn: what is the problem you're encoutering? can you send your current package definition? <lle-bout`>Rovanion: one thing, the commit message is not compliant, but I am about to suggest you a correct version on the bug <civodul>80% of substitutes on aarch64-linux, woow <civodul>cbaines: i can reproduce the crash with 10 threads <civodul>cbaines: with two it seems to be okay <civodul>i tried "rr record -n guile /tmp/threaded-https-connections-test.scm", but unfortunately rr crashes :-/ <cbaines>civodul, there's a (iota 512) bit, and if you're not seeing it crash, I'd increase that number. <lle-bout`>Rovanion: so you actually added more unrelated m4 defines and it worked..? o_O <lle-bout`>Rovanion: smrsh is still missing somehow but great work! continue! <bone-baboon>lle-bout`: thank you for pointing out `xorg-server-service-type`. I will give it a try it. <Rovanion>lle-bout`: The error messages in the bulid log was about `mkdir -p /etc/mail` failing so I went through the build scripts trying to find where it could possibly be doing that. And it seems to have worked. <lle-bout`>Rovanion: I see! They were silently ignored it seems, I couldnt find them myself. <lle-bout`>Rovanion: I also made a complete answer to your bug <soouul>anybody here use wayland? im trying to compile a program and i do have the dependencies but pkg-config cant find them :c <lle-bout`>soouul: did you use the guix environment command? <lle-bout`>wayland-client is included in the wayland package <soouul>yeah i have it but it cant find it <soouul>perhaps cuz its installed globally? <lle-bout`>soouul: you can do: guix environment --ad-hoc wayland pkg-config <lle-bout`>it spawns a temporary shell environment with those packages available <lle-bout`>You can also have a oneliner like: guix environment --ad-hoc wayland pkg-config meson -- meson <whatever> <lle-bout`>Whyvn: I don't think using (loki-network) at the end works, use loki-network alone without parenthesis instead <soouul>yeah i think i gotta install wayland-client for myself <Whyvn>lle-bout`: hrm, i used guix hash -rx is that wrong? <lle-bout`>Whyvn: cmake stuff looks OK! make is run automatically in a default 'build phase so do not worry about that, just run it now and figure errors out <Whyvn>lle-bout`: how can I add the -j$(nproc) to the make command? thanks for looking at it <lle-bout`>soouul: In GNU Guix, not all packages are available in the global environments, e.g. sway can require wayland while not poluting the global system profile environment with it <lle-bout`>environment allows you to explicitly specify the packages you want available in the spawned shell environment, by the way to quit just use CTRL-D <soouul>so basically i can get away with compiling in an environment and not actually having those dependencies on my system? <lle-bout`>Whyvn: it's automatically added, controlled by #:parallel-build? field <lle-bout`>soouul: yes, but beware if you use 'guix gc' the built binaries might break, that's why it's preferable to create a package definition or have a profile somewhere (which can also be used with environment) so that it's protected from garbage collection by being registered as a gc root <lle-bout`>soouul: basically the built binaries will have absolute paths to /gnu/store/... in them, if you use 'guix gc' these paths might be deleted, so that's why the binaries could break <lle-bout`>registering as gc root means the store items wont be deleted when using 'guix gc' <soouul>wack, so basically i should just make a package myself? <lle-bout`>The ways to register as gc root, is by including them in a profile <lle-bout`>soouul: yes, you can write one with Scheme code or JSON even if you are at better ease with that, note however that JSON is less powerful and some things you will not be able to do with it. <soouul>its a wayland utility so at that point, if i do end up packaging it, i might as well commit it? lmfao <lle-bout`>soouul: if you have any question, ask I will answer <soouul>and then ran it again because you know <soouul>and it works! but still imma package it, this feels janky as hell <lle-bout`>soouul: it might be because other packages in your various user or system profiles register the dependencies of wlsunset in a gc-root <soouul>i mean, i am using wayland after all and that package has like no dependencies <lle-bout`>soouul: note you can embed package definitions in your system configuration <lle-bout`>it's just code and the packages field takes a list of package objects, so you can just define one above and use it down there <lle-bout`>but I do encourage you submit it to GNU Guix also <lle-bout`>in the mean time (pending review) you can use the package definition this way in your system configuration <soouul>in define modules i should leave it as "gnu packages xxx" <lle-bout`>first, if you are preparing to contribute to GNU Guix, do you have a git clone of GNU Guix built? <soouul>the first line in the packages example is `(define-module (gnu packages hello))` <soouul>no, i wanna figure out how it works first <soouul>i see now that, i dont need the define-module thingy <soouul>since im gonna commit it to an existing package anyways <lle-bout`>soouul: you will be adding wl-sunset to an existing module probably yes <lle-bout`>but you otherwise do not need modules if you are making an out of tree package <lle-bout`>soouul: the out-of-tree package just has to contain the (package ..) object, nothing more <lle-bout`>to bring modules into scope, use (use-modules (gnu packages ...) (guix download) ...) for example <lle-bout`>soouul: for environment actually it's -l instead not -f <lle-bout`>Whyvn: since you use a git-reference in your package definition, guix hash doesnt work, also you should use guix download rather, but for git there's no subcommand, so what I do is I run the build then copy the actual hash from the error and feed it in. <lle-bout`>I am not sure of the technicalities of how git-reference is hashed and it seems there's no subcommand to reproduce that behavior. <soouul>how do i get the sha256 of the package? <nckx>lle-bout`: guix hash -rx <lle-bout`>soouul: what I do is I get it from the error when it happens, it prints the hash it got <nckx>lle-bout`: <guix hash doesnt work> When? <lle-bout`>nckx: is that for git-reference? I remember trying and it didnt produce what was expected <nckx>Well, I don't know what you were expecting, so can't say. It prints the value expected in the origin's hash field. <lle-bout`>nckx: yes that is what I am talking about, I'll try again but it didnt work when I tried to do that, thanks. Also what about tarballs? Can I generate the hash without using "guix download" with guix hash? <lle-bout`>nckx: It never produced the outputs expected in the origin fields for me, but I'll try again. <nckx><guix hash doesnt work, also you should use guix download rather> They are the same, so something is wrong. <nckx>Basically your whole response to Whyvn sounds like something went wrong in a confusing way for you once, and we should find out what. <lle-bout`>nckx: not only once but yep, that was when I was still a complete stranger to the project and I asked here several times and got no answers so I resorted even until now to workarounds <nckx>That's still quite a leap to ‘guix hash doesn't work on git checkouts’. It's documented to, and the manual explains how to invoke it. <lle-bout`>I can't recommend what I didnt use and havent seen working, so that's what I felt was the most appropriate to answer for me <nckx>Well, if you didn't use it... <nckx>I don't know what to say. <lle-bout`>nckx: I did use it but it wasnt producing the expected outputs <nckx>lle-bout`: On which input? <nckx>I would like to debug this. <nckx>I'm currently trying random hashes + git checkouts already in Guix, which isn't a very efficient way to do so :) <nckx>Is it possible you had generated files in the checkout? <lle-bout`>nckx: I didnt have any generated file in the checkout, however now that I am thinking it may be the .git <soouul>wait if i put im using the meson build system, i dont have to put meson's module right? <nckx>The purpose of ‘-x’ is to filter out .git (it's a hard-coded list IIRC, not ideal but good enough). <lle-bout`>soouul: you have to bring (guix build-system meson) <nckx>lle-bout`: It would still have been mentioned in the --help output. Anyway. It must have been a memorably frustrating experience not to receive answers here that you thought guix hash was broken for 3 years. Genuinely sorry about that. <nckx>I hope we're doing better now. <lle-bout`>nckx: this will be helpful, because I otherwise felt quite uneasy not being able to check the signature of tarballs or git tags if they exist before putting a hash in a guix package definition, even if it's still useful in TOFU mode <soouul>how do i make it so the build system takes no arguments? #f is not working <nckx>soouul: Hmm? I haven't been following your thread but few fields are mandatory. <nckx>Thought maybe you were inheriting something. <lle-bout`>soouul: as general advice, reading other package definitions in GNU Guix is great help resource <soouul>was looking at dunst package for this one <lle-bout`>nckx: it wasnt clear at the time that GNU Guix wasnt including the .git in the checkout, how all that worked was still confusing and unclear <nckx>lle-bout`: Right. Both; it tries to shallow clone but that still creates a .git, so Guix has (delete-file-recursively ".git"). <soouul>weird, i did the hash thing you told me but it keeps saying im using the wrong one <nckx>soouul: Could you give more details? <lle-bout`>soouul: so you cloned the repo? you checked out to the right commit (or version tag/branch), then ran guix hash -rx <path/of/clone>? <nckx>Does ‘git status’ report any untracked/unstaged changes? <soouul>i didnt do what lle-bout` said :( <nckx>You should do what lle-bout` says. <soouul>yeah no, i did do it from the error and from what you told me <soouul>gives the same hash but not working <lle-bout`>nckx: I think 'guix download' is not a good mechanism, because it doesnt allow you to verify hashes with another format or check signatures <soouul>i did not do it properly and its working now :DDD <nckx>lle-bout`: Yes, it's very (too) limited. <lle-bout`>nckx: it doesnt print the path of the store item, from which you could do verification afterwards even though it would be great to do it before actually adding it to the store <nckx>I think it does what it does well, it should just handle more input. <nckx>lle-bout`: <it doesnt print the path of the store item> There you go again, I don't know what to say. Are we even talking about the same tool? <nckx>guix download → store name\nhash <lle-bout`>nckx: why do you say you don't know what to say, you could just say it does <lle-bout`>nckx: in my memory it printed just the hash and it has gotten me puzzled and stuck before but somehow now it doesnt just print the hash >.> <nckx>In the context of discussing x's design flaws, to someone saying ‘x doesn't y’, simply saying ‘yes it does’ is lazy and assumes that person doesn't know what they're talking about. <lle-bout`>nckx: I think you can say that it does do it for you <nckx>First you said it didn't work, then you say it needs improvement (true) because it doesn't do something that's trivial to check on your end. <nckx>It is not very respectful of my time. <lfam>There are some recent updates, soouul <lfam>The basics are still correct, though <lle-bout`>nckx: I feel more uneasy when you say you don't know what to say than what I suggested <soouul>do i still have to build the --pure environment though? <nckx>lle-bout`: I genuinely don't. All good though. <soouul>or maybe its easier to know whats different <lfam>soouul: Are you just asking about how to build Guix? <lle-bout`>nckx: I don't have a shell in my mind so some times I say wrong things or remember wrong it's normal <nckx>lle-bout`: Then it's better to ask than to declare. <lfam>Regarding #47428, the root user's Guix is up to date and the recent copy of the manual is already built in /gnu/store <lfam>But, it's still not updated on the web site <lfam>We need to figure this out <lle-bout`>nckx: when I send email I check things more, but in IRC like I speak IRL I am not relaxed about checking what I am saying always <nckx>lfam: <So, maybe we just need to update and reconfigure ci.guix.gnu.org, and try again.> Is that still the question? <lle-bout`>I used to be more rigorous in everything but I stopped because that's also a mental health issue for me, so put myself to unrealistic levels of exigence at all times <lfam>nckx: Yeah, I guess so. It's not clear to me how the server is being managed though, so I'm scared to reconfigure it <nckx>lle-bout`: There's the problem. I'm never relaxed. I'm always on edge. I think it has something to do with being subscribed to GNU mailing lists without alcohol in the house. <nckx>{that laughing through tears emojo I'm too lazy to look up} <soouul>do you guys use a vpn? if so which one? i have been eyeing one for a while now but still cant pick <nckx>lfam: It's not that scary (although I can't say it's best practice city, either). I can reconfigure if that will help? <lfam>As far as I can tell, the current-system of ci.guix.gnu.org is up to date, as well as root's current-guix <lfam>So, I'm not sure what is wrong <lfam>Maybe I can find the cron logs <lle-bout`>soouul: I use Mullvad's wireguard servers with NetworkManager wireguard support (without their Electron client) it works great <lfam>write(1) is not installed <nckx>lfam: It worked and scared the hell out of me. <soouul>lle-bout`: yeah i was thinking of mullvad, seems nice <lle-bout`>soouul: it really cares about privacy because it only asks for an account number and you can buy vouchers with cash in shops so payments can also be untracable <lle-bout`>soouul: but I don't say that works well for a VPN, at that level of worrying probably better to use Tor <soouul>ye, i used to use PIA, but it seems its not as good nowadays <soouul>yeah, im not that worried! just want a nice vpn <lfam>nckx: We should look into rotating the mcron.log <lle-bout`>would be nice if network-manager service supported dispatchers <soouul>wireguard-tools for the network-manager support right? <lle-bout`>soouul: with Linux 5.6+ wireguard is in the kernel <lle-bout`>soouul: I didnt have to install any wireguard things besides linux with network-manager to have it work IIRC <nckx>lfam: Weird, it should be in util-linux. ‘Should’. Not in ours. <lfam>I just thought it might be fun <nckx>lfam: Yes, well spotted, we should look into rotating the 78-gigabyte log file, good point. <lfam>I was like, why is it taking so long to open? <lle-bout`>> when you have so much disk space 78GB log files arent raising any alarm <nckx>oreoking[m]: I don't know, what does that log file say? (Use bzless to view it, if you can't read raw bzip2.) <lfam>oreoking[m]: There was a broken version of that package. You should do `guix pull` to make the fixed version available <lfam>nckx: I think it was a test failure that accidentally got "packaged" <lle-bout`>oops sorry actual users affected by my broken commits <lfam>The current revision is 18-6e7ba45 <lfam>Anyways... back to the the berlin server <lfam>I don't think the log file is the problem, although it makes it difficult to inspect the cron outputs <lfam>I wonder, can I invoke the service "by hand"? <nckx>lfam: I see you still have mcron.log open, so will keep it around for now? <lfam>If it's still open, then it's being held open in a virtual terminal that I've closed <lfam>Shall I kill PID 25728, nckx? <nckx>So I've added a rottlog rule to berlin.scm on berlin, but haven't even committed it because it's probably not the right place. Should be a default, no? <nckx>lfam: It was vi, so go ahead, although it can't hurt much (just waste space until it dies). <lfam>I noticed you adding the rottlog job for mcron.log. I think it's right enough <lfam>It should be a default, though, you're right <nckx>I'm too tired/not in the mood to submit patches tonight. <nckx>That file was 71 times the size of my hard drive growing up. It was disgusting. <lfam>I'm going to file a bug about how mcron should use the rottlog service <nckx>Poor rottlog is still chugging through it. <lfam>Next step... try reading the rotated logs :) <lfam>We should probably make a similar adjustment for cuirass-web.log <nckx>It gzip-compresses them without adding a .gz extension, which is a bit meh, but fine. <nckx>lfam: Well, it's still going to be one giant file now. <lfam>Yeah... it should add the .gz <lfam>It's already written >1 GiB to the new log <lfam>Or maybe it's writing the "rotated" logfile, not sure <oreoking[m]><lfam "oreoking: There was a broken ver"> guix pull is not working <nckx>oreoking[m]: That's not helpful. Please elaborate. <lfam>To be fair, we sent our messages at the same instant. They weren't replying to my question <nckx>I have only minute granularity and the choice of words was coincidental. <lfam>I just ran `guix pull` and it succeeded <nckx>lfam: Is there a specific reason your bug report is as non-specific as it is? <lfam>It's just a feature request. "mcron should use logrotate" <nckx>And I responded: <nckx> oreoking[m]: I don't know, what does that log file say? (Use bzless to view it, if you can't read raw bzip2.) ***aidalgol_ is now known as aidalgol
<pranavats>I installed it from that channel and I'm getting the error: "Cannot open load file: No such file or directory, comp". <pranavats>I was wondering if anybody else faced this issue. <rhou[m]>what does this mean from linter: `sentences in description should be followed by two space`? <jx96>VGA output doesn't work with Guix + GNOME, but it works on other distros (including Parabola/Trisquel). <nckx>oreoking[m]: Thanks. Your problem is with a third-party channel (maybe pkill9's, they are a regular here but not currently on-line) that is still using the removed qt@4. The owner needs to fix it. <vagrantc>rhou[m]: The description should have sentences followed by two spaces. Like that <---. Not like this. Or this. <jx96>Suspend with Guix System + GNOME is broken for some reason. Also works in other distros. <rhou[m]><vagrantc "rhou: The description should hav"> so you have to put a space before a period? <nckx>oreoking[m]: You could lock your guix channel to commit 0d8cea4f247272a36c307276253f014f271f1b56 in your channels.scm. You won't get security updates (if any) so don't forget to remove it as soon as the conflict is resolved. <vagrantc>rhou[m]: two spaces after the period, unless it's the last sentence. <nckx>‘Hello. I am nckx.’ <-- not this. *roptat is building scala again <rhou[m]>ok gone try it out, kind of unusual tho... <nckx>It's more unusual now than it used to be. <vagrantc>rhou[m]: it's a pretty pendantic stylistic preference, i'll agree. :) <nckx>I grew up doing it & still do, especially after switching to emacs. <jx96>And some GNOME vector icons (Web, icons in the settings and menus) <jx96>I just want to know if anyone can reproduce these bugs. <nckx>jx96: I've noticed some SVG icon corruption (e.g., the ‘pen’ icon in Evince has wings). Don't use GNOME. <mprofessor>QQ: Am I gonna run into issues if I install guix on a computer with Nvidia graphics? <nckx>mroh: I think so, if your card is in any way recent. I don't think any modern PC graphics cards have free drivers anymore, and certainly not non-Intel ones. <nckx>Sorry, mroh, meant mprofessor. <pkill9>well, for 3D accelerated graphics <nckx>True, although even 2D is a crap shoot. <mprofessor>Hmm. That's a bummer. So y'all have AMD graphics? <nckx>‘i915: it's acceptable™.’ <pkill9>that's some very modest marketing <mprofessor>Intel didn't make sense to me anymore last time I upgraded, went with Ryzen and Nvidia. <mprofessor>Only learned about the driver issues while reading an article about wayland. <pkill9>oreoking[m]: I removed the snowman package from the pkill9 repository, which referenced qt-4, so should work now <nckx>mprofessor: Don't be fooled, new (and I've been saying that for so long it's hardly ‘new’ now) AMD graphics are no more free than nvidia. <nckx>IIRC they require proprietary firmware? We had great troubles getting one of the previous Guix releases to display the installer. <nckx>To my great disappointment, not a 3D experience. <nckx>I happened to have an AMD gfx laptop when the installer first came out & refused to work on it. Decided to get rid of it by accidentally spilling water on it. Was a good decision. <sneek>jonsger, you have 1 message! *lle-bout needs to redo their system and user configuration in a proper way also with something like guix-home or guix-home-manager 
