<leoprikler>Well, that's to be expected given a project that had its last update four years ago.
<leoprikler>Guix uses a specific commit in Guile to not break things for guile-emacs
<nckx>dftxbs3e: What you describe sounds like a free side-effect of moving substitutes to a content-addressed, distributed network like GNUnet (or IPFS), right? That does excite me in a way that an ad-hoc approach with hard-coded servers really doesn't. Sounds like we both want to end up in the same place.
<alextee[m]>shouldn't guix have an /etc/os-release file too?
<nckx>dftxbs3e: I'm looking at your patch. One thing that immediately struck me is that you compare a string the value of boot-triplet, which is a procedure: everywhere else you'll see it applied (‘called’): ‘(boot-triplet)’.
<nckx>And yet I assume you've tested this and it worked?
<nckx>Colour me slightly puzzled but also very tired then 🙂
<snape>dftxbs3e: things that are unreproducible have different outputs, but they have the same hash, because the hash is made of all the input hashes
<leoprikler>so in the GNUnet case you can get two directories with the same name but different contents
<leoprikler>and you'd have to hash over the contents not knowing which one is correct
<snape>so when someone publish something that isn't reproducible, you can't see it just with the hash (which only represents the inputs), you have to compare its output with another same-hash build
<nckx>Blackbeard[m]: The fd.o ‘desktop directories’ were obviously dreamt up in a monolingual bubble. I had to symlink 下载 to Downloads after a month of never quite realising where my important download had gone when I needed it.
<nckx>leoprikler: I'm not arguing against translation, and I think that accents breaking things are just bugs in the things, not reasons not to translate things. Those programs would break on any home directory in 2019, Blackbeard[m].
<leoprikler>Nautilus by comparison has: A header bar indicating the current location, buttons for the most important tasks, and a menu with things you will likely need, that can't necessarily be put neatly into rememberable shortcuts.
<leoprikler>I tried Emacs without those bars, but it still isn't visually pleasing to me.
<leoprikler>meanwhile I've programmed a music player with a Guile REPL (the code for which is very ugly and likely won't work on Guix), that has a header bar and I find that very pleasing
<nckx>Silly question: does emacs insist on flashing disabled menu bars in your face for six picoseconds when you start it too, or is there just something wrong with my configuration?
<leoprikler>I think Emacs 26 starts the GUI before loading your init.el
<leoprikler>In Emacs 27 you might get your config running earlier.
<nckx>That's the 3rd time this year I've been that 27 will be my lord & saviour.
<efraim>start to finish, with time off, i took 8 months I think for aarch64
***Server sets mode: +cnt
<janneke>efraim: i could not have done mes without the amazing help and love from #bootstrappable and #guix
<elais[m]>Has anyone gotten qmk to work in guix? It doesn't find an avr library when I try to make a keyboard
<peanutbutterandc>On a Debian 10.2 machine, inside my guix profile, I have install guile-gnome and am trying to play around with it. However, I get the following error: no code for module (gnome gobject). Yes, I have $ eval `guix package --search-paths=prefix` as well. Any ideas as to why it might not be working?
<valignatev>Hello everyone! I've installed fish through guix on a foreign distro (Arch) and now I want to set it as my login shell. Unfortunately, "which fish" is a $HOME/.guix-profile/bin/fish which is a symlink to the actual executable, and I can't just "chsh -s /home/user/.guix-profile/bin/fish user" because if I do this, I won't be able to log in later. An
<valignatev>d I don't feel like putting an absolute path to store is a good idea because I'll have to update it every time I update fish then. Is there some more elegant approach?
<alextee[m]>it basically contains all the packages in a zip and the installer just chooses which one to install and what command to run based on the distro... idk if there's better ways but this is much easier for me than having separate installers for each distro/architecture
<leoprikler>and you can create SquashFS/Docker images if you don't like tarballs
<jlicht>valignatev: you could try something like 'exec fish' in your .bashrc
<jlicht>that way, all your interactive shells are replaced by a fish process, while all your existing scripts should still work
<valignatev>I really want to use fish as my login shell, not as my user shell
<valignatev>That's why I don't have "all my existing scripts" in bash :) In fact, I wan't as little shell configuration as possible, that's why I go with fish in the first place - it allows me to have only 3 lines in my fish.config
<zap>valignatev: or is it possible to make some kind of system profile and edit /etc/environment PATH
<alextee[m]>leoprikler: thx so much for the info! never tried squashfs but sounds usable in this case
<zap>valignatev: Ive been using fish for long time but bash domination subdue any resistance
<zap>fzf + bash actually quite fine. But I still miss autocompletion from manpages
<valignatev>I start to feel the same way, but haven't given up yet. In Arch I feel like fish is the first class citizen. I understand that guix only recently got sort off decent fish support through fish-foreign-env. And I want to play with it more
<valignatev>zap: Yeah, I've noticed it as well. fzf definition have to be improved with installing man pages and shell keybindings. I'll try to do this if I have time next weekend
<zap>valignatev: cool post it on your github then (`/valignatev` is yours right?) :)
<valignatev>right :) If I pull it off, I'll definitely submit the patch upstream. Now I worked around it by just manually dropping fzf_key_bindings.fish into a fish shared functions in the /gnu store
<zap>valignatev: didn't get your last message. There is go-github-come-junegunn-fzf package. And it has these files in .guix-profile/src/github.com/junegunn/fzf/shell/ if it is in your profile
<valignatev>So instead of sourcing the file manually, you let fish know about it. To be honest, I see that some people wouldn't want fzf_key_bindings appear in their global fish namespace, that's why I'm a bit hesitant. I wonder what's guix philosophy about it
<zap>yes good point. There are mitht be multiple package outputs
<valignatev>Manjaro is like at the second place on distrowatch
<zap>well... Lots of arch people mix their system administration and development environment space and never get to learn how to manage their stuff while convincing themselves being hardcore
<zap>Because you can aways pacman -S or yaourt something
<zap>Ive been arch user for a long time know it from the first hands...
<valignatev>Oh yeah, I agree. You don't have to tell me that all my python virtual environments get rekt after system python upgrade or how I can't compile something if it requires autoconf version that is different from the system one :)
<PurpleSym>civodul: Following up on --with-graft: What’s the recommended path to replace an existing package (in the guix channel) with one from a different channel?
<PurpleSym>(Not just for one particular `guix install`, but “globally”.)
<rockandska>are those distinction is done with `guix gc` ( clean all build dependencies) and `guix pack` (don't include build dependencies) ?
<nckx>rockandska: Not really, although native-inputs vs. inputs comes close. The build-time vs. run-time decision isn't left to humans: all inputs are available at build time, and whatever remains embedded in the result is the run-time closure (visible as ‘guix gc --references $package’).
<rockandska>the last time i try to pack bash with docker, more packages was inside the docker mage ( bash-minimal, and more)
<nckx>I don't think you understood. What you describe as ‘build dependencies’ won't be embedded.
<nckx>rockandska: That's because bash-minimal could be called at run-time, because your package retains a reference to it. If bash is only used at build time, your package shouldn't keep that reference and bash won't be packed.
<rockandska>nckx: why bash need to use bash-minimal after the build ?
<snape>ishmael: and does it contain a lot of references to /gnu/store?
<nckx>More seriously: libgcc_s is probably not part of ‘gcc’ on other distributions, maybe some opaque ‘base-runtime’ package, but that's just a packaging decision (that could be changed to create smaller images). None of this is a bug or flaw in Guix. In fact, I think it's the opposite.
<ishmael>snape: not /gnu/store, only my profile (as it should, right?)
<ng0>nckx: even here it requires lterminfo.1, lc.12, and lintl.1 in the end.
<snape>Yes, yes, sorry. but it contains references to each emacs packages you installed?
<rockandska>nckx: thanks for your feedback. i'm curious and will take a closer look later because it will be really great if the docker images generated by guix had more or less the same that the dockerhub ones
<nckx>rockandska: Thanks. 80 MiB is smaller than any Docker image I've ever seen, but I'm sure we can do better. There's always a trade-off between micro-managing split packages for size, and developer sanity.
<nckx>bavier: EMACSLOADPATH was completely overhauled, I think twice even.
<nckx>rockandska: I should clarify that while ‘gcc-5.5.0’ shows up in that list I pasted, it doesn't mean that bash depends on the compiler collection. ‘gcc-5.5.0-lib’ is ‘only’ 37 MiB, it contains ‘only’ the GCC run-time that every C executable on GNU *needs* to run.
<ishmael>snape: well i did multiple times, to no avail, i'll try restarting today
<nckx>rockandska: You can see that >80% of ‘bash’ is just the glibc and GCC run-times. There's no build- vs. run-time ‘mistake’ that needs fixing at all. The packages are just (too) big for a minimal use case.
<rockandska>nckx: bash itself is around ~6MB + readline 1.4MB, i don't get how they could delete libgcc / gcc in their docker image
<kmicu>I saw that too many times. Copy‑pasting w/o understadning is very fashionable thing in this modern age :)
<nckx>rockandska: Sometimes hashes are retained in the output for no reason, for example because the build system is a bit weird and saves an irrelevant environment variable containing all inputs in the executable. These things do happen, and they are a bug, and they are fixed when found (which is usually easy). But they don't imply a design flaw in Guix.
<snape>rockandska: e.g. a software I worked today checks in 'git' is in the PATH. If it is, it builds the BUILD_VERSION #define based on the output of 'git describe'. This is clearly something optional that could be removed at packaging level
<nckx>civodul: Wasn't it decided that keeping the ref scanner fast was more important than (say) a pluggable system for .jars, UCS-42, and Everything?
<kmicu>No worries, it’s good to discuss those to clarify things.
<kmicu>Countless discussions on #nixos exist about putting pkgconfig and the rest in regular inputs. That stuff is not very familiar if we don’t have a build machine or do not crosscompile.
<nckx>‘Build inputs go in native-inputs’ is a great rule of thumb because it's almost always the right thing. Problem is people then erroneously infer that ‘native’ is Guix-speak for ‘build’ and that's hard to beat out of 'em later
<kmicu>It’s good to make the biggest closures slimer from time to time (I’m looking at you LaTeX) but otherwise shaving few megabytes is not very productive thing to do.
<kmicu>(There are long topics (on nixos ml) about renaming ‘native’ but ‘native’ makes sense if we have more than one computer or from a sysadmin prespective.)
<nckx>Things like rock's just-bash-as-a-Docker-image spectacularly bring out the edge cases (‘>80 MiB for bash‽’) but on any real system *everything* depends on glibc+gcc-lib so their cost per package is completely insignificant.
<kmicu>Native input is like a monad, it’s just a burrito in the category of endobuilds.
<nckx>kmicu: Rename it to what? Don't say build don't say build
<nckx>I also wonder what makes it so stateful but I could just look that up.
<leoprikler>I can feel you. I still have a Gentoo machine up and running but almost never updated it since this one switched to guix.
<leoprikler>Guix and eix both ending in ix doesn't really help things either… try eix package -u and you'll be surprised.
<kmicu>I installed it on ARM box to later assimilate it with Guix System :)
<kmicu>With Guix System i have system.scm with Arch I need to note everything in org-mode and execute it block by block when something is broken and I need to start over.
<nckx>I'd basically re-implemented Nix (badly!) in bash on Exherbo before I switched to Nix. Arch reminds me of the bad old days, but OTOH is the only Major Lunix Distroe that I've never tried. Wonder what I missed.
<nckx>kmicu: I just want them to go away. Please find an unfixable freedom issue kthx.
<ishmael>is Thunderbird considered not-copyleft by Gnu? I'm confused about this
*kmicu dreams about Guixverse where folks update Guix Packs and we can use them if we trust authors. That way we could avoid compiling a browser and use nckx’s one instead.
<nckx>ishmael: I think the current hurdle is actually packaging it. If there is a redistribution issue it's probably related to the Mozilla trademark policy (the same thing that gave us the name ‘IceCat’). However… didn't Mozilla dump Thunderbird as a subproject?
<jonsger>nckx: I have some preliminary package "definition" for Thunderbird, but it's not working
<kmicu>leoprikler: more like I built my minimal Emacs version, I sign it with my keys, I publish it to Guixverse, if you trust me, then that package is visible in your guix package search and you can install it. All hassle free.
<nckx>kmicu: Sure, I guess. https://guix.tobias.gr has at least 3 caveats: 1) it's still catching up from my own RAID failure 2) it's affected by the same TLS disconnection bug as ci.guix ATM 3) I have no idea if the weather's any good because this breaks ‘guix weather’. Hope to fix all that soon.
<kmicu>Even something simple like Guix Register so a place when we can discover channels.
<nckx>I really dislike all of these centralised + push-based GuixHub suggestions but am unable to formulate my superior alternative. This irks me greatly.
<kmicu>For me it’s only about sharing packages to avoiding compilation and help environment a little bit.
<leoprikler>I think letting people discover your channel through search engines/social media is a better idea than hosting e.g. channels.guix.gnu.org
<nckx>Same, but I'd like to see a sig/key-based WoT layer on top of decentralised substitute distribution.
<leoprikler>If you want to share your own flavour of Emacs, you'd have to come up with a package definition and a channel for said definition.
<kmicu>Or share a Guix Pack but that’s an implementation detail.
<nckx>So guix.tobias.gr is: domain-name → nginx → guix publish → /gnu/store ← guix building stuff.
<nckx>If you drop/replace the first two steps with, say, GNUnet or IPFS or whatever else I know too little about, we're already close to what I'd prefer to see.
<kmicu>So to use your subs I need to be on the same Guix version, is that correct?
<nckx>Every user (who opts in) publishing their store, signed by their key, other users trust these keys and The Network connects you.
<kmicu>I can create an Emacs package, sign it and publish it on my site. But adding it to ELPA makes it visible in your Emacs w/o any work from you.
<nckx>kmicu: You don't have to be on the exact same commit but you should be guix pulling regularly, following master. It's built for me & how I use Guix; as noted there it's not an archive of older builds. If someone updates icecat 3 times on master today, g.t.g will ideally only build the latest one and never even schedule the older 2.
<leoprikler>kmicu: Adding your package to guix would be contributing to guix in some way (e.g. through patches).
<nckx>kmicu: We should (and I was just as guilty above) be very clear about what you mean by ‘package’: just the Guix (package …) expression? Or the resulting binary substitute? We really can't distribute the latter, because there's no way to audit those.
<leoprikler>Adding your package to ELPA might be different, but I don't think you can just push it there without any checks.
<nckx>ELPA is a dangerous metaphor because there's no wildly different one-way binary artefact to build.
<nckx>kmicu: That too. It builds my custom (but not yet public) channels. For example, it includes Nicecat, which is a shitty trivial IceCat fork that nobody should want 😛 But unless you have my channel source, you won't have the hash to ask g.t.g for the binary.
<kmicu>leoprikler: ELPA was just an example of a modarated registry. Nothing more.
<nckx>TBH we're so understaffed as-is, ‘any blatant copyright/FSDG violations will be caught by moderation’ makes me nervous.
<kmicu>Thank you nckx: and what I want is a registry when I can use your NiceCat (Guix Pack).
<kmicu>jlicht: Basically I go to a Guix Registry, search for NiceCat from Tobias or EmacsSansGTK from me and run it on Parabola. Done. Links to corresponding source code are provided so you can build them from source if your want.
<kmicu>But let’s wait for more folks providing custom builds before we take above seriously.
<kmicu>(And btw that Registry can be operated by community like AUR, not maintainers)
<nckx>jlicht: Not trying to be pedantic, but there can be a spectacular difference. Me giving you a substitute for Foo implies you have the Foo package expression (probably through a channel), and I'm just saving you time. You're fully empowered. Publishing Guix Packs to PackHub is just a blob dump (and a dump it would IMO be). Here's a thing, you can run it, I made it this way, probably, who cares? Are you a hippie? And this isn't just my pessimism; it's already
<jlicht>so any service that prevenst you from easily reverse the mapping from subs ( or -> packs) back to packages could have the issue you described?
<kmicu>drvs is not the source code so I think yes.
<nckx>Substitutes give us a way to *technically enforce* ‘giving the corresponding source’. The source doesn't actually correspond? You won't find the substitute by hash. There are some cool implications. Maybe. Maybe I'm just trippin'.
<nckx>jlicht: The mapping isn't unreversible now, and I don't think that's a requirement (I can still give you a .narinfo URL and you can download the substitute it points to without having the source). But somewhere along the spectrum from that to PackHub, where packs are no longer content-addressed, something real is lost, and not in a hippie sense. Just not sat down to figure out what yet.
<nckx>kmicu: It's not about getting your binaries only from trusted sources. Sorry if I made it sound like that. It's making the binaries first-class addressable elements without the source.
<nckx>I *really* have to get back to work, sorry for getting off a tangent I helped start 🙂
<kmicu>[jokin’] It's a 3 letter organization! Belgian sigint op probably.
<nckx>Something like that. I've done some pretty weird things (‘…man’), it's a very obscure ref to some of them, deliberately so. I only noticed the obvious λ in there after I put it up. 't Was meant to be.
<pkill9>i wish all websites had progressive enhancement
<kirisime>civodul: If you count simple suggestions as help, I think the package list could be split into fixed size sections so that instead of having pages like A, B, C... you'd have A - AL, AM - AZ, B - BU...
<kirisime>So I wouldn't need to go through ten pages of python-* to find the right python package.
<nckx>Wouldn't the sections change constantly? Or is that the point?
<kirisime>They would all change as soon as one package is added, but finding the section where each package is would be a matter of clicking a single link rather than picking the first letter and then seeing that there's thirty pages, of which half are all cl-something when you jump to the middle.
<nckx>I'd like something linkable, e.g. http://guix.gnu.org/packages/ghc-abstract-deque . It almost embarrasing to send a ‘your package is now in Guix!’ mail or patch upstream and not be able to actually link to anything. I think this used to be possible, long ago, or at least the /a links were sane and had all a packages on them for C-f to find.
<nckx>kirisime: OK, but let's take python as an example. You'd still have multiple py* pages, you'd still have to choose a number.
<kirisime>You wouldn't need to guess since the bounds are clearly stated in the section and all you need to do is see if your package's name is in the range given.
<nckx>I'd agree if the section names weren't limited to 2 letters.
<nckx>(I'm pro-hugepages without any numbers, just a big list & let your browser do the searching, but that doesn't seem to be the consensus, which is fine.)
<kirisime>nckx: You'd end up with something like P - PT, PY - PYTHON-AL, PYTHON-AM - PYTHON-AZ...
<nckx>OK, I didn't get that from your limited example above.
<civodul>i agree that being able to link to specific packages would be an improvement
<kirisime>Then take the last and first names, compare them to the last and first names of the previous and earlier groups, and cut them where they first differ...
<nckx>Yeah, I think we're describing the same thing.
<kirisime>It would require the whole website being regenerated whenever a package is added, but it would make finding packages without a search bar much much easier.
<nckx>The reason this is somewhat more complicated than it might seem is that it has to work as a static collection of pages. We can't do the obvious /package?start=ghc-something&n=20, with a link to /package?start=$<last entry +1>&n=$n at the end.
<nckx>kirisime: But that's how it already works, it's a static site generated hourly.
<kirisime>Also, to make special sections so that you don't get pages that have python and non-python packages, or packages starting with the same first letter, split the list based on the groups, do your thing on each group and then list them one after another in the final grouping.
<kirisime>I have nothing packaged for it though, maybe later. This system suffers greatly from patial upgrades because all good software comes from openrepos and when the os updates your python deps are gone.
<kirisime>nckx: Where would I start with the port? I sort of like this system but it has some proprietary parts to it that I don't think I'd get working on a libre system and since it's my only phone I don't want to render it dysfunctional for even a minute.
<kirisime>Or if there's someone who wants to try and can swap phones, let's do that.
<nckx>TBH I don't think porting is a good idea under those constraints.
<pimi>hello guys I am little Guix noob, I create a package, how I can download beside source code in the same time other archives that are needed on building step