<civodul>pkill9: it shows everything but there are some things it doesn't know in advance <civodul>in those cases, it displays it another time later on <pkill9>why doesn't it know them in advance? <pkill9>sometimes it only shows a few things <pkill9>only shows 33mb will be downloaded <lfam>The red-eclipse store item is 1 gigabyte, but Guix only reports it as 33 megabytes? <pkill9>no, it only reports the first few dependencies <pkill9>basically it means you can't see how much will be downloaded <pkill9>and that was a good example of the discrepancy <roptat>how would I start the shepherd in my chroot? <roptat>looks like I managed to run it, though every service is failing *lle-bout still hasnt done CVE entries, hopes people will help but also wants to work on other things and ignore CVE entries for now <lfam>I'm going to take care of patching the `patch` package <lle-bout>lfam: thanks! honestly not sure how to do this /stable thing, it froze my motivation because it requires me to understand someone else's undocumented work <lfam>I understand what that's like: getting stuck because you are struggling to understand something <lfam>I think we all experience it <lle-bout>It's a bit tiring to spend most of your GNU Guix contribution time organizing changes in an incremental manner so that they can be committed individually, some times I spend more time thinking about that commit story than the actual changes to the code. I feel like that's a bad thing. I feel like maybe there's a way to accodomate that need for documentation of individual changes without that phenomenon <lfam>Sometimes I do this kind of work during code review, on behalf of the contributor <pkill9>nice to see lagrange is in guix now <lfam>I thought about your comment for a few minutes <lle-bout>pkill9: there was a duplicate patch submitted <lle-bout>pkill9: not sure which one's best but yeah, I bothered with unbundling and the merged one didnt <lfam>It reminds me of a discussion I had with another person recently, about how the package synopses and descriptions can feel so hard to write after getting the package working <lle-bout>I am thinking the first troublesome task of having to duplicate the 'what' of changes maybe it could be fully automated? I heard s-diff something from ludo one day? <lfam>It's hard to change tasks from coding / packaging to what is basically writing documentaiton <lfam>And, I think that making "good" Git commits is a form of writing documentation <lfam>The what could be automated in many cases <lle-bout>lfam: I would say most the effort is not spent on documentation but rather on duplicating the 'what' <lfam>But, in general, I recommend approaching these things as a different kind of work. Maybe it requires a break after the real coding part <pkill9>there was a privilege escalation in sudo that time, how much do people really need to use sudo anyways <pkill9>why not just swithc to another tty and run as root there <lfam>I don't think that a nice changelog-style commit message merely duplicates the "what". <lfam>It's invaluable in understanding the commit <lfam>In some cases, it could be automated, but that doesn't mean it's the same thing <lle-bout>lfam: for example, when adding a patch to a package, I spent most the time writing the commit message and with git <lfam>Okay, but how much time are we talking about? One or two minutes? <lfam>I think that the majority of the time wil be spent analyzing the problem, finding the patch, and making sure it has the desired effect <lle-bout>lfam: I never measured but it wouldnt surprise me if it's more <lfam>The case of adding patches to packages can definitely be automated <lfam>I have a little script that writes linux-libre updates Git commits for me <lfam>But, all these commit messages are exactly the same. "Add file, add it, use it" <lle-bout>I am thinking that why do we have to automate generating commits etc. Can't we find a way to make it easier all the time for everything instead of having to write scripts to automate the same kind of stuff in different ways. <lfam>Anyways, my point was that this kind of thing is a different type of work from programming. And thus should be treated differently. Maybe one takes a break before tackling it <pkill9>there is a commit template used in emacs <lfam>Well, certain types of commits are always the same (like adding a patch to a package). But other types of commits require some judgement from the author <lfam>I don't think we can discount this "human factor" <lfam>Remember, the commit messages are there to help other people understand what was done without having to read all the code changes <lle-bout>What I am saying in general is that I like to be creative, and I hate to feel like a robot <lfam>Yes, I understand. I don't think we disagree. That's what I mean when I talk about "different types of work" <lfam>It's why I often just handle this work on behalf of contributors, rather than making them do it <lfam>In fact, writing their commit messages can be an integral part of review. If I can't understand the commit enough to write a good commit message, then I don't understand the commit at all <lfam>I would say, it's fine to not want to do this stuff, and it's fine to ask other people to do it. It's also fine to work on automating it, to the degree that is possible <lle-bout>I like writing documentation but I hate feeling like I do redundant or robot work <lle-bout>I feel empowered to write documentation when I understand how things actually work fully <lfam>Do you have any ideas about how the workflow could be improved for you? <lle-bout>I am not sure, it's got to start from feelings when doing it, maybe I am not the only one having those probably, I am thinking creating some kind of yas snippet that uses s-diff or something would be huge help already. <lfam>It would be great to take advantage of s-expressions <lfam>So much information is available to the computer with a language like Scheme, and we shouldn't hesitate to use it <lfam>Really, a huge proportion of submissions need their commit messages rewritten, so there is a lot of room for improvement *lfam finds himself restoring a "proof of concept" Git repo from 4 year old backups <lle-bout>I feel like so many things conflict with the functional package manager idea in all Free Software that we spend time having to force it into the functional package manager model a lot, I feel like many theoretical problems are not fully identified and many workarounds are present in GNU Guix all over the place, when someone finds the Right Way to do something I feel like often it's not shared very widely even among committers. <lfam>It sounds like a FOSDEM talk :) <lle-bout>I am thinking we miss some kind of packaging guidelines document for many kinds of packages, other people have suggested it before <lle-bout>One recent example is the /stable thing, another is the GUIX_PYTHON_PATH thing, not sure what it solves, how are we going to incorporate it into GNU Guix <lfam>foo/stable should be documented <lfam>I'll write the docs when I deal with `patch` <lfam>pkill9: It's a way to deliver security updates for core packages, in situations that are not really graftable <lfam>It's something that requires some judgment about the security vulnerability, and some knowledge of how the package is used <lfam>The crux of the matter is that grafts happen after building, so they don't affect what happens while building <lfam>For example, there are some unfixed vulnerabilities in our package of the `patch` program <lfam>Now, they may not be exploitable in the build environment, because we control exactly which patches are applied, there is no network access, and the environment is sandboxed <pkill9>i assume something to do with malicious patches? <lle-bout>pkill9: To be less abstract for me, it's a mechanism that allows to discriminate between use during build and use by the end users, /stable package variants would be used by GNU Guix itself during builds where security is less critical, and the regular package would be used by everything else, this allows to reduce dependents of the regular variant so it can be updated freely without too many rebuilds <lfam>But, since `patch` is a core part of how all packages are built in Guix, we cannot just update the package as normal <lfam>Normally, we'd use a graft to deal with this situation <lfam>But, since the vulnerabilities do not apply to the bulk of the use cases, there's no point <lfam>Instead, we can leave alone the `patch` used in the build environment, and make a new package that you'd get from `guix install patch <lfam>It's important to fix what you get with `guix install patch`, since that is what a human will use to apply whatever random patches they find online <lfam>It's a very special situation in Guix, and we've basically ignored it in the past <lfam>The reality is that "applying patches" is a security disaster <lfam>It's only something you can consider safe in a situation like the Guix build sandbox <lfam>All of these original Unix tools are like that <lfam>But, we should still apply fixes as they are announced, despite the quixotic nature of the entire effort <lle-bout>I feel like the review process is confusing because the way reviews are handled differs from committer to committer and there's no authority document for best practices. <lfam>Hm, there are packaging guidelines in the manual <lle-bout>Otherwise without such authority document, the only way to gather such knowledge would be through reviewing but since reviewing varies from committer to committer you only get confusing information <lfam>The reality is that task requires judgment and discretion that can only be learned from experience <lfam>I don't think we should try to make a set of rules that a submission can either pass or not <lfam>Okay. I agree that the guidelines should be improved <lfam>There is a lot of implicit knowledge that Guix old-timers have in their heads <lfam>For texinfo, I just copy what's already there. If it builds, I figure it's okay <lfam>Texinfo has been identified as a barrier to contribution many times over the years, across all of GNU <lfam>The question of why GNU uses texinfo instead of HTML has been argued since HTML was invented :( <lfam>To be honest, I think it's a mistake to avoid HTML for this <lle-bout>I wouldnt find HTML better but I probably just need to learn Texinfo <lfam>Like, texinfo is fine. It is well-suited to the task. But it's a barrier, and it didn't catch on outside of GNU <lfam>I was reading these arguments from the mid-1990s recently <lfam>Well, at least HTML is popular <lfam>It lacks a lot of nice things that Texinfo has. Texinfo is closer to normal writing, by a lot <lle-bout>I can't write raw HTML in an efficient way for documentation, maybe Commonmark (Markdown) but that's it, or plain text <lfam>Plain text isn't really suitable, since it lacks the formatting capabilities <lle-bout>I like that Texinfo is a nice middleground between Markdown and verbose HTML <reily>ORG is a decent option, which can export to just about any other format, and is familiar to Emacs users, which I would image is a pretty decent overlap with Guix users. <lfam>I'm surprised Guix doesn't use org :) <lfam>It's surely because you have to use texinfo in order to be a GNU project <lle-bout>I don't think GNU Guix should adhere to GNU programming guidelines at all times, especially if those don't make sense to GNU Guix itself and it's contributors. <reily>Just export to Texinfo from org :p <lfam>Well... maybe you get your wish one day lle-bout <lfam>I'm not sure the dictatorial nature of GNU will continue for much longer <ryuslash>I like Texinfo, at least for reading, I haven't done much writing. I can't bring myself to write in anything other than org, though... I've heard good things about AsciiDoc too <ryuslash>although so far even org-mode doesn't have as nice a reading experience as Info-mode in my opinion :) <lle-bout>Additionally, I value that contributors come with their skillsets and that I feel like striving to make use of these skillsets without enforcing that those contributors learn too many things in a way that creates a barrier to contribution. <lle-bout>E.g. people not knowing Texinfo wanting to write documentation being barred, people not using GNU Emacs being barred because all tooling for GNU Guix exists only there and doing it outside of GNU Emacs feels like a nightmare often <lfam>I don't know, it's not a "nightmare" <lfam>It's definitely a situation of "give and take" between submitters and reviewers <pkill9>i like the idea of emacs but it feels like it has a steep learning curve <pkill9>but maybe I shouldn't be intimidated, i'v elearnt to use guix, lol <lle-bout>My statements are probably hyperbolic but I just want to outline the idea <lfam>I agree that there are barriers to contribution <lle-bout>I don't know how I'd do to contribute to GNU Guix without GNU Emacs that I had to learn specially for GNU Guix <lfam>I would call them "hurdles", which has less of a pejorative connotation <lfam>I mean, contributions require strong Unix skills, and medium Git <lfam>It's not unreasonable that people who want to contribute should know how to use a Unix system at the command line <raghavgururajan>I see texinfo as a meta-format, where you can then export to any different formats like html, pdf epub etc. <lfam>Ultimately, there are skills required to use Guix, and they largely overlap with the skills required to contribute <lfam>I'd like for Guix to be easier to use. We really need a package management GUI <lfam>But for now, it requires a strong grasp of command-line operation, things like enviroment variables, permissions, service management, etc <lle-bout>lfam: I think many things in GNU Guix can be done without a lot of knowledge and that's also really attractive for including more people within the project, but the barriers prevent it somehow. <lfam>I do see myself as exceptional in some ways, in terms of learning how to use Unix (it's been over 15 years) <raghavgururajan>> lfam: I'd like for Guix to be easier to use. We really need a package management GUI <raghavgururajan>+1. In far future, once I get good at programming, I am planing to do this using GNUstep. <lfam>I mean, even configuring services on Guix seems wizard-like to me <lfam>It's why I use Debian and enjoy systemd / journald <raghavgururajan>lle-bout: In Guix? No idea. I was looking at GNUstep one day and like it. <lfam>There's a lot for us to learn from systemd <lfam>I couldn't go 100% Linux until Debian adopted systemd, because service management was too arcane <lfam>Systemd really understand how to design a UI <lle-bout>raghavgururajan: I never saw any program use it <lfam>Systemd has complex areas, but the simple things are very simple <reily>ONe thing I really miss from systemd is being able to easily get logs for services <lfam>Integrated service management and logging <raghavgururajan>lle-bout: Not many software use GNUstep. If my attempt with it fails, then I might to turn to gtk. <lfam>It just works, the way you want <lfam>lle-bout: You should write your ideas out some more, before you forget them. Before you know it, you will have Stockholm Syndrome <ryuslash>speaking of things that are simple in Systemd, does Guix (Shepherd?) have any concept of user services? <lfam>You can run Shepherd as your user, but it's completely disintegrated from the system. There is not even a way to start your user's shepherd at boot <reily>You can run a separate shepherd service as a user. There are some utilities that attepmt to integrate this, such as guix-home, but they are still very alpha <lle-bout>lfam: It's difficult to transform feelings into precise factual problems <lfam>lle-bout: Feelings are valuable <lfam>You can just write your feelings <lfam>In the long run, we want this stuff to be as integrated and sophisticated as systemd. But, we have work to do <lfam>Guix is not an "anti-systemd" distro, by any means <lle-bout>About GNU Shepherd, the way I run it as my user is bad because somehow it's run with a different version of GNU Guile and all existing .go wont load. <lle-bout>I use .desktop autostart files but it does the same thing with .bash_profile <lfam>It doesn't happen for me, but I guess I update my user profiles along with the system profiles, at least for major updates like Guile <lle-bout>I also do that, I don't have anything in my user profile *lfam looks at their Guix System machine <lfam>Hm, my Guile is just /run/current-system/profile/bin/guile <lfam>How could it be finding some different version of Guile? I don't know <lfam>One of many problems that should be fixed before we can call it "user friendly" <lle-bout>lfam: it seems my GNU Guile is 3.0.5, and GNU Shepherd is compiled against 3.0.2 <lle-bout>I didnt do anything to get such newer GNU Guile <lfam>3.0.5 is the current version of Guile in Guix <lfam>But yes, sheperd depends on 3.0.2 <ryuslash>lle-bout: I don't suppose this is about uprading your guix daemon, right? (I'm not very knowledgeable about Guix yet :) <lle-bout>lfam: the shepherd script starts GNU Guile 3.0.2 <lfam>Well, my approach is very crude <lfam>Whenever the system reboots, I log in over SSH and do `[ -z $(pgrep -U $(id --user) shepherd) ] && shepherd` and then close that virtual terminal <lle-bout>but somehow all .go get rejected and basically starting GNU Shepherd means wasting time with stat etc.. at startup checking .go files then basically recompiling every guile object somehow..? <lfam>With systemd, it just works, and there is even `loginctl --enable-linger` if you want it <lle-bout>As Andrew Tropin said, we must get some PAM stuff to start GNU Shepherd at login <kozo[m]>May I have a 2nd set of eyes? I don't know what is weird about this command. If I remove --container it works fine. <kozo[m]>guix environment --container --network --preserve="^DISPLAY$" --ad-hoc firefox -- firefox <kozo[m]>guix environment: error: mount: mount "/home/guix" on "/tmp/guix-directory.yhqH8l//home/guix": Invalid argument *raghavgururajan thought it was cloned guix repo <kozo[m]>At least it's on the radar or smart people <lfam>I'm not sure which smart people you're talking about :) <lfam>We are all smart after we learn :) <lfam>And we all begin as babies! <lle-bout>Let's say people have varrying interests and obsessions which make them learn and be good at different things. <kozo[m]>So my other error was solved by exposing my Xauthority file so this works for me <kozo[m]>guix environment --container --no-cwd --network --expose=/home/guix/.Xauthority --preserve="^DISPLAY$" --ad-hoc firefox -- firefox <lfam>I wonder if we could copy that example, but use Icecat, to fix 47097 <lfam>I don't really want to focus on that bug... I hope someone else fixes it :) <kozo[m]>swapping firefox with icecat works for me. Fonts are messed but it runs <lfam>Somebody just hit that issue again! <lfam>And I marked the email as read and archived it again <lfam>I wish we would just hardcode some fonts and be done with it <lle-bout>lfam: I am thinking we need some better mechanism here, some kind of package parameters but better <kozo[m]>While on the topic of fonts If you are trying to use Duolingo with Firefox or Icecat, you need to use FONT-GOOGLE-NOTO <lfam>lle-bout: You mean for fixing Icecat's missing fonts? <lle-bout>lfam: and lots of other things, yes, fonts are some kind of external state which the user must provide or Icecat package shouldnt even install <lfam>Is that because noto has full Unicode coverage kozo[m]? Like, other fonts are missing glyphs for all the languages? <lfam>I think it makes sense for `guix install icecat` to give a working browser. However it's achieved is not as important <lfam>If it was a rare problem, I'd feel differently <lfam>But it gets reported constantly <kozo[m]>Not all the fonts, it specifically fixes Japanese. Though when looking for that answer, it sounds like it has knowledge of glyph type characters for Japanese and Chinese <lfam>IIUC, the point of noto is that it has *everything* <lfam>That is why it was created <lfam>It's like the corporate edition of GNU Unifont <lle-bout>/.icecat-real:75): Pango-WARNING **: 02:07:30.548: failed to create cairo scaled font, expect ugly output. the offending font is 'DejaVu Sans 9.9990234375' <lle-bout>After: guix environment --pure --container --expose=$HOME/.Xauthority --no-cwd --network --preserve='^DISPLAY$' --ad-hoc icecat font-google-noto hicolor-icon-theme font-dejavu -- icecat <lle-bout>I also get those: (/gnu/store/yww6abq4cly81a94ynirvql6rx3b22yg-icecat-78.9.0-guix0-preview1/lib/icecat/.icecat-real:336): Pango-WARNING **: 02:15:56.977: font_face status is: file not found <lle-bout>(/gnu/store/yww6abq4cly81a94ynirvql6rx3b22yg-icecat-78.9.0-guix0-preview1/lib/icecat/.icecat-real:336): Pango-WARNING **: 02:15:56.977: scaled_font status is: file not found <apteryx>rekado: by the way, thanks for the xpath clues you provided some time ago; they were used as part of the recent go importer update <apteryx>lle-bout: by the way, DISPLAY is already a precious variable in pure environments, so you don't need to explicitly preserve it <apteryx>see (guix scripts environment) for the full list. <PotentialUser-15>Hey, I'm trying to install Samba but whenever I run samba-tool, Python throws an error after failing to import the talloc module. Any advice? Brand new to guix, here <lfam>I don't know the answer to your question though. Stick around and I'm sure someone will have some advice <PotentialUser-15>All good, I managed to fix it by explicitly setting the PYTHONPATH environment variable ***iyzsong-- is now known as iyzsong-w
<Frosku>How can I set a /sys file's contents on bootup? (brightness for laptop) <BlackMug>can i request for free packages which can be added to guix ? like i send package request in guix bugs ? <BlackMug>(not me adding the package, just a request) <BlackMug>hmm yeah seems like that wishlist is like dropping the coin in the water and say your wish... <abcdw>long actions like delete-generations is a little missaligned in guix system --help, do we need to realign all other action's docstrings? <lfam>That would be great abcdw <abcdw>lfam, good, will send a patch. <civodul>mothacehe: what's the status of adding "dover" as an aarch64 build machine? <civodul>i see Andreas committed changes to the config, which looks like we're getting there, right? <mothacehe>he had problems with Cuirass package for aarch64 <mothacehe>but I "solved" them by disabling tests on this arch <mothacehe>seems there's a transitory fiber related issue <mothacehe>anyway I guess it shoud work now. The wip-dover branch also seems fine. <mothacehe>we just need to authorize the dover wireguard public key on berlin <mothacehe>civodul: about Andy's Guile read implementation: does this mean we can get rid of suspendable ports dance in Fiber? <wingo>mothacehe: the default ports implementation is still the C one, i.e. not suspendable <wingo>so you do need to "turn on" suspendable ports to get suspendable "read" <civodul>but read in Scheme means we no longer have to call read in a thread or whatever crazy thing we had to do in Cuirass :-) <civodul>mothacehe: one thing i'd like to do but i'm not sure we can is adding a "guile" jobset <civodul>it would track both the 'guix channel and the Guile repo (not a channel) <civodul>and the Guile repo would would provide a guix.scm file <mothacehe>civodul: mmh that's tricky I haven't thought about this use case yet <mothacehe>we could maybe have a new build type "package-from-git" that takes as argument a package name and a git url <civodul>mothacehe: maybe we just need a way to specify non-channel inputs? <wingo>or synthesize a channel from a git repo with a guix.scm <mothacehe>the new evaluation mechanism is built around channels <mothacehe>it does the same thing as "guix pull" roughly <mothacehe>yeah having an extra channel providing a "guile-master" package could work <civodul>non-channel inputs would trigger builds but wouldn't be passed to "guix pull"-y code <civodul>actually a 'guile-master' package isn't enough because it wouldn't be rebuilt when something's pushed to Guile <mothacehe>i need to think more about that, but that sounds like an important feature <mothacehe>unrelated: I fixed system tests with: fc37346f <mothacehe>we already have guix, tarball and images subsets at 100% coverage *civodul tries "guix weather -m etc/release-manifest.scm" <civodul>looks like we're missing cross-compilation jobs, like /gnu/store/76cz0iwrx9g5rpbplfvcg09aqi2ipql7-guile-3.0.2.drv (x86_64 to powerpc-linux-gnu) <civodul>hmm i can't locate the jobs corresponding to cross builds in the interface <civodul>also the .drv above is missing from berlin; it could have been gc'd, but it could be that it just wasn't computed <mothacehe>the jobs are sorted alphabetically in the dashboard, so its possible to find the powerpc jobs but very tedious <mothacehe>the search is operating on nix_name so we cant use it to find those jobs <efraim>I've only looked at it on my phone, if I hover with the mouse can I see what it is? <mothacehe>nix_name = "gcc-7.5.0", job_name = "powerpc64le-linux-gnu.gcc.x86_64-linux.x86_64-linux" <mothacehe>maybe I should add a filter input to the dashboard <civodul>mothacehe: through the search box i couldn't find it <mothacehe>yeah see the nix_name vs job_name explanation above <civodul>BTW, from an accessibility viewpoint, it might be best to use blue/red rather than green/red for the dots <mothacehe>yes! I expect it will be one of the conclusions of the accessibility report <roptat>finally got my DNS back up, but my server is still down :/ <roptat>it's my arm server, I tried booting older generations, but none of them works, it's stuck at "Starting Kernel..." <roptat>so I suspect something changed in u-boot that it doesn't like, because I kept all my generations from the first one, and none of them boots <roptat>now, I just learned that this message is from the compressed kernel wrapper that tells it's decompressed the kernel and is now running it <roptat>meaning that whatever u-boot did, the kernel probably doesn't like, whichever version it is <roptat>I believe it used to work with u-boot 2020.10, and now fails with 2021.01, but I can't guarantee, as it doesn't reboot very often <roptat>the server is at my parents' house, so I spent the week-end bugging them, and managed to make them install a foreign distro on the SD card (I still have the guix system on the disk) <roptat>so I have ssh access to the foreign distro, but I'm pretty sure if I just reinstall guix on the disk, I'll have the same issue again <roptat>found out that getting a serial console is very hard on windows... <civodul>perhaps vagrantc would know if something changed in u-boot <roptat>civodul, and at the same time my backup server (for email) crashed because of an hypervisor issue (a bug in qemu apparently) ^^' <roptat>it's up now, but since it was also my secondary for DNS, it couldn't connect to the primary to get the zone info, I'm just getting all the emails from the week-end now <BlackMug>how can i add my own repo to guix? i couldnt find that (tried) in guix manual <BlackMug>yeah like adding repo to debian you will add https repo to sources.list and add the key to it and done <BlackMug>fedora/dnf same thing if i remember correctly <roptat>BlackMug, do you mean substitutes for packages that are in guix, or for defining new packages that are not in guix yet? <roptat>that would be a channel, it's documented I think, let me find the page in the manual <BlackMug>ok , wonder why not guix using common stuff used by decades from main distros like debian fedora... <roptat>because it doesn't match our packaging model <BlackMug>no i mean stuff like sources.list , interfaces..etc <roptat>^ if you want to use an existing channel, instead of creating a new channel <roptat> sources.list is a mix of package definitions and substitutes for instance, we split the two concepts, so channels add more package definitions, and substitute servers provide substitutes for them <roptat>you define channels in ~/.config/guix/channels.scm (one per user), and you allow substitute servers with "guix archive" by allowing their public key <roptat>(and you can specify more servers on the command line and on guix daemon invocation, though it won't download anything that's not present on the servers you accepted the keys) <roptat>I don't feel like I'm being very clear ^^' <BlackMug>roptat correct me if im wrong: to have full upgraded guix one need to run guix pull , guix upgrade , sudo guix system reconfigure /etc/config.scm am i right? <brendyyn>There is no such thing as propagated-native-inputs? <roptat>brendyyn, no, I don't think it makes sense? <brendyyn>roptat the idea would be all dependant packages would have the native-inputs intersected <roptat>BlackMug, I'm not entirely sure which guix is run with sudo <brendyyn>i thought thats what propagated inputs did in addition to making them go in to the profile <roptat>I think it's correct, you could check with "sudo guix describe" it should tell you the same as "guix describe" as user <efraim>does anyone have a router os-config for guix I can use as a starting point? <roptat>brendyyn, oh, then propagated-native-inputs would not go to the profile, but it would still be propagated in dependent packages? <brendyyn>roptat is it not ok for native inputs to go in the profile? <roptat>BlackMug, then that should be correct :) <roptat>brendyyn, no, it's another architecture <roptat>that's why we keep build-only dependencies in native-inputs <brendyyn>in some cases its normal to have 32bit libs, like alsa pipewire. or is that the same "architecture" ? <roptat>I guess you could have 32bit libs (I don't think we do), but you need to specify that explicitely <roptat>native-inputs is for cross-compilation, you don't want armhf binaries in your x86_64 profile <roptat>civodul, any idea about "cannot pivot old root directory"? from inside a chroot? <roptat>found a workaround, apparently systemd was interfering <roptat>I see u-boot was updated, so I should be able to run guix pull now, and build with the newer u-boot <felipebalbi>does one need to be subscribed to guix-patches in order to be able to send patches? I've sent a patch several hours ago but still can't see it in the archives. <brendyyn>felipebalbi: no but if its your first time i think it will go in a queue to be checked for spam by a human. so maybe within a day itll go through the first time, and then you can post as much as you want <nefix>Hello! Is it possible to add services to a Guix env? <felipebalbi>another question: what's the correct way to ensure I have pdftex and texi2dvi as native-inputs for a package? I tried adding a package that requires it for building documentation, but it always failed with a permission problem on a file that was read-only. guix tried to write to it <roptat>felipebalbi, it can happen when it's from a git repository, the files are all read-only <roptat>you can add a phase to make them read-write, then you shouldn't have any issue <felipebalbi>roptat: thanks, I'll try to find out how to do that :-) <ekaitz>hi, i sent a patch a couple of weeks ago and I didn't get any answer <nefix>Also, does nix-import work? When I tried to use it, it hang and never ended <brendyyn>ekaitz: you might be able to simplify it by using #:configure-flags instead of setenv <rekado>ekaitz: this looks pretty okay to me. I’ll apply it in a few minutes with a few changes. <ekaitz>i tried extremely hard to solve it <ekaitz>but cmakeflags don't work as expected <rekado>brendyyn: oh, right, the cmake-build-system does have a knob for that. <ekaitz>rekado: i didn't find how to solve, if you give me some clues, I'll fix it <civodul>roptat: that error message must come from a failed pivot_root(2) call (in the daemon?), but i can't tell much beyond that <roptat>civodul, thanks, I found a workaround <rekado>ekaitz: I think you can use “-DCMAKE_EXE_LINKER_FLAGS”, but you don’t need to revise it. I’m working on it now. <ekaitz>rekado: I want to learn for the future, but it's fine! thank you for fixing it :) <rekado>nefix: the nix importer was perhaps useful in the early days, but in recent years I haven’t heard of even one successful application of the nix importer. I think it’s just broken. <rekado>ekaitz: some more comments: I would move the arguments field below the build system, because conceptually these are arguments for the build system, so mentioning the build system first feels right to me. <rekado>the unquotes (“,”) don’t need to align and it feels odd to do that <rekado>we don’t call things “open source” (or “free software” for that matter) in descriptions <ekaitz>ok! thanks, do you want me to fix it myself? <rekado>because all software in Guix is free software (or “open source”) <rekado>ekaitz: only if you want to do that :) <rekado>I don’t mind changing these things myself as part of the review <ekaitz>me neither, maybe it's faster if you do it, so I don't need to share it with you again and all that <terpri>out of curiousity, is it possible in practice to assign copyright to the fsf for guix contributions, despite it not being required? (one'd still get credit via the commit info after all) <rekado>but we can indeed avoid another round-trip by email ;) <rekado>terpri: I don’t know how that would work <terpri>rekado, same, i don't recall anyone trying it <rekado>ekaitz: what copyright line should I add to graphics.scm for you? <ekaitz>rekado: oh! I forgot it! There's my copyright line in engineering.scm already. <ekaitz>my nick is my actual name, so you'll find it <terpri>there are only 20 FSF copyright lines afaict, mostly copied files, patches, etc. <lubrito>cbaines_ I think I'm almost there, but I think that the code is not the prettiest. Can you see what I've got until now and tell me if I am in the right path? <lubrito>what could be a good way to share a screenshot of the current json output? <cbaines_>lubrito, hey, I can have a look a bit later, would be be able to email guix-devel@gnu.org with what you've got so far, and I'll take a look when I can? <rekado>ekaitz: okay, I’ll copy it from there. <cbaines_>For context, this is Outreachy and Guix Data Service related <rekado>ekaitz: nah, sorry for letting your patch sit in the queue for so long! You know how it is… :) <rekado>I’ll push the addition of openvdb in a moment (after moving away some commits I had been working on) <ekaitz>the Blender fix should be easier but it takes ages to compile... I had a good time with it <terpri>lubrito, paste a .ppm or .xpm maybe ;) <ekaitz>also, i'm currently updating freecad and guess what? ages to compile again haha <rekado>ekaitz: I’ll just trust you that it builds. I’ll leave it to the build farm to prove us wrong :) <rekado>ekaitz: you added libxxf86vm to the inputs; is that related to the addition of openvdb? <ekaitz>I checked nix package and they had that as an input <rekado>that’s … not sufficient to justify it ;) <ekaitz>let me compile it without it, maybe we don't need it <rekado>if you happen to rebuild blender anyway perhaps you could remove that input. <ekaitz>i'll do it now, so we'll know in half an hour :S <rekado>if it’s too much to build blender on your machine: we could push the commit to wip-blender and have the build farm work on it. <rekado>it may still be useful to add that input, but I’d rather add it in a separate commit with its own justification. <ekaitz>don't worry, i'll build it myself and I'll dig on blender docs to see if it's necessary <rekado>otherwise our future selves might misremember the reason to add it in a commit to enable the voxel remesher. <ekaitz>it's probably needed for video editing but nothing else <rekado>the openvdb addition is now pushed as commit f53ec9d99b <rekado>(FWIW: I use the blender sequence editor and hadn’t noticed any missing features there) <ekaitz>yeah, sometimes they are hidden missing things like the voxel remesher <ekaitz>it's only one specific option, if you don't use it you don't notice <ekaitz>but I need to find why is it needed <sss2>hi all, after recent update evolution do not see acounts (email accounts, dav accounts) <ekaitz>rekado: it looks like a basic dependency for blender that includes the XF86 video mode (which I don't know what it is) <ekaitz>it is compiling right now (20%) but the configure step said XF86VMODE was on even with the dep removed <ekaitz>maybe we are propagating it from other of the outputs? <ekaitz>in fact, there are some other libs missing from the list i shared <rekado>yes, perhaps it’s due to propagation <rekado>if it’s explicitly checked for then it should be an input. <rekado>but it would be better to put that change in a separate commit, because it’s really unrelated. <ekaitz>ok, I'll prepare a separate commit with all the libs that are supposed to be an input <ekaitz>when it compiles I'll confirm that the voxel remesher works without it <ekaitz>rekado: worked, so libxx86-vm not needed for the voxel remesher, sorry for the mess <ekaitz>i'll prepare a new (separate) commit with all the deps when this merge is done <kisaja[m]>Is somebody working on libreoffice 7.1, we now have 6.4 <civodul>roptat: are you done with changes to Guile-Git? i'd like to cut a release <civodul>i remember we discussed folders last time <roptat>civodul, right, I was having issues finding my way around the GC, so I can't do better than what I have on my branch <civodul>roptat: does your branch have additional things compared to 'master'? <civodul>mdevos: oops, my bad, i hadn't seen it <lfam>Does anybody know where the 'core' file is found on Guix System after a segfault? <mdevos>lfam: I don't ever have seen 'core' files on Guix System, even though I've seen a few segfaults <mdevos>I think you need to manually ‘enable’ core files somewhere <lfam>I don't know very much about this stuff... <lfam>`make update-guix-package` segfaults, and ludo asked me to send the core file <lfam>I don't know if it actually is dumping the core or not though <lubrito>hey, I sent an email to guix-devel@gnu.org but it didn't show up until now. I'm already subscribed to the mailing list. <lubrito>does the email have to be accepted or something? <mdevos>I think the first e-mail has to be accepted, but subsequent don't. At least that's the case for some other mailin lists; <myglc2>Hello! I need to run multiple octoprint (python) instances. Each uses 1 USB port. Suggestions? <myglc2>I'd like to make them part of the sys fig & have them run at startup. <roptat_>lubrito, it has to be reviewed by a human first, so it can take up to a day. Following emails will go through immediately <roptat_>(slightly more complex, but it runs a daemon) <apteryx>for security, is it better to run a service under its own user, or is 'nobody' good enough? <lle-bout`>apteryx: not sure if nobody is treated specially but basically different user offers better granularity for data directories and such, I am not sure if there's conventions for changing uid after starting and keeping file descriptions to things opened before, not sure. So in my opinion, it's better one user for each especially if there's data directories, then also all processes running under the same user can read each other's memory <lle-bout`>So if multiple services run under nobody they can read and affect each other's memory using SYS_PTRACE capability. <lle-bout`>There's no isolation between those services basically, in that case. <lle-bout`>A compromise of one such service means compromise of all other service's data etc. <mjw>dongcarl, sorry no. That is too long ago. <mjw>dongcarl, It might be that was on RHEL7 and it just had too old a kernel <dongcarl>mjw: I think you're right, I'm debugging for my colleague and he encountered the problem with 4.4 kernel, and it dissappeared with 5.0 <dongcarl>Perhaps someone knowledgeable knows what change between 4.4 and 5.0 Guix depends on for the /dev/pts bind mount... <mjw>RHEL7 is 3.10 btw. But has lots and lots of backports <dongcarl>Yeah... Smells like a kernel version problem to me :-) <apteryx>lle-bout`: I see, good points, thanks! <lfam>Do we have any "Git forge" type things packaged in Guix? <lfam>Like, gitlab, pagure, gitea <lfam>Or, at least work in progress? <efraim>Looks like all the gitea stuff I had I couldn't make work with a service <FennecCode>I'm having trouble installing MongoDB, and also having trouble even finding its service or package definition. Is it still available in Guix? <lfam>I see efraim. So you have packages, but not a working service? <lfam>I guess we should wait for the go-build-system overhaul before adding Gitea, in any case. But, I think we should consider prioritizing a "forge" package <lfam>FennecCode: We removed MongoDB recently. There were unpatched security vulnerabilities and the fixed versions are not free software anymore (they changed their license) <lfam>Or, could be added there <FennecCode>Shoot, that's awful. I had no idea they changed licenses. That's incredibly frustrating. 🙁 <FennecCode>I'm just running this locally on my machine for a class, so an old version with some security holes is actually good enough for my use case. I'll check that out. Than you 🙂 <lfam>You could always use `guix time-machine`. We will still have substitutes for this stuff, since it was only removed about a month ago <efraim>It was a while ago so I don't remember what the problem was. It works when launched through the shell script though ***jorts is now known as nckx
<efraim>Probably need to go through all the sources and figure out where it was calling random binaries in /usr/bin or something <lfam>Nix has a service for it, fwiw <lfam>We definitely need to overhaul the go-build-system before embarking on long-term maintenance of complex Go software, IMO <avalenn>lfam, I agreee. It is on my todo-list also but time is scarce. <lfam>Of course :) Time is the most scarce resource <civodul>lfam: the JS-heavy forges are more or less a lost cause <roptat_>lfam, not a forge, but I have gitile (which is down with my server :/) <civodul>lfam: because of the "JS dystopia", to quote dustyweb <lfam>You mean, Guix can't package them, because we can't package JS? <lfam>Like, from a practical perspective? <civodul>well, more or less, we can and do package some bits <FennecCode>lfam: How would I go about using time-machine for loading a service in my system config file? Would I point to the reference to a prebuilt package or something? I'm a little unclear on how I might use this for referring to a service definition that no longer exists... It seems like what I want, I'm just not familiar with how to use it 😅 <roptat_>we could, but we're missing some tooling to make it a bit more practical <roptat_>and it's not easy in terms of bootstrapping <FennecCode>Also, sorry to break up conversation. I just need this for class relatively soon. GitTea stuff is important 😅🙂 <lfam>FennecCode: This is crude, but I'd use time-machine for everything: `guix time-machine --commit=old -- system reconfigure /etc/config.scm` <lfam>Well, it leaves us without many options, right? <roptat_>civodul, that's older than my own attempt <FennecCode>Oh, yikes... Yea, I could just do that for as long as I need MongoDB, which is just a week or so <lfam>I think the FSF's insistence on "no javascript at all" is... misguided <lfam>FennecCode: Maybe you could use it to build a VM image for your schoolwork <lfam>`guix system image config.scm ...` <lfam>But, we should try to have something "in our pocket" in this regard <FennecCode>Ifam: Good idea! How do I invoke that with time machine, though? <lfam>`guix time-machine --commit=$old -- system image config.scm` <roptat_>FennecCode, you can invoke any guix command with the time machine, so guix time-machine --commit*... -- system image config.scm <FennecCode>This is exactly what I need! Thank you all a bunch 😊 <lfam>Don't hesitate to come back if you get stuck <civodul>lfam: it's more about our own (Guix's) will to build from source <roptat_>I noticed there's u-boot 2021.04 in guix now, so I ran guix pull on the server, it's still running, hopefully I'll be able to reconfigure before going to bed <lfam>I'm optimistic that we could do the work to our own standards with Gitea <roptat_>if that doesn't work, I'll reflash the foreign u-boot, reconfigure with u-boot 2020.10 and hope it works <lfam>I think any of us these options would be achievable for us, from a technical perspective ***cbaines_ is now known as cbaines
<roptat_>oh, also I got a new machine at work, and tried to install guix on it (foreign distro) <roptat_>although I'm pretty sure I said "yes" when it asked me if I wanted to use substitutes, it didn't add the public key to the acl <lfam>Hm... can you report a bug? <lfam>We need to look into this for the new release <roptat_>ah, I still had the terminal opened. After I typed yes, I got: /home/roptat/guix-install.sh: line 445: /root/.config/guix/current/share/guix/ci.guix.gnu.org.pub: No such file or directory <roptat_>didn't pay attention and went ahead with running guix after it told me everything was installed <lfam>So, the key was missing from the tarball? <lfam>That's the 1.2.0 tarball? <roptat_>yes: guix-binary-1.2.0.x86_64-linux.tar.xz <lfam>Hm, the file exists in the tarball's store, where it is expected <lfam>So, something went wrong creating the /root/config/guix/current directory... <lfam>Should have been /root/.config/guix/current <roptat_>indeed, when I used guix later, it told me it couldn't access /var/guix/profiles/per-user/roptat, and I had to create it myself <roptat_>so I can believe something went wrong in there <lfam>Well, that's the aarch64 tarball, oops <lfam>I don't see where the x86_64 tarball is... <roptat_>I can spawn a VM of a foreign distro later, and try that <lfam>I'm curious, does /root/.config exist? <lfam>Maybe the installer script assumes that ~/.config exists <roptat_>oh, it didn't exist when I ran the script <lfam>Hm, it does mkdir-p ~root/.config, more or less <roptat_>but I ran guix pull as root, so that might have created it <lfam>But, the rest of the path is missing? <roptat_>I used the latest version of that script <roptat_>and it's present in /var/guix/profiles/per-user/root/guix-current-1-link/share/guix <roptat_>actually on my first run of the script I got "[1618245242.243]: [ FAIL ] A previous Guix installation was found. Refusing to overwrite." <roptat_>that was because I had created /gnu to mount another partition on it <roptat_>I removed the directory and ran the script again, which worked except for the authorize thing <rekado>roptat: for my installation on an AWS EC2 instance I had to patch the script to be able to install into an empty /gnu (a mount point for a separate volume) <rekado>so perhaps we can make the script relax a bit and have it accept an empty /gnu directory <roptat_>so, I suppose it could not have had an effect, right? <reily>Hello, Im having a bit of trouble configuring elogind and upower on my laptop that is running guix system. The system reconfigures fine, but it doesnt seem like the configuration takes effect with regard to idle time (from elogind) and auto power off (from upower). the relevant part of my configuration is available here: https://pastebin.com/7samYmgS. Is there anything obvious I am missing? <reily>roptat: yes, I have tried several times. <roptat_>sorry, I need to go, if nobody can help you, you might have more luck sending an email to help-guix@gnu.org (it might take some time for a human to validate your message if it's your first time, but you don't need to be subscribed, and answers will go through immediately) <Lycurgus>i used nix about a decade ago and dropped it but am intrigued to find this <Lycurgus>is there a commercial interest that has glommed on yet, a la canonical? <lfam>Like, a commercially-backed version of Guix? As Ubuntu is to Debian? <lfam>Or, are there commercial sponsors of Guix itself? <Lycurgus>well a driver of commercial level quality, so such an entity actually using not just sponsoring <lfam>No, not really. There is a project called PantherX, but it's not "ready yet", if I understand correctly <Lycurgus>sponsoring can mean a check for a hunderd buck or permission to use a marque <lfam>There is some backing from the scientific computing / HPC world <lfam>Presumably it's a difference in how the sender's email client "quotes" things <hpfr>does mailman understand html email? <hpfr>I assumed everything was plaintext <lfam>Maybe someone else knows the answer <civodul>hpfr: you can send HTML mail and Mailman will display correctly in the on-line archive <civodul>that said, i'd recommend turning off HTML for mailing list posts <hpfr>yup I do, I was just curious how mailman did the blockquotes for some emails <hpfr>I bit the bullet and downloaded the mbox, turns out it's a plaintext email. I'm comparing it with an email that mailman displays with ">" now, mailman must use some kind of header encoding info to prettify these ***mood_ is now known as mood
<hpfr>ok, I'm 90% sure it does this to format=flowed emails. cool 😅 <rekado>I’d like to send format=flowed emails. Don’t know if mu4e can be configured to do that. *kmicu throws mu4e-compose-format-flowed at folks <morgansmith>efraim: Thanks for committing my patch! Is there a reason you didn't close the bug? (47325) *raghavgururajan peeps-in <rekado>now we just need to buy some build farm hardware (and figure out a way to host the machines) <nij>How does my emacs know where the package (fetched via guix) is? <rekado>via the EMACSLOADPATH shell/environment variable <nij>Does guix set that automatically for me? Or I should set it manually? <morgansmith>sometimes you have to log out and log back in because it does it in your profile but ya it should all be automatic <rekado>when the “emacs” package is installed in a profile then that profile’s etc/profile file should include the variable. <rekado>the usual GUIX_PROFILE=/path/to/.guix-profile followed by source $GUIX_PROFILE/etc/profile takes care of this. <morgansmith>How do we do the current build farm hardware? I'm very tempted to purchase some talos hardware for myself and I'm wondering if I could use it to expose some substitutes <nij>I tried to turn on my machine with guix to check.. but unlike yesterday, it doesn't load the GNU system correctly this time. <nij>... Unable to load firmware: rtl_nic/rtl8168g-3.fw (-2) <nij>Weird! It was working yesterday.. I wonder why. <rekado>morgansmith: build farm hardware needs to be accessible via SSH by the head node of the build farm; it also needs to run a service to be hooked up to Cuirass. <jeko>Adding (use-modules (gnu packages gettext)) to my package definition generate the following backtrace : <jeko> 586:29 19 (map1 (#<package emacs-flycheck-guile@0.2 gnu/packag…> …)) <jeko> 586:29 18 (map1 (#<package emacs-multiple-cursors@1.4.0 gnu/pa…> …)) <jeko> 586:29 17 (map1 (#<package emacs-magit@2.90.1-6.7f486d4 gnu/pa…> …)) <jeko> 586:29 16 (map1 (#<package emacs-ggtags@0.9.0 gnu/packages/ema…> …)) <jeko> 586:29 15 (map1 (#<package emacs-projectile@2.3.0 gnu/packages…> …)) <jeko> 586:29 14 (map1 (#<package guile-readline@3.0.2 gnu/packages/g…> …)) <jeko> 586:29 13 (map1 (#<package guile-colorized@0.1 gnu/packages/gu…> …)) <jeko> 586:29 12 (map1 (#<package guile-hall@0.3.1 gnu/packages/guile…> …)) <jeko> 586:29 11 (map1 (#<package guile-spec@0.1.0-4.7524b6f jeko-pac…> …)) <jeko> 586:29 10 (map1 (#<package git@2.31.1 gnu/packages/version-con…> …)) <jeko> 586:29 9 (map1 (#<package nss-certs@3.59 gnu/packages/certs.s…> …)) ***ChanServ sets mode: +q *!*@2a01:e0a:25f:d8f0:90e2:9613:c656:d1f
***ChanServ sets mode: -q *!*@2a01:e0a:25f:d8f0:90e2:9613:c656:d1f
<nij>Ooops.. retried many times. It seems that my machine with GUIX dies. <nij>It was running ok yesterday. But now it's stuck after "This is the GNU system. Welcome." <jeko>I guess I can't delete my message ? 😶️ <rekado>nij: failing to load firmware (blobs?) should not be fatal <nckx>jeko: You can't delete IRC messages. It's not a big deal, but use a paste site next time :) <morgansmith>rekado: what kind of upload would one need to be useful? I've got 15Mbps. I could ask my boss to put it at work though maybe. Also how does trust work? Do you just rely on people challenging the server? <nij>rekado: I dunno. It's stuck there, and didn't proceed. <lfam>nij: What kind of computer is it? <rekado>morgansmith: I have no idea about minimum network requirements. I don’t think it matters too much to be honest. <nij>It's a lenovo B50-80. <rekado>nij: if you hit return a few times do you see a login prompt? <lfam>jeko: Maybe a module import cycle? <nij>Problem solved.. so what's that problem? <rekado>did you expect a graphical user interface? <rekado>I have spent some frustrated hours with gdm failing to start. Perhaps that’s what you’re experiencing. <jeko>lfam: something like gettext requires a module I imported which also requires gettext? <morgansmith>rekado: are substitutes provided to users by head node or by the machine that built it? <nij>I started with a bare-bone template config.scm. <nij>And was careful not to add any graphical UI stuff <morgansmith>rekado: sorry if I'm pestering you with questions :P is our setup well documented somewhere? <rekado>morgansmith: the head node orchestrates the builds and serves the substitutes. The builders need to provide the build results. <lfam>jeko: Yes, perhaps something like that <rekado>morgansmith: it’s documented in the sense that our infrastructure is code. <rekado>berlin.scm is the head node at ci.guix.gnu.org <morgansmith>rekado: oh ok. So upload wouldn't be an issue. Now I'm just wondering about trust. Like if I did start making substitutes for you guys, would you accept them? <nij>How does guix work with common-lisp packages? <nij>Usually I'd just `ql:quickload` a package. <nij>But that doesn't work on guix cuz the cl-packages aren't installed in the default folders. <jeko>lfam: Ok, I will look after something like that <rekado>morgansmith: I fell out of the loop and no longer know how the current incarnation of Cuirass handles builds, so I can’t answer the question well enough. <jeko>lfam: thanks for the clue <lfam>morgansmith: The question of trust is handled as you'd expect, on a case by case basis <nij>So.. anyone knows how to use ql:quickload properly in guix? <jeko>is there a way to populate a Guix image with pre-defined files (emacs conf, scripts)? <jeko>oh I can see skeletons in the reference ! <rekado>jeko: the special-files-service-type could be used for that. <rekado>nij: I don’t use Common Lisp, so I can’t help with that, I’m afraid. <morgansmith>so I see a few mentions of gradle here and there but I couldn't find a definitive answer. Do we not support gradle because it can't be bootstraped? I honestly don't know what gradle is. Just want to build a package :P