<civodul>maybe c45477d2a1a651485feede20fe0f3d15aec48b39 or something close inadvertently turned on deduplication
<civodul>so in (gnu system vm), we could pass #:deduplicate? #f to 'root-partition-initializer'
<apteryx>rekado: I got what I wanted with a mix of --ProfileManager --new-inst (configured new profile), and now I can start it using icecat -P mynewprofile (even if the original profile is running). Nifty!
<tune>I was thinking of getting into emacs, but I don't know if I'm ready just yet, so I'll check out claws. Thanks for all the recs.
<buenouanq>I too am not yet cool enough to do email through emacs - Claws-mail is great.
<janneke>sneek: later tell civodul: i am making some progress with wip-bootstrap; i found the bug that caused the weirdness i saw: a depedency on non-bootstrapped linux-kernel-headers. now added a linux-libre-headers-bootstrap tarball too
<ngz>Hello. I'm having trouble with Guix environment variables in a foreign distribution (Debian Buster) using Gnome (Wayland). Logging through GDM doesn't let me enter Gnome session. I have to rename .profile to .profile_bak or some such so I can log in. But then, ~/.guix-profile/etc/profile is not sourced.
***rekado_ is now known as rekado
<rekado>ngz: this is probably a problem with the XDG_* environment variables.
<rekado>GNOME looks up binaries in directories on XDG_*, but they might be incompatible.
<wigust>sneek: later tell ngz Try instead of unsetting - set them to what they were before sourcing ‘~/.guix-profile/etc/profile’ . For me setting XDG_CONFIG_DIRS and XDG_DATA_DIRS after sourcing  works.
<sneek>civodul, janneke says: i am making some progress with wip-bootstrap; i found the bug that caused the weirdness i saw: a depedency on non-bootstrapped linux-kernel-headers. now added a linux-libre-headers-bootstrap tarball too
<novaskell>Hello, I was wondering if it's possible to direct the grub-efi installer to use x86_64-efi correctly as i386-pc seems to be missing (I may also lack an understanding within this area) on my install media generated using the default gnu/system/install.scm.
<novaskell>I have tried legacy boot but it sadly doesn't seem to work at all for my x220
<janneke>the auto* implementation of the gnu build system really sucks, at least for developers
<janneke>it's beyond me how we created such an atrocity
<rain1>I think the idea of entropy that OriansJ raised is the key
<OriansJ>janneke: I think civodul is expressing, although the source code is available under a free license, the net desired freedom isn't obtainable because the build information required still needs to be collected and stored
<rain1>the inputs should be sealed off in such a way that it is clear what will be conditioned upon
<rain1>and the compiliation procedure would ideally be a function of these inputs (like a reproducible build)
<OriansJ>Aka source code without the required build information is effectively useless, like Haskell source code without a Haskell compiler
<ng0>I'm currently packaging one of the oldest OTP releases and the perl + other dependencies which where out back then.. having to reconstruct environments is not fun.
<janneke>most of us know that you should never patch .ac or .am, but always patch configure or .in
<janneke>because "you can never expect to regeerate
<janneke>that's just terrible...and we keep on doing this
<janneke>in theory, guix could solve this by providing auto* packages for all possible configurations
<OriansJ>janneke: that is because the pain of history hasn't been experienced by those who most benefited by their toxic choices.
<janneke>i haven't seen any effort towards that direction
<rain1>i hope we don't make janneke late... we can always pick this up another time :P
<OriansJ>Much like how companies used to dump toxic waste in streams, todays build processes need a green revolution
<mbakke>Wait, why doesn't Hydra have substitutes for 'libinput' on master?
<ison111>I have a rather trivial package for SpaceFM that I'm thinking about contributing. I understand that I would send it to the mailing list but who maintains it after that (just updating the version number and hash I assume)? If it were accepted should I then keep an eye out for new versions and submit a new copy to the mailing list, or is it maintained in some other way?
<amz3>ison111: no one is assigned maintenance duty
<amz3>ison111: there is no maitainer per package if that's what you meant
<amz3>ison111: how did you solve you issue regarding playing videos in google doc?
<ison111>amz3: Oh, I still haven't resolved that. I suspect it's just a special case involving the custom script required to play videos from google docs on cytu.be.
<ison111>amz3: But thanks for the info on submitting packages. I didn' have anything specific in mind, was just looking for info. I wasn't sure if there could be some automated way they check for updates and automatically grab the new hash or anything like that.
<amz3>ison111: iirc there is sub command of guix that can check for updates
<amz3>ison111: but it still requires to commit the change and submit the patch
<ison111>amz3: Well like I said the package is fairly trivial. I just want to do things in the standard way. So when there's a new version do people typically just resend the package to the mailing list then?
<jlicht>ison111: usually, yes. After some time, if you feel like it, you might be offered (or simply ask for) commit-permissions to the repo, after which you can directly commit the more-or-less trivial package updates to the relevant git branch.
<roptat>amz3: ison111: guix refresh is helpful to find new versions
<roptat>but it works only on a subset of our packages
<ison111>jlicht: Is there any special formatting I should use for the email subject or body? Sorry for the simple questions, I've never submitted a package before.
<jlicht>ison111: don't worry, everyone had to sent their first patch at one point :)
<jlicht>but you can also simply send the patch as an attachment in a normal email to the mailing list. The commit message format used by the guix project is similar to ChangeLog, and a bit verbose, but you should be able to check the git log for other examples.