<KittyOwO[m]>woah I didn't know gnome-maps was a thing, it looks quite neate. Is there anything like it thats less gnome-y? I know of open street maps and have been wanting a dedicated stand alone client for a while lol
<leoprikler>it seems I already had an open instance that wasn't unregistered (due to the bug), so subsequent ones didn't open either
<leoprikler>KittyOwO[m]: GNOME Maps is just an OpenStreetMaps viewer
<leoprikler>there's probably a KDE version of it somewhere as well
<KittyOwO[m]>ye, I just want a nice simple minimal configurable open street maps viewer that works well lol. Closest thing I have seen yet.
<KittyOwO[m]>Also, am I supposed to seemingly not be able to drag my view around?
<southerntofu>maximed: no, some people are talking of opening a new substitute server i'm thinking about how to keep super close to upstream while allowing long-living local patches in case merging upstream takes time
<maximed>southerntofu: httpps://debbugs.gnu.org/server-request.html has some information
<southerntofu>so for example if we patch a build system, we'd like to rebuild all related local package declarations
<maximed>maybe look at "cuirass-service-type" in the guix manual
<maximed>and replace %default-channels with a channel with your modified guix
<southerntofu>i mean i'm not really a part of the project, although i've followed it from afar, but when i asked about the patch/rebasing strategy they had they had zero clue YET so i proposed to draft a little architecture document on how i would make it best from a UX perspective and how to implement it :)
<maximed>and an appropriate ‘job specification’ so only packages you're actually interested in are built
<KittyOwO[m]>ah right, I don't quite know how to send the full thing but I suspect it happens near the start. I made the mistake of playing around with emacs for one of the first times and might have done something without intending it lol, I believe it is a problem on this line
<KittyOwO[m]>`(Use-modules (gnu)(gnu packages xdisorg)(gnu packages graphics))`I haven't gotten enough sleep so unless there is something obvious wrong then I can send the full config.
<KittyOwO[m]>in my struggles with emacs I must have invoked some oddly specific command that did that, or accidently deleted and rewrote it like that. I don't know why I thought it would be a good idea to play with emacs for one of the first few times as root on an important file LOL
<tissevert>(at least, that's were I declare using xmonad, and that's where I setup tmpfs on /tmp)
<the_tubular>Which kind of package should go in a man file then ?
<tissevert>I don't know which *should* as in RFC something, but I happen to have a manifest acting as a sort of «wish list» for a collection of packages I want installed only for my user, that are a bit heavy and I don't want upgraded anytime I try and update my system (because I can live being two minor versions of Libreoffice late, for instance)
<iyzsong>my system 'packages' are only 'nss-certs, file, screen, and %base-packages'
<tissevert>that way, I can upgrade whenever I want without having to worry too much about bad weather and my computer suddenly attempting to compile ungoogled-chromium
<the_tubular>Yeah, I think pretty much everything with a GUI will be in my manifest file
<the_tubular>Packages like docker, git and curl makes me hesitate though
<tissevert>a helpful tip I received here after popping in to cry that I was lacking substitutes : ) pass it on when the time comes
<tissevert>that said, I put a good deal of my GUI everyday-use programs like my mail client or text editor, git and light UNIX tooling in config.scm, because they're light enough to be virtually «always» available
<tissevert>I don't know whether that's a good thing, I guess it's just a matter of what you consider *your* system, and what you want to simply have handy to install and «remember»
<tissevert>but ultimately drawing the line belongs to you
<tissevert>what you *have* to put in your config is everything that's relative to the system itself like users, services, etc.
<tissevert>I haven't used docker on guix, but I suppose there must be some kind of herd service for it, isn't there ?
<tissevert>hendursaga: what a timing ! we were precisely discussing docker services and I linked to virtualization services by error
<tissevert>the_tubular: yeah, shepherd is the init system of Guix, it performs the same general operations that others like systemd, openRC or runit do on other distributions
<the_tubular>Yes that I know. But the page you sent doesn't really mention shepard, it seems to list packages that are included in docker
<tissevert>I'm pretty sure you can simply «install» a daemon in an environment to run it by hand and see how it goes, but the «correct» way to enable a service is through your config.scm by including it in the (services …) field
<the_tubular>Ohh, so I should have installed docker in my config.scm ?
<tissevert>hendursaga: yes and no, technically containers are not proper «virtualization» (there's no virtual machine or emulation involved, since they're precisely about reusing the kernel in a separate (sub-)filesystem
<hendursaga>K8s seems like it would take a little while to get packaged, Golang and all
<tissevert>the_tubular: likewise, there's a docker-service-type and a docker-configuration
<tissevert>and the page I linked is there to tell you about the various options you can pass to tweak your docker daemon a bit
<the_tubular>But I mean, what's the point of including docker in a man file if I need herd and root privileges to start the daemon ?
<tissevert>but setting that doesn't mean the docker command will be available in your environment (I don't know how it's done in guix, perhaps it will, but I mean conceptually they're two separate concepts, you could want one and not the other, and in any case they run in separate environments — you don't run docker as your user in other distros, do you ?)
<hendursaga>How "secure" is guix environment --container anyways? Same as Docker/podman containers?
<hendursaga>tissevert: well, with podman, it's rootless, so yes, I've run containers under other users
<tissevert>the_tubular: I think there's absolutely none for the daemon, but if you need the client to manage your containers, well the manifest is as good a place as anyother to declare that you want it in your environment
<tissevert>though, personally, by choice, I'd put it in my system config.scm, but it's just a matter of taste
<tissevert>some processes have to have privileges, like a web server to be able to open ports under 1024 (namely 80 for HTTP and 443 for HTTPS), they're simply granted particular privileges at run time
<tissevert>without «being» root, so I'd expect docker to be able to do the same but maybe it isn't, I don't know : )
<tissevert>that said, the general pattern and I'm trying to convey here, is that what Guix does is create independent environments that have everything they need and that only
<tissevert>so enabling a server doesn't mean you have to have the executable in your path
<tissevert>that is based on many parameters I don't really know, but think stuff like version, dependencies and such
<Noisytoot>GNOME Boxes (installed from Guix) recommends nonfree operating systems (RHEL and Fedora are both Featured Downloads, and more nonfree operating systems are listed in Operating System Download)
<tissevert>the_tubular: when a package is needed (be it from a service, and explicit installation, global to the system or to a particular user), the guix-daemon computes it, keeps it in the store, and then makes symlinks to its content
<roptat>when you install a new package to your profile, guix will download/build the required packages and create a new generation of the profile in the store, as /gnu/store/...-profile. Then, when it's successful, it'll also create a symlink from /var/guix/profiles/per-user/$USER/guix-profile-nn (where nn is your current generation+1), and symlink /var/guix/profiles/per-user/$USER/guix-profile to it. ~/.guix-profile is itself a symlink to
<the_tubular>I'm not yet comfortable enough with guile to do everything I do with Python to be honest
<the_tubular>A lot of my python usage is also on foreign machine, and I've never seen guile installed on a CTF target :/
<Aurora_v_kosmose>I find that most cases where Python has better ergonomics than Guile for getting something done usually has something to do with a library patching over Python's interfaces for that something.
<Aurora_v_kosmose>the_tubular: That's a somewhat unusual case that does constrain you a bit to choices which the target machine can execute already.
<jpoiret>i remember someone talking about aligning operating-system's swap declaration to be more in line with file-systems, ie using dependencies explicitely with a file-system like object, has this already been done? if not, i could consider doing this as it should be pretty easy, but I'm not sure what path to take with the deprecation of the old way
<Aurora_v_kosmose>the_tubular: Also, one way you could do so is to simply have a bash script extract a tarball of a Guile installation into the user's $HOME, append the loading vars to the appropriate dotfiles and execute whatever scripts you want.
<Aurora_v_kosmose>You know those scripts that get packed with data at the end so they can drop executables?
<tissevert>do you people usually package the daemon itself then find in an environment what needs to be done to run it ?
<roptat>tissevert, you can get some inspiration from opensmtpd, it's the easiest service I know of
<tissevert>thank you ! I was looking at nginx but it's still a bit mysterious on some points
<tissevert>but about the creative process for the human involved, do you know how it was created ?
<roptat>mh, creating a package for opensmtpd, reading the doc to find out which option was needed to pass a config file to the daemon, and writing the service whose config is just specifying the opensmtpd package to use and the config file to pass :)
<tissevert>wait it actually looks more mysterious to me: there's no opensmtp-sheperd-service like for nginx, how can it know what to do ?
<tissevert>at least in nginx there was something that looked like a run function
<roptat>so, it seems that you'll need an environment with the packages described in requirements.txt, and run "FLASK_APP=fhost flask db upgrade", then you should be able to run "FLASK_APP=fhost flask run" and have it run on localhost:5050
<tissevert>ok, but we know how to handle RW data, I suppose it only means we need an (instance-folder …) parameter to the service, defaulting to something like /var/lib/<app-name> and we can generate services not only for null-pointer but for any flask app ?
<lispmacs[work]>hi, I'm trying to run a guix pull on an older 32 bit laptop. I keep getting error "Git error: error inflating zlib stream"
<drakonis>its for the big changes that result in mass rebuildings
<roptat>core-updates is regularly merged into master, but it's almost guaranteed to be broken in between merges
<jpoiret>oh alright thanks, while i'm at it do any of you know if someone has worked on aligning the swap field's behavior with that of file-systems? ie being able to specify explicit dependencies? my swapfile on a (non-root) lvm partition won't swap on automatically and i'm guessing it's just a matter of dependencies since the service starts fine otherwise
<jab>Maybe someday I'll set up a ham radio...When my boss calls me, it will actually get routed to my server..., which will then forward the call to my radio tower, which will then broadcast the unencrypted signal to my phone, which I will then answer. Then when I respond to my boss' question, my phone will broadcast back to the ham radio, which will talk back to my boss via VoIP...
<therealdonotshak>I am wondering where I can find the total disk size of the official guix substitute servers. And if possible how much resources are being spent building the store. Wondering what running a complete mirror might look like.
<lispmacs[work]>jab: oh, no, don't send me down that path. I'll be dead on the first rust build
<lispmacs[work]>is there a trick running guix pull from the repl to disable compression, or change compression method?
<apteryx>was there a way to retrieve the hash of a file added to the store with 'add-to-store'?
<cybersyn>hiya guix, i'm working on my first package contribution (planning to be first of many!) and I've hit a snag where make tries to use the network to import a module (which as we know is a no no). browsing around I found that the solution is to use propagated inputs, so I went ahead and packaged the missing module in the same file, and tried to use it as a propagated input, but it still wants to ask the network for it. any pointers on
<apteryx>wonder how I ended up with "ld: ld: DWARF error: can't find .debug_ranges section." when attempting to build Guix from my tree
<guixy>What is the difference between the "uncompressed-iso9660" and "iso9660" system image build types?
<guixy>What is the difference between the "uncompressed-iso9660" and "iso9660" system image build types? In what situation would I want one over the other?
<civodul>apteryx: that's weird; that's when linking guix-daemon?
<civodul>guixy: "iso9660" is a gzip-compressed ISO, with transparent decompression when you boot it: it saves space but takes more time to build than "uncompressed-iso9660"
<guixy>That's good to know. So if I wanted to distribute an image, I would want it compressed, but if I wanted to just build a live ISO image and didn't care about space, then the uncompressed option would probably be faster? Good to know.
<guixy>Is there a way to run a clean shutdown from the recovery REPL?
<guixy>Either I quit the recovery REPL and it kernel panics, or I force it to power off.
<guixy>And upon kernel panic, I have to force it to shut off anyway...
<jab74>sorry again that I had to change the hang out time last minute guix
<apteryx>civodul: I think it happened even before that. I've now git clean'd the thing and rebuilt the tree successfully.