<pineapples>In this case, the next (un)logical step is a thin, Electron-based client that fetches a web app from the Internet for every "desktop" application on your computer. DRM at its finest
<lfam>It's something that GNU should focus on. I don't know many "non-techie" computer users who prefer to use native applications over web-based replacements
<lle-bout>web based IDEs simplify things a lot for companies and their employees, suddenly they only need to give out thin clients to their employees and rent servers with as-you-use pricing. It also means employees don't lose time setting up their own machine, for each and every project.. but GNU Guix if generalized can also in a very elegant and respectful way achieve that.
<lfam>Native applications were easier to use, until they weren't
<lfam>Local files were more convenient, until they weren't
<lle-bout>For companies, local files are intellectual property loss risk
<lle-bout>I still "struggle" to share files to my peers with onionshare some times
<lfam>Already, a huge number of corporate office workers do all their real work over VNC
<lle-bout>And the user I am giving it to needs Tor Browser
<lfam>They have their laptops at home these days, but they are just terminals
<lle-bout>Amazon Workplace or Citrix XenApps is very common yes
<lle-bout>But let's be honest, this isnt the same monster, we can't be at the forefront of technology on every subject with GNU-spirit projects and ideas that works for real people. There's nothing we can do to prevent people from doing these things.
<lfam>To replace these things with free software, there are so many missing pieces, at every level of the stack. So I think we have to be pragmatic in our advice, and focus on building the movement
<lle-bout>There's Eclipse Che by Red Hat but really unfortunate it's not AGPL instead.
<lle-bout>The permissive license for that project specifically makes it so easy to abuse and strip user rights along the way
<dannym>vagrantc: Did you make the image to boot the novena with using guix system disk-image? Which image type did you use?
<dissoc>how do i add authorized keys to the (operating-system ...) in config.scm? am i supposed to modify the guix-service-type do append the keys? would i likely use (local-file "something.pub") ? what format is (authorized-keys expecting the keys to be in?
<dissoc>im following the invoking guix deploy page. the generated key is in this unique format with parenthesis.
<mroh>dissoc: try something like `(define %my-keys (append (list (local-file "key.pub") (local-file "key2.pub")) %default-authorized-guix-keys))` and than in guix-service-type: `(guix-configuration (authorized-keys %my-keys))`
<dissoc>mroh: it works! at some point i had it working but i made changes and it stopped. but all is good now. thank you!
<charles`>lle-bout do you still need help with Emacs?
<lle-bout>Do we need to run-geiser or it does that all automatically when it needs to?
<charles`>I've seen other geiser like thing provide the documentation in the minibuffer. let me see
<lle-bout>well - thanks for looking that up for me - I could do more research even though I've done a lot already. I've had my Emacs try-hard period which I ended because unproductiveness. At least this gave me the hang of it (I know the basic shortcuts :-))
<charles`>do you have geiser working? It required guile2.2
<charles`>on fedora the package is guile22 and the binary command is guile2.2, so in emacs you should M-x customize-variable RET geiser-guile-binary RET and change the value to be guile2.2
<apteryx>Hello Guix! IceCat question: there used to be a button on the left of the URL bar which could be used to configure the content blocking preferences on a particular site, but I can't find how to do this anymore?
<lle-bout>Yes Fedora's guile package gave me lots of trouble compiling GNU Guix notably..
<lle-bout>apteryx: Did you change version since then..? Maybe that was patched out for some reason?
<apteryx>lle-bout: the change has been quite some time ago, I think it was with one of the major version bumps.
<lle-bout>apteryx: I can't see it either. But you can configure in about:preferences#privacy with "Manage Exceptions.." I guess, not user friendly I know.
<charles`>lle-bout the number 1 feature of geiser is the ability to put your cursor over a definition and press C-M-x to invisibly send it to the REPL.
<charles`>lle-bout you said you're using terminal Emacs? you can M-x menu-bar-open RET to to navigate to the geiser menu and see a lot of documentation related geiser functions. Look up symbol descriptions, module descriptions.
<lle-bout>charles`: wait a little, still doing the first thing
<apteryx>lle-bout: in that 'Manage Exceptions...' you can only remove existing entries, not add any, unless I'm missing something.
<lle-bout>charles`: I believe what I asked was solved by adding: (which-key-mode) in my .emacs
<charles`>about documentation, I don't see a super easy way to make it appear as a popup, or in minibuffer, but consider binding a key to geiser-doc-symbol-at-point it opens documentation in an Emacs window window
<jas4711>i tried reading the manual but there is a gap between 'guix package' and 'guix system' I think
<jas4711>maybe 'guix package --list-profiles' could list the system profile? just an idea. that would have helped me but maybe it is architecturally incorrect
<dannym>vagrantc: Hmm, because it seems disk-image with u-boot-novena-bootloader doesn't use its bootloader installer (it's #f in the resulting guile code build side). That's why it fell back to grub-efi (!)
<dannym>So I tried to cp gnu/system/images/pine64.scm gnu/system/images/novena.scm and s;arm64;arm32; and so on, and then guix disk-image -t novena-raw novena.scm, and then it tries to compile a cross-compiler for armhf ON armhf
<dannym>Was that new disk-image api stuff tested? Sigh...
<mothacehe>dannym: it's been only used in a cross-compilation context for now
<lle-bout>PotentialUser-62: GNU Guix's a bit weird and unconventional compared to other systems so some software's assumptions may no longer be true but whether that is a GNU Guix's bug and other software's bug is not so certain.. I believe you can just use the GNU Guix's recipe to install jupyter and python-notebook like civodul said.
<dannym>You have to decide that--but it would be better than the current thing
<dannym>The reason I started contributing to Guix all those years ago in the first place is in order to have trustable packages. All x86_64 machines have binary blobs even before the main CPU comes out of reset. There exist ARMHF machines which don't have *any* blobs in that chain.
<dannym>So at least for me, it's much more important for it to work on ARMHF than on x86_64 (or even aarch64)
<dannym>I'm not gonna prepare disk images for a trustworthy system on an untrustworthy system by cross compilation
<mothacehe>Yeah, I get that. What about having a "system" field in (gnu image) that would describe the expected system of the image. When one a foreign system, "guix system" would automatically cross-compile and when on the right system, build natively?
<bonz060>Hi guix! How would you use the graph API to draw a graph inside the REPL? I want to add an extra phase in some package definition that generates that graph and stores it in some static dir...
<bonz060>I'm kinda lost when I tried poring through "guix/graph.scm"
<dannym>I'm not sure which is better for reproducibility--do people want to be able to guix challenge the images that result from cross-compilation vs. non-cross-compilation ? Does that even make sense or will they be different anyway?
<dannym>mothacehe: But yeah: My gut feeling says yes, a "system" field would be nice.
<mothacehe>dannym: people could pass "--system" and "--target" arguments to force native/cross image building and challenge images. But if nothing is passed, "guix system" would try to do the right thing. I think having a bit of magic is necessary here so that user don't have to understand the differences between system/target, what's a cross-compilation triplet and so on.
<dannym>pineapples: I can try to do that later after I've reviewer mothacehe's patches, pushed my gnu/system/images/novena.scm, migrated the Guix system to the SATA drive (or did guix system init again ? Not sure)
<dannym>pineapples: But I've never used sway before--how would I test it?
<guix-vits>dannym: add elogind-service, then on tty `sway`. if resolution is correct, u win.
<pineapples>guix-vits: Copying the default config is not necessary, Sway will read the config stored in the /gnu/store path automatically. dannym: Just add elogind-service, run `guix install sway` and `sway`. To close it, use the META(Win)+Shift_L+E key combination.
<pineapples>guix-vits: If you don't mind: what troubles did you run into on Wayland? And what other problems did you experience with rockpro64 on Guix? I considered rockpro64 before, but there was a lack of mainline drivers for me to justify buying it
<mothacehe>dannym: hehe, thanks for testing. Regarding ABI, you can just "rm gnu/system/images/*.go".
<mothacehe>dannym: I see that the "kernel" field is commented in novena.scm, does it manaage to find the right kernel anyway?
<mizukota[m]>can guix be installed without root access at all? without daemon and builders with usergroups
<mbakke>mizukota: you need the daemon, but it's possible (although not recommended) to run it without root
<guix-vits>sneek later tell pineapples: trouble #1 for me, but i didn't heard about that from anyone else: keyboard do not working in u-boot menu. i need to use a serial console to roll-back in case of troubles. #2: i don't remember exactly, but armbian's numbering for emmc and uSD devices was different from what it was on guix boot.. use LABEL or UUID for /. #3: my 1680x1050 screen works in 1440x900 in sway.. maybe display/adapter issue.
<guix-vits>#4: need to re-attach keyboard after every boot. #5: fan is a must under load (imho). Needless to say, u have chances to NOT encounter ANY of these :) (#6: aarch64 low on substitutes.. probably u need to get a bloated-web browser from someone).
<guix-vits>mizukota[m]: main trouble, there will be no proper isolation in build processes, reproductibility may suffer. (see manual)
<guix-vits>sneek: later tell pineapples: armbian worked better, but idk why. and it has all sorts of non-free things enabled by default (also it has cpu-max-working-freqs higher, vs guix; idk why). good news: sdl games work (7kaa, blobwars). nomad-browser working too (so webkit is working).
<civodul>because a UI to authorize new servers can be tricky to get right
<mothacehe>oh didn't really think about the implications
<civodul>fetching /signing-key.pub doesn't sound confidence-inspiring for instance :-)
<civodul>or you'd delegate to the X.509 PKI, which may or may not be a good idea
<mothacehe>OK, I'll think about that. Almost unrelated, I'm having a look to your recent "substitute" patchset, looks really nice! I have a small concern about the integration with the discovery mechanism. "read-substitute-urls" is now called when "guix substitute" is started. With your patchset it would only be run once, right? That would prevent the newly discovered substitute servers to be used.
<civodul>note that in practice, if you run a "guix" command, even though read-substitute-urls is called only once, it's good enough
<civodul>because the session is terminated right when the command terminates
<civodul>it could be problematic for long-running sessions as with Cuirass
<civodul>or for a very long "guix upgrade" or "guix system init"
<mothacehe>oh I see, then I guess it's fine! Calling it in "--query" and "--subtitute" loops would be too much, right?
<constfun>Hello, is there a way to prevent having to enter the password twice when setting up with LUKS encryption? I tried seven different ways now. I'm using manual partitioning with non-encrypted efi partition. I'm still getting two prompts, one before Grub, one after. I also tried creating a separate boot partition in addition (/boot) in addition to the
<constfun>efi partition (/boot/efi), but I get a broken system that way, it appears grub doesn't attempt to use luks at all in this configuration.
<civodul>mothacehe: in --query, it wouldn't make any difference since adding the discovered substitute URLs normally doesn't change the list of available substitutes (since discovered servers are typically not trusted)
<civodul>in --substitute, it would be excessive to call it once per loop iteration
<civodul>given that we're struggling to optimize things, that is ;-)
<ces>Hey, can someone help me? I am trying to create a package for xmonad-utils, and i have used the gux import hackage xmonad-utils, and rewritten it with the define-public and define-module "blocks/style". The package has inputs ghc-x11 and ghx-random, but when i try to install it with =guix install= i get error: ghc-x11: unbound variable
<nckx>Hi civodul. Do the recent avahi improvements (thanks Mathieu!) make the offload machines act more like a mesh than a star, or just reduce the (to, one might say, zero) conf needed to find them?
<ces>I use (gnu packages ghc-x11) but it still does not work
<PotentialUser-29>Has anyone successfully installed guix system with graphical installer with gnome desktop?
<nckx>ces: (gnu packages ghc-x11) means that you created a gnu/packages/ghc-x11.scm file in your Guix git checkout, that does (define-public ghc-x11 (package ...)). Is that the case?
<civodul>nckx: discovery is for substitutes, not for offloading
<mothacehe>nckx: for now the only implication of the Avahi improvements is that your daemon is able to use substitute servers on your local network without any config
<nckx>Hmph. Shows how much I've been following the commit ML.
<PotentialUser-29>My installation doesn't work. I got a white screen saying something went wrong. I guess gdm fails.
<civodul>mothacehe: no, (guix scripts offload) has a short timeout when connecting to machines and it skips those that are unavailable
<ces>nckx: I have never used the =guix git checkout= so holdup (i installed yesterday). But quick question: i assumed that i could just write and then install packages from GUIX-PACKAGE-PATH and all the packages i have installed would be in ""scope"? Is this possible (or stupid)? Also, source https://pastebin.com/nP5A6c03.
<nckx>That should definitely be possible, but it's not a method I ever used myself.
<ces>nckx: No, i actually was able to find both dependencies with guix install.
<leoprikler>"Mostly superseded by channels" here means, that GUIX_PACKAGE_PATH is only really useful as a quick and dirty hack for testing and should not (seriously) be used otherwise.
<ces>leoprikler: This is kinda also my use case (i.e. i need a dirty hack). I depend on xmonad-utils to build my xmonad, but as soon as it has been compiled once i could actually work sort of comfortably (and make it "correct").
<leoprikler>Then it's fine, just telling you in case you want to share your xmonad with others.
<nckx>leoprikler: And ‘guix build -f’ nibbles a good chunk out of that use-case too.
<ces>leoprikler: i actually would love to share it after thou, to leave a rope for people
<PotentialUser-29>ces: I'm using Debian now but with sddm but when I was using parabola with gdm I used to have problems with gdm too but would fix with setting Wayland flag to off. I have a 64 bit capable Pentium 4
<leoprikler>Guix does not yet have Wayland, so you should be running on Xorg.
<samplet>leoprikler: There are six or so spots where we patch it to work nicely with Guix, but we only did the X path. AFAIK, one would have to check which changes need to go on the Wayland path and adapt them.
<samplet>I did the finishing touches to get GDM working with X, but I wasn’t motivated at the time to investigate Wayland.
<lfam>The installation process is trying to copy some files that are part of qoauth into the store directory of qtbase, which is another package. This is a bug in the qoauth package — once packages are built on Guix, their store directories become immutable and can not be written to
<distopico>I see, there is a workaround? or is something that we should report to guix?
<lfam>I wonder what changed that caused this to happen. This package has only ever been touched once
<lfam>It's a bug and should be reported. The only workaround will be to fix it
<jorge[m]>Se puede ver los paquetes de guix por categorias ?
<nckx>jorge[m]: No. Guix doesn't have package categories. There's a rough grouping by module name (.scm file) but it's for technical reasons, not taxonomy, nor do I know an easy way to search for packages by module.
<civodul>"guix search" takes file names into account
<nckx>You can use ‘guix package -A | grep /gnu/packages/foo.scm’, I guess. Or using recsel.
<leoprikler>would it make sense to add "keywords" or "tags" to packages?
<nckx>civodul: It won't help you search for something like ‘web browser’ or ‘IRC client’, both are littered amongst modules.
<leoprikler>proper tagging might also make some other stuff more visible, like often searched commands
<lfam>*If* we can keep the tags up to date, they will be useful. But I think no tagging system is better than a stale one
<leoprikler>Well, I'd imagine using tags for stuff that doesn't change that often.
<guixy_>Now I checkout origin/master, where origin points to my most recent fetch from savannah
<lfam>guixy_: Okay. I do recommend starting from a Git commit in our repo, and a clean worktree. You might as well rebuild the repo from scratch at that point. If you still have trouble, it will help to know which Git commit you are building from, the commit you are "building with" — `guix describe` for whatever Guix you are using for `guix environment --pure guix`, the CPU arch you are using, and any other detail that you think might b
<nckx>jorge[m]: No releases in 4 years, especially in a fast-moving field, is only a red flag. We package software that hasn't seen releases for a long time if it's useful: if it's ‘done’. But not if it's ‘abandoned’. I don't know which describes Gneural Network. How did you try to compile and run it?
<nckx>That's what a 4-year old v0.91 suggests to me...
<guixy_>ok then, I won't send a bug report. At least I'm not the only one who knows about it now.
<nckx>jorge[m]: Actually, gneural_network-0.9.1.tar.gz builds fine with ‘guix environment hello -- sh -c './configure && make && src/gneural_network’. I just don't know what to do with it now.
<nckx>OK, I can run it on the *.input files in tests/...
<nckx>...and it creates ‘final_results.dat’ with numbers, which I guess is good.
<jorge[m]><nckx "jorge: No releases in 4 years, e"> Me parece super interesante,imagina construir IA que cree un efecto cascada con todo el sofwared libre,el mantenedor es autor de otros paquetes en GNU. voy a escribirle por que solo informa por correo segun lo que vi.
<rekado>mbakke: no, I haven’t used pipewire yet. I’ll use JACK until it becomes unmaintained or all software I regularly use supports pipewire.
<rekado>I like the conceptual minimalism of JACK; it’s easy to understand. From the little I know about pipewire it seems more ambitious.
<nckx>jorge[m]: I think this would be a very easy package to write: just a name, version, gnu-build-system, home-page, synopsis etc. It doesn't seem to need any custom phases. Are you interested in trying to package it and sending a patch? We're always here to help you if you get stuck.
<rekado>I wonder if I can fix at least one mumi bug tonight.
<nckx>Well, figuratively always, I'm going to bed. o/
***jonsger1 is now known as jonsger
<ces>Hey, anyone use zsh (or any non bash)? I can't use chsh (due to pam for some reason, even with sudo) and i also assume that i have to point it to a profile binary? I couldn't find anything with a quick search on the documentation.
<hurricos>sneak: later tell vagrantc: Hi there, you talked about linux-libre on your Asus C201 / veyron around September last year, did you replace u-boot on flash to attempt to boot it, and did it ever boot?
<hurricos>sneek: later tell vagrantc: Hi there, you talked about linux-libre on your Asus C201 / veyron around September last year, did you replace u-boot on flash to attempt to boot it, and did it ever boot?