<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? <johnjay>leoprikler: the oldest trick in the book! <dftxbs3e>nckx, IPFS would still have to have a main URL from which you gather all the substitutes <dftxbs3e>If someone publishes something that isnt reproducible, it will just be under a different hash? <jonsger>alextee[m]: there was a discussion on devel a while a go, while we should not have it. I would rather have one :) <dftxbs3e>but where do you get all the hashes from? <nckx>alextee[m]: Not all of those systemd ‘specs’ are a good idea, but I think this was already proposed, with patch even. <nckx>No idea why it wasn't mergerd. *nckx dislikes /etc/os-release but doesn't care enough to argue. <nckx>It has exactly one valid use case: to display ‘You're running Foo on BarOS!’, which is stupid. All other uses are evil. <dftxbs3e>> doesnt care enough to argue ; > argues <leoprikler>Let's create an /etc/os-release with bogus content to trick people who use it for evil. <leoprikler>to actually infer BarOS from a program that shouldn't care (e.g. malicious Javascript in your web browser) <leoprikler>IIRC most browsers can natively tell that you're running some flavour of Linux, but do not know the exact one. <leoprikler>If you are however able to read /etc/os-release (through whichever means), you know exactly what distro someone is running and have an easier time looking up CVEs. <Blackbeard[m]>But in Spanish they also have accents and the same first letters <nckx>dftxbs3e: case "$os" Ubuntu|Debian) cp foo.ba /etc/default/blah;; RHEL) service buz;; *) echo 'Unknown OS impossible you have been hacked install a corporate-approved distro™'; exit 10000;; esac <nckx>Everything I've ever seen over years & years: this. I didn't used to be this angry; I became it. *nckx is never really angry 🙂 Don't worry. <Blackbeard[m]>I've come to realize I don't really use the www much anymore <Blackbeard[m]>Only stuff for my school with noscript and ublock and all the privacy addons <nckx>The great thing about Guix that makes me haps is that this can just be done as the simplest of services, and everyone else is free not to care about the spex crowd. <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. <snape>and there are tools for that: 'guix challenge' compares outputs of different substitute servers, and 'guix build --check' builds twice, and then compares the outputs <nckx>leoprikler: Why'd you get out? <leoprikler>I'm still studying, but there are no more courses in that area that interest me. <leoprikler>So I've worked on my secondary specialization and take some other courses to pass the time while I'm not writing my thesis. <Blackbeard[m]>nckx: yes, I had the same issue. I also hate Descargas and Documentos starting the same <leoprikler>Documents and Downloads literally have the same problem in English, though <nckx>Nothing has created Documents here, though. Maybe I'm just lucky. <leoprikler>People less versed in English benefit from translation imho <Blackbeard[m]>leoprikler: what about Imágenes Público Vídeos Música breaking lots of programs <Blackbeard[m]>Because they have accents and not every program supports that on paths and makes it impossible to use them <leoprikler>I firmly believe, that we can all use Unicode in 2019, current year argument. <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]. <nckx>They are just buggy and need to be fixed. <nckx>What I don't like is this being done at the fs level, so depending on the locale of the week (in my case literally) it uses a physically different folder. <Blackbeard[m]>But I am not saying my feelings towards it are rational haha <nckx>I can't believe I'm saying this buit I think Windows did this right, at the UI level, but I can't confirm. <leoprikler>To this day, that is one of the mindbogglingest decision I've ever seen. <nckx>sneek has ‘learnt something’, we can only wonder what it was & despair. <nckx>sneek: What is To this day, that? <sneek>I could be wrong, but To this day, that is one of the mindbogglingest decision I've ever seen. <leoprikler>Imagine seeing "Bilder" in your folder, then opening it in the terminal and having to 'cd Pictures' <leoprikler>Because of course Windows does NOT understand 'cd Bilder' <leoprikler>(Linux has the same weirdness with .desktop files, which is only acceptable because they're literally text that you can read and grep.) <nckx>Well, that's another level of wtfery. But if you're trying to convince me that there is no solution and we're all doomed: good point. <nckx>All eyes nervously on leoprikler. <nckx>They have said The Words. <leoprikler>IIRC, you can set all the $XDG_CONFIG variables in some file BEFORE those directories are created. *Blackbeard[m] silently gets pop corn <leoprikler>I'm not sure, which file it is, but I vaguely remember something like that existing on Gentoo. <leoprikler>Assuming you only change your locale, but leave that file unchanged, everything should be fine. <leoprikler>Blackbeard: Yes, that one. You may want to change $XDG_CONFIG_HOME, but who does that? <nckx>Blackbeard[m], leoprikler: Thanks for that info. <nckx>I'll have to try it out. <Blackbeard[m]>Now I don't care about emacs, icons, directories, or anything <leoprikler>I don't need anything but Emacs, now I don't care about emacs ??? <leoprikler>I really like Emacs, but for me it lacks one crucial thing, that has become a fetish for me: <Blackbeard[m]>I've been saying and writing words I don't mean recently. I wonder if I am losing my mind <leoprikler>Emacs by default has: A title bar, that is practically useless, a menu, that no one uses because shortcut exist, and a toolbar that no one uses because shortcuts exist <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. <nckx>To be clear: I don't mind that at all. <leoprikler>Apropos $XDG_CONFIG_HOME, what do you thing of $XDG_CONFIG_HOME/guix/profile? <Blackbeard[m]>I have emacs with doom-bar gruvbox theme automatically changed for light/dark and terminus font. And that's all I need visually :) <nckx>leoprikler: That's usually ~/.config, right? Wouldn't it belong it whatever-is-usually-~/.local? (And so it begins.) <nckx>Basing that mainly on the ~/.local/bin precedent by the way. <leoprikler>but we already have $XDG_CONFIG_HOME/guix/current (which I find should be renamed to guix/channels, but I digress). <nckx>leoprikler: I consider that an outlier already for the same reason. ~/.config/guix makes sense to me apart from current. <nckx>Although, go UNIX enough on me and I'll concede that what is a symlink but a text file anyway? But let's not. <leoprikler>But where would you store current? ~/.guix-current? <leoprikler>or should we perhaps make ~/.guix/current and ~/.guix/profile? <nckx>My point is pedantic either way 🙂 If we break things, let's break 'em once and fix 'em perfectly. <leoprikler>Basically, I want to find a way, that would allow for multiple profiles per user without needing extra scripting in ~/.$SHELL_CONFIG_FILE <leoprikler>And given that both current and .guix-profile are in fact profiles, I'd like to put them into one place and start working from there. <nckx>I use for my scripts and a distribution I used to use put it in $PATH by default, but don't ask me what it was. <leoprikler>don't worry, I'm aware that some tools use .local/bin even we both can't name them <nckx>~/.guix is fun to type, ~/.local/guix acceptable because you get that nice ‘clean ~’ feeling, ~/.local/share/guix is just meh. <nckx>leoprikler: Oh, I wasn't. I wasn't dancing around anything. Now you've made me curious. <nckx>OK so compromise ~/GUIX everybody hates it great done next item. Bed time for nckx 🙂 <lispmacs>Hi, I wanted to learn how to package libhackrf, which is available from a git repo and uses CMake. What would be a good package to hack on, to modify it into a libhackrf package? <lispmacs>it is a C library, if that makes a difference ***catonano_ is now known as catonano
<str1ngs>lispmacs there is a cmake-build-system . use git grep cmake-build-system in the guix git tree <str1ngs>any one of the packages using that is a good starting point <dftxbs3e>nckx, oh.. well that patch to commencement isnt actually useful for bootstrap-tarballs.. <dftxbs3e>and I'm not even sure it has to be there for growing GNU Guix... <dftxbs3e>because I am literally lost now everything that I believed was true is now false. ***jje_ is now known as jje
<efraim>working on bootstrapping is tough <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? <roptat>peanutbutterandc: do you have guile in your profile? <leoprikler>You have to first use (use-modules (gnome)) or something like that before you can use other stuff. <peanutbutterandc>leoprikler, I see. I was following the code examples that they have in their documentation. I will try it right away. Thank you very much <peanutbutterandc>I have been infected by this crazy idea of extending gnucash using guile, graphically. I don't even know if that is possible. And I'm barely just trying to scratch the surfacd <leoprikler>does gnucash not already have a guile interface? <peanutbutterandc>It can be extended using guile, yes. It is one of the featured free softwares in guile.gnu.org <leoprikler>Keep in mind, though, that this interface is limited to GTK2. <leoprikler>If you want to use GTK3, there are two projects to do so through GObject-Introspection: guile-gi and g-golf <peanutbutterandc>leoprikler, It works! Thank you. I see. guile-gi and g-golf, hun? I will look them up. Thank you very much. (I was worried since Gnucash 3 probably uses gtk3) <leoprikler>guile-gi is packaged in Guix, but IIRC the package differs from upstream, so I'm not sure whether it works as intended, but give it a try <leoprikler>Also check whether Gnucash itself has a typelib associated with it. <leoprikler>I don't think g-golf is packaged and guile-gi is the more mature one right now. <peanutbutterandc>g-golf couldn't be found. I see. guile-gi then. But it does warn that it is pre-alpha code in the description <leoprikler>I'm sorry, but I have to go now. Catch you later. <alextee[m]>similar question: how can i reliably tell if a system is a guix system? <oriansj>alextee[m]: [ -e /root/.guix-profile/bin/guix ] && echo "Success" <roptat>I wouldn't use that, root shouldn't have guix in its profile <roptat>and it could be the case on a foreign distro, with guix installed as a package manager <roptat>you could check for the absence of /etc/os-release and the presence of /gnu/store for instance ***zig` is now known as zig
<alextee[m]>foreign distros dont have /run/current-system right? <roptat>unless it's used by the distro (maybe nixos does that?) <alextee[m]>that sounds like the best bet, /gnu/store + /run/current-system <alextee[m]>i very much doubt someone on nixos will install guix on top <g_bor[m]>alextee: you could also try guix system list-generations... <kmicu>(NixOS uses /run/{current,booted}-system) <leoprikler>> similar question: how can i reliably tell if a system is a guix system? We had a discussion about that yesterday and came to the conclusion it was an evil use of /etc/os-release. <leoprikler>imho scripts shouldn't behave differently based on the distro they run on <civodul>rekado_: mumi frequently dies with "too many open files" these days <civodul>i think we should have a service for it (not that it would fix the problem, but we'd have better traceability) <g_bor[m]>civodul: yes, I have also observed that. Do we know what these open files are? <civodul>cached bug reports i guess, but i don't know <g_bor[m]>:) I mean the caching, not the crashes... <g_bor[m]>btw I agree with having a service would be nice. <civodul>i don't know if there were recent changes to explain the crash <g_bor[m]>oops, the mumi git repo seems to be down. <g_bor[m]>An error occurred while writing CGI reply is all I got <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? <g_bor[m]>civodul: I see that mumi was last updated on 2019.09.20., so it should not be it... <alextee[m]>leoprikler: "imho scripts shouldn't behave differently based on the distro they run on" i am running a script that selects a package to install based on the distro <leoprikler>why would you do that if you have guix (the package manager) tho? <alextee[m]>leoprikler: making an all-in-one binary installer for my program <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 <rekado_>civodul: I noticed that too. This started happening since I went back to (web server) from (fibers web server), because with fibers I’d get crashes when parsing the Debbugs XML. <rekado_>but I had no time to investigate yet. <alextee[m]>really? im not sure if that will work properly. what about glib schemas? i need to try this later <civodul>rekado_: ah ok, maybe we can stick to the less unstable version for now? <civodul>the problem with "too many open files" is that it doesn't actually crash, it just enters an endless loop, it seems <rekado_>well, I wish I could, but it’s not a change in mumi that’s wrong here <leoprikler>IIRC it uses magic to fake /gnu/store and other stuff into existence <rekado_>I got this once I entered an environment with the current guix <rekado_>I don’t know at what point fibers started failing on me. <rekado_>civodul: trust me, you don’t want a crash on *every* debbugs communication. It’s better to just shut off mumi then. <alextee[m]>leoprikler: this sounds really nice! if i can get this to work without having to package for each distro it would be awesome <leoprikler>you can also use a manifest for programs that do not run out of the box but work inside guix environment --ad-hoc stuff <rekado_>the problem appears to be with locales in the server threads <rekado_>any communication outside of the server threads is fine. <civodul>i mean if it crashes once every two days and gets transparently restarted, that's ok <rekado_>(the savannah git repo doesn’t respond to me) <civodul>guix is very much into locale business :-) <civodul>Savannah seems to be having troubles <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 <zap>You just need to source it <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 <zap>one of them can be shell completion <valignatev>Oh, right! And guix users might opt in or opt out of it <valignatev>I didn't think about outputs immediately because I'm a total guix noob <zap>valignatev: common :) you were minority of a minority of a minority when you were using arch. Now with guix you went one level deeper <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”.) <civodul>PurpleSym: depends on what you mean for "globally" <civodul>do you mean that the UI would map package names to your packages instead of those of the 'guix package? <civodul>or do you mean that you'd replace things in the package graph? <civodul>for the latter, you can use package-input-rewriting <janneke>coreutils-mesboot finally builds again, now on to `hello' <janneke>patch-boot0 fails its tests without ED, hmm <Parra>if I add ruby as input dependency, the command "ruby" will be visible during compilation? or do I need to set some variable like PATH? <Parra>I could patch the package, but I couldn't solve the tk dependency <Parra>related to what I was talking yesterday <janneke>hmm output (`/gnu/store/58a9flvxxqxcjjk9wg6kici64w7v49cl-glibc-2.29-debug') is not allowed to refer to path `/gnu/store/cvqyhi8ii53djaza5mf3g0jlzs3ri8yw-linux-libre-headers-bootstrap-0' <Parra>pkill9: do you know how can I set the PATH during build time? <zig>security, ocaps et al. ***ng0_ is now known as ng0
<zig>Parra: you can add ruby as one of the input, I don't remember which one. <pkill9>Parra: you can use setenv, there are some examples in some otger package definitions <Parra>zig: I'm doing that but seems not to work <Parra>pkill: I'm going to check that <Parra>I need doc about the language itself, and all functions that are available, where can I find that? <sneek>Welcome back nckx, you have 1 message. <nckx>dftxbs3e: Where are you lost? <rockandska>Didn't take a look for long time, but is there a clear distinction between "build dependencies" and "run dependencies" in the package description ? <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>nckx: because, as a result, you embedded more packages than needed in docker images for example <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 ? <nckx>What you're really asking for is the ability to lie to Guix: ‘this package is used only at build time, never at run time’. Oh? Guix answers. ‘Prove it. Remove all traces of it in your output.’ <rockandska>if i expose it simpler, the docker image provided by bash is around 12Mb when the one generated with 'guix pack' is around 80Mb <nckx>rockandska: I checked and my system's bash doesn't retain a reference to bash-minimal. <rockandska>nckx: ok, but the last time a pack bash with docker, bash-minimal was inside the image <nckx>rockandska: Because one of the packages in your image retained it as a reference (‘run-time dependency’ if you will). <nckx>Guix *has* the distinction between build- and run-time, it just doesn't let tricksy humans meddle with it. <nckx>So it's not there in the package definition. <nckx>I don't speak Dockerfile, I have no idea what any of that means. <nckx>rockandska: See, that's probably a lie. <nckx>ncurses-dev, sure, but on Guix, bash depends on gcc because almost every programme needs files provided by GCC at run-time. <rockandska>nckx: ^^ the package are clearly add before the build then removed at the end <rockandska>maybe other programs needs gcc , but it seems that bash not <nckx>Then there's a bug in Guix's bash package and it can be fixed. <rockandska>i didn't compare too many dockerhub images vs one build by guix <nckx>And I can only grok Guix packages, not Docker images, sorry 🙂 <rockandska>that's why i asked if there was a clear distinction between build vs runtime dependencies to know if it was a design or package definition problem <ishmael>am i the only one who's getting a wierd bug with Emacs' lisp-dir loading? <ishmael>after the last upgrade Emacs complains about trying to load a directory that doesn <nckx>rockandska: You can ‘declare’ dependencies as build-time-only simply by ensuring the build result doesn't refer to them. <bavier>ishmael: no, the same happened to me recently, but then I rebooted (unrelated) and afterwards things were fine. <ishmael>bavier: oof, what a pain, i'll try that i guess <nckx>rockandska: You say bash doesn't require GCC at run-time, but that's not true. It requires libgcc_s.so. <nckx>This is true on any distribution, not Guix-specific. <rockandska>nckx: i assume gcc is not require from what bash dockerfile describe, didn't take a look deeper <bavier>ishmael: I didn't try very hard to fix, but it seems like emacs should just refuse to start if a directory in EMACSLOADPATH doesn't exist <snape>ishmael: does 'env | grep -i emacs' returns EMACSLOADPATH <nckx>rockandska: That Dockerfile was written by humans. Guix never lies, humans do 😛 <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? <ng0>pkgsrc on NetBSD, yes <snape>it means you should 'guix pull' ;-) <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 <bavier>snape: there was a change recently? <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. <rockandska>nckx: bash:4.0 12.6MB / profile:347l4b6njy37q5hksxybfp0szjrqclwm 83.8MB <bavier>cool, probably too difficult to handle a transition like that more smoothly <snape>yes, it was for the greater good ;) <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 <snape>ishmael: what does 'guix describe' say? <nckx>rockandska: The ‘real’ GCC alone would be several 100 MiBs, maybe even GiBs. (laptop too slow to check.) <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 <snape>nckx: how does Guix know which inputs are embedded in a package though? <snape>does it grep in its output for /gnu/store? <nckx>Well, not grep, but it's exactly that: a string search. <nckx>To paraphrase one of the first Nix papers: it's crazy but in practice it actually works. <bricewge>Should I reopen an issue for such a minor issue? <nckx>bricewge: Bugs go read-only n weeks after closing. I think mailing nnnn-reopen@debbugs.gnu.org will work. <nckx>If that doesn't, try ‘reopen nnnn’ in the body to control@debbugs.gnu.org. <snape>nckx: you don't have a reference to that paper at hands right? <alextee[m]>is there a reason the guix pack tarball is read only? <bricewge>nckx: Will it reopen it? Because this is just a kind of off-topic comment on the original bug report. <bricewge>But it's the only place I have mentions of it. <nckx>bricewge: Ack, I confused ‘unarchive’ and ‘reopen’, sorry. <alextee[m]>but i can't figure out how to extract this o.o am i doing something wrong? <nomr>#guix, how do I tell `guix upgrade` to never bump the major version of a package? <snape>alextee[m]: you can extract with 'tar xaf `guix pack -RR -C xz zrythm`' <nckx>So cut through the academese and my paraphrasing wasn't too libre 🙂 <alextee[m]>snape: that worked, thanks. gnome must be broken or something <bavier>alextee[m]: I think gnome's archive tool tries to extract to the same directory (/gnu/store) which I would not have permission to do <nckx>The previous pages explain how Nix (and hence Guix) handles dependencies in general, which might be relevant to rockandska as well. <nckx>alextee[m]: And writing to /gnu/store is always a bug in the Guix world; the read-only nature a feature that catches it. *nckx has tpyoes evreyday. <alextee[m]>oh i see, i didn't know you could specify "/" in tarballs <snape>nckx: very interesting. So is an input that doesn't end up in the output the same, in practice, as a build input? <snape>(except when cross-compiling?..) <rockandska>nckx: got it, thanks for the doc. Not sure if i got it well, but by scanning hash, is there no way to know if the hash is only optional or not isn't it ? <nckx>It turns out to have been so, you could say. ‘Build’ inputs aren't treated differently at build time, everything's a (native-)input, so it doesn't really matter or I'm missing your point. <snape>so my question is rather: why would anyone declare as 'input' (and not 'native-input') something that doesn't end up in the output? <ng0>you should also take that paper with 2 grains of salt, in guix and nix some things changed since then <nckx>I linked it only for the ref scanner, which hasn't. <nckx>snape: I can't answer that hypothetical generally off the top of my head. There are probably legitimate cases for non-native build-only inputs. Dunno. <kmicu>snape: cuz folks do whatever builds and call it a day. Sometimes there’s no good reason behind it. <snape>I don't even know if people to that, I just wanted to know if inputs *should* end up in the output <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. <nckx>rockandska: Sorry, I'll stop now 😉 <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? <nckx>That's how I remember it. Which is fair. <snape>(and that could be removed by just removing the 'git' input, or by patching the source if the 'git' input is needed for other reasons) <snape>well my example is bad, because this PATH check would happen at build time, not at run time, so there would be no hash of git in the output <snape>let's just forget about it :) <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 hasn't peeked into #nixos in… ages. Wow. <kmicu>Some folks wanted build but as we can see native prevailed. <nckx>Evocative *and* accurate. <kmicu>consult-docs-before-use-inputs <kmicu>consult-docs-before-use-native-inputs <kmicu>Isnt_java_like_that_factory? <nckx>(inputs …) (more-input …) (extra-inputs …) ; now you *have* to read the docs. <kmicu>nixIsMoreLIke = super: let self = super.pkgs; in rec { self.nix }; <nckx>You forgot withPkgOverrides. Mmm, withPkgOverrides. *kmicu should have add 70% of bash to make it more realistic. <kmicu>BTW, do we have any fancy stats to check what's top biggest closures on build farm? <nckx>It's suffered an (btr)fs failure. <kmicu>I assume no backups (btrfs snapshots) if it’s still offline. <kmicu>That’s a good time to remind: raid is for staying online, backups are for backups‑backups are more important. <nckx>I think it was hardware, actually, but I'm not sure. *kmicu went to start another borg backup, just in case. <nckx>Snapshots certainly aren't backups, and especially not on btrfs 😛 <kmicu>Snapshops are backups if we send them to backup machine. <ng0>kmicu: i call gnunet with all dependencies or firefox because of rust^N <mbakke>I think it was a btrfs RAID, actually <kmicu>I hope they read manual before using it. <kmicu>And not an ancient kernel with unfixed bugs. <nckx>kmicu: Snapshots are nice for a consistent image but I wouldn't back up btrfs to btrfs myself. I've had too many fs-specific failures to trust one true fs across all tiers. <nckx>kmicu: That wiki is notoriously outdated. <kmicu>I use snapshots for diffs only. For example to inspect effects of running guix commands. <kmicu>nckx: nah, it's updated constantly. I have it in rss and follow dev maililng list. <nckx>I've found the thread; it's a weird fs-specific mount failure 😉 surprisedtrombone.ogg <kmicu>It was outdated in the past though (years ago). <nckx>kmicu: Really? That sure has changed then! <kmicu>Is that that thing related to not mounting after Guix updated cuz lazymounting has stopped working? *nckx mumbles ‘too little too late’ into a paper bag & sets it on fires & continues testing bcachefs. If I'm gonna lose data Imma do it in style. <nckx>kmicu: A manual mount goes zombies so no. <kmicu>I use bcachefs as SSD cache on my nas. <nckx>kmicu: bcachefs or bcache? <nckx>(~fs = bch2 in kernel code I think.) <kmicu>For me bcache is just stable bcachefs. <kmicu>BTW installed Arch recently. I do not recommend. <kmicu>Executing all those stateful commands by hand… <kmicu>How folks can tolerate that. <kmicu>(In my mind the whole process was much more complicated than installing a Guix System.) <kmicu>(And I’m a former Arch user xD) <nckx>Why installed it, I mean. <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. <leoprikler>You've missed the biggest resource of troubleshooting in Linux. <leoprikler>Arch is like Murphy's Law. If there is a bug, then some Arch Linux user will experience it. <kmicu>Arch wiki is great, just the imperative stateful interaction is not for me after experiencing NixOS/Guix System. <davexunit>I used arch for awhile back in the early 2010s. learned a lot by using it but eventually grew tired of updating my system and having everything break. <nckx>leoprikler: I use their wiki and package search all the time! Just not their OS. Their mailing list was a fun source of drama in the systemd days too. <davexunit>then returned to debian, missed the freshness of arch packages. then guix was started so I decided to use something that I had to help build instead ;) <leoprikler>s/the biggest resource/an opportunity to contribute to the biggest resource/ <leoprikler>And who would not want to experience a bug so big you can write a wiki article on it? <pkill9>anyonanyone gonna tryinstlaling guix system on pinephone? :) <kmicu>Let Replicant folks install Replicant on it. Done. :) *nckx .oO Why's my system 14 GiB into swap oh god I'm building both of the Chromiums <leoprikler>I'm building one version of Chromium on my first core while building another version on the second. I'll take a memory page and SWAP IT! <kmicu>And then share them as xmas gifts. <nckx>Phew, I could still ssh in and kill 'em. <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? <nckx>kmicu: I run a substitute server. It explicitly blacklists Chromium because I hate it. So… 😛 <kmicu>nckx: welcome in my Ethical Software Distribution Guidelines where Chromium is unethical cuz it’s driven by Big Corp. <ishmael>nckx: oh yeah you're right, i completely forgot about that <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. <leoprikler>Oh, one more thing about Gentoo: `emege --oneshot portage`. <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>And if you have some resources to spare, you can couple a channel with a cuirass instance that builds its packages. <kmicu>I undrestand your point of view but for me ELPA, MELPA, hackage, etc are useful resources. <kmicu>I only want ELPA where users can share their packages. So GCA where users can share their channels. <nckx>Pushing & pulling packages to/from a centralised GuixHub will never happen, because Guix would be responsible for distribution of any proprietary crap pushed by (malicious) users. <kmicu>So you go to GCA and see kmicuchannel: in addition to libre also ethical software compiled with minimal dependencies aka Emacs w/o GTK. Subscribe to channel. <kmicu>nckx: do you see any proprietary software on ELPA? <nckx>I don't know how to answer that. <leoprikler>The thing is you're confusing two different things when talking about your idea in greater detail while claiming it to be one thing. <leoprikler>Let's say you wanted to share your build of Guix' Emacs. <leoprikler>Then you would just host a Cuirass instance and let others use it. <leoprikler>Or if you want it to be more grass-roots, you can copy /gnu/store/xxx-emacs onto a USB stick and go from there. <kmicu>Sure, that's a manual imperative way. We already have that. <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. <leoprikler>ELPA is also just a source repository. When downloading a package from it, you build it locally inside your Emacs. <nckx>It's all binaries all the time. <nckx>But there's only one trusted ‘input’: pulling from savannah's guix.git. <leoprikler>That's the point. You're confusing ELPA (a source repo) with Guix CI (a binary repo). <leoprikler>You can guix challenge it, but only if you're building stuff from source. <nckx>kmicu: Implementation aside, g.t.g is identical to ci.guix. The point is that both distribute (Free) binary blobs, and you can compare them to see if anything fishy is going on. <kmicu>nckx: you did not modify anything on it? <nckx>kmicu: It continuously build unmodified Guix from source. <kmicu>Like for example IceCat w/o PulseAudio? <kmicu>Heh, then we talk about different things. Sorry for being not clear enough. <leoprikler>That would be a package that needs its own channel. <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). <jlicht>kmicu: so you want this registry to be for channels? Not binary substitutes? *nckx understands less & less but that could be the multi-tasking talking. <kmicu>jlicht: i think Guix Packs are closer. <jlicht>yeah, packs <--> binary substitutes is not really a relevant detail ;-) <kmicu>jlicht: it is if your are not on Guix. <jlicht>semantically speaking, not really; it would have most of the same drawbacks already mentioned by others. <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 <leoprikler>"I have this custom gcc, that is really just GCC with a few little tweaks and I did not do anything harmful to it, I promise." <nckx>The fact that substitutes are these hard-to-grasp things floating in a namespace only addressable if you have the source is IMO a feature. Horribly worded, but still. <jlicht>don't you actually only need the derivation? <nckx>jlicht: Actually the way I ended up writing that I really don't think it's pedantry after all. Certainly not intended to be. It's a big deal to me. *nckx hopes to have this clearly elucidated in their brain by FOSDEM but don't count on it. It's not a very lucid place. <nckx>Pun intended, but my brain. <jlicht>but I understand the difference, thanks for taking the time to explain! <jlicht>but substitutes map to derivations, not packages right? <leoprikler>Totally unrelated, but can we collect some non-offensive insults for sudo like "It's not a very lucid place."? <nckx>packages → drvs → subs, yes. <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'. <leoprikler>I don't think you can come up with a service, that distributes Guix packs alongside their source without using an explicit forward mapping. <leoprikler>And at that point how is this service different from a channel + substitute server? <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. <nckx>Your friendly free software TLA infiltrator now really signing off, see y'all later o/ <leoprikler>Folks, I'm sad to inform you, but we've been beaten. <leoprikler>Gentoo puts out weirder error messages than Guix :( <leoprikler>It also beats is in amount of time spent not accomplishing anything (dependency resolution vs. Guile overhead). <bavier>would be nice for Guix to get a mention on proot-me.github.io for 'guix pack -RR' <sneek>kirisime, you have 1 message. <sneek>kirisime, nckx says: Can't speak from experience, but (guix)Desktop Services in the manual explains one way to use these files with Guix. <nckx>Hm? Oh, that was about D-Bus .service files. <kirisime>Oh, right. I added bluez to my profile and the org.bluez.obex.service became known. <nckx>Good to know, I might need it someday. <nckx>When I finally lose my last µUSB cable. <kirisime>The old-fashioned way, though. I don't know what adds the executable, but it's used by bluetooth-sendto which was in my PATH. <kirisime>It looks like a GNOME thing, maybe it's supposed to appear as an option in nautilus when bluetooth is detected or some such. Didn't fix the detection issue though. <bavier>oof, with 'guix pack -RR' binaries, I get 'FATAL: kernel too old' on the remote system <bavier>I wonder if passing -k to proot for kernel emulation might work <nckx>kirisime: Without running Guix locally? Not that I know of. <nckx>(Just ‘Guix’ 🙂 Unfortunately-named subreddits notwithstanding.) <nckx>Looks like all that's missing is a better UI (must be static on the server side, use libre JS, & degrade nicely without it). <civodul>nckx: re ref scanner, yes, keeping it fast sounds more important <civodul>bavier: isn't "kernel too old" coming from our own ld.so, if you have a kernel older than the one our glibc supports? <bavier>civodul: I think it's coming from proot <kirisime>bricewge: Oh wow, thanks! Looks like what I'm looking for is packaged too. <bavier>the changelog mentions the addition of -k to circumvent the 'tool old' message <bricewge>By the way, why doesn't guix.gnu.org use the package browser from hpc.guix.info? <bavier>civodul: or yeah, maybe from ld.so indeed <nckx>bricewge: Neat! Regex search is weirdly simplistic though. ^ works, $ obviously matches the home page URL. <nckx>So volunteer Webfolk plz respond 🙂 <bavier>civodul: but oh, the proot'd packages work on another machine with a slightly newer kernel :) <alextee[m]>how do you make a meta package again? do you just add the dependencies as inputs and that's it? <leoprikler>alextee: Propagated inputs, see `guix edit gnome` <alextee[m]>omg all the gx-* lv2 plugin packages. im thinking to merge them <leoprikler>I find it funny, how many plugin systems exist, that exist solely for the sake of modularity as most users will just install them all anyways. <nckx>alextee[m]: …to merge all lv2 packages into one? <alextee[m]>nckx: there is literally a meta package by upstream <alextee[m]>making all these packages separately was not very smart lol <alextee[m]>leoprikler: i'm making an lv2-plugins meta package that installs all lv2 plugins <alextee[m]>but while i'm add it i will fix the gxplugins packages too <civodul>bricewge: for guix.gnu.org, we initially wanted to have something that can work without JS <civodul>now, it'd be great to have "progressive enhancement" so those who're fine with JS can have a search box and all <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? <nckx>And you'd still have to guessbisect. <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. <nckx>That looks suspiciously human-generated 😉 <kirisime>Toss in arbitrary delimiters for when the leading letter changes and when you enter special package groups like cl or python and you'll be able to keep them somewhat separated. <nckx>Or do you have an algorithm for that? <nckx>You'll need variable-size pages for that to work. <kirisime>I'm pretty sure some dictionaries and whatnot used to do this, but I don't have an algorithm no. <kirisime>But, suppose you took your list of package names, sorted it, then sectioned it off to fixed-size chunks... <nckx>I guess (shortest-common-substring (last-entry previous-page) (first-entry this-page)) or something. <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. *pkill9 wants to get a pinephone and install guix system onto it <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>pkill9: My jolla runs guix, good enough? <pkill9>is that the distro or package manager? <nckx>‘The Jolla smartphone is a smartphone produced by Jolla that runs the Sailfish OS, released on 27 November 2013 and manufactured in China.’ <nckx>I'm going to say package manager. <nckx>If not, BLOG POST NOW PLZ. <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