<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
<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
<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.
<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>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
<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.
<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 ^^'
<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
<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”)
<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
<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`
<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?
<roptat_>sorry, I need to go, if nobody can help you, you might have more luck sending an email to email@example.com (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
<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.
<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.
<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