<Luk6655>How long does it usually take for patches that contain a new (small)piece of software to be merged into guix? <Luk6655>I just checked the oldest and it seems it is from April, well, I thought a couple of weeks, I guess I was wrong <singpolyma>Yeah, unless you're very lucky I wouldn't count on timely inclusion. That's why channels are great :) <ytc>is it possible for me to upgrade a package that is already in the default guix channel using custom channels? or can i only add new packages and install them? <Luk6655>I think it would be useful to add a note to the guix manual, for users looking for missing software, to go search in debbugs before attempting to write their own packages. I only found out about debbugs after I submitted my own patch, but now I see there is some useful stuff there. <Luk6655>I seem to be having a problem adding a comment to my own bug, I sent an email few days ago to patch_number <at> debbugs.gnu.org, but this didn't get added. I thought maybe because the subject line was different. So I resent 20min ago withthe same subject line. Still it is not showing up. Am I doing something wrong? <Luk6655>perhaps I need a subject formatted as Re: original subject ? <unmatched-paren>ytc: you can add a new package with the same name but a different variable binding <unmatched-paren>you can write one with both the same, but you'll get errors if you bring them both into the same scope <Luk6655>ytc: no doubt there are better ways to do it, but I use a local clone of the guix repo, I created my own branch and I point my channels.scm at that branch. <ytc>what if that package is a dependency to other packages? should i write other recipes for them and install them instead of the default ones? <ytc>unmatched-paren: Luk6655: i will look into that. thanks for your help. <Luk6655>ytc: mind that if you do that and you update a package that a lot of stuff depends on, a lot of packages may end up being rebuilt on your system <Luk6655>however, sometimes you want that :-) <Luk6655>that's why I said there are better ways, I'm just starting with guix <ytc>Luk6655: i'm a new user. so i won't probably dive into that for the foreseeable future. :-) <unmatched-paren>you probably don't want to fork the repo just to make some modifications <ytc>i installed gnu guix several times before. every time i returned my old distro regretfully because of the 'weirdness' of guix. but this time i am determined to tame this beast. :-D <ulfvonbelow>why does it take so much memory to compile stuff these days <ulfvonbelow>seems just yesterday 8GB was plenty for any conceivable need <zamfofex>I still believe that (at least for the vast majority of use cases) if any single program requires more than 2GB of RAM, it is inherently poorly designed. <ulfvonbelow>nowadays you've got ungoogled-chromium's build system just casually mentioning "ah, by the way, allocate 50GB of ram for this linking step", or at least that's what it looked like in top <ulfvonbelow>but there's also stuff like monero and monero-gui, which you'd think shouldn't take tons of memory to build, yet building monero brings even my system with 16GB of memory to a crawl for a period <unmatched-paren>it's uh, running tests. Yep, that's definitely what it's doing. Mhm. Nothing to see here. <ulfvonbelow>from what I see in top, telling it to build with less cores would probably lessen the usage on that one, but in the ungoogled-chromium case there's no getting around it, the final link step just straight-up demands an absurd amount <ulfvonbelow>there are few things more depressing than seeing that there's a new security update for ungoogled-chromium in guix master, rebasing on top of it, building chromium, then when it finishes 3 days later you see that there's another security update. At that point, long compile times are legitimately a security issue. <Kabouik>If I want an env var to be exported when logging in, where should I set it? Typically I think that'd be in /etc/profile in other distros, or in .xinitrc for Xorg but I'm in Wayland and <Kabouik>Should I just create a ~/.profile or are there other files where that'd be read already? I need this variable for Icecat so .bashrc won't work <Kabouik>I think my question is more a Sway question than a Guix one, I'll ask there instead <oriansj>Kabouik: actually more of a wayland question than a Sway question actually <oriansj>but hopefully the answer is something along the lines of XDG <oriansj>with it just being some file in ${XDG_CONFIG_HOME} <muradm>Kabouik: my vars are in ~/.profile <sneek>Welcome back muradm, you have 1 message! <sneek>muradm, unmatched-paren says: https://issues.guix.gnu.org/57721 <- wlgreet patch sent! Thanks for your work on greetd; since you're the expert on it around here, would you mind doing a cursory review of it to see -if- what I got wrong? :P <Kabouik>That's something I tried but without success muradm <muradm>hmm that depends how you are starting sway <muradm>suppose i have package1, package2 ... packageN, is there something like (merge "new-pkg" package1 package2 ... packageN) ? <jpoiret>Kabouik: it's a Guix question not a Sway one <jpoiret>sway itself doesn't load anything on startup, but because on guix we need to activate profiles prior to the WM starting, we run the WM through a login shell <jpoiret>so just use the usual login shell files ***MohammadSalehKam is now known as mskf1383[m]
***boud is now known as doublecheck
***doublecheck is now known as boud
<rekado>I already closed the associated issue because we’ve accepted the patches; would be bad if the changes got lost due to branch management delays. <Kabouik>Thanks jpoiret. I think I am using gdm (the one that came by default with Guix when installed with xfce4 and i3, and then I enabled Wayland in my config.scm); but someone in #sway said gdm doesn't load anything in Wayland, just in Xorg <Kabouik>I created a ~/.pam_environment with my variables exported in it, I'll see at next reboot if that works. I read somewhere it might. <Kabouik>On another front, I'm trying to build something that requires limits.h and notify.h so I ran `guix shell gcc-toolchain` and `guix shell libnotify`, that fixed the missing limits.h but notify.h is still missing. Is libnotify not the package that provides it? <Kabouik>The error I get does report that: #include <libnotify/notify.h> <rekado>sneek later tell civodul woo, a new shepherd release! <Kabouik>Heh, now it complains about glib.h, but at least it seems happy with notify.h now unmatched-paren <Kabouik>Yes that's progress, I'll iterate from here <Kabouik>batsignal; it seems to be something that's able to watch battery level and run a command at when a certain level is reached. I'd like it to suspend or poweroff my system when battery is very low, to avoid damaging it. I'm just testing it, not sure yet if it will do what I want. <Kabouik>Adding glib to the guix shell doesn't seem to solve the missing glib.h though <Kabouik>upower can do the same? I'm using it already <Kabouik>Yes it's libnotify that complains about it, as far as I understand the error output <unmatched-paren>so it must be something weird with libnotify, as it's just a gdbus abstraction over the dbus notify interface <examors>You want to add pkg-config to your environment <examors>that should set the right compiler flags to find glib <Kabouik>That went further indeed, I think I'm just not used to guix shell --pure <unmatched-paren>for the actual package, you'll want to do (inputs (list libnotify)) (native-inputs (list pkg-config)) <Kabouik>To be honest I was not trying to package it yet, just wanted to try it in a quick and dirty way with guix shell <Kabouik>`guix shell pkg-config coreutils grep gcc-toolchain glib libnotify make --pure` followed by `make CC=gcc` did it, thank you both <unmatched-paren>drop this into gnu/packages/monitoring.scm and do the ./pre-inst-env guix build batsignal dance <Kabouik>Nice unmatched-paren! I'm testing the binary right now to see if it actually runs a command when the battery threshold is reached, then I can do that. I don't know the pre-inst-env dance yet, actually. Just heard about that script but never used it. <unmatched-paren>`guix shell -D guix -- ./bootstrap && guix shell -D guix -- ./configure --localstatedir=/var && guix shell -D guix -- make -j$(nproc) && ./pre-inst-env guix build batsignal` <Kabouik>Heh except I see it doesn't match the battery level that my i3status-rust is reporting <Kabouik>I need to reboot to test if my ~/.pam_environment works too, killing two birds with one stone <Kabouik>Yeah that worked perfectly, so definitely batsignal could be useful <Kabouik>.pam_environment didn't though'that's irritating <examors>I think ~/.pam_environment is deprecated <Kabouik>Am I missing something unmatched-paren? I tried that `guix shell -D guix -- …" command that you recommended but it doesn't find ./bootstrap, and I am guessing it wouldn't find configure or pre-inst-env later either ***Dynom_ is now known as Guest5933
<Kabouik>Heh, I guess that's what I was missing. -.- <zamfofex>I remember ‘guix shell’ having trouble running relative‐path binaries at some point, though maybe it was with ‘-C’. In my case, I had to explicitly use ‘env’. <Kabouik>Do you folks use aliases or scripts for that step? You're packaging much more often than I am and that command is a tad long to remember <unmatched-paren>it's just the typical gnu bootstrap line, followed by a pre-inst-enved invocation of guix to test <unmatched-paren>you need the --localstatedir or things will break badly on your system <zamfofex>I think it fails to build if you don’t specify it. (I remember some failure when I did it before without realizing it.) <Kabouik>It seems to be building a whole lot of things now, I was expecting it would just build batsignal <unmatched-paren>./pre-inst-env ... sets up an environment where guix commands will reference the local checkout, not the pulled guix <Kabouik>What is the benefit of that against just testing the package with guix build -f batsginal.scm? <zamfofex>I think just making sure that it actually works as expected. <unmatched-paren>it's how you upstream things, it lets you test multi-file package sets, and it allows you to make modifications to existing code <Kabouik>I see, so it is most useful for multi-file package sets <unmatched-paren>yeah, and it also allows you to just send in the patchset once you've got it working <tschilptschilp23>I just run into an unexpected situation, not sure though if it's gnome or guix' gnome implementation. I'd like to change my desktop's background image (right click, 'change background'), but don't seem to be able to do so. Once I click 'add picture' on the top right, the file browser opens as expected, but the 'open' button stays greyed out, when selecting an image. At first I thought, that it might be the file format or resolution, <tschilptschilp23>but even if I convert one of the .png images (already at my screen's resolution) to jpeg using gimp, the situation persists. <lilyp>it's also useful if you're actually writing a patch :) <Kabouik>I was trying to update i3status-rust yesterday (our package is 1.5 years old as far as I remember), and it needs an update for rust-inotify too. I managed to build rust-inotify with guix build -f fine, but didn't know how to make i3status-rust find it. Maybe that's the way. <tschilptschilp23> As a sidenote, if I right-click the image from the file-browser and select 'open with another application' to open the image with gimp, I receive a popup surrounded by yellow dashes from '.blueman-applet-real' stating 'Failed to apply network settings\n you might not be able to connect to the bluetooth network via this machine' with a 'g-dbus-error-quark' exception. This also persists, if I actually plug in my (working) bluetooth <lilyp>no ideas on the dongle thing, but you can set the background from nautilus <lilyp>(right click on file "set as background") <lilyp>you can also use gnome-tweaks <lilyp>I'm not sure what makes the button greyed out, but I'd hazard a guess it uses the system-wide backgrounds, which are read-only <Kabouik>I didn't get this error when trying to build without a package definition, just using make CC=gcc from sources <Kabouik>Well, I wanted to fix it myself then looked at the package definition and figured I had no idea how to fix it. Now that I see your solution, I'm glad I asked. :p <unmatched-paren>> command "/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash" "./configure" "CONFIG_SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash" "SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash" "--prefix=/gnu/store/rzk797xqdm142djsn1b3m1n8qgvqpg7j-batsignal-1.6.0" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" failed with status 127 <Kabouik>I think it's still missing the dependencies we discussed above (glib, libnotify, pkg-config, grep, coreutils). Are those native inputs? <lilyp>from left to right p sure regular, regular, native, don't know, why? <unmatched-paren>the former an input because it's executed on the target, the latter a native-input because it needs to be executed by the host during the build <zamfofex>I wanted to say: I’ve actually been able to set up a substitute server for Guix on the Hurd, by the way! 🎉 However, when I try to run ‘guix build hello’ on it, it fails when preparing the sources for GCC 10.3.0 for some reason. I don’t know why, but the SSH connection just closes amidst the preparation (after the download, while it is listing the files in the source). <zamfofex>If anyone is willing to help, feel free to send me a DM and I might share the login information to the server. <Kabouik> https://0x0.st/of7-.txt does that look correct? Apparently I use a new use-modules for packages gnome due to libnotify, I'm surprised this wouldn't be used by any package in monitoring.scm already <unmatched-paren>you need to do (native-inputs (list pkg-config)) and likewise for inputs <zamfofex>unmatched-paren: I’m glad you seem to be enthused by it! 🙂 I’m very happy about it myself! 🎉 I wish I could know what’s wrong with the GCC build, though. 🤔 🙁 <Kabouik> https://0x0.st/of78.txt I'm sorry to bother you with errors in each iteration that I am not able to solve myself unmatched-paren, that was why I initially aimed at just a quick and dirty build from sources without a package :O <zamfofex>lilyp: But just while listing the sources? (I think it’s during the patch phase.) Is that actually likely? (I don’t know!) The Hurd VM has 1.5GiB (the VPS has 2GiB). <unmatched-paren>btw, the #~(...) thing means "this is evaluated in the build environment" <Kabouik>#:phases is in (arguments (list)), I meand the line under phases <lilyp>zamfofex: if it's during the patch phase, it could be trying to patch a file that's too large – idk if 2G ought to suffice <Kabouik>I seem to remember I need to add a comment when tests are disabled, to explain why <zamfofex>lilyp: Actually, I don’t think it’s during the patch phase. It seems to be while building ‘/gnu/store/…-gcc-10.3.0.tar.xz.drv’, so before the actual package. <lilyp>zamfofex: could the tarball grow too large? <tschilptschilp23>Mhm, although I couldn't make out any changes on gnome-related packages since commit e05e5342a0baa8a72d3e1b1e3a5d57da13f764b3 except gnome-maps, I just pulled and tried to reconfigure, and now my custom wifi-dongle-module fails to build. As I'm having troubles reading the error -- here it is: http://paste.debian.net/1253488. The module's definition looks like that: http://paste.debian.net/1253489. This one built successfully from kernel <tschilptschilp23>5.15.x to 5.17.x. For making it work on 5.18.x I had to update the github definition to upstream. Since then only the docs received and update at upstream, so this will likely not help this time. Happy about hints what the error means! <LemanR>Hey all, is dual booting with windows possible? <LemanR>If so would I follow steps similar to other distros? <lilyp>Currently not, but there is a chain-loader patch on the mailing list that might help you <LemanR>Is that where grub leads and has the windows boot loader as an entry? If not I can research this <lilyp>regardless of what you do, you'll have to make grub lead (or load, same meaning in the end :P) <LemanR>Also do you all help with the nongnu install method? (I have a Thinkpad so I have to use nongnu) <LemanR>Or no since it's not strictly what gnu guix intends or supports <unmatched-paren>you'll have to go to #(name of the Forbidden Channel of Death and Despair) <Kabouik>unmatched-paren, I'm assuming you're already in monitoring.scm copyrights? <Kabouik>What should I add for you in the patch? <tschilptschilp23>OK, arch users on kernel 5.19.x seem to have troubles as well, trying to adapt the workaround mentioned at upstream issues... <Kabouik>I can't find in the documentation how to make the patch before sending it with git send-email, and I don't remember. Are there conventions or can I name it the way I want with git diff monitoring.scm > batsignal.patch? <unmatched-paren>Kabouik: never use git diff > file, i don't think it works for git email patches <pkill9>why does rhythmbox suck, lol, it randomly crashes <pkill9>I always imagined rhythmbox as *the* bog standard dekstop musci player for linux <talos>Hi all, if you're looking for a GUI music player, I would recommend Strawberry. On any distro. <mbakke>rekado: I don't see the update-vulkan-headers-staging branch, and it has not been evaluated by cuirass <zamfofex>unmatched-paren: I never figure out how to use Git to send emails, so I just send patches by attaching the ‘git diff’, and it seems to work have worked somewhat well enough. <unmatched-paren>> In summary, git format-patch is useful to transmit a commit, while git diff is useful to get a diff between two trees. <unmatched-paren>> They are two different things and have different purposes, they just happen to output a patch format. But git-format-patch adds data about a commit (date, author, commit message) and bundles it up into a format that is suitable for sending as a Unix mail message (although these are just files, so they can be sent to other methods and still applied by git-am). <unmatched-paren>Also git-format-patch generates a patch file for each commit in the range that you specify. These changes will be added as commits to your repository with git-am. <unmatched-paren>doing git diff HEAD~blah will create a diff containing all the patches <Kabouik>Pretty sure zamfofex will be smarted than me but I fail using that script so far :< <Kabouik>Those are all new commands to me and I guess I'm trying to cut corners and reading the manual of each one <Kabouik>Ah, then I was fooled by the .sh already <unmatched-paren>it's just a set of commands with explanations, not to be run as a whole <Kabouik>Is the cover letter mandatory for a new package? I guess the commit is self explanatory <zamfofex>unmatched-paren: In my case, my patches were just a few files (sometimes just one), so I didn’t need to worry much about it. (Though I will say: I only sent, like, three patches insofar.) I shall investigate ‘format-patch’ or ‘send-email’ more carefully if it makes it easier for maintainers. <Kabouik>Oh, I thought the cover letter was some custom messages I'd have to append <unmatched-paren>Kabouik: You need to type the blurb and subject, but the rest is auto-generated <Kabouik>I have "gnu: batsignal: new variable." which I think is standard, although I couldn't find confirmation in the manual <pkill9>rhythmbox decides tow rok, after some reopenings <tschilptschilp23>Is it possible to point git-reference to a certain branch of a github-repo? <Guest50>What should I do or who should I contact about outdated packages? Libreoffice is on 7.1 for example. How should I see it gets updated? <antipode>tschilptschilp23: (guix git-download) does not care on which website the git repositories are hosted. <oriansj>tschilptschilp23: well any git repo could be used and if by git-reference you mean a commit id, yeah that works fine <antipode>So you can do in the same as for any other Git repo. <oriansj>(even self-hosted and local to your machine) <unmatched-paren>tschilptschilp23: you *could* use a branch name, but then the package will randomly break <antipode>I wonder if "guix refresh -u libreoffice" will 'just work' ... <Guest50>is guix for libreoffice using the fresh or stable branch? <antipode>AFAICT guix does not use a fresh or stable branch. <phodina[m]>tschilptschilp23: If you point to a branch name it's possible it will not work in the future as the hash will be different if you push patches. Better to specify directly the commit or the tag <antipode>It seems to just use the latest released version (except for currently being out-of-date) <Guest50>So I just submit a bug report to bug-guix@gnu.org about an outdated package and the maintainer will take it from there? <phodina[m]>> <@tschilptschilp23:matrix.org> Is it possible to point git-reference to a certain branch of a github-repo? <phodina[m]> * If you point to a branch name it's possible it will not work in the future as the hash will be different if you push patches. Better to specify directly the commit or the tag. <phodina[m]>To answer your question. Yes, but IMHO would not recommend this. Just use `(commit "branch-name")` <unmatched-paren>you'll need to take matters into your own hands, or wait until someone decides to do it <Guest50>I like guix because the dependencies are just tar and guile, more lightweight than flatpak. <antipode>Guix has more dependencies than 'guile and tar', e.g. it requires a C++ <unmatched-paren>and guile-avahi and guile-ac-d-bus and guile-semver and guile-sqlite and guile-git and guile-ssh and ... <Guest50>What I meant was, on slackware at least, I have to install about 6 dependencies to setup flatpak or I can just run the installer for guix which slackware already has the dependencies for. <antipode>unmatched-paren: "guix refresh -u" fails ... <lilyp>All 69 channel news entries are valid. Nice. <oriansj>antipode: incorrect, since the latest release guix uses stage0 for bootstrapping <oriansj>and if one wanted to go the live-bootstrap route you don't even require guile or tar as a bootstrap dependency <antipode>However we boostrap things, g++ remains a dependency of guix, it is still in the (implicit) inputs <antipode>I'm referring to the dependencies, not the bootstrap seeds <lilyp>Kabouik: The cover letter is mostly a courtesy when doing multiple patches at once. If you only have a single patch but want to add notes, add them below the ChangeLog (after the --- line) <Kabouik>Yeah, I sent the patch too jut now unmatched-paren. Hope I didn't do any bad shenanigans, the whole thing is a bit intimidating for someone not used to it I must say. There's a tiny mistake as my cover letter was for a previous commit whereby I forgot to add myself in copyrights (I thought it was fine if you were the only one in there since you wrote the packge definition), and the patch actually has one extra line for that extra copyright compared to <Kabouik> what is announced in the cover letter <oriansj>antipode: I thought we got rid of the c++ nix build bit with something more guixy <lilyp>antipode: perhaps part of git? <lilyp>a mail-formated git patch has three parts: commit message, summary, and patch <lilyp>the summary won't show up anywhere so you can abuse it to put your own message there <antipode>Found the "guix refresh -u" bug, writing a patch ... <tschilptschilp23>phodina: or even better, I won't change anything at all. I like my computer as it is and can live with not using kernel 5.19.x for now :) <phodina[m]>Not sure what machine you run but you can choos the OS in the GRUB/uboot (run the previous generation). Is there something in 5.19 that sounds scary? <oriansj>but I thought we were all the odd number sort ;-p <lilyp>No, I believe Python would have been better off had they skipped Python 3 and went straight to 4 <zamfofex>Well, currently Guix is at 1.3, that’s *two* odd numbers in a row! 😅 <tschilptschilp23>My 'only' problems are the gnome-issues I described above and I hoped that a 'guix pull' could solve them. This is very unlikely looking at the changelog since then. I tried anyway, and the upstream wifi driver I packaged for my personal use does not compile on kernel 5.19, which comes with the latest pull. Upstream seems to have this compilation problem solved within a certain branch -- that's where my question regarding branches in <tschilptschilp23>package definition comes from. But I've just thought through your hint and the consequences will likely bring me more trouble in future than desktop-background-design and a filebrowser-gimp-glitch... <Kabouik>lilyp: before sending another mail, would nicknames like "Co-authored by ( and Matf" work or does it *have to* match the copyrights? <lilyp>I'm p sure ( should be rendered unmatched-paren <lilyp>but the more obvious point was w.r.t. you sending the mail from one account and demanding credit for another; if that was your intent, go ahead, but I'd like to avoid MUA misconfigurations that could lead to errors down the line <Kabouik>Okay. So I `git commit --amend` to update the commit message, how should I proceed now to send just that change? <lilyp>I have used mail addresses that are valid nowhere outside my local network before, so I'm just being cautious here. <lilyp>you don't send just that change, you typically send a v2. also don't forget to address the other points raised <Kabouik>That was intentional because my general Git email is the one I sent the patch from, makes it easier to monitor all my notifications in one place even though for Guix I agree to use something less anonymous <Kabouik>If that is an issue, I can send the v2 from the same email as reported in the copyright, you tell me <tschilptschilp23>I guess I'll keep monitoring upstream's github repo and wait until the branch fixing the problem on kernel 5.19.x is merged into the default one, and then make a properly updated package definition, which is properly controllable with hashes. This does not make me extremely happy, but at the same time my current system configuration is not extremely old... <lilyp>it's fine as long as you remember to put copyrights in your patches – if you forget, a committer might pick up the wrong one <phodina[m]><tschilptschilp23> "My 'only' problems are the gnome..." <- Well either you can have the definition in file/channel for the specific kernel with the fix or just wait 🤞 <lilyp>tschilptschilp23: I suppose you tried transforming the package already? <antipode>Updating libreoffice should now be just a matter of "./pre-inst-env guix refresh -u libreoffice" <Kabouik>I don't know how to resolve the point you raised about batsignal -v test lilyp; before we disabled the tests, the build was failing <lilyp>the point is you should be able to run the command they run in a container in a regular shell <oriansj>and I have a stupid idea for potentially solving the guix luks double password prompt problem <lilyp>(replace 'check (lambda* (#:key tests? #:allow-other-keys) (when tests? ...))) <oriansj>and it doesn't involve putting key material in the store either <Kabouik>I'm sorry but since I cannot understand that code, I don't know how/where to include it in the package without making things worse. Could you please show me context lines lilyp? <lilyp>mbakke: Resource unavailable? <lilyp>Kabouik: In plain english, you have to replace the check phase (in #:phases) so that rather than invoking "make check" it invokes "./batsignal -v" <Kabouik>I understand but I don't know how to write Scheme, that was what unmatched-paren did really, I'm just doing the submission work (badly) <zamfofex>Kabouik: I think you need to use ‘invoke’ to just run the test command. <oriansj>basically one can create a custom initramfs to replace the one guix makes <zamfofex>Also: I’m feeling really bummed that my Hurd substitute project seems to have failed. I feel like I got so far, but I just can’t afford a VPS with more RAM. 🙁 <lilyp>oriansj: "makes" or "currently makes" <tschilptschilp23>phodina: right :) I just visited a file called 'fix_nautilus_gimp_blueman.org' and only even typing the filename made me scared... <Kabouik>That's assuming I know Scheme fundamentals zamfofex, but I don't: the whole (arguments ...) snippet is the most obscure of all to me and I don't know how/where/instead of what I should paste what lilyp suggested above, or the 'invoke' function. With the scheme code above in the package definition, I think I'm able to understand a bit and try and iterate things, but with (arguments ...), I'm not there yet <antipode>Kabouik: Search with git grep -F "(replace 'check" <tschilptschilp23>ha, and once more I'd forgotten about gnome-tweaks -- first issue solved ;) <unmatched-paren>this procedure takes arguments like #:tests?, #:phases, #:make-flags, etc <unmatched-paren>so, arguments is a list of arguments to splice into the call to that function <unmatched-paren>(modify-phases PHASES SPEC ...) takes a set of build phases as PHASES, and a few SPECs like (delete 'phase), (replace 'phase PROC), (add-(before|after) 'phase 'new-phase PROC) <unmatched-paren>and #~..., which is a "gexp", tells guix to evaluate an expression at build time, as I said before <apteryx>is there an action to do for the lint check: tracker@3.3.3: Disarchive entry refers to non-existent SWH directory <zamfofex>Also: “Associations lists” are like dictionaries in Python, or objects in JavaScript. (Or “maps” in some languages.) <oriansj>lilyp: the one that guix currently makes in a build; after that build completes <Kabouik>Thanks unmatched-paren, zamfofex. I'm sorry if all this may be basic stuff but from my perspective it's a bit much to process (it could be that I'm slow too). I'm enjoying Guix so I want to try contributing, and having the packages I deem useful is also beneficial to me anyway, but development, let alone in Scheme, is far from my skill set. I'm still trying to remember other things I learned with Guix in the past few days, the build-system linguo <unmatched-paren>it took me about a week to put together my first package, iirc (a small gnome app in python) <Kabouik>Appreciate your patience unmatched-paren. :> <unmatched-paren>#:foo is a keyword argument, so you can call procedures with keyword arguments like (proc #:keyword1 value1 #:keyword2 value2) <unmatched-paren>and maybe put it after add-after, since configure comes after unpack <zamfofex>The idea is that you specify a keyword (which is like a key in a dictionary), then the value associated with the keyword immediately after it. <unmatched-paren>the (arguments (list ...)) is just a list of arguments to pass to the procedure that runs the build <zamfofex>Keywords are just the way Scheme/Guile has to pass in named arguments to procedures. <unmatched-paren>(apply string-append (list "foo" "bar")) == (string-append "foo" "bar") <unmatched-paren>mhm, like, say, python's named args: `foo(bar = baz, quux = buzz)` or ocaml: `foo ~bar:baz ~quux:buzz` <Kabouik>I know bash (a bit) and R (a bit more) :p *unmatched-paren searches "R keyword args" <tschilptschilp23>and now it's getting really embarassing -- it turns out, that by some coincidence the above mentioned 'blueman-error message when opening an image from nautilus with gimp' simply WAS a screenshot (ie not a pop-up, but indeed an IMAGE) I once took having troubles with a bluetooth dongle :) shame on me... <Kabouik>I think I didn't get what the substitute snipped does then, that was not in lilyp's review <unmatched-paren>Kabouik: > The test appears to be running "batsignal -v", which we could do in the <unmatched-paren>(in practice it won't because one of the dependencies apparently can't cross-compile) <Kabouik>I totally missed antipode's review, now that makes sense to me (even though I feel like a puppet not understanding every move I'm doing) <tschilptschilp23>sorry guix for polluting the chat today, I guess it's time to get some fresh air! <unmatched-paren>tschilptschilp23: There's no polluting chat, unless it's cryptospammers (who literally do pollute the environment :P) <Kabouik>I feel I polluted it much more than you did, tschilptschilp23! <oriansj>unmatched-paren: well there is also the people who just copy and paste a dumpster fire of text directy into IRC instead of putting it somewhere proper like paste.debian.net <unmatched-paren>but that's just because they don't know that you're not supposed to do that on IRC <oriansj>ideally, but there are also assholes who don't care that they are acting like jerks <unmatched-paren>I have never come across someone who pastes a load of text deliberately, but okay, i haven't been using irc for very long <lilyp>and then there's folks using the matrix bridge who don't even know that all their fancy things are not meant for IRC <oriansj>unmatched-paren: be grateful, as they are the type that just screams at everyone because their exact use-case isn't magically solved and how dare we not rush to address their problems. <Kabouik>Maybe I need to remove the pkg-config input actually? <Kabouik>So I guess it should be ok then, I just tested and building works <unmatched-paren>i would say use guix build --target=aarch64-linux-gnu to test cross-compilation, but as antipode said one of the dependencies doesn't cross-compile anyway <Kabouik>I'll afk a bit before sending the v2 patch, I need some air, I'm in apnea since the beginning of the (arguments ...) explanation :p <Kabouik>Yeah cross compilations fails at krb5-config <unmatched-paren>guix build -system=aarch64-linux will automatically set up a qemu and run the build in there (this isn't cross-compilation) <unmatched-paren>and you can then use the resulting binaries by setting up the qemu-binfmt service <podiki[m]>so matrix users note you won't be receiving messages except from matrix users <lilyp>podiki[m]: can you read this? <podiki[m]>woohoo see that lilyp's emacs native comp patches got merged, great work! now for a good emacs yak shave... <zamfofex>I have a computer with 4 GiB of RAM and 0.5 TiB of disc space. I wonder if I could set it up as my Hurd substitute server instead of running a VPS. 🤔 I’d need to back up all my stuff from it, though, so I’m unsure. Before I commit to it, I wanted to know: Would anyone here benefit from or appreciate a substitute server for the Hurd? <zamfofex>I really wish more people would be interested in the Hurd, so that I could have more reason to continue to work on this. <podiki[m]>so with the transformation noted in the news about emacs native comp, could use that on a manifest of your emacs packages to do the compilation all at once, very nice! <lilyp>podiki[m]: yep, that's what I did for testing <lilyp>zamfofex: I think with the biggies like usb not working, I doubt the year of the Hurd desktop is comig soon <lilyp>so rather than a full-blown substitute server, perhaps you want to start a little smaller and build a hurd experiment rig <LemanR>Can someone check over how I have my boot setup. I want to confirm that my setup should work before I reboot, I've not had success yet <zamfofex>lilyp: I understand, I suppose. Though if I understand what you mean by “experiment rig” properly, I feel like, at least for Guix, it’d be nice to have a substitute server somewhere, instead of having to build everything from source. <LemanR>Mainly should grubx64.efi end up at /mnt/boot/efi/EFI/grubx64.efi? Mount is /dev/my-boot-partition /mnt/boot/efi <Kabouik>I got a mail delivery issue with git send-email -v2 unmatched-paren. Your comand uses guix-patches@bla.com instead of the issue number, is that correct? <LemanR>Meant '/mnt/boot/efi/EFI/Guix/grubx64.efi' <zamfofex>LemanR: You should be able to try it, and if it fails, you can always roll back to a previous system configuration from GRUB. <zamfofex>lilyp: It also feels really sad because I got mostly everything working, and it’s now just an unfortunate budget problem. <LemanR>Based on reading that should work but has failed before where my bios still shows on old fedora entry which shouldn't exist. I think that's related. zamfofex that's an issue, I don't get grub, just one of my computer's menu options. It includes old entries that no longer apply and when selecteb loops back to the same menu <LemanR>Does grub have a function I can use to double check things? <apteryx>is someone using emacsy? it's been failing to build for a long while <LemanR>I know my gentoo system required initramfs or else it would refuse to boot <LemanR>SWEET it works. Maybe I was messing up some small step before <tschilptschilp23>lilyp, unmatched_paren: just reading up the logs -- thanks for your input! <lilyp>zamfofex: long-term we should probably set up some substitute servers for the hurd <LemanR>oriansj I can see that. Luckily I did something different apparently cause it working now. Can't wait to get going. <lilyp>that being said, this takes more than just some vps with 2 gigs of ram and a few gigs of space <zamfofex>lilyp: I suppose so. Though note that I had a block volume with 150GiB of space attached to it, at least. <zamfofex>(And I was running the VM from it, so it should be available to it.) <lilyp>yeah i doubt that's enough to start sending substitutes to a large user base <zamfofex>Though “a large user base” doesn’t really seem to be applicable here, I feel. <lilyp>it's better to first get some big package (like gtk) working on one machine rather than none at all <lilyp>Our interest in the Hurd is not zero, it's just that many find it too impractical to try <lilyp>so do expect a sizable number of requests once you start advertising this in guix channels <oriansj>lilyp: and there isn't a good getting started guide for people want might want to try <zamfofex>I wish I could help in some way. If anything, I felt like setting up a substitute server like that would at least help acquire some interest in it. <lilyp>true, but that's one reason to set up an experiment rig first <oriansj>for example a basic procedure and an example config to play with would be nice <lilyp>for that you will need at least a configuration, which in turn can be shared to enable others interested in the hurd to do the same <lilyp>you get a feeling for how much space is needed to build X package etc. <oriansj>lilyp: about 20GB should be enough for a solid base system with gui <lilyp>I said think small,but not that small <lilyp>20G will fill up quickly if you're putting this into "real world" tests <lilyp>I'd say around 8G of RAM and 128G disk should cover the "I'm camping in the Hurd for a year" case <lilyp>You will want the benefits of guix like multiple generations with roll-back for example :) <zamfofex>How much disc space do you think it takes to have a decent substitute server? <zamfofex>lilyp: >“long-term we should probably set up some substitute servers for the hurd” Is there any reason for this to be “long term”? I assume there are other priorities, I suppose. <zamfofex>It would be really neat to be able to use GNU/Hurd for a month (or maybe even a year), then make a video about it. I feel like that’d help gather interest from people by showing it is viably usable! <Cairn>I posted in the wrong channel <oriansj>lilyp: the reason I say 20GB not because of it being enough to live in for a year but rather it is small and cheap enough that it wouldn't be a burden on anyone and you can just include a comment suggesting 120+GB if one wants to use it as a daily driver <unmatched-paren>Kabouik: You should do `git send-email --to=<bugnum>@debbugs.gnu.org -v2 -<npatchus>` <Kabouik>That's what I did afterwards indeed unmatched-paren, I got confused by the last line in your send-patch procedure where guix-patches@ is hardcoded instead of ${bugnum} <oriansj>especially when one notices guix stores 1+GB each for everytime they build ghc, rustc, llvm, qtbase, qemu, etc <Kabouik>The patch was sent, you can check if you are curious <Kabouik>I'm submitting another patch for another program. It's a rust program. I see that most rust packages are named `rust-nameoftheprogram`. However, some are not, like e.g. swayhide. What is the convention I should follow? ***maximed is now known as antipode
<unmatched-paren>Kabouik: Why were you sending your Rust package to the batsignal issue? <Kabouik>That was a mistake unmatched-paren, I sent a comment about it. I only realized it once I saw my emails. :( <Kabouik>The rust package was not sent to the batsignal issue as far as I know, but the other way around <Kabouik>Does the co-authoring formatting justify a v3? <Kabouik>I hope I can fix the rot8 issue where batsignal patch was sent as well. <Kabouik>I actually thought about it when I formatted the patch, but then forgot while filling the cover letter <Kabouik>Or maybe you were referring to the co-authorship formatting <Cairn>Am I misunderstanding `--with-source`? I cloned Emacs, but when I run `guix build --with-source=emacs emacs` I get "./autogen.sh: line 286: git: command not found" <unmatched-paren>i think it should be --with-source=emacs=file:///home/cairn/code/emacs <Cairn>Hm. Same error unmatched-paren <Cairn>Also the manual seems to imply you can simply specify the directory of source. But yeah, neither version works. <Cairn>Would this constitute a bug report, or does that seem like intended behavior? <Cairn>So maybe an Emacs bug report then =) <Cairn>Sure enough, removing .git worked. At least it moved past that stage of the build process. <lilyp>unmatched-paren, Kabouik: only the co-authors, not the main author should be listed in co-authored-by. The main author is the one sending the email by convention ***rgherdt_ is now known as rgherdt
<Kabouik>"Co-authored-by: unmatched-paren <paren@disroot.org>" then? I'll send a v3, that way I'm practicing my send-email kung fu <Kabouik>Sure, I was following lilyp's instructions above when I first proposed (, but it's best if you can confirm what you want actually <Kabouik>Apparently the other person doesn't get listed in the changelog. They said the sender is typically the main author, but actually I'm happy to swap that if you prefer <unmatched-paren>Anyone around here who could review and possibly merge the 6 packages in 56961? <Kabouik>You wrote the package definition and I submitted it after tests and minor edits, so I thought co-authoring was appropriate (but I don't mind not being listed at all, only apparently the sender automatically gets listed as main author) <unmatched-paren>I believe Git treats Foo-bar-baz: ... lines at the end of the commit specially <Kabouik>Problem is when I use git rebase -i to amend my commit and properly mention co-authorship, git send-email doesn't see any file change, so it doesn't produce a new patch <Kabouik>-a works only for the latest commit, doesn't it? I have the rot8 commit after the batsignal one <Kabouik>I found minor formatting issues in the description anyway, namely spaces should be doubled. I'll include that as well in the v3 commit. <lilyp>-a only works on the latest commit, you're thinking of rebase <Kabouik>I think git send-email was not seeing the batsignal.patch in my mess because I told it my patchset is of size 1. If I use git format-patch -2, then both patches are created, but they also report Patch 1/2 and 2/2 accordingly (which I gues I can just edit for now, to clear the mess and get it over with) <unmatched-paren>Kabouik: small formatting issues: (1) co-authored-by should have no leading spaces and should be preceded by a newline, (2) the (replace 'check ...) formatting is messed up <Kabouik>I wish you told me that seconds ago :< <Kabouik>Don't be sorry, it's all on me really. Looking into it, thanks <unmatched-paren>I wish I could merge your patch, but you need to have had 50 of your own commits merged before you can ask :) <Kabouik>Heh, from my perspective that looks like the bar is kinda low. In 50 commits, I'll still be a noob. I could destroy Guix with just my mistakes and commit permissions. :> Fortunately that's not granted automatically, I hope. :P <unmatched-paren>You also need to have 3 committers vouch for you and have 6 months of experience with the project <Kabouik>You would have heard about it here otherwise, surely D: <podiki[m]>lilyp: huh, emacs-pdf-tools doesn't build with --with-input=emacs-minimal=emacs <podiki[m]>will investigate later unless you know what it is off hand <Kabouik>Hopefully that iteration was the last one, I don't want to spam everyone's mailbox <Kabouik>This is a whole different level of complexity though <lilyp>podiki[m]: I haven't checked all packages, so please do <Kabouik>Damnit unmatched-paren. I forgot the copyrights this time (I restarted from scratch in another branch). *sigh, then cries* <Kabouik>At least this rocky road helps me remembering things. <unmatched-paren>No problem with sending a gazillion revisions. That's what you're signing up for when you subscribe to guix-patches :D <Kabouik>Now before I send another one, I'm doubting: should co-authors be added to copyrights? <podiki[m]>lilyp: it fails on invoking emacs for the byte to native compile with status 255....had you seen that before for any packages? <Kabouik>My opinion is they should but I'm not sure what's the convention <Kabouik>lilyp didn't raise that point earlier so I assume that was fine <Kabouik>Out of curiosity unmatched-paren, your send-guix-patchset.sh howto L22-25 mentions that we can send revisions in a single command. We still have to git format-patch with the rebased commit beforehand, don't we? <lilyp>podiki[m]: the package builds fine on my machine; is your emacs broken? <unmatched-paren>the only reason we don't do that for v1 is because we need to send the cover letter and the rest to different addresses <Kabouik>git send-email -v5 -1 --to=57731@debbugs.gnu.org <Kabouik>Meh. That was me typing my command in the wrong window. <lilyp>it does however not perform native compilation, probably because it uses a different build system <lilyp>nvm i forgot to prefix it with ./pre-inst-env <unmatched-paren>the reason we have to send the cover letter to guix-patches first is that debbugs isn't very good at figuring out which emails are related <unmatched-paren>so it'll create a new issue for each email if we send them all to guix-patches <Kabouik>Now the issue is actually lacking explanations for all those revisions, everything happened here. <Kabouik>Yeah, I got that issue when I submitted nmail unmatched-paren. Your howto will be very handy, I'll keep it preciously, and probably amend it with some idiot-proof extra instructions for myself. <unmatched-paren>I have it bookmarked so that I can bring it up whenever someone asks "how send patch" :) <unmatched-paren>annoyingly i can't edit it, so i'll need to create a new one to fix that issue in the last command with the wrong address <Kabouik>An interactive tool doing all that work to facilitate contributions to Guix would be quite handy, but on the other hand I think average Guix packages and developers are well above the git send-email confusion I faced <zamfofex>I’m back. And I will say: Now that my Hurd endeavors have proven themselves unfruitful, I still feel interested in doing something for Guix, and I still don’t know what that should be. I did want to ask, though, lilyp: You said 2GiB oughtn’t to be enough for a substitute server, but isn’t it all that the Hurd can have access to, currently being 32‐bit and all? <lilyp>I could be wrong about this, the final tarball seems to be only 76M big <lilyp>that being said, I don't know what'd be killing your ssh if not the oom killer <unmatched-paren>zamfofex: I think 32-bit kernels support up to 4GiB? probably wrong though <lilyp>also yes, memory is unsigned <lilyp>and iirc there are largemem tricks but I don't think hurd supports them <zamfofex>I could try starting QEMU on the server manually with ‘--display curses’ and running ‘guix build hello’ then to see if some error comes up. <podiki[m]>lilyp: so you also got an error in the 'emacs-build' phase with status 255? <lilyp>podiki[m]: yeah, there is a native compile error, but you don't get the full message (truncation strikes again) <rekado>mbakke: drat, the push must have failed without me noticing… Just pushed it. <podiki[m]>okay. I've used that package before on emacs with native-comp, so likely something with the guix packaging or how emacs is called *unmatched-paren pulling native-comp commits <zamfofex>It seems the entire VM shuts down while building the GCC derivation because the ext2fs translator dies! <zamfofex>Note that even when accessing it through SSH, it would always close the connection after listing that exact directory (‘…/vetfail’), so maybe there is something wrong with that directory specifically. ***dantan is now known as tschilptschilp2`
***tschilptschilp2` is now known as dantan
<pkill9>how can I call (guix-environment* ...) from guix/scripts/environment.scm to have it put me in an environment with given manifest? <Kabouik>Say I'm trying to update i3status-rust package and that implies updating rust-inotify too. Those are in two different files (rust-apps.scm and crates-io.scm), respectively. Should that be one commit or two commits? In the former case, how do I format it? ***tschilptschilp23 is now known as tschilptschilp24
